Routing

 View Only

IMPORTANT MODERATION NOTICE

This community is currently under full moderation, meaning  all posts will be reviewed before appearing in the community. Please expect a brief delay—there is no need to post multiple times. If your post is rejected, you'll receive an email outlining the reason(s). We've implemented full moderation to control spam. Thank you for your patience and participation.



  • 1.  MPLS L3VPN bookdoor link scenario

    Posted 03-28-2011 13:27

    Hi Experts

     

    I have one scenario for MPLS L3VPN with back door link b/w CE. You are providing L3VPN Services and PE-CE protocol is BGP. CE are using private AS number and as-override is configured. Customer is using some backdor p-t-p links. How to be sure no routing loop is formed without using communities ( i.e. SITE OF ORIGIN ) ?

     

    I followed this document http://www.juniper.net/techpubs/software/junos/junos95/swconfig-vpns/id-10296579.html

     

    But I have question about this scenario:

     

    1- How loop is forming? Does it means CE1 routes are going over the back door link to CE2 and then CE2 to PE2 and PE2 to PE1 and PE1 to CE1 again?

     

    2- If we reject the CE2 routes coming from PE2 on PE1 and viceversa so if backdoor b/w CEs are down then they can not use the MPLS L3 VPN in this case because we are rejecting the routes of each CE at opposite PE?

     

    Thanks



  • 2.  RE: MPLS L3VPN bookdoor link scenario

    Posted 04-01-2011 06:38


  • 3.  RE: MPLS L3VPN bookdoor link scenario

    Posted 04-03-2011 01:36

    Hi

     

    But I am not using the OSPF as CE-PE



  • 4.  RE: MPLS L3VPN bookdoor link scenario

    Posted 04-04-2011 00:28

    Hi,

     

    Sorry, didn’t pay attention to PE-CE protocol…

    In this case yes, you seem to be right regarding 1st and 2nd point.

    One workaround that I see in this situation is the usage of “conditional advertising”, this way you can attach SOO on CE1 advertised routes to PE1 only if backdoor link exist (the route to the CE2 loopback is in the CE1 routing-table, or indirect static route…), the same should be accomplished on CE2.(Pay attention that CE1 and CE2 loopbacks should not be advertised to PE routers...)

    This will solve the problems related to 1st and 2nd point.

     

    On CE1:

    [edit]

    policy-options {

    policy-statement export-to-my-isp {

    term a {

    from {

    protocol direct;

    condition CE2-SOO;

    }

    then {

    community add my-soo;

    accept;

    }

    }

    term b {

    from {

    protocol direct;

    }

    then {

    accept;

    }

    }

    }

    Condition CE2-SOO {

          if-route-exists {

                1.1.1.1/32;//CE2 loopback address

                table inet.0;

          }

    }

    }

     

    This way if the CE2 loopback won't be in CE1 routing-table, the CE1 prefixes will be advertised to PE without SOO.

     



  • 5.  RE: MPLS L3VPN bookdoor link scenario

    Posted 04-06-2011 11:07

    Thanks for your reply. Lets say I do not have access to CE then what is the solution on PE routers? In first place I am not able to understand how this topology will create a loop? because always CE will prefer the IBGP routes from eachother not from the PE as this route have longer AS-PATH length.



  • 6.  RE: MPLS L3VPN bookdoor link scenario
    Best Answer

    Posted 04-07-2011 04:10
      |   view attached

    Hi,

     

    Let's start with the fact that in the case depicted in your link, there's no way a routing loop can occur.

    In a little more complex scenario a routing loop can easily occur.(see attach)

    In this topology, administrators want all outbound traffic(inter-site) to pass though CE2-PE2, and they set the local-pref for all prefixes received from PE2 to 200.

    From the attached topology lets assume that S1 wants to communicate to S2, the traffic will be forwarded on the following path:

    CE1---CE2---PE2---PE1---CE1---CE2----PE2---and so on.... ROUTING LOOP is due to the higher local-pref set for the prefixes received from PE2.

     

    As you wrote, the CE routers are outside of ISP domain and that's the reason it's desirable to set SOO for dual-homed sites, because you never know what's in their mind, like in this sample topology a simple "local-pref" can be very harmful.


    #MPLSL3VPNbackdoorlinkscenario
    #RoutingLoopbymissingSOO


  • 7.  RE: MPLS L3VPN bookdoor link scenario

    Posted 04-07-2011 08:36

    Thanks.. that was a very good explanation of how loop can form.



  • 8.  RE: MPLS L3VPN bookdoor link scenario

    Posted 04-10-2011 01:09

    Hi dpapana  

     

    Simply you are the expert 😉 Just last thing is in order to avoid this, on PE1 I will tag the routes coming from CE1 using SOO (say SSO-1) and on PE2 I would match the SOO-1 and reject the rotues. On PE2 should I reject these routes when importing the routes via MBGP OR when exporting these routes to CE2 from VRF?

     

    Thanks



  • 9.  RE: MPLS L3VPN bookdoor link scenario

    Posted 04-11-2011 09:15

    You have to filter prefixes with SOO-1 in export policy to CE routers...



  • 10.  RE: MPLS L3VPN bookdoor link scenario

    Posted 04-12-2011 01:36

    Hi

     

    Thanks for the reply. But what is the harm if I reject the routes on PE while importing the routes in VRF?

     

     



  • 11.  RE: MPLS L3VPN bookdoor link scenario

    Posted 04-15-2011 03:49

    No harm, either way is acceptable.