CCIE Pursuit Blog

August 14, 2008

14 August – CCIE Quickies

Filed under: Cisco,Cisco Certification — cciepursuit @ 12:17 pm
Tags: , , , ,

CCIE, The Everest Quest - Lessaid recently passed his R&S written exam.  Congratulations.

GlobalConfig.net - This site recently ran a cabling spaghetti photo contest.  Here’s the winner.

Cisco Press- Cisco Press has just made available a (118 page!) excerpt from the new CCIE Routing & Switching Practice Labs book.

CCIE CandidateAnother new blogger joins Ethan’s site.  Welcome aboard Carl.

Internetwork Expert Blog – More of the Volume I v5.0 labs are coming soon.  IE is asking for input as to which technologies you would like more coverage on.  There’s already a vote for redistribution (my choice).

Cisco Live! Virtual- You can test drive the Cisco Live Virtual interface and check out the free “Troubleshooting LAN Protocols” session.

CiscoLive 1 of the top sessions in www.ciscolivevirtual.comin July 2008 was Troubleshooting LAN Protocols…Login to watch & rate this session! 38 minutes ago from web

I created a guest access acount and signed in.  It sure is pretty!  :-)  I quickly gave up on trying to find the free content though.  Hopefully you have better luck.

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: 0×4940
  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: 0×840
  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.

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 (?)

The Rubric Theme. Create a free website or blog at WordPress.com.

Follow

Get every new post delivered to your Inbox.

Join 109 other followers