So far, building our BGP network I have accomplished the following:
- Created eBGP peering between R2 (AS65100) and R8 (AS65089).
- Created iBGP peering between R2 and R4 using their respective Loopback0 interfaces to form a BGP session.
Now, let's fix the problem of BGP prefixes advertisement between R1 and R4 over iBGP.Here's the BGP table on R1:
R1#show ip bgp
BGP table version is 13, local router ID is 10.1.1.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter,
x best-external, a additional-path, c RIB-compressed,
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found
Network Next Hop Metric LocPrf Weight Path
*> 10.1.1.1/32 0.0.0.0 0 32768 i
*>i 10.2.2.2/32 172.16.123.2 0 100 0 i
*>i 10.8.0.0/28 172.16.123.2 0 100 0 65089 i
*>i 10.8.0.16/28 172.16.123.2 0 100 0 65089 i
*>i 10.8.0.32/28 172.16.123.2 0 100 0 65089 i
*>i 10.8.0.48/28 172.16.123.2 0 100 0 65089 i
*>i 10.8.8.8/32 172.16.123.2 0 100 0 65089 i
*>i 10.8.80.0/24 172.16.123.2 0 100 0 65089 i
*>i 10.8.81.0/24 172.16.123.2 0 100 0 65089 i
*>i 10.8.82.0/24 172.16.123.2 0 100 0 65089 i
*>i 10.8.83.0/24 172.16.123.2 0 100 0 65089 i
*>i 198.51.100.0 172.16.123.2 0 100 0 65089 i
R1#
Clearly, all is good here. R1 has 172.16.123.2 as its next hop IP towards the destination (next-hop-self command on R2). It receives all the prefixes that R2 is getting over eBGP from R8.
But what does the BGP table look like on R4 that is peering with R1?
R4#show ip bgp
BGP table version is 2, local router ID is 10.4.4.4
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter,
x best-external, a additional-path, c RIB-compressed,
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found
Network Next Hop Metric LocPrf Weight Path
r>i 10.1.1.1/32 10.1.1.1 0 100 0 i
R4#
There are no BGP routes we expect to see. There is only 10.1.1.1 (R1's Loopback0). Since we are getting it via EIGRP as well, the lower AD of EIGRP will make this entry 'rib-failure' in BGP. The BGP protocol will not be used on R4 to install this one. R2 will rather rely on EIGRP as a better source of routing information.
R4#show ip bgp rib-failure
Network Next Hop RIB-failure RIB-NH Matches
10.1.1.1/32 10.1.1.1 Higher admin distance n/a
R4#
R4#show ip route 10.1.1.1
Routing entry for 10.1.1.1/32
Known via "eigrp 10", distance 90, metric 409600, type internal
Redistributing via eigrp 10
Last update from 172.16.14.1 on Ethernet0/0.14, 01:07:02 ago
Routing Descriptor Blocks:
* 172.16.104.1, from 172.16.104.1, 01:07:02 ago, via Ethernet0/1
Route metric is 409600, traffic share count is 1
Total delay is 6000 microseconds, minimum bandwidth is 10000 Kbit
Reliability 255/255, minimum MTU 1500 bytes
Loading 1/255, Hops 1
172.16.14.1, from 172.16.14.1, 01:07:02 ago, via Ethernet0/0.14
Route metric is 409600, traffic share count is 1
Total delay is 6000 microseconds, minimum bandwidth is 10000 Kbit
Reliability 255/255, minimum MTU 1500 bytes
Loading 1/255, Hops 1
R4#
That, we already know.
Is R1 even trying to advertising prefixes learned from R2 towards R1?
R1#show ip bgp neighbor 10.4.4.4 advertised-routes
BGP table version is 13, local router ID is 10.1.1.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter,
x best-external, a additional-path, c RIB-compressed,
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found
Network Next Hop Metric LocPrf Weight Path
*> 10.1.1.1/32 0.0.0.0 0 32768 i
It does not advertise them at all. But why?
In order to avoid internal routing loops, BGP uses its own 'bgp split-horizon' rule. It stipulates that prefixes learned via iBGP, CANNOT be advertised over an iBGP session.
There are a number of ways around that.
- Use BGP Route-Reflectors (explained in this post).
- Use iBGP full-mesh connectivity. This one may be hard to implement with a lot of routers as it falls under n(n-1)/2 formula, where 'n' is the number of routers involved.
- Use BGP Confederations.
I will tackle the last two options in later posts, but for now in order to enable connectivity between R4 and AS 65089, I will use Route-Reflector.
In the simplest scenario, BGP Route-Reflector is a router that has iBGP sessions established to all other neighbors that need the prefixes. It will a 'sort of' break the rule of split-horizon and forward the prefixes to other neighbors based on the admin's configuration.
Simply put, Route-Reflector is the central router that can advertise BGP prefixes to all other routers.
Route-Reflector can have three types of neighbors:
- eBGP Peer
- Client Peer
- Non-client Peer
Given that, RR (route-reflector) will follow a few rules:
Routes learned from eBGP neighbors will be forwarded to ALL peers (eBGP, client, non-client).
Routes learned from client peers will be forwarded to All peers (eBGP, client, non-client).
Routes learned from non-client peers, will be forwarded to eBGP and clients.
Take a look at the above topology. R1 has currently an iBGP connectivity with R2 and R4. In a moment I will add R5 to the mix (blue arrows indicate iBGP sessions). It is a candidate to become a Route-Reflector.
I am going to start with advertising Loopback0 from R4, so that AS 65089 is receiving.
R4#show run | s router bgp
router bgp 65100
bgp log-neighbor-changes
network 10.4.4.4 mask 255.255.255.255
neighbor 10.1.1.1 remote-as 65100
neighbor 10.1.1.1 update-source Loopback0
R4#
The BGP table on R4 looks like this:
R4#show ip bgp | begin Network
Network Next Hop Metric LocPrf Weight Path
r>i 10.1.1.1/32 10.1.1.1 0 100 0 i
*> 10.4.4.4/32 0.0.0.0 0 32768 i
R4#
I am ready to advertise (reflect) routes learned from AS 65089 towards R4. The R1 router will become a route reflector with R4 (and later R5) as its client.
R1#show run | section router bgp
router bgp 65100
bgp log-neighbor-changes
network 10.1.1.1 mask 255.255.255.255
neighbor 10.4.4.4 remote-as 65100
neighbor 10.4.4.4 update-source Loopback0
neighbor 10.4.4.4 route-reflector-client
neighbor 172.16.123.2 remote-as 65100
R1#
BGP session between R1 and R4 has been re-established upon this change. What are the results then?
Since the output of 'show ip bgp neighbor 10.4.4.4' is rather large, I will check it this way:
R1#show ip bgp neighbors 10.4.4.4 | include Route-Reflector
Route-Reflector Client
R1#
R4 is now a route-reflector client.
So, can R4 see all the prefixes previously missing?
R4#show ip bgp | begin Network
Network Next Hop Metric LocPrf Weight Path
r>i 10.1.1.1/32 10.1.1.1 0 100 0 i
*>i 10.2.2.2/32 172.16.123.2 0 100 0 i
*> 10.4.4.4/32 0.0.0.0 0 32768 i
*>i 10.8.0.0/28 172.16.123.2 0 100 0 65089 i
*>i 10.8.0.16/28 172.16.123.2 0 100 0 65089 i
*>i 10.8.0.32/28 172.16.123.2 0 100 0 65089 i
*>i 10.8.0.48/28 172.16.123.2 0 100 0 65089 i
*>i 10.8.8.8/32 172.16.123.2 0 100 0 65089 i
*>i 10.8.80.0/24 172.16.123.2 0 100 0 65089 i
*>i 10.8.81.0/24 172.16.123.2 0 100 0 65089 i
*>i 10.8.82.0/24 172.16.123.2 0 100 0 65089 i
*>i 10.8.83.0/24 172.16.123.2 0 100 0 65089 i
*>i 198.51.100.0 172.16.123.2 0 100 0 65089 i
R4#
It worked.Now onto the iBGP session between R1 and R5. This time I will ensure that R5 is a route-reflector client.
Let's start with removing 'passive-interface' command on R1 in order to establish EIGRP adjacency:
Configuration on R1:
router eigrp 10
network 10.1.1.1 0.0.0.0
network 172.16.0.0
passive-interface Ethernet0/0.15
eigrp router-id 10.1.1.1
Removing the command is simple:
R1#conf t
Enter configuration commands, one per line. End with CNTL/Z.
R1(config)#router eigrp 10
R1(config-router)#no passive-interface ethernet0/0.15
R1(config-router)#
R1(config-router)#
R1(config-router)#do show ip eigrp interfaces
EIGRP-IPv4 Interfaces for AS(10)
Xmit Queue PeerQ Mean Pacing Time Multicast Pending
Interface Peers Un/Reliable Un/Reliable SRTT Un/Reliable Flow Timer Routes
Lo0 0 0/0 0/0 0 0/0 0 0
Et0/0.14 1 0/0 0/0 4 0/2 50 0
Et0/0.123 1 0/0 0/0 5 0/2 50 0
Et0/1 1 0/0 0/0 6 0/2 50 0
Et0/0.15 0 0/0 0/0 0 0/0 0 0
In the above output it is clear that R1 will start sending 'hello' packets over its Ethernet0/0.15 interface.
Now, onto the R1 BGP configuration:
R1#show run | s router bgp
router bgp 65100
bgp log-neighbor-changes
network 10.1.1.1 mask 255.255.255.255
neighbor 10.4.4.4 remote-as 65100
neighbor 10.4.4.4 update-source Loopback0
neighbor 10.4.4.4 route-reflector-client
neighbor 172.16.15.5 remote-as 65100
neighbor 172.16.15.5 route-reflector-client
neighbor 172.16.123.2 remote-as 65100
R1#
Obviously, R5 needs a respective eigrp and BGP configuration.
R5#show run | section router eigrp
router eigrp 10
network 172.16.0.0
R5#
R5#show run | section router bgp
router bgp 65100
bgp log-neighbor-changes
network 10.5.5.5 mask 255.255.255.255
neighbor 172.16.15.1 remote-as 65100
R5#
When RR receives a route over iBGP session, it tags it internally to know that it comes from a client. This way it know which neighbors the prefix should be forwarded to.
R1#show ip bgp 10.5.5.5
BGP routing table entry for 10.5.5.5/32, version 17
Paths: (1 available, best #1, table default)
Advertised to update-groups:
1 2
Refresh Epoch 1
Local, (Received from a RR-client)
172.16.15.5 from 172.16.15.5 (10.5.5.5)
Origin IGP, metric 0, localpref 100, valid, internal, best
R1#
Apart from that, when RR is advertising prefixes it will include two extra attributes (more on those in later posts).
- Originator ID
- Cluster List
They will ensure a loop free topology.
R2#show ip bgp 10.5.5.5
BGP routing table entry for 10.5.5.5/32, version 15
Paths: (1 available, best #1, table default)
Advertised to update-groups:
1
Refresh Epoch 2
Local
172.16.15.5 (metric 307200) from 172.16.123.1 (10.1.1.1)
Origin IGP, metric 0, localpref 100, valid, internal, best
Originator: 10.5.5.5, Cluster list: 10.1.1.1
R2#
A final connectivity test between the two Autonomous Systems.
Ping from R4 to R8:
R4#ping 10.8.8.8 source loopback0
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.8.8.8, timeout is 2 seconds:
Packet sent with a source address of 10.4.4.4
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/2 ms
R4#
And ping test from R5.
R5#ping 10.8.8.8 source loopback0
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.8.8.8, timeout is 2 seconds:
Packet sent with a source address of 10.5.5.5
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/2 ms
R5#
