[f-nsp] VPLS/VLL Redundancy

Lazuardi Nasution mrxlazuardin at gmail.com
Fri Oct 17 10:22:08 EDT 2008


Hi Tomasz,

What if there are some another CEs of the same subscriber/company
which are connected to the same aggregation switch ? I think I must
assign them into the same VLAN for making them to be the same member
of VPLS cloud ? If so, the traffic from a CE to the another CE will
not traverse to VPLS Router. In that case, VLAN based RL on VPLS
Router side cannot be used.

Best regards,

On Fri, Oct 17, 2008 at 4:13 PM, Tomasz Szewczyk <tomeks at man.poznan.pl> wrote:
> Hi,
> I think you can use vlan baser RL but in this case I would suggest to run
> STP on access switches and for some VPLS instances (it is possible on 3.8 or
> 3.9 code on XMR as Topology Group). This would give you better control on
> limits applied for the customer, because you can setup primary and secondary
> active port. I mean something like on attached picture. You can apply the
> same RL on ports A and B. The port B should be blocked by STP, hence all
> customer traffic will be limited by policer on port A. In case of failure
> port B becomes active and all customer traffic will be limited by policer
> applied to port B.
> But this relies on STP - so in my opinion it is the last thing you should do
> ;-) Additional problem is L2 VLAN for STP control. The main disadvantage is
> that VPLS can not be used for STP control, so you have to connect XMRs via
> L2 (in our network we don't have such connections).
>
> Regards
>
> Tomek
>
> Lazuardi Nasution pisze:
>>
>> Hi Tomasz,
>>
>> The configuration is like attached picture. Each aggregation switch is
>> connected to two VPLS Routers as a ring. I use two  VPLS Router for
>> redundancy. Each subscriber device will be connected to one or two
>> aggregation switches side. So, I think the port based rate limitting
>> must be done on aggregation switches. I have no idea if I could use
>> VLAN based rate limitting on the VPLS router side since there are some
>> subsribers which have more than one node connected to the same
>> aggregation switch.
>>
>> Best regards.
>>
>>
>> On Fri, Oct 17, 2008 at 1:48 PM, Tomasz Szewczyk <tomeks at man.poznan.pl>
>> wrote:
>>
>>>
>>> Hi,
>>>
>>>
>>>>
>>>> 1. Anyone has experience with the VPLS/VLL redundancy where each
>>>> subscriber node is connected to diffrent PE Router (NetIron MLX/XMR) ?
>>>> I need some configuration brief about that. The whitepapers are very
>>>> helpful too.
>>>>
>>>>
>>>
>>> We used transparent BPDU flooding over VPLS instance, so it was possible
>>> to
>>> run STP on L2 devices connected to XMRs (bot not on XMRs)
>>> It is possible to enable it on interface:
>>> no vpls-bpdu-block
>>> However I used this only in case when L2 devices were under our
>>> administration. Running this option on customer's interface is a little
>>> bit
>>> risky because in case of L2 loop created by customer, the control plane
>>> of
>>> XMRs can be affected. However there is cpu-protection option, but I think
>>> it
>>> will not protect you against "loop" MAC learning.
>>>
>>>>
>>>> 2. Is it possible to map different VLANs into the same VPLS cloud ?
>>>>
>>>>
>>>
>>> Yes - you just need to type:
>>> vlan xxx
>>> tag/untag e8/1
>>> vlan yyy
>>> tag/untag e8/2
>>>
>>> Or you just setup different VLANs on remote VPLS endpoints. It works :-)
>>>
>>>>
>>>> 3. I need some suggestion of FastIron Edge products which have port
>>>> based incoming and outgoing rate limitting with 64kbps granularity. I
>>>> will combine it on my design with NetIron MLX/XMR for making VPLS/VLL
>>>> provider.
>>>>
>>>>
>>>
>>> Unfortunately I don't have a lot of experiences with FastIron series, but
>>> last times I successfully tested rate-shaping for VPLS based on DSCP in
>>> customer's IP packets. It works fine too :-)
>>>
>>> Regards
>>>
>>> Tomek
>>>
>>>
>>>
>>> ------------------------------------------------------------------------
>>>
>
>
> --
> Tomasz Szewczyk
> Poznan Supercomputing and Networking Center
> e-mail: tomeks at man.poznan.pl
> tel: +48 61 8582020
> fax: +48 61 8525954
>
>



More information about the foundry-nsp mailing list