[j-nsp] l2circuit between ASR9k and MX80

[Saku Ytti]

On (2015-08-02 11:16 +0200), Marcin Kurek wrote:

Hey Marcin,

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

I probably misunderstand this comment, but your config clearly shows tagged
logical interface in JNPR, i.e. both ends have SVLAN, just it happens to be
same SVLAN in both ends (if it were different your config wouldn't work
without 'output-vlan-map swap', which you should standardize into, so that
when configuring A end, you don't need to care about config in B end)

> 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

RFC talks about Raw and Tagged mode, but yes. And I can't speak for ASR9k, but
you observed same issue as I did in CAT7600 ES+ (same Trident NPU as 1st gen
ASR9k). 'Why does this work, as per config, it should not work'.
And when I captured the frame, I noticed by SVLAN was popped and replaced by
7600 internal VLAN.
I determined that because it was VLAN mode circuit, 7600 automatically readded
the internal VLAN (and automatically does swap towards LAN).

JunOS OTOH, automatically does nothing, no pop, push, swap on any direction,
which is strict contrast to what normally happens in logical VLAN interface,
normally it is popped and pushed.

I think 7600/ES+ behaves like this, because there is no way to explicitly
configure it correctly, or at least that time it there wasn't. Correct
configuration on EoMPLS LAN config is:
a) retain top SVLAN on ingress
b) swap   top VLAN on egress

More complete rule, covering all VLAN stack use-cases is

a) pop all but 1 SVLAN on ingress
b) swap top SVLAN, push rest of SVLANS on egress

(why not just push all SVLANs? Because then we'd destroy the CoS bits of the
SVLAN of the far-end)

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

Quite, and in your config, 'pop symmetric', you'd violate it, you wouldn't
guarantee existance of VLAN.

> 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?

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"

This clearly is not true in your use-case, as you say it works, only way it to
work, is if Cisco is sending 3101, because JNPR isn't doing anything to the
SVLAN.
Perhaps capture the frame and see what CSCO is sending. I'm not sure how to do
inline capture in ASR9k, but if your JNPR is trio, you can do
'packet-via-dmem' (https://github.com/ytti/packet_via_dmem) to see what is
coming in from MPLS core.

> 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?

Yes. In 7600 the 'dummy tag' is the internal VLAN of the interface, which
would not be 3101, and your config would be broken, until you add
'output-vlan-map swap' on JNPR, which you should do anyhow.

> 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?

There are many ways to get functioning EoMPLS on arbitrary and mismatching
SVLAN counts, but only one way to do it, so that you don't need A-B
intelligence to configure A, which I view as crucial property.
The way to avoid A-B knowledge is to guarantee that when you send EoMPLS frame
to MPLS core it has exactly 1 SVLAN, which far-end will swap to its own SVLAN.
This way, A does not need to know what is happening in B port. Maybe A has 2
SVLAN (QinQ SVLAN) and B has 0?

-- 
  ++ytti