[f-nsp] VPLS/VLL Redundancy

[Lazuardi Nasution]

Hi Tomasz,

Both VLAN should be bridged to be same broadcast domain on a VPLS
cloud. I'm using the different VLAN for making sure that the traffic
will traverse through the VPLS Router. If I'm using the same VLAN, the
traffic will not traverse through VPLS Router since the nodes are
connected to the same Aggregation Switch.

Best regards,

On Tue, Oct 21, 2008 at 4:40 PM, Tomasz Szewczyk <tomeks at man.poznan.pl> wrote:
> Hi,
>
> In my opinion, in this case you will connect two customer's VLANs on L2. I
> mean in this configuration you will make on XMR L2 bridge between those two
> VLANs.
> If this is what you wanted - it will work. If you would like to "aggregate"
> customer's VLANs into single VPLS cloud without enabling bridging between
> them, I think you should use QinQ (probably on aggregation switch).
>
> Best Regards
>
> Tomek
>
> Lazuardi Nasution pisze:
>>
>> Hi Tomasz,
>>
>> What happen if I attach some differents VLAN on the same VPLS cloud ?
>> Let assume that each node is connected to the same VPLS Router via the
>> same Aggregation Switch with following scripts.
>>
>> On the VPLS Router:
>> vpls CompanyA 10000
>>   vlan 100
>>      tag ethernet 1/1 -> this port is connected to Aggregation Switch
>>   vlan 200
>>      tag ethernet 1/1 -> this port is connected to Aggregation Switch
>>
>> On Aggregation Switch:
>> vlan 100
>>   untag ethernet 1/1 -> this port is connected to Node A1 of Company A
>>   tag ethernet 1/24 -> this port is connected to VPLS Router
>> vlan 200
>>   untag ethernet 1/2 -> this port is connected to Node A2 of Company A
>>   tag ethernet 1/24 -> this port is connected to VPLS Router
>>
>> If we can use that script with no problem, I think we can use VLAN
>> Based Rate Limit since each node of same subscriber/company can be
>> mapped to different VLAN.
>>
>> Best regards,
>>
>> On Mon, Oct 20, 2008 at 2:58 PM, Tomasz Szewczyk <tomeks at man.poznan.pl>
>> wrote:
>>
>>>
>>> Hi,
>>>
>>> I think now I got your point. In my opinion placing the RLs depends on
>>> what
>>> is the service definition for the customer. I think the simplest solution
>>> is
>>> to put RL on access interface, but in case of VPLS-like services
>>> (many-to-many) it is not so easy to predict traffic amount in the core.
>>> For
>>> example if customer wants to connect 5 sites with 100Mbps, I would put
>>> input
>>> rate-limit and output rate-shaping (both 100Mbps) for each access
>>> interface.
>>> RL should limit traffic entering the core and priority/DSCP based rate
>>> shaping avoid (or manage) congestion on output interface.
>>>
>>> Best Regards
>>>
>>> Tomek
>>>
>>> Lazuardi Nasution pisze:
>>>
>>>>
>>>> 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
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> ------------------------------------------------------------------------
>>>>>>>
>>>>>>>
>>>>>>>
>>>
>>>
>
>