2

We are currently transporting an Ethernet Port using LDP Based Layer 2 VPN service (P2P PW) in Juniper MX.This P2P LDP PW is up and currently working. Below is the configuration against this:-

set interfaces xe-0/0/1 mtu 9192
set interfaces xe-0/0/1 encapsulation ethernet-ccc
set interfaces xe-0/0/1 unit 0 family ccc
set protocols l2circuit neighbor 10.253.0.12 interface xe-0/0/1.0 virtual-circuit-id 70
set protocols l2circuit neighbor 10.253.0.12 interface xe-0/0/1.0 no-control-word
set protocols l2circuit neighbor 10.253.0.12 interface xe-0/0/1.0 mtu 9192
set protocols l2circuit neighbor 10.253.0.12 interface xe-0/0/1.0 ignore-mtu-mismatch
set routing-instances inter-msc-1 interface xe-0/0/1.0

We want to transport the same ethernet port but using LDP based VPLS Instance instead of l2circuit.

Is it possible to transport an Ethernet Port using LDP Based Layer 2 VPLS Service in Juniper MX routers? It would be very nice if sample configurations are shared for Juniper MX.

Improve this question
1

1 Answer 1

Reset to default
5

Yes, LDP VPLS is a pretty standard deployment. Where it can get confusing is the various types of PE-CE interface encapsulation depending upon the type of service you're running. In your case of a simple ethernet circuit, it's easy.

Here's a simple example.

Topology

CE1 [ge-0/0/0] <=> [ge-0/0/1] PE1 [ge-0/0/0] <= LDP => [ge-0/0/0] PE2 [ge-0/0/1] <=> [ge-0/0/0] CE2

For example's sake, CE1 and CE2 have a IP's in the same subnet and have no idea they're connected to a VPLS.

CE1

set interfaces ge-0/0/0 unit 0 family inet address 192.168.1.10/24

CE2

set interfaces ge-0/0/0 unit 0 family inet address 192.168.1.20/24

For the PE's, I'm going to skip the LDP configuration and only include what's required for VPLS.

PE1

set interfaces ge-0/0/1 description to-CE1
set interfaces ge-0/0/1 encapsulation ethernet-vpls
set interfaces ge-0/0/1 unit 0 family vpls

set interfaces lo0 unit 0 family inet address 1.1.1.1/32
set interfaces lo0 unit 0 family mpls
    
set routing-instances VPLS instance-type vpls
set routing-instances VPLS interface ge-0/0/1.0
set routing-instances VPLS protocols vpls no-control-word
set routing-instances VPLS protocols vpls no-tunnel-services
set routing-instances VPLS protocols vpls vpls-id 70
set routing-instances VPLS protocols vpls mtu 9192
set routing-instances VPLS protocols vpls ignore-mtu-mismatch
set routing-instances VPLS protocols vpls neighbor 2.2.2.2   # The loopback of the remote LDP neighbor (PE2)

PE2

set interfaces ge-0/0/1 description to-CE2
set interfaces ge-0/0/1 encapsulation ethernet-vpls
set interfaces ge-0/0/1 unit 0 family vpls

set interfaces lo0 unit 0 family inet address 2.2.2.2/32
set interfaces lo0 unit 0 family mpls

set routing-instances VPLS instance-type vpls
set routing-instances VPLS interface ge-0/0/1.0
set routing-instances VPLS protocols vpls no-control-word
set routing-instances VPLS protocols vpls no-tunnel-services
set routing-instances VPLS protocols vpls vpls-id 70
set routing-instances VPLS protocols vpls mtu 9192
set routing-instances VPLS protocols vpls ignore-mtu-mismatch
set routing-instances VPLS protocols vpls neighbor 1.1.1.1  # The loopback of the remote LDP neighbor (PE1)

Verification

Let's just look at PE1 VPLS status:

jhead@PE> show vpls connections
Layer-2 VPN connections:

Legend for connection status (St)
EI -- encapsulation invalid      NC -- interface encapsulation not CCC/TCC/VPLS
EM -- encapsulation mismatch     WE -- interface and instance encaps not same
VC-Dn -- Virtual circuit down    NP -- interface hardware not present
CM -- control-word mismatch      -> -- only outbound connection is up
CN -- circuit not provisioned    <- -- only inbound connection is up
OR -- out of range               Up -- operational
OL -- no outgoing label          Dn -- down
LD -- local site signaled down   CF -- call admission control failure
RD -- remote site signaled down  SC -- local and remote site ID collision
LN -- local site not designated  LM -- local site ID not minimum designated
RN -- remote site not designated RM -- remote site ID not minimum designated
XX -- unknown connection status  IL -- no incoming label
MM -- MTU mismatch               MI -- Mesh-Group ID not available
BK -- Backup connection          ST -- Standby connection
PF -- Profile parse failure      PB -- Profile busy
RS -- remote site standby    SN -- Static Neighbor
LB -- Local site not best-site   RB -- Remote site not best-site
VM -- VLAN ID mismatch

Legend for interface status
Up -- operational
Dn -- down

Instance: VPLS
  LDP-VPLS State
  VPLS-id: 70
  Mesh-group connections: __ves__
    Neighbor                  Type  St     Time last up          # Up trans
    2.2.2.2(vpls-id 70)       rmt   Up     Dec  3 21:07:21 2020           1
      Remote PE: 2.2.2.2, Negotiated control-word: No
      Incoming label: 262146, Outgoing label: 262146
      Negotiated PW status TLV: No
      Local interface: lsi.1048577, Status: Up, Encapsulation: ETHERNET
        Description: Intf - vpls VPLS neighbor 2.2.2.2 vpls-id 70
      Flow Label Transmit: No, Flow Label Receive: No

Finally, we can see that the two CEs can communicate.

jhead@CE1> ping 192.168.1.20
PING 192.168.1.20 (192.168.1.20): 56 data bytes
64 bytes from 192.168.1.20: icmp_seq=0 ttl=64 time=8.838 ms
64 bytes from 192.168.1.20: icmp_seq=1 ttl=64 time=4.620 ms
64 bytes from 192.168.1.20: icmp_seq=2 ttl=64 time=5.639 ms
64 bytes from 192.168.1.20: icmp_seq=3 ttl=64 time=3.969 ms
64 bytes from 192.168.1.20: icmp_seq=4 ttl=64 time=5.594 ms
Improve this answer
6
  • Thank you very much for providing the detailed configuration. One Confusion. Why there is mentioning of route-distinguisher and route-target in the LDP based VPLS configuration you shared for PEs.At the same time you are also mentioning the remote VPLS LDP peer. In my openion , RD and RT are not required if this is a LDP based VPLS.
    – Nabeel
    Dec 4, 2020 at 7:57
  • RD and RT are required for BGP signalled VPLS where we need auto discovery and assignment of MPLS Lables at the same time. This is a LDP signalled VPLS.
    – Nabeel
    Dec 4, 2020 at 7:59
  • Correct, I have fixed my answer to exclude them. Honestly I added it out of sheer habit since I'm typically doing BGP signalled, it works as expected without them.
    – Jordan Head
    Dec 4, 2020 at 15:36
  • Appreciate that.
    – Nabeel
    Dec 4, 2020 at 16:49
  • @JordanHead, I'm debugging some juniper l2circuit ccc issues and noticed that you have "family mpls" on your loopback interfaces. Since there is no data-plane neighbor on the loopback, is there a need for family mpls on the loopback? I am fairly newb to juniper's ways of doing things, so I could be totally mistaken here...
    – Mike Pennington
    Dec 21, 2021 at 0:05

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.