[f-nsp] VPLS/VLL Redundancy
Tomasz Szewczyk
tomeks at man.poznan.pl
Tue Oct 21 05:40:44 EDT 2008
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
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> ------------------------------------------------------------------------
>>>>>>
>>>>>>
>>>>>>
>>
More information about the foundry-nsp
mailing list