The first post in this BGP mini-series looked at setting up BGP peering between routers. Now we’ll take things a step further and actually exchange some routing information between those peers. Here’s the network:
The basic BGP config on each router looks like this:
R1#sh run | s router router bgp 1 no synchronization bgp log-neighbor-changes neighbor 2.2.2.2 remote-as 23 neighbor 2.2.2.2 ebgp-multihop 2 neighbor 2.2.2.2 update-source Loopback0 neighbor 3.3.3.3 remote-as 23 neighbor 3.3.3.3 ebgp-multihop 2 neighbor 3.3.3.3 update-source Loopback0 no auto-summary R2#shrun | s router router bgp 23 no synchronization bgp log-neighbor-changes neighbor 1.1.1.1 remote-as 1 neighbor 1.1.1.1 ebgp-multihop 2 neighbor 1.1.1.1 update-source Loopback0 neighbor 3.3.3.3 remote-as 23 neighbor 3.3.3.3 ebgp-multihop 2 neighbor 3.3.3.3 update-source Loopback0 no auto-summary R3#sh run | s router router bgp 23 no synchronization bgp log-neighbor-changes neighbor 1.1.1.1 remote-as 1 neighbor 1.1.1.1 ebgp-multihop 2 neighbor 1.1.1.1 update-source Loopback0 neighbor 2.2.2.2 remote-as 23 neighbor 2.2.2.2 ebgp-multihop 2 neighbor 2.2.2.2 update-source Loopback0 no auto-summary
We’ve now got peering between all three routers, but no routes are being learned yet via BGP. So far only static and connected routes are shown in the routing tables and we can see this on R1:
R1#sh ip bgp neighbors | i BGP BGP neighbor is 2.2.2.2, remote AS 23 external link BGP version 4, remote router ID 2.2.2.2 BGP state = Established, up for 05:17:02 BGP table version 1, neighbor version 1/0 External BGP neighbor may be up to 2 hops away. BGP neighbor is 3.3.3.3, remote AS 23 external link BGP version 4, remote router ID 3.3.3.3 BGP state = Established, up for 05:16:57 BGP table version 1, neighbor version 1/0 External BGP neighbor may be up to 2 hops away. R1#sh ip route {output omitted} Gateway of last resort is not set 1.0.0.0/32 is subnetted, 1 subnets C 1.1.1.1 is directly connected, Loopback0 2.0.0.0/32 is subnetted, 1 subnets S 2.2.2.2 [1/0] via 10.0.12.2 3.0.0.0/32 is subnetted, 1 subnets S 3.3.3.3 [1/0] via 10.0.13.3 10.0.0.0/29 is subnetted, 2 subnets C 10.0.12.0 is directly connected, FastEthernet0/0 C 10.0.13.0 is directly connected, FastEthernet1/0
There are two main methods of advertising routes into BGP – network statements and redistribution.
Network Statements
On R2 we will use a network statement to advertise the 192.168.2.0 /24 network into BGP (note that bgp network statements use subnet masks rather than wildcard masks):
R2(config)#router bgp 23 R2(config-router)#network 192.168.2.0 mask 255.255.255.0
If we check R1’s BGP table we see that it has learned of 192.168.2.0/24 route, also that the best route is via R2, and that the path is through AS23:
R1#sh ip bgp
BGP table version is 36, 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
* 192.168.2.0 3.3.3.3 0 23 i
*> 2.2.2.2 0 0 23 i
The best route is now also in R1’s routing table (note the administrative distance of 20 for external BGP):
R1#sh ip route bgp
B 192.168.2.0/24 [20/0] via 2.2.2.2, 00:25:55
Redistribution
On R3 we will redistribute connected networks so that we advertise the 192.168.3.0 /24 network into BGP:
R3(config)#router bgp 23 R3(config-router)#redistribute connected
This works but is a little clumsy. We can now see the 192.168.3.0 /24 network in R1’s routing table, but we also see the 10.0.23.0 /29 transit network between R2 and R3:
R1#show ip route bgp
10.0.0.0/29 is subnetted, 3 subnets
B 10.0.23.0 [20/0] via 3.3.3.3, 00:01:22
B 192.168.2.0/24 [20/0] via 2.2.2.2, 00:20:27
B 192.168.3.0/24 [20/0] via 3.3.3.3, 00:01:22
Plus we also get some RIB failure messages relating to R3’s other connected networks:
R1#sh ip bgp
BGP table version is 8, 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
r 3.3.3.3/32 2.2.2.2 0 23 ?
r> 3.3.3.3 0 0 23 ?
r 10.0.13.0/29 2.2.2.2 0 23 ?
r> 3.3.3.3 0 0 23 ?
* 10.0.23.0/29 2.2.2.2 0 23 ?
*> 3.3.3.3 0 0 23 ?
* 192.168.2.0 3.3.3.3 0 23 i
*> 2.2.2.2 0 0 23 i
* 192.168.3.0 2.2.2.2 0 23 ?
*> 3.3.3.3 0 0 23 ?
This is because R1 already has a static route to 3.3.3.3/32 and is directly connected to 10.0.13.0/29.
To tidy this up we’ll filter routes using a route map that references an access list to match only the 192.168.3.0/24 network:
R3(config)#route-map R3RouteMap permit 10 R3(config-route-map)#match ip address 10 R3(config)#access-list 10 permit 192.168.3.0 0.0.0.255 R3(config)#router bgp 23 R3(config-router)#redistribute connected route-map R3RouteMap
Now R1 only learns the route to 192.168.3.0/24 from R3, as the route map is preventing the other networks from being advertised:
R1#sh ip bgp
BGP table version is 17, 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
* 192.168.2.0 3.3.3.3 0 23 i
*> 2.2.2.2 0 0 23 i
* 192.168.3.0 2.2.2.2 0 23 ?
*> 3.3.3.3 0 0 23 ?
R1#sh ip route bgp
B 192.168.2.0/24 [20/0] via 2.2.2.2, 02:20:54
B 192.168.3.0/24 [20/0] via 3.3.3.3, 02:16:40
As well being less clumsy, this is much more like a real-world scenario where an ISP would be filtering the routes it advertises to a customer or vice versa.
I hope this has been a useful explanation. The next post in this series looks at modifying BGP attributes to inlfuence route selection.
Thanks for reading, and good luck with your CCNP studies!
Rich
Follow Rich on Twitter
Discover more from RSS Feeds Cloud
Subscribe to get the latest posts sent to your email.
