BGP Peering and Default Routes

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.

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 9 ratings

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