Friday, January 20, 2012


I hope to explain to you, curious reader, the essence behind the technique to configure a RFC 2547 BGP/MPLS VPN.

First, we create "loopback" interfaces (Lo1000 used here) on all three routers used in this example.

Next, we enable MPLS forwarding on the interfaces that participate in the forwarding path. Please note that R5 is acting as the "P" router, and R1 and R2 are "PE/CE" routers. The VRF instance "blue" represents the CE network.

R6 interfaces is shown here as an example:

interface Serial1/1:0
bandwidth 64
ip address
encapsulation ppp
mpls ip
no fair-queue

Next, we enable IGP in the "P" core. Here we use OSPF and place the interfaces in Area 0. Notice the special LDP commands included under OSPF to facilitate interaction with MPLS LDP.

router ospf 1
mpls ldp sync
mpls ldp autoconfig
mpls ldp autoconfig area 0

network area 0
network area 0

Now, we can verify MPLS LDP operation with the following commands:

show mpls forwarding table

Local Outgoing Prefix Bytes tag Outgoing Next Hop
tag tag or VC or Tunnel Id switched interface
25 Untagged 4872 Fa0/0
26 Untagged 12615289 Fa0/0
27 Pop tag 5800 Se1/1:0 point2point
28 Pop tag 10771 Fa0/1
30 Untagged 0 Se1/1:0 point2point
31 Pop tag 0 Fa0/1
32 Pop tag 9321 Se1/1:0 point2point

We now proceed to configure BGP with multi-protocol extensions as follows:

router bgp 65001
no synchronization
bgp log-neighbor-changes
neighbor remote-as 65001
neighbor update-source Loopback1000
no auto-summary
address-family vpnv4
neighbor activate
neighbor send-community extended
address-family ipv4 vrf blue
redistribute connected
no synchronization

Let's check that BGP has established a neighbor relationship and is receiving the routes in the VRF (blue):

R1#show ip bgp vpnv4 vrf blue
BGP table version is 5, local router ID is
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete

Network Next Hop Metric LocPrf Weight Path
Route Distinguisher: 100:10 (default for vrf blue)
*> 0 32768 ?
*>i172.16.106.0/24 0 100 0 ?

Note the RT extended community:

R1#show ip bgp vpnv4 vrf blue
BGP routing table entry for 100:10:, version 5
Paths: (1 available, best #1, table blue)
Not advertised to any peer
Local (metric 1564) from (
Origin incomplete, metric 0, localpref 100, valid, internal, best
Extended Community: RT:100:10
mpls labels in/out nolabel/17

Note the MPLS label imposition - there are two labels imposed:

R1#show mpls forwarding-table vrf blue detail
Local Outgoing Prefix Bytes Label Outgoing Next Hop
Label Label or VC or Tunnel Id Switched interface
None 17[V] \
0 Gi0/0
MAC/Encaps=14/22, MRU=1496, Label Stack{32 17}
00011FBE98010013C32C2CD88847 0002000000011000
VPN route: blue
No output feature configured

Finally, we can verify that we have connectivity:

R1#ping vrf blue
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to, timeout is 2 seconds:
Success rate is 100 percent (5/5), round-trip min/avg/max = 8/9/12 ms
1340399: Jan 20 10:01:36: MPLS les: Gi0/0: rx: Len 118 Stack {41 0 254} - ipv4 data
1340400: Jan 20 10:01:36: ICMP: echo reply rcvd, src, dst

You may wonder why R1 is receiving label 41. We need to examine R6 for an explanation:

R6#show mpls forwarding-table vrf blue detail
Local Outgoing Prefix Bytes tag Outgoing Next Hop
tag tag or VC or Tunnel Id switched interface
None 41 0 Se1/1:0 point2point
MAC/Encaps=4/12, MRU=1496, Tag Stack{28 41}
FF030281 0001C00000029000
No output feature configured
Per-packet load-sharing

No comments:

Post a Comment