2

I am building an l2circuit ccc (draft-martini) between an EX4500 and an MX204.

The issue is that I need to have mismatched l2circuit encapsulation-type on either side.

The East-coast EX4550-32F (Junos: 15.1R7-S11.1, lo0.0: 10.8.224.191) side of the l2circuit service is configured with encapsulation-type ethernet as shown:

[email protected]> show configuration | display set | match xe-0/0/14   
set interfaces xe-0/0/14 enable
set interfaces xe-0/0/14 encapsulation ethernet-ccc
set interfaces xe-0/0/14 unit 0 family ccc
set protocols l2circuit neighbor 10.8.224.187 interface xe-0/0/14.0 virtual-circuit-id 2
set protocols l2circuit neighbor 10.8.224.187 interface xe-0/0/14.0 no-control-word
set protocols l2circuit neighbor 10.8.224.187 interface xe-0/0/14.0 mtu 1522
set protocols l2circuit neighbor 10.8.224.187 interface xe-0/0/14.0 encapsulation-type ethernet
set protocols l2circuit neighbor 10.8.224.187 interface xe-0/0/14.0 ignore-encapsulation-mismatch
set protocols l2circuit neighbor 10.8.224.187 interface xe-0/0/14.0 ignore-mtu-mismatch
set protocols l2circuit neighbor 10.8.224.187 interface xe-0/0/14.0 pseudowire-status-tlv
set protocols l2circuit neighbor 10.8.224.187 interface xe-0/0/14.0 connection-protection
set protocols l2circuit neighbor 10.8.224.187 interface xe-0/0/14.0 oam bfd-liveness-detection minimum-receive-interval 1000
set protocols l2circuit neighbor 10.8.224.187 interface xe-0/0/14.0 oam bfd-liveness-detection multiplier 5
set protocols l2circuit neighbor 10.8.224.187 interface xe-0/0/14.0 oam bfd-liveness-detection transmit-interval minimum-interval 1000

{master:0}

The West-coast MX204 (Junos: 19.4R3-S6.1, lo0.0: 10.8.224.187) side of the l2circuit service is configured with encapsulation-type ethernet-vlan as shown:

set interfaces et-0/0/0 enable
set interfaces et-0/0/0 vlan-tagging
set interfaces et-0/0/0 encapsulation extended-vlan-ccc
set interfaces et-0/0/0 unit 0 vlan-id-list 3113
set protocols l2circuit neighbor 10.8.224.191 interface et-0/0/0.0 virtual-circuit-id 2
set protocols l2circuit neighbor 10.8.224.191 interface et-0/0/0.0 no-control-word
set protocols l2circuit neighbor 10.8.224.191 interface et-0/0/0.0 mtu 1522
set protocols l2circuit neighbor 10.8.224.191 interface et-0/0/0.0 encapsulation-type ethernet-vlan
set protocols l2circuit neighbor 10.8.224.191 interface et-0/0/0.0 ignore-encapsulation-mismatch
set protocols l2circuit neighbor 10.8.224.191 interface et-0/0/0.0 ignore-mtu-mismatch
set protocols l2circuit neighbor 10.8.224.191 interface et-0/0/0.0 pseudowire-status-tlv
set protocols l2circuit neighbor 10.8.224.191 interface et-0/0/0.0 connection-protection
set protocols l2circuit neighbor 10.8.224.191 interface et-0/0/0.0 oam bfd-liveness-detection minimum-receive-interval 1000
set protocols l2circuit neighbor 10.8.224.191 interface et-0/0/0.0 oam bfd-liveness-detection multiplier 5
set protocols l2circuit neighbor 10.8.224.191 interface et-0/0/0.0 oam bfd-liveness-detection transmit-interval minimum-interval 1000

The control plane is up in this configuration:

[email protected]> show l2circuit connections 
Layer-2 Circuit Connections:
...
Legend for interface status  
Up -- operational            
Dn -- down                   
Neighbor: 10.8.224.187 
    Interface                 Type  St     Time last up          # Up trans
    xe-0/0/14.0(vc 2)         rmt   Up     Dec 21 17:41:51 2021           1
      Remote PE: 10.8.224.187, Negotiated control-word: No Encapsulation: VLAN
      Incoming label: 300016, Outgoing label: 104
      Negotiated PW status TLV: Yes
      local PW status code: 0x00000000, Neighbor PW status code: 0x00000000
      Connection protection: Yes
      Local interface: xe-0/0/14.0, Status: Up, Encapsulation: ETHERNET
      Flow Label Transmit: No, Flow Label Receive: No

{master:0}
[email protected]>

And in the West coast:

Neighbor: 10.8.224.191 
    Interface                 Type  St     Time last up          # Up trans
    et-0/0/0.0(vc 2)          rmt   Up     Dec 21 18:42:37 2021           1
      Remote PE: 10.8.224.191, Negotiated control-word: No Encapsulation: ETHERNET
      Incoming label: 104, Outgoing label: 300016
      Negotiated PW status TLV: Yes
      local PW status code: 0x00000000, Neighbor PW status code: 0x00000000
      Connection protection: Yes
      Local interface: et-0/0/0.0, Status: Up, Encapsulation: VLAN
      Flow Label Transmit: No, Flow Label Receive: No

root@rf-rtr1-l>

LDP and RSVP are enabled on all transit interfaces and loopbacks.

East-coast LDP info:

[email protected]> show ldp session detail 
Address: 10.8.224.187, State: Operational, Connection: Open, Hold time: 22
  Session ID: 10.8.224.191:0--10.8.224.187:0
  Next keepalive in 2 seconds
  Active, Maximum PDU: 4096, Hold time: 30, Neighbor count: 2
  Neighbor types: discovered configured-layer2
  Keepalive interval: 10, Connect retry interval: 1
  Local address: 10.8.224.191, Remote address: 10.8.224.187
  Up for 02:25:59
  Capabilities advertised: none
  Capabilities received: none
  Protection: disabled
  Session flags: none
  Local - Restart: disabled, Helper mode: enabled
  Remote - Restart: disabled, Helper mode: enabled
  Local maximum neighbor reconnect time: 120000 msec
  Local maximum neighbor recovery time: 240000 msec
  Local Label Advertisement mode: Downstream unsolicited
  Remote Label Advertisement mode: Downstream unsolicited
  Negotiated Label Advertisement mode: Downstream unsolicited
  MTU discovery: enabled
  Nonstop routing state: Not in sync
  Next-hop addresses received:
    10.8.224.187
    10.8.224.176
    gr-0/0/27.202

{master:0}
[email protected]>

West-coast LDP info:

root@rf-rtr1-l> show ldp session detail       
Address: 10.8.224.191, State: Operational, Connection: Open, Hold time: 23
  Session ID: 10.8.224.187:0--10.8.224.191:0
  Next keepalive in 3 seconds
  Passive, Maximum PDU: 4096, Hold time: 30, Neighbor count: 2
  Neighbor types: discovered configured-layer2
  Keepalive interval: 10, Connect retry interval: 1
  Local address: 10.8.224.187, Remote address: 10.8.224.191
  Up for 02:24:49
  Capabilities advertised: none
  Capabilities received: none
  Protection: disabled
  Session flags: none
  Local - Restart: disabled, Helper mode: enabled
  Remote - Restart: disabled, Helper mode: enabled
  Local maximum neighbor reconnect time: 120000 msec
  Local maximum neighbor recovery time: 240000 msec
  Local Label Advertisement mode: Downstream unsolicited
  Remote Label Advertisement mode: Downstream unsolicited
  Negotiated Label Advertisement mode: Downstream unsolicited
  MTU discovery: enabled
  Nonstop routing state: Not in sync
  Next-hop addresses received:
    10.8.224.177
    10.8.224.188
    10.8.224.191
    gr-0/0/0.202

root@rf-rtr1-l>

However, I cannot ping across the service yet (both clients attached in 192.168.150.0/24).

Questions:

  • Does juniper support mismatched l2circuit encapsulation-types?
  • If so, what do I need to do to fix this problem?

Update 2021-12-24...

After reconfiguring my lab with the following, I still show martini control plane is up and the data-plane is broken...

This is the West-coast martini PE mx204 config I'm using...

root@rf-rtr1-l> show configuration | display set | match et-0/0/0 
set interfaces et-0/0/0 enable
set interfaces et-0/0/0 vlan-tagging
set interfaces et-0/0/0 encapsulation flexible-ethernet-services
set interfaces et-0/0/0 unit 0 encapsulation vlan-ccc
set interfaces et-0/0/0 unit 0 vlan-id 3113
set interfaces et-0/0/0 unit 0 input-vlan-map pop
set interfaces et-0/0/0 unit 0 output-vlan-map push
set protocols l2circuit neighbor 10.8.224.190 interface et-0/0/0.0 virtual-circuit-id 3
set protocols l2circuit neighbor 10.8.224.190 interface et-0/0/0.0 no-control-word

root@rf-rtr1-l>

This is the East-coast martini config that I'm using (now on a qfx Model: qfx5200-48y, Junos: 18.4R2-S9.2)...

root@switch02-t> show configuration | display set | match xe-0/0/14 
set interfaces xe-0/0/14 enable
set interfaces xe-0/0/14 encapsulation ethernet-ccc
set interfaces xe-0/0/14 unit 0 family ccc
set protocols l2circuit neighbor 10.8.224.187 interface xe-0/0/14.0 virtual-circuit-id 3
set protocols l2circuit neighbor 10.8.224.187 interface xe-0/0/14.0 no-control-word

{master:0}
root@switch02-t>

West-coast show l2circuit connections extensive...

Neighbor: 10.8.224.190 
    Interface                 Type  St     Time last up          # Up trans
    et-0/0/0.0(vc 3)          rmt   Up     Dec 24 07:18:33 2021           1
      Remote PE: 10.8.224.190, Negotiated control-word: No
      Incoming label: 118, Outgoing label: 26
      Negotiated PW status TLV: No
      Local interface: et-0/0/0.0, Status: Up, Encapsulation: ETHERNET
      Flow Label Transmit: No, Flow Label Receive: No
    Connection History:
        Dec 24 07:18:33 2021  PE route changed     
        Dec 24 07:18:33 2021  Out lbl Update                        26
        Dec 24 07:18:33 2021  In lbl Update                        118
        Dec 24 07:18:33 2021  loc intf up                   et-0/0/0.0

root@rf-rtr1-l>

And the East-coast QFX switch...

Neighbor: 10.8.224.187 
    Interface                 Type  St     Time last up          # Up trans
    xe-0/0/14.0(vc 3)         rmt   Up     Dec 22 22:18:44 2021           1
      Remote PE: 10.8.224.187, Negotiated control-word: No
      Incoming label: 26, Outgoing label: 118
      Negotiated PW status TLV: No
      Local interface: xe-0/0/14.0, Status: Up, Encapsulation: ETHERNET
      Flow Label Transmit: No, Flow Label Receive: No
    Connection History:
        Dec 22 22:18:44 2021  status update timer  
        Dec 22 22:18:43 2021  PE route changed     
        Dec 22 22:18:43 2021  Out lbl Update                       118
        Dec 22 22:18:43 2021  In lbl Update                         26
        Dec 22 22:18:43 2021  loc intf up                  xe-0/0/14.0

{master:0}
root@switch02-t>

I checked the routing table on both sides and the push / pop entries looked fine (this is a single-hop topology, so there's no IGP tag pushed on these services)

Improve this question

2 Answers 2

Reset to default
3

Juniper does support mismatched encapsulations, but that technically isn't needed for what you're trying to accomplish. To be frank, Juniper's terminology for the different encapsulation types and how they interoperate with different L2 services are not intuitive. It's been something that has frustrated me for over a decade.

I digress, here's what should work for you.

Topology

CE1 <== ETHERNET ==> PE1 <== LDP ==> PE2 <== VLAN ==> CE2

I'm using Spirent to emulate the CEs, that are both running EBGP and a pair of MX204s for the PEs.

CE1

192.85.1.2
AS1111
Untagged

CE2

192.85.1.1
AS2222
Tagged with VLAN 3113

PE1 (CE Interface)

set interfaces xe-0/1/0 encapsulation ethernet-ccc
set interfaces xe-0/1/0 unit 0 family ccc

PE1 (L2CKT)

set protocols l2circuit neighbor 2.2.2.2 interface xe-0/1/0.0 virtual-circuit-id 2
set protocols l2circuit neighbor 2.2.2.2 interface xe-0/1/0.0 no-control-word

PE2 (L2CKT)

set protocols l2circuit neighbor 1.1.1.1 interface xe-0/1/0.0 virtual-circuit-id 2
set protocols l2circuit neighbor 1.1.1.1 interface xe-0/1/0.0 no-control-word

PE2 (CE Interface)

set interfaces xe-0/1/0 enable
set interfaces xe-0/1/0 vlan-tagging
set interfaces xe-0/1/0 encapsulation flexible-ethernet-services
set interfaces xe-0/1/0 unit 0 encapsulation vlan-ccc
set interfaces xe-0/1/0 unit 0 vlan-id 3113
set interfaces xe-0/1/0 unit 0 input-vlan-map pop
set interfaces xe-0/1/0 unit 0 output-vlan-map push

You'll notice a couple of differences from your configuration, I'll highlight the main ones. I would suspect you were seeing one-way traffic, which is because one of the CEs wasn't receiving what was expected due to the lack of VLAN tag.

  1. Using vlan-id instead of vlan-id-list is simpler, if you need to terminate multiple VLANs, I'd suggest using a sub-interface/unit per VLAN, similar to how this is configured.

  2. input-vlan-map pop implies that the remote end is ethernet-ccc and should receive untagged packets, so it pops the tag on ingress (from the CE).

  3. output-vlan-map push implies that the local PE is receiving untagged packets from the remote PE and should impose the configured VLAN tag (3113) prior to sending traffic toward the CE.

A Common Pitfall

set interfaces xe-0/1/0 unit 0 output-vlan-map push vlan-id 3113

is not the same as

set interfaces xe-0/1/0 unit 0 vlan-id 3113

In fact, if you combine both, you'll double push 3113 despite it not being so obvious.

I digress, here's what the final result looks like.

PE1

Neighbor: 2.2.2.2 
    Interface                 Type  St     Time last up          # Up trans
    xe-0/1/0.0(vc 2)          rmt   Up     Dec 23 14:37:01 2021           1
      Remote PE: 2.2.2.2, Negotiated control-word: No
      Incoming label: 17, Outgoing label: 17
      Negotiated PW status TLV: No
      Local interface: xe-0/1/0.0, Status: Up, Encapsulation: ETHERNET
      Flow Label Transmit: No, Flow Label Receive: No

PE2

Neighbor: 1.1.1.1 
    Interface                 Type  St     Time last up          # Up trans
    xe-0/1/0.0(vc 2)          rmt   Up     Dec 23 14:37:01 2021           1
      Remote PE: 1.1.1.1, Negotiated control-word: No
      Incoming label: 17, Outgoing label: 17
      Negotiated PW status TLV: No
      Local interface: xe-0/1/0.0, Status: Up, Encapsulation: ETHERNET
      Flow Label Transmit: No, Flow Label Receive: No

Despite the obvious VLAN tagging/manipulation, the encapsulations match. This is one of those things that falls into the "not-so-intuitive" bucket.

Lastly, here's the resulting forwarding plane being show with the BGP session between Spirent ports establish.

enter image description here

Improve this answer
3
  • Hi Jordan, thank you for the excellent walk-through... unfortunately these configs are still broken in the data-plane... and sorry about swapping PE routers from the ex4550 to qfx... so far that doesn't seem to matter because the data-plane is broken everywhere at the moment. Any ideas for how to solve the problem? I edited my question with the latest status...
    – Mike Pennington
    Dec 24, 2021 at 8:12
  • Hey Mike, happy to help remedy this - a couple of question: 1. What model QFX? 2. Do you happen to know what the packets look like on either end (tags, etc.)? 3. Is the side set as vlan-ccc receiving tagged traffic from the CE?
    – Jordan Head
    Dec 27, 2021 at 13:34
  • the qfx is Model: qfx5200-48y, Family: junos-qfx, Junos: 18.4R2-S9.2
    – Mike Pennington
    Dec 27, 2021 at 14:34
2

EDIT:

Keeping the original answer here to document that some of Juniper's docs appear to conflict with Jordan's expertise on l2circuit configurations. See his answer for more details...

Question: Does juniper support mismatched l2circuit encapsulation-types? Answer: No
Quoting from a Juniper MPLS deployment guide:

Standard behavior for Martini tunnels requires the same encapsulation type and VLAN-ID on both sides. Junos does allow non-standard behavior in the form of mismatching VLAN-IDs on each side of a Martini tunnel and different encapsulation types on each side – for example, ethernet on one side and vlan on the other.

Improve this answer
3
  • You can definitely mismatch the encapsulations by either building an input/output VLAN map or by using TCC encapsulation with proxy-arp. I'll see if I can get a lab together and some working configs.
    – Jordan Head
    Dec 22, 2021 at 16:01
  • Actually mismatched CE attachment circuit encapsulation is not my most pressing issue… building a functional martini configuration is my #1 gap… as you can see, the martini control plane is up but I can’t ping through it (even if I have matching CE encap)
    – Mike Pennington
    Dec 22, 2021 at 16:05
  • 1
    I posted an answer for what I think fixes your problem, that said if there are other permutations, just post the question and I'll be on the lookout.
    – Jordan Head
    Dec 23, 2021 at 16:01

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.