0

As an experiment I've created a non-default VRF, directly cabled between an L3 port on the default VRF and an L3 port on the non-default VRF, and am trying to ping between them. Neither interface can resolve the other.

The setup is:

  • eth1/34 has IP 10.10.1.211/24 on VRF1
  • eth1/6 has IP 10.10.1.111/24 on default VRF
  • eth1/6 is connected to eth1/34 by a cat 5 cable

When I try to ping between them, each reports the other is unreachable. With a monitor session active on the connection, the problem appears to be unanswered ARP requests in each direction:

switch1# ping 10.10.1.111 source-interface ethernet 1/34
PING 10.10.1.111 (10.10.1.111): 56 data bytes
36 bytes from 10.10.1.211: Destination Host Unreachable
Request 0 timed out
36 bytes from 10.10.1.211: Destination Host Unreachable
Request 1 timed out
36 bytes from 10.10.1.211: Destination Host Unreachable
Request 2 timed out
36 bytes from 10.10.1.211: Destination Host Unreachable
Request 3 timed out
36 bytes from 10.10.1.211: Destination Host Unreachable
Request 4 timed out


switch1# ping 10.10.1.211 source-interface ethernet 1/6
PING 10.10.1.211 (10.10.1.211): 56 data bytes
36 bytes from 10.10.1.111: Destination Host Unreachable
Request 0 timed out
36 bytes from 10.10.1.111: Destination Host Unreachable
Request 1 timed out
36 bytes from 10.10.1.111: Destination Host Unreachable
Request 2 timed out
36 bytes from 10.10.1.111: Destination Host Unreachable
Request 3 timed out
36 bytes from 10.10.1.111: Destination Host Unreachable
Request 4 timed out

From the monitor session:

17:53:04.716375 ARP, Request who-has 10.10.1.111 (Broadcast) tell 10.10.1.211, length 46
17:53:06.721173 ARP, Request who-has 10.10.1.111 (Broadcast) tell 10.10.1.211, length 46
17:53:10.724456 ARP, Request who-has 10.10.1.111 (Broadcast) tell 10.10.1.211, length 46
17:53:18.727720 ARP, Request who-has 10.10.1.111 (Broadcast) tell 10.10.1.211, length 46
...
17:54:35.932830 ARP, Request who-has 10.10.1.211 (Broadcast) tell 10.10.1.111, length 46
17:54:37.934559 ARP, Request who-has 10.10.1.211 (Broadcast) tell 10.10.1.111, length 46
17:54:41.937869 ARP, Request who-has 10.10.1.211 (Broadcast) tell 10.10.1.111, length 46

I know that this is an unusual setup, but is there actually something I'm missing that would stop this setup from working? What I think are the relevant parts of the configuration are below.

switch1(config-)# show running-config int ethernet 1/34

!Command: show running-config interface Ethernet1/34
!Running configuration last done at: Thu Jan  4 17:33:19 2024
!Time: Thu Jan  4 17:33:22 2024

version 9.3(9) Bios:version 5.5.0 

interface Ethernet1/34
  description "TO 6"
  no switchport
  speed 1000
  vrf member VRF1
  ip address 10.10.1.211/24

switch1(config)# show running-config int ethernet 1/6

!Command: show running-config interface Ethernet1/6
!Running configuration last done at: Thu Jan  4 17:33:19 2024
!Time: Thu Jan  4 17:34:03 2024

version 9.3(9) Bios:version 5.5.0 

interface Ethernet1/6
  description "TO 34"
  no switchport
  speed 1000
  ip address 10.10.1.111/24

switch1(config)# show ip route
IP Route Table for VRF "default"
'*' denotes best ucast next-hop
'**' denotes best mcast next-hop
'[x/y]' denotes [preference/metric]
'%<string>' in via output denotes VRF <string>

10.10.1.0/24, ubest/mbest: 1/0, attached
    *via 10.10.1.111, Eth1/6, [0/0], 00:06:36, direct
10.10.1.111/32, ubest/mbest: 1/0, attached
    *via 10.10.1.111, Eth1/6, [0/0], 00:06:36, local

switch1(config)# show ip route vrf VRF1
IP Route Table for VRF "VRF1"
'*' denotes best ucast next-hop
'**' denotes best mcast next-hop
'[x/y]' denotes [preference/metric]
'%<string>' in via output denotes VRF <string>

10.10.1.0/24, ubest/mbest: 1/0, attached
    *via 10.10.1.211, Eth1/34, [0/0], 00:06:49, direct
10.10.1.211/32, ubest/mbest: 1/0, attached
    *via 10.10.1.211, Eth1/34, [0/0], 00:06:49, local
1
  • Please edit your question to include the entire configuration (remove sensitive info). Also, what IOS version are you running?
    – Ron Trunk
    Commented Jan 4 at 19:02

1 Answer 1

-1

The intended function of VRF is to create a separate Virtual Router and Forwarding instance inside the hardware and local software router instance. This prevents communication between each VRF and any other VRF or the global route table (locally connected interfaces, etc.) without additional configuration.

You appear to be trying to use the same IP network (10.10.1.0/24) in 2 different VRF instances. This is fine if you know what you are doing, but it prevents you from communicating between those IP addresses in the 2 VRF instances without significant changes to the network design. Ideally, IP addresses should be unique in your network unless the networks are isolated or use Network Address Translation or other methods to masquerade or modify source and destination network addresses.

You could either change one network to be a different /24 network (10.10.2.0/24) or make both networks smaller (10.10.1.0/25 and 10.10.1.128/25 for example).

Once you have the IP address overlap issue sorted, you need to implement some kind of configuration to 'leak', export, or learn IP routes between the VRF instances so they learn of each others' IP networks. That can be done by multiple methods.

There is more information here:

https://learningnetwork.cisco.com/s/article/introduction-to-vrfs-part-1-ipv4-only-vrfs-x

and

https://www.cisco.com/c/en/us/support/docs/ip/ip-routing/200158-Configure-Route-Leaking-between-Global-a.html

and

https://ipwithease.com/route-leaking-between-vrf-and-global-routing-table/

3
  • They literally connected default to VRF1 through a physical cable. This should function as if it were two physical devices. I've done this many times with switches (VLANs), and the only thing necessary is to disable CDP/LLDP so it can't tell it's plugged into itself.
    – Ricky
    Commented Jan 5 at 0:24
  • Still doing some troubleshooting but it looks like the issue might be resolved by just enabling proxy-arp on the relevant interfaces
    – Kevin
    Commented Jan 5 at 18:43
  • Ah, I assumed you connected the interfaces to each other as a troubleshooting step but if that is your intended design then yeah, I guess you can do that to avoid managing the need to import route config between the VRFs. Commented Jan 6 at 1:08

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.