Routing
Highlighted
Routing

Understanding how IBGP/EBGP behaves in JunOS

‎12-30-2016 01:05 AM

Hello,


I am trying to understand how IBGP and EBGP behave in JunOS and I find that the official documentation is in no way enough to understand what is going on.

 

What surprised me was that everything I advertised into IBGP was being re-advertised to my neighbor ASes through EBGP. I find that not very useful and I'm trying to understand if there are any other gotchas.

 

Can anyone here confirm that the following is correct?

 

Default JunOS IBGP behavior:

export routes that the localhost learned through EBGP
import routes that remote hosts learned through EBGP

 

Default JunOS EBGP behavior:
export routes that the localhost learned through EBGP or IBGP (!)
import routes that the remote hosts learned through EBGP or IBGP

1 REPLY 1
Highlighted
Routing
Solution
Accepted by topic author ka_ge
‎01-03-2017 04:35 AM

Re: Understanding how IBGP/EBGP behaves in JunOS

[ Edited ]
‎12-30-2016 03:00 AM

 Hi,

Yes, you are almost correct and please find the details on BGP route handling in Junos in a simple words, by default, only active BGP routes are advertised.

 

The rules are as simple as follows:
1. IBGP peers advertise routes received from EBGP peers to other IBGP peers.
2. EBGP peers advertise routes learned from IBGP or EBGP peers to other EBGP peers.

 

To be Noticed: IBGP peers do not advertise routes received from IBGP peers to other IBGP peers[unless it is functioning as a route reflector]. The purpose of the advertisement rules is to prevent routing loops on a BGP network.

 

A full mesh is required to ensure all IBGP speakers have consistent BGP routing information. Because of the internal BGP (IBGP) full-mesh requirement, most networks use route reflectors to simplify configuration. The formula to compute the number of sessions required for a full mesh is v * (v - 1)/2, where v is the number of BGP-enabled devices. The full-mesh model does not scale well. Using a route reflector, you group routers into clusters, which are identified by numeric identifiers unique to the autonomous system (AS). Within the cluster, you must configure a BGP session from a single router (the route reflector) to each internal peer. With this configuration, the IBGP full-mesh requirement is met.

 

Reiterating your statement as below:

 

Default JunOS IBGP behavior:

Export routes that the localhost learned through EBGP
Import routes to its own routing table learned through EBGP or IBGP  Peers<<<<

 

Default JunOS EBGP behavior:
Export routes that the localhost learned through EBGP or IBGP (!)
Import routes to its own routing table learned through EBGP or IBGP Peers

 

Importing or Exporting Protocol

Default Import Policy

Default Export Policy

BGP

Accept all received BGP IPv4 routes learned from configured neighbors and import into the inet.0 routing table. Accept all received BGP IPv6 routes learned from configured neighbors and import into the inet6.0 routing table.

Readvertise all active BGP routes to all BGP speakers, while following protocol-specific rules that prohibit one IBGP speaker from readvertising routes learned from another IBGP speaker, unless it is functioning as a route reflector.

 

http://www.juniper.net/documentation/en_US/junos13.3/topics/concept/policy-routing-policies-actions-...

 

-Python

#Please mark my solution as accepted if it helped, Kudos are appreciated as well.

 
-Python JNCIE 3X [SP|DC|ENT] JNCIP-SEC JNCDS 3X [ WAN | DC|SEC] JNCIS-Cloud JNCIS-DevOps CCIP ITIL
#Please mark my solution as accepted if it helped, Kudos are appreciated as well.