[j-nsp] vpls question

Ben Dale bdale at comlinx.com.au
Mon Apr 27 05:40:36 EDT 2015


On 27 Apr 2015, at 5:57 pm, james list <jameslist72 at gmail.com<mailto:jameslist72 at gmail.com>> wrote:

Well indeed OSPF is running also with customer peer in the other side of the MPLS cloud (CE2) and PE3/4 (still other side)... and it's due by customer requested design to have VPLS and OSPF on the PEs...

So I understand that putting "protocols vpls connectivity-type irb" do not solve...

I'm wondering why and the expected behaviour...


If you have a VPLS with two PEs joining to one CE at each site, you've created two loops, one at each site.

Standard behaviour is to define both PEs as a single "site" in the VPLS and use multi-homing and site-preference to keep one PE-CE interface inactive until such time as the other is required as already mentioned.

You can't run OSPF across both links without bringing them both up, which will create an L2 loop - these things are mutually exclusive.

The "protocols vpls connectivity-type irb" will keep the instance up if you have irbs defined and the PE-CE link goes down, but this doesn't really help you though.

It might be time to break out the sock puppets and have a robust discussion with your customer.


cheers
James

2015-04-27 0:36 GMT+02:00 Ben Dale <bdale at comlinx.com.au<mailto:bdale at comlinx.com.au>>:
Hi James,

On 27 Apr 2015, at 5:31 am, james list <jameslist72 at gmail.com<mailto:jameslist72 at gmail.com>> wrote:

> Hi amarjeet
> Because if PE1 fails there is faster convergence to PE2 due to neighbor
> already established.
>

Is there a reason you wouldn't consider using an L3VPN instead of a VPLS?  It seems odd to me that you would be using L3 adjacencies to an L2 service.

If it really is L2 fail-over you are chasing, then Amarjeet is correct - multihoming and site-preference are designed for exactly this purpose.

If you customer requires L3 connectivity across your VPLS, you would be better off carrying their OSPF across the VPLS and let their CEs form adjacencies with each other - that way, you can take care of L2 fail-over, and the customer is responsible for L3.

Cheers,

Ben



> Cheers
> James
> Il 24/apr/2015 13:23, "james list" <jameslist72 at gmail.com<mailto:jameslist72 at gmail.com>> ha scritto:
>
>> I have a VPLS multi-homed environment with two MX routers (PE1 and PE2)
>> connected to a single ethernet switch (CE1). I have PE1 configured with
>> site-preference as "primary" and PE2 as "backup".
>>
>>
>> Behind the CE1 there is a router running OSPF with both MX (on irb
>> interface).
>>
>>
>> My goal is to have:
>>
>> 1)    Multihoming to prevent loops
>>
>> 2)    Let the router run two OSPF neighbor with both PE and not just one
>> with the primary PE.
>>
>> I’m wondering if using:
>>
>>
>> set routing-instances XXXX protocols vpls connectivity-type irb
>>
>>
>> instead of the default (connectivity-type ce) could give me the option to
>> reach my goal number 2) and if I can introduce any drawback.
>>
>>
>> Or if there is another solution keeping 1).
>>
>>
>> I don’t have a lab to test…
>>
>>
>> Any help/feedback is really appreciated.
>>
>>
>> Greetings
>>
>> James
>>
> _______________________________________________
> juniper-nsp mailing list juniper-nsp at puck.nether.net<mailto:juniper-nsp at puck.nether.net>
> https://puck.nether.net/mailman/listinfo/juniper-nsp





More information about the juniper-nsp mailing list