On occasion I'm seeing loss of connectivity to test hosts that are part of a subnet belonging to a vrf autoclassify subnet
Below I show the interface and the vrf autoclassify commands. 10.145.255.0/24 is source classified into vrf "three" I couple times over the last few weeks I've seen loss of connectivity to a host. I looked closer today and saw 2 hosts with this problem, and noticed that the cef vrf three entry for those 2 broken hosts, were missing from the cef vrf three table. What might be causing this? Has anyone had a problem like this at all, or more particularly with using vrf autoclassify feature? I tried to recreate the problem by simple deleting the cef entry. this causes loss of connectivity to the host, but 10-25 seconds later, the entry is back into the cef vrf table and connectivity is good again. However, during the time of the actual observed problem, connectivity was only restored when I removed dhcp config from the host and reapplied it, which I'm guessing generated enough of traffic or certain traffic type, to cause cef table repopulate and connectivity was good again. interface Bundle1 vrf forwarding one ip vrf autoclassify source ip dhcp relay information trusted ip address 111.222.111.225 255.255.255.248 secondary ip address 10.13.254.1 255.255.255.0 secondary ip address 10.255.2.1 255.255.255.0 secondary ip address 10.145.255.1 255.255.255.0 secondary vrf three . cmts0.test#sh ip cef vrf three | in 10.145. 10.145.254.1/32 receive Loopback100 10.145.255.0/24 attached Bundle1 10.145.255.0/32 receive Bundle1 10.145.255.1/32 receive Bundle1 10.145.255.2/32 attached Bundle1 10.145.255.220/32 attached Bundle1 10.145.255.255/32 receive Bundle1 cmts0.test#cle arp vrf three 10.145.255.2 cmts0.test#cle arp vrf three 10.145.255.2 cmts0.test#cle arp vrf three 10.145.255.2 cmts0.test#cle arp vrf three 10.145.255.2 cmts0.test#cle arp vrf three 10.145.255.2 cmts0.test#cle arp vrf three 10.145.255.2 cmts0.test#cle arp vrf three 10.145.255.2 cmts0.test#cle arp vrf three 10.145.255.2 cmts0.test#cle arp vrf three 10.145.255.2 cmts0.test#cle arp vrf three 10.145.255.2 cmts0.test#sh ip cef vrf three | in 10.145. 10.145.254.1/32 receive Loopback100 10.145.255.0/24 attached Bundle1 10.145.255.0/32 receive Bundle1 10.145.255.1/32 receive Bundle1 10.145.255.220/32 attached Bundle1 10.145.255.255/32 receive Bundle1 (about 10-25 seconds later, 10.145.244.2 is back in cef table and is once again pingable) cmts0.test#sh ip cef vrf three | in 10.145. 10.145.254.1/32 receive Loopback100 10.145.255.0/24 attached Bundle1 10.145.255.0/32 receive Bundle1 10.145.255.1/32 receive Bundle1 10.145.255.2/32 attached Bundle1 10.145.255.220/32 attached Bundle1 10.145.255.255/32 receive Bundle1 - Aaron _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
