L2VPN LDP signaled VPLS between Ios & Junos with Control Word enabled

[Jerems]

Hi dear community,

I have a good one for you regarding the setup of a vpls (ldp signaled) between a Cisco ISR1100X and a Juniper SRX300.

As an example i am sending a simple ping between each node at each side of the VPLS.

Both nodes are in Vlan 18 and has an IP **bleep** of 192.168.18.1/24 & 192.168.18.2/24

It was working well initially but for some learning purpose and because wireshark needed some specific parametres (" Decode As") related to PW Control Word, i decided to enable control word at each PE.

Could it be the reason of the failure when trying to ping each node ?

Here is the config :

Cisco PE :

l2vpn vfi context VPLS-12118 
 vpn id 12118
 member pseudowire12118
!
bridge-domain 18 
 member vfi VPLS-12118
!
interface pseudowire12118
 encapsulation mpls
 signaling protocol ldp
 neighbor 10.0.0.1 12118
 control-word include
!
interface GigabitEthernet0/0/1
 no ip **bleep**
 negotiation auto
 service instance 18 ethernet
  encapsulation dot1q 18
  bridge-domain 18

Juniper PE:

set interfaces ge-0/0/5 unit 18 description "vlan l2vpn-test-vpls"
set interfaces ge-0/0/5 unit 18 encapsulation vlan-vpls
set interfaces ge-0/0/5 unit 18 vlan-id 18
set interfaces ge-0/0/5 unit 18 family vpls
!
set routing-instances vpls-12118 protocols vpls neighbor 10.0.0.21
set routing-instances vpls-12118 protocols vpls encapsulation-type ethernet
set routing-instances vpls-12118 protocols vpls control-word
set routing-instances vpls-12118 protocols vpls no-tunnel-services
set routing-instances vpls-12118 protocols vpls vpls-id 12118
set routing-instances vpls-12118 protocols vpls pseudowire-status-tlv
set routing-instances vpls-12118 interface ge-0/0/5.18
set routing-instances vpls-12118 instance-type vpls
set routing-instances vpls-12118 vlan-id 18

and the results from the cisco perspective:

jey-isr1K-pe-01#sh l2vpn vfi name VPLS-12118 detail
Legend: RT=Route-target, S=Split-horizon, Y=Yes, N=No

VFI name: VPLS-12118, state: up, type: multipoint, signaling: LDP
  VPN ID: 12118
  Bridge-Domain 18 attachment circuits:
  Pseudo-port interface: pseudowire100003
  Interface          Peer **bleep**     VC ID        S
  pseudowire12118    10.0.0.1         12118        Y

jey-isr1K-pe-01#sh l2vpn service vfi peer 10.0.0.1 vcid 12118 detail 
Legend: St=State    XC St=State in the L2VPN Service      Prio=Priority
        UP=Up       DN=Down            AD=Admin Down      IA=Inactive
        SB=Standby  HS=Hot Standby     RV=Recovering      NH=No Hardware
        m=manually selected

  Interface          Group       Encapsulation                   Prio  St  XC St
  ---------          -----       -------------                   ----  --  -----
VPLS name: VPLS-12118, State: UP
  pw100003                       VPLS-12118(VFI)                 0     UP  UP   
  pw12118            core_pw     10.0.0.1:12118(MPLS)            0     UP  UP   
                                 Local VC label 47              
                                 Remote VC label 262145         

It seems like the mac addresses are correctly flowing between each peers :

jey-isr1K-pe-01#sh bridge-domain 18
Bridge-domain 18 (2 ports in all)
State: UP                    Mac learning: Enabled
Aging-Timer: 300 second(s)
Unknown Unicast Flooding Suppression: Disabled
Maximum **bleep** limit: 65536
    GigabitEthernet0/0/1 service instance 18
    vfi VPLS-12118 neighbor 10.0.0.1 12118
   AED MAC **bleep**    Policy  Tag       Age  Pseudoport
   0   207B.D2D9.24AD forward dynamic   299  GigabitEthernet0/0/1.EFP18
   0   A8B4.56B6.5480 forward dynamic   300  VPLS-12118.40401c

and the screenshot of a capture framed related to ARP request :

In the screenshot above, the PW ethernet Control Word Sequence number with the value 0 is not what is expected, i believe.

Do you have any thoughts on this subject please?

Thanks in advance,

Jerems

[Jerems]

Deleting the statement on the Junos platform solved the issue.

But Why ?

root@jey-srx3x-pe-01# delete routing-instances vpls-12118 protocols vpls control-word 

Here is now what i need to do in Wireshark to see the entire content of the MPLS payload :

I have to use the option from the contextual meu Decode As and select Ethernet PW (With CW) to be able to check the MPLS Payload.

[Harold Ritter]

Hi @Jerems ,

This might be due to the Wireshark version you are using. I use version 4.2.5 and I can see the entire MPLS payload with or without the control word.

Regards,

[Jerems]

Hi @Harold Ritter 

I hope you are well !

I did the test with another PC with latest wireshark version onboard and it gives the same result.

No visibility on MPLS payload as long as i don't use the "Decode As" option.

Jeremie

[MHM Cisco World]

I think this MPLS is like hello, it same bytes and in both way, and normally the hello is contain unknown data 
you say the L2VPN is work 
so try open DHCP or ARP 
you will see the MPLS header and below the ARP or DHCP packet 

MHM

[Jerems]

Hi @MHM Cisco World ,

I hope you are well !

Thank you for your time (as well as @Harold Ritter ) for answering me.

Again it works only if i use the "Decode As" option but doesn't work without it.

It this new example i used putty to connect from the host 192.168.18.2 to host 192.168.18.1 using ssh protocol.

Frame ID 103 with CW option in wireshark :

Frame ID 103 without it :

Thanks again for your kind help.

Regards,

Jerems

[MHM Cisco World]

But the SSH is also encrypted traffic.

As I mention check ARP or DHCP or use telent instead of ssh

MHM

[Jerems]

Sure but it should not prevent me from at least viewing the header of the ip packet.

Anyway with telnet nothing changes.

Thanks  again for your time.

Jerems

[Jerems]

I probably know what is happening. I'm falling into this situation where the mac addr of my Juniper device (next hop) has a mac addr begining with digit '4' which is badly interpreted.

[Jerems]

Physical interface: ge-0/0/1, Enabled, Physical link is Up
  Interface index: 139, SNMP ifIndex: 514
  Description: 
  Link-level type: Ethernet, MTU: 1614, LAN-PHY mode, Link-mode: **ll-duplex, Speed: 1000mbps, BPDU Error: None, Loop Detect PDU Error: None, Ethernet-Switching Error: None, MAC-REWRITE Error: None,
  Loopback: Disabled, Source filtering: Disabled, Flow control: Disabled, Auto-negotiation: Enabled, Remote fault: Online
  Device flags   : Present Running
  Interface flags: SNMP-Traps Internal: 0x0
  Link flags     : None
  CoS queues     : 8 supported, 8 maximum usable queues
  Current addr: 44:aa:50:4c:70:c1, Hardware addr: 44:aa:50:4c:70:c1

[Harold Ritter]

Hi @Jerems ,

I think you are on the right track, but this behavior would not be related to the Juniper (PE) MAC addr, but rather to the encapsulated traffic (end points) MAC addresses (24:ad:81:00:00:12 and 54:80:20:7b:d2:d9). 

Regards,

[Jerems]

You are right, i got it too fast probably. Need to investigate **rther more.

[Jerems]

https://www.rfc-editor.org/rfc/rfc8469

[Jerems]

https://null.53bits.co.uk/index.php?page=pseudowire-ecmp-missordering

[Jerems]

The best reference about that topic :

https://archive.nanog.org/meetings/nanog57/presentations/Tuesday/tues.general.SnijdersWheeler.MACaddresses.14.pdf