This Article explains a situation where a VRF routing table may still be present and remains stuck even after deleting the VRF.
Customer may complain that they have the vrf routing table present in the system even after the vrf has been deleted using netconf provisioning.
<rpc>
<edit-config>
<target>
<candidate/>
</target>
<default-operation>merge</default-operation>
<config-text>
<configuration-text>
groups {
replace:
C3-CUSTOMER-CONFIG {
<...new config excluding config to be deleted...>
}
apply-groups C3-CUSTOMER-CONFIG;
</configuration-text>
</config-text>
</edit-config>
</rpc>
You will see stuck vrf in “show bop summary” as below.
labroot@lab-device> show bgp summary
Threading mode: BGP I/O
Groups: 10 Peers: 26 Down peers: 4
Table Tot Paths Act Paths Suppressed History Damp State Pending
inet.0
16720 16720 0 0 0 0
bgp.l3vpn.0
15892 15892 0 0 0 0
bgp.l3vpn-inet6.0
52 52 0 0 0 0
Peer AS InPkt OutPkt OutQ Flaps Last Up/Dwn State|#Active/Received/Accepted/Damped...
10.0.0.4 2345 0 0 0 0 37 Idle
10.10.10.1 64555 0 0 0 0 35w6d 10:07:50 Idle
169.254.15.218 203665 438828 419637 0 2 18w6d 11:49:54 Establ
INTERNET.inet.0: 0/1/1/0
169.254.21.9 65098 31 33 0 983 2:03:51 Idle
169.254.22.13 65098 32 34 0 975 2:03:37 Idle
192.168.2.1 65515 422647 419628 0 2 18w6d 11:49:51 Establ
VPN-vrf-57152ec2-a00c-41ac-8c7f-8e7a02f17c9f.inet.0: 3/3/3/0
192.168.2.5 65515 422527 419512 0 3 18w6d 10:56:47 Establ
VPN-vfr-57152ec2-a00c-41ac-8c7f-8e7a02f17c9f.inet.0: 0/3/3/0
195.130.0.89 203665 438828 419628 0 2 18w6d 11:49:54 Establ
VPN-vrf-58f68742-c82f-4901-abb8-0fde35d4845c.inet.0: 10/11/11/0
inet.0: 1045/1045/1045/0
----------the below are stuck vrf tables---------------
VPN-vrf-18ca97b4-990b-4120-b3d5-c6f7a76b2fb6.inet.0: 0/0/0/0
VPN-vrf-f820f167-1d80-4c1a-9146-3124fc98a397.inet.0: 0/0/0/0
VPN-vrf-3ef8fcf6-8fa6-4226-99dd-420fcdb6c2bc.inet.0: 0/0/0/0
VPN-vrf-2208f99f-226c-4928-82fd-b54e266ea891.inet.0: 0/0/0/0
Issue is happening because we refresh the reference to the inet table through ted_init(), even though when its clients (MPLS, RSVP) are deactivated through config. This is because after config parsing, ted_init() triggers before the tag and rsvp instance deletion instance are processed.
The TED module instance releases the DELETE flag of vrf.inet.0 table during config processing, So we are not deleting them and it gets leaked.
We can try deleting the MPLS under that instance first and then later deactivating the instance.