Forum Discussion
About ping from BIG-IP
Hello,
I use BIG-IP's LTM on the intranet. It is a question when I ping from BIG-IP.
Internet side ⇔ Firewall⇔ L3switch (2 units redundant with HSRP) ⇔ BIGIP (LTM) ⇔ Server
With the above configuration, I was pinging to confirm the normality when replacing the old L3SW with the new L3SW.
While continuing to ping (with routedomain) from BIGIP to FW (default gateway), we did the following:
① Delete VLAN of old L3SW (standby machine → active machine)
② Clear MAC address table with FW
③ Put VLAN in new L3SW (active machine → standby machine)
The movement of ping at this time was unexpected.
In ①, ping stops when VLAN of standby machine is deleted.
After executing ②, a number of "host unreachable" pings are returned from the firewall, and then "host unreachable" comes back from the external Self IP of BIG-IP.
③ After that, ping starts to fly normally.
If I thought ping started again when I put the VLAN in both machines. . .
Why does it behave like this?
- Hannes_Rapp
Nimbostratus
Are you pinging from the Management interface or TMM/data interface? If from the Management interface, it's unlikely to be a BigIP problem. Nevertheless, as a first step, try to set a MAC masquerade address for your BigIP traffic-group. This is normally only needed for Active-Active BigIP clusters but it doesn't hurt with Active-Standby. A problem with
updates and old ARP caches is a possibility. You may need to perform a similar procedure with your L3 switches to make the failover event more reliable.Gratuitous ARP
- Akiko_344053
Nimbostratus
Thank you for the fast reply
Since the source address is not specified, I think that it is transmitting from the interface address of the same segment.
What is "A problem with Gratuitous ARP updates and old ARP caches"? Could you tell me more specifically?
- Hannes_Rapp
Nimbostratus
If a new unit in a cluster comes active it must update all network participants, forcing them to update ARP cache tables immediately. A problem here is my main suspect since you said failovers were involved. In particular, it looks as if either Standby BigIP or Standby L3 Switch was assumed an owner of floating IP addresses by the network. Re-Adding a deleted VLAN to a Standby L3 switch would not restore connectivity otherwise.
- Akiko_344053
Nimbostratus
Is it okay for the Standby L3 switch to have floating IP addresses so that you know the way to the Firewall and ping is returned?
Please let me organize it again.
① Delete VLAN of old L3SW (Clear with Standby machine → Clear with Active machine)
② Clear MAC address table with FW
③ Put VLAN in new L3SW (Add to Active machine → Add to Standby machine)
※ L3 switch uses vPC function on Nexus (maybe I forgot to say something quite important)
Describing in detail the ping of this situation.
① When VLAN is deleted on Standby machine → ping stop (Time out)
② After that, "From [Firewall] Destination Host Unreachable" is repeated several times from the firewall, then "[BIG-IP _ external_SelfIP] destination host unreachable" continues. (In some cases, after returning from BIG-IP, several pings are returned from the firewall.)
③ After that, the ping returns normally from the Firewall.
I am concerned about the behavior of ping after ②.
I am sorry for lack of information. Does the first explanation and situation change?
- Hannes_Rapp_162
Nacreous
Are you pinging from the Management interface or TMM/data interface? If from the Management interface, it's unlikely to be a BigIP problem. Nevertheless, as a first step, try to set a MAC masquerade address for your BigIP traffic-group. This is normally only needed for Active-Active BigIP clusters but it doesn't hurt with Active-Standby. A problem with
updates and old ARP caches is a possibility. You may need to perform a similar procedure with your L3 switches to make the failover event more reliable.Gratuitous ARP
- Akiko_344053
Nimbostratus
Thank you for the fast reply
Since the source address is not specified, I think that it is transmitting from the interface address of the same segment.
What is "A problem with Gratuitous ARP updates and old ARP caches"? Could you tell me more specifically?
- Hannes_Rapp_162
Nacreous
If a new unit in a cluster comes active it must update all network participants, forcing them to update ARP cache tables immediately. A problem here is my main suspect since you said failovers were involved. In particular, it looks as if either Standby BigIP or Standby L3 Switch was assumed an owner of floating IP addresses by the network. Re-Adding a deleted VLAN to a Standby L3 switch would not restore connectivity otherwise.
- Akiko_344053
Nimbostratus
Is it okay for the Standby L3 switch to have floating IP addresses so that you know the way to the Firewall and ping is returned?
Please let me organize it again.
① Delete VLAN of old L3SW (Clear with Standby machine → Clear with Active machine)
② Clear MAC address table with FW
③ Put VLAN in new L3SW (Add to Active machine → Add to Standby machine)
※ L3 switch uses vPC function on Nexus (maybe I forgot to say something quite important)
Describing in detail the ping of this situation.
① When VLAN is deleted on Standby machine → ping stop (Time out)
② After that, "From [Firewall] Destination Host Unreachable" is repeated several times from the firewall, then "[BIG-IP _ external_SelfIP] destination host unreachable" continues. (In some cases, after returning from BIG-IP, several pings are returned from the firewall.)
③ After that, the ping returns normally from the Firewall.
I am concerned about the behavior of ping after ②.
I am sorry for lack of information. Does the first explanation and situation change?
Recent Discussions
Related Content
* Getting Started on DevCentral
* Community Guidelines
* Community Terms of Use / EULA
* Community Ranking Explained
* Community Resources
* Contact the DevCentral Team
* Update MFA on account.f5.com