[c-nsp] ip vrf autoclassify source - loss of connectivity to hosts

[Aaron Gould]

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