09-24-2009 10:06 PM - edited 02-21-2020 03:41 AM
Hi,
Im having trouble with my standby pix. After sometime the outside interface becomes insaccessible but my inside interface is still accessible. By clearing my arp table, the outside interface can now be accessible. Has anyone of you what might cause this problem? Ive already check if i have a duplicate ip, but i cant find any duplicate ip.
Here is logging of my device whenever this problems occurs..
405001: Received ARP response collision from x.x.x.x/0000.0c07.xxxx on interface outside
405001: Received ARP response collision from x.x.x.x/0000.0c07.xxxx on interface outside
405001: Received ARP response collision from x.x.x.x/0000.0c07.xxxx on interface outside
405001: Received ARP response collision from x.x.x.x/000d.xxxx.xxxx on interface outside
405001: Received ARP response collision from x.x.x.x/0000.0c07.xxxx on interface outside
405001: Received ARP response collision from x.x.x.x/000d.xxxx.xxxx on interface outside
106021: Deny icmp reverse path check from y.y.y.y to x.x.x.x on interface outside
106021: Deny icmp reverse path check from y.y.y.y to z.z.z.z on interface outside
405001: Received ARP response collision from x.x.x.x/0000.0c07.xxxx on interface outside
405001: Received ARP response collision from x.x.x.x/000d.xxxx.xxxx on interface outside
106021: Deny icmp reverse path check from y.y.y.y to x.x.x.x on interface outside
106021: Deny icmp reverse path check from y.y.y.y to z.z.z.z on interface outside
405001: Received ARP response collision from x.x.x.x/0000.0c07.xxxx on interface outside
405001: Received ARP response collision from x.x.x.x/000d.xxxx.xxxx on interface outside
hope you could help me.
Thanks
09-24-2009 11:23 PM
Did you try finding out who is holding the MAC addr of the reported collision party ?
It should be some devices in the same subnet as the outside interface IP.
09-24-2009 11:30 PM
hi,
the mac addres of the reported collision are from two valid sources with different ip. the outside interface seems to be confused with this. Is this the cause? Is it possible to statically bind the mac address of the standby pix to its ip add?
Thanks
09-25-2009 12:08 AM
The problem is not with the standby PIX unable to bind to its own mac address.
If you have a ARP collision, when other devices in the subnet performs ARP on the relevant IP, the incorrect party will sometimes reply faster than the PIX, which will result in packets being redirected to another device instead. Thus causing non responsiveness.
When you say "Cannot access", where are you accessing the Outside Interface from ?
Trace the path inwards until you reach the device just before reaching the PIX. You can then fix a static ARP there so that it doesn't do dynamic ARP for that particular IP.
Hope this helps.
09-25-2009 12:29 AM
Hi,
im accessing it from the outside. From my scenario, when i'm not able to access the outside interface of the standby, what i'll do is access it through its inside. This is also true when im on the inside network.
Any suggestions to what might have been the cause? And what is the workaround for this? Could it be that the outside physical port is problematic? But i can't see any errors on the said port..
hope you can help
09-25-2009 07:12 AM
Perhaps you can provide a network diagram with the PIX and the outside network (preferably with IP Addresses), i can explain to you more in detail.
The only way to workaround is to set a static ARP for the standby PIX outside interface on the next hop device.
09-27-2009 03:36 PM
Hi,
My primary and standby pix is connected to a single switch. 2 routers in hsrp are also connected via this switch. All outside interfaces are on the same vlan. The next hop of the pix is the router. Lets say that my outside ip for standby pix is 1.1.1.3 and the ip for primary pix is 1.1.1.2. For the router lets say that its outside is 1.1.1.4 and 1.1.1.5 with a VIP of 1.1.1.1.
should i set a static arp on the router for the standby pix?
thanks.
09-28-2009 07:43 AM
Yes, configure static ARP on both the HSRP routers for the standby pix (1.1.1.3).
That should prevent anymore ARP hijacks.
09-30-2009 11:41 PM
isnt it that when i statically assign the mac of the standby pix to the router's, i will have a problem when there comes a time that a failover occurs?
the issue that i am having is that the mac of primary is being used by the VIP of the router. Is this because i am having a collision?
Any other suggestions?
Hope you could help.
09-30-2009 11:42 PM
is there a way from i which i can map the mac of the standby to its ip?
10-01-2009 12:03 AM
>>isnt it that when i statically assign the mac of the standby pix to the router's, i will have a problem when there comes a time that a failover occurs?
If this is the Physical IP Address of the standby PIX, it shouldn't matter because ultimately it belongs to the standby PIX.
>>the issue that i am having is that the mac of primary is being used by the VIP of the router. Is this because i am having a collision?
The VIP will always match the physical MAC of the Active PIX under normal condition.
---------------
What im saying here is, IF the Physical IP Address of the standby is experiencing IP conflicts, you can just configure a static ARP in the routers to workaround the problem.
This has nothing got to do with the VIP (unless your VIP is also experiencing IP conflicts as well, then its a different issue)
10-01-2009 12:49 AM
Hi,
>>The VIP will always match the physical MAC of the Active PIX under normal condition.
do you have any documentation for this?if so why?
>>What im saying here is, IF the Physical IP Address of the standby is experiencing IP conflicts, you can just configure a static ARP in the routers to workaround the problem.
do you mean the failover ip? is the failover ip the physical ip of the standby pix? I Have a cable-based failover?
Thanks
10-01-2009 12:59 AM
why is it that i dont have a value for the arp tble counter? is this because of the collision or bug?
Stateful Failover Logical Update Statistics
Link : stateful
Stateful Obj xmit xerr rcv rerr
General 234413 0 98283969 0
sys cmd 234413 0 234413 0
up time 0 0 2 0
xlate 0 0 4672 0
tcp conn 0 0 98044436 0
udp conn 0 0 446 0
ARP tbl 0 0 0 0
RIP Tbl 0 0 0 0
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide