MPLS VPN EIGRP between CE and PE

Hi @Network_Eric
first question

R1 PE-1 and R5 CE-1 are both running EIGRP . then i redistributed the EIGRP route into R1 BGP table as VPNv4 route and the route-target export is

Export VPN route-target communities

RT:1000:1

then R4 which is PE-2 when received this ibgp update , R4 need to redistribute that route back into EIGRP again because R4 is also run EIGRP between PE-2 and CE-2.

the question here is ,

why do we need to use the route target import 1000:1 if we`re using redistribute from ibgp back into EIGRP command on PE-2?

why do we need both RT import 1000:1 and redistribute bgp on PE-2 side?

on PE-2 side, what that RT import 1000:1 is trying to solve ?

and what the redistribute bgp under rip vrf-b instance is trying to solve on PE-2?

i know the RT value is responsible for redirect the incoming ibgp update to the correspond routing table . so , why do we need redistribution ?

===================

another question

if EIGRP is running between CE-1 and PE-1 , and static routing between PE-2 and CE-2 , and R1 redistribute the RIP route into BGP and advertise that route as an ibgp route to R4 , on R4 why we don`t need to use redistribution like what we did in the first question?

Hey Major,

I think the issue you have here is about what a route-target actually is, so we’ll try to approach this from that angle.

  • And RD often gets confused with a Route Target. RD is purely used to keep identical routes separated from each other. This allows two different VRFs to have 192.168.1.0/24 and have a method of storing them in the BGP tables and keep them separate. This is completely separate from the Route Target. I know you didn’t ask, but I’ve found for most it’s a sticking point because it uses the same format, etc. In a small lab, this mostly matters for things like load balancing across the MPLS.

  • The Route-target export command says that you want to tell the BGP vpnv4 network that anything wanting to import this should be allowed to. You can have multiple route target exports and imports and multiple VRFs can have the same route target exports and imports.

  • Why this matters. A route target tells BGP which vrfs to import the routes in to. It can be multiple VRFs, or none on a given router. Once it does import them in to a vrf, it is importing them in BGP on that vrf.

  • The reason we do redistribution is because we are not running BGP all through our network, as described, we’re using EIGRP in our network. So, if we want to share routes with our EIGRP neighbors, we will need to redistribute from BGP in to EIGRP.

So, simple explanation. Route target tells BGP VPNV4/6 to export from and import to BGP in a VRF. If we want that route to not be a BGP route, we must use redistribution.

This should cover both of your questions.

3 Likes

@Network_Eric
sir, i`m still confusing
when i configure
ip vrf vrf-a
rd 1000:1
route-target import 1515:1515
here in this configuration, where is the job for bgp ?
what is the relation between bgp and route-target ?

1 Like

The route target is how BGP VPNV4 knows which VRF to import the routes in to. But it does not directly import routes to the routing table, it imports them to a BGP instance running in that VRF, which is why we need to redistribute them in to EIGRP.

1 Like

@Network_Eric
i`m still confused
is that what happened ?

Hey Major,

No, the commands aren’t being copied in to the BGP instance. Let me try to do a step by step breakdown.

  • You have a router with EIGRP, it is neighbors with the PE. It advertises the routes it has to this neighbor.
  • The PE receives the routes as EIGRP routes, this is done in a VRF, Let’s call it VRF-A. What we do is create an instance of BGP in that VRF. This is done with the address-family ipv4 vrf VRF-A. We then redistribute the EIGRP routes in to BGP (under vrf-A). Now the BGP instance in VRF-A knows these routes.
  • We then form a VPNv4 neighbor relationship with another PE router at another site.
  • VPNv4 checks the redistributed routes and learns the Route-target import, export, and Route distinguisher information.
  • The route distinguisher is appended to each of the routes in the VPNv4 routing table so it can have duplicate addresses from different sources, it serves no other purpose. It marks all of the routes with their proper exports (remember, vrfs can have multiple exports and imports and different VRFs can have the same exports and imports, this is why we need to use the RD to keep things separate and not the RT).
  • Then, like any other BGP, if forwards this information on to it’s neighbor (can even have route-reflectors), let’s call this PE2.
  • PE 2 receives the routes and checks the RT exports against the imports of it’s local VRFs, but only ones where there is an instance of BGP running (this is important. You could have 15 VRFs with the matching import, but if there is no address-family ipv4 vrf X for that VRF, it will NOT import it). It finds that is has a matching import for an instance of BGP in VRF-A on PE 2.
  • It then imports these routes in to the BGP instance that is running in VRF-A. For the purposes of VRF-A, this is just like running normal BGP. It will do all the normal administrative distance checks, NWLLA OMNI OLL, etc. But remember, this is the provider router, not the customer router. The customer router is running EIGRP, not BGP.
  • So, in VRF-A on PE 2, we need to have an instance of EIGRP that we make the neighbor of the customer. We then redistribute the BGP routes in to EIGRP so the customer has the routes.

Now keep in mind, routing protocols are designed to work with MPLS BGP VPNv4. This means, that for instance, OSPF treats the MPLS as a super backbone. It has things like Sham-links specifically designed to work with it, and even modifies things like the downward bit for loop prevention. So this works a bit differently than regular redistribution, in that the protocols are designed to intercommunicate. That’s what people mean when they ask if you know MPLS within an enterprise context. You’re unlikely to spend time traffic engineering MPLS, so training won’t go in to detail on that (that’s more of a service provider thing). It’s mostly going to be about how different routing protocols behave when interacting with this MPLS and what options you have to mitigate issues.

That was a bit longer than I intended but hopefully it gives you a good overview of how it behaves. At the end of the day, it’s just BGP neighbors exchanging routes. We use the information provided by VRFs to keep it all straight, and there is information we keep from the redistributed protocols so we can have them interact properly together.

1 Like

@Network_Eric
sir, this is a very very simple and direct question

if PE-2 R4 is configured with this
ip vrf vrf-c
rd 2:2
route-target import 1000:1
and when R1 PE-1 advertise the vpnv4 route with route-target export 1000:1 that route will be received to the PE-2 R4.
the question is, this configuration
route-target import 1000:1 is not configured under
PE-2#) router bgp 14
address-family ipv4 vrf vrf-c
neighbor 6.6.6.6 remote-as 56
neighbor 6.6.6.6 ebgp-multihop 5
neighbor 6.6.6.6 update-source Loopback1
neighbor 6.6.6.6 activate
neighbor 6.6.6.6 send-community
neighbor 6.6.6.6 soo 4444:4444
exit-address-family

when this route is received to R4 PE-2, how could R4 knows this route is belongs to the vrf-c IF the address-family ipv4 vrf vrf-c under the bgp instance is NOT configured with ANY route-targets ?

the route-target is configured under the VRF NOT under the address-family vrf vrf-c instace of the bgp.
how could the bgp instace on R4 use the RT value which is NOT configured under any of the BGP instance at all on R4?

R4#show running-config | section router
router eigrp 1
network 4.0.0.0
network 10.1.34.0 0.0.0.255
eigrp router-id 0.0.0.4
router bgp 14
bgp router-id 4.4.4.4
bgp log-neighbor-changes
neighbor 1.1.1.1 remote-as 14
neighbor 1.1.1.1 update-source Loopback0
!
address-family ipv4
neighbor 1.1.1.1 activate
exit-address-family
!
address-family vpnv4
neighbor 1.1.1.1 activate
neighbor 1.1.1.1 send-community extended
exit-address-family
!
address-family ipv4 vrf vrf-c
neighbor 6.6.6.6 remote-as 56
neighbor 6.6.6.6 ebgp-multihop 5
neighbor 6.6.6.6 update-source Loopback1
neighbor 6.6.6.6 activate
neighbor 6.6.6.6 send-community
neighbor 6.6.6.6 soo 4444:4444
exit-address-family

Hey Major,

Because BGP VPNv4 was explicitly made to function with VRFs. Specifically to handle VRFs in an MPLS network, so not VRF Lite. BGP is fully capable of checking the VRF to pull the information it needs, but it needs to know which VRFs to check. That’s where the address-family ipv4 vrf X comes in, it tells BGP which VRF instances BGP has so it knows which ones to check.

1 Like

@Network_Eric
and what happened after the bgp check the VRF instance ?

It gets the RD and route-target information from the VRF

@Network_Eric


ok that is what happened here exactly like what i said . why you said this is not correct ?

Hey Major,

No, they aren’t copied in to there, and they also aren’t under the EIGRP domain. They are stored in the VRF, and the VRF is read by the other protocols.

1 Like