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:

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:

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

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:

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:

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:

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

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

Still the prefix is not in the BGP 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:

Now the BGP configuration looks like this:

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

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.


Cisco vs Juniper: different eBGP behavior

One thought on “Cisco vs Juniper: different eBGP behavior

  • November 11, 2013 at 19:03
    Permalink

    Hello, this is definitely an informative post. Thanks !
    I also had a question though. Consider this setup: SiteA — ISP — Site B . Both sites have same AS, and have allowas-in configured. So doesn’t that mean that the SiteA will also receive the routes back from the ISP/Transit and create multiple entries of that route ?

    Reply

Leave a Reply

%d bloggers like this: