BGP Peering and Default Routes

By Marko Milivojevic on November 8th, 2010

One of the interesting restrictions of BGP is that neighbor will not establish BGP session with a peer if the only way to reach it is through the default route. Is there anything we can do in that scenario?

First of all, let’s try to reproduce the problem. We will use the simple network shown on the diagram below for this purpose.

Diagram

In the network we will use, R2 is a hub to which other routers connect to. R1 and R2 are connected in OSPF NSSA area 12 and R2 originates the default route to R1. See below.

R1:

router ospf 1
 area 12 nssa
 network 0.0.0.0 255.255.255.255 area 12
!
R1#show ip route | begin Gateway
Gateway of last resort is 12.12.12.2 to network 0.0.0.0

O*IA  0.0.0.0/0 [110/65] via 12.12.12.2, 00:35:15, Serial1/0
      1.0.0.0/32 is subnetted, 1 subnets
C        1.1.1.1 is directly connected, Loopback0
      12.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
C        12.12.12.0/24 is directly connected, Serial1/0
L        12.12.12.1/32 is directly connected, Serial1/0

R2:

router ospf 12
 area 12 nssa no-summary
 network 2.2.2.2 0.0.0.0 area 0
 network 12.12.12.2 0.0.0.0 area 12
!
R2#show ip route ospf | begin ^Gateway
Gateway of last resort is 0.0.0.0 to network 0.0.0.0

      1.0.0.0/32 is subnetted, 1 subnets
O        1.1.1.1 [110/65] via 12.12.12.1, 00:35:54, Serial1/0

R2 and R3 are using RIPv2. Again, R2 is the one originating the default route.

R3:

router rip
 version 2
 passive-interface default
 no passive-interface Serial1/1
 network 0.0.0.0
 no auto-summary
!
R3#show ip route | begin ^Gateway
Gateway of last resort is 23.23.23.2 to network 0.0.0.0

R*    0.0.0.0/0 [120/1] via 23.23.23.2, 00:00:26, Serial1/1
      3.0.0.0/32 is subnetted, 1 subnets
C        3.3.3.3 is directly connected, Loopback0
      23.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
C        23.23.23.0/24 is directly connected, Serial1/1
L        23.23.23.3/32 is directly connected, Serial1/1

R2:

router rip
 version 2
 passive-interface default
 no passive-interface Serial1/1
 network 23.0.0.0
 default-information originate
 no auto-summary
!
R2#show ip route rip | begin ^Gateway
Gateway of last resort is 0.0.0.0 to network 0.0.0.0

      3.0.0.0/32 is subnetted, 1 subnets
R        3.3.3.3 [120/1] via 23.23.23.3, 00:00:15, Serial1/1

Finally, R2 and R4 are using EIGRP. You guessed right – R2 originates the default to R4.

R4:

router eigrp 24
 network 0.0.0.0
 no auto-summary
!
R4#show ip route | begin ^Gateway
Gateway of last resort is 24.24.24.2 to network 0.0.0.0

D*    0.0.0.0/0 [90/2297856] via 24.24.24.2, 00:37:28, Serial1/2
      4.0.0.0/32 is subnetted, 1 subnets
C        4.4.4.4 is directly connected, Loopback0
      24.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
C        24.24.24.0/24 is directly connected, Serial1/2
L        24.24.24.4/32 is directly connected, Serial1/2

R2:

router eigrp 24
 network 24.24.24.2 0.0.0.0
 no auto-summary
!
interface Serial1/2
 ip summary-address eigrp 24 0.0.0.0 0.0.0.0
!
R2#show ip route eigrp | begin ^Gateway
Gateway of last resort is 0.0.0.0 to network 0.0.0.0

D*    0.0.0.0/0 is a summary, 00:38:27, Null0
      4.0.0.0/32 is subnetted, 1 subnets
D        4.4.4.4 [90/2297856] via 24.24.24.4, 00:39:18, Serial1/2

To sum this up, we can see that R2 has full visibility of all network, while other routers receive only default route from R2. We also have full reachability in the network. To preserve space, we’ll run the test only from R1, but it will work from all other routers as well.

R1:

R1#tclsh
R1(tcl)#foreach ip {
+>(tcl)#1.1.1.1
+>(tcl)#2.2.2.2
+>(tcl)#3.3.3.3
+>(tcl)#4.4.4.4
+>(tcl)#} { ping $ip source Loopback0 repeat 3 timeout 1 }

Type escape sequence to abort.
Sending 3, 100-byte ICMP Echos to 1.1.1.1, timeout is 1 seconds:
Packet sent with a source address of 1.1.1.1
!!!
Success rate is 100 percent (3/3), round-trip min/avg/max = 4/4/4 ms
Type escape sequence to abort.
Sending 3, 100-byte ICMP Echos to 2.2.2.2, timeout is 1 seconds:
Packet sent with a source address of 1.1.1.1
!!!
Success rate is 100 percent (3/3), round-trip min/avg/max = 8/9/12 ms
Type escape sequence to abort.
Sending 3, 100-byte ICMP Echos to 3.3.3.3, timeout is 1 seconds:
Packet sent with a source address of 1.1.1.1
!!!
Success rate is 100 percent (3/3), round-trip min/avg/max = 16/18/20 ms
Type escape sequence to abort.
Sending 3, 100-byte ICMP Echos to 4.4.4.4, timeout is 1 seconds:
Packet sent with a source address of 1.1.1.1
!!!
Success rate is 100 percent (3/3), round-trip min/avg/max = 16/17/20 ms
R1(tcl)#tclquit

BGP Configuration

To begin with, let’s configure BGP between R1 and R2 using Loopback0 as update-source. We will use iBGP.

R1:

router bgp 1234
 bgp router-id 1.1.1.1
 neighbor 2.2.2.2 remote-as 1234
 neighbor 2.2.2.2 update-source Loopback0
!

R2:

router bgp 1234
 bgp router-id 2.2.2.2
 neighbor 1.1.1.1 remote-as 1234
 neighbor 1.1.1.1 update-source Loopback0
!

If our premise is correct, nothing should happen, as BGP will not work from R1 to R2. However, after just couple of seconds, we should be seeing the following message on R1:

 %BGP-5-ADJCHANGE: neighbor 2.2.2.2 Up

How is this possible when the only route to 2.2.2.2 is the default route? Well, let’s examine this session a little bit. To do that, we’ll use “show ip bgp neighbor” command. We don’t need all the output for what I’m trying to illustrate, so I will filter it out a little bit using regular expressions and wonderful “| include” command modifier.

R1:

R1#show ip bgp neighbors 2.2.2.2 | include ^(Connection state|(Local|Foreign) host)
Connection state is ESTAB, I/O status: 1, unread input bytes: 0
Local host: 1.1.1.1, Local port: 179
Foreign host: 2.2.2.2, Foreign port: 13877

This looks normal, but there is one thing I’d like to especially point out. Look at the port numbers. Local port is 179 (BGP) and remote port is random high number. This means that it was R2 that initiated the session and R1 just accepted it. Let’s try to force the reverse.

R1:

router bgp 1234
 neighbor 2.2.2.2 transport connection-mode active
!

R2:

router bgp 1234
 neighbor 1.1.1.1 transport connection-mode passive
!

After clearing the sessions we don’t see the session being enabled. It’s time to call debug to assistance.

R1:

R1#debug ip bgp ipv4 unicast

Sure enough, after just few seconds, we’ll see the log message similar to the one below:

BGP: 2.2.2.2 Active open failed - no route to peer, open active delayed 13312ms (35000ms max, 60% jitter)

Conclusions

There are two important lessons we should learn here:

  1. It is true that BGP will not actively open (initiate) BGP session with a peer if the only route to it is the default route.
  2. If at least one of the peers has a more specific route to its peer and it actively opens the session, peer that has the default route to it will passively open (accept) the session.

This doesn’t really help us for the situation in which both peers have only default routes to each other. What do we do then?

Double Default

Let’s now focus on R3 and R4. They both have only default routes, but they can surely ping each other.

R3:

R3#ping 4.4.4.4 source Loopback0

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 4.4.4.4, timeout is 2 seconds:
Packet sent with a source address of 3.3.3.3
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 16/17/20 ms

Knowing what we learned in the last exercise, if we simply configure BGP between them, the session should not come up. Let’s put this knowledge to the test – with debug enabled.

R3:

router bgp 1234
 bgp router-id 3.3.3.3
 neighbor 4.4.4.4 remote-as 1234
 neighbor 4.4.4.4 update-source Loopback0
!

R4:

router bgp 1234
 bgp router-id 4.4.4.4
 neighbor 3.3.3.3 remote-as 1234
 neighbor 3.3.3.3 update-source Loopback0
!

After turning on the debug (using “debug ip bgp ipv4 unicast”), both routers will very soon let us know that they don’t have the routes to each other. At first glance, a hopeless situation.

In a sense, it is, but it’s not an unsolvable problem. Remember, routers are reachable, which mwans we could trick them into thinking they are directly connected using GRE tunnel. Of course, that means running a routing protocol over the tunnel or using static routes. Let’s take a look at that solution.

R3:

interface Tunnel34
 ip unnumbered Loopback0
 tunnel mode gre ip
 tunnel source Serial1/1
 tunnel destination 34.34.34.4
!
router ospf 1
 network 3.3.3.3 0.0.0.0 area 0
!

R4:

router ospf 1
 network 4.4.4.4 0.0.0.0 area 0
!
interface Tunnel34
 ip unnumbered Loopback0
 tunnel mode gre ip
 tunnel source Serial1/2
 tunnel destination 23.23.23.3
!

In just couple of seconds, our BGP neighbors will come up and our problem has been solved.

Happy studies!

BGP Peering and Default Routes, 4.4 out of 5 based on 10 ratings
Be Sociable, Share!

    Tags: BGP, CCIE, CCIE Routing & Switching, CCIE Service Provider, default route

    12 Responses to “BGP Peering and Default Routes”

    1. Daniel says:

      It’s not as pretty, but if you care a static route will also work just pointing out the same direction your default route goes

      if your using a loop-back you’ll need a static for that also though (if going though lots of routers you’ll want to redistribute them into the routing protocol)

      VA:F [1.9.22_1171]
      Rating: 0.0/5 (0 votes cast)
    2. Amit says:

      This is a nice thing to be aware of. Good one. Thanks Marko.

      VA:F [1.9.22_1171]
      Rating: 1.0/5 (1 vote cast)
    3. Rohit says:

      Found the EXACT same issue on one of the routers. Excellent post, Marko. Thank you!

      VA:F [1.9.22_1171]
      Rating: 0.0/5 (0 votes cast)
    4. Dean says:

      I have also seen the error:
      Active open failed – no route to peer, open active delayed

      When the BGP TCP connection failed due to a missing ebgp-multihop command. It is quite confusing because you can see the route in the RIB (not as default either) and you get this same message.

      Anyway, stumped me for a bit so thought I would share it.

      VA:F [1.9.22_1171]
      Rating: 0.0/5 (0 votes cast)
    5. wintermute000 says:

      One question, are the configs incomplete? As in for R1/R2 OSPF, what command is sending the default route from R2 to R1 for example? I don’t see a static w/ redistribute or default information originate for example.

      VA:F [1.9.22_1171]
      Rating: 0.0/5 (0 votes cast)
    6. Learned Something says:

      OH!.. this just got me. Adding a backdoor for a client and wanted to lab up my redistribution. Literally typed the bgp part in as fast as I could and minutes later realized nothing was happening. How in the world could I possibly not know what I am doing with a 5-line BGP config with 5 routers? I looked for maybe 15 minutes (while making sure my EBGP multi was correct). I stumbled on this and I don’t think I ever realized this was a requirement. Great article.. and great work around needing to put a static in.

      VA:F [1.9.22_1171]
      Rating: 0.0/5 (0 votes cast)
    7. [...] Today 01:34 PM #19 http://blog.ipexpert.com/2010/11/08/…efault-routes/ One of the interesting restrictions of BGP is that neighbor will not establish BGP session with [...]

    8. Vinod Sharma says:

      The tunnel solution wil not work, as it is not working in my test lab.

      R1#sh run int tun 0
      Building configuration…

      Current configuration : 113 bytes
      !
      interface Tunnel0
      ip unnumbered Loopback0
      tunnel source FastEthernet0/0
      tunnel destination 192.168.1.2
      end

      R1#sh ip inter brief | ex una
      Interface IP-Address OK? Method Status Protocol
      FastEthernet0/0 192.168.1.1 YES manual up up
      Loopback0 1.1.1.1 YES manual up up
      Tunnel0 1.1.1.1 YES TFTP up up
      R1#sh ip route 2.2.2.2
      % Network not in table
      R1#sh ip bgp summ | be 2.2.2.2
      2.2.2.2 4 2 299 299 0 0 0 00:05:51 Active

      Please correct me if i am wrong.

      VA:F [1.9.22_1171]
      Rating: 0.0/5 (0 votes cast)
    9. Chris says:

      Awesome article. I understand RFC 4271 addresses the restriction of BGP not establishing a TCP session when the peer is reachable via a default route, but I just can’t seem to find that wording. Could you highlight that wording in the actual RFC? Thanks!

      VA:F [1.9.22_1171]
      Rating: 0.0/5 (0 votes cast)

    Leave a Reply