vMX

Expand all | Collapse all

advertise-peer-as question

  • 1.  advertise-peer-as question

    Posted 10-25-2020 10:58

    I have a simple topology as follows:

    R1 (65100)  -------- R2 (5104) --------- R3(65100)  (lo0.0 3.3.3.3)

    if R1 accepts 3.3.3.3, either I can configure loops 1 on R1 or I can configure as-override on R2.

    When I configure advertise-peer-as on R2, R1 still needs loops 1, so why should I use advertise-peer-as ?

    thanks !!

     



  • 2.  Re: advertise-peer-as question

    Posted 30 days ago

    By default, Junos doesn't advertise the routes if the neighboring AS number is already in the AS path of the respective route. To make sure Junos doesn't follow the default behavior "advertise-peer-as" is needed in place and the remote peer needs "loops".

     

    The catch here is, the above mentioned behavior is different on other vendors, in some vendor the routers advertises the route without noticing the AS path and the remote peer has the responsibility of dropping the concerned route when seeing its own AS in the AS path. So the loop prevention responsibility is simply on the receiving router.



  • 3.  Re: advertise-peer-as question

    Posted 30 days ago

    thanks so much !!



  • 4.  Re: advertise-peer-as question

    Posted 30 days ago

    Hello,

    "advertise-peer-as" is a knob to provide backwards compatibility between RFC1771-compliant speakers and RFC4271-compiant speakers.

    RFC 1771 section 9.1.3 https://tools.ietf.org/html/rfc1771 states:

     

    For the benefit of future support of inter-AS multicast capabilities,
       a BGP speaker that participates in inter-AS multicast routing shall
       advertise a route it receives from one of its external peers and if
     it installs it in its Loc-RIB, it shall advertise it back to the peer
       from which the route was received. For a BGP speaker that does not
       participate in inter-AS multicast routing such an advertisement is
       optional.

     

    The above text is not present in RFC4271. Hence, a RFC4271-compliant speaker shall use "advertise-peer-as" knob when talking to RFC1771-compliant speaker that expects own routes back.

    As to what RFC1771-compliant speaker needs to do with own routes, is left out of the BGP spec and is therefore implementation-specific.

    Finally, apart from the above purpose, using "advertise-peer-as" and "loops" is certainly possible but it is a complex way to do simple things when better tools are available such as "as-override".

    HTH

    Thx

    Alex

     

     



  • 5.  Re: advertise-peer-as question

    Posted 30 days ago

    thanks a lot !!