Hi Saku,
Thanks for your explanation, I found it helpful.
What dummy tag? Is there [ SVLAN CVLAN ] stack coming to the CSCO, or just
[ SVLAN ]?
If just SVLAN, then this should happen
a) 3101 comes to CSCO from LAN
b) CSCO pops 3101
c) CSCO detects its VLAN EoMPLS and pushes 3101 back
d) Frame sent to MPLS WAN
e) JNPR gets it, does not nothing, sends out to LAN
And reverse
a) 3101 comes to JNPR from LAN
b) JNPR does nothing
c) CSCO gets it
d) CSCO rewrite 3101 to 3101 due to VLAN mode detected
If there were CVLAN in in addition to SVLAN, it would be left untouched, and
would be seen after SVLAN.
Adding 'output-vlan-map swap' on JNPR would allow the config to work with
mismatching SVLANs in either end.
No, I was testing very basic scenario with SVLAN only coming to cisco.
Okay, so I need to take a step back and ask for a clarification about VC
Type 4 and VC Type 5 if you don't mind.
My understanding is that on ASR9k the VLAN tag manipulation is
completely independent of negotiated PW type.
We can have two cases here:
a) Type 5 - port mode
b) Type 4 - VLAN mode
In either case, we can do whathever we want with the tags by means of
"rewrite ingress" commands.
According to the standard, when using VC Type 5 frames transported over
the PW _MAY_ have VLAN tags attached.
On the contrary, when using VC Type 4 frames _MUST_ have a VLAN tag
attached.
If we have VLAN EoMPLS like in our example and we have stripped the
SVLAN tag on ingress, something need to be pushed to the VLAN tag stack,
right?
Quote from cisco docs:
"In order to address this possibility, the EVC platforms insert a dummy
VLAN tag 0 on top of the frame for type 4 PWs"
"However, if you use a type 4 PW between an EVC platform and a non-EVC
platform, this might lead to interoperability problems. The non-EVC
platform does not consider the top VLAN tag as the dummy VLAN tag and
instead forwards the frame with the dummy VLAN tag 0 as the outer tag"
So what the heck is the dummy tag? When you mentioned that CSCO detects
VLAN EoMPLS and pushes 3101 back, did you mean the "dummy tag" as cisco
calls it?
Regarding VC Type 4 and Type 5 discussion, there was another thread on
cisco-nsp a few days ago.
Waris Sagheer wrote:
"Little bit history, VC type 4 came into being since some hardware did
not have the capability to manipulate the tag at egress hence the
concept of dummy tag. VC type 4 is pretty much becoming non existent and
is being supported on legacy platforms only. VC type 5 will be the
default signaling moving forward where users will have the flexibility
to add/remove tags based on the EVC configuration.
I found it interesting, although I still don't understand what problems
does VC Type 4 solve.
If some hardware couldn't manipulate the tag at egress (but was capable
of manipulation at ingress), how does the dummy tag help?
Using our example, how they handled situation where they had [ SVLAN
CVLAN ] tag stack and the SVLAN was different at both sides?
Many thanks,
Marcin
_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
