[j-nsp] l2circuit between ASR9k and MX80

[James Bensley]

On 31 July 2015 at 11:41, Marcin Kurek <notify at marcinkurek.com> wrote:
> Hello,
>
> I'm doing some interoperability tests between Cisco and Juniper routers and
> I wanted to ask about a particular piece of config.
> I would expect that it shouldn't work, but it works perfectly, so I'm a bit
> confused.
>
> There is a l2vpn circuit between ASR9k and MX80 running in VLAN mode (VC
> Type 4).
>
> ------------------- ASR9k ------------------------------------
>
> interface TenGigE0/0/1/5.3101 l2transport
>  encapsulation dot1q 3101
>  rewrite ingress tag pop 1 symmetric
>
> l2vpn
> !
>  pw-class PW_TYPE_VLAN
>   encapsulation mpls
>    transport-mode vlan
>   !
>  !
> !
>  xconnect group XCONNECT_GROUP_2
>   p2p PW2
>    interface TenGigE0/0/1/5.3101
>    neighbor ipv4 3.3.3.3 pw-id 101
>     pw-class PW_TYPE_VLAN
>    !
>   !
>  !
> ------------------- MX80 -------------------------------------
>
>  ge-1/0/1 {
>         description "ESXi 2 VMNIC3";
>         flexible-vlan-tagging;
>         encapsulation flexible-ethernet-services;
>         unit 3101 {
>             encapsulation vlan-ccc;
>             vlan-id 3101;
>
> protocols {
>  l2circuit {
>         neighbor 4.4.4.4 {
>             interface ge-1/0/1.3101 {
>                 virtual-circuit-id 101;
>                 no-control-word;
>                 encapsulation-type ethernet-vlan;
>             }
>         }
>     }
> }
>
> In my understanding following things should happen:
> - a frame coming to ASR9k from a CE is tagged with VLAN 3101
> - we are doing VLAN tag manipulation on ASR9k, the tag is popped
> - since we are using VC type 4, the PW forwarder adds a dummy tag 0 before
> forwarding the frame
> - MX80 should get the frame with tag 0 imposed
>
> If above is true, how does the MX handle the dummy tag?


Hi Marcin,

My understanding of how this should be configured and what would happen;

> - a frame coming to ASR9k from a CE is tagged with VLAN 3101
> - we are doing VLAN tag manipulation on ASR9k, the tag is popped
> - since we are using VC type 4, the PW forwarder adds a dummy tag 0 before
> forwarding the frame
> - MX80 should get the frame with tag 0 imposed
> - THE MX80 SHOULD POP THE DUMMY VLAN 0 TAG
> - THE MX80 SHOULD PUSH THE TAG 3101


However the MX80 hasn't got "output-vlan-map" configured as Saku pointed out.

Even without that configured, my understanding is that it should at
least PoP the dummy VLAN, unless it doesn't support VC type 4
properly? So the 3101 tag should be being popped unless it somehow
knows that isn't the dummy VLAN tag (maybe becasue it's not 0?).


On 10 August 2015 at 11:29, Marcin Kurek <notify at marcinkurek.com> wrote:
> Hi Saku,
>
> I wanted to follow-up with the results of further testing in the lab.
>
>>  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"
>
>
> I did a packet capture on one of the core links and it clearly shows that
> above isn't true.
> When setting VC Type 4 (VLAN mode) between ASR9k w/ Typhoon LC and MX80 the
> tag is stripped (rewrite ingress tag pop 1 symmetric) and then it is pushed
> again, so the packet is traversing the core with tag 3101.
>
> Also I tested this configuration:
>
>>> ----A----
>>> interface GigabitEthernet0/1/0/19.100 l2transport
>>> encapsulation dot1q 100
>>>
>>>
>>> ----B----
>>> interface GigabitEthernet0/1/0/19.200 l2transport
>>> encapsulation dot1q 200
>>> rewrite ingress tag translate 1-to-1 dot1q 100 symmetric
>
> And it seems to be working, although I understand your point.



Makes sense (albeit a little naughty of Cisco), as per your testing
above the ASR9K is pushing the SVLAN tag back on before transmission
over the pseudowire.



On 2 August 2015 at 10:16, Marcin Kurek <notify at marcinkurek.com> wrote:
> 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.



It was me that started that thread. I was confused because I had made
a mistake in my testing which I hadn't spotted (classic!) and so my
results weren't "adding up". I was about to begin some interopt
testing like you for pseudowire between a mixture of Cisco and Juinper
devices that use different configurations and AC encapsualtions, so
MX480's & MX960's running pseudowires to 7600's, ME3600/ME3800's,
ASR1000's and ASR9001/9006's so a full mix of IOS types and
configuration types using EVC and port based AC etc.

I've done some more testing, everything works using VC type 5 more a
less (that is the main take away here). I don't see any need to be
using VC type 4 anywhere. VC type 5 can transport untagged, tagged,
double tagged frames so juse use VC type 5.

During my testing weird things were happening when I used VC type 4
and the devices didn't support it properly. For example ASR1000s don't
support PoP'ing of the dummy VLAN tag so for a pseudowire between
ME3800 and ASR1001-X, traffic that ingresses the ME3800 would egress
the ASR1K with the extra dummy tag on and always be dropped. For
traffic that ingresses the ASR1K and egresses the ME3800, the
ME3800s/ME3600's can PoP the dummy tag so traffic flows
unidirectionaly only. But there is nothing (that I can find) in the
ASR1000 docs that says it can't PoP the VC type 4 dummy tag. I opened
a TAC case and Cisco confirmed that it can't do the PoP.

So just use VC type 5 everywhere (Cisco devices will almost always try
and negotiate VC type 5 by default unless you force on PE to VC type 4
using "interworking vlan").

Can you share you final wokring config and did you stay with VC type 4?

Cheers,
James.