Scenario 1:
Due to partner misconfiguration, Gateway handoff interface will not sent the arp request for the customer peer ip during the arp flood from customer peer ip.
The behavior might cause the peer device delayed to learn the next hop gateway arp address.
Scenario 2:
After partner performing gateway upgrade or gateway redeployment for existing connected PE device , gateway unable to learn the nexthop PE arp address
VMware VeloCloud SD-WAN
Scenario 1:
In a corner case scenario such as arp flood for unknown ip received by gateway handoff interface from customer peer ip, gateway handoff interface will not sent the arp request for the customer peer ip.
As arp flood initiated by peer ip , gateway will keep refreshing the arp table for the peer ip.
Lab :
Gateway Handoff IP - 101.101.101.11
PE Peer IP - 101.101.101.10
ARP requests were sent from gateway to PE IP every 3 minutes. (i.e. No inbound ARP flood from PE to VCG)
Tcpdump output on gateway handoff interface - Working state :
We could see inbound ARP flooding from PE to VCG (101.101.101.12 doesn't exist on that vcg) and no ARP request sent by VCG to PE.
Tcpdump output on gateway handoff interface - Issue state :
Scenario 2 :
After partner upgrading or redeploying the partner gateway , partner gateway unable to learn the nexthop arp address as the peer device might have sent the arp request to the older partner gateway handoff interface mac address.
This shall be noticed when we verify the tcpdump on partner gateway handoff interface towards peer ip. The output shall be displayed as gateway sending the arp request to the peer but gateway didn't receive arp reply or arp request from the peer.
1) Partner need to check the PE device why it were sending arp flood (101.101.101.12) to the gateway where gateway doesn't own ip 101.101.101.12.
2) Partner need to check why PE device weren't sending arp request or arp reply to the gateway handoff interface.