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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> >> 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: [EMAIL PROTECTED] > tel: +48 61 8582020 > fax: +48 61 8525954 > > _______________________________________________ foundry-nsp mailing list [email protected] http://puck.nether.net/mailman/listinfo/foundry-nsp
