CCIE Pursuit Blog

June 26, 2009

Core Knowledge Question of the Day: 26 June 2009

What is the name of a well-known discretionary BGP attribute that is used to alert downstream routers that a loss of path information has occurred?

Highlight for answer: ATOMIC_AGGREGATE.

June 25, 2009

Core Knowledge Question of the Day: 25 June 2009

Filed under: BGP,Cisco,Cisco Certification,Question Of The Day — cciepursuit @ 8:44 am

What is the name of a well-known mandatory attribute that uses a sequence of AS numbers to describe the route to the destination specified by the NLRI?

Highlight for answer: AS_PATH

May 29, 2009

Core Knowledge Question of the Day: 29 May 2009

By default, what is the TTL of an EBGP peering?

Highlight for answer: 1

April 28, 2009

Core Knowledge Question of the Day: 28 April 2009

Which well known BGP community is used in confederation scenarios to prevent sending packets outside the local AS?

Highlight for answer: Local-AS

February 6, 2009

Where Is The ‘neighbor allowas-in’ Command in the 12.4 Documentation?

I was doing a lab last night that required that you allow prefixes into a BGP AS that had that AS number in the AS-path.  Normally, BGP would drop these advertisements, but I knew that there was a command to allow the local AS in.  I also knew that it was configured as a ‘neighbor’ command.

Weird….I figured that this was something like ‘neighbor allow as’ but I couldn’t find that command in the BGP command reference:

neighbor activate
neighbor advertise-map
neighbor advertisement-interval
neighbor capability orf prefix-list
neighbor default-originate
neighbor description
neighbor disable-connected-check

But there it was on the CLI:

Rack1R3(config-router)#neigh 136.1.23.2 ?
activate                 Enable the Address Family for this Neighbor
advertise-map            specify route-map for conditional advertisement
advertisement-interval   Minimum interval between sending BGP routing updates
allowas-in               Accept as-path with my AS present in it

That’s strange.  I went to the 12.4 Master Command List and it’s there…under:

Cisco IOS Multiprotocol Label Switching Command Reference
neighbor allowas-in

I find it odd that it was not under the BGP command reference, but it’s not a big deal as the name of the command pretty much sums up what it does.  The only (optional)argument that the command takes is the number of times that the local AS can appear in the path.

August 17, 2008

Internetwork Expert Volume II: Lab 8 – Section 4

Section 4 – Exteriour Gateway Routing – 13 Points

4.1 BGP

Easy BGP peering task.  Only “twist” is that you’ll be configuring confederations.

SubAS 65145 has a full mesh. 65267 does not.  You’ll need make r6 a route-reflector.

You’ll also need to remember to set ‘next-hop-self’ between inter-confederation peers where needed (unlike true EBGP peerings, inter-confederation peers do not automatically set ‘next-hop-self’).  Or not…this will be addressed in later tasks.  :-)

For some reason IE peered between the loopbacks on the routers in SubAS 65145.

4.2 BGP Summarization

Advertise a summary of 174.x.0.0/16 to the backbone routers.

“Do not allow any other devices in your BGP network to see this prefix.”
“Use one static router on r5 and r6 to accomplish this.”

So we’ll need to create a static route to Null0 on r5 and r6 and redistribute it into BGP…while filtering it for the rest of the BGP routers.

First, create the static route:

r5(config)#ip route 174.1.0.0 255.255.0.0 null0

Next, match that route in a prefix-list and create route-maps to filter it for our network:

r5(config)#ip prefix-list TASK_4_2 permi 174.1.0.0/16

r5(config)#route-map OUT_TO_R4 deny 10
r5(config-route-map)#match ip add pre TASK_4_2
r5(config-route-map)#route-map OUT_TO_R4 permi 1000
r5(config-route-map)#do sh hist

r5(config-route-map)#route-map OUT_TO_R1 deny 10
r5(config-route-map)#match ip add pre TASK_4_2
r5(config-route-map)#route-map OUT_TO_R1 permi 1000

Finally, redistribute the static route into BGP and apply the route-maps outbound to the neighbors we need to filter for:

r5(config-route-map)#router bgp 65145
r5(config-router)#redistribute static
r5(config-router)#neigh 174.1.145.4 route-map OUT_TO_R4 out
r5(config-router)#neigh 174.1.145.1 route-map OUT_TO_R1 out

We are advertising the summary to BB3:

r5#sh ip bgp neigh 204.12.1.254 adv| b Netw
   Network          Next Hop            Metric LocPrf Weight Path
*> 174.1.0.0        0.0.0.0                  0         32768 ?

Total number of prefixes 1

But we’re not advertising the summary to r4 and r1:

r5#sh ip bgp neigh 174.1.145.4 adv| b Netw
   Network          Next Hop            Metric LocPrf Weight Path
*> 28.119.16.0/24   204.12.1.254             0             0 54 i
*> 28.119.17.0/24   204.12.1.254             0             0 54 i

Total number of prefixes 2

r5#sh ip bgp neigh 174.1.145.1 adv| b Netw
   Network          Next Hop            Metric LocPrf Weight Path
*> 28.119.16.0/24   204.12.1.254             0             0 54 i
*> 28.119.17.0/24   204.12.1.254             0             0 54 i

Total number of prefixes 2

4.3 BGP Next-Hop Processing

“Configure the network in such a way that all devices throughout your network have reachablility to the BGP prefixes learned from AS54.”

Ugh.  That “all devices” bit had me worried that I would need to redistribute BGP into IGP. But the only devices not running BGP are sw3 and sw4 and they are in an OSPF stub area so they will just send traffic for unknown destinations to r3.  So we should be cool.

“Do not advertise the Frame Relay link to BB1 or the Ethernet link to BB3 into IGP or BGP to accomplish this.”

Not a problem I just use ‘next-hop-self’

“Do not use the next-hop-self command to accomplish this.”

Oh poop. I’m stumped.  Should I summarize the routes?  Create a default route? 

Nope. IE was being a bit tricky.  I need to use next-hop modification BUT I cannot use the command ‘next-hop-self’.  Instead I can set the next-hop in a route-map with ‘set ip next-hop peer-address':

We can use the route-maps that we created for the last task and just add the line:

r6(config)#route-map OUT_TO_R2 perm 1000
r6(config-route-map)#set ip next-hop peer-address

I can ping prefixes from BB1 and BB3 from sw3 even though BGP is not running:

sw3#p 28.119.17.1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 28.119.17.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/6/8 ms

sw3#p 112.0.0.1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 112.0.0.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 8/8/8 ms

sw3#sh ip proto sum
Index Process Name
0     connected
1     static
2     ospf 100
*** IP Routing is NSF aware ***

4.4 BGP Bestpath Selection

Advertise some networks into BGP and then make the routes to some of these networks be preferred via one of the AS 54 backbone routers.

We’re affecting inbound traffic so we have a choice of AS-Path or MED. I picked AS-Path.

We also have this requirement:

“Other AS’s beyond AS 54 should not see these specific subnets, but instead should only see the previously advertised aggregate.”

This task would be very difficult without our good friend the BGP community attribute.  :-)

r6(config)#ip prefix-list VLAN3 permi 174.1.3.0/24
r6(config)#ip prefix-list VLAN4 permi 174.1.4.0/24
r6(config)#ip prefix-list VLAN7 permi 174.1.7.0/24

r6(config)#route-map OUT_TO_BB1
r6(config-route-map)#match ip add pre VLAN3 VLAN7
r6(config-route-map)#set as-path prepend 100 100 100 100
r6(config-route-map)#set community no-export
r6(config-route-map)#route-map OUT_TO_BB1 20
r6(config-route-map)#match ip add pre VLAN4
r6(config-route-map)#set community no-export
r6(config-route-map)#route-map OUT_TO_BB1 permit 1000

r6(config)#router bgp 65267
r6(config-router)#neigh 54.1.2.254 send-community
r6(config-router)#neigh 54.1.2.254 route-map OUT_TO_BB1 out

IE used MED instead of AS-Path (although they noted that both were acceptable).  They did drop this on me (I can’t believe that I didn’t know this):

MED is only compared (by default) between prefixes learned from the same autonomous system.

4.5 BGP Filtering

Advertise VLAN 1001 into BGP but make sure that devices outside of AS 65145 don’t have reachbility to this VLAN.

“Do not use any access-lists or prefix-lists to accomplish this.”

Another job for the BGP community attribute.  r1 is inside a confederation so we should use local-AS.

r1(config)#route-map TASK_4_5
r1(config-route-map)#set community local-AS

r1(config)#router bgp 65145
r1(config-router)#net 174.1.1.0 ma 255.255.255.0 route-map TASK_4_5
r1(config-router)#neighbor 174.1.145.4 send-comm
r1(config-router)#neighbor 174.1.145.5 send-comm

We see the route in AS 65145:

r4#sh ip bgp 174.1.1.0 255.255.255.0
BGP routing table entry for 174.1.1.0/24, version 20
Paths: (1 available, best #1, table Default-IP-Routing-Table, not advertised outside local AS)
Flag: 0x880
  Not advertised to any peer
  Local
    174.1.145.1 from 174.1.145.1 (150.1.1.1)
      Origin IGP, metric 0, localpref 100, valid, confed-internal, best
      Community: local-AS

We do not see it outside of AS 65145:

r2#sh ip bgp 174.1.1.0 255.255.255.0
% Network not in table

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.

July 28, 2008

The Value Of Redoing Labs

I completed IE’s Volume II lab 3 for the second time yesterday.  I’ve started redoing all of the labs in order (I hope to make it through all 20 before my lab date).  As I’ve stated before, I was surprised that I don’t memorize labs.  It looks like I last did this lab back in December (where has the time gone?) so it shouldn’t be too big of a surprise.

This was a difficulty level 6 lab, so it was pretty straight forward.  I did hit a couple of snags, but I was able to get through them because I finally have my head around some of the technologies.  As Brian Dennis says, “You never stop making mistakes, you just get better at spotting them.” 

The first time through this lab I was nowhere near as strong in BGP and multicast (I’m still not “lab ready” in either technology, but I’m way better than I was).  In this lab there were two AS 100.  I was having a heck of a time because I could not get the backbone prefixes advertised into one AS 100 to propagate to the other AS 100 (there was a transit AS between them).  So I stepped back and thought about it.  I could see the prefixes in the peer’s BGP table and I could see that they were being advertised (‘show ip bgp neighbor x.x.x.x adv’) from the peer but not received by my router (“show ip bgp neighbor x.x.x.x route’).  My router was installing 3 other prefixes that were originated from a different backbone router. WTF?  So I started mentally running through the reasons why my router would not accept those routes.  What was it that was different about those 3 prefixes that were installed and the 10 that were not being installed.  Voila!  Those 10 prefixes were being advertised to the other AS 100 then to the transit AS and then dropping when hitting this AS 100.  DOH!  A BGP router will not install prefixes that already contain its own AS number.  That was the problem.  Now I could concentrate on solving this issue rather than wasting time on troubleshooting.

Now you’re probably thinking “big deal” and/or “how does this guy expect to pass the lab?”, but my point is that I was able to solve this issue by knowing the technology.  I’m pretty sure that the first time through this lab I did not even notice this issue (you eventually filter those routes, so it becomes a non-issue) nor would I have successfully found the reason.  Doing a lab for a second (or third…or forth…) time can help catch problems that you did not see the first time through.

I hit another snag when I got to multicast.  Try as I might I could not get one of my routers to recognize the RP.  The interface was configured correctly and I was seeing the PIM neighbor.  By doing a simple traceroute I was able to see that traffic was routing over a PTP link instead of the Frame Relay link.  But I took care of that earlier in the lab by setting the OSPF cost to a high value, right?.  Unfortunately, after that task I set the OSPF auto-cost so that all of the other links now had a higher cost.  My PTP link was now preferred over my Frame Relay link.  I had used a high cost value (6000) but it was not high enough once the other costs were adjusted  :-(  Again, I was able to (relatively) quickly find the issue and I understood how and why it was happening (as well as how to fix it).  My multicast configuration was correct.  The first time through I most likely did not catch this issue because I probably did not verify everything with the degree of anal-retentiveness that I do now.  I could have easily overlooked this issue if I did not verify the RP mapping on that router.  The problem would not show up in my ping scripts.  I would have lost points for at least two sections.

Anyhoo…my point is that you should definitely do labs more than once, especially if it’s been a while since you last did the lab.

July 8, 2008

BGP Path Manipulation + Goofy Mnemonic

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

When altering BGP path selection, it is a good idea to have the following table committed to memory:

Method Direction Applied Direction Affected Best Metric
Weight Inbound Outbound Highest
Local Preference Inbound Outbound Highest
AS Path Outbound Inbound Shortest
MED (metric) Outbound Inbound Lowest

This table shows the four most common BGP path manipulation attributes in order of preference (here’s a mnemonic to memorize all of the BGP attributes).  Whenever I am tasked with BGP path manipulation in the lab I quickly recreate the above table with the following mnemonic:

“When applying in London in April, make love.”

W = Weight
A = applied (April reminds me of showers which reminds me of London, so this helps recreate the mnemonic as well)
I = inbound
L = Local Preference
I = inbound
A = AS Path
M = MED (London makes me think of sex for reasons I’ll keep to myself :-) )
L = lowest

You’re probably thinking “Nice. But that doesn’t look like the entire table to me is represented in that stupid phrase.” And you’re right.  :-)

I write out the table first with the headers only:

Method Direction Applied Direction Affected Best Metric
       
       
       
       

Then I write ‘Weight’.  The “applying” bit just reminds me that the second header should be “Direction Applied” and not “Direction Affected“.  If you mix up those two headers, then you are in for a very bad experience.  :-)

Method Direction Applied Direction Affected Best Metric
Weight      
       
       
       

“In” means inbound (under Direction Applied).  With just this bit of information I can fill in the rest of the “Direction” fields because I know that the first two attributes are applied inbound.  That means the that the last two attributes are applied outbound.  Since the “Direction Affected” is the opposite of the “Direction Applied”, it’s a snap to fill in that information as well.

Method Direction Applied Direction Affected Best Metric
Weight Inbound Outbound  
  Inbound Outbound  
  Outbound Inbound  
  Outbound Inbound  

So we’re left with ‘London in April, make love’.  ‘London’ = local preference.  ‘in’ is another reminder that Local_Pref is applied inbound (and it makes the goofy sentence flow better).  ‘April’ = AS Path and ‘make’ = MED.

Method Direction Applied Direction Affected Best Metric
Weight Inbound Outbound  
Local Preference Inbound Outbound  
AS Path Outbound Inbound  
MED Outbound Inbound  

Now all we need is to fill in the ‘Best Metric’ column.  I assume that the highest metric is always the best metric except in the case of the last two attributes.  In this case, ‘love’ = lowest (for MED).  I know that the shortest AS Path is the best (no need to memorize that as it’s pretty logical). 

So now I have the whole table:

Method Direction Applied Direction Affected Best Metric
Weight Inbound Outbound Highest
Local Preference Inbound Outbound Highest
AS Path Outbound Inbound Shortest
MED Outbound Inbound Lowest

So thanks for crawling into my mind.  Pretty empty huh? The exit is through my ears.  :-)

You can create your own mnemonic (I’m sure that mine is not the best) and add more or less detail as needed.  After you are able to recreate this table a couple of times, you’ll find that you won’t need to use the mnemonic, but it’s nice to have it in case you need it.

May 24, 2008

Some Of This Crap Really Has Real World Implications :-)

Filed under: BGP,Cisco,Cisco Certification,IOS,Work — cciepursuit @ 3:39 pm
Tags: , , ,

I had an issue at work with a DS3 mysteriously bouncing.  We never saw the circuit actually drop (nor any errors) but the BGP peering would sporadically drop.  After one of the engineers “solved” the problem by having AT&T set their BGP timers to match ours (see this QoD for an explanation of why that did not work) the issue came to me.  I suggested that we disable bgp fast-external-fallover and see if that at least kept the peering nailed up.  That worked!  We later found out that the site had taken a lightning strike a couple of weeks ago.  We had a vendor meet with Cisco, AT&T, the cabling vendor, and the LEC the next day.  MAGICALLY the issue “cleared while testing” once the LEC looked at the circuit.  :-)

Anyhoo…by default bgp fast-external-fallover is enabled.  This is generally a good thing as it will bring down a BGP peering if a directly connected link goes down.  No need to wait out your 3 keepalives.  In our case, their was some sporadic issue that “blinked” out the circuit (I suspect a punch-drunk repeater or some CO equipment) very briefly.  Our router would then bring down the BGP peering and then re-establish it.  By configuring ‘no bgp fast-external-fallover’ under the BGP process, we were able to keep the BGP peering up.

bgp fast-external-fallover

Usage Guidelines
The bgp fast-external-fallover command is used to disable or enable fast external fallover for BGP peering sessions with directly connected external peers. The session is immediately reset if link goes down. Only directly connected peering sessions are supported.

If BGP fast external fallover is disabled, the BGP routing process will wait until the default hold timer expires (3 keepalives) to reset the peering session. BGP fast external fallover can also be configured on a per-interface basis using the ip bgp fast-external-fallover interface configuration command.

Next Page »

The Rubric Theme. Blog at WordPress.com.

Follow

Get every new post delivered to your Inbox.

Join 113 other followers