Hi,
So I'm configuring a new FTD box to replace a legacy ASA 5510 (that still feels strange...calling ASA5510's "legacy" - but I guess I'm showing my age).
Anyway, the plan is to set up the FTD box in a side by side config on a spare IP in our public range, test everything we can and then have a cut-over period where we move all the NAT's across and update internal routes etc to start using the new FTD box.
However, I have hit a strange issue straight away, where I am unable to ping the outside interface of the new FTD from anywhere and also unable to access the newly configured AnyConnect SSL portal on the new FTD.
Cue lots of head scratching, pointing fingers at the ISP, who were pointing fingers at Cisco TAC (admittedly I did raise TAC case with the AnyConnect team - so not blaming them at all, we were all going round in circles).
After some time we decided to strip things back and look at the arp details on the FTD to check it was seeing the correct MAC addresses and we came across the following....
Outside xx.xx.xx.225 5475.d0e3.dc66
Outside xx.xx.xx.252 e4d3.f179.3380
Outside xx.xx.xx.253 a493.4cbc.4880
Outside xx.xx.xx.254 5475.d0e3.dc66
The first arp is the legacy ASA (IP .225)
Second arp is one of the pair of ISP upstream routers (IP .252)
Third arp is the other ISP upstream router (ip .253)
Last arp is the VRRP presented by the ISP upstream routers (IP .254) - which is of course the default outside route also!
so...hopefully you will have spotted that the VRRP IP for some strange reason is showing as the MAC of the ASA, not the actual VRRP mac (which of course should be along the lines of 00:00:5E:00:xx:xx)
Why is the ASA doing this (gratuitous arp???) and how do I stop it? - it certainly has locally defined NATs or interfaces using that IP but its obviously arp-ing that IP and causing me a headache!
Any help/advise greatly appreciated :)
Thanks
Paul
