Tag Archives: troubleshooting

MARS: Zone product or package version does not match

I’ve been having problems getting my Cisco MARS Local and Global controllers to synchronise their topologies. This error message vexed me for a few days, but thankfully Cisco’s TAC solved it for me.

If you read Ciscos troubleshooting guides they will tell you to check that the MARS Local & Global controllers are running the same version, and to check that the SSL certificates are copied/pasted correctly.

If after checking the above Cisco recommendations and the additional basics ( network connectivity / ntp / timezones etc) check that both MARS boxes are running and have downloaded the same version of IPS signatures; under Admin -> IPS Signature Dynamic Update Settings -> Update Now.

It fixed the problem for me!

Strange ASA ARP Replying Behavior

I’ve been implementing a few Cisco ASA’s recently, and I blogged about this strange behavior; well I came across another one yesterday.

Take a look at this debug arp….

CiscoASA# debug arp
debug arp  enabled at level 1
CiscoASA#
CiscoASA# arp-set: added arp outside 192.168.1.122 001e.7000.1234 and updating NPs at 4301321940
arp-set: added arp inside 192.168.1.61 001a.7100.1234 and updating NPs at 4301321940


arp-in: request at outside from 192.168.1.125 001a.3000.1234 for 192.168.1.120 001e.7a51.1234
arp-in: rqst for me from 192.168.1.125 for 192.168.1.120, on outside
arp-set: added arp outside 192.168.1.125 001a.3000.1234 and updating NPs at 4301326660
arp-in: generating reply from 192.168.1.120 001e.7a51.1234 to 192.168.1.125 001a.3000.1234


arp-in: request at outside from 192.168.1.125 001a.3000.1234 for 192.168.1.73 001e.7a51.1234
arp-in: rqst for me from 192.168.1.125 for 192.168.1.73, on outside
arp-set: added arp outside 192.168.1.125 001a.3000.1234 and updating NPs at 4301326660
arp-in: generating reply from 192.168.1.73 001e.7a51.1234 to 192.168.1.125 001a.3000.1234
arp-in: request at outside from 192.168.1.125 001a.3000.1234 for 192.168.1.69 001e.7a51.1234


arp-in: rqst for me from 192.168.1.125 for 192.168.1.69, on outside
arp-set: added arp outside 192.168.1.125 001a.3000.1234 and updating NPs at 4301326660
arp-in: generating reply from 192.168.1.69 001e.7a51.1234 to 192.168.1.125 001a.3000.1234


arp-in: request at outside from 192.168.1.125 001a.3000.1234 for 192.168.1.123 001e.7a51.1234
arp-in: rqst for me from 192.168.1.125 for 192.168.1.123, on outside
arp-set: added arp outside 192.168.1.125 001a.3000.1234 and updating NPs at 4301326660
arp-in: generating reply from 192.168.1.123 001e.7a51.1234 to 192.168.1.125 001a.3000.1234
arp-in: response at outside from 192.168.1.125 001a.3000.1234 for 192.168.1.125 ffff.ffff.ffff
arp-in: updating gratuitous ARP 192.168.1.125 - 001a.3000.1234
arp-set: added arp outside 192.168.1.125 001a.3000.1234 and updating NPs at 4301326660
CiscoASA#

The firewall is replying to arp requests even though both the source & destination of the traffic are on the same (outside) interface, now I haven’t manged to work out why the firewall was doing this, but I did find a fix on the cisco forums.

sysopt noproxyarp outside

Names, IPs & MAC’s have been changed to protect the innocent.
:cool: