CCIE Pursuit Blog

August 14, 2008

Internetwork Expert Volume II: Lab 12 – Section 5

Section 5 – Exterior Gateway Routing – 20 Points

5.1 BGP Peering
5.2 BGP Route Reflection
5.3 BGP Origination

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

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

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

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

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

5.4 BGP Bestpath Selection

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

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

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

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

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

sw1:

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

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

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

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

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

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

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

Our route-map now looks like this:

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

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

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

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

Next we need to make meet the last requirement:

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

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

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

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

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

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

Verification:

Rack16R6#trace 129.16.3.3

Type escape sequence to abort.
Tracing the route to 129.16.3.3

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

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

Rack16R6#trace 129.16.3.133

Type escape sequence to abort.
Tracing the route to 129.16.3.133

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

Note that the route via r2 is not available:

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

5.5 BGP Filtering

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

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

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

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

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

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

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

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

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

Do the same on sw1:

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

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

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

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

Rack16SW2#trace 222.22.2.1

Type escape sequence to abort.
Tracing the route to 222.22.2.1

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

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

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

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

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

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

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

5.6 BGP Default Routing

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

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

default-information originate (BGP)

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

neighbor default-originate

Before:

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

Total number of prefixes 13

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

After:

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

Total number of prefixes 14

5.7 BGP Default Routing

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

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

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

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

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

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

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

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

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

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

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

Verify:

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

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

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

5.8 BGP Bestpath Selection

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

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

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

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

Here’s what I came up with:

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

This seemed to work:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

5.9 BGP Bestpath Selection

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

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

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

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

5.10 BGP Aggregation

Last BGP task!!!

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

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

Rack16R2(config-router)#net 150.16.0.0 mask 255.255.0.0

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

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

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

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

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

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

On r2:

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

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

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

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

IE method (sans loopback advertisement):

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

Total number of prefixes 7

My method:

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

Total number of prefixes 7

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

I’ll revisit this later.

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 12, 2008

Internetwork Expert Volume III: Lab 5 – Section 5

Exterior Gateway Routing – 7 Points

5.1 BGP Peerings

IE solution is missing the peerings r4-sw3 and r4-sw4.

5.2 BGP Path Manipulation

“Using local-preference within AS 200, ensure that r4 is used as the exit point for all BGP prefixes learned from AS 100.”

To affect OUTBOUND routing (weight and local_pref) we will create a route-map and apply it INBOUND.

r4:
route-map LOCAL_PREF permit 10
 set local-preference 1000
!
router bgp 200
 neighbor 128.1.14.1 route-map LOCAL_PREF in

“AS 100 should use r5 as the entyr point for any routes advertised by AS 200.”

Basically the same thing as the first task, but configured on the peering between r1 (AS 100) and r5 (AS 200):

r1(config)#route-map LOCAL_PREF perm 10
r1(config-route-map)#set local-pre 1000
r1(config-route-map)#router bgp 100
r1(config-router)#neigh 128.1.125.5 route-map LOCAL_PREF in

5.3 Redistribution

“Redistribute sw2’s lo0 network (150.1.8.0/24) into EIGRP on r4.”
“Do not redistribute any other BGP routes into EIGRP.”

Yuck.

I really screwed this task up.  Here’s the IE solution:

ip prefix-list SW2_LOOPBACK seq 5 permit 150.1.8.0/24
!
route-map BGP->EIGRP permit 10
 match ip address prefix-list SW2_LOOPBACK
!
router eigrp 10
 redistribute bgp 200 metric 1 1 1 1 1 route-map BGP->EIGRP
!
router bgp 200
 bgp redistribute-internal

I did everything except “bgp redistribute-internal”

bgp redistribute-internal

Usage Guidelines
The bgp redistribute-internal command is used to configure iBGP redistribution into an IGP. The clear ip bgp command must be entered to reset BGP connections after this command is configured.

When redistributing BGP into any IGP, be sure to use IP prefix-list and route-map statements to limit the number of prefixes that are redistributed.

 

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

January 27, 2008

Internetwork Expert Volume III: Lab 4 – Section 5

Exterior Gateway Routing – 6 Points

5.1 BGP Peerings

This was a pretty easy BGP peering task.  You need to set up a confederation, so you’ll need to be familiar with:

bgp confederation identifier

bgp confederation peers

I did mess up a little bit. I configured “neighbor 150.1.5.5 ebgp-multihop” on r4.

r4 (AS 100) <— r6 (no BGP) —> bb1 (AS 54)

It turns out that I don’t need this command because r6 is bridging, not routing.

neighbor ebgp-multihop

I also missed “neighbor 152.1.37.3 next-hop-self” on sw1, but I did eventually catch that error when I found that I was not installing the bb2 routes on r3:

Without “neighbor 152.1.37.3 next-hop-self” on sw1:

r3#sh ip route bgp
B    119.0.0.0/8 [200/0] via 152.1.125.5, 00:28:44
B    118.0.0.0/8 [200/0] via 152.1.125.5, 00:28:44
B    117.0.0.0/8 [200/0] via 152.1.125.5, 00:28:44
B    116.0.0.0/8 [200/0] via 152.1.125.5, 00:28:44
B    115.0.0.0/8 [200/0] via 152.1.125.5, 00:28:44
B    114.0.0.0/8 [200/0] via 152.1.125.5, 00:28:44
B    113.0.0.0/8 [200/0] via 152.1.125.5, 00:28:44
B    112.0.0.0/8 [200/0] via 152.1.125.5, 00:28:44

r3#sh ip bgp | i Network|192.10.1.254
   Network          Next Hop            Metric LocPrf Weight Path
*  205.90.31.0      192.10.1.254             0    100      0 (7000) 254 ?
220.20.3.0       192.10.1.254             0    100      0 (7000) 254 ?
*  222.22.2.0       192.10.1.254             0    100      0 (7000) 254 ?

r3#sh ip route 192.10.1.254
% Network not in table

With “neighbor 152.1.37.3 next-hop-self” on sw1:

r3#sh ip route bgp
B    119.0.0.0/8 [200/0] via 152.1.125.5, 00:30:15
B    118.0.0.0/8 [200/0] via 152.1.125.5, 00:30:15
B    222.22.2.0/24 [200/0] via 152.1.37.7, 00:00:15
B    117.0.0.0/8 [200/0] via 152.1.125.5, 00:30:15
B    220.20.3.0/24 [200/0] via 152.1.37.7, 00:00:15
B    116.0.0.0/8 [200/0] via 152.1.125.5, 00:30:15
B    115.0.0.0/8 [200/0] via 152.1.125.5, 00:30:15
B    114.0.0.0/8 [200/0] via 152.1.125.5, 00:30:15
B    113.0.0.0/8 [200/0] via 152.1.125.5, 00:30:15
B    112.0.0.0/8 [200/0] via 152.1.125.5, 00:30:15
B    205.90.31.0/24 [200/0] via 152.1.37.7, 00:00:15

r3#sh ip bgp | i Network|152.1.37.7
   Network          Next Hop            Metric LocPrf Weight Path
*> 205.90.31.0      152.1.37.7               0    100      0 (7000) 254 ?
*> 220.20.3.0       152.1.37.7               0    100      0 (7000) 254 ?
*> 222.22.2.0       152.1.37.7               0    100      0 (7000) 254 ?

r3#sh ip route 152.1.37.7
Routing entry for 152.1.37.0/24
  Known via “connected”, distance 0, metric 0 (connected, via interface)
  Routing Descriptor Blocks:
  * directly connected, via FastEthernet0/0
      Route metric is 0, traffic share count is 1

5.2 BGP Bestpath Selection

“Configure the network so that AS 100 routes through r1 to reach prefixes originated in AS 254.”
“Use MED to accomplish this.”

set metric (BGP, OSPF, RIP)

I had the right idea for this task, but I boned it up.  IE used an aggregate-address on sw1 to ensure reachability to all networks advertised by the backbone routers.  They have a short writeup to explain their method.

aggregate-address

I REALLY need to study BGP some more.

January 19, 2008

Internetwork Expert Volume II: Lab 4 – Section 11

Exterior Gateway Routing – 8 Points

11.1 BGP Peering

“The BGP peering session between r4 and r5 should remain up if r4 loses both the frame Relay and Ethernet segments to r5.”

Peer loopbacks between r4 and r5.  These routers have 3 connections between them, so if the Frame and Ethernet drop, the PTP connection will kick in.  Remember to configure ‘ebgp-multihop’ when peering loopbacks.

11.2 BGP Filtering

You need to configure r6 so that it is only advertising the routes shown in a command output to r2.

“Do not use communities, IP access-lists, or prefix-list filtering to accomplish this.”

From my output I need to filter the following routes:

*> 205.90.31.0      141.1.123.2                            0 200 254 ?
*> 220.20.3.0       141.1.123.2                            0 200 254 ?
*> 222.22.2.0       141.1.123.2                            0 200 254 ?

I should be able to filter on as path for these networks based on as_path.  Or does that count as an “ip access-list”?  IE solution guide says “go ahead”.  🙂

ip as-path access-list

r6(config)#ip as-path access-list 71 permit _54$
r6(config)#router bgp 100
r6(config-router)#neigh 141.1.123.2 filter-list 71 out
r6(config-router)#do sh ip bgp neigh 141.1.123.2 adv | b Network
Network          Next Hop            Metric LocPrf Weight Path
*> 112.0.0.0        54.1.1.254               0             0 54 50 60 i
*> 113.0.0.0        54.1.1.254               0             0 54 50 60 i
*> 114.0.0.0        54.1.1.254               0             0 54 i
*> 115.0.0.0        54.1.1.254               0             0 54 i
*> 116.0.0.0        54.1.1.254               0             0 54 i
*> 117.0.0.0        54.1.1.254               0             0 54 i
*> 118.0.0.0        54.1.1.254               0             0 54 i
*> 119.0.0.0        54.1.1.254               0             0 54 i

I think that there is a typo in the output because there are routes from bb3 present, but we are not peering with bb3 in this lab:

bb3#sh ip bgp | b Network
 Network          Next Hop            Metric LocPrf Weight Path
*> 28.119.16.0/24   0.0.0.0                  0         32768 i
*> 28.119.17.0/24   0.0.0.0                  0         32768 i

11.2 BGP filtering – typo?

Or is it a typo?  According to this port bb3 should peer with bb1 and then pass the routes to r6? 

Task 11.2

I’m just going to ignore those routes.  I don’t have a peering between bb1 and bb3 in my lab.

11.3 BGP Connectivity

I hit the wall on this task.  I’ll have to come back and revisit it as I was so wiped from labbing that I just couldn’t handle mucking about with BGP redistribution.  😦

January 1, 2008

Internetwork Expert Volume III: Lab 3 – Section 5

5 Exterior Gateway Routing

5.1 BGP Peerings

This task started out looking very straight-forward, then took an ugly turn.  😦

“All devices running BGP should have reachability to all BGP learned prefixes.”
“Don’t use tunnelling to accomplish this.”

This seemed really simple.  I set up my peerings and all of the BGP learned routes were valid best routes.

I had problems with the routes learned from the backbone routers:

r3#p 113.0.0.1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 113.0.0.1, timeout is 2 seconds:
U.U.U
Success rate is 0 percent (0/5)
r3#trace 113.0.0.1

Type escape sequence to abort.
Tracing the route to 113.0.0.1

  1 190.1.135.532 msec 32 msec 28 msec
  2 190.1.135.5 !H  *  !H

I didn’t read enough into this question as “all devices running BGP” means ALL devices not just my devices.  Since the backbones are running BGP, I need to ensure that they have full reachability as well.

I threw in the towel here.  I reallyneed to review BGP.  Luckily, the answer guide has a breakdown for this task (the only breakdown in the guide).  It had a lot of good information, but I am still lacking in my BGP skills.

5.2 BGP Summarization

You are asked to summarize 112.0.0.0/8 – 119.0.0.0/8 into a single advertisement without overlapping any other networks.

This is a case where you can quickly whip this up by utilizing the Windows Calculator in scientific mode. [You are allowed to use the Windows calculator in the CCIE lab.]

1) Open the Microsoft calculator (you can search for it in Programs or just type ‘calc’ in Start->Run).
2) Click ‘View’.  Make sure that that calculator is in ‘scientific’ mode.
3) Dec (decimal) should be selected.  Key in 112.
4) Now select Bin (binary).  You should get 1110000
5) Switch back to Dec and do the same for 119.  You should get 1110111

You want to summarize at the point where the bits no longer match

112  – 01110|000
119  – 01110|111

So your summarization will be 112.0.0.0/5 or 112.0.0.0 with a mask of 248.0.0.0.  Now it’s just a simple matter of using “aggregate-address” to advertise the summary:

aggregate-address  

router bgp 100
 aggregate-address 112.0.0.0 248.0.0.0

The IE answer key introduced me to a cool new verification command:

show ip bgp cidr-only

r6#sh ip bgp cidr-only
BGP table version is 30, local router ID is 150.11.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   54.11.1.254                            0 54 i
*> 28.119.17.0/24   54.11.1.254                            0 54 i
*> 112.0.0.0/5      0.0.0.0                            32768 i
s> 190.11.0.0/24    0.0.0.0                  0         32768 i

Blog at WordPress.com.