[f-nsp] Assigning traffic to different VLLs based on the inner QinQ tag
David Ball
davidtball at gmail.com
Fri Apr 25 12:20:28 EDT 2008
Just an update on this for those who asked me privately about it
(and the rest of you, I guess). Doesn't sound like it is possible for
the XMR to look at the inner tag of a QinQ frame and assign the
traffic to a service (ie. a VLL, VPLS, etc) based on the value of that
inner tag. It may be looked at for a future software release.
David
On 22/04/2008, David Ball <davidtball at gmail.com> wrote:
> Actually, forget the sniffer. I know the inner tag is being sent
> across the network towards the XMR, because I tested this with other
> Juniper gear earlier (no Foundry), and the QinQ worked by simply
> pushing an outer tag before sending to the cust/switch. Just trying
> to find out if there's a 'push outer tag' knob I can use on the XMR,
> without having to modify tag-types.
>
> David
>
>
> On 22/04/2008, David Ball <davidtball at gmail.com> wrote:
> > No solution to it yet, though I'm going to open a TAC ticket on it
> shortly.
> >
> > As per the User Configuration guide, the MLX/XMR "supports
> > 802.1q-in-q tagging where the inner and outer tag can have different
> > or same tag-type values.". However, the examples therein all indicate
> > that the tag-type for the outer should be set to 9100, which I don't
> > want to do (because not all of my downstream devices can modify
> > tag-type). I just need it to stick an outer tag on and not touch the
> > original.
> > It also indicates in the VLL section that if the endpoint on the
> > XMR is tagged, it'll tag the outbound traffic (towards the
> > cust/switch) with the associated tag...but never says if or what it
> > does to any existing VLAN tag in the original payload. I'm setting up
> > a sniffer now to ensure that I'm actually passing the original tag
> > across the network (99% sure I am, cuz I'm not explicitly stripping
> > it).
> >
> > David
> >
> >
> > On 22/04/2008, Andreas Larsen <andreas at larsen.pl> wrote:
> > > This is a very interesting question. Have you received any feedback on
> it ?
> > > One very stupid way of doing it would be to untagg towards the XMR or
> Loop a
> > > XMR interface.
> > > I know Redback and Ericsson equipment can do this as well.
> > >
> > > Curious if you received any feedback on this matter.
> > >
> > > Regards Andreas
> > >
> > >
> > > On Tue, Apr 22, 2008 at 4:31 PM, David Ball <davidtball at gmail.com>
> wrote:
> > > >
> > > > I have a non-Foundry switch connected to an XMR Gig port (running
> > > > 3.6.0cT163). I'm expecting QinQ'd traffic (tag-types will both be
> > > > 8100) coming from that switch. I'm trying to determine how I can
> > > > strip off the outer tag, then assign the traffic to different VLLs,
> > > > VPLSs, etc. based on the 'inner' tag. I've read the VLANs section of
> > > > the config guide a few times over and either it's not mentioning it,
> > > > or I don't 'get' it. I'm more familiar with Juniper's way of doing
> > > > this, which lets you inspect both inner and outer tags, and do
> > > > pop/push/swap with the tags, but am struggling to understand how the
> > > > XMRs handle things. Any insight would be appreciated.
> > > > Some (possibly irrelevant) config snippets are below.
> > > >
> > > > interface ethernet 2/1
> > > > enable
> > > > no spanning-tree
> > > > no flow-control
> > > > gig-default neg-off
> > > > !
> > > > <snip>
> > > > vll vll-tagged 500 raw-mode
> > > > vll-peer 172.16.0.1
> > > > vlan 500
> > > > tagged e 2/11
> > > > <snip>
> > > > _______________________________________________
> > > > foundry-nsp mailing list
> > > > foundry-nsp at puck.nether.net
> > > > http://puck.nether.net/mailman/listinfo/foundry-nsp
> > > >
> > >
> > >
> >
>
More information about the foundry-nsp
mailing list