Forum Discussion

smp_86112's avatar
Icon for Cirrostratus rankCirrostratus
Oct 05, 2010

"stuck" mac address

I'm troubleshooting NTP communication which gets processed by a wildcard, Forwarding (IP) VS. The source is in the internal LTM (10.2.0) VLAN, and the NTP server is in the external. I run a trace on the internal vlan and when the request comes in, the source has the right mac address. However when the LTM sends the response back out the internal VLAN, the LTM inserts the wrong dest mac address. The mac that it has used to be assigned to the node, but it's not used any longer. So it appears like the old mac address is "stuck" in the arp table. However I can't find any reference to the bad mac anywhere - all i can find is the correct mac. There are no static arp entries, and I tried removing the phantom entry from the arp table which had no effect. The rest of the traffic to and from this node works just fine.



Can you think of any way I can remove this "stuck" mac, or think of anywhere else to check that might be hanging onto this mac?

2 Replies

  • That's an odd one. A 'b load' would probably fix it if you don't find out why it's still there.



  • Hey buddy, nice to hear from you again. I thought you had left.



    I can close the loop on this one, from a troubleshooting perspective at least. I opened a case, and I was asked to spit out the entire connection table to validate the accuracy of the AUTOLASTHOP MAC address. Instead of the entire thing, I just focused in on the individual connection and sure enough, the LASTHOP address was incorrect. I had to use the the "all" switch at the end of the "b conn" command to view the LASTHOP value. Then I just deleted the connection from the table, and that fixed it.




    This AutoLastHop thing was new to me. I'm still circling around with F5 trying to figure out why it didn't have the right address.