EIGRP and VRF Issue

[ALI12]

Hi Everyone,

I’ve set up a lab in GNS3 using the EIGRP protocol, as shown in the attached diagram.
Everything was working fine until I created a VRF interface on R2.

Now, I’m facing some connectivity issues:

-Loopback 1 can ping and reach Loopback 2 but cannot reach Loopback 3.
-Loopback 3 cannot reach Loopback 1 or Loopback 2 but can reach the VRF interface.
-Additionally, on R2, interface e1/0 cannot reach interface e1/1.

I’ve attached the configuration files for your reference. Any insights or advice would be greatly appreciated.

Thanks in advance!

[Peter Paluch]

Hello Ali,

I believe that the behavior after configuring the VRF on R2 is expected.

Every VRF is an independent routed world, and for the sake of our discussion, the global routing table can also be seen as a VRF on its own. Now, two distinct VRFs cannot communicate, just like two distinct VLANs on a switch cannot communicate. That's why it is sometimes said that VRFs turn a single physical router into several virtual routers, just like VLANs turn a single physical switch into several virtual ones.

In your configuration on R2, e1/0 is associated with the global routing table while e1/1 is associated with the VRF "testvrf". Because of this, each of this interfaces lives in its own independent routed universe - each one uses its own routing table (e1/0 uses the global routing table, e1/1 uses the routing table associated with the testvrf VRF), there are really two independent EIGRP processes running. With the VRF as deployed on R2, you have split your network into two logically disconnected universes.

And because the goal of VRFs is to create separate routed universes, your network behaves exactly as expected - those two VRFs (the global one and the testvrf one) do not communicate.

If you wanted these two to communicate, you could configure route leaking whereby one VRF imports or exports routes from another one - but if you wanted to do that on R2 in this topology, it would in fact obviate the need for the VRFs in the first place.

If you're just starting to play around with VRFs, I can see how this can be confusing. Please feel welcome to ask further!

Best regards,
Peter

[ALI12]

Thank you @Peter Paluch  for the detailed explanation and valuable information.

You’re absolutely right, I’m still in the early stages of working with VRFs, and although I’ve read quite a bit on the topic, I still occasionally confuse VRFs with EIGRP.

Additionally, I tried to export on R2 with the following commands, but the issue still exists:

R2(config-vrf)#route-target export 200:2
R2(config-vrf)#route-target import 200:2

Thanks again for your help.

Best regards,

[Peter Paluch]

Hello Ali,

You are heartily welcome.

Just to reinforce the topic, VRFs and routing protocols are not the same thing. A VRF is a separate copy of the routing table along with the interfaces that are associated with that routing table. This means several things:

• The directly connected network of an interface appears only in the VRF that the interface is associated with
• Any routing protocol configured to run over an interface populates only the VRF that the interface is associated with
• A packet received on an interface is routed based on the contents of the VRF that the interface is associated with

Your configuration of route-target commands won't help here. Route targets are used in MPLS Layer3 VPN scenarios by BGP, to sort out networks of different customers and their locations into proper VRFs. However, if you are only now starting to get acquainted with VRFs, then MPLS L3 VPNs are too complex for now and you don't need to bother yourself too much with it just yet.

The gotcha here is that it is in fact quite complicated, configuration-wise, to have R2 pass packets between two VRFs, the global and the testvrf. You would either need to set up a set of static routes for each VRF pointing into the other one (which has all the disadvantages of static routing), or you would need to start BGP on R2 and do extra configuration with route maps and route filtering to have BGP locally leak the routes from the testvrf VRF into the global routing table and vice versa. Once again, if you are not yet fluent with route maps and/or redistribution, the configuration would most likely be confusing to you. I'm not trying to withhold any information from you but judging by the fact that you are only getting used to working with VRF, I would rather see you first learn their rules, and only then start breaking them : )

The very important thing to understand here is this: Your configuration on R2 is valid as far as IOS commands are concerned, but it does not make sense. You have placed two interfaces on R2 into different VRFs. It is natural, then, that they no longer communicate because that is what we have VRFs for - to turn R2 into a series of independent virtual routers. That is exactly what you have achieved. If you want the two VRFs on R2 to continue fully communicating with each other, you're saying in essence: "I implemented Layer3 isolation - but I don't really want it." In that case, you didn't need to use the VRFs at all.

I understand that you are learning about VRFs and you most probably wanted to see what happens if you implement them, and you wanted to find out how to make two VRFs talk to each other on the same router. Well, the trick with multiple VRFs on the same router is that it's in fact quite tricky to get them talk to each other, because that is not what you would usually do. It is possible, but the tools for it may - for now - be somewhat too complex. You would need BGP (this is an IOS specialty; not that you would be having multiple routers speaking BGP but if you want to leak routes between VRFs on the same router, it is internally done through BGP's code), route maps, and ideally prefix lists to have the leaking controller. I'm happy to share an example configuration if you'd like. But remember - this is not how you would use VRFs in real life.

Of course, if you put both e1/0 and e1/1 on R2 into the same VRF, say testvrf, then things would start of course working again because you would again have both these interfaces work within the same routed universe.

Please feel welcome to ask further!

Best regards,
Peter

[ALI12]

Thank you @Peter Paluch  for the detailed explanation.

You are right; in this case, using VRFs is unnecessary and adds unnecessary complexity and effort.

Thanks again for your guidance.

[MHM Cisco World]

I hope run lab for you after 2-3 hrs' I will share with you step to solve this issue.

MHM

[ALI12]

@MHM Cisco World 

Thank you, Prof.

I’m looking forward to your feedback and appreciate your continued assistance.

[MHM Cisco World]

this lab for you and other see this post 

step is simple 
1-we run BGP for route leaking between GLOBAL and VRF-RED 

2- we redistribute eigrp (100 vrf-red) and eigrp (110 global) into bgp under the address family 

3- we redistribute bgp into both eigrp <<- here what control the redistribute is the import and export map 

MHM

R2#show run
R2#show running-config
Building configuration...

Current configuration : 2480 bytes
!
version 15.2
service timestamps debug datetime msec
service timestamps log datetime msec
!
hostname R2
!
boot-start-marker
boot-end-marker
!
!
!
no aaa new-model
no ip icmp rate-limit unreachable
ip cef
!
ip vrf red
rd 1:1
import ipv4 unicast map glo-vrf-red
export ipv4 unicast map vrf-red-glo
!
!
!
!
!
!
no ip domain lookup
no ipv6 cef
!
!
multilink bundle-name authenticated
!
!
!
!
!
!
!
!
!
ip tcp synwait-time 5
!
!
!
!
!
!
!
!
!
!
!
!
interface Loopback0
ip vrf forwarding red
ip address 2.2.2.2 255.255.255.255
!
interface FastEthernet0/0
ip vrf forwarding red
ip address 100.0.0.2 255.255.255.0
duplex full
!
interface FastEthernet1/0
no ip address
shutdown
speed auto
duplex auto
!
interface FastEthernet1/1
ip address 110.0.0.2 255.255.255.0
speed auto
duplex auto
!
interface FastEthernet2/0
no ip address
shutdown
speed auto
duplex auto
!
interface FastEthernet2/1
no ip address
shutdown
speed auto
duplex auto
!
interface FastEthernet3/0
no ip address
shutdown
speed auto
duplex auto
!
interface FastEthernet3/1
no ip address
shutdown
speed auto
duplex auto
!
!
router eigrp MHM
!
address-family ipv4 unicast autonomous-system 110
!
topology base
redistribute bgp 100 metric 100000 1000 255 1 1500
exit-af-topology
network 110.0.0.0 0.0.0.255
exit-address-family
!
address-family ipv4 unicast vrf red autonomous-system 100
!
topology base
redistribute bgp 100 metric 100000 1000 255 1 1500
exit-af-topology
network 2.2.2.2 0.0.0.0
network 100.0.0.0 0.0.0.255
exit-address-family
!
router bgp 100
bgp log-neighbor-changes
!
address-family ipv4
redistribute connected
redistribute eigrp 110
exit-address-family
!
address-family ipv4 vrf red
redistribute connected
redistribute eigrp 100
exit-address-family
!
ip forward-protocol nd
!
!
no ip http server
no ip http secure-server
!
!
ip prefix-list 2.2.2.2 seq 5 permit 2.2.2.2/32
ip prefix-list 2.2.2.2 seq 10 permit 100.0.0.0/24
ip prefix-list 2.2.2.2 seq 15 permit 1.1.1.1/32
!
ip prefix-list 3.3.3.3 seq 5 permit 3.3.3.3/32
ip prefix-list 3.3.3.3 seq 10 permit 110.0.0.0/24
!
route-map glo-vrf-red permit 10
match ip address prefix-list 3.3.3.3
!
route-map vrf-red-glo permit 10
match ip address prefix-list 2.2.2.2
!
!
!
control-plane
!
!
line con 0
exec-timeout 0 0
privilege level 15
logging synchronous
stopbits 1
line aux 0
exec-timeout 0 0
privilege level 15
logging synchronous
stopbits 1
line vty 0 4
login
!
!
end

[ALI12]

Thank you @MHM Cisco World  for sharing this.

Initially, I thought this scenario would be straightforward and could be managed with just one or two commands.

However, after reviewing the configuration, I realize it's more complex and will require additional effort.
Based on this, I now agree with Peter that it's best to avoid using VRFs with dynamic routing protocols.

I created this lab to test the configuration before applying it to eight real routers, some of which have VRF configurations. I now think the best solution is to avoid using any interfaces inside VRFs and create new interfaces outside of VRFs to make the task seamless and easier.

Thanks again for your usual support

[MHM Cisco World]

You are so welcome 

Yes VRF is complex and it used 

For mpls mp-bgp

Or 

Virtual network for security

Or 

Dmvpn tunnels ivrf + fvrf 

MHM

[MHM Cisco World]

Run lab by yourself and keep it as reference maybe in feature your need it.

Goodluck friend 

MHM

[ALI12]

Sure, I will do it.

Thank you, Prof @MHM Cisco World , for your usual assistance.

[Peter Paluch]

Hello Ali,

Only one humble comment. You wrote:

Based on this, I now agree with Peter that it's best to avoid using VRFs with dynamic routing protocols.

Oh, I did not say anything of the sort : ) VRFs and dynamic routing protocols go hand in hand fabulously. This is how the whole world is using them - they are being populated by routing protocols just like normal routing tables.

The complexity in your case comes from the requirement to leak routes between two VRFs on the same router. It is possible, but it gets complex because it goes against the goal of having the VRFs in the first place. Note this has nothing to do, in principle, with routing protocols. The fact that we need BGP to do this is in fact an ugly hack... pardon, an ugly property of Cisco IOS / IOS XE in particular : )

I just wanted to make sure we do not have a misunderstanding. VRFs and routing protocols are a match made in heaven, there's no discussion about that. Just the local route leaking is a pain in the rear end : )

Best regards,
Peter

[ALI12]

@Peter Paluch 
I apologize for not expressing my intention clearly.

I was specifically referring to my own case, not in general.

You are absolutely right.