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.
CCIE Pursuit Blog 