[f-nsp] Question about MLX/XMR capabilities

[Allan Eising]

Dimitar,

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).

I hope that clarifies it.

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.

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:

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.
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:

interface GigabitEthernet0/0.152012
 encapsulation dot1q 1520 second-dot1q 12
 ip address 10.0.0.1 255.255.255.0
 service-policy what-ever-I-want
!

How would I do that on a Netiron?



On Tue, Jan 27, 2009 at 11:49 AM, Dimitar Kosadinov <kgb at bginfo.net> wrote:

> On Tue, 27 Jan 2009 10:28:36 +0100
> Allan Eising <allan.eising at gmail.com> wrote:
>
> > Hi there,
> >
> > We're currently considering if the Foundry MLX/XMR series will fit as our
> > core routers.
> > I've been searching through the foundry site, and there are two core
> > requirements that I'm uncertain if the XMR or MLX can handle:
> >
> >  - VLANs overlapping between interfaces, eg. two routed vlan
> subinterfaces
> > both encapsulated with vlan 50.
> I don't understand why You need VLAN overlapping for this case.
> 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!!!
> Why You need VLAN overlapping btw ? my be find different way ...
>
> >  - Per sub-interface shaping.
> rate-limit with policy-map work very good per VLAN for me.
> rate-limit with policy-map + ACL work too / my use per vrf or global /
>
>
>
>
> >
> > For the sake of clarity, I've uploaded a conceptual diagram, available
> here:
> > http://img104.imageshack.us/img104/5186/conceptsl6.png
> >
> > Is there anyone on this list who are able to assist?
> >
> > Regards,
> >
> > Allan Eising
> >
>
>
> --
>  <kgb at bginfo.net>
> _______________________________________________
> foundry-nsp mailing list
> foundry-nsp at puck.nether.net
> http://puck.nether.net/mailman/listinfo/foundry-nsp
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/foundry-nsp/attachments/20090127/60bfe58e/attachment.html>