[action] [PR:23970] [arp_update]Resolve neighbors from config_db

[mssonicbld]

What changed

• This change is being implemented in arp_update script to ensure neighbor resolution works properly after firmware upgrades and system repaves.
• This change was originally developed and validated on 202205, 202211 images ([master] Resolve neighbors from config_db #15006), and is now being backported to 202411 and newer versions to maintain consistent neighbor resolution across images of all sonic versions.
• The arp_update script now defines kernel neighbors (KERNEIGH4 and KERNEIGH6) based on different device subtype to properly handle DualToR.

Why I did it

After firmware upgrades/repaves, devices will experience neighbor resolution issues because kernel neighbor table can be empty/missing entries, and hence traffic going to certain neighbors will drop.

What is being fixed

• In Non-DualToRs, FAILED/INCOMPLETE neighbors are excluded because this status represents connection issues.
• In DualToRs, servers are connected to two ToR switches but only one path is active at a time. When a neighbor is reachable through the peer ToR switch, the local ToR switch will have FAILED/INCOMPLETE neighbor entries, which is an expected behavior.
  • The original code excluded FAILED/INCOMPLETE neighbors for all device types, which cause issues on DualToR devices: Neighbors that should be reachable via the peer switch but are FAILED in kernel wouldn't be detected as mismatches.
  • With the fix (post_upgrade), the standby ToR will include FAILED/INCOMPLETE neighbors in mismatch checking and will be included in synchronization processing since the script can detect the mismatch between kernel FAILED state and APPL_DB entries.

Example

# Immediately after system repave on DualToR standby switch
$ sonic-db-cli APPL_DB keys NEIGH_TABLE:Vlan100:*
NEIGH_TABLE:Vlan100:192.168.1.100
NEIGH_TABLE:Vlan100:192.168.1.101
NEIGH_TABLE:Vlan100:192.168.1.102

# Kernel starts with empty/failed entries
$ ip -4 neigh show | grep Vlan100
192.168.1.100 dev Vlan100 FAILED
192.168.1.101 dev Vlan100 FAILED
192.168.1.102 dev Vlan100 FAILED

# With enhanced arp_update script:
# 1. Includes FAILED entries in mismatch detection
# 2. Compares with APPL_DB entries
# 3. Triggers appropriate resolution (ping/tunnel route setup)
# 4. Results in proper neighbor state restoration

# Final state after arp_update processing:
$ ip -4 neigh show | grep Vlan100
192.168.1.100 dev Vlan100 lladdr 00:00:00:00:00:00 PERMANENT  # Zero MAC for peer-reachable
192.168.1.101 dev Vlan100 lladdr aa:bb:cc:dd:ee:ff REACHABLE  # Direct reachable
192.168.1.102 dev Vlan100 lladdr 00:00:00:00:00:00 PERMANENT  # Zero MAC for peer-reachable

Work item tracking

• Microsoft ADO (number only):

How to verify it

Which release branch to backport (provide reason below if selected)

• 202205
• 202211
• 202305
• 202311
• 202405
• 202411
• 202505

Tested branch (Please provide the tested image version)

Description for the changelog

Link to config_db schema for YANG module changes

A picture of a cute animal (not mandatory but encouraged)

[mssonicbld]

Original PR: #23970

[mssonicbld]

/azp run Azure.sonic-buildimage

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).