Dimitar,<br><br>My routers will connect to a number of different access providers, and we have found it very difficult to make our access providers choose vlans that don't overlap with each other. Also, one of our access providers are delivering all circuits QinQ encapsulated, so there *will* be overlap there as well (but only on the outer vlan).<br>
<br>I hope that clarifies it.<br><br>If we didn't have this provider, that terminates with QinQ encapsulation, my solution would have been to add a PVLAN, but since I've never seen equipment that handles QinQinQ, it's not an option.<br>
<br>How does the MLX/XMR handle QinQ by the way? Since this is an unusual way of dealing with QinQ, let me exemplerize a bit:<br><br>Normal QinQ approach would be one outer VLAN to a customer, where you would typically have a voice vlan and a data vlan inside your outer vlan. <br>
We have one access provider that gives us circuits with two vlan tags with no apparent system. On a cisco router, I would configure a link like this:<br><br>interface GigabitEthernet0/0.152012<br> encapsulation dot1q 1520 second-dot1q 12<br>
 ip address 10.0.0.1 255.255.255.0<br> service-policy what-ever-I-want<br>!<br><br>How would I do that on a Netiron?<br><br><br><br><div class="gmail_quote">On Tue, Jan 27, 2009 at 11:49 AM, Dimitar Kosadinov <span dir="ltr"><<a href="mailto:kgb@bginfo.net">kgb@bginfo.net</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="Ih2E3d">On Tue, 27 Jan 2009 10:28:36 +0100<br>
Allan Eising <<a href="mailto:allan.eising@gmail.com">allan.eising@gmail.com</a>> wrote:<br>
<br>
> Hi there,<br>
><br>
> We're currently considering if the Foundry MLX/XMR series will fit as our<br>
> core routers.<br>
> I've been searching through the foundry site, and there are two core<br>
> requirements that I'm uncertain if the XMR or MLX can handle:<br>
><br>
>  - VLANs overlapping between interfaces, eg. two routed vlan subinterfaces<br>
> both encapsulated with vlan 50.<br>
</div>I don't understand why You need VLAN overlapping for this case.<br>
feature name is ip-follow but on MLX-XMR this is not support, you need use PVLAN to make this if use old IOS, in new IOS PVLAN not supported!!!<br>
Why You need VLAN overlapping btw ? my be find different way ...<br>
<br>
>  - Per sub-interface shaping.<br>
rate-limit with policy-map work very good per VLAN for me.<br>
rate-limit with policy-map + ACL work too / my use per vrf or global /<br>
<div class="Ih2E3d"><br>
<br>
<br>
<br>
><br>
> For the sake of clarity, I've uploaded a conceptual diagram, available here:<br>
> <a href="http://img104.imageshack.us/img104/5186/conceptsl6.png" target="_blank">http://img104.imageshack.us/img104/5186/conceptsl6.png</a><br>
><br>
> Is there anyone on this list who are able to assist?<br>
><br>
> Regards,<br>
><br>
> Allan Eising<br>
><br>
<br>
<br>
</div><font color="#888888">--<br>
 <<a href="mailto:kgb@bginfo.net">kgb@bginfo.net</a>><br>
</font><div><div></div><div class="Wj3C7c">_______________________________________________<br>
foundry-nsp mailing list<br>
<a href="mailto:foundry-nsp@puck.nether.net">foundry-nsp@puck.nether.net</a><br>
<a href="http://puck.nether.net/mailman/listinfo/foundry-nsp" target="_blank">http://puck.nether.net/mailman/listinfo/foundry-nsp</a><br>
</div></div></blockquote></div><br><br>