Cisco vs Juniper: different eBGP behavior

Last week I had to troubleshoot a problem about eBGP peering with an external provider and I think my findings will be interesting for some of you out there.

Let me start with some background information. I have two locations, same ASN, both connected to the same provider network using eBGP as routing protocol. Due to the looping prevention mechanism, default behavior in eBGP peering between Cisco equipment, is not to accept in BGP table prefixes that have in the AS-Path the same ASN as the local BGP router. You can still accept these prefixes, if you use the “allowas-in” trick on Cisco routers:

neighbor x.x.x.x allowas-in

The above command will tell BGP protocol on Cisco routers to ignore the presence of its own ASN in the AS-Path and to accept the prefixes. If all other attributes are in good standing, the routes to those prefixes will be installed in the routing table.

As a short example, take the following tolopogy:

I have a typical eBGP peering configuration. On one of the edge Cisco routers I have a Lo0 interface with 5.5.5.5/32 IP address which I advertise into BGP. Checking the middle Cisco router (provider) I can see that the BGP table has the 5.5.5.5/32 prefix installed:

sh ip bgp 5.5.5.5
BGP routing table entry for 5.5.5.5/32, version 2
Paths: (1 available, best #1, table Default-IP-Routing-Table)
Flag: 0x820
  Advertised to update-groups:
        1
  65082
    10.10.12.1 from 10.10.12.1 (10.10.12.1)
      Origin IGP, metric 0, localpref 100, valid, external, best

Next I check if the provider router does advertise this prefix to the next neighbor:

sh ip bgp neigh 10.10.13.1 advertised-routes | i 5.5.5.5
*> 5.5.5.5/32       10.10.12.1               0             0 65082 i

From this perspective everything is fine. On the edge Cisco router, I cannot see this prefix in the BGP table, which is normal due to the reasons I explained above:

R6#sh ip bgp 5.5.5.5
% Network not in table

As soon as I add the “allowas-in” configuration on the edge Cisco router, the BGP table will contain the prefix 5.5.5.5/32:

router bgp 65082
 no synchronization
 bgp log-neighbor-changes
 neighbor 10.10.13.2 remote-as 65086
 neighbor 10.10.13.2 allowas-in
 no auto-summary

sh ip bgp 5.5.5.5    
BGP routing table entry for 5.5.5.5/32, version 2
Paths: (1 available, best #1, table Default-IP-Routing-Table)
Flag: 0x820
  Not advertised to any peer
  65086 65082
    10.10.13.2 from 10.10.13.2 (10.10.13.2)
      Origin IGP, localpref 100, valid, external, best

Now let take the example when the provider is using Juniper technology. The eBGP peering is now between Cisco and Juniper devices:

I have configured the eBGP in the same way and I have advertised from one Cisco router the 5.5.5.5/32 prefix. 

On Juniper the BGP configuration looks like this:

yotis@J1# run show configuration protocols        
bgp {
    local-as 65086;
    group TST {
        peer-as 65082;
        neighbor 10.10.12.1;
        neighbor 10.10.13.1;
    }
}

Checking on the Juniper device I can see the prefix in the BGP table and routing table:

yotis@J1# run show route protocol bgp receive-protocol bgp 10.10.12.1    
 
inet.0: 7 destinations, 7 routes (7 active, 0 holddown, 0 hidden)
  Prefix		  Nexthop	       MED     Lclpref    AS path
* 5.5.5.5/32              10.10.12.1           0                  65082 I
 
__juniper_private2__.inet.0: 1 destinations, 1 routes (0 active, 0 holddown, 1 hidden)

yotis@J1# run show route 5.5.5.5                                         
 
inet.0: 7 destinations, 7 routes (7 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
 
5.5.5.5/32         *[BGP/170] 01:19:15, MED 0, localpref 100
                      AS path: 65082 I
                    > to 10.10.12.1 via em1.0

On the second Cisco router, I did not change anything. The “allowas-in” command is still there:

router bgp 65082
 no synchronization
 bgp log-neighbor-changes
 neighbor 10.10.13.2 remote-as 65086
 neighbor 10.10.13.2 allowas-in
 no auto-summary

Still the prefix is not in the BGP table:

R6#show ip bgp 5.5.5.5
% Network not in table

Here is a big difference on the way eBGP protocol behave on Cisco vs. Juniper. On Cisco devices, the eBGP will send the prefixes, no matter of the peer ASN and it’s the task of the peer to apply the default policy when its own ASN is present in the AS-Path and deny the prefixes to be installed in the BGP table.

With Juniper, eBGP protocol will not even announce the prefixes if the ASN of its peer is already present in the AS-Path.

According to http://www.juniper.net/techpubs/software/junos/junos94/swconfig-routing/disabling-suppression-of-route-advertisements.html#id-13255463

“The JUNOS software does not advertise the routes learned from one external BGP (EBGP) peer back to the same EBGP peer. In addition, the software does not advertise those routes back to any EBGP peers that are in the same AS as the originating peer, regardless of the routing instance.”

There is a solution to overcome this behavior and it’s pretty simple. You can set this configuration on global basis or per group in Junos BGP configuration:

[edit protocols bgp group TST]
yotis@J1# set advertise-peer-as

Now the BGP configuration looks like this:

yotis@J1# run show configuration protocols        
bgp {
    local-as 65086;
    group TST {
        advertise-peer-as;
        peer-as 65082;
        neighbor 10.10.12.1;
        neighbor 10.10.13.1;
    }
}

If I check now the Cisco BGP table, the 5.5.5.5/32 prefix will be there:

show ip bgp 5.5.5.5
BGP routing table entry for 5.5.5.5/32, version 4
Paths: (1 available, best #1, table Default-IP-Routing-Table)
Flag: 0x820
  Not advertised to any peer
  65086 65082
    10.10.13.2 from 10.10.13.2 (10.10.12.2)
      Origin IGP, localpref 100, valid, external, best

Don’t forget to check my Juniper, first steps after power-on the device if you are new with Juniper products. You may be interested also in my older posts Cisco: BGP path selection for outgoing traffic and Cisco: BGP path selection for inbound traffic if you just start to work with external providers.