VPLS on SRX

One of the topics that I haven’t written about so far was VPLS but I had already written some posts which lay the foundation for this VPLS setup. On this post, I will try to explain how VPLS is configured and verified on Junos particulary on packet mode Juniper SRX.  I believe it will be useful for those who don’t know anything about VPLS too. The way I explain VPLS here is how I have experienced it so far. Let’s get started by simplifying some stuff;

VPLS (Virtual Private Lan Service) is a L2VPN technology by which you can turn an ISP cloud consisting of numerous routers connecting different locations into an Ethernet Switch i.e it is a switch in the global network. Not yet clear? Let explain it by a simple example;

vpls_analogy

Above is a simplified view of two devices’ communication through an ISP network and both of these devices are in the same subnet and WebServer has a L2 connection towards the DatabaseServer e.g you can ping your database server from Webserver device and MAC address of Database Server will be in the ARP cache of Webserver device after a succesful ARP Request/Reply. This was the simplified view.

Before getting into the details, I need to list the prerequisites:

  • On this setup, for VPLS to work properly, you need to have a working MPLS clould which means IGP and RSVP should be running properly. To prepare the same MPLS cloud, you can take a look at my MPLS series posts here
  • Your MPLS LSPs must already been setup to create our L2 pipe.
  • For this setup, VLANs used on both side of the pipe must be the same

Now we will zoom in to this ISP network and see how VPLS is configured and verified but for this I need to put the ISP topology in detail and here it is;

vpls_srx

 

First I need to explain this setup a little. It is a single autonomous system with ASN 8500 on this lab. I also drew a rectangle to show the boundaries of this ISP network in other words our so-called L2 switch. Routers J40 and J35 are crossed by this rectangle as they represent the trunk ports of our switch since they are the PE routers in our ISP.

On this post, I will enable two devices on the west J39 (10.0.7.1)  and on the east side J37 (10.0.7.2) to communicate via this L2VPN. As you can see their IP addresses are on the same subnet.

As this is a free BGP core network, we running BGP only on J40 and J35 PE devices.

root@j40> show configuration protocols bgp 
family inet {
    unicast;
}
family l2vpn {
    signaling;
}
group IBGP {
    type internal;
    local-address 10.1.1.8;
    neighbor 10.1.1.7;
}

and our ingress and egress LSPs are also established.

root@j40> show mpls lsp 
Ingress LSP: 1 sessions
To              From            State Rt P     ActivePath       LSPname
10.1.1.7        10.1.1.8        Up     0 *                      j40-j35 
Total 1 displayed, Up 1, Down 0

Egress LSP: 1 sessions
To              From            State   Rt Style Labelin Labelout LSPname 
10.1.1.8        10.1.1.7        Up       0  1 FF       3        - j35-j40
Total 1 displayed, Up 1, Down 0

Transit LSP: 0 sessions
Total 0 displayed, Up 0, Down 0

Now we can start VPLS configuration:

J39 site is connected to our J40 PE router on its ge-0/0/3 interface. We will start with the east side first.

[edit]
root@j40# show interfaces ge-0/0/3  
vlan-tagging;
encapsulation vlan-vpls;
unit 803 {
    description "J39 Facing Interface";
    encapsulation vlan-vpls;
    vlan-id 803;
    family vpls;
}

[edit]
root@j40# show routing-instances vpn-b 
instance-type vpls;
interface ge-0/0/3.803;
route-distinguisher 10.1.1.8:102;
vrf-target target:8500:102;
protocols {
    vpls {
        site-range 2;
        no-tunnel-services;
        site ce-c {
            site-identifier 1;
        }
    }
}

As you can see we are using encapsulation vlan-vpls and interface is tagged hence we will accept tagged traffic on this interface. Let’s check if we have any VPLS connection or not.

root@j40> show vpls connections summary 
Layer-2 VPN Connections Summary:

Instance: vpn-b
  Local site: ce-c (1)
    Total VCs up: 0, Total VCs down: 0

hmm, nothing yet as we haven’t configured the remote PE router J35 yet. Now we configure the remote side;

[edit]
root@j35# show interfaces ge-0/0/3  
vlan-tagging;
encapsulation vlan-vpls;
unit 803 {
    description "J37 Facing interface";
    encapsulation vlan-vpls;
    vlan-id 803;
    family vpls;
}

[edit]
root@j35# show routing-instances vpn-b 
instance-type vpls;
interface ge-0/0/3.803;
route-distinguisher 10.1.1.7:102;
vrf-target target:8500:102;
protocols {
    vpls {
        site-range 2;
        no-tunnel-services;
        site ce-d {
            site-identifier 2;
        }
    }
}

If everything is correct, then we should have the VC up.

root@j40> 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
VM -- VLAN ID mismatch

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

Instance: vpn-b
  Local site: ce-c (1)
    connection-site           Type  St     Time last up          # Up trans
    2                         rmt   Up     Jan 11 19:24:56 2015           1  <---Channel IS UP
      Remote PE: 10.1.1.7, Negotiated control-word: No
      Incoming label: 262146, Outgoing label: 262145
      Local interface: lsi.1048576, Status: Up, Encapsulation: VPLS
        Description: Intf - vpls vpn-b local site 1 remote site 2

Yesss... we have brought the channel UP.

Now it is time to do a ping test from J39 to J37 which are located on two different sides of the ISP network.

root@j39> show arp no-resolve 
MAC Address       Address         Interface     Flags
78:19:f7:aa:d0:80 100.100.100.1   ge-0/0/4.0           none
00:0c:29:8b:5a:73 100.100.100.252 ge-0/0/4.0           none
Total entries: 2

root@j39> ping 10.0.7.2 count 1    
PING 10.0.7.2 (10.0.7.2): 56 data bytes
64 bytes from 10.0.7.2: icmp_seq=0 ttl=64 time=84.917 ms

--- 10.0.7.2 ping statistics ---
1 packets transmitted, 1 packets received, 0% packet loss
round-trip min/avg/max/stddev = 84.917/84.917/84.917/0.000 ms

root@j39> show arp no-resolve 
MAC Address       Address         Interface     Flags
00:0c:29:c3:b3:f4 10.0.7.2        ge-0/0/0.803         none  <--- MAC address of the remote device J37
78:19:f7:aa:d0:80 100.100.100.1   ge-0/0/4.0           none
00:0c:29:8b:5a:73 100.100.100.252 ge-0/0/4.0           none
Total entries: 3

Bingo!!! we have now L2VPN up and running and we are passing traffic.

We can also check the mac table on our PE router

root@j40> show route forwarding-table family vpls    
Routing table: vpn-b.vpls
VPLS:
Destination        Type RtRef Next hop           Type Index NhRef Netif
default            perm     0                    rjct   587     1
ge-0/0/3.803       user     0                    comp   561     2
lsi.1048576        user     0                    comp   593     2
00:0c:29:37:61:a2/48 dynm     0                  ucst   559     3 ge-0/0/3.803 <-- OUR MAC (J39)
00:0c:29:c3:b3:f4/48 dynm     0                  indr 262142     4  <-- REMOTE SIDE
                              24.1.1.1          Push 262145, Push 299824(top)   562     2 ge-0/0/0.0

I think I have achieved what I wanted to explain so far. VPLS is ready and passing traffic. If you do see any mistake or feedback, please drop your comments!

About: rtoodtoo

Worked for more than 10 years as a Network/Support Engineer and also interested in Python, Linux, Security and SD-WAN // JNCIE-SEC #223 / RHCE / PCNSE


5 thoughts on “VPLS on SRX”

  1. Hi, Hope you reed this, It is possible to somehow remove the tagged vlan in the vpls and deliver to the custommer as untagged?

  2. Hello

    When I type this command :”show route forwarding-table family vpls” , sometimes I a have the mac-address connected to the vpls interface sometimes not.

    If the mac-address appears, I don’t have the next-hop adress.

    VPLS:
    Destination Type RtRef Next hop Type Index NhRef Netif
    default perm 0 rjct 1313 1
    lsi.1048835 user 0 comp 1335 2
    ge-0/0/4.0 user 0 comp 1341 2

    What could be the cause of the problem ?

    Thank you in advance.

    1. sorry, it has been very login that I haven’t worked with VPLS on a junos box. I would advise to check release notes to see if there is any bug or not.

  3. How doea the ge-0/0/0 interface towards the mpls backbone look at J40 and J35?? Do you have the complete configuration (all routers and switches?)
    I am running a fairly new release which is 15.
    BR. Peter

Leave a Reply to rtoodtooCancel reply

Discover more from RtoDto.net

Subscribe now to keep reading and get access to the full archive.

Continue reading