Sunday 4 March 2012

Basic Junos MPLS based IP-VPNs

This post will cover how to set up and verify a basic MPLS based Unicast IPv4 VPN configuration using Junos.

This topology has 5 Routers:

Two CE routers each BGP peering with to two MPLS PE routers which are connected via a MPLS P router.  The P router is also acting as a BGP Route-Reflector.  The P/PE network is also using OSPF to support LDP and BGP loopback reachability:

R1(CE)-EBGP-R2(PE)-IBGP-R3(P)-IBGP-R4(PE)-EBGP-R5(CE)

We'll start with the PE and P configurations first

R2-PE
root@R2-PE> show configuration | display set
set system host-name R2-PE
set interfaces em1 vlan-tagging
set interfaces em1 unit 23 vlan-id 23
set interfaces em1 unit 23 family inet address 10.1.23.2/24
set interfaces lo0 unit 0 family inet address 2.2.2.2/32
set routing-options router-id 2.2.2.2
set protocols ospf area 0.0.0.0 interface em1.23
set protocols ospf area 0.0.0.0 interface lo0.0

So far this is just setting up the IGP so R2-PE will be able to communicate with R3-P

To enable MPLS, we need to add the protocol family to the interface so the interface will not discard MPLS traffic hitting it and then we need to add the interface to the protocol to establish the control plane level connectivity.  Finally to establish a mechanism to distribute MPLS labels, we turn on LDP.

root@R2-PE> configure
Entering configuration mode

[edit]
root@R2-PE# set interfaces em1 unit 23 family mplsroot@R2-PE# set protocols mpls interface em1.23root@R2-PE# set protocols ldp interface em1.23

Now we set up the IBGP connection to peer with R3-P only using the IPv4 VPN Unicast Address Family - note we are setting the local address to be the same as lo0.0

[edit]
root@R2-PE# set routing-options autonomous-system 65500
root@R2-PE# edit protocols bgp group Core
[edit protocols bgp group Core]
root@R2-PE# set type internal
root@R2-PE# set local-address 2.2.2.2
root@R2-PE# set family inet-vpn unicast
root@R2-PE# set peer-as 65500
root@R2-PE# set neighbor 3.3.3.3
root@R2-PE# commit and-quit
commit complete
Exiting configuration mode

The configuration for R4-PE is very similar to R2-PE

root@R4-PE> show configuration | display set
set system host-name R4-PE
set interfaces em1 vlan-tagging
set interfaces em1 unit 34 vlan-id 34
set interfaces em1 unit 34 family inet address 10.1.34.4/24
set interfaces lo0 unit 0 family inet address 4.4.4.4/32
set routing-options router-id 4.4.4.4
set protocols ospf area 0.0.0.0 interface lo0.0
set protocols ospf area 0.0.0.0 interface em1.34

set interfaces em1 unit 34 family mpls
set protocols mpls interface em1.34
set protocols ldp interface em1.34

set routing-options autonomous-system 65500
set protocols bgp group Core type internal
set protocols bgp group Core local-address 4.4.4.4
set protocols bgp group Core family inet-vpn unicast
set protocols bgp group Core peer-as 65500
set protocols bgp group Core neighbor 3.3.3.3

For R3-P - the configuration is very similar as to what has occured for R2-PE and R4-PE.  The primary difference here is that R3-P is a BGP route-reflector.  Within the configured BGP peer group, once the cluster id is set, the router is now acting as a route reflector

root@R3-P> show configuration | display set
set system host-name R3-P
set interfaces em1 vlan-tagging
set interfaces em1 unit 23 vlan-id 23
set interfaces em1 unit 23 family inet address 10.1.23.3/24
set interfaces em1 unit 34 vlan-id 34
set interfaces em1 unit 34 family inet address 10.1.34.3/24
set interfaces lo0 unit 0 family inet address 3.3.3.3/32
set routing-options router-id 3.3.3.3
set protocols ospf area 0.0.0.0 interface em1.23
set protocols ospf area 0.0.0.0 interface lo0.0
set protocols ospf area 0.0.0.0 interface em1.34

set interfaces em1 unit 23 family mpls
set interfaces em1 unit 34 family mpls
set protocols mpls interface em1.23
set protocols mpls interface em1.34
set protocols ldp interface em1.23
set protocols ldp interface em1.34

set routing-options autonomous-system 65500
set protocols bgp group Core-RRClients type internal
set protocols bgp group Core-RRClients local-address 3.3.3.3
set protocols bgp group Core-RRClients family inet-vpn unicast

set protocols bgp group Core-RRClients cluster 3.3.3.3 
set protocols bgp group Core-RRClients peer-as 65500
set protocols bgp group Core-RRClients neighbor 2.2.2.2
set protocols bgp group Core-RRClients neighbor 4.4.4.4

root@R3-P> show bgp neighbor | match "^Peer:|Type"
Peer: 2.2.2.2+64071 AS 65500   Local: 3.3.3.3+179 AS 65500
  Type: Internal    State: Established  (route reflector client)Flags:
Peer: 4.4.4.4+54609 AS 65500   Local: 3.3.3.3+179 AS 65500
  Type: Internal    State: Established  (route reflector client)Flags:

So at this stage, we have our core network MP-BGP enabled, MPLS/LDP active but no L3 VPN configuration yet

root@R2-PE> show bgp neighbor | match "^Peer:|Address families"
Peer: 3.3.3.3+179 AS 65500     Local: 2.2.2.2+64071 AS 65500
  Address families configured: inet-vpn-unicast

root@R2-PE> show route table inet.3

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

3.3.3.3/32         *[LDP/9] 00:26:46, metric 1
                    > to 10.1.23.3 via em1.23
4.4.4.4/32         *[LDP/9] 00:03:07, metric 1
                    > to 10.1.23.3 via em1.23, Push 299840

root@R3-P> show bgp neighbor | match "^Peer:|Address families"
Peer: 2.2.2.2+64071 AS 65500   Local: 3.3.3.3+179 AS 65500
  Address families configured: inet-vpn-unicast
Peer: 4.4.4.4+54609 AS 65500   Local: 3.3.3.3+179 AS 65500
  Address families configured: inet-vpn-unicast

root@R3-P> show route table inet.3

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

2.2.2.2/32         *[LDP/9] 00:04:14, metric 1
                    > to 10.1.23.2 via em1.23
4.4.4.4/32         *[LDP/9] 00:04:10, metric 1
                    > to 10.1.34.4 via em1.34
root@R4-PE> show bgp neighbor | match "^Peer:|Address families"
Peer: 3.3.3.3+179 AS 65500     Local: 4.4.4.4+54609 AS 65500
  Address families configured: inet-vpn-unicast

root@R4-PE> show route table inet.3

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

2.2.2.2/32         *[LDP/9] 00:04:48, metric 1
                    > to 10.1.34.3 via em1.34, Push 299872
3.3.3.3/32         *[LDP/9] 00:04:48, metric 1
                    > to 10.1.34.3 via em1.34

Lets create the Routing-Instance (VRF) on the PEs

Starting on R2 - we define the IP interface in the base router configuration facing R1-CE

root@R2-PE> configure
Entering configuration mode

[edit]
root@R2-PE# set interfaces em1 unit 12 vlan-id 12
root@R2-PE# set interfaces em1 unit 12 family inet address 10.1.12.2/24


Then the rest of the configuration will be contained within a routing-instance CustomerA

Firstly we add the interface to the routing instance and define the instance to be a vrf and set the L3 VPN's RD and RT values:

root@R2-PE# edit routing-instances CustomerA

[edit routing-instances CustomerA]
root@R2-PE# set interface em1.12
root@R2-PE# set instance-type vrf
root@R2-PE# set route-distinguisher 65500:1
root@R2-PE# set vrf-target target:65500:1





The following command is a hack used on Olives which doesn't have a tunnel services PIC to assist in the double label lookup, so normally isn't required on real platforms.

[edit routing-instances CustomerA]
root@R2-PE# set vrf-table-label

Now we set up the BGP configuration to peer with our R1-CE


[edit routing-instances CustomerA]
root@R2-PE# edit protocols bgp group CE

[edit routing-instances CustomerA protocols bgp group CE]
root@R2-PE# set type external
root@R2-PE# set family inet unicast
root@R2-PE# set neighbor 10.1.12.1 peer-as 64512
root@R2-PE# commit and-quit
commit complete
Exiting configuration mode

For R4-PE the configuration is similar (R5-CE is in AS 64513)

root@R4-PE> configure
Entering configuration mode

[edit]
root@R4-PE# set interfaces em1 unit 45 vlan-id 45
root@R4-PE# set interfaces em1 unit 45 family inet address 10.1.45.4/24
root@R4-PE# edit routing-instances CustomerA

[edit routing-instances CustomerA]
root@R4-PE# set instance-type vrf
root@R4-PE# set interface em1.45
root@R4-PE# set route-distinguisher 65500:1
root@R4-PE# set vrf-target target:65500:1
root@R4-PE# set vrf-table-label
root@R4-PE# edit protocols bgp group CE

[edit routing-instances CustomerA protocols bgp group CE]
root@R4-PE# set type external
root@R4-PE# set family inet unicast
root@R4-PE# set neighbor 10.1.45.5 peer-as 64513
root@R4-PE# commit and-quit
commit complete
Exiting configuration mode

The CE Configurations are quite straight forward - each has an EBGP peering with the MPLS PE and redistributes it's directly connected interfaces into BGP with the intention that each CE will have reachability to the others lo0.0 interface.

root@R1-CE> show configuration | display set
set system host-name R1-CE
set interfaces em1 vlan-tagging
set interfaces em1 unit 12 vlan-id 12
set interfaces em1 unit 12 family inet address 10.1.12.1/24
set interfaces lo0 unit 0 family inet address 1.1.1.1/32
set routing-options autonomous-system 64512
set protocols bgp export ToBGP
set protocols bgp group PE type external
set protocols bgp group PE family inet unicast
set protocols bgp group PE peer-as 65500
set protocols bgp group PE neighbor 10.1.12.2
set policy-options policy-statement ToBGP term Direct from protocol direct
set policy-options policy-statement ToBGP term Direct then accept

root@R5-CE> show configuration | display set
set system host-name R5-CE
set interfaces em1 vlan-tagging
set interfaces em1 unit 45 vlan-id 45
set interfaces em1 unit 45 family inet address 10.1.45.5/24
set interfaces lo0 unit 0 family inet address 5.5.5.5/32
set routing-options router-id 5.5.5.5
set routing-options autonomous-system 64513
set protocols bgp export ToBGP
set protocols bgp group PE type external
set protocols bgp group PE family inet unicast
set protocols bgp group PE peer-as 65500
set protocols bgp group PE neighbor 10.1.45.4
set policy-options policy-statement ToBGP term Direct from protocol direct
set policy-options policy-statement ToBGP term Direct then accept


Lets verify that things are operational First lets check the control plane view


root@R1-CE> show route terse

inet.0: 5 destinations, 5 routes (5 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.1/32         D   0                       >lo0.0
* 5.5.5.5/32         B 170        100            >10.1.12.2       65500 64513 I
* 10.1.12.0/24       D   0                       >em1.12
* 10.1.12.1/32       L   0                        Local
* 10.1.45.0/24       B 170        100            >10.1.12.2       65500 I

R1 can see R5's loopback and the BGP AS path is as expected.

Lets track how things get there through the Core

root@R2-PE> show route instance CustomerA
Instance             Type
         Primary RIB                                     Active/holddown/hidden
CustomerA            vrf
         CustomerA.inet.0                                5/0/0

root@R2-PE> show route table CustomerA.inet.0

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

1.1.1.1/32         *[BGP/170] 00:16:58, localpref 100
                      AS path: 64512 I
                    > to 10.1.12.1 via em1.12
5.5.5.5/32         *[BGP/170] 00:06:01, localpref 100, from 3.3.3.3
                      AS path: 64513 I
                    > to 10.1.23.3 via em1.23, Push 16, Push 299840(top)
10.1.12.0/24       *[Direct/0] 00:17:02
                    > via em1.12
                    [BGP/170] 00:16:58, localpref 100
                      AS path: 64512 I
                    > to 10.1.12.1 via em1.12
10.1.12.2/32       *[Local/0] 00:17:02
                      Local via em1.12
10.1.45.0/24       *[BGP/170] 00:11:23, localpref 100, from 3.3.3.3
                      AS path: I
                    > to 10.1.23.3 via em1.23, Push 16, Push 299840(top)


The Top label should be the label that gets us to R4-PE

root@R2-PE> show route table inet.3

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

3.3.3.3/32         *[LDP/9] 00:41:33, metric 1
                    > to 10.1.23.3 via em1.23
4.4.4.4/32         *[LDP/9] 00:36:07, metric 1
                    > to 10.1.23.3 via em1.23, Push 299840

On the Route Reflector we can see that the VPN Label matches up as well

root@R3-P> show route table bgp.l3vpn.0 5.5.5.5/32

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

65500:1:5.5.5.5/32
                   *[BGP/170] 00:43:02, localpref 100, from 4.4.4.4
                      AS path: 64513 I
                    > to 10.1.34.4 via em1.34, Push 16


Which we can confirm that Label 16 on R4-PE refers to the CustomerA.inet.0 routing table.

root@R4-PE> show route table mpls

mpls.0: 7 destinations, 7 routes (7 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

0                  *[MPLS/0] 02:21:40, metric 1
                      Receive
1                  *[MPLS/0] 02:21:40, metric 1
                      Receive
2                  *[MPLS/0] 02:21:40, metric 1
                      Receive
16                 *[VPN/0] 00:51:50
                      to table CustomerA.inet.0, Pop
300112             *[LDP/9] 00:51:37, metric 1
                    > to 10.1.34.3 via em1.34, Pop
300112(S=0)        *[LDP/9] 00:51:37, metric 1
                    > to 10.1.34.3 via em1.34, Pop
300128             *[LDP/9] 00:51:37, metric 1
                    > to 10.1.34.3 via em1.34, Swap 299872

All this certainly indicates that we should have connectivity from R1-CE to R5-CE, so lets verify it:

root@R1-CE> ping 5.5.5.5 source 1.1.1.1 count 3
PING 5.5.5.5 (5.5.5.5): 56 data bytes
64 bytes from 5.5.5.5: icmp_seq=0 ttl=63 time=6.351 ms
64 bytes from 5.5.5.5: icmp_seq=1 ttl=63 time=3.656 ms
64 bytes from 5.5.5.5: icmp_seq=2 ttl=63 time=4.496 ms

--- 5.5.5.5 ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max/stddev = 3.656/4.834/6.351/1.126 ms

Yes we do.

No comments:

Post a Comment