Ignorer les commandes du ruban
Passer au contenu principal
SharePoint

Networking

août 01
Basic MPLS L3VPN configuration on IOS XE

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 routers

Routers 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

Commentaires

Aucun commentaire sur ce billet.