CCIE Pursuit Blog

August 14, 2008

Internetwork Expert Volume II: Lab 12 – Section 5

Section 5 – Exterior Gateway Routing – 20 Points

5.1 BGP Peering
5.2 BGP Route Reflection
5.3 BGP Origination

Thus begins the monster BGP section.  20 points!  Plus we get to deal with a network in which there is not end-to-end IGP reachability.  WHEE!!!

I drew out my BGPpeering diagram and spotted four possible route-reflectors.  I needn’t have bothered as the next task explicitly pointed them out. 🙂  The only twist is that these route-reflectors should not treat each other as clients.

All of these first three tasks were very basic, so I just did them all together.

Because of the broken IGP you’ll need to configure “next-hop-self” for all of the iBGP peerings behind routers with EBGP peerings.

The IE solution for r2 shows a ‘next-hop-self’ statement for the EBGP peering from r2 to BB2.  They do the same thing for the EBGP peering between r6 and BB1 as well as the EBGP peering between sw2 and BB3.  This seems redundant to me.  Watch the network masks (/25) when advertising in VLANs 3 and 33.  That task also asks you to use r2, but that’s a typo as it should be r3.  VLAN 45 is a /29 so watch that one as well.

5.4 BGP Bestpath Selection

Configure AS 200 to affect traffic inbound from AS 100 so that traffic to VLAN 3 goes one route and traffic to VLAN 33 goes another.  If either link fails, use the other as a backup.  Make sure that a third link is not used at all.

Well we’re tasked with affecting inbound traffic by configuring AS 200.  We have two primary options to do this: AS-Path or MED.  Since we are affecting all traffic and AS 200 is the destination AS,  MED is the easier method to use.  We will need to change the MED on two of the three AS border routers and then either crank up the MED to an impossibly high value or just filter the routes (my preference) on the third.

First we need to create prefix-lists for the two VLANs:

Rack16SW1(config)#ip prefix-list VLAN33 permit 129.16.3.128/25
Rack16SW1(config)#ip prefix-list VLAN3 permit 129.16.3.0/25

Then match those prefixes in a route-map and set the metric value accordingly.  In the case of sw1 we want traffic destined for VLAN 3 to prefer this link:

sw1:

Rack16SW1(config)#route-map OUT_TO_SW2
Rack16SW1(config-route-map)#match ip add pre VLAN3
Rack16SW1(config-route-map)#set metric ?
  +/-<metric>     Add or subtract metric
  <0-4294967295>  Metric value or Bandwidth in Kbits per second
  <cr>

Remember that MED = metric and that the LOWER the value, the more preferred that route is.

Rack16SW1(config-route-map)#set metric 1

Now let’s make sure that VLAN33 traffic has a higher (therefore less preferred) MED:

Rack16SW1(config-route-map)#route-map OUT_TO_SW2 permit 20
Rack16SW1(config-route-map)#match ip add VLAN33
Rack16SW1(config-route-map)#set metric 666

Finally, do NOT forget to add an ‘explicit permit’ statement for the rest of the traffic:

Rack16SW1(config-route-map)#route-map OUT_TO_SW2 permit 1000

Our route-map now looks like this:

route-map OUT_TO_SW2 permit 10
 match ip address prefix-list VLAN3
 set metric 1
!
route-map OUT_TO_SW2 permit 20
 match ip address VLAN33
 set metric 666
!
route-map OUT_TO_SW2 permit 1000

We can configure r1 the same way, but just flip the metric values so the VLAN 33 is prefered.

Finally we just need to add the route-map to the neighbor statement:

Rack16SW1(config-route-map)#router bgp 200
Rack16SW1(config-router)#nei 129.16.78.8 route-map OUT_TO_SW2 out

Next we need to make meet the last requirement:

“The Frame Relay circuit between r2 and r4 should not be used as a transit path for either of these destinations.”

We just need to make sure that these two VLANs are not advertised out this link:

Rack16R2(config)#ip prefix-list VLAN33 permit 129.16.3.128/25
Rack16R2(config)#ip prefix-list VLAN3 permit 129.16.3.0/25
Rack16R2(config)#route-map OUT_TO_R4 deny 10
Rack16R2(config-route-map)#match ip add pre VLAN33
Rack16R2(config-route-map)#route-map OUT_TO_R4 deny 20
Rack16R2(config-route-map)#match ip add pre VLAN3
Rack16R2(config-route-map)#route-map OUT_TO_R4 permit 1000
Rack16R2(config-route-map)#router bgp 200
Rack16R2(config-router)#neigh 129.16.124.4 route-map OUT_TO_R4 out

The IE solution guide got fancy with a prefix list that matched both networks with a single line:

ip prefix-list VLANS_3_33 seq 5 permit 129.16.3.0/24 ge 25 le 25

Good to know and understand, but not required for this task.

Verification:

Rack16R6#trace 129.16.3.3

Type escape sequence to abort.
Tracing the route to 129.16.3.3

  1 129.16.46.4 4 msec 0 msec 0 msec
  2 129.16.45.5 4 msec 4 msec 0 msec
  3 129.16.58.8 4 msec 4 msec 4 msec <-sw2
  4 129.16.78.7 0 msec 4 msec 4 msec <-sw1

  5 129.16.17.1 [AS 200] 20 msec 20 msec 20 msec
  6 129.16.13.3 36 msec *  32 msec

Rack16R6#trace 129.16.3.133

Type escape sequence to abort.
Tracing the route to 129.16.3.133

  1 129.16.46.4 0 msec 4 msec 4 msec
  2 129.16.124.1 28 msec 32 msec 28 msec <-FR link between r1 and r4
  3 129.16.13.3 44 msec *  40 msec

Note that the route via r2 is not available:

Rack16R4#sh ip bgp 129.16.3.0 255.255.255.128
BGP routing table entry for 129.16.3.0/25, version 29
Paths: (2 available, best #1, table Default-IP-Routing-Table)
Flag: 0x4940
  Advertised to update-groups:
     2          3
  200
    129.16.58.8 (metric 2) from 150.16.5.5 (150.16.5.5)
      Origin IGP, metric 1, localpref 100, valid, internal, best
      Originator: 150.16.8.8, Cluster list: 150.16.5.5
  200
    129.16.124.1 from 129.16.124.1 (150.16.1.1)
      Origin IGP, metric 666, localpref 100, valid, external

5.5 BGP Filtering

Configure AS 200 to only route traffic destined for AS 254 (BB2) over the Frame Relay link between r2 and r4.  Do not allow traffic destined for AS 254 from AS 100 to route out any other connections even if the Frame Relay link between r2 and r4 is down.

This means that we need to filter all routes to destinations that have AS 254 in the AS-Path from using r1 and sw1 to enter AS 100.

Since we’re tasked with doing this in AS 100 AND we only want the traffic to AS 254 to use one link regardless of the state of that link, we just need to filter any advertisements with AS 254 in the path outbound on r1 and sw1.

First we need an AS-Path statement matching traffic with AS 254 in the path.  We need to match any AS-Path that contains an instance of ‘254’:

Rack16R1(config)#ip as-path access-list 55 permit _254_

Now we need to filter any prefixes that match that AS-Path in a route-map.  We already have an outbound route-map set up for r4:

route-map OUT_TO_R4 permit 10
 match ip address prefix-list VLAN3
 set metric 666
route-map OUT_TO_R4 permit 20
 match ip address VLAN33
 set metric 1
route-map OUT_TO_R4 permit 1000

So let’s just add our deny statement at the beginning of that existing route-map:

Rack16R1(config)#route-map OUT_TO_R4 deny 5
Rack16R1(config-route-map)#match as-path 55

Do the same on sw1:

Rack16SW1(config)#ip as-path access-list 55 permit _254_
Rack16SW1(config)#route-map OUT_TO_SW2 deny 5
Rack16SW1(config-route-map)#match as-path 55

SW2 now routes though r4 rather than sw1 (directly connected):

Rack16SW2#sh ip bgp reg _254_
BGP table version is 53, local router ID is 150.16.8.8
Status codes: s suppressed, d damped, h history, * valid, > best, i – internal,
              r RIB-failure, S Stale
Origin codes: i – IGP, e – EGP, ? – incomplete

   Network          Next Hop            Metric LocPrf Weight Path
*>i205.90.31.0      150.16.4.4               0    100      0 200 254 ?
*>i220.20.3.0       150.16.4.4               0    100      0 200 254 ?
*>i222.22.2.0       150.16.4.4               0    100      0 200 254 ?

Rack16SW2#trace 222.22.2.1

Type escape sequence to abort.
Tracing the route to 222.22.2.1

  1 129.16.58.5 0 msec 8 msec 0 msec
  2 129.16.45.4 0 msec 0 msec 0 msec
  3 129.16.124.2 34 msec 25 msec 33 msec <-FR link from r4 to r2
  4 192.10.16.254 34 msec *  25 msec

R4 only has these routes via the Frame Relay connection to r2:

Rack16R4#sh ip bgp reg _254_
BGP table version is 34, local router ID is 150.16.4.4
Status codes: s suppressed, d damped, h history, * valid, > best, i – internal,
              r RIB-failure, S Stale
Origin codes: i – IGP, e – EGP, ? – incomplete

   Network          Next Hop            Metric LocPrf Weight Path
*> 205.90.31.0      129.16.124.2                           0 200 254 ?
*> 220.20.3.0       129.16.124.2                           0 200 254 ?
*> 222.22.2.0       129.16.124.2                           0 200 254 ?

And of course after all of that….IE uses a different AS-Path statement:

ip as-path access-list 1 permit ^254$

I’m a little confused on this.  This matches any paths where AS 254 is the first AS in the path.  Both solutions provide the same results, but mine does not assume that there will always be only one exit path to AS 254.  I say tomato, IE says tomato.

5.6 BGP Default Routing

Just read the last few lines of this task as the rest may confuse you (as it did me).  You need to configure As 100 do advertise a default route into AS 200 but “send AS 200 a full view along with a default out each BGP connection.”

Well, don’t bite and go for this option:

default-information originate (BGP)

We need to advertise it to our neighbors in AS 200 and we need to include the more specific routes so we want:

neighbor default-originate

Before:

Rack16SW1#sh ip bgp neigh 129.16.78.8 route | b Net
   Network          Next Hop            Metric LocPrf Weight Path
*> 28.119.16.0/24   129.16.78.8                            0 100 54 i
*> 28.119.17.0/24   129.16.78.8                            0 100 54 i
*> 112.0.0.0        129.16.78.8                            0 100 54 50 60 i
*> 113.0.0.0        129.16.78.8                            0 100 54 50 60 i
*> 114.0.0.0        129.16.78.8                            0 100 54 i
*> 115.0.0.0        129.16.78.8                            0 100 54 i
*> 116.0.0.0        129.16.78.8                            0 100 54 i
*> 117.0.0.0        129.16.78.8                            0 100 54 i
*> 118.0.0.0        129.16.78.8                            0 100 54 i
*> 119.0.0.0        129.16.78.8                            0 100 54 i
*> 129.16.45.0/29   129.16.78.8                            0 100 i
*> 129.16.46.0/24   129.16.78.8                            0 100 i
*> 129.16.58.0/24   129.16.78.8              0             0 100 i

Total number of prefixes 13

Rack16SW2(config)#router bgp 100
Rack16SW2(config-router)#neigh 129.16.78.7 default-originate

After:

Rack16SW1#sh ip bgp neigh 129.16.78.8 route | b Net
   Network          Next Hop            Metric LocPrf Weight Path
*> 0.0.0.0          129.16.78.8                            0 100 i
*> 28.119.16.0/24   129.16.78.8                            0 100 54 i
*> 28.119.17.0/24   129.16.78.8                            0 100 54 i
*> 112.0.0.0        129.16.78.8                            0 100 54 50 60 i
*> 113.0.0.0        129.16.78.8                            0 100 54 50 60 i
*> 114.0.0.0        129.16.78.8                            0 100 54 i
*> 115.0.0.0        129.16.78.8                            0 100 54 i
*> 116.0.0.0        129.16.78.8                            0 100 54 i
*> 117.0.0.0        129.16.78.8                            0 100 54 i
*> 118.0.0.0        129.16.78.8                            0 100 54 i
*> 119.0.0.0        129.16.78.8                            0 100 54 i
*> 129.16.45.0/29   129.16.78.8                            0 100 i
*> 129.16.46.0/24   129.16.78.8                            0 100 i
*> 129.16.58.0/24   129.16.78.8              0             0 100 i

Total number of prefixes 14

5.7 BGP Default Routing

Configure sw1 so that the only prefix that it sees from AS 100 is the default route.

“Additionally, ensure that sw1 is the most preferred exit point out of AS 200 for a prefix that no other device in AS 100 has a longer match for.”

Okay…so we need to filter all routes from sw2(AS 100) except for the default route. We also need to make sure that AS 200 prefers our default route over the ones advertised to r1 and r2.

First things first.  Let’s write a prefix-list to match the default route:

Rack16SW1(config)#ip prefix-list DEFAULT permit 0.0.0.0/0

Now let’s filter everything except this route from sw2:

Rack16SW1(config)#route-map IN_FROM_SW2
Rack16SW1(config-route-map)#match ip add pre DEFAULT

We might as well address our last requirement at this point.  We need to affect outbound traffic from AS 200 to prefer this default route.  We have a choice of Weight or Local Preference to do this.  Since we are limited to configuring sw1 and we need to affect all of AS 200 only we need to use local_pref.  We just need to set the local-preference for this default route to a high value (higher than the default of 100 at least):

Rack16SW1(config-route-map)#set local-preference 666666

Now we just need to apply this route map inbound from sw2:

Rack16SW1(config-route-map)#router bgp 200
Rack16SW1(config-router)#neighbor 129.16.78.8 route-map IN_FROM_SW2 in

Verify:

Rack16SW1#sh ip bgp neigh 129.16.78.8 route | b Net
   Network          Next Hop            Metric LocPrf Weight Path
*> 0.0.0.0          129.16.78.8                            0 100 i

R1 prefers the default route to sw1 over the default route it learns from EBGP peer r4 and iBGP peer r2:

Rack16R1#sh ip bgp 0.0.0.0
BGP routing table entry for 0.0.0.0/0, version 36
Paths: (2 available, best #2, table Default-IP-Routing-Table)
Flag: 0x840
  Advertised to update-groups:
     1          3
  100
    129.16.124.4 from 129.16.124.4 (150.16.4.4)
      Origin IGP, metric 0, localpref 100, valid, external
  100, (Received from a RR-client)
    129.16.17.7 from 129.16.17.7 (150.16.7.7)
      Origin IGP, metric 0, localpref 666666, valid, internal, best

5.8 BGP Bestpath Selection

Configure AS 200 so that it will only send traffic out the Frame Relay circuit between r2 and r4 that is destined for AS 100 and it’s directly connected customers.

“Configure this filtering in such a way that it can account for an arbitrary amount of new customers that may be connected to AS 100 int the future.”

All of this means that we need to write as AS-Path statement that will match paths that start with AS 100 and can have exactly one more AS in the path.  Ugh.

Well we know that we need to match for ^100 and x$.  This is where it helps to know where to find the documentation for regular expressions.

Here’s what I came up with:

ip as-path access-list ^100_[0-9]*_$

This seemed to work:

Rack16SW1#sh ip bgp reg ^100_[0-9]*_$
BGP table version is 39, local router ID is 150.16.7.7
Status codes: s suppressed, d damped, h history, * valid, > best, i – internal,
              r RIB-failure, S Stale
Origin codes: i – IGP, e – EGP, ? – incomplete

   Network          Next Hop            Metric LocPrf Weight Path
*> 0.0.0.0          129.16.78.8                666666      0 100 i
*>i28.119.16.0/24   129.16.17.1              0    100      0 100 54 i
*>i28.119.17.0/24   129.16.17.1              0    100      0 100 54 i
*>i114.0.0.0        129.16.17.1              0    100      0 100 54 i
*>i115.0.0.0        129.16.17.1              0    100      0 100 54 i
*>i116.0.0.0        129.16.17.1              0    100      0 100 54 i
*>i117.0.0.0        129.16.17.1              0    100      0 100 54 i
*>i118.0.0.0        129.16.17.1              0    100      0 100 54 i
*>i119.0.0.0        129.16.17.1              0    100      0 100 54 i
*>i129.16.45.0/29   129.16.17.1              0    100      0 100 i
*>i129.16.46.0/24   129.16.17.1              0    100      0 100 i
*>i129.16.58.0/24   129.16.17.1              0    100      0 100 i

IE came up with ^100(_[0-9]+)?$

Rack16SW1#sh ip bgp reg ^100(_[0-9]+)$
BGP table version is 39, local router ID is 150.16.7.7
Status codes: s suppressed, d damped, h history, * valid, > best, i – internal,
              r RIB-failure, S Stale
Origin codes: i – IGP, e – EGP, ? – incomplete

   Network          Next Hop            Metric LocPrf Weight Path
*>i28.119.16.0/24   129.16.17.1              0    100      0 100 54 i
*>i28.119.17.0/24   129.16.17.1              0    100      0 100 54 i
*>i114.0.0.0        129.16.17.1              0    100      0 100 54 i
*>i115.0.0.0        129.16.17.1              0    100      0 100 54 i
*>i116.0.0.0        129.16.17.1              0    100      0 100 54 i
*>i117.0.0.0        129.16.17.1              0    100      0 100 54 i
*>i118.0.0.0        129.16.17.1              0    100      0 100 54 i
*>i119.0.0.0        129.16.17.1              0    100      0 100 54 i

I guess that I read the requirements wrong as I thought that we needed to include traffic destined for AS 100 AND AS 100 plus one more AS.

DOH!!!  Those of you with a keen eye will see where I fucked up.  I pasted in the IE regular expression.  If you look at my command you’ll notice that the question mark is missing.  You need to use ‘control+v’ to insert a question mark.  Here’s what the output should look like:

Rack16SW1#sh ip bgp reg ^100(_[0-9]+)?$
BGP table version is 39, local router ID is 150.16.7.7
Status codes: s suppressed, d damped, h history, * valid, > best, i – internal,
              r RIB-failure, S Stale
Origin codes: i – IGP, e – EGP, ? – incomplete

   Network          Next Hop            Metric LocPrf Weight Path
*> 0.0.0.0          129.16.78.8                666666      0 100 i
*>i28.119.16.0/24   129.16.17.1              0    100      0 100 54 i
*>i28.119.17.0/24   129.16.17.1              0    100      0 100 54 i
*>i114.0.0.0        129.16.17.1              0    100      0 100 54 i
*>i115.0.0.0        129.16.17.1              0    100      0 100 54 i
*>i116.0.0.0        129.16.17.1              0    100      0 100 54 i
*>i117.0.0.0        129.16.17.1              0    100      0 100 54 i
*>i118.0.0.0        129.16.17.1              0    100      0 100 54 i
*>i119.0.0.0        129.16.17.1              0    100      0 100 54 i
*>i129.16.45.0/29   129.16.17.1              0    100      0 100 i
*>i129.16.46.0/24   129.16.17.1              0    100      0 100 i
*>i129.16.58.0/24   129.16.17.1              0    100      0 100 i

There’s a nice breakdown on how they came up with this regular expression.

We just need to use a filter-list inbound on r2 to make the magic happen:

Rack16R2(config)#ip as-path access-list 58 perm ^100(_[0-9]+)$
Rack16R2(config)#router bgp 200
Rack16R2(config-router)#neigh 129.16.124.4 filter-list 58 in

“This link should still be able to be used to send traffic out to AS 100 if there are no longer matches throughout the BGP domain, but should only be preferred as a default exit point if sw1’s connection to AS 100 is down.”

All this is saying is that we should leave the default route to AS 100 alone (we already configured the AS 200 to prefer the default route to sw2).

5.9 BGP Bestpath Selection

At this point I was sick to death of BGP.  Only two more tasks to go:

I had a hell of a time deciphering this mess.  I think that we just need to make sure that the default route that r1 is learning from r4 is only used if the link between sw1 and sw2 as well as the link between r2 and r4 are down.  This seems like it should be as simple as setting the local-preference on the default to be less than those two links.  sw1-sw2 has a local-preference of 666666 and r2-r4 has the default of 100, so we just need to configure the default on r1 to a value less than 100.

Rack16R1(config)#ip prefix-list DEFAULT perm 0.0.0.0/0
Rack16R1(config)#route-map IN_FROM_R4
Rack16R1(config-route-map)#match ip add DEFAULT
Rack16R1(config-route-map)#set local 50
Rack16R1(config-route-map)#route-map IN_FROM_R4 perm 1000
Rack16R1(config-route-map)#router bgp 200
Rack16R1(config-router)#neigh 129.16.124.4 route-map IN_FROM_R4 in

This is similar to task 5.7 except that we want to allow in all of the routes, not just the default route.  That’s why we need to add the ‘explicit permit’ line in the route-map.

5.10 BGP Aggregation

Last BGP task!!!

Configure BGP summaries to the three BB routers, but don’t let any of your devices see these summaries.

Since there are no loopback prefixes currently advertised into BGP, we need to advertise those in:

Rack16R2(config-router)#net 150.16.0.0 mask 255.255.0.0

There’s no requirement about “no overlapping address space” so let’s just advertise a /16 for the devices and another for the loopbacks.  Should we use ‘summary-only’?  I’m not sure:

Rack16R2(config-router)#aggregate-address 150.16.0.0 255.255.0.0
Rack16R2(config-router)#aggregate-address 129.16.0.0 255.255.0.0

Now we need to set up filtering so that our other BGP peers do not see these summaries.  First write prefix-lists to match the summaries:

Rack16R2(config)#ip prefix-list INTERNAL permit 150.16.0.0/24
Rack16R2(config)#ip prefix-list INTERNAL seq 10  permit 129.16.0.0/24

Now write a route-map (r2 will be a special case as there is already an existing route-map outbound to r4 – just add a deny statement to that map):

Rack16R2(config)#route-map FILTER_AGGREGATE deny 10
Rack16R2(config-route-map)#match ip add INTERNAL
Rack16R2(config-route-map)#route-map FILTER_AGGREGATE permit 1000

On r2:

Rack16R2(config)#route-map OUT_TO_R4 deny 30
Rack16R2(config-route-map)#match ip add INTERNAL

Finally just add the route-map to a neighbor statement outbound for each peer (other than the BB):

Rack16R2(config-router)#neighbor 129.16.23.3 route-map FILTER_AGGREGATE out

I’ll have to review how to advertise a summary in BGP.  I thought that the network needed to be in the BGP table before you could advertise it as an aggregate.  Obviously, this in not the case:

IE method (sans loopback advertisement):

Rack16R6#sh ip bgp neigh 54.16.1.254 adv | b Net
   Network          Next Hop            Metric LocPrf Weight Path
*> 129.16.0.0       0.0.0.0                            32768 i
*>i129.16.3.0/25    129.16.58.8              1    100      0 200 i
*>i129.16.3.128/25  129.16.46.4              1    100      0 200 i
*>i129.16.17.0/24   129.16.46.4              1    100      0 200 i
r>i129.16.45.0/29   129.16.46.4              0    100      0 i
r>i129.16.46.0/24   129.16.46.4              0    100      0 i
r>i129.16.58.0/24   129.16.58.8              0    100      0 i

Total number of prefixes 7

My method:

Rack16R6#sh ip bgp neigh 54.16.1.254 adv | b Net
   Network          Next Hop            Metric LocPrf Weight Path
*> 129.16.0.0       0.0.0.0                            32768 i
*>i129.16.3.0/25    129.16.58.8              1    100      0 200 i
*>i129.16.3.128/25  129.16.46.4              1    100      0 200 i
*>i129.16.17.0/24   129.16.46.4              1    100      0 200 i
r>i129.16.45.0/29   129.16.46.4              0    100      0 i
r>i129.16.46.0/24   129.16.46.4              0    100      0 i
r>i129.16.58.0/24   129.16.58.8              0    100      0 i

Total number of prefixes 7

I’m also not sure why the 150.16.0.0/16 summary is not being advertised to this backbone router.  Oh well.  Too much BGP. 

I’ll revisit this later.

Advertisements

Internetwork Expert Volume II: Lab 12 – Section 6

Section 6 – IP Multicast – 8 Points

6.1 PIM

I doesn’t get any easier than this.  You’re asked to configure dense mode on specific interfaces.

6.2 Multicast Distribution

Users in VLAN 22 want access to a video feed on 225.25.25.25 (using UDP port 31337) from VLAN 17. For some reason (most likely because PIM is not configured on r3’s s1/3 🙂  ) r3 is not passing this traffic to r2.  Configure the network so that the users can receive traffic from this group.

“Do not enable PIM on any additional interfaces to accomplish this.”

Fuck.  There goes the easy solution.

This has me stumped.  The multicast path from VLAN 17 to VLAN 12 is broken at r3. Is there a way to change this traffic to unicast or broadcast traffic?  Yup.  🙂

ip multicast helper-map

To allow IP multicast routing in a multicast-capable internetwork between two broadcast-only internetworks, use the ip multicast helper-map command in interface configuration mode.

Configuring an Intermediate IP Multicast Helper Between Broadcast-Only Networks

r3:

Rack16R3(config)#ip access-list ex TASK_6_2
Rack16R3(config-ext-nacl)#permit udp any any eq 31337
Rack16R3(config)#ip forward-protocol udp 31337

Rack16R3(config)#int s1/3
Rack16R3(config-if)#ip directed-broadcast

Rack16R3(config)int s1/2
Rack16R3(config-if)ip multicast helper-map 225.25.25.25 129.16.23.255 TASK_6_2

r2:

Rack16R2(config)#ip forward-protocol udp 31337
Rack16R2(config)#ip access-list ex TASK_6_2
Rack16R2(config-ext-nacl)#permit udp any any eq 31337

Rack16R2(config-ext-nacl)#int s0/1
Rack16R2(config-if)#ip multicast helper-map broadcast 225.25.25.25 TASK_6_2

There are a lot of verification commands in the solution guide, but nothing as far a breakdown.

6.3 Static RP

Well you didn’t think that we were going to get away with just running dense-mode on three devices did you?  This task has you set up a pim-spare multicast network in the OSPF half of the network.

The weird bit is that we have to create loopback 1 on r4 and r5 and then give them the same address and advertise them into OSPF.

Then we need to configure r6 to use r4’s loopback 1 as the RP and sw2 to use r5’s loopback 1 as the RP.  If either should fail, then they should switch over to the other loopback 1 as the RP.  Remember, these loopbacks have the same /32 address.

Enter a command I’ve never heard of before”

ip msdp peer

To configure a Multicast Source Discovery Protocol (MSDP) peer, use the ip msdp peer command in global configuration mode.

Rack16R5(config)#ip msdp peer 150.16.4.4 connect-source lo0
Rack16R4(config)#ip msdp peer 150.16.5.5 connect-source lo0

Aug 12 14:05:14.346: %MSDP-5-PEER_UPDOWN: Session to peer 150.16.5.5 going up

After that bit is configured, just statically map your RP’s on r6 and sw2:

Rack16R6(config)#ip pim rp-address 150.16.0.255
Rack16SW2(config)#ip pim rp-address 150.16.0.255

Rack16R4#sh ip msdp peer
MSDP Peer 150.16.5.5 (?), AS 100
  Connection status:
    State: Up, Resets: 0, Connection source: Loopback0 (150.16.4.4)
    Uptime(Downtime): 00:00:37, Messages sent/received: 0/1
    Output messages discarded: 0
    Connection and counters cleared 00:00:37 ago
  SA Filtering:
    Input (S,G) filter: none, route-map: none
    Input RP filter: none, route-map: none
    Output (S,G) filter: none, route-map: none
    Output RP filter: none, route-map: none
  SA-Requests:
    Input filter: none
  Peer ttl threshold: 0
  SAs learned from this peer: 0
  Input queue size: 0, Output queue size: 0

Rack16R4#sh ip msdp summary
MSDP Peer Status Summary
Peer Address     AS    State    Uptime/  Reset SA    Peer Name
                                Downtime Count Count
150.16.5.5       100   Up       00:01:05 0     0     ?

Rack16R6#sh ip pim rp map
PIM Group-to-RP Mappings

Group(s): 224.0.0.0/4, Static
    RP: 150.16.0.255 (?)

Rack16SW2#sh ip pim rp mapp
PIM Group-to-RP Mappings

Group(s): 224.0.0.0/4, Static
    RP: 150.16.0.255 (?)

August 13, 2008

Internetwork Expert Volume II: Lab 12 – Section 7

Section 7 – IPv6 – 16 Points

7.1 IPv6 Addressing

Very basic IPv6 addressing task.  The only confusing bit:

“Use the address 2001:CC1E:X:3::Y/64 for r3’s Ethernet interface.”

Ummm…r3 has TWO Ethernet interfaces?  Which one do they mean?  It turns out that they only mean e0/0 (VLAN3).

7.2 IPv6 over Frame Relay

This is a basic IPv6 Frame Relay hub-and-spoke task.  They even go so far as to tell you what to use for the link-local addresses.  I always read ahead in the IPv6 section to see if we will be running an IPv6 IGP over the Frame Relay network.  In this case task 7.4 will require exactly that.  SO….if there are no requirements against it, I hardset the link-local addresses to Fe80::Y (where Y is the router number) AND I go ahead and create frame maps for the link-local addresses.  It’s not required in this task, but we might as well do it now.

R1 (spoke) before:

Rack16R1(config-if)#do sh run int s0/0 | i face|add|rame
interface Serial0/0
 ip address 129.16.124.1 255.255.255.0
 encapsulation frame-relay
 frame-relay map ip 129.16.124.2 104
 frame-relay map ip 129.16.124.4 104 broadcast
 no frame-relay inverse-arp

R1 after:

Rack16R1(config-if)#do sh run int s0/0 | i face|add|rame
interface Serial0/0
 ip address 129.16.124.1 255.255.255.0
 encapsulation frame-relay
 ipv6 address 2001:CC1E:16:124::1/64
 ipv6 address FE80::1 link-local
 frame-relay map ipv6 FE80::2 104
 frame-relay map ipv6 FE80::4 104
 frame-relay map ipv6 2001:CC1E:16:124::2 104
 frame-relay map ipv6 2001:CC1E:16:124::4 104 broadcast
 frame-relay map ip 129.16.124.2 104
 frame-relay map ip 129.16.124.4 104 broadcast
 no frame-relay inverse-arp

7.3 RIPng

This is a simple RIPng task.

“Configure r2 so that RIPng routes learned from BB2 with a mask longer than /64 will not be passed on to r3.”

Here are the RIPng routes that we’re receiving from BB2:

Rack16R2#sh ipv6 route rip
IPv6 Routing Table – 12 entries
Codes: C – Connected, L – Local, S – Static, R – RIP, B – BGP
       U – Per-user Static route
       I1 – ISIS L1, I2 – ISIS L2, IA – ISIS interarea, IS – ISIS summary
       O – OSPF intra, OI – OSPF inter, OE1 – OSPF ext 1, OE2 – OSPF ext 2
       ON1 – OSPF NSSA ext 1, ON2 – OSPF NSSA ext 2
R   2001:205:90:31::/64 [120/2]
     via FE80::200:CFF:FE4A:689C, FastEthernet0/0
R   2001:220:20:3::/64 [120/2]
     via FE80::200:CFF:FE4A:689C, FastEthernet0/0
R   2001:222:22:2::/64 [120/2]
     via FE80::200:CFF:FE4A:689C, FastEthernet0/0

R   2001:CC1E:16:3::/64 [120/2]
     via FE80::206:D7FF:FEBD:1741, Serial0/1

We need to filter some routes.  Our old filtering friends from RIPv1/2 are still available although the offset-list has been moved to the interface level and renamed:

Rack16R2(config)#ipv6 router rip RIPng
Rack16R2(config-rtr)#?
  distance         Administrative distance
  distribute-list  Filter networks in routing updates

Rack16R2(config-if)#ipv6 rip RIPng ?
  metric-offset        Adjust default metric increment

Well…the metric-offset is not quite as flexible as the old skool offset-list because you can’t specify the routes to offset.  It’s an “all or nothing” solution:

Rack16R2(config-if)#ipv rip RIPng metric-offset 16 ?
  <cr>

ipv6 rip metric-offset

Let’s use a distribute list instead:

distribute-list prefix-list (IPv6 RIP)

The first thing that we need to do is write an IPv6 prefix-list to match any IPv6 routes that are /64 or less:

Rack16R2(config)#ipv6 prefix-list TASK_7_2 perm 0::0/0 le 64

Then apply the distribute-list under the RIPng process:

Rack16R2(config)#ipv6 router rip RIPng
Rack16R2(config-rtr)#distribute-list prefix-list TASK_7_2 out s0/1

Since we don’t have any routes greater than /64 coming from BB2, there is really no good way to validate this.  BUT make sure that the this doesn’t break your IPv6 routing by making sure that the RIPng routes from BB2 are getting to r3:

Rack16R3#sh ipv route rip
IPv6 Routing Table – 10 entries
Codes: C – Connected, L – Local, S – Static, R – RIP, B – BGP
       U – Per-user Static route
       I1 – ISIS L1, I2 – ISIS L2, IA – ISIS interarea, IS – ISIS summary
       O – OSPF intra, OI – OSPF inter, OE1 – OSPF ext 1, OE2 – OSPF ext 2
       ON1 – OSPF NSSA ext 1, ON2 – OSPF NSSA ext 2
R   2001:192:10:16::/64 [120/2]
     via FE80::211:92FF:FE17:C860, Serial1/3
R   2001:205:90:31::/64 [120/3]
     via FE80::211:92FF:FE17:C860, Serial1/3
R   2001:220:20:3::/64 [120/3]
     via FE80::211:92FF:FE17:C860, Serial1/3
R   2001:222:22:2::/64 [120/3]
     via FE80::211:92FF:FE17:C860, Serial1/3

7.4 OSPFv3

OSPFv3 is enabled under the interface as well:

Rack16R2(config)#int s0/0
Rack16R2(config-if)#ipv os 666 area 0

If you did not create frame maps for the link-local addresses then you will need to do this now (IPv6 IGPs use the link-local address for next-hop processing).

We need to get our neighbor adjacencies up, but we’re not allowed to change the default OSPF type.  This means we need neighbor statements on the hub (and priority 0 statements on the spokes).  The only deviation form the OSPFv2 process is that this is done under the interface:

Rack16R4(config-rtr)#int s0/0.124
Rack16R4(config-subif)#ipv6 ospf ?
  <1-65535>            Process ID
  authentication       Enable authentication
  cost                 Interface cost
  database-filter      Filter OSPF LSA during synchronization and flooding
  dead-interval        Interval after which a neighbor is declared dead
  demand-circuit       OSPF demand circuit
  flood-reduction      OSPF Flood Reduction
  hello-interval       Time between HELLO packets
  mtu-ignore           Ignores the MTU in DBD packets
  neighbor             OSPF neighbor
  network              Network type
  priority             Router priority
  retransmit-interval  Time between retransmitting lost link state
                       advertisements
  transmit-delay       Link state transmit delay

Rack16R4(config-subif)#ipv6 ospf neigh 2001:CC1E:16:124::2
OSPFv3: Neighbor address needs to be a link-local address

Doh!

Rack16R4(config-subif)#ipv6 ospf neigh FE80::2
Rack16R4(config-subif)#ipv6 ospf neigh FE80::1

Rack16R4#sh ipv os neigh

Neighbor ID     Pri   State           Dead Time   Interface ID    Interface
150.16.1.1        0   FULL/DROTHER    00:01:42    5               Serial0/0.124
150.16.2.2        0   FULL/DROTHER    00:01:32    5               Serial0/0.124

7.5 OSPv3

Create two new OSPFv3 areas and:

“r6 should see only one router for both the Frame Relay segment and VLAN 17 of r1.”

Here’s what we see on r6 right now:

Rack16R6#sh ipv route os
IPv6 Routing Table – 6 entries
Codes: C – Connected, L – Local, S – Static, R – RIP, B – BGP
       U – Per-user Static route
       I1 – ISIS L1, I2 – ISIS L2, IA – ISIS interarea, IS – ISIS summary
       O – OSPF intra, OI – OSPF inter, OE1 – OSPF ext 1, OE2 – OSPF ext 2
       ON1 – OSPF NSSA ext 1, ON2 – OSPF NSSA ext 2
OI  2001:CC1E:16:1::/64 [110/66]
     via FE80::207:EFF:FE9C:F4C2, FastEthernet0/0
OI  2001:CC1E:16:124::/64 [110/65]
     via FE80::207:EFF:FE9C:F4C2, FastEthernet0/0

So…is the task asking us to summarize these two routes or is it asking for a single default route?  I would ask the proctor on this one.

Since making this a totally-stubby area is the easier solution, that’s the one I chose.  🙂  IE also went this route.

Rack16R4(config-if)#ipv6 router ospf 666
Rack16R4(config-rtr)#area 2 stub no-summ

Rack16R6(config)#ipv6 router ospf 666
Rack16R6(config-rtr)#area 2 stub

Rack16R6#sh ipv route os
IPv6 Routing Table – 5 entries
Codes: C – Connected, L – Local, S – Static, R – RIP, B – BGP
       U – Per-user Static route
       I1 – ISIS L1, I2 – ISIS L2, IA – ISIS interarea, IS – ISIS summary
       O – OSPF intra, OI – OSPF inter, OE1 – OSPF ext 1, OE2 – OSPF ext 2
       ON1 – OSPF NSSA ext 1, ON2 – OSPF NSSA ext 2
OI  ::/0 [110/2]
     via FE80::207:EFF:FE9C:F4C2, FastEthernet0/0

7.6 IPv6 Redistribution

Oh fun.  🙂  At least there are only two IPv6 protocols and one point of redistribution (r2).

I tried to build a TCL script and quickly found out that there is no ‘show ipv6 alias” command.  😦  I just did a “show ipv6 int brief” and copied the addresses:

foreach x {
2001:CC1E:16:1::1
2001:CC1E:16:124::1
2001:CC1E:16:3::3
2001:CC1E:16:23::3
2001:192:10:16::2
2001:CC1E:16:124::2
2001:CC1E:16:23::2
2001:CC1E:16:124::4
2001:CC1E:16:46::4
2001:CC1E:16:46::6
2001:222:22:2::1} {ping $x re 2}

The redistribution is pretty straight-forward except I couldn’t decide if I needed “include-connected” as well.  I voted “no” – which ended up being a mistake.   I need to review IPv6 redistribution to find out why.

Rack16R2(config-rtr)#ipv6 router ospf 666
Rack16R2(config-rtr)#redistribute rip RIPng include-conn

Rack16R2(config-rtr)#ipv6 router rip RIPng
Rack16R2(config-rtr)#redist ospf 666 metric 1 include-conn

Rack16R1#sh ipv route os
IPv6 Routing Table – 13 entries
Codes: C – Connected, L – Local, S – Static, R – RIP, B – BGP
       U – Per-user Static route
       I1 – ISIS L1, I2 – ISIS L2, IA – ISIS interarea, IS – ISIS summary
       O – OSPF intra, OI – OSPF inter, OE1 – OSPF ext 1, OE2 – OSPF ext 2
       ON1 – OSPF NSSA ext 1, ON2 – OSPF NSSA ext 2
OE2  2001:192:10:16::/64 [110/20]
     via FE80::2, Serial0/0
OE2  2001:205:90:31::/64 [110/20]
     via FE80::2, Serial0/0
OE2  2001:220:20:3::/64 [110/20]
     via FE80::2, Serial0/0
OE2  2001:222:22:2::/64 [110/20]
     via FE80::2, Serial0/0
OE2  2001:CC1E:16:3::/64 [110/20]
     via FE80::2, Serial0/0
OE2  2001:CC1E:16:23::/64 [110/20]
     via FE80::2, Serial0/0

OI  2001:CC1E:16:46::/64 [110/74]
     via FE80::4, Serial0/0

Internetwork Expert Volume II: Lab 12 – Section 8

Section 8 – QoS – 6 Points

8.1 Frame Relay Traffic Shaping

Oooh.  A VoIP issue with an interface running at less than 768K.  Time for some packet interleaving.  🙂

The task tells us that r2 and r4 have been provisioned at 512K and that we should “ensure that neither of these devices send traffic beyond this rate on this circuit.”

We also have this requirement:

“Additional VCs on r4 (DLCIs 401 and 405) should equally share the remaining bandwidth of its T1 interface to the Frame Relay cloud.”

Okay.  That bit confused me.  Basically we need to split the the remaining bandwidth (1544 – 512)/2.  In the end we’re assigning a CIR of 512 to each of the three circuits on int s0/0 of r4.

It’s the last requirement that gives us the most “actionable information”:

“In order to allow VoIP traffic to be interleaved between larger data converstions ensure that the maximum time that it takes to transmit a packet across the Frame Relay network is 10ms.”

All of that just basically means that we need to use a Tc of 10ms.

We aren’t asked to allow a burst, so we can set Be to 0.  Bc can be determined by the following formula:

Bc =  CIR * (Tc/1000)
Bc = 512000 * (10/1000)
Bc = 512000 * .01
Bc = 5120

So our map-class should be:

map-class frame-relay FRTS
 frame-relay cir 512000
 frame-relay bc 5120
 frame-relay be 0

Now we need to enable interleaving:

frame-relay fragment

Rack16R2(config-map-class)#frame ?
  fragment           fragmentation – Requires Frame Relay traffic-shaping to be configured at the interface level

Rack16R2(config-map-class)#frame frag ?
  <16-1600>  Define fragment size, Bytes
  <cr>

Okay.  So how do we come up with this value?  There’s a chart of suggested values in the frame-relay fragement documentation.  As long as the speed is under 768K We just need to convert the Bc of the lowest speed link in the path (in our case both sides are 512K) to bytes (divide by 8):

5120/8 = 640 bytes

So now we have:

map-class frame-relay FRTS
 frame-relay cir 512000
 frame-relay bc 5120
 frame-relay be 0
 frame-relay fragment 640
 frame-relay fair-queue <- IOS added this

Now apply the map-class to the DLCI:

Rack16R2(config)#int s0/0
Rack16R2(config-if)#frame interface-d 204
Rack16R2(config-fr-dlci)#class FRTS

I generally only apply traffic shaping to the specific DLCI, IE likes to apply it to the all DLCIs on the interface.  Ask your proctor. 🙂

Rack16R2(config-if)#do sh traffic

Interface   Se0/0
       Access Target    Byte   Sustain   Excess    Interval  Increment Adapt
VC     List   Rate      Limit  bits/int  bits/int  (ms)      (bytes)   Active
201           56000     875    7000      0         125       875       –
203           56000     875    7000      0         125       875       –
205           56000     875    7000      0         125       875       –
213           56000     875    7000      0         125       875       –
204           512000    640    5120      0         10        640       –  

Rack16R2#sh frame pvc 204

PVC Statistics for interface Serial0/0 (Frame Relay DTE)

DLCI = 204, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial0/0

  input pkts 1026          output pkts 1092         in bytes 148630
  out bytes 148115         dropped pkts 0           in pkts dropped 0
  out pkts dropped 0                out bytes dropped 0
  in FECN pkts 0           in BECN pkts 0           out FECN pkts 0
  out BECN pkts 0          in DE pkts 0             out DE pkts 0
  out bcast pkts 254       out bcast bytes 90472
  5 minute input rate 0 bits/sec, 0 packets/sec
  5 minute output rate 0 bits/sec, 0 packets/sec
  pvc create time 04:09:41, last time pvc status changed 04:08:32
  fragment type end-to-end fragment size 640
  cir 512000    bc   5120      be 0         limit 640    interval 10 
  mincir 256000    byte increment 640   BECN response no  IF_CONG no
  frags 74        bytes 9639      frags delayed 0         bytes delayed 0

  shaping inactive
  traffic shaping drops 0
  Queueing strategy: weighted fair
  Current fair queue configuration:
   Discard     Dynamic      Reserved
   threshold   queue count  queue count
    64          16           0
  Output queue size 0/max total 600/drops 0

One “gotcha” on r4 is that we already have a class applied to DLCI 504:

interface Serial0/0.54 point-to-point
 ip address 129.16.54.4 255.255.255.0
 ip ospf demand-circuit
 frame-relay interface-dlci 405
  class FREEK

We just need to add the additional FRTS configuration to that already existing map-class.  You could create only one additional map-class for both of the remaining DLCIs, but the next task will require two separate map-classes as you will tweak DLCI 402 only.

Rack16R4#sh traffic

Interface   Se0/0
       Access Target    Byte   Sustain   Excess    Interval  Increment Adapt
VC     List   Rate      Limit  bits/int  bits/int  (ms)      (bytes)   Active
403           56000     875    7000      0         125       875       –
413           56000     875    7000      0         125       875       –

Interface   Se0/0.54
       Access Target    Byte   Sustain   Excess    Interval  Increment Adapt
VC     List   Rate      Limit  bits/int  bits/int  (ms)      (bytes)   Active
405           512000    640    5120      0         10        640       –

Interface   Se0/0.124
       Access Target    Byte   Sustain   Excess    Interval  Increment Adapt
VC     List   Rate      Limit  bits/int  bits/int  (ms)      (bytes)   Active
401           512000    640    5120      0         10        640       –
402           512000    640    5120      0         10        640       –

8.2 Priority Queueing

“…configure your network so that all VoIP traffic (UDP 16384 – 32767) coming from VLAN 46 going out the Frame Relay circuit to R2 gets priority over data traffic.”

“VoIP should be allocated a maximum of 192Kbps during periods of congestion on this link.”

It’s nice that IE included the VoIP protocol ports, but you should probably memorized that before the lab.  It’s pretty obvious that we’ll be configuring LLQ and mixing it with the existing FRTS configuration.

ip access-list extended TASK_8_2
 permit udp 129.16.46.0 0.0.0.255 any range 16384 32767

Rack16R4(config)#class-map TASK_8_2
Rack16R4(config-cmap)#match access-group name TASK_8_2

Rack16R4(config-ext-nacl)#policy-map TASK_8_2
Rack16R4(config-pmap)#class TASK_8_2
Rack16R4(config-pmap-c)#prio ?
  <8-2000000>  Kilo Bits per second <- KILO!!!

  percent      % of total bandwidth

Rack16R4(config-pmap-c)#prio 192

Rack16R4(config-pmap-c)#map-class frame-relay DLCI_402
Rack16R4(config-map-class)#service-policy out TASK_8_2

Configure the same thing on r2 (remember to alter the direction of your access-list).

Internetwork Expert Volume II: Lab 12 – Section 9

Section 9 – Security – 3 Points

9.1 Traffic Filtering

Allow telnet access to r6 only from an NMS at 129.16.46.100.  Log all attempts from unauthorized devices.

Let’s start with our ACL – remember that we need to add and explicit deny statement for logging:

Rack16R6(config)#ip access-list ex TASK_9_1
Rack16R6(config-ext-nacl)#perm tcp host 129.16.46.100 any eq 23
Rack16R6(config-ext-nacl)#deny tcp any any eq 23 log

Now just apply this to the vty lines:

Rack16R6(config-ext-nacl)#line vty 0 4
Rack16R6(config-line)#access-class TASK_9_1 in

Verify:

Rack16R4#telnet 150.16.6.6
Trying 150.16.6.6 …
% Connection refused by remote host

Rack16R6#sh log | b Log Buffer
Log Buffer (4096 bytes):

Aug 13 14:17:37.053: %SYS-5-CONFIG_I: Configured from console by console
Aug 13 14:17:42.285: %SEC-6-IPACCESSLOGP: list TASK_9_1 denied tcp 129.16.46.4(43572) -> 0.0.0.0(23), 1 packet

Internetwork Expert Volume II: Lab 12 – Section 10

Section 10 – System Management – 10 Points

10.1 Logging

“Configure r6 to send its logged access-list hits to this device [129.x.46.100].”
“A log message should only be generated once 10 access-list hits have been accumulated.”

The first bit is easy:

Rack16R6(config)#logging 129.16.46.100

The second bit mindfucked me.  I looked through all of the logging option and couldn’t find a match.  That’s because the configuration is a global level ip access-list command.  😦

ip access-list log-update

To set the threshold number of packets that generate a log message if they match an access list, use the ip access-list log-update command in global configuration mode.

Rack16R6(config)#ip access-list log-update threshold ?
<0-2147483647>  Access list log-update threshold (number of hits)

Rack16R6(config)#ip access-list log-update threshold 10

10.2 NTP

Basic NTP task.  r4 and r6 get time from BB1.  r1-3 and sw1 from BB2. r5 and sw2 from BB3.

Don’t overthink this one.  🙂

ntp server

To allow the software clock to be synchronized by a Network Time Protocol (NTP) time server, use the ntp server command in global configuration mode.

Rack16R2#sh ntp status
Clock is synchronized, stratum 5, reference is 192.10.16.254
nominal freq is 249.5901 Hz, actual freq is 249.5901 Hz, precision is 2**18
reference time is CC4DEE0D.A71E36DD (23:34:37.652 UTC Wed Aug 13 2008)
clock offset is 1.0901 msec, root delay is 7.06 msec
root dispersion is 1.63 msec, peer dispersion is 0.52 msec

Rack16R2#sh ntp ass

address         ref clock     st  when  poll reach  delay  offset    disp
*~192.10.16.254 127.127.7.1       4    49    64  377     7.1    1.09     0.5
* master (synced),# master (unsynced), + selected, – candidate, ~ configured

10.3 NTP

Configure devices in BGP AS 100 for CST -6 (Chicago – Brian McGahan) and devices in AS 200 for PST -8 (Reno – Brian Dennis). 🙂

clock timezone

Rack16R2(config)#clock timezone PST -8
Aug 13 23:38:00.742: %SYS-6-CLOCKUPDATE: System clock has been updated from 23:38:00 UTC Wed Aug 13 2008 to 15:38:00 PST Wed Aug 13 2008, configured from console by console.

Rack16R4(config)#clock timezone CST -6
Aug 13 16:39:06.862: %SYS-6-CLOCKUPDATE: System clock has been updated from 16:39:06 UTC Wed Aug 13 2008 to 10:39:06 CST Wed Aug 13 2008, configured from console by console.

Beware of this bit:

“Configure these devices to reflect the appropriate time zone and daylight savings time configuration.”

That daylight savings time needs to be configured:

clock summer-time

To configure the system to automatically switch to summer time (daylight saving time), use one of the formats of the clock summer-time command in global configuration mode.

Since I’m configuring this in August, the clocks will change to Daylight Savings Time:

Rack16R4(config)#clock summer-time CDT recurring
Aug 13 16:44:06.414: %SYS-6-CLOCKUPDATE: System clock has been updated from 10:44:06 CST Wed Aug 13 2008 to 11:44:06 CDT Wed Aug 13 2008, configured from console by console.

10.4 General Management

“Configure sw3 and sw4 in such a way that they will display the exact time and date of the last restart using the ‘show version’ command.”

One thing to note when addressing this task is that sw3 and sw4 are NOT configured for NTP. Does this task require turning NTP on for these devices?  Yes.

Internetwork Expert Volume II: Lab 12 – Section 11

Section 11  – IP Services – 2 Points

11.1 DNS

Configure all devices to use DNS server 129.x.3.100.

An easy task to end the lab.  🙂

ip name-server

To specify the address of one or more name servers to use for name and address resolution, use the ip name-server command in global configuration mode.

Rack16R1(config)#ip name-server 129.16.3.100

Verify:
Rack16SW4#fuck <- I truly am a child  🙂
Translating “fuck”…domain server (129.16.3.100)

The IE solution guide shows that you should apply the configuration to “r1 – sw2”.  Think that  this was an old lab converted from 2 switches to 4?  🙂

February 20, 2008

Internetwork Expert Volume II: Lab 12 – Section 4

Section 4 – Interior Gateway Routing – 8 Points

“Note: Do not redistribute between IGPs”

Sweet!!!!  Well, at least I thought so at first.  This short IGP section with no redistribution only meant that I was about to get my teeth kicked in on the BGP section.  🙂

4.1  OSPF

“To minimize WAN utilization OSPF traffic should only be sent over the Frame Relay segment during initial adjacency establishment and when changes occur in the OSPF topology.”

Huh?  Does OSPF traffic include hellos?  If it doesn’t, then we’re good by default…except for the 30 minute paranoid update.  😦

If they include hellos, then we need to configure the the point-to-point FR connection as a demand circuit.

ip ospf demand-circuit

“ip ospf demand-circuit” only needs to be configured on one side of the link.

r4(config-if)#int s0/0.54
r4(config-subif)#ip os demand

r4#sh ip os int s0/0.54
Serial0/0.54 is up, line protocol is up
  Internet Address 129.1.54.4/24, Area 0
  Process ID 100, Router ID 150.1.4.4, Network Type POINT_TO_POINT, Cost: 65
  Configured as demand circuit.
  Run as demand circuit.

  DoNotAge LSA allowed.
  Transmit Delay is 1 sec, State POINT_TO_POINT,
  Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5
    oob-resync timeout 40
    Hello due in 00:00:01
  Supports Link-local Signaling (LLS)
  Index 1/1, flood queue length 0
  Next 0x0(0)/0x0(0)
  Last flood scan length is 1, maximum is 2
  Last flood scan time is 0 msec, maximum is 4 msec
  Neighbor Count is 1, Adjacent neighbor count is 1
    Adjacent with neighbor 150.1.5.5  (Hello suppressed)
  Suppress hello for 1 neighbor(s)

4.2 OSPF

Interesting task:

Configure sw4 to match exactly the output below and nothing more:

sw4#sh ip os data | i Net Link States \(Area 34\)
                Net Link States (Area 34)

Currently I show:

sw4#sh ip os data | i Net Link States \(Area 34\)
                Net Link States (Area 34)
                Summary Net Link States (Area 34)

So I need to get rid of Summary Net Link States (LSA 3).  How to do this?

Stub networks?  No:

OSPF Stubs:

Type Keyword LSAs Default Injected?
stub area x stub 1,2,3,4 Yes
totally stubby area x stub no-summary 1,2,default of 3 Yes
not-so-stubby area x nssa 1,2,3,4,7 NO
not-so-totally-stubby area x nssa no-summary 1,2,default of 3,7 Yes

The answer was easy — change the OSPF network type on po34 from Broadcast to Point-to-Point:

sw4#sh ip os int po34 | i Type
  Process ID 100, Router ID 150.1.10.10, Network Type BROADCAST, Cost: 1

sw4(config)#int po34
sw4(config-if)#ip os net point-to-point

sw3(config-if)#int po34
sw3(config-if)#ip os net point-to-point
sw4
#sh ip os data | i Net Link States \(Area 34\)
                Summary Net Link States (Area 34)

Task 4.2

4.3 EIGRP

This was a pretty basic EIGRP configuration with one exception.  r1, r2, and r4 form a Frame Relay hub-and-spoke network.  r1 and r2 (spokes) are running EIGRP, but EIGRP is not enabled on r4 (hub).  Consequently, r1 and r2 are not peering though the Frame Relay cloud.

r2#sh ip ei int
IP-EIGRP interfaces for process 200

                        Xmit Queue   Mean   Pacing Time   Multicast    Pending
Interface        Peers  Un/Reliable  SRTT   Un/Reliable   Flow Timer   Routes
Lo0                0        0/0         0       0/1            0           0
Se0/0/0           0        0/0         0       0/1            0           0
Se0/1/0            1        0/0         4       0/15          50           0

r2#sh ip ei nei
IP-EIGRP neighbors for process 200
H   Address                 Interface       Hold Uptime   SRTT   RTO  Q  Seq
                                            (sec)         (ms)       Cnt Num
0   129.1.23.3              Se0/1/0           13 00:09:18    4   200  0  11

Can I disable EIGRP split-horizon on r4 even though it’s not running EIGRP?

r4(config)#int Serial0/0.124
r4(config-subif)#no ip split-horizon eigrp ?
  <1-65535>  Autonomous system number

r4(config-subif)#no ip split-horizon eigrp 200

It takes the command, but that’s not the fix:

r2#clear ip ei neighbors
IP-EIGRP neighbors for process 200
H   Address                 Interface       Hold Uptime   SRTT   RTO  Q  Seq
                                            (sec)         (ms)       Cnt Num
0   129.1.23.3              Se0/1/0           12 00:00:02    2   200  0  18

Okay….next try a neighbor command:

neighbor (EIGRP)

r2(config)#router ei 200
r2(config-router)#neigh 129.1.124.1 Serial0/0/0

r1(config)#router ei 200
r1(config-router)#neigh 129.1.124.2 s0/0

Sweet, sweet IOS music:

*Mar  1 21:17:56.758: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 200: Neighbor 129.1.124.2 (Serial0/0) is up: new adjacency

r2#sh ip ei nei
IP-EIGRP neighbors for process 200
H   Address                 Interface       Hold Uptime   SRTT   RTO  Q  Seq
                                            (sec)         (ms)       Cnt Num
1   129.1.124.1           Se0/0/0          140 00:00:39   14   200  0  18
0   129.1.23.3              Se0/1/0           12 00:03:24    1   200  0  18

Alas, all of this effort was for naught.  I didn’t read the task close enough.  Instead I configured EIGRP based on the IGP diagram.  That diagram shows the spokes’ Frame Relay interfaces in the EIGRP domain, BUT the task does not require that you configure them.  😦

This posting discusses an anomaly in the solution guide (two EIGRP routes on sw1 showing as D EX in the solution guide):

Task 4.3

February 18, 2008

Internetwork Expert Volume II: Lab 12 – Section 3

Section 3 – Frame Relay – 8 Points

3.1 Hub-and-Spoke

Basic hub and spoke configuration with the additional requirement of turning on CDP.

3.2 Point-To-Point

Very basic configuration.

3.3 Keepalives

This is the first lab where I’ve had to configure Frame Relay End-To-End keepalives.  Time to get my FREEK on.  🙂

Key phrases:

“having r4 and r5 poll each other”
“the other side’s interface is up and reachable every 15 seconds”

frame-relay end-to-end keepalive mode

frame-relay end-to-end keepalive timer

Defaults
Send timer: 10 seconds
Receive timer: 15 seconds

r5(config)#map-class frame KEEPALIVES
r5(config-map-class)#frame end-to-end keepalive mode bidirectional
r5(config-map-class)#frame end-to-end keepalive timer send 15

* Receive timer is 15 by default so we don’t need to configure it.

r5(config-map-class)#int s0/0.54
r5(config-subif)#frame-relay interface-dlci 504
r5(config-fr-dlci)#class KEEPALIVES

Damn my fat fingers.  I accidentally typed a subinterface that did not exist – which brought it into existence  😦

r4(config-map-class)#int s0/0.15
% Incomplete command.

r4(config-subif)#do sh ip int br
Serial0/0.15               unassigned      YES unset  up                    up

r4(config-subif)#no int s0/0.15
Not all config may be removed and may reappear after reactivating the sub-interface

I see a reload in my future.  😦

r4#sh frame end keep

End-to-end Keepalive Statistics for Interface Serial0/0 (Frame Relay DTE)

DLCI = 405, DLCI USAGE = LOCAL, VC STATUS = ACTIVE (EEK UP)

SEND SIDE STATISTICS

Send Sequence Number: 255,      Receive Sequence Number: 255
Configured Event Window: 3,     Configured Error Threshold: 2
Total Observed Events: 1,       Total Observed Errors: 0
Monitored Events: 0,            Monitored Errors: 0
Successive Successes: 0,        End-to-end VC Status: UP

RECEIVE SIDE STATISTICS

Send Sequence Number: 255,      Receive Sequence Number: 255
Configured Event Window: 3,     Configured Error Threshold: 2
Total Observed Events: 1,       Total Observed Errors: 0
Monitored Events: 0,            Monitored Errors: 0
Successive Successes: 0,        End-to-end VC Status: UP

3.4 Point-to-Point

Very basic configuration.

Internetwork Expert Volume II: Lab 12 – Section 2

Section 2 – Bridging and Switching – 16 Points

2.1 Core Layer 2

This task was an interesting twist on a standard L2 core task.  You are asked to configure each of the switches to match a couple of show commands:

sw3(config-if)#do sh vtp stat | i (Operating Mode|Name)
VTP Operating Mode              : Client
VTP Domain Name                 : IE
sw3(config-if)#do sh vlan br | e (unsup|^1 |^ )

VLAN Name                             Status    Ports
—- ——————————– ——— ——————————-
3    VLAN0003                         active
17   VLAN0017                         active
22   VLAN0022                         active
33   VLAN0033                         active    Fa0/3
38   VLAN0038                         active    Fa0/24
45   VLAN0045                         active    Fa0/5
46   VLAN0046                         active
58   VLAN0058                         active

I actually found this task to be easier than usual.  BUT…make sure you open your ports.  IE shut a number of them down in the initial configurations. 

2.2 EtherChannel

This was an easy Layer 3 EtherChannel task, except that the diagram has an incorrect subnet for po34 between sw3 and sw4.  It should be 129.x.34.0/24 and not 129.x.43.0/24

2.2 – typo/difference between diagram and solution

2.3 MAC Filtering

You need to limit a couple of ports to only learning two MAC addresses and to shut down for 60 seconds if they learn a third. 

Configuring Port Security

•The switch does not support port security aging of sticky secure MAC addresses.

(Optional) Set the violation mode, the action to be taken when a security violation is detected, as one of these:

•protect—When the number of port secure MAC addresses reaches the maximum limit allowed on the port, packets with unknown source addresses are dropped until you remove a sufficient number of secure MAC addresses to drop below the maximum value or increase the number of maximum allowable addresses. You are not notified that a security violation has occurred.

Note We do not recommend configuring the protect mode on a trunk port. The protect mode disables learning when any VLAN reaches its maximum limit, even if the port has not reached its maximum limit.

•restrict—When the number of secure MAC addresses reaches the limit allowed on the port, packets with unknown source addresses are dropped until you remove a sufficient number of secure MAC addresses or increase the number of maximum allowable addresses. An SNMP trap is sent, a syslog message is logged, and the violation counter increments.

•shutdown—The interface is error-disabled when a violation occurs, and the port LED turns off. An SNMP trap is sent, a syslog message is logged, and the violation counter increments.

Note When a secure port is in the error-disabled state, you can bring it out of this state by entering the errdisable recovery cause psecure-violation global configuration command, or you can manually re-enable it by entering the shutdown and no shutdown interface configuration commands.

We need to use shutdown mode (default) with errdisable recovery cause psecure-violation

errdisable recovery

Defaults
Recovery is disabled for all causes.
The default recovery interval is 300 seconds.

Here’s the configuration:

errdisable recovery cause psecure-violation
errdisable recovery interval 60
!
int range fa0/7 – 8
switch mode access
switchport port-security
switchport port-security max 2
switchport port-security violation shutdown

sw1#sh errdisable recovery | e Dis
—————–    ————–
psecure-violation    Enabled

Timer interval: 60 seconds

Interfaces that will be enabled at the next timeout:

sw1#sh port-security
Secure Port  MaxSecureAddr  CurrentAddr  SecurityViolation  Security Action
                (Count)       (Count)          (Count)
—————————————————————————
      Fa0/7                         0                  0         Shutdown
      Fa0/8              2            0                  0         Shutdown
—————————————————————————
Total Addresses in System (excluding one mac per port)     : 0
Max Addresses limit in System (excluding one mac per port) : 6272

2.4 MAC Filtering

This was a pretty easy MAC filtering task using MAC ACLs….or so I thought.  🙂

Port ACLs

Creating Named MAC Extended ACLs

mac access-list extended FILTER_ROUTER
deny host 0030.1369.87a0 any
permit any any

Applying a MAC ACL to a Layer 2 Interface

sw1(config-if-range)#mac access-group FILTER_ROUTER ?
  in  Apply to Ingress

sw1(config-if-range)#mac access-group FILTER_ROUTER in

sw1#sh mac access-group int fa0/7
Interface FastEthernet0/7:
   Inbound access-list is FILTER_ROUTER
   Outbound access-list is not set
sw1#sh mac access-group int fa0/8
Interface FastEthernet0/8:
   Inbound access-list is FILTER_ROUTER
   Outbound access-list is not set

After all of that…the solution guide uses:

mac-address-table static 0030.1369.87a0 vlan 17 drop

Okay…why?  Well, there’s really good reason. 🙂

The immediate reaction to this task is typically to use an extended MAC address access-list to deny traffic from this MAC address from entering interfaces fa0/7 or fa0/8.  However, MAC address access-lists only affect non-IP traffic.  Therefore, assuming that host on VLAN 17 are running IP (a fair assumption), using a MAC assess-list to filter this host will have no effect.

Good discussion about this task:

Task 2.4

2.5 QoS

Police a port to 3Mbps, but don’t use policing.  Clue: the task specifies unicast traffic.

Configuring Storm Control

Storm control uses one of these methods to measure traffic activity:

•Bandwidth as a percentage of the total available bandwidth of the port that can be used by the broadcast, multicast, or unicast traffic

•Traffic rate in packets per second at which broadcast, multicast, or unicast packets are received (Cisco IOS Release 12.2(25)SE or later)

•Traffic rate in bits per second at which broadcast, multicast, or unicast packets are received (Cisco IOS Release 12.2(25)SE or later)

With each method, the port blocks traffic when the rising threshold is reached. The port remains blocked until the traffic rate drops below the falling threshold (if one is specified) and then resumes normal forwarding. If the falling suppression level is not specified, the switch blocks all traffic until the traffic rate drops below the rising suppression level. In general, the higher the level, the less effective the protection against broadcast storms.

REMEMBER that Storm control is inbound!!!

Storm control has some WEIRD parameters:

sw2(config-if)#storm-control unicast level bps ?
  <0.0 – 10000000000.0>[k|m|g]  Enter rising threshold

Specify the rising and falling suppression levels as a rate in bits per second at which traffic is received on the port.

•bps—Rising suppression level, up to 1 decimal place. The range is 0.0 to 10000000000.0. Block the flooding of storm packets when the value specified for bps is reached.

sw2(config-if)#storm-control unicast level bps 3000000

sw2(config-if)#do sh run int fa0/2
interface FastEthernet0/2
 switchport access vlan 22
 storm-control unicast level bps 3m

sw2#sh storm uni
Interface  Filter State   Upper        Lower        Current
———  ————-  ———–  ———–  ———-
Fa0/24     Forwarding         3m bps       3m bps        0 bps

Send some large pings from r2 to bb2:

r2#p 192.10.1.254 re 10000 si 1500

Type escape sequence to abort.
Sending 10000, 1500-byte ICMP Echos to 192.10.1.254, timeout is 2 seconds:
.!!!!!!!!!!!!!!!!!!!!!!!!!!!

sw2#sh storm uni
Interface  Filter State   Upper        Lower        Current
———  ————-  ———–  ———–  ———-
Fa0/2     Blocking           3m bps       3m bps    7.83m bps

01:29:46: %STORM_CONTROL-3-FILTERED: A Unicast storm detected on Fa0/2. A packet filter action has been applied on the interface.

sw2#sh storm uni
Interface  Filter State   Upper        Lower        Current
———  ————-  ———–  ———–  ———-
Fa0/2     Forwarding         3m bps       3m bps   12.89k bps

The IE solution uses the older percentage of interface bandwidth configuration:

storm-control unicast level 3.00

2.6 Traffic Filtering

Stop PCs on a VLAN from communicating directly with each other, but allow them to still communicate with other ports or interfaces in the VLAN.  Use the minimum configuration.

switchport protected

Use the switchport protected interface configuration command to isolate unicast, multicast, and broadcast traffic at Layer 2 from other protected ports on the same switch. Use the no form of this command to disable protection on the port.

So….which ports do I apply it to?

The answer shows fa0/7 and fa0/8 on sw1.  Are they part of VLAN 17?

Well….they were initially, but I thought that that was an intial config error (see error 4?)

From intial config:

interface range Fa0/7 – 8
 switchport access vlan 17
 no shutdown

By completing this task you will “break” task 2.1  I think that this is just the result of a mistake in the lab document for task 2.1

sw1#sh int fa0/7 swit | i Protected
Protected: true
sw1#sh int fa0/8 swit | i Protected
Protected: true

Next Page »

Blog at WordPress.com.