Oh yeah, I went there. We now have another eBGP neighbor to play with some weight configuration with, and see what behaviors occur when working with this Topology so lets dive in!
No configurations changes have been made from the previous lab except adding R5 back into the mix, and Peering it to R1 as an eBGP Neighbor.
So my first thought was can it see the advertisement of 4.4.4.4 from R4 correctly?
R5#sh ip bgp
BGP table version is 2, local router ID is 5.5.5.5
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
*> 4.4.4.4/32 172.12.15.1 0 123 4 i
R5#
Sure enough it does, and we can also verify the Weight is 0 so R1 is doing no advertising of Weight for the route, because that is locally significant only!
So first I want to remove the previous weight command to the neighbor 172.12.123.3:
R1#conf t
Enter configuration commands, one per line. End with CNTL/Z.
R1(config)#router bgp 123
R1(config-router)#no neighbor 172.12.123.3 weight 200
R1(config-router)#^Z
R1#
R1#clear ip bgp * soft in
R1#sh ip bgp
BGP table version is 4, local router ID is 1.1.1.1
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
* i4.4.4.4/32 172.12.123.3 0 100 0 4 i
*>i 172.12.123.2 0 100 0 4 i
R1#
So R1 is back to business as usual, but what about R5?
R5#clear ip bgp * soft in
R5#sh ip bgp
BGP table version is 2, local router ID is 5.5.5.5
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
*> 4.4.4.4/32 172.12.15.1 0 123 4 i
R5#
So that was not impacted by the change at all either, so I am going to add a loopback to R4 and advertise it to the network to see if we can make things interesting:
R4#conf t
Enter configuration commands, one per line. End with CNTL/Z.
R4(config)#int lo44
*Apr 14 06:00:00.331: %LINEPROTO-5-UPDOWN: Line protocol on Interface Loopback44, changed state to up
R4(config-if)#ip add 44.4.4.4 255.255.255.255
R4(config-if)#router bgp 4
R4(config-router)#network 44.4.4.4 mask 255.255.255.255
R4(config-router)#^Z
R4#wr
Building configuration…
So lets check around on out routers again, and see where everyone is at with the new addition to the network advertisements:
R2#sh ip bgp
BGP table version is 3, local router ID is 2.2.2.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
*> 4.4.4.4/32 172.12.23.4 0 0 4 i
*> 44.4.4.4/32 172.12.23.4 0 0 4 i
R2#
ASR#3
[Resuming connection 3 to r3 … ]
R3#sh ip bgp
BGP table version is 3, local router ID is 3.3.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
*> 4.4.4.4/32 172.12.23.4 0 0 4 i
*> 44.4.4.4/32 172.12.23.4 0 0 4 i
R3#
ASR#1
[Resuming connection 1 to r1 … ]
R1#sh ip bgp
BGP table version is 5, local router ID is 1.1.1.1
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
* i4.4.4.4/32 172.12.123.3 0 100 0 4 i
*>i 172.12.123.2 0 100 0 4 i
* i44.4.4.4/32 172.12.123.3 0 100 0 4 i
*>i 172.12.123.2 0 100 0 4 i
R1#
So R2 and R3 are showing the correct Next Hop as their Best Path to the networks, and R1 is back to RID being the tie breaker again!
***One important note about the effect of “next-hop-self” command on neighbors is that it will advertise every route that way to iBGP Peers, so if you issue a neighbor command, unless you explicitly know otherwise, assume it effects all routes advertised***
So now I’ll demonstrate how to only change the weight on the local router R1 (of course) of the advertised network 44.4.4.4/32, so 4.4.4.4 will remain unchanged and any future routes added will not be effected by the weight change either:
R1(config)#access-list 44 permit 44.4.4.4
R1(config)#route-map WeightChange permit 10
R1(config-route-map)#match ip add 44
R1(config-route-map)#set weight 200
R1(config-route-map)#route-map WeightChange permit 20
R1(config-route-map)#^Z
R1#wr
Building configuration…
*Mar 31 14:03:18.961: %SYS-5-CONFIG_I: Configured from console by console[OK]
R1#
Even with BGP, or any Route-Map, it is just best practice to add on a blank sequence / clause to the end permitting traffic to flow normally, unless tasked to do otherwise.
Now after configuring the above route-map, you will want to choose which neighbor to apply it to, as if you were to apply it to both R2 and R3 we’d still be in the same boat with RID as a tie breaker:
R1#sh ip bgp
BGP table version is 5, local router ID is 1.1.1.1
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
* i4.4.4.4/32 172.12.123.3 0 100 0 4 i
*>i 172.12.123.2 0 100 0 4 i
* i44.4.4.4/32 172.12.123.3 0 100 0 4 i
*>i 172.12.123.2 0 100 0 4 i
R1#
So it is currently using R2 as best path for both, so I will apply the Route-Map to iBGP neighbor R3:
R1#conf t
R1(config)#router bgp 123
R1(config-router)#neighbor 172.12.123.3 route-map WeightChange ?
in Apply map to incoming routes
out Apply map to outbound routes
R1(config-router)#neighbor 172.12.123.3 route-map WeightChange in ?
<cr>
R1(config-router)#neighbor 172.12.123.3 route-map WeightChange in
R1(config-router)#^Z
R1#
*Mar 31 14:10:30.212: %SYS-5-CONFIG_I: Configured from console by console
R1#clear ip bgp * soft in
R1#sh ip bgp
BGP table version is 6, local router ID is 1.1.1.1
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
* i4.4.4.4/32 172.12.123.3 0 100 0 4 i
*>i 172.12.123.2 0 100 0 4 i
*>i44.4.4.4/32 172.12.123.3 0 100 200 4 i
* i 172.12.123.2 0 100 0 4 i
R1#
There it is just as easy as that, so route-maps are coming in very handy with BGP Best Path manipulation with a majority of its attributes. I am actually not sure why I even added R5 to the mix, as it didn’t really get used other than to demonstrate R1 wasn’t sharing the Weight change to it’s eBGP Neighbor R5.
So that is it for Weight changing and its behaviors, next up is Route Aggregation and Route Summarization, but having cleared 4 videos in one day and 4 separate posts I am 100% brain fried, so I will pick up hopefully tomorrow on BGP and keep hammering away at it to finish it off by the end of the long holiday weekend.
8 hours of work, followed by 6 hours of studying, enough to mix myself a 2am drink to relax the brain because this guy does not work in the morning 🙂 See you soon with even MORE BGP! WooooohoooooO!
The DEVNET GRIND! 