VRF and VLAN trunking

[mluo]

Catalyst9500(10.190.5.6) can ping Nexus9000(10.190.5.2) but cannot ping the router(10.190.5.1).  The IP addresses are in the same subnet(/24).  They are configured in the same VLAN(5).  The only catch is on the Nexus9000, the VLAN5 is in MGMT VRF instead of the default VRF.  How can I make the 

[MHM Cisco World]

I will run lab and test this 

MHM

[Flavio Miranda]

Hi @mluo 

Seems to me this is a normal bahavior when using MGMT VRF

https://www.cisco.com/c/en/us/td/docs/switches/datacenter/nexus9000/sw/6-x/unicast/configuration/guide/l3_cli_nxos/l3_virtual.html

Management VRF

• The management VRF is for management purposes only.
• Only the mgmt 0 interface can be in the management VRF.
• The mgmt 0 interface cannot be assigned to another VRF.
• No routing protocols can run in the management VRF (static only).

[mluo]

@Flavio Miranda Thank you for your reply.  But

1. The management VRF is different from MGMT VRF. They are two different VRFs.
2. The IP address is NOT configured in the mgmt 0 interface.  It is configured in the VLAN5 interface.

Nexus9000# sh vrf
VRF-Name VRF-ID State Reason
MGMT 4 Up --
default 1 Up --
management 2 Up --

[SamuelGLN]

Hi @mluo 

As you use no ip redirects inside vlan 5 on nexus9000, the behavior is correct.

You can find more information on the follow link: https://www.cisco.com/c/en/us/support/docs/ip/routing-information-protocol-rip/13714-43.html

Best regards
******* If This Helps, Please Rate *******

[mluo]

@SamuelGLN  Thank you for your reply.  I had thought about that and tested with "ip redirect".  Same behavior.  Based on the link you posted, "ICMP redirect messages are used by routers to notify the hosts on the data link that a better route is available for a particular destination".  This does not apply to my case.  In my case, the source and destination are in the same subnet and same VLAN.  There is no better route available to the destination.  And the source didn't try to reach the destination via a sub-optimal route.

In the ARP table below, 10.190.5.6 is the source (Cat9500).  10.190.5.2 and 10.190.5.3 are the Nexus9000s.  The Nexus IPs are in a VRF.  10.190.5.1 is the router(destination).  I have another network similar to this but the Nexus IPs are in the default VRF.  In that case, the Cat9500 can ping the router with no problem.

Catalyst9500#sh ip arp
Protocol Address Age (min) Hardware Addr Type Interface
Internet 10.190.5.1 0 0050.5601.1c2f ARPA Vlan5
Internet 10.190.5.2 1 006b.f1e1.0d35 ARPA Vlan5
Internet 10.190.5.3 1 006b.f1e1.0cb9 ARPA Vlan5
Internet 10.190.5.6 - 8c44.a5cc.ecbf ARPA Vlan5
Catalyst9500#

[MHM Cisco World]

can I see the router config ?

MHM

[mluo]

@MHM Cisco World The router is actually a PaloAlto virtual firewall running on VMware ESXi.  I'll try to get it from the firewall team.  The Nexus in the same VLAN has no problem pinging the router.  What could be the potential problem? Thanks!

[MHM Cisco World]

I run lab sure I use VRF name other than mgmt to be simple for me for troubleshooting
all three Device in same VLAN 
so the frame never routing and ARP must pass from 9500 to Palo 
I think the issue is in Palo it have ACL to deny some IP

MHM

[mluo]

Thank you all for your help!  It turned out to be a duplicated IP address.  Another host is using the same IP address 10.190.5.6 as the Catalyst9500.  the Palo Alto virtual firewall's ARP table has the MAC address of the host instead of the Catalyst9500.  My teammate shut down the host and clear the firewall ARP table.  Now it's working.

[MHM Cisco World]

thanks for update us 

have a nice summer 

MHM