Enhanced Security Measures in Place: To ensure a safer experience, we’ve implemented additional, temporary security measures for all users.
08-08-2018 06:01 AM
We experienced a loss of routing of two virtual server and their arp to IP information had to be added to a virtual router to get it to route. Any ideas how this could occur?
08-08-2018 06:30 AM - edited 08-08-2018 06:32 AM
Certain servers/services require static ARP entires to maintain their entry in the ARP cache, however the use of static ARP is declining. In my experiance load-balancers, application delivery controllers, and generally anything that uses a lot of VIP entries are canidates for this sort of configuration.
As for how it happened; the ARP cache cleared the mapping for those two servers. Creating a static mapping simply creates a static ARP table entry so that whatever IP you entered will always map to that MAC address.
08-08-2018 06:35 AM
What I am trying to do is rule out the PA as what is causing the issue. I would say by adding it to a virtual router on the PA is just doing routing that another part of the network should be doing and the PA is not the cause
08-08-2018 06:45 AM
Just to verify; when you say you added it into the VR, you really mean interface configuration right? The VR doesn't hold the static ARP entries, this would be something you configure on the interface configuration.
As for what actually caused the issue it could have been the PA, but it really wouldn't have been the PAs fault if you weren't told it needed a static ARP entry. Usually if you are configuring a static ARP entry on the firewall, it would also be configured on your core switches. Everything needs to have the same ARP entry otherwise things will break.
So on my network for example we need a static ARP entry for our OWA VIP, without it our users can't access OWA. So lets say that VIP has a MAC address of 00:11:22:33:44:55 and it maps to 10.191.1.111; that means I have a static ARP entry on my Core switches along with the interface on the PA so that the traffic can actually route correctly. If I take the static ARP off either my Cores or the PA I can't route to that VIP anymore.
Now as to your particular issue I'd say that this is more likely the following options:
1) Interface/Routing changes were made on the PA and this static ARP entry wasn't entered for some reason. This is the fault of the PA, but likely due to not knowing it needed the ARP entry.
2) If that isn't the case then this is a new setup or they changed the setup in some way. Fully the fault of the server/service admin for not knowing that a static ARP entry was going to be required.
That's really your only two options that should take place. If a service was working with a dynamic ARP entry and no change has taken place then you wouldn't have run into the issue.
08-08-2018 09:29 AM
Well I found out the new guy left some important vlans off a switch and that was the issue, I had asked him this stuff before but he assured me it was all correct on his side. So I guess added the arp and IP information to the the interface sorry not the virtual router fixed the issue. Our internatl communication between people is greatly lacking here and contributes to our issues. Thanks bpry great response
08-08-2018 09:31 AM
Internal Comms is something that we've been trying to work on here, but we're pretty siloed as far as who handles what aspects. Always fun when someone else causes issues 😉
Click Accept as Solution to acknowledge that the answer to your question has been provided.
The button appears next to the replies on topics you’ve started. The member who gave the solution and all future visitors to this topic will appreciate it!
These simple actions take just seconds of your time, but go a long way in showing appreciation for community members and the LIVEcommunity as a whole!
The LIVEcommunity thanks you for your participation!
