Skip to content

Test changes for fboss neighbor scale #1037

Open
itskittycisco wants to merge 1 commit intofacebook:mainfrom
itskittycisco:neighbor_scale_changes
Open

Test changes for fboss neighbor scale #1037
itskittycisco wants to merge 1 commit intofacebook:mainfrom
itskittycisco:neighbor_scale_changes

Conversation

@itskittycisco
Copy link
Copy Markdown

@itskittycisco itskittycisco commented Mar 26, 2026

Pre-submission checklist

  • I've ran the linters locally and fixed lint errors related to the files I modified in this PR. You can install the linters by running pip install -r requirements-dev.txt && pre-commit install
  • pre-commit run
    clang-format.............................................................Passed
    shellcheck...........................................(no files to check)Skipped
    shfmt................................................(no files to check)Skipped
    trim trailing whitespace.................................................Passed
    fix end of files.........................................................Passed
    check yaml...........................................(no files to check)Skipped
    check json...........................................(no files to check)Skipped
    check for merge conflicts................................................Passed
    ruff check...........................................(no files to check)Skipped
    ruff format..........................................(no files to check)Skipped

Summary

In the fboss test logs there are 1024 SAI_API_CREATE::create_neighbor_entry calls, all successful (no OOR).
They create all 1024 neighbors with same dst MAC (logged as 02:03:04:05:06:07).

Why no OOR

The SDK’s get_next_hop_host() reuses one nexthop host for all neighbors with the same MAC.
So it allocates one GID per unique MAC (one host nexthop per MAC).
Creating 1024 neighbors all with the same destination MAC uses only one host nexthop (one GID).

The limit is applied to number of host nexthops (GIDs), not number of neighbor entries, so the 1024th create still succeeds and we never see OOR.

With the changes in PR: 512 neighbors were created and programmed in hardware. The 513th and 514th add attempts hit OOR and did not create new entries.

Different MAC per neighbor

SAI: create_neighbor_entry shows DST_MAC increasing by index, e.g.
1::2 → 02:00:00:00:00:00, 1::3 → 02:00:00:00:00:01, 1::4 → 02:00:00:00:00:02, … up to 02:00:00:00:01:ff for the last successful one.
SDK: add_ipv6_host shows mac_addr= (flat=0x20000000000), 0x20000000001, 0x20000000002, … (same pattern: one MAC per IP).
So all created neighbors use unique MACs (one IP host / GID per neighbor).

Results: the 513th (1::204) and 514th (1::205) attempts hit IP_HOSTS OOR; the test sees the OOR via getNeighborTableUpdateFailure() = 1 and passes.

Test Plan

Manually verified the neighbor test -
AgentNeighborResolutionOverFlowTest.neighborResolutionOverFlow

@itskittycisco itskittycisco requested a review from a team as a code owner March 26, 2026 17:06
@meta-cla meta-cla bot added the CLA Signed label Mar 26, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant