MP-BGP signalled VPLS and L3 VRFs over MPLS on SRX

My last post was how to setup an RSVP based MPLS tunnel between two SRXs. These general concepts can be applied to any Juniper router like SRX, J and MX, no matter whether it’s in flow mode like my SRXs or not. In this post, I will setup a L2 VPLS and a L3 VRF and do all the verification to show you the correct operation of these running on the network. (This post will just be L2 VPLS, in the next one ill move into point to point L2 tunnels, using LDP and BGP signalling)

Currently I have a simple MPLS network using RSVP between two SRX Juniper router/firewalls. There is one path in each direction and no complicated knobs or features being utilised at this stage. What I want to be able to achieve in this post is building a Layer 3 VRF to exchange routes in and a VPLS to bridge a LAN between the two routers.

perrin@srx-au> show configuration protocols bgp | display set 
perrin@srx-au> show configuration protocols bgp group mpls-core | display set
set protocols bgp group mpls-core type internal
set protocols bgp group mpls-core multihop
set protocols bgp group mpls-core local-address 119.69.0.5
set protocols bgp group mpls-core family inet unicast
set protocols bgp group mpls-core family inet multicast
set protocols bgp group mpls-core family inet-vpn unicast
set protocols bgp group mpls-core family inet6 unicast
set protocols bgp group mpls-core family inet6 multicast
set protocols bgp group mpls-core family inet6-vpn unicast
set protocols bgp group mpls-core family l2vpn signaling
set protocols bgp group mpls-core graceful-restart
set protocols bgp group mpls-core neighbour 119.69.0.1

Just to quickly recap, here is the BGP configuration we will be using to signal our VRFs, applicable to this situation is “l2vpn signalling” and “inet-vpn unicast” These enable BGP to carry correct NLRI per service we are enabling.

I’ll start with the L3 VRF

perrin@srx-au> show configuration routing-instances |display set 
set routing-instances CORE_L3VPN_LAB instance-type vrf
set routing-instances CORE_L3VPN_LAB interface lt-0/0/0.1
set routing-instances CORE_L3VPN_LAB route-distinguisher 119.69.0.5:1001
set routing-instances CORE_L3VPN_LAB vrf-target target:64514:1001

Not too bad yeah! I'll explain a few things quickly. So firstly there is the vrf-target. This is specifying the BGP community to match when exchanging routes with other PE routers, or in this case, the SRX on the other end. This is carried across the MPLS tunnel as a secondary tag, going through a larger MPLS network this would have the top MPLS label added on top the the P routers would use to pass the traffic through to the correct egress router. VRFs will export all VRFs tagged with "64514:1001" and import them into any router with a matching target. The "route-distinguisher" essentially "distinguishes" which IP address belongs to what VRF. The RD field is added to a route when transported across the network. Naturally there is a lot more detail in what each of these two components too, but I'm trying to make this a more hands on, "lets actually configure it" exercise.

To demonstrate the redistribution of routes across this VPN, I have done a simple route import from my inet.0 table on one SRX,

set routing-options interface-routes rib-group inet inet.0-to-CORE_L3VPN_LAB
set routing-options rib-groups inet.0-to-CORE_L3VPN_LAB import-rib inet.0
set routing-options rib-groups inet.0-to-CORE_L3VPN_LAB import-rib CORE_L3VPN_LAB.inet.0

That is a rib copy to do interface routes only coping from inet.0 to CORE_L3VPN_LAB. Example before the RIB copy

perrin@srx-nz# run show route table CORE_L3VPN_LAB terse 

CORE_L3VPN_LAB.inet.0: 3 destinations, 4 routes (3 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

A Destination        P Prf   Metric 1   Metric 2  Next hop         AS path
* 1.1.1.0/24         D   0                       >lt-0/0/0.1   
                     B 170        100            >gr-0/0/0.2       I
* 1.1.1.2/32         L   0                        Local
* 192.168.1.0/24     B 170        100            >gr-0/0/0.2       I

and after the RIB copy is applied

perrin@srx-nz> show route table CORE_L3VPN_LAB terse   

CORE_L3VPN_LAB.inet.0: 34 destinations, 37 routes (33 active, 0 holddown, 1 hidden)
+ = Active Route, - = Last Active, * = Both

A Destination        P Prf   Metric 1   Metric 2  Next hop         AS path
* 1.1.1.0/24         D   0                       >lt-0/0/0.1   
                     B 170        100            >gr-0/0/0.2       I
* 1.1.1.2/32         L   0                        Local
* 10.0.2.0/24        D   0                       >lo0.0        
* 10.0.2.1/32        L   0                        Local
* 10.0.252.0/31      D   0                       >gr-0/0/0.3   
* 10.0.252.0/32      L   0                        Local
* 10.0.255.0/31      D   0                       >gr-0/0/0.0   
* 10.0.255.0/32      L   0                        Local
* 10.0.255.2/31      D   0                       >ip-0/0/0.3   
* 10.0.255.2/32      L   0                        Local
* 10.0.255.4/31      D   0                       >gr-0/0/0.2   
* 10.0.255.4/32      L   0                        Local
* 10.0.255.12/30     D   0                       >gr-0/0/0.0   
* 10.0.255.13/32     L   0                        Local
* 10.0.255.240/30    D   0                       >ip-0/0/0.0   
* 10.0.255.242/32    L   0                        Local
* 119.69.0.1/32      D   0                       >lo0.0        
* 172.16.1.0/30      D   0                       >vlan.20      
* 172.16.1.1/32      L   0                        Local
* 172.16.2.0/32      D   0                       >lo0.0        
* 172.16.5.0/31      D   0                       >vlan.30      
* 172.16.5.0/32      L   0                        Local
* 172.16.31.254/32   D   0                       >lo0.0        
* 172.31.255.254/32  D   0                       >lo0.0        
* 172.32.255.254/32  D   0                       >lo0.0        
* 192.168.0.16/30    D   0                       >gr-0/0/0.1   
* 192.168.0.18/32    L   0                        Local
* 192.168.1.0/24     D   0                       >vlan.5       
                     B 170        100            >gr-0/0/0.2       I
* 192.168.1.2/32     L   0                        Local
* 192.168.1.251/32   L   0                        Local
* 202.124.101.64/29  D   0                       >ge-0/0/0.0   
                     D   0                       >ge-0/0/0.0   
* 202.124.101.66/32  L   0                        Local
* 202.124.101.69/32  L   0                        Local

As you can see here we have a heap of routes now populated that are traditionally interface routes on the srx_nz router. All going to plan, the routes should have now been transported via the MPLS tunnel to the other end.

perrin@srx-au> show route table CORE_L3VPN_LAB.inet.0          

CORE_L3VPN_LAB.inet.0: 17 destinations, 17 routes (17 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

1.1.1.0/24         *[Direct/0] 6d 03:57:59
                    > via lt-0/0/0.1
1.1.1.1/32         *[Local/0] 6d 03:57:59
                      Local via lt-0/0/0.1
10.0.2.0/24        *[BGP/170] 00:01:10, localpref 100, from 119.69.0.1
                      AS path: I
                    > via gr-0/0/0.2, label-switched-path 5-to-1
10.0.2.1/32        *[BGP/170] 00:01:10, localpref 100, from 119.69.0.1
                      AS path: I
                    > via gr-0/0/0.2, label-switched-path 5-to-1
10.0.252.0/31      *[BGP/170] 00:01:10, localpref 100, from 119.69.0.1
                      AS path: I
                    > via gr-0/0/0.2, label-switched-path 5-to-1
10.0.255.0/31      *[BGP/170] 00:01:10, localpref 100, from 119.69.0.1
                      AS path: I
                    > via gr-0/0/0.2, label-switched-path 5-to-1
10.0.255.2/31      *[BGP/170] 00:01:10, localpref 100, from 119.69.0.1
***output ommited***

Excellent, everything is working well, I haven't displayed everything here but you get the idea. All the routes have been learned from BGP via LSP 5-to-1, if you were using a route reflector for your BGP, then that would be where the "from 119.69.0.1" for my lab just have the BGP point to point. By default, BGP is the only routing protocol that can view the inet.3 table which it uses to resolve the next hop.

perrin@srx-au> show route table inet.3    
inet.3: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

119.69.0.1/32      *[RSVP/7/1] 05:01:26, metric 1
                    > via gr-0/0/0.2, label-switched-path 5-to-1

For a more in-depth look at routes, you can add the extensive flag on the end to view more detailed information like BGP attributes and label information

perrin@srx-au> show route table CORE_L3VPN_LAB.inet.0 10.0.2.0/24 extensive 

CORE_L3VPN_LAB.inet.0: 17 destinations, 17 routes (17 active, 0 holddown, 0 hidden)
10.0.2.0/24 (1 entry, 1 announced)
TSI:
KRT in-kernel 10.0.2.0/24 -> {indirect(262146)}
        *BGP    Preference: 170/-101
                Route Distinguisher: 119.69.0.1:1001
                Next hop type: Indirect
                Address: 0x15b95bc
                Next-hop reference count: 18
                Source: 119.69.0.1
                Next hop type: Router, Next hop index: 643
                Next hop: via gr-0/0/0.2 weight 0x1, selected
                Label-switched-path 5-to-1
                Label operation: Push 315504
                Label TTL action: prop-ttl
                Protocol next hop: 119.69.0.1
                Push 315504
                Indirect next hop: 1694bc8 262146
                State: 
                Local AS: 64514 Peer AS: 64514
                Age: 53:00 	Metric2: 1 
                Task: BGP_64514.119.69.0.1+179
                Announcement bits (1): 1-KRT 
                AS path: I
                Communities: target:64514:1001
                Import Accepted
                VPN Label: 315504
                Localpref: 100
                Router ID: 119.69.0.1
                Primary Routing Table bgp.l3vpn.0
                Indirect next hops: 1
                        Protocol next hop: 119.69.0.1 Metric: 1
                        Push 315504
                        Indirect next hop: 1694bc8 262146
                        Indirect path forwarding next hops: 1
                                Next hop type: Router
                                Next hop: via gr-0/0/0.2 weight 0x1
			119.69.0.1/32 Originating RIB: inet.3
			  Metric: 1			  Node path count: 1
			  Forwarding nexthops: 1
				Nexthop: via gr-0/0/0.2

Thats pretty much that sorted. A fully operational L3 VRF using RSVP MPLS. Now I'll show you the VPLS.

perrin@srx-au> show configuration routing-instances CORE_VPLS_LAB | display set 
set routing-instances CORE_VPLS_LAB instance-type vpls
set routing-instances CORE_VPLS_LAB vlan-id none
set routing-instances CORE_VPLS_LAB interface lt-0/0/0.0
set routing-instances CORE_VPLS_LAB route-distinguisher 119.69.0.5:1000
set routing-instances CORE_VPLS_LAB vrf-target target:64514:1000
set routing-instances CORE_VPLS_LAB protocols vpls site-range 255
set routing-instances CORE_VPLS_LAB protocols vpls no-tunnel-services
set routing-instances CORE_VPLS_LAB protocols vpls site srx-au site-identifier 5
set routing-instances CORE_VPLS_LAB protocols vpls connectivity-type ce

This is example assumes prior knowledge of VPLS operation, thinks like mac address transporting and components with NLRI for VPLS attributes. With the VPLS configured on both sides, we can verify it with these few commands. Also things like vrf-target and route-distinguisher share very similar properties here in application as they do with L3 VRFs

perrin@srx-au> show vpls connections 
**output ommited**
Instance: CORE_VPLS_LAB
  Local site: srx-au (5)
    connection-site           Type  St     Time last up          # Up trans
    1                         rmt   Up     Jan 20 17:00:59 2014           1
      Remote PE: 119.69.0.1, Negotiated control-word: No
      Incoming label: 262145, Outgoing label: 262157
      Local interface: lsi.1051648, Status: Up, Encapsulation: VPLS
        Description: Intf - vpls CORE_VPLS_LAB local site 5 remote site 1
perrin@srx-au> show route table CORE_VPLS_LAB 

CORE_VPLS_LAB.l2vpn.0: 2 destinations, 2 routes (2 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

119.69.0.1:1000:1:1/96                
                   *[BGP/170] 05:29:56, localpref 100, from 119.69.0.1
                      AS path: I
                    > via gr-0/0/0.2, label-switched-path 5-to-1
119.69.0.5:1000:5:1/96                
                   *[L2VPN/170/-101] 6d 04:38:11, metric2 1
                      Indirect

Here you can see the remote VPLS site is signed as UP, that command also shows some label operation and the local label switched interface. LSI's are used when no-tunnel-services as you longer need to use a tunnel pic to run VPLS.

We can go into more detail my adding the extensive command on the end to view things like community tags and local-pref

perrin@srx-au> show route table CORE_VPLS_LAB extensive 

CORE_VPLS_LAB.l2vpn.0: 2 destinations, 2 routes (2 active, 0 holddown, 0 hidden)
 119.69.0.1:1000:1:1/96 (1 entry, 1 announced)
        *BGP    Preference: 170/-101
                Route Distinguisher: 119.69.0.1:1000
                Next hop type: Indirect
                Address: 0x15ba0b8
                Next-hop reference count: 5
                Source: 119.69.0.1
                Protocol next hop: 119.69.0.1
                Indirect next hop: 2 no-forward
                State: 
                Local AS: 64514 Peer AS: 64514
                Age: 5:38:48 	Metric2: 1 
                Task: BGP_64514.119.69.0.1+179
                Announcement bits (1): 0-CORE_VPLS_LAB-l2vpn 
                AS path: I
                Communities: target:64514:1000 Layer2-info: encaps:VPLS, control flags:, mtu: 0, site preference: 100
                Import Accepted
                Label-base: 262153, range: 8
                Localpref: 100
                Router ID: 119.69.0.1
                Primary Routing Table bgp.l2vpn.0
                Indirect next hops: 1
                        Protocol next hop: 119.69.0.1 Metric: 1
                        Indirect next hop: 2 no-forward
                        Indirect path forwarding next hops: 1
                                Next hop type: Router
                                Next hop: via gr-0/0/0.2 weight 0x1
			119.69.0.1/32 Originating RIB: inet.3
			  Metric: 1			  Node path count: 1
			  Forwarding nexthops: 1
				Nexthop: via gr-0/0/0.2
**output ommited**

Unfortunately one really crucial command in my opinion that seems to be missing from the SRX platform is the "show vpls mac-table" command. This can be used to view the bridging table of the VPLS instance. Remote sites show up as their appropriate LSI interfaces with the 48 bit mac address and locally learnt macs via the local interface. i.e. ge-0/0/0 or in my case lt-0/0/0.0 Of course on a proper MPLS router like the MX line, these commands are all supported and work well.

That raps up a quick overview on how to provision simple VPLS and L3 services over MP-BGP signalled MPLS. I can appreciate that this kind of configuration is all over the internet but here I am trying to demonstrate a working model over some very basic juniper routers, at low cost and between two countries :) Enjoy and stay tuned for some reading on LDP based technology and more advanced RSVP-TE concepts.

Leave a Reply

Your email address will not be published.

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

WordPress spam blocked by CleanTalk.