ACE module: clearing an entry in the FIB table

[MMazuhelli_2]

Hello,

I need to clear an entry that appears in the FIB table of a context of our ACE module:

# sh ip fib | inc 6.34

x.y.6.34/32     N/A                 DROP   V [0xc00]

(I masked the 2 first numbers of the IP address with x.y)

This entry appeared after I tried to define a VServer with IP address x.y.6.134 but entered x.y.6.34 my mistake. I corrected the mistake but all traffic to x.y.6.34 started being dropped, and, unlucky as I am, x.y.6.34 is the address of another existing VServer (defined in another context).

I temporarily fixed the problem by hard-coding a route for x.y.6.34. It's now working but the DROP entry is still present in the FIB table:

# sh ip fib | inc 6.34

x.y.6.34/32     N/A                 DROP   EV [0xc40]

x.y.6.34/32     vlan2121              17   S [0xc]

I don't want to leave the x.y.6.34/32 route forever.

Is "clear rtcache" the right command to clear the FIB table and get rid of the "DROP" entry?

Since there are no parameters to this command, the whole table will be cleared.

Is it dangerous to enter this command on a production box?

Version info: ACE 2 module in a Cat6500 running frimware version A2(3.5).

Thanks for your help,

Marc.

[Kanwaljeet Singh]

Hi Marc,

I did a quick search here internally and it seems that in cases like these before the only workaround was to reload the ACE module. Also, do check if this entry has been replicated in FT peer as well or not. If yes, then reload standby first and then the active so that you have proper failover during the problem.

If you would like it to investigate further or to reproduce the problem, i would suggest opening a TAC case for the same.

Regards,

Kanwal

[MMazuhelli_2]

Hi Kanwal,

Thank you for your answer. I thought that maybe "clear rtcache" would do the trick...

I checked and this entry was indeed replicated to the FT peer. If we reload the failover module first and wait until it's back in "standby hot" state before rebooting the active module, will the table entry be replicated from the active to the standby again? If it's the case we would have to reload both modules at the same time, causing an interruption   ;-(

Marc.

[Kanwaljeet Singh]

Hi Marc,

I haven't tested this myself but in previous instances it was suggested to reload the standby first and then the active one. Try to reload standby and check if the entry is there or not. If not then i guess we are good to reload the active. If not, let me know and i will see if there's anything else we can do to avoid interruption.

Regards,

Kanwal