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:

Routes learned from an iBGP neighbor must never be advertised to any other iBGP neighbor. Don't forget to download the EVE-NG topology file for this tutorial below.
Network topology diagram showing the need for full mesh ibgp due to split horizon rule preventing route advertisement in BGP.

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. 

Network topology diagram displaying a full mesh iBGP configuration with successful prefix advertisement.

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

Network topology diagram illustrating for full mesh ibgp and logical peering with R1, R2, and R3 in AS123.
The last octet is the router number unless specified otherwise. Example: R1's G0/0 is 10.10.12.1/24

Initial Configs

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's free! 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.

Discussion

You need to be a member if you want to use or view the support forum. Register here, it's free.