Routing

 View Only
last person joined: 13 hours ago 

Ask questions and share experiences about ACX Series, CTP Series, MX Series, PTX Series, SSR Series, JRR Series, and all things routing, including portfolios and protocols.
  • 1.  Understanding how IBGP/EBGP behaves in JunOS

    Posted 12-30-2016 01:05

    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


    #IBGP
    #ebgp


  • 2.  RE: Understanding how IBGP/EBGP behaves in JunOS
    Best Answer

     
    Posted 12-30-2016 03:00

     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-defaults.html

     

    -Python

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