ip prefix-list Lo1 seq 5 permit 1.2.3.4/32
route-map To_R3 permit 10
match ip address prefix-list Lo1
set metric 1000
route-map To_R3 permit 20
router bgp 100
neighbor 155.1.13.3 remote-as 200
neighbor 155.1.13.3 route-map To_R3 out
And now AS300
ip prefix-list Lo1 seq 5 permit 1.2.3.4/32
route-map To_R3 permit 10
match ip address prefix-list Lo1
set metric 100
route-map To_R3 permit 20
router bgp 300
neighbor 155.1.37.3 remote-as 200
neighbor 155.1.37.3 route-map To_R3 out
Poof! Everything worked! Yay! I just need to wrap my head around this. It's not difficult, it just necessary to be consistent and configure all pertinent routers. Phew. Moving on....
DMZ Link bandwidth is another of those topics that is not difficult to understand or implement. It's just a matter of putting all the pieces together. First, you need to enable dmz-link bw under both the BGP process and for the ebgp neighbors.
R6(config-router)#router bgp 100
R6(config-router)#nei 54.1.1.254 remote-as 54
R6(config-router)#nei 54.1.1.254 dmzlink-bw
R6(config-router)#bgp dmzlink-bw
That was easy enough - but you need to understand how this works. BGP inserts the bandwidth into an extended community to send to it's neighbors. So that means we need to enable send-community to our iBGP neighbors within the relevant AS.
R6(config-router)#router bgp 100
R6(config-router)#nei 155.1.146.1 send-comm ext
Ok, now we should be collecting bandwidth and sending the data to our peers. BGP does not by default load balance across unequal paths. So now we need to enable that within our AS.
R1(config-router)#router bgp 100
R1(config-router)#maximum-paths ibgp 2
Now we will load-balance across unequal paths within AS 100 based on bandwidth to links in AS54. So now if we view our routes in AS100, we will see multiple paths.
R1(config-router)#do sh ip route | i 204.12.1.254|54.1.1.254
B 119.0.0.0/8 [200/0] via 204.12.1.254, 00:06:06
[200/0] via 54.1.1.254, 00:06:06
B 118.0.0.0/8 [200/0] via 204.12.1.254, 00:06:07
[200/0] via 54.1.1.254, 00:06:07
B 117.0.0.0/8 [200/0] via 204.12.1.254, 00:06:07
[200/0] via 54.1.1.254, 00:06:07
B 116.0.0.0/8 [200/0] via 204.12.1.254, 00:06:07
[200/0] via 54.1.1.254, 00:06:07
B 115.0.0.0/8 [200/0] via 204.12.1.254, 00:06:07
[200/0] via 54.1.1.254, 00:06:07
B 114.0.0.0/8 [200/0] via 204.12.1.254, 00:06:07
[200/0] via 54.1.1.254, 00:06:07
B 113.0.0.0/8 [200/0] via 204.12.1.254, 00:06:07
[200/0] via 54.1.1.254, 00:06:07
B 112.0.0.0/8 [200/0] via 204.12.1.254, 00:06:07
[200/0] via 54.1.1.254, 00:06:07
B 28.119.17.0 [200/0] via 204.12.1.254, 00:06:07
[200/0] via 54.1.1.254, 00:06:07
B 28.119.16.0 [200/0] via 204.12.1.254, 00:06:07
[200/0] via 54.1.1.254, 00:06:07
Take notice that this affects the routing table and not the BGP table as BGP will always select a best route over all available paths, but you will see multipath in the route details.
R1(config-router)#do sh ip bgp 28.119.16.0
BGP routing table entry for 28.119.16.0/24, version 47
Paths: (2 available, best #2, table Default-IP-Routing-Table)
Multipath: eBGP iBGP
Advertised to update-groups:
1 2
54, (Received from a RR-client)
54.1.1.254 (metric 2560002816) from 155.1.146.6 (150.1.6.6)
Origin IGP, metric 0, localpref 100, valid, internal, multipath
DMZ-Link Bw 250 kbytes
54, (Received from a RR-client)
204.12.1.254 (metric 2560002816) from 155.1.146.4 (150.1.4.4)
Origin IGP, metric 0, localpref 100, valid, internal, multipath, best
DMZ-Link Bw 12500 kbytes
If you see something in a scenario saying you should only accept routes from directly connected ASes, but you can't use AS-Path filtering, it is a simple command. This is where having exposure to every detail of a protocol will help you.
router bgp 100
bgp maxas-limit 1
You can selectively delete communities received from a neighbor, while still adding your own. First you create an expanded community list, using regex to match the communities you want to delete. Here, we are matching any community that starts with 200:
SW1(config)#ip community-list expanded TST permit 200:[0-9]+_
Now create a route-map, add any communities you would like to add in this AS, and then delete the selected communities and apply the route-map.
SW1(config)#route-map SetComm permit 10
SW1(config)# set comm-list TST delete
SW1(config)# set community 300:200 additive
SW1(config)#router bgp 300
SW1(config-router)#nei 155.1.37.3 send-comm both
SW1(config-router)#nei 155.1.37.3 route-map SetComm in
Here is the end result.
SW1(config)#do sh ip bgp 222.22.2.0
BGP routing table entry for 222.22.2.0/24, version 80
Paths: (1 available, best #1, table Default-IP-Routing-Table)
Flag: 0x880
Advertised to update-groups:
1 2
200 254
155.1.37.3 from 155.1.37.3 (150.1.3.3)
Origin incomplete, localpref 100, valid, external, best
Community: 254:100 300:200
For comparison, here is the same route from R2 in AS200 (which send routes to SW1) and from R6 in AS100 (which SW1 send routes to).
R2(config)#do sh ip bgp 222.22.2.0
BGP routing table entry for 222.22.2.0/24, version 99
Paths: (1 available, best #1, table Default-IP-Routing-Table)
Advertised to update-groups:
2
254
192.10.1.254 from 192.10.1.254 (222.22.2.1)
Origin incomplete, metric 0, localpref 100, valid, external, best
Community: 200:123 200:254 254:100
R6(config)#do sh ip bgp 222.22.2.0
BGP routing table entry for 222.22.2.0/24, version 48
Paths: (2 available, best #1, table Default-IP-Routing-Table, Advertisements suppressed by an aggregate.)
Flag: 0x880
Not advertised to any peer
(65014) 200 254
155.1.13.3 (metric 27260160) from 155.1.146.1 (150.1.1.1)
Origin incomplete, metric 0, localpref 100, valid, confed-external, best
Community: 200:123 200:254 254:100
300 200 254
155.1.67.7 from 155.1.67.7 (150.1.77.77)
Origin incomplete, localpref 100, valid, external
Community: 254:100 300:200
Another fun scenario was using extended access-lists to match a range of subnets, something that would be much simpler with prefix-lists, but alas, can also be accomplished with extended access-lists. In short, the source in your access-list would be what to match in the network, with the destination matching the subnet mask.
R4(config)#access-list 104 deny 0.0.1.0 255.255.254.0 255.255.252.0 0.0.3.255
R4(config)#access-list 104 permit ip any any
This would deny any route with an odd third octet, with a /22 mask or larger up to a /24. I already know how to match networks based on access-lists, but matching the masks with an access-list is something new. Looking at it, it makes total sense, but something I need to see a few more times to really get a handle on.
Moving on, I stumbled across bgp dampening. Something I always though was pretty easy, but INE presents it differently. "Once a prefix flaps two times in a row, the advertisement should resume in 5 minutes". Most scenarios will specify the actual dampening parameters. Here is the actual formula:
P (t) = P (0) /2^(t/Half_life)
We know that the time we want is 5 minutes.
P(5) = P(0)/2^(5/Half_life)
Now substitute P(5) = 750 (the reuse limit) and P(0) = 2000 (suppress limit). The equation becomes:
200/750=2^(5/Half_life)
From this equation, take the logarithm of the both sides.
Half_life=5*Ln(2)/Ln(200/75) = 3.5 (approx.)
We may now round up to 4. Max suppress time is by default 4 x half_life, giving us the following:
router bgp 200
bgp dampening 4 750 2000 16
Wow. Am I the only one lost? It's been a number of years since I've taken an advanced math class, so I'm guessing that is why I am lost. I'll review this again later, but I would hope Cisco doesn't expect all candidates to be up on advanced math.
The default bgp scanner time is 60 seconds. Keepalive is defaulted to 60 seconds with the holdtime being 180. The BGP scanner is responsible checking validity and reachability of BGP NEXT_HOP attributes, performs conditional advertisement and route injection, imports new routes into BGP table from RIB and performs route dampening. If you receive a scenario to configure BGP to do route injection every 20 seconds, you will need to alter the BGP scan time. Also, setting the advertisement-interval to 0 will remove batch updates and advertise immediately.
You can adjust the bgp next-hop trigger timers. Remember the BGP scan time is responsible for validity and reachability of the NEXT_HOP attributes. If we use the next-hop trigger timers, we can tune this to be more in line with IGP timers.
That finally wraps up BGP. This took me a while, but I wanted to take my time going through BGP, knowing that it is one of my weaknesses. More to come later from Vol 1.....
DMZ Link bandwidth is another of those topics that is not difficult to understand or implement. It's just a matter of putting all the pieces together. First, you need to enable dmz-link bw under both the BGP process and for the ebgp neighbors.
R6(config-router)#router bgp 100
R6(config-router)#nei 54.1.1.254 remote-as 54
R6(config-router)#nei 54.1.1.254 dmzlink-bw
R6(config-router)#bgp dmzlink-bw
That was easy enough - but you need to understand how this works. BGP inserts the bandwidth into an extended community to send to it's neighbors. So that means we need to enable send-community to our iBGP neighbors within the relevant AS.
R6(config-router)#router bgp 100
R6(config-router)#nei 155.1.146.1 send-comm ext
Ok, now we should be collecting bandwidth and sending the data to our peers. BGP does not by default load balance across unequal paths. So now we need to enable that within our AS.
R1(config-router)#router bgp 100
R1(config-router)#maximum-paths ibgp 2
Now we will load-balance across unequal paths within AS 100 based on bandwidth to links in AS54. So now if we view our routes in AS100, we will see multiple paths.
R1(config-router)#do sh ip route | i 204.12.1.254|54.1.1.254
B 119.0.0.0/8 [200/0] via 204.12.1.254, 00:06:06
[200/0] via 54.1.1.254, 00:06:06
B 118.0.0.0/8 [200/0] via 204.12.1.254, 00:06:07
[200/0] via 54.1.1.254, 00:06:07
B 117.0.0.0/8 [200/0] via 204.12.1.254, 00:06:07
[200/0] via 54.1.1.254, 00:06:07
B 116.0.0.0/8 [200/0] via 204.12.1.254, 00:06:07
[200/0] via 54.1.1.254, 00:06:07
B 115.0.0.0/8 [200/0] via 204.12.1.254, 00:06:07
[200/0] via 54.1.1.254, 00:06:07
B 114.0.0.0/8 [200/0] via 204.12.1.254, 00:06:07
[200/0] via 54.1.1.254, 00:06:07
B 113.0.0.0/8 [200/0] via 204.12.1.254, 00:06:07
[200/0] via 54.1.1.254, 00:06:07
B 112.0.0.0/8 [200/0] via 204.12.1.254, 00:06:07
[200/0] via 54.1.1.254, 00:06:07
B 28.119.17.0 [200/0] via 204.12.1.254, 00:06:07
[200/0] via 54.1.1.254, 00:06:07
B 28.119.16.0 [200/0] via 204.12.1.254, 00:06:07
[200/0] via 54.1.1.254, 00:06:07
Take notice that this affects the routing table and not the BGP table as BGP will always select a best route over all available paths, but you will see multipath in the route details.
R1(config-router)#do sh ip bgp 28.119.16.0
BGP routing table entry for 28.119.16.0/24, version 47
Paths: (2 available, best #2, table Default-IP-Routing-Table)
Multipath: eBGP iBGP
Advertised to update-groups:
1 2
54, (Received from a RR-client)
54.1.1.254 (metric 2560002816) from 155.1.146.6 (150.1.6.6)
Origin IGP, metric 0, localpref 100, valid, internal, multipath
DMZ-Link Bw 250 kbytes
54, (Received from a RR-client)
204.12.1.254 (metric 2560002816) from 155.1.146.4 (150.1.4.4)
Origin IGP, metric 0, localpref 100, valid, internal, multipath, best
DMZ-Link Bw 12500 kbytes
If you see something in a scenario saying you should only accept routes from directly connected ASes, but you can't use AS-Path filtering, it is a simple command. This is where having exposure to every detail of a protocol will help you.
router bgp 100
bgp maxas-limit 1
You can selectively delete communities received from a neighbor, while still adding your own. First you create an expanded community list, using regex to match the communities you want to delete. Here, we are matching any community that starts with 200:
SW1(config)#ip community-list expanded TST permit 200:[0-9]+_
Now create a route-map, add any communities you would like to add in this AS, and then delete the selected communities and apply the route-map.
SW1(config)#route-map SetComm permit 10
SW1(config)# set comm-list TST delete
SW1(config)# set community 300:200 additive
SW1(config)#router bgp 300
SW1(config-router)#nei 155.1.37.3 send-comm both
SW1(config-router)#nei 155.1.37.3 route-map SetComm in
Here is the end result.
SW1(config)#do sh ip bgp 222.22.2.0
BGP routing table entry for 222.22.2.0/24, version 80
Paths: (1 available, best #1, table Default-IP-Routing-Table)
Flag: 0x880
Advertised to update-groups:
1 2
200 254
155.1.37.3 from 155.1.37.3 (150.1.3.3)
Origin incomplete, localpref 100, valid, external, best
Community: 254:100 300:200
For comparison, here is the same route from R2 in AS200 (which send routes to SW1) and from R6 in AS100 (which SW1 send routes to).
R2(config)#do sh ip bgp 222.22.2.0
BGP routing table entry for 222.22.2.0/24, version 99
Paths: (1 available, best #1, table Default-IP-Routing-Table)
Advertised to update-groups:
2
254
192.10.1.254 from 192.10.1.254 (222.22.2.1)
Origin incomplete, metric 0, localpref 100, valid, external, best
Community: 200:123 200:254 254:100
R6(config)#do sh ip bgp 222.22.2.0
BGP routing table entry for 222.22.2.0/24, version 48
Paths: (2 available, best #1, table Default-IP-Routing-Table, Advertisements suppressed by an aggregate.)
Flag: 0x880
Not advertised to any peer
(65014) 200 254
155.1.13.3 (metric 27260160) from 155.1.146.1 (150.1.1.1)
Origin incomplete, metric 0, localpref 100, valid, confed-external, best
Community: 200:123 200:254 254:100
300 200 254
155.1.67.7 from 155.1.67.7 (150.1.77.77)
Origin incomplete, localpref 100, valid, external
Community: 254:100 300:200
Another fun scenario was using extended access-lists to match a range of subnets, something that would be much simpler with prefix-lists, but alas, can also be accomplished with extended access-lists. In short, the source in your access-list would be what to match in the network, with the destination matching the subnet mask.
R4(config)#access-list 104 deny 0.0.1.0 255.255.254.0 255.255.252.0 0.0.3.255
R4(config)#access-list 104 permit ip any any
This would deny any route with an odd third octet, with a /22 mask or larger up to a /24. I already know how to match networks based on access-lists, but matching the masks with an access-list is something new. Looking at it, it makes total sense, but something I need to see a few more times to really get a handle on.
Moving on, I stumbled across bgp dampening. Something I always though was pretty easy, but INE presents it differently. "Once a prefix flaps two times in a row, the advertisement should resume in 5 minutes". Most scenarios will specify the actual dampening parameters. Here is the actual formula:
P (t) = P (0) /2^(t/Half_life)
We know that the time we want is 5 minutes.
P(5) = P(0)/2^(5/Half_life)
Now substitute P(5) = 750 (the reuse limit) and P(0) = 2000 (suppress limit). The equation becomes:
200/750=2^(5/Half_life)
From this equation, take the logarithm of the both sides.
Half_life=5*Ln(2)/Ln(200/75) = 3.5 (approx.)
We may now round up to 4. Max suppress time is by default 4 x half_life, giving us the following:
router bgp 200
bgp dampening 4 750 2000 16
Wow. Am I the only one lost? It's been a number of years since I've taken an advanced math class, so I'm guessing that is why I am lost. I'll review this again later, but I would hope Cisco doesn't expect all candidates to be up on advanced math.
The default bgp scanner time is 60 seconds. Keepalive is defaulted to 60 seconds with the holdtime being 180. The BGP scanner is responsible checking validity and reachability of BGP NEXT_HOP attributes, performs conditional advertisement and route injection, imports new routes into BGP table from RIB and performs route dampening. If you receive a scenario to configure BGP to do route injection every 20 seconds, you will need to alter the BGP scan time. Also, setting the advertisement-interval to 0 will remove batch updates and advertise immediately.
You can adjust the bgp next-hop trigger timers. Remember the BGP scan time is responsible for validity and reachability of the NEXT_HOP attributes. If we use the next-hop trigger timers, we can tune this to be more in line with IGP timers.
That finally wraps up BGP. This took me a while, but I wanted to take my time going through BGP, knowing that it is one of my weaknesses. More to come later from Vol 1.....
No comments:
Post a Comment