MPLS Layer 3 VPN PE-CE EIGRP

This topic is to discuss the following lesson:

Thanks for adding these! I have gone through all of the other MPLS videos.

You are welcome Anthony!

very good!

hi Rene ,
Correct order should be as below . The same will apply at PE2. When I try with GNS3 , I only found out that. Again, thanks for enlighten us. Your lessons are simple and clear. Especially QOS and mpls lesson you make me very easy. By the way , please teach us Multicast basic as well. :smiley:

PE1(config)#router eigrp 1
PE1(config-router)#address-family ipv4 vrf CUSTOMER 
PE1(config-router)#autonomous-system 1

Hi Jimmy,

Thanks for sharing this, in my example I used IOS 15 but I didn’t realize that the configuration is slightly different on older IOS versions.

Rene

Rene,

Great lesson, if I need to run EBGP between CE and PE then how can we configure?

Thanks

 

Hamood

Hi Hamood,

In this example I used BGP between the PE and CE:

https://networklessons.com/mpls/mpls-layer-3-vpn-configuration/

I will add another example soon with some other BGP PE-CE examples.

Rene

Hi Rene,

Do we have a lesson for EIGRP SoO?

Not yet but I’ll add it soon.

Hi Rene,

So basically you are saying the EIGRP AS number for the VRFs ( not the Global ) on both the PEs and the CEs must be or preferably identical, right ? However the Global EIGRP AS Number for the PEs may or may not be the same and even it could be different from VRF Eigrp AS, Right ?

thx

Ahmad

Hi Ahmad,

The global EIGRP AS number is completely separated from the VRF EIGRP AS numbers. You could use the same or another number, it won’t matter. I would prefer another AS number for global EIGRP just to keep it simple. Just make sure all PE routers use the same global AS number.

Between each PE/CE pair, you have to use the same EIGRP AS number. Like in my example, you can use different EIGRP AS numbers for each PE/CE pair. The only downside is that each CE will then see the routes as EIGRP external. This can be an issue if you have a backdoor link between the two CE sides.

Rene

Hi Rena,
As usual you made it clear ! Thank you for your outstanding support. Ahmad

12 posts were merged into an existing topic: MPLS Layer 3 VPN PE-CE EIGRP

Hi Rene ,

Why the metric for EIGRP is 90 , because this is external.

image

Thx…

Hello Fabio,

Good question, this is something that MPLS VPN does. Here’s an article from Cisco that explains it:

https://www.cisco.com/c/en/us/td/docs/ios/12_0s/feature/guide/seipecec.html

the EIGRP routes in Site 1 are carried through the BGP core network as iBGP routes. The EIGRP routes in “Site 1” and “Site 2” are converted to iBGP routes and EIGRP extended community attributes are appended to the iBGP routes. (See Table 1 for a description of these attributes.) The EIGRP extended community attributes are appended to the EIGRP routes when they are redistributed into BGP as iBGP routes, and VPN routing information is redistributed between the PE routers by multiprotocol BGP.

The routes that originate in “Site 1” travel to the PE router that is connected to the CE router in “Site 2” of the VPN and are then converted back to EIGRP routes using the EIGRP extended community attributes. EIGRP routes are treated the same in “Site 1” and “Site 2.” If the route is internal in “Site 1”, it will be internal in “Site 2”, and if the route is external in “Site 1”, it will be external in “Site 2.” All EIGRP metrics are preserved, and EIGRP metric information, along with the autonomous system, tag, and external data, is carried across the VPN over the BGP core network.

EIGRP routes are converted to iBGP routes on the PE router by appending EIGRP extended community attributes. The PE router uses multiprotocol BGP to distribute the VPN routing information using the these extended community attributes. The BGP routes are converted back to EIGRP routes using the extended community attribute information when the iBGP routes reach the PE router that is connected to the destination CE router.

Hope this helps!

Rene

1 Like

Any luck on the EIGRP SoO lesson yet Rene? :wink:

Cost Communities are actually a huge part of MPLS VPN.

The lessons idea button doesn’t seem to be working btw.

Hello Chris…

Hmm, I’ll let @ReneMolenaar know about the malfunctioning Submit Ideas button… Thanks for the heads up…

Laz

Hi Rene,
Thanks for great explanation. You have explained MPLS in a simple language but I have one debut you used the different AS number for RD & RT and for BGP in all the example of different IGP peeing between Customer and ISP. would this work? May be it should the same.

Hello Abdul,
RD and RT has nothing to do with used BGP AS or EIGRP AS. RD is just a mechanism to make the routes unique by prepending configured RD to the them.

  • IPv4 routes are going to have 64 + 32 = 96 bits when you prepend configured RD to them.
  • IPv6 routes are going to have 64 + 128 = 192 bits when you prepend configured RD to them.

RD itself is 64 bits long and usually first 32 bits are used to be the same as BGP AS of the ISP, following 32 bits usually represent customer number. In this example Rene used RD of 1:1 to make it easy, but it can be any unique number, for example 234:1.

RT can be also different from RD, BGP AS and EIGRP AS. RT is setting BGP extended community string on the route. Whatever RT you use as an extended community string for export you should import on the other end.

Lets make an example. Look at the picture in the lesson. Imagine that each PE router is connecting to two different customers (CUST_111 and CUST_222).

Configuration would look somehow like this.

! PE1 configuration:

vrf definition CUST_111
 rd 234:111
 address-family ipv4
  route-target export 567:11        ! PE2 is going to import 567:11
  route-target import 890:131       ! PE2 is going to export 890:131
!
vrf definition CUST_222
 rd 234:222
 address-family ipv4
  route-target export 987:22
  route-target import 654:232

Now PE1 vrf CUST_111 is exporting routes with tag of 567:11, thus PE2 has to import routes with tag of 567:11 to vrf CUST_111.
PE1 vrf CUST_111 is importing routes with tag of 890:131, thus PE2 vrf CUST_111 has to export routes with tag of 890:131.
PE1 vrf CUST_222 is exporting routes with tag of 987:22, thus PE2 vrf CUST_222 has to import routes with the same tag og 987:22.
PE1 vrf CUST_222 is importing routes with tag of 654:232, thus PE2 vrf CUST_222 has to export routes with the tag of 654:232.

! PE2 configuration:

vrf definition CUST_111
 rd 234:111
 address-family ipv4
  route-target export 890:131
  route-target import 567:11
!
vrf definition CUST_222
 rd 234:222
 address-family ipv4
  route-target export 654:232
  route-target import 987:22

Only RT values are important for importing and exporting routes into VRF.
RD values does not need to match on PE1 and PE2.
VRF names does not need to mach on PE1 and PE2.
RT you are exporting on PE1 must match the number you are importing on PE2 and vice versa.
RT you are importing on PE1 must match the number you are exporting on PE2 and vice versa.

In reality we want to keep this simple, thus for each customer we use same RD, RT export, RT import and VRF names on all PE routers.