|
In this article, we show you how to build a basic VPRN : an ISP network composed of 1 core router interconnecting two customer sites on 2 different edge routers. OSPF is used as an IGP and customer's routers are peering with ISP router using eBPG. After completing steps below, hosts on each sites should ping each other.
Software used in this scenario :
-
Hypervisor : VMware ESXi 6.0.0 build-2494585
-
Routers : CSR1000V, IOS XE Version 03.15.00.S, IOS Version 15.5(2)S
Step 1 : cabling routersRouters and hosts are connected using VLANs on a same vSwtich to emulate direct connections. 

Step 2 : addressing and IGP configuration and MPLS activation
We begin configuring CE1, this router is not part of the backbone, neither MPLS nor IGP is needed :
interface GigabitEthernet2 ip address 192.168.10.1 255.255.255.252 negotiation auto ! interface GigabitEthernet3 ip address 172.16.100.254 255.255.255.0 negotiation auto |
On PE1, we activate MPLS toward the core router that only switch label packets. We also activate OSPF on the core facing interface for the edge router to be known (routed) within the backbone. Notice that customer facing interface is added to a VRF :
ip vrf CUSTOMER1 rd 64512:1 route-target export 64512:1 route-target import 64512:1 ! interface GigabitEthernet2 ip vrf forwarding CUSTOMER1 ip address 192.168.10.2 255.255.255.252 negotiation auto ! interface GigabitEthernet3 ip address 192.168.20.1 255.255.255.252 negotiation auto mpls ip ! router ospf 1 network 192.168.20.0 0.0.0.3 area 0 |
On P router, we activate OSPF and MPLS on both links :
interface GigabitEthernet2 ip address 192.168.20.2 255.255.255.252 negotiation auto mpls ip ! interface GigabitEthernet3 ip address 192.168.30.2 255.255.255.252 negotiation auto mpls ip ! router ospf 1 network 192.168.20.0 0.0.0.3 area 0 network 192.168.30.0 0.0.0.3 area 0 |
Configuration on PE2 and CE2 is not detailed because it is similar to PE1 and CE1 configuration. Verifications :
! to check on which interface MPLS is activated PE1#show mpls interfaces Interface IP Tunnel BGP Static Operational GigabitEthernet3 Yes (ldp) No No No Yes ! to check LDP ID, and LDP Hello messages received if any
PE1#show mpls ldp discovery Local LDP Identifier: 192.168.20.1:0 Discovery Sources: Interfaces: GigabitEthernet3 (ldp): xmit/recv LDP Id: 192.168.30.2:0 ! to check LDP session PE1#show mpls ldp neighbor Peer LDP Ident: 192.168.30.2:0; Local LDP Ident 192.168.20.1:0 TCP connection: 192.168.30.2.51582 - 192.168.20.1.646 State: Oper; Msgs sent/rcvd: 6/6; Downstream Up time: 00:00:53 LDP discovery sources: GigabitEthernet3, Src IP addr: 192.168.20.2 Addresses bound to peer LDP Ident: 192.168.30.2 192.168.20.2 ! to check ospf adjacency PE1#show ip ospf neighbor Neighbor ID Pri State Dead Time Address Interface 192.168.30.2 1 FULL/BDR 00:00:30 192.168.20.2 GigabitEthernet3 |
Step 3 : configuring eBGP peering 
On CE1,
router bgp 64512 bgp log-neighbor-changes redistribute connected neighbor 192.168.10.2 remote-as 4200000000 |
On PE1,
router bgp 4200000000 bgp log-neighbor-changes ! address-family ipv4 vrf CUSTOMER1 neighbor 192.168.10.1 remote-as 64512 neighbor 192.168.10.1 activate exit-address-family |
Verifications :
! to check eBGP session PE1#show bgp all summary snip Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd 192.168.10.1 4 64512 15 15 3 0 0 00:09:56 2 ! to check prefixes learned PE1#show bgp vpnv4 unicast vrf CUSTOMER1 snip Network Next Hop Metric LocPrf Weight Path Route Distinguisher: 64512:1 (default for vrf CUSTOMER1) *>
172.16.100.0/24 192.168.10.1 0 0 64512 ? r> 192.168.10.0/30 192.168.10.1 0 0 64512 ? ! to check RIB insertion PE1#show ip route vrf CUSTOMER1 Routing Table: CUSTOMER1 snip Gateway of last resort is not set 172.16.0.0/24 is subnetted, 1 subnets B
172.16.100.0 [20/0] via 192.168.10.1, 00:05:17 192.168.10.0/24 is variably subnetted, 2 subnets, 2 masks C 192.168.10.0/30 is directly connected, GigabitEthernet2 L 192.168.10.2/32 is directly connected, GigabitEthernet2
|
Step 4 : configuring MP-BGP
On PE1, we configure iBGP peering with P2 to exchange VPNv4 routes via MP-BGP :
bgp log-neighbor-changes
neighbor 192.168.30.1 remote-as 4200000000
!
address-family vpnv4
neighbor 192.168.30.1 activate
neighbor 192.168.30.1 send-community extended
exit-address-family |
Similar configuration is done on PE2.
Verifications :
! to check iBGP session PE1#show bgp vpnv4 unicast all summary snip Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd 192.168.10.1 4 64512 21 22 9 0 0 00:15:40 2 192.168.30.1 4 4200000000 15 15 9 0 0 00:08:10 2 ! to check prefixes learned PE1#show bgp vpnv4 unicast all snip Network Next Hop Metric LocPrf Weight Path Route Distinguisher: 64512:1 (default for vrf CUSTOMER1) *>
172.16.100.0/24 192.168.10.1 0 0 64512 ? *>i
172.16.200.0/24 192.168.30.1 0 100 0 64512 ? r> 192.168.10.0/30 192.168.10.1 0 0 64512 ? *>i
192.168.40.0/30 192.168.30.1 0 100 0 64512 ? ! to check RIB import PE1#show ip route vrf CUSTOMER1 Routing Table: CUSTOMER1 snip Gateway of last resort is not set 172.16.0.0/24 is subnetted, 2 subnets B 172.16.100.0 [20/0] via 192.168.10.1, 00:18:38 B 172.16.200.0 [200/0] via 192.168.30.1, 00:11:57 192.168.10.0/24 is variably subnetted, 2 subnets, 2 masks C 192.168.10.0/30 is directly connected, GigabitEthernet2 L 192.168.10.2/32 is directly connected, GigabitEthernet2 192.168.40.0/30 is subnetted, 1 subnets B 192.168.40.0 [200/0] via 192.168.30.1, 00:11:57 ! problem, on CE1, routes from CE2 are not learned from PE1 : CE1#show ip route snip Gateway of last resort is not set 172.16.0.0/16 is variably subnetted, 2 subnets, 2 masks C 172.16.100.0/24 is directly connected, GigabitEthernet3 L 172.16.100.254/32 is directly connected, GigabitEthernet3 192.168.10.0/24 is variably subnetted, 2 subnets, 2 masks C 192.168.10.0/30 is directly connected, GigabitEthernet2 L 192.168.10.1/32 is directly connected, GigabitEthernet2 CE1#show ip bgp snip Network Next Hop Metric LocPrf Weight Path *> 172.16.100.0/24 0.0.0.0 0 32768 ? *> 192.168.10.0/30 0.0.0.0 0 32768 ? |
First issue
If we activate BGP updates debugging on CE1, we can see that CE2's routes are announced by PE1 but denied by CE1 :
CE1#terminal monitor CE1#debug bgp ipv4 unicast updates BGP updates debugging is on for address family: IPv4 Unicast CE1#clear bgp ipv4 un 192.168.10.2 CE1# *Jul 19 2016 12:12:15.842 CEST: %BGP-3-NOTIFICATION: sent to neighbor 192.168.10.2 6/4 (Administrative Reset) 0 bytes *Jul 19 2016 12:12:15.843 CEST: %BGP-5-ADJCHANGE: neighbor 192.168.10.2 Down User reset *Jul 19 2016 12:12:15.843 CEST: %BGP_SESSION-5-ADJCHANGE: neighbor 192.168.10.2 IPv4 Unicast topology base removed from session User reset *Jul 19 2016 12:12:15.895 CEST: %BGP-5-ADJCHANGE: neighbor 192.168.10.2 Up CE1# *Jul 19 2016 12:12:15.896 CEST: BGP(0): (base) 192.168.10.2 send UPDATE (format) 172.16.100.0/24, next 192.168.10.1, metric 0, path Local *Jul 19 2016 12:12:15.899 CEST: BGP(0): 192.168.10.2 rcv UPDATE w/ attr: nexthop 192.168.10.2, origin ?, originator 0.0.0.0,
merged path 4200000000 64512, AS_PATH , community , extended community , SSA attribute *Jul 19 2016 12:12:15.899 CEST: BGPSSA ssacount is 0 *Jul 19 2016 12:12:15.899 CEST: BGP(0): 192.168.10.2 rcv UPDATE about 172.16.200.0/24 --
DENIED due to: AS-PATH contains our own AS; *Jul 19 2016 12:12:15.899 CEST: BGP(0): 192.168.10.2 rcv UPDATE about 192.168.40.0/30 --
DENIED due to: AS-PATH contains our own AS; |
This is a normal behavior : routes are rejected by CE1 because AS-PATH attribute contains CE1's AS number. This is the well known BGP loop prevention mechanism. One solution is to delete CE's AS number from the AS-PATH :
PE1(config)#router bgp 4200000000 PE1(config-router)#address-family ipv4 vrf CUSTOMER1 PE1(config-router-af)#neighbor 192.168.10.1 as-override |
With the « as-override » command, BGP router rewrite AS-PATH attribute before sending BGP update replacing customer's AS number 64512 with it's own AS number 4200000000. This time, BGP updates are accepted by CE1 and routes are installed in CE1's RIB, notice the modified AS-PATH :
CE1#show ip bgp snip Network Next Hop Metric LocPrf Weight Path *> 172.16.100.0/24 0.0.0.0 0 32768 ? *>
172.16.200.0/24 192.168.10.2 0 4200000000 4200000000 ? *> 192.168.10.0/30 0.0.0.0 0 32768 ? *>
192.168.40.0/30 192.168.10.2 0 4200000000 4200000000 ? CE1#show ip route snip 172.16.0.0/16 is variably subnetted, 3 subnets, 2 masks C 172.16.100.0/24 is directly connected, GigabitEthernet3 L 172.16.100.254/32 is directly connected, GigabitEthernet3 B 172.16.200.0/24 [20/0] via 192.168.10.2, 00:18:44 192.168.10.0/24 is variably subnetted, 2 subnets, 2 masks C 192.168.10.0/30 is directly connected, GigabitEthernet2 L 192.168.10.1/32 is directly connected, GigabitEthernet2 192.168.40.0/30 is subnetted, 1 subnets B 192.168.40.0 [20/0] via 192.168.10.2, 00:18:44 |
Now let's try to test connectivity between customer sites by pinging CE2's internal interface:
CE1#ping 172.16.200.254 source 172.16.100.254 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 172.16.200.254, timeout is 2 seconds: Packet sent with a source address of 172.16.100.254 ..... Success rate is 0 percent (0/5) CE1#traceroute 172.16.200.254 source 172.16.100.254 Type escape sequence to abort. Tracing the route to 172.16.200.254 VRF info: (vrf in name/id, vrf out name/id) 1 192.168.10.2 2 msec 4 msec 1 msec 2 * * * 3 * * * 4 * * * snip
|
Ping KO, traceroute stops at PE1…
Second issue
As you noticed, we tried to set up MPLS L3VPN without configuring loopbacks on the ISP's routers. Because we don't care of redundancy in our scenario (there's only one path between edge routers), we can think that loopbacks are not required but in fact loopbacks are needed for packets can get to their destination.
The problem is that when pinging 172.16.200.254 CE2's interface from 172.16.100.254 CE1's interface, packets are leaving CE1 with only one label, the VPN label, but no IGP label on top of the label stack. When receiving these labeled packets, router P drops them, because VPN labels are irrelevant for core routers.
The reason for PE1 forwarding packets to P with no IGP label is that P distributes to its neighbors the implicit-null label for prefix 192.168.30.0/30 as it is directly connected :
P#show mpls ldp bindings detail snip lib entry:
192.168.30.0/30, rev 4, chkpt: none local binding: label:
imp-null (owner LDP) Advertised to: 192.168.20.1:0 192.168.30.1:0 remote binding: lsr: 192.168.20.1:0, label: 16 checkpointed remote binding: lsr: 192.168.30.1:0, label: imp-null checkpointed |
Notice the outpout chain for destination 172.16.200.0/24 on PE1 :
PE1#show ip cef vrf CUSTOMER1 172.16.200.0/24 internal 172.16.200.0/24, epoch 0, flags [rlbls], RIB[B], refcnt 6, per-destination sharing sources: RIB feature space: IPRM: 0x00018000 Broker: linked, distributed at 3rd priority LFD: 172.16.200.0/24 0 local labels contains path extension list ifnums: (none) path list 7F9D765E3A08, 5 locks, per-destination, flags 0x249 [shble, rif, hwcn, bgp] path 7F9DC3D77E00, share 1/1, type recursive, for IPv4, flags [must-be-lbld] MPLS short path extensions: MOI flags = 0x0 label 17 recursive via 192.168.30.1[IPv4:Default] label 17, fib 7F9DD0427358, 1 terminal fib, v4:Default:192.168.30.0/30 path list 7F9D765E3968, 2 locks, per-destination, flags 0x69 [shble, rif, rcrsv, hwcn] path 7F9D76666788, share 1/1, type recursive, for IPv4, flags [dsnt-src-via, cef-intnl] recursive via 192.168.30.0/30<nh:192.168.30.1>[IPv4:Default], fib 7F9DD0427558, 1 terminal fib, v4:Default:192.168.30.0/30 path list 7F9D765E3AA8, 3 locks, per-destination, flags 0x49 [shble, rif, hwcn] path 7F9DC3D77EA8, share 1/1, type attached nexthop, for IPv4 MPLS short path extensions: MOI flags = 0x0 label implicit-null nexthop 192.168.20.2 GigabitEthernet3, IP adj out of GigabitEthernet3, addr 192.168.20.2 7F9DD052DF90 output chain: label 17 label implicit-null TAG adj out of GigabitEthernet3, addr 192.168.20.2 7F9DD052DDA8 |
The solution is to configure loopbacks, and use them for iBGP sessions establishment between edge routers :
PE1(config)#interface lo0
PE1(config-if)#ip add 1.1.1.1 255.255.255.255
PE1(config)#router ospf 1
PE1(config-router)#network 1.1.1.1 0.0.0.0 area 0
PE1(config)#router bgp 4200000000
PE1(config-router)#no neighbor 192.168.30.1
PE1(config-router)#neighbor 2.2.2.2 remote-as 4200000000
PE1(config-router)#neighbor 2.2.2.2 update-source lo0
PE1(config-router)#address-family vpnv4
PE1(config-router-af)#neighbor 2.2.2.2 activate
PE2(config)#int lo0
PE2(config-if)#ip add 2.2.2.2 255.255.255.255
PE2(config)#router ospf 1
PE2(config-router)#network 2.2.2.2 0.0.0.0 area 0
PE2(config-router)#router bgp 4200000000
PE2(config-router)#no neighbor 192.168.20.1
PE2(config-router)#neighbor 1.1.1.1 remote-as 4200000000
PE2(config-router)#neighbor 1.1.1.1update-source lo0
PE2(config-router)#address-family vpnv4
PE2(config-router-af)#nei 1.1.1.1 activate |
Now, on PE2, next-hop for 172.16.200.0/24 is 2.2.2.2. As router P is not directly connected to 2.2.2.2/32 no implicit-null label is distributed for this prefix but label 17. Notice the output chain on PE1 :
PE1#show ip route vrf CUSTOMER1 Routing Table: CUSTOMER1 snip 172.16.0.0/24 is subnetted, 2 subnets B 172.16.100.0 [20/0] via 192.168.10.1, 1d23h B 172.16.200.0 [200/0] via 2.2.2.2, 00:11:04 192.168.10.0/24 is variably subnetted, 2 subnets, 2 masks C 192.168.10.0/30 is directly connected, GigabitEthernet2 L 192.168.10.2/32 is directly connected, GigabitEthernet2 192.168.40.0/30 is subnetted, 1 subnets B 192.168.40.0 [200/0] via 2.2.2.2, 00:11:04 P#show mpls ldp bindings snip lib entry:
2.2.2.2/32, rev 8 local binding: label: 17 remote binding: lsr: 192.168.30.1:0, label: imp-null remote binding: lsr: 192.168.20.1:0, label: 19 snip PE1#show ip cef vrf CUSTOMER1 172.16.200.0/24 internal 172.16.200.0/24, epoch 0, flags [rlbls], RIB[B], refcnt 6, per-destination sharing sources: RIB feature space: IPRM: 0x00018000 Broker: linked, distributed at 3rd priority LFD: 172.16.200.0/24 0 local labels contains path extension list ifnums: (none) path list 7F9D765E3A08, 5 locks, per-destination, flags 0x249 [shble, rif, hwcn, bgp] path 7F9D76666788, share 1/1, type recursive, for IPv4, flags [must-be-lbld] MPLS short path extensions: MOI flags = 0x0 label 17 recursive via 2.2.2.2[IPv4:Default] label 17, fib 7F9DD0427258, 1 terminal fib, v4:Default:2.2.2.2/32 path list 7F9D765E3AA8, 5 locks, per-destination, flags 0x49 [shble, rif, hwcn] path 7F9DC3D77EA8, share 1/1, type attached nexthop, for IPv4 MPLS short path extensions: MOI flags = 0x0 label 17 nexthop 192.168.20.2 GigabitEthernet3 label 17, IP adj out of GigabitEthernet3, addr 192.168.20.2 7F9DD052DF90 output chain: label 17 label 17 TAG adj out of GigabitEthernet3, addr 192.168.20.2 7F9DD052DDA8 |
And… it works !
CE1#ping 172.16.200.254 source 172.16.100.254
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.16.200.254, timeout is 2 seconds:
Packet sent with a source address of 172.16.100.254
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 8/16/24 ms
CE1#traceroute 172.16.200.254 source 172.16.100.254
Type escape sequence to abort.
Tracing the route to 172.16.200.254
VRF info: (vrf in name/id, vrf out name/id)
1 192.168.10.2 5 msec 2 msec 3 msec
2 192.168.20.2 [MPLS: Labels 17/17 Exp 0] 7 msec 7 msec 13 msec
3 192.168.40.2 [AS 4200000000] [MPLS: Label 17 Exp 0] 7 msec 19 msec 20 msec
4 192.168.40.1 [AS 4200000000] 23 msec * 7 msec
|
Configuration file and Visio diagram
MPLS_basic_L3VPN.zip
|