iBGP Peering

BGP peers can be either internal or external. This relationship is determined based on the process ID of the local router vs. that of the remote router. If they match, they are internal (iBGP) peers and if they differ, they will be external (eBGP) peers. I will put up a post later on the eBGP part - this is mainly focused on a simple configuration of iBGP relationship in an autonomous system (AS) with three routers.

Any routing protocol, worth its weight, needs some form of loop prevention and I will describe (shortly) the loop prevention used with iBGP. Keep in mind that the loop prevention mechanism differs for iBGP and eBGP.

Loop prevention with iBGP works by simply not allowing any routes learned from an iBGP neighbor to be advertised to another iBGP neighbor. Pretty simple. This often times creates a need for iBGP neighbors to be fully meshed, which would be quite the hassle in some cases - with every router added requiring more and more manual peers to be created. Some fixes to this would be to use a route reflector or configure confederations within the internal AS - I will make a post or two on the matter later. The use of peer groups and communities also serve to alleviate some of the administrative burden of managing large-scale BGP installations.

Internal BGP relies heavily on the existing network infrastructure to function properly. A feature of iBGP is the BGP synchronization, which requires a router to have IGP reachability before any routes, learned from iBGP peers, can be installed into the routing table.

The command neighbor <ip address> remote-as <asn> under the BGP process is the main neighbor command used to configure a peer. The external/internal decision is based on a comparison of the ASN of the local router and the ASN configured in the remote-as of the peer - if they are a match, they will be iBGP peers.

In the diagram below are three routers, where BGP is configured on two of them. They peer across the network, reaching each other through the non-BGP router and proceeds to exchange routes with each other.

iBGP peering lab setup with transit AS 1.23

This is one of the things possible with BGP, which cannot be done using any of the IGPs on the CCIE curriculum - this can be done by default because the BGP messages exchanged between internal peers have a TTL of 255 - as opposed to the TTL of 1 for external BGP peers (this can be tuned).

The problem this poses, is that traffic transiting the network, will have to go through the non-BGP router - which in most cases will have to drop the traffic, due to not having a route to the destined network (because it is not running BGP and therefore does not have the route in its routing table).

Below is a traceroute done on R4 towards a subnet in AS 5.5 - notice where the traffic stops flowing.

R4#show ip interface loopback 1 | include Internet address
  Internet address is 21.0.0.1/8
R4#traceroute 31.0.0.1 source loopback 1
Type escape sequence to abort.
Tracing the route to 31.0.0.1
VRF info: (vrf in name/id, vrf out name/id)
  1 140.1.14.1 2 msec 1 msec 1 msec
  2  *  *  *
  3  *  *  *
  <output omitted>

The trace reaches R2, but R2 is unable to route to the destination network - and also unable to reply to the source address. Below shows R2s routing table, which illuminates the issue in the routing scenario.

R2#show ip route | begin Gateway
Gateway of last resort is not set
      10.0.0.0/8 is variably subnetted, 4 subnets, 2 masks
C        10.0.12.0/24 is directly connected, GigabitEthernet1.12
L        10.0.12.2/32 is directly connected, GigabitEthernet1.12
C        10.0.13.0/24 is directly connected, GigabitEthernet1.13
L        10.0.13.2/32 is directly connected, GigabitEthernet1.13

There is no default route and also no routes toward the networks in AS 4.4 or 5.5.

The quick fix for this issue would be to turn on BGP on R2 and have it peer with routers R1 and R3 - then they would give it their BGP routes and traffic from AS 4.4 towards AS 5.5 would now transit AS 1.23 without any black holing.

Another solution would be to configure a GRE tunnel between routers R1 and R3 and use that for the BGP traffic - allowing the traffic to traverse router R2, but with a source/destination that would be in R2s routing table.

Yet another solution would be to turn on synchronization on routers R1 and R3 so that they do not advertise routes to their eBGP peers, that cannot be routed by the internal routers in AS 1.23 (in this case, router R2). The rules of synchronization states that for a BGP router to advertise a prefix, that same prefix must already be entered into the routing table by an IGP. Since this is not the case, the routes would not be allowed to be advertised to the peers of routers R1 and R3 - solving the problem by disallowing transit to occur.

There are many more solutions to the issue, and surely turning on synchronization is near the bottom, I would reckon.