From the blog.

Managing Digital Racket
The more I tune out, the less I miss it. But that has presented me with some complex choices for a nuanced approach to curb
Complexity – My Friend, My Enemy
Over my years of network engineering, I've learned that the fewer features you can implement while still achieving a business goal, the better. Why? Fewer

Soup-To-Nuts BGP Labs 1-5 – Dual Route Reflectors + Conditional Advsertisements + BGP Dampening + Aggregates

941 Words. Plan about 6 minute(s) to read this.

I spent some time with Narbik Kocharians’ Soup-To-Nuts BGP labs today. There are 15 small BGP labs, each focusing on a specific BGP feature. Here’s a few notes from my work today.

Lab 1 – I don’t know why, but it never registered with me to be concerned about BGP’s auto summarization capability.

Lab 2 – When configuring dual route reflectors for redundancy, remember that the route-reflectors should be peered with one another. I also was playing with the BGP cluster ID, although Narbik doesn’t discuss it in this lab. I found that the BGP cluster ID is very obvious when you do a “show ip bgp xx.xx.xx.xx”, so it’s easy to tell which route reflector advertised a particular prefix.

Lab 3 – I sort of knew how advertise-maps worked before, but I have a better idea now. A BGP advertise-map is a way to conditionally advertise a list of prefixes to a neighbor, depending on whether or not some other prefix is present in the table. Before this lab, I was under the false impression that an advertise-map contained everything that would get advertised to a neighbor – kind of like a conditional distribute list. Not so. An advertise-map only affects the prefixes defined in the advertise-map route-map. Prefixes that aren’t listed in the advertise-map route-map aren’t impacted one way or the other.

Take a look at this code example. Here, we see first that R3 is seeing prefix 1.0.0.0/8, along with other prefixes, advertised from R1. Then we add the advertise-map to R1. The advertise-map says to advertise everything in route-map ADVERTISE (1.0.0.0/8), if the prefixes in route-map CONDITIONAL (2.0.0.0/8) do not exist. If CONDITIONAL does exist, then the prefixes in route-map ADVERTISE will with be withdrawn.

R3#show ip bgp
BGP table version is 9, local router ID is 150.1.2.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
*> 1.0.0.0 131.1.13.1 0 0 100 i
*> 2.0.0.0 131.1.13.1 0 100 200 i
*> 3.0.0.0 0.0.0.0 0 32768 i
*> 131.1.12.0/24 131.1.13.1 0 0 100 i
r> 131.1.13.0/24 131.1.13.1 0 0 100 i
R3#

R1#show run | s prefix-list
ip prefix-list ONE seq 5 permit 1.0.0.0/8
ip prefix-list TWO seq 5 permit 2.0.0.0/8

R1#show run | s route-map
route-map ADVERTISE permit 10
match ip address prefix-list ONE
route-map CONDITIONAL permit 10
match ip address prefix-list TWO

R1#show run | s bgp
router bgp 100
network 1.0.0.0
network 131.1.12.0 mask 255.255.255.0
network 131.1.13.0 mask 255.255.255.0
neighbor 131.1.12.2 remote-as 200
neighbor 131.1.13.3 remote-as 300
neighbor 131.1.13.3 advertise-map ADVERTISE non-exist-map CONDITIONAL
no auto-summary

R3#show ip bgp
BGP table version is 10, local router ID is 150.1.2.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
*> 2.0.0.0 131.1.13.1 0 100 200 i
*> 3.0.0.0 0.0.0.0 0 32768 i
*> 131.1.12.0/24 131.1.13.1 0 0 100 i
r> 131.1.13.0/24 131.1.13.1 0 0 100 i
R3#

One other really important note on this. The 1.0.0.0/8 prefix was not withdrawn instantly when I applied the advertise-map on R1. I didn’t time it exactly, but it took around a minute before 1.0.0.0/8 was no longer seen by R3. This is one of those features where you have to be a little patient when verifying your work. The same thing when I removed the advertise-map from R1: 1.0.0.0/8 took about a minute to show back up in R3’s BGP table.

Lab 4 – You can set BGP dampening on a per route-basis with a route-map. This I did not know. I had run into dampening before, but only to enable it and tweak the parameters. I hadn’t actually written a route-map that would allow unique dampening characteristics per-prefix.

Lab 5 – This lab covered aggregate routes. One issue presented was how to make sure an aggregate route is not received by an AS from which some of the component routes originate. Let’s say you’ve got AS100 connecting to AS200 connecting to AS300 in a line. AS100 and AS300 are not peered. Now let’s say you’re doing summarization in AS200 for routes in AS300. You want the aggregate route to show up in AS100, but not AS300. How do you stop the aggregate from showing up in the AS300 BGP table? By setting the AS path of the aggregate so that it looks like it originated in AS300. When the aggregate prefix is advertised to AS300, AS300 will reject it since BGP won’t accept routes that appear to originate from its own AS to prevent loops. You can manipulate the AS path of an aggregate route using the “aggregate address xx.xx.xx.xx xx.xx.xx.xx summary-only as-path advertise-map MAP-NAME”, where MAP-NAME refers to a route-map that will define the AS path components to be used for the aggregate.

R2#show ip as-path 300
AS path access list 300
permit ^300
R2#show run | s route-map SETPATH
route-map SETPATH permit 10
match as-path 300

R2#show run | s router bgp
router bgp 200
no synchronization
bgp log-neighbor-changes
network 2.0.0.0
aggregate-address 3.1.0.0 255.255.0.0 as-set summary-only advertise-map SETPATH
neighbor 131.1.12.1 remote-as 100
neighbor 131.1.23.3 remote-as 300
no auto-summary

R2#show ip bgp
BGP table version is 63, local router ID is 2.2.3.2
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
*> 2.0.0.0 0.0.0.0 0 32768 i
s> 3.1.0.0/24 131.1.12.1 0 0 100 i
*> 3.1.0.0/16 0.0.0.0 100 32768 300 i
s> 3.1.1.0/24 131.1.23.3 0 0 300 i
s> 3.1.2.0/24 131.1.23.3 0 0 300 i
s> 3.1.3.0/24 131.1.23.3 0 0 300 i
s> 3.1.4.0/24 131.1.23.3 0 0 300 i

You can select on a per-neighbor basis to unsuppress prefixes that were suppressed by the aggregate-address “summary-only” keyword using neighbor unsuppress-map. Alternatively, you could globally change which routes are suppressed by the aggregate-address command using the “suppress-map” keyword. Note that when I applied and unsuppress-map to a neighbor, it took perhaps a minutes before the newly unsuppressed prefix showed up in the BGP table.