BGP Split Horizon and Full Mesh iBGP
Contents
Intro
In this tutorial I’ll cover BGP Split Horizon and Full Mesh iBGP. Just so you know eBGP uses AS-Path to prevent loops. By default if an eBGP router receives a prefix with its own AS number in the path, it will not accept the prefix. What about iBGP? That’s where the split horizon rule comes into play. The BGP split horizion states:
If you look at the picture above, R1 advertises the 1.1.1.1/32 prefix to R2, but R2 does not propagate this prefix to R3. This scenario highlights a typical problem in non-full mesh iBGP configurations due to the iBGP loop prevention rule.
To fix this I’ll configure a Full Mesh iBGP network where R1, R2, and R3 are all inter-peered, ensuring all routes, including the 1.1.1.1/32 from R1, are properly propagated throughout the AS.
Here’s what a AS123 will look like in a fully meshed iBGP network.
With a Full Mesh iBGP, R1 has a new iBGP peering to R3. R3 doesn’t have to worry about not receiving the prefix from R2 because it’s going to get it from R1. Keep in mind that R1 is not physically connected to R3, it doesn’t need to be. Sure it’s better to have a dedicated physical connection between R1 and R3 but it’s not a requirement. iBGP peers can be interconnected through one or more intermediate routers, as long as there is IP connectivity between them. This means that the peering can be logical, using routed paths within the network, rather than physical direct connections.
I’ll show you the split horizion problem now and how to fix it by configuring full mesh iBGP peerings. Here’s the topology I’ll use.
Topology
Initial Configs
conf t
hostname R1
no ip domain-lookup
line con 0
logging syn
!
int g0/0
no sh
ip add 10.10.12.1 255.255.255.0
!
int lo1
ip add 1.1.1.1 255.255.255.255
conf t
hostname R2
no ip domain-lookup
line con 0
logging syn
!
int g0/0
no sh
ip add 10.10.12.2 255.255.255.0
!
int g0/1
no sh
ip add 10.10.23.2 255.255.255.0
conf t
hostname R3
no ip domain-lookup
line con 0
logging syn
!
int g0/1
no sh
ip add 10.10.23.3 255.255.255.0
Configuration Steps
1. Configure Basic BGP in AS123 and advertise R1's Lo1 prefix
I’ll start by getting all of the BGP peerings up using their respective AS numbers and R1’s Lo1 prefix advertised into BGP.
R1:
router bgp 123
neighbor 10.10.12.2 remote-as 123
network 1.1.1.1 mask 255.255.255.255
R2:
router bgp 123
neighbor 10.10.12.1 remote-as 123
neighbor 10.10.23.3 remote-as 123
R3:
router bgp 123
neighbor 10.10.23.2 remote-as 123
That should be enough to get the peerings up and R1’s loopback prefix into BGP. After a few seconds I should see messages confirming the neighbors are up.
R1:
%BGP-5-ADJCHANGE: neighbor 10.10.12.2 Up
R2:
%BGP-5-ADJCHANGE: neighbor 10.10.12.1 Up
%BGP-5-ADJCHANGE: neighbor 10.10.23.3 Up
R3:
%BGP-5-ADJCHANGE: neighbor 10.10.23.2 Up Great, now I’ll check the BGP tables on R2 and R3 to if the prefixes are being received.
R2:
R2#show ip bgp
BGP table version is 2, local router ID is 10.10.23.2
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,
t secondary path,
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found
Network Next Hop Metric LocPrf Weight Path
*>i 1.1.1.1/32 10.10.12.1 0 100 0 i R2#show ip bgp 1.1.1.1
BGP routing table entry for 1.1.1.1/32, version 2
Paths: (1 available, best #1, table default)
Not advertised to any peer
Refresh Epoch 1
Local
10.10.12.1 from 10.10.12.1 (1.1.1.1)
Origin IGP, metric 0, localpref 100, valid, internal, best
rx pathid: 0, tx pathid: 0x0 R2’s BGP table has the prefix from R1. Let me check R3.
R3:
R3#show ip bgp
R3#show ip bgp 1.1.1.1
% Network not in table R3 is receving nothing. Let me just confirm the peering is up using the show ip bgp summary command.
R3:
R3#show ip bgp summary
BGP router identifier 10.10.23.3, local AS number 123
BGP table version is 1, main routing table version 1
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
10.10.23.2 4 123 5 5 1 0 0 00:02:21 0 R3’s peering to R2 is up and no prefixes are being received. Let me verify using one more command but on R2.
R2:
R2#show ip bgp neighbors 10.10.23.3 advertised-routes
Total number of prefixes 0 Looks like this confirms R2 is not advertising anything to R3. Knowing that these routers are not fully meshed this confirms BGP split horizon is the issue. Let’s get these routers fully meshed. I’ll configure R1 to peer with R3 and then I’ll configure R3 to peer with R1.
2. Configure Full Mesh iBGP in AS123
R1:
router bgp 123
neighbor 10.10.23.3 remote-as 123
R3:
router bgp 123
neighbor 10.10.12.1 remote-as 123
After a few seconds I should see messages letting me know the neighbors are up… But those messages never come. Remember as long as there is IP connectivity between the IP’s used in the peerings then the neighbors should come up. But can R1 reach 10.10.23.3? Can R3 reach 10.10.12.1?
R1:
R1#ping 10.10.23.3
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.10.23.3, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)
R1#show ip route 10.10.23.3
% Subnet not in table R3:
R3#ping 10.10.12.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.10.12.1, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)
R3#sh ip route 10.10.12.1
% Subnet not in table They sure can’t, they don’t even know those networks exist since they’re not directly connected. We can fix this using static routes or use an routing protocol like OSPF of EIGRP. I’ll use OSPF to provide IP reachability for the links in AS123.
R1:
int g0/0
ip ospf 1 area 0 R2:
int range g0/0-1
ip ospf 1 area 0 R3:
int g0/1
ip ospf 1 area 0 I used interface level OSPF commands to create OSPF process 1 and I put the interfaces in area 0. I’ll check the routing tables again on R1 and R3 to see if they know each others directly connected links.
R1:
R1#show ip route | beg Gateway
Gateway of last resort is not set
1.0.0.0/32 is subnetted, 1 subnets
C 1.1.1.1 is directly connected, Loopback1
10.0.0.0/8 is variably subnetted, 3 subnets, 2 masks
C 10.10.12.0/24 is directly connected, GigabitEthernet0/0
L 10.10.12.1/32 is directly connected, GigabitEthernet0/0
O 10.10.23.0/24 [110/2] via 10.10.12.2, 00:14:35, GigabitEthernet0/0> R3:
R3#show ip route | beg Gateway
Gateway of last resort is not set
1.0.0.0/32 is subnetted, 1 subnets
B 1.1.1.1 [200/0] via 10.10.12.1, 00:14:40
10.0.0.0/8 is variably subnetted, 3 subnets, 2 masks
O 10.10.12.0/24 [110/2] via 10.10.23.2, 00:14:45, GigabitEthernet0/1
C 10.10.23.0/24 is directly connected, GigabitEthernet0/1
L 10.10.23.3/32 is directly connected, GigabitEthernet0/1 Great, now that the OSPF routes showed up the new iBGP peering between R1 and R3 should come up as well.
R1:
%BGP-5-ADJCHANGE: neighbor 10.10.23.3 Up R3:
%BGP-5-ADJCHANGE: neighbor 10.10.12.1 Up And the new iBGP peering is up. Let me see how many BGP neighbors R3 has and how many prefixes are being received.
R3:
R3#show ip bgp summary
BGP router identifier 10.10.23.3, local AS number 123
BGP table version is 6, main routing table version 6
1 network entries using 144 bytes of memory
1 path entries using 84 bytes of memory
1/1 BGP path/bestpath attribute entries using 160 bytes of memory
0 BGP route-map cache entries using 0 bytes of memory
0 BGP filter-list cache entries using 0 bytes of memory
BGP using 388 total bytes of memory
BGP activity 3/2 prefixes, 3/2 paths, scan interval 60 secs
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
10.10.12.1 4 123 26 25 6 0 0 00:18:08 1
10.10.23.2 4 123 39 40 6 0 0 00:33:02 0 The show ip bgp summary command on R3 shows the peering is up and 1 prefix is being received. Let’s see what prefixes R3 actually has.
R3:
R3#show ip bgp
BGP table version is 6, local router ID is 10.10.23.3
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,
t secondary path,
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found
Network Next Hop Metric LocPrf Weight Path
*>i 1.1.1.1/32 10.10.12.1 0 100 0 i The show ip bgp command on R3 confirms that it is receiving the 1.1.1.1/32 prefix from R1 thanks to the full mesh iBGP configuration. This setup prevents routing issues that come with partial mesh configurations and still follows the rule that iBGP learned routes must not be re-advertised to other iBGP peers. Full Mesh iBGP works great in this scenario because there’s only 3 routers. As the number of iBGP routers starts to grow so does the configuration. If you want scalability then route reflectors or confederations are a better option for working around split horizon.
Don’t forget to download the EVE-NG topology file if you want to practice this out yourself. I’m here to help you so be sure to leave a comment if you have any questions.
EVE-NG Lab File
To download the EVE-NG topology file you'll need to be a member. You can register here. It will be right here once you log in.
Full Configs
Here are the full configs from all routers if you want to try it out yourself.
conf t
hostname R1
no ip domain-lookup
line con 0
logging syn
!
int g0/0
no sh
ip add 10.10.12.1 255.255.255.0
ip ospf 1 area 0
!
int lo1
ip add 1.1.1.1 255.255.255.255
!
router bgp 123
neighbor 10.10.12.2 remote-as 123
neighbor 10.10.23.3 remote-as 123
network 1.1.1.1 mask 255.255.255.255
conf t
hostname R2
no ip domain-lookup
line con 0
logging syn
!
int g0/0
no sh
ip add 10.10.12.2 255.255.255.0
ip ospf 1 area 0
!
int g0/1
no sh
ip add 10.10.23.2 255.255.255.0
ip ospf 1 area 0
!
router bgp 123
neighbor 10.10.12.1 remote-as 123
neighbor 10.10.23.3 remote-as 123
conf t
hostname R3
no ip domain-lookup
line con 0
logging syn
!
int g0/1
no sh
ip add 10.10.23.3 255.255.255.0
ip ospf 1 area 0
!
router bgp 123
neighbor 10.10.23.2 remote-as 123
neighbor 10.10.12.1 remote-as 123