BGP peering over default routes

One interesting thing is that BGP can't peer over default route as RFC 4271 implies. First, let's consider this simple topology

R1#sh run | s router bgp

router bgp 1

 no synchronization

 bgp log-neighbor-changes

 neighbor 2.2.2.2 remote-as 1

 neighbor 2.2.2.2 ebgp-multihop 2

 neighbor 2.2.2.2 update-source Loopback0

 no auto-summary

R1#show ip route

....

Gateway of last resort is 10.1.2.2 to network 0.0.0.0

     1.0.0.0/32 is subnetted, 1 subnets

C       1.1.1.1 is directly connected, Loopback0

     10.0.0.0/24 is subnetted, 1 subnets

C       10.1.2.0 is directly connected, FastEthernet0/0

S*   0.0.0.0/0 [1/0] via 10.1.2.2

 R2#show run | s router bgp

router bgp 2

 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

 no auto-summary

R2#show ip route

Gateway of last resort is 10.1.2.1 to network 0.0.0.0

     2.0.0.0/32 is subnetted, 1 subnets

C       2.2.2.2 is directly connected, Loopback0

     10.0.0.0/24 is subnetted, 1 subnets

C       10.1.2.0 is directly connected, FastEthernet0/0

S*   0.0.0.0/0 [1/0] via 10.1.2.1

The configuration above is to establish a BGP session between R1 and R2  using their Loopback interfaces.

R1#ping 2.2.2.2 source lo0 

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 2.2.2.2, timeout is 2 seconds:
Packet sent with a source address of 1.1.1.1
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 16/28/52 ms

There is reachability between  R1 and R2 loopbacks, but the BGP sessions won't come up.

R1#show ip bgp neighborsBGP neighbor is 2.2.2.2,  remote AS 1, internal link  BGP version 4, remote router ID 0.0.0.0  BGP state = Active

~~output omitted for brevity~~

   Connections established 0; dropped 0  Last reset never  External BGP neighbor may be up to 2 hops away.  No active TCP connection

Both R1 and R2 are in active state and no TCP session is established even though.

The Rule is simple according to RFC 4271. BGP will only try to Actively initial a TCP session with it's neighbor if it has a specific route to the neighbor.

For BGP peers to for neighbors, one must Actively initiate a session ( the one with the Higher Router-ID ) and the other will be passive. It is negotiated in the BGP Open Message

To test that, we can manually set R1 to try to actively initiate a TCP session with R2 and set R2 be passive. Adding to that, R2 will have a more specific route to R1 loopback address, which is is not supposed to work since R2 is the passive neighbor.

R1(config)#router bgp 1 

R1(config-router)#neighbor 2.2.2.2 transport connection-mode active  

R2(config)#router bgp 2 

R2(config-router)# neighbor 1.1.1.1 transport connection-mode passive 

R2(config)#ip route 1.1.1.1 255.255.255.255 10.1.2.1 

A minute later, the peers are still in active state

R1#show ip bgp neighbors
BGP neighbor is 2.2.2.2,  remote AS 2, external link
  BGP version 4, remote router ID 0.0.0.0
  BGP state = Active  

  ~ommited output~  

  Connections established 0; dropped 0
  Last reset never
  External BGP neighbor may be up to 2 hops away.
  TCP session must be opened actively
  No active TCP connection 

R2#show ip bgp neighbors
BGP neighbor is 1.1.1.1,  remote AS 1, external link
  BGP version 4, remote router ID 0.0.0.0
  BGP state = Active 

  ~ommited output~ 

  Connections established 0; dropped 0
  Last reset never
  External BGP neighbor may be up to 2 hops away.
  TCP session must be opened passively
  No active TCP connection 

Now let's flip it. We will remove the static route from R2 and i will add one on R1 pointing to R2 loopback

R2(config)#no ip route 1.1.1.1 255.255.255.255 10.1.2.1
 R1(config)#ip route 2.2.2.2 255.255.255.255 10.1.2.2
R1(config)#
*Mar  2 08:09:12.324: %BGP-5-ADJCHANGE: neighbor 2.2.2.2 Up 

The session is now UP between R1 and R2.

So, here's are the rules

• For the BGP peer who actively tries to initiate a session with another peer, it must have a specific route
• For the passive peer, it will not matter if the session is over a default-route or a specific route. Both will work
• Once the peering is established, it will not be be affected by the removal of the specific route. unless you cleared the session manually or they lose communication with each other, then the Active BGP peer will need a specific route again.