Routing

 View Only
last person joined: 2 days 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.  InterAS VPNs Option C

    Posted 03-01-2024 11:11

    Hello,  

    I am new to this forum and not sure how the search  works but I have a question/scenario that is not working regarding interas l3vpns.  I have a working lab where the loopbacks are exchanged between ASNs using BGP-LU.  L3vpns can talk between ASNs.  However, I'm looking at a concept where we send only an anycast address at the ASBRs and the route reflectors change the nexthop to the anycast address.  Thus each ASN only gets the anycast address and not all the loopbacks via BGP-LU.  This concept works on routes in the inet.0 table but not on bgp.l3vpn table.  I can see that the label swap changes the vpn label as the ASBR when I set the next-hop to the anycast address.  The anycast address does show up as a mpls tunnel prefix in the peering asn just like the loopback address.   

    Not sure if this possible to use an anycast address as protocol next-hop with bgp.l3vpn routes in option c.



    ------------------------------
    GARY RUBEL
    ------------------------------


  • 2.  RE: InterAS VPNs Option C

    Posted 03-04-2024 10:06

    Hi Gary,

    As far as I know, Inter-AS VPN Option C is used for one sole reason - to allow creation of Inter-AS MPLS services, both L2 and L3 in a fully transparent way - i.e. using the full mesh of E2E transport LSPs to carry service-related traffic. If you want to use anycast you are breaking the true nature of that concept and you are actually tring to re-invent Option B. Why don't you then just simply use Option B? What are you trying to achieve here?

    Also, it's not clear to me where the anycast NH terminates. On which router? Anycast would probably mean that you assign the same IP address to the loopback of several routers in the network.

    Maybe I'm missing something here? Thanks!



    ------------------------------
    Berislav Todorovic
    ------------------------------



  • 3.  RE: InterAS VPNs Option C

    Posted 03-04-2024 10:57
    Edited by GARY RUBEL 03-04-2024 11:07

    Hi Berislav, 

    Thanks for the reply.  My interest behind trying this method is two-fold,

    1.  Security -> Say you don't want to exchange BGP-LU loopbacks due to security reasons since it exposes the internal network routers.   I've thought about  using secondary loopbacks as well but it still exposes all your devices.
    2. ASBR capabilities -> Say your ASBR has limited resources and gets a full Internet table from a couple of IBGP route reflectors.  Peering with another AS using Option B may hit the ASBRs limit if one provider has a large Internet presence as well.

    From the drawing, say you have two peering points.  Those two ASBRs would originate the same anycast address locally that is used for the next-hop like option B does.  The anycast address would be advertised to the other AS based on a condition like reachability to the internal route reflectors.  Thus, if one ASBR loses its internal RR connections the other peering point would be used.  This works great for inet.0 routes but not for anything that requires BGP-LU paths. 

    Taking my two points into consideration, I was just curious if somehow an Option B/C hybrid could be implemented as the ASBRs would have the internal bgp next-hop to the destination PE.  Basically use OptionB but will full routes being exchanged between route reflector instead of the ASBRs.  The ASBRs would only advertise the RR loopbacks via inet.0 and the anycast via inet.3

     Not sure if all that is clear.

    thanks



    ------------------------------
    GARY RUBEL
    ------------------------------



  • 4.  RE: InterAS VPNs Option C

    Posted 03-04-2024 15:38

    Hi Gary,

    When you follow the anycast IP NH your packets will follow the LSP terminated on the ASBR, where that anycast IP address is being assigned to. Then, the top-of-stack (transport) label will go away and the ASBR will try to interpret the next label in stack, which is the VPN service label. Since it won't find the VPN label in its MPLS table - game over.

    OTOH, if you establish the MP-eBGP multihop session between two non-ASBR PE routers or on-path RRs (instead of off-path RRs) and associate the anycast IP with those PE routers - things will work, because those PEs will have the knowledge about the service (VPN) label. You can then use next-hop self (or set NH to the anycast IP address associated with the loopback). That works!

    Another possibility is to wait until draft-zzhang-bess-vpn-option-bc gets imlemented (see link).



    ------------------------------
    Berislav Todorovic
    ------------------------------