MPLS Layer 3 VPN PE-CE EIGRP
In this lesson we’ll take a look how we can use EIGRP as the PE-CE routing protocol for MPLS L3 VPN. If you already have seen my lesson for PE-CE RIP then you can skip to the “EIGRP between PE and CE routers” section as the configuration of the service provider network is exactly the same.
Above we have 5 routers. CE and CE2 belong to the customer who wants to run EIGRP between their sites. The service provider has two PE routers and one P router in the middle.
Configuration IGP and LDP
Let’s prepare the service provider routers. We need an IGP (OSPF) and LDP on the PE1, PE2 and P router.
PE1(config)#interface loopback 0
PE1(config-if)#ip address 2.2.2.2 255.255.255.255
P(config)#interface loopback 0
P(config-if)#ip address 3.3.3.3 255.255.255.255
PE2(config)#interface loopback 0
PE2(config-if)#ip address 4.4.4.4 255.255.255.255
Now we can configure OSPF:
PE1(config)#router ospf 1
PE1(config-router)#network 192.168.23.0 0.0.0.255 area 0
PE1(config-router)#network 2.2.2.2 0.0.0.0 area 0
PE1(config-router)#mpls ldp autoconfig
P(config)#router ospf 1
P(config-router)#network 192.168.23.0 0.0.0.255 area 0
P(config-router)#network 192.168.34.0 0.0.0.255 area 0
P(config-router)#network 3.3.3.3 0.0.0.0 area 0
P(config-router)#mpls ldp autoconfig
PE2(config)#router ospf 1
PE2(config-router)#network 192.168.34.0 0.0.0.255 area 0
PE2(config-router)#network 4.4.4.4 0.0.0.0 area 0
PE2(config-router)#mpls ldp autoconfig
This takes care of IGP and LDP. Make sure you have LDP neighbors before we continue:
P#show mpls ldp neighbor | include Peer
Peer LDP Ident: 2.2.2.2:0; Local LDP Ident 3.3.3.3:0
Peer LDP Ident: 4.4.4.4:0; Local LDP Ident 3.3.3.3:0
Our P router in the middle has two neighbors so this is looking good. Just in case, let’s verify if there is connectivity between PE1 and PE2:
PE1#traceroute 4.4.4.4 source loopback 0
Type escape sequence to abort.
Tracing the route to 4.4.4.4
VRF info: (vrf in name/id, vrf out name/id)
1 192.168.23.3 [MPLS: Label 17 Exp 0] 0 msec 0 msec 4 msec
2 192.168.34.4 0 msec 0 msec *
The PE routers are able to reach each others loopback interfaces and we are using label switching.
VRFs on the PE Routers
Our next step in the configuration is to configure the VRFs. I will use a VRF called “CUSTOMER”, the route distinguisher and route-target will be 1:1.
PE1 & PE2
(config)#ip vrf CUSTOMER
(config-vrf)#rd 1:1
(config-vrf)#route-target both 1:1
Don’t forget to add the interfaces facing the customer routers into the VRF:
PE1(config)#interface FastEthernet 0/0
PE1(config-if)#ip vrf forwarding CUSTOMER
PE1(config-if)#ip address 192.168.12.2 255.255.255.0
PE2(config)#interface FastEthernet 0/1
PE2(config-if)#ip vrf forwarding CUSTOMER
PE2(config-if)#ip address 192.168.45.4 255.255.255.0
Let’s check if the PE routers are able to ping the CE routers from the VRF:
PE1#ping vrf CUSTOMER 192.168.12.1
PE2#ping vrf CUSTOMER 192.168.45.5
IBGP between PE1 and PE2
Our two PE routers require iBGP to exchange the VPNv4 routes. Let’s configure this:
PE1(config)#router bgp 234
PE1(config-router)#neighbor 4.4.4.4 remote-as 234
PE1(config-router)#neighbor 4.4.4.4 update-source loopback 0
PE1(config-router)#address-family vpnv4
PE1(config-router-af)#neighbor 4.4.4.4 activate
PE2(config)#router bgp 234
PE2(config-router)#neighbor 2.2.2.2 remote-as 234
PE2(config-router)#neighbor 2.2.2.2 update-source loopback 0
PE2(config-router)#address-family vpnv4
PE2(config-router-af)#neighbor 2.2.2.2 activate
we should check if our routers have formed an IBGP neighbor adjacency:
PE1#show bgp vpnv4 unicast all summary
BGP router identifier 2.2.2.2, local AS number 234
BGP table version is 1, main routing table version 1
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
4.4.4.4 4 234 5 6 1 0 0 00:01:03 0
EIGRP between PE and CE routers
CE1(config)#interface loopback 0
CE1(config-if)#ip address 1.1.1.1 255.255.255.255
CE1(config)#router eigrp 1
CE1(config-router)#no auto-summary
CE1(config-router)#network 192.168.12.0
CE1(config-router)#network 1.1.1.1 0.0.0.0
CE2(config)#interface loopback 0
CE2(config-if)#ip address 5.5.5.5 255.255.255.255
CE2(config)#router eigrp 1
CE2(config-router)#no auto-summary
CE2(config-router)#network 192.168.45.0
CE2(config-router)#network 5.5.5.5 0.0.0.0
The EIGRP configuration above is pretty straight forward. On both routers, I used AS number 1. At the end of this lesson I’ll show you what happens if you pick a different AS number for two sites.
Let’s configure the PE routers:
PE1(config)#router eigrp 1
PE1(config-router)#address-family ipv4 vrf CUSTOMER autonomous-system 1
PE1(config-router-af)#no auto-summary
PE1(config-router-af)#network 192.168.12.0
PE2(config)#router eigrp 1
PE2(config-router)#address-family ipv4 vrf CUSTOMER autonomous-system 1
PE2(config-router-af)#no auto-summary
PE2(config-router-af)#network 192.168.45.0
When you configure the PE router, you can pick any AS number for the “global” EIGRP process. When you configure the address-family, that’s where you specify the AS number for the VRF. If you forget this, EIGRP will not run since the router has no idea what AS number to pick for the VRF.
Let’s check if the PE routers have learned anything from the CE routers:
PE1#show ip route vrf CUSTOMER eigrp
1.0.0.0/32 is subnetted, 1 subnets
D 1.1.1.1 [90/156160] via 192.168.12.1, 00:01:33, FastEthernet0/0
PE2#show ip route vrf CUSTOMER eigrp
5.0.0.0/32 is subnetted, 1 subnets
D 5.5.5.5 [90/156160] via 192.168.45.5, 00:00:34, FastEthernet0/1
Great, it’s in the routing table for the customer’s VRF. Let’s redistribute these into BGP:
PE1(config)#router bgp 234
PE1(config-router)#address-family ipv4 vrf CUSTOMER
PE1(config-router-af)#redistribute eigrp 1
PE2(config)#router bgp 234
PE2(config-router)#address-family ipv4 vrf CUSTOMER
PE2(config-router-af)#redistribute eigrp 1
Let’s make sure these routes have become VPNv4 routes:
PE1#show bgp vpnv4 unicast vrf CUSTOMER
BGP table version is 7, local router ID is 2.2.2.2
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale, m multipath, b backup-path, x best-external, f RT-Filter
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path
Route Distinguisher: 1:1 (default for vrf CUSTOMER)
*> 1.1.1.1/32 192.168.12.1 156160 32768 ?
*>i5.5.5.5/32 4.4.4.4 156160 100 0 ?
*> 192.168.12.0 0.0.0.0 0 32768 ?
*>i192.168.45.0 4.4.4.4 0 100 0 ?
PE2#show bgp vpnv4 unicast vrf CUSTOMER
BGP table version is 7, local router ID is 4.4.4.4
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale, m multipath, b backup-path, x best-external, f RT-Filter
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path
Route Distinguisher: 1:1 (default for vrf CUSTOMER)
*>i1.1.1.1/32 2.2.2.2 156160 100 0 ?
*> 5.5.5.5/32 192.168.45.5 156160 32768 ?
*>i192.168.12.0 2.2.2.2 0 100 0 ?
*> 192.168.45.0 0.0.0.0 0 32768 ?
Excellent, above we have our VPNv4 routes. Take a close look at the MED value of 156160. This is the EIGRP metric that has been copied to BGP’s MED attribute.
The last thing to do is redistributing these VPNv4 routes back into EIGRP:
PE1(config)#router eigrp 1
PE1(config-router)#address-family ipv4 vrf CUSTOMER
PE1(config-router-af)#redistribute bgp 234 ?
metric Metric for redistributed routes
route-map Route map reference
<cr>
EIGRP doesn’t have an option to transparently redistribute the metric from BGP into EIGRP, we still have to use a seed metric. The cool thing however is that the router will ignore whatever metric you specify here. It will use the metric from the BGP MED attribute:
PE1(config-router-af)#redistribute bgp 234 metric 1 1 1 1 1
Let’s do the same on PE2:
PE2(config)#router eigrp 1
PE2(config-router)#address-family ipv4 vrf CUSTOMER
PE2(config-router-af)#redistribute bgp 234 metric 1 1 1 1 1
Verification
I already showed you how to verify some of the things during the configuration but now we will test end-to-end reachability. First we will check the routing tables of CE1 and CE2:
CE1#show ip route eigrp
5.0.0.0/32 is subnetted, 1 subnets
D 5.5.5.5 [90/158720] via 192.168.12.2, 00:03:50, FastEthernet0/0
D 192.168.45.0/24 [90/30720] via 192.168.12.2, 00:03:50, FastEthernet0/0
CE2#show ip route eigrp
1.0.0.0/32 is subnetted, 1 subnets
D 1.1.1.1 [90/158720] via 192.168.45.4, 00:04:08, FastEthernet0/0
D 192.168.12.0/24 [90/30720] via 192.168.45.4, 00:04:08, FastEthernet0/0
This is looking good. Both CE routers have learned each others loopback interfaces. In the EIGRP topology table you can see what metric they learned from the PE routers:
CE1#show ip eigrp topology 5.5.5.5/32
EIGRP-IPv4 Topology Entry for AS(1)/ID(1.1.1.1) for 5.5.5.5/32
State is Passive, Query origin flag is 1, 1 Successor(s), FD is 158720
Descriptor Blocks:
192.168.12.2 (FastEthernet0/0), from 192.168.12.2, Send flag is 0x0
Composite metric is (158720/156160), route is Internal
Vector metric:
Minimum bandwidth is 100000 Kbit
Total delay is 5200 microseconds
Reliability is 255/255
Load is 1/255
Minimum MTU is 1500
Hop count is 2
Originating router is 5.5.5.5
Above you can see the advertised distance (156160) which we also found in the BGP MED attribute. Let’s do a quick ping, see if we can reach the other side:
CE1#ping 5.5.5.5 source loopback 0
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 5.5.5.5, timeout is 2 seconds:
Packet sent with a source address of 1.1.1.1
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/3/4 ms
No problems there. Let’s do a trace so you can see the transport and VPN labels:
CE1#traceroute 5.5.5.5 source loopback 0
Type escape sequence to abort.
Tracing the route to 5.5.5.5
VRF info: (vrf in name/id, vrf out name/id)
1 192.168.12.2 0 msec 0 msec 4 msec
2 192.168.23.3 [MPLS: Labels 17/19 Exp 0] 0 msec 0 msec 4 msec
3 192.168.45.4 [MPLS: Label 19 Exp 0] 0 msec 0 msec 4 msec
4 192.168.45.5 0 msec 0 msec *
Here you can see the transport label (17) and the VPN label (19). Everything is working as it should, there’s one last thing that I would like to show you. What happens when we use a different AS number between one of the PE-CE routers? Let’s try this on PE2 and CE2, I’ll use AS 2 there:
PE2(config)#router eigrp 1
PE2(config-router)#no address-family ipv4 vrf CUSTOMER
PE2(config-router)#address-family ipv4 vrf CUSTOMER autonomous-system 2
PE2(config-router-af)#no auto-summary
PE2(config-router-af)#network 192.168.45.0
PE2(config-router)#address-family ipv4 vrf CUSTOMER autonomous-system 2
PE2(config-router-af)#redistribute bgp 234 metric 1 1 1 1 1
PE2(config)#router bgp 234
PE2(config-router)#address-family ipv4 vrf CUSTOMER
PE2(config-router-af)#redistribute eigrp 2
CE2(config)#no router eigrp 1
CE2(config)#router eigrp 2
CE2(config-router)#no auto-summary
CE2(config-router)#network 192.168.45.0
CE2(config-router)#network 5.5.5.5 0.0.0.0
The configuration is exactly the same but we changed the EIGRP AS number on PE2 and CE2. Take a look at the routing tables now:
CE1#show ip route eigrp | incl 5.5.5.5
D EX 5.5.5.5 [170/2560002816] via 192.168.12.2, 00:02:13, FastEthernet0/0
CE2#show ip route eigrp | incl 1.1.1.1
D EX 1.1.1.1 [170/2560002816] via 192.168.45.4, 00:02:44, FastEthernet0/0
There’s two things that have changed now:
-
We have EIGRP external routes, this makes sense since we are using two different AS numbers.
-
The metric is the actual seed metric that I used, the router no longer uses the information in the BGP MED attribute.
This doesn’t affect connectivity in our example but it might be a problem if you use a backup link. For example, let’s say our customer is using the MPLS link as their primary connection but they also have a GRE tunnel over the Internet between CE1 / CE2 where they use EIGRP. In our first example, with the internal EIGRP routes (AD 90) and low metric we have a good chance the routers will prefer the MPLS link over the backup GRE tunnel.
With the different AS numbers, we now have EIGRP external routes (AD 170) and a large (seed) metric. You have to make sure that the MPLS link will still be preferred over the GRE backup tunnel…
Conclusion
Running EIGRP as the PE-CE routing protocol isn’t much different than RIP, the main difference is understanding that the seed metric is ignored when you redistribute back into EIGRP but that you do have to specify something. You have also seen how using different EIGRP AS numbers affects the routing tables.
