CCIE Pursuit Blog

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

Advertisements

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 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.

April 28, 2008

Internetwork Expert Volume II: Lab 5 – Section 5

Exterior Gateway Routing – 10 Points

4.1 BGP Peering

Basic peering task.  Keep in mind that sw3 and sw4 don’t have an IGP running.

I’m still having problems with know when to apply ‘next-hop-self’.  I need to do some more work on BGP. 😦

Task 4.1 – BGP Next-Hop-Self

4.2 AS-Path Manipulation

We need to make sure that the private AS’s do not get outside of AS 300:

Before:
r4#sh ip bgp quote _650.._
BGP table version is 10, local router ID is 150.1.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
*> 150.1.9.0/24     162.1.0.3                              0 300 65002 65034 i
*> 150.1.10.0/24    162.1.0.3                              0 300 65002 65034 i
*> 162.1.7.0/24     162.1.0.2                              0 300 65001 i
*> 162.1.18.0/24    162.1.0.3                              0 300 65002 i

r3#sh ip bgp neigh 162.1.0.4 adv
BGP table version is 10, local router ID is 150.1.3.3
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
*> 28.119.16.0/24   162.1.0.4                              0 100 54 i
*> 28.119.17.0/24   162.1.0.4                              0 100 54 i
*> 150.1.9.0/24     162.1.38.8                             0 65002 65034 i
*> 150.1.10.0/24    162.1.38.8                             0 65002 65034 i
*>i162.1.7.0/24     162.1.27.7               0    100      0 65001 i
*> 162.1.18.0/24    162.1.38.8               0             0 65002 i
*> 205.90.31.0      162.1.13.1                             0 200 254 ?
*> 220.20.3.0       162.1.13.1                             0 200 254 ?
*> 222.22.2.0       162.1.13.1                             0 200 254 ?

Total number of prefixes 9

r3(config)#ip as-path access-list 42 perm _650.._
r3(config)#route-map TASK_42 deny 10
r3(config-route-map)# match as-path 42
r3(config-route-map)#route-map TASK_42 perm 1000
r3(config-route-map)#router bg 300
r3(config-router)#neigh 162.1.0.4 route-map TASK_42 out
r3(config-router)#neigh 162.1.13.1 route-map TASK_42 out

After:
r3#sh ip bgp neigh 162.1.0.4 adv
BGP table version is 10, local router ID is 150.1.3.3
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      162.1.13.1                             0 200 254 ?
*> 220.20.3.0       162.1.13.1                             0 200 254 ?
*> 222.22.2.0       162.1.13.1                             0 200 254 ?

Total number of prefixes 3

r4#sh ip bgp
BGP table version is 14, local router ID is 150.1.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
*> 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
*> 205.90.31.0      162.1.0.3                              0 300 200 254 ?
*> 220.20.3.0       162.1.0.3                              0 300 200 254 ?
*> 222.22.2.0       162.1.0.3                              0 300 200 254 ?

My solution works (umm…technically 🙂  ), but I’m actually filtering off the routes (which I did not think broke the task).  There’s a much easier way:

neighbor remove-private-as

Usage Guidelines
This command is available for external BGP (eBGP) neighbors only.

When an update is passed to the external neighbor, if the autonomous system path includes private autonomous system numbers, the software will drop the private autonomous system numbers.

If the autonomous system path includes both private and public autonomous system numbers, the software considers this to be a configuration error and does not remove the private autonomous system numbers.

If the autonomous system path contains the autonomous system number of the eBGP neighbor, the private autonomous system numbers will not be removed.

If this command is used with confederation, it will work as long as the private autonomous system numbers follow the confederation portion of the autonomous path.

The private autonomous system values are from 64512 to 65535.

There is a much better solution.  The prefixes are still advertised to the eBGP neighbor but do not show up on the neighbor:

r3#sh ip bgp neigh 162.1.0.4 adv
BGP table version is 10, local router ID is 150.1.3.3
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
*> 28.119.16.0/24   162.1.0.4                              0 100 54 i
*> 28.119.17.0/24   162.1.0.4                              0 100 54 i
*> 150.1.9.0/24     162.1.38.8                             0 65002 65034 i
*> 150.1.10.0/24    162.1.38.8                             0 65002 65034 i

*>i162.1.7.0/24     162.1.27.7               0    100      0 65001 i
*> 162.1.18.0/24    162.1.38.8               0             0 65002 i
*> 205.90.31.0      162.1.13.1                             0 200 254 ?
*> 220.20.3.0       162.1.13.1                             0 200 254 ?
*> 222.22.2.0       162.1.13.1                             0 200 254 ?

Total number of prefixes 9

r4#sh ip bgp neigh 162.1.0.3 routes
BGP table version is 20, local router ID is 150.1.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
*> 150.1.9.0/24     162.1.0.3                              0 300 i
*> 150.1.10.0/24    162.1.0.3                              0 300 i
*> 162.1.7.0/24     162.1.0.2                              0 300 i
*> 162.1.18.0/24    162.1.0.3                              0 300 i
*> 205.90.31.0      162.1.0.3                              0 300 200 254 ?
*> 220.20.3.0       162.1.0.3                              0 300 200 254 ?
*> 222.22.2.0       162.1.0.3                              0 300 200 254 ?

Total number of prefixes 7

4.3 BGP Filtering

Configure a new loopback interface on r5 and advertise it into BGP.  r4 should not pass this prefix on.  Configure this on r5.

Use the ‘no-advertise’ BGP community.

set community

(Optional) Well know communities can be specified by using the following keywords:

•internet
•local-as
•no-advertise
•no-export

ip prefix-list TASK_43 seq 5 permit 162.1.15.0/24
!
route-map TASK_43 permit 10
 match ip address prefix-list TASK_43
 set community no-advertise
!
route-map TASK_43 permit 1000
!
router bgp 500
 neighbor 150.1.4.4 send-community  <- don’t forget this line
 neighbor 150.1.4.4 route-map TASK_43 out

r4#sh ip bgp 162.1.15.0
BGP routing table entry for 162.1.15.0/24, version 22
Paths: (1 available, best #1, table Default-IP-Routing-Table, not advertised to any peer)
Flag: 0x880
  Not advertised to any peer 
  500
    150.1.5.5 (metric 66) from 150.1.5.5 (150.1.5.5)
      Origin IGP, metric 0, localpref 100, valid, external, best
      Community: no-advertise

IE used an as-path access-list matching ^$ instead of a prefix-list matching the network.  Both methods work, but the IE method would match any additional networks that you decide to advertise on r5 in the future.

4.4 BGP Table Stability

Pretty simple task using BGP dampening on routes learned from BB3 with the variables specified in the task.

bgp dampening

half-life: 15 minutes
reuse: 750
suppress: 2000
max-suppress-time: 4 times half-life

We are asked to set the max-suppress-time to 30 minutes.  This can be usually be done two ways.  Set the max-suppress-time to number of minutes specified, or set the half-life to 1/4 of that amount.  In this task we cannot use 1/4 of the max-suppress-time (30 minutes) for the half-life because it is not a whole number (7.5).

(Optional) Maximum time (in minutes) a route can be suppressed. The range is from 1 to 20000; the default is 4 times the half-life. If the half-life value is allowed to default, the maximum suppress time defaults to 60 minutes. When the max-suppress-time is configured, the maximum penalty will never be exceeded, regardless of the number of times that the prefix dampens. The maximum penalty is computed with the following formula:

Max penalty = reuse-limit *2^(maximum suppress time/half time)

I applied the dampening only to routes from AS 54:

r4(config)#ip as-path access-list 44 permit ^54$
r4(config)#route-map TASK_44 permit 10
r4(config-route-map)#match as-path 44
r4(config-route-map)#set dampening 15 1000 3000 30
r4(config-route-map)#router bgp 100
r4(config-router)#bgp dampening route-map TASK_44

The IE solution applied BGP dampening to all prefixes on r4???

Task 4.4

r4#sh ip bgp dampening parameters
 dampening 15 1000 3000 30 (route-map TASK_44 10)
  Half-life time      : 15 mins       Decay Time       : 370 secs
  Max suppress penalty:  4000         Max suppress time: 30 mins
  Suppress penalty    :  3000         Reuse penalty    : 1000

 

April 5, 2008

Internetwork Expert Volume II: Lab 6 – Section 4

Exterior Gateway Routing – 11 Points

4.1 BGP Peering

Easy task as there are not a lot of devices running BGP and all but one peering is on r6.

“All BGP traffic between r4 and r6 should traverse the VPN tunnel.”

Easy enough,  just make the neighbor addresses 191.1.46.x.  This also save me from configuring ‘ebgp multihop’ for the r4 <-> r6 peering.

4.2  BGP Bestpath Selection

Send all traffic for prefixes learned from AS 54 on r6 to BB1.  Don’t use local_pref.

What about weight?

Best Path Selection Table:

Attribute Direction Applied Traffic Flow Affected Prefer
Weight Inbound Outbound High
Local_Pref Inbound Outbound High
AS-Path Outbound Inbound Shortest
MED Outbound Inbound Lowest

Just set the weight from routes learned from BB1 to something greater than the default of 0 (IE used 100, I used 65000):

r6(config-router)#do sh ip bgp | i 54.1.3.254
*> 112.0.0.0        54.1.3.254               0         65000 54 50 60 i
*> 113.0.0.0        54.1.3.254               0         65000 54 50 60 i
*> 114.0.0.0        54.1.3.254               0         65000 54 i
*> 115.0.0.0        54.1.3.254               0         65000 54 i
*> 116.0.0.0        54.1.3.254               0         65000 54 i
*> 117.0.0.0        54.1.3.254               0         65000 54 i
*> 118.0.0.0        54.1.3.254               0         65000 54 i
*> 119.0.0.0        54.1.3.254               0         65000 54 i

4.3 BGP Filtering

Configure r6 so that AS 100 will not accept any prefixes from as 54 with a mask longer than /20.  Use a single-line prefix-list.

The prefix-list bit is easy:

r6(config)#ip prefix-list LESSTHANTWENTY perm 0.0.0.0/0 le 20

There’s a really nice breakdown on prefix-lists in general in the IE solution guide.

I was thrown off by the SET_WEIGHT route-map in the IE solution guide, but it’s same route-map name they used in the previous task (I had named mine ‘WEIGHT’) with an additional line.  So your final route-map should look similar to this:

route-map WEIGHT permit 10
 match ip address prefix-list LESSTHANTWENTY
 set weight 65000

task 4.3

4.4 BGP Summarization

Configure a summary of 191.1.0.0/16 and 150.1.0.0/20 but do not use aggregate-address.  You are allowed to use two static routes on r3 to accomplish this.

I had NO CLUE on this one.  I peeked the solution guide and then slapped my big, dumb forehead.  The ip routes are to NULL0.  You then redistribute the static routes.  DOH!!!

r3(config)#ip route 150.1.0.0 255.255.240.0 null0
r3(config)#ip route 191.1.0.0 255.255.0.0 null0
r3(config)#router bgp 200
r3(config-router)#redist static

r6#sh ip route bgp | i 150|191.1.
     191.1.0.0/16 is variably subnetted, 21 subnets, 4 masks
B       191.1.0.0/16 [20/0] via 204.12.1.3, 00:01:00         
     150.1.0.0/16 is variably subnetted, 10 subnets, 3 masks
B       150.1.0.0/20 [20/0] via 204.12.1.3, 00:01:00 

4.5 BGP Table Stability

Configure r6 to not advertise 112.0.0.0/8 and 113.0.0.0/8 if they are “consistently unstable.”

bgp dampening

Usage Guidelines
The bgp dampening command is used to enable BGP route dampening. This command can be entered without any arguments or keywords. The half-life, reuse, suppress, and max-suppress-time arguments are position-dependent; meaning that if any of these arguments are entered, then all optional arguments must be entered.

When BGP dampening is configured and a prefix is withdrawn, BGP considers the withdrawn prefix as a flap and increases the penalty by a 1000. If BGP receives an attribute change, BGP increases the penalty by 500. If then the prefix has been withdrawn, BGP keeps the prefix in the BGP table as a history entry. If the prefix has not been withdrawn by the neighbor and BGP is not using this prefix, the prefix is marked as dampened. Dampened prefixes are not used in the BGP decision process and not installed to the routing table.

router bgp 100
 bgp dampening route-map FLAPPERS
!
ip prefix-list FLAPPERS seq 5 permit 112.0.0.0/8
ip prefix-list FLAPPERS seq 10 permit 113.0.0.0/8
!
route-map FLAPPERS permit 10
 match ip address prefix-list FLAPPERS

I missed on important piece though:

r6(config-router)#
*Mar  6 18:15:27.386: %BGP-3-BADROUTEMAP: Bad parameters in the route-map FLAPPERS applied for Dampening

You MUST specify dampening parameters in the route map.  Just use the defaults:

Defaults
BGP dampening is disabled by default. The following values are used when this command is enabled without configuring any optional arguments:

half-life: 15 minutes
reuse: 750
suppress: 2000
max-suppress-time: 4 times half-life

r6(config-router)#route-map FLAPPERS perm 10
r6(config-route-map)#set dampening 15 750 2000 60

r6#sh ip bgp dampening parameters
 dampening 15 750 2000 60 (route-map FLAPPERS 10)
  Half-life time      : 15 mins       Decay Time       : 2320 secs
  Max suppress penalty: 12000         Max suppress time: 60 mins
  Suppress penalty    :  2000         Reuse penalty    : 750

 

April 4, 2008

Internetwork Expert Volume II: Lab 3 – Section 5

Exterior Gateway Routing – 16 Points

5.1 BGP Peering

This was an easy section but there were a lot of AS’s and peerings.  There are two separate AS 100.

Remember ebgp-multihop between r4 and r5.

There is no need for RR in area 100 (r1, r6, r3) as there is a full mesh.

I did miss ‘neigh 136.1.109.10 next-hop-self’ on sw3  ARGH!!!!

5.2 BGP FIltering

AS100 cannot be used a transit to reach AS54.  Configure this only on r6.

I tried to filter the traffic with an as-path access-list and a route map.  IE has a better solution: use the no-export community.

set community

(Optional) Well know communities can be specified by using the following keywords:

•internet
•local-as
•no-advertise
•no-export

r6(config-route-map)#set community ?
  <1-4294967295>  community number
  aa:nn           community number in aa:nn format
  additive        Add to the existing community
  internet        Internet (well-known community)
  local-AS        Do not send outside local AS (well-known community)
  no-advertise    Do not advertise to any peer (well-known community)
  no-export       Do not export to next AS (well-known community)
  <cr>

Nice break down of the BGP communities in the IE solution guide.  This is good because I am still shaky on BGP communities.

r3#sh ip bgp 114.0.0.0
BGP routing table entry for 114.0.0.0/8, version 25
Paths: (1 available, best #1, table Default-IP-Routing-Table, not advertised to EBGP peer)  <-
Flag: 0x880
  Advertised to update-groups:
     2
  54
    54.1.3.254 (metric 2560002816) from 136.1.136.6 (150.1.6.6)
      Origin IGP, metric 0, localpref 100, valid, internal, best
      Community: no-export

5.3 BGP Bestpath Selection

Advertise VLAN3 on r3 into BGP.  AS400 should route through AS300 to get to this prefix.  Do this configuration in AS100.

Best Path Selection Table:

Attribute Direction Applied Traffic Flow Affected Prefer
Weight Inbound Outbound High
Local_Pref Inbound Outbound High
AS-Path Outbound Inbound Shortest
MED Outbound Inbound Lowest

Before:
r5#sh ip bgp 136.1.3.0
BGP routing table entry for 136.1.3.0/24, version 27
Paths: (2 available, best #2, table Default-IP-Routing-Table)
  Advertised to update-groups:
     1          2
  300 100
    136.1.245.2 from 136.1.245.2 (150.1.2.2)
      Origin IGP, localpref 100, valid, external
  100
    136.1.15.1 from 136.1.15.1 (150.1.1.1)
      Origin IGP, localpref 100, valid, external, best

I went with MED….:-(

“To affect inbound traffic flow you must either prepend the AS-path attribute or set the MED value as the prefix is adveritised outside the AS.  However, since MED is only compared by default on prefixes learned from the SAME AS, AS-path prepending must be used in this case.”

ip prefix-list 53 seq 5 permit 136.1.3.0/24
!
route-map TASK_53_ASPATH permit 10
 match ip address prefix-list 53
 set as-path prepend 100 100
route-map TASK_53_ASPATH permit 1000
!
router bgp 100
 neigh 136.1.15.5 route-map TASK_53_ASPATH out

After:
r5#sh ip bgp 136.1.3.0
BGP routing table entry for 136.1.3.0/24, version 28
Paths: (2 available, best #2, table Default-IP-Routing-Table)
Flag: 0x820
  Advertised to update-groups:
     1          2
  100 100 100
    136.1.15.1 from 136.1.15.1 (150.1.1.1)
      Origin IGP, localpref 100, valid, external
  300 100
    136.1.245.2 from 136.1.245.2 (150.1.2.2)
      Origin IGP, localpref 100, valid, external, best

5.4 BGP Attribute Manipulation

Advertise VLAN 29  on r2.

r5 should see this:

r5#sh ip bgp | i 136.1.29.0|Net
   Network          Next Hop            Metric LocPrf Weight Path
*> 136.1.29.0/24    136.1.245.2                          100 300 i

Here’s what we currently see:

r5#sh ip bgp | i 136.1.29.0|Net
   Network          Next Hop            Metric LocPrf Weight Path
*  136.1.29.0/24    136.1.15.1                             0 100 300 i
*>                        136.1.245.2              0             0 300 i

I looks like we’re going to set the weight to 100 and filter the other route?

Attribute Direction Applied Traffic Flow Affected Prefer
Weight Inbound Outbound High
Local_Pref Inbound Outbound High
AS-Path Outbound Inbound Shortest
MED Outbound Inbound Lowest

bgp router 200
 neighbor 136.1.245.2 route-map TASK_54_WEIGHT in
!
ip prefix-list 54 seq 5 permit 136.1.29.0/24
!
route-map TASK_54_WEIGHT permit 10
 match ip address prefix-list 54
 set weight 100
route-map TASK_54_WEIGHT permit 1000

Hmmm….not quite what I got.

   Network          Next Hop            Metric LocPrf Weight Path

*  136.1.29.0/24    136.1.15.1                             0 100 300 i  <-not shown in IE
*>                             136.1.245.2              0           100 300 i

IE solution was the same as mine…kinda bad question.

5.5 BGP Bestpath Selection

YIKES!!!!

Nice breakdown though.

r2#sh ip bgp neigh 136.1.245.5 | i Cond
  Condition-map NON_EXIST, Advertise-map ADVERTISE, status: Withdraw

5.6 BGP AS Path

Advertise the EtherChannel subnet on sw3 into BGP.  Make sure that r3 and sw3 will accept BGP updates with AS100 in the AS-path.  Don’t alter r2’s configuration to accomplish this.

This is where our two AS100’s come back to haunt us.

neighbor allowas-in

March 27, 2008

Cool Command 2: Verify Your BGP Regular Expressions

Here’s a great command for verifying (or just practicing) your BGP regular expression filters.  In the example below, I want to only see the routes where AS54 is the last AS in the AS path*.  I’m pretty sure that my regular expression is correct, but I want to verify it by running it against my BGP database.

Here’s the full BGP database:

r6(config)#do sh ip bgp | 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
*> 112.0.0.0        54.1.3.254               0             0 54 50 60 i
*> 113.0.0.0        54.1.3.254               0             0 54 50 60 i
*> 114.0.0.0        54.1.3.254               0             0 54 i
*> 115.0.0.0        54.1.3.254               0             0 54 i
*> 116.0.0.0        54.1.3.254               0             0 54 i
*> 117.0.0.0        54.1.3.254               0             0 54 i
*> 118.0.0.0        54.1.3.254               0             0 54 i
*> 119.0.0.0        54.1.3.254               0             0 54 i
*> 205.90.31.0      204.12.1.3                             0 200 254 ?
*> 220.20.3.0       204.12.1.3                             0 200 254 ?
*> 222.22.2.0       204.12.1.3                             0 200 254 ?

Here’s the results of filtering with ^54_ :

r6(config)#do sh ip bgp regex ^54_
BGP table version is 14, local router ID is 150.1.6.6
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
*> 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
*> 112.0.0.0        54.1.3.254               0             0 54 50 60 i
*> 113.0.0.0        54.1.3.254               0             0 54 50 60 i
*> 114.0.0.0        54.1.3.254               0             0 54 i
*> 115.0.0.0        54.1.3.254               0             0 54 i
*> 116.0.0.0        54.1.3.254               0             0 54 i
*> 117.0.0.0        54.1.3.254               0             0 54 i
*> 118.0.0.0        54.1.3.254               0             0 54 i
*> 119.0.0.0        54.1.3.254               0             0 54 i

show ip bgp regexp

*Thanks to apep for the correction.  See comment section for details.

Next Page »

Blog at WordPress.com.