Repository navigation
Cover port-channel generation - #2569
Merged
Merged
Conversation
berendt
force-pushed
the
sonic-e2e-v2-portchannel
branch
from
August 5, 2026 15:10
18a6299 to
6513399
Compare
ideaship
force-pushed
the
sonic-e2e-v2-portchannel
branch
from
August 5, 2026 19:51
6513399 to
11756b8
Compare
berendt
force-pushed
the
sonic-e2e-v2-portchannel
branch
from
August 6, 2026 10:56
11756b8 to
a69029d
Compare
ideaship
force-pushed
the
sonic-e2e-v2-portchannel
branch
from
August 6, 2026 12:10
a69029d to
d48d1df
Compare
ideaship
force-pushed
the
sonic-e2e-v2-portchannel
branch
from
August 6, 2026 12:19
d48d1df to
7029d37
Compare
berendt
force-pushed
the
sonic-e2e-v2-portchannel
branch
from
August 7, 2026 05:35
7029d37 to
3b303bb
Compare
ideaship
force-pushed
the
sonic-e2e-v2-portchannel
branch
from
August 7, 2026 08:07
3b303bb to
92fdab3
Compare
berendt
force-pushed
the
sonic-e2e-v2-portchannel
branch
from
August 7, 2026 08:59
92fdab3 to
1e53c84
Compare
ideaship
force-pushed
the
sonic-e2e-v2-portchannel
branch
from
August 25, 2026 13:55
1e53c84 to
945ef2f
Compare
ideaship
force-pushed
the
sonic-e2e-v2-portchannel
branch
from
September 16, 2026 14:18
945ef2f to
af8e0ba
Compare
ideaship
removed this pull request from stack #2572
September 16, 2026 14:27
ideaship
force-pushed
the
sonic-e2e-v2-portchannel
branch
from
September 16, 2026 15:02
af8e0ba to
24e8728
Compare
ideaship
force-pushed
the
sonic-e2e-v2-portchannel
branch
from
September 16, 2026 15:11
24e8728 to
afcbf17
Compare
ideaship
added this pull request to stack #2704
September 16, 2026 15:50
berendt
force-pushed
the
sonic-e2e-v2-portchannel
branch
from
September 16, 2026 16:02
afcbf17 to
098f1b5
Compare
berendt
force-pushed
the
sonic-e2e-v2-portchannel
branch
from
September 16, 2026 18:05
098f1b5 to
e994bc3
Compare
berendt
force-pushed
the
sonic-e2e-v2-portchannel
branch
from
September 16, 2026 19:28
e994bc3 to
ae28276
Compare
Add a port-channel (LAG) device to the SONiC E2E synthetic fixtures. Until now the base/breakout fixtures modelled no LAGs, so PORTCHANNEL, PORTCHANNEL_INTERFACE and PORTCHANNEL_MEMBER were emitted by the generator but always empty in every golden -- that code path had no coverage. e2e-portchannel (rack E2E, position 9, edgecore-7726-32x-e2e / Accton-AS7726-32X, role leaf) reuses the site/location/tenant/tag objects created by 100-base.yml. It bonds Ethernet0 and Ethernet4 into PortChannel1: a NetBox LAG interface (type: lag) with the two data ports referencing it via their lag field, the same way real deployments model a port-channel. This brings cumulative non-empty config_db table coverage across the golden set from 32 to 35 of the 38 tables the generator emits (only the VXLAN EVPN/tunnel tables remain uncovered). Verified with a full down/regen/verify cycle against a freshly started NetBox stack, so the goldens reflect a from-scratch database rather than an UPDATE over a reused one. Assisted-by: Claude:claude-sonnet-5 Signed-off-by: Roger Luethi <luethi@osism.tech>
Nothing in the golden set distinguished a numbered BGP session from an unnumbered one on the paths that generate most of them. e2e-portchannel modelled an uncabled LAG, so its BGP_NEIGHBOR and BGP_NEIGHBOR_AF were both empty -- get_connected_interfaces() marks a port channel connected only when a member is cabled, so those loops were never entered at all. No fixture reached the shape where an interface carries no address of its own while the endpoint it faces carries one, which is where the neighbour identity and the address family selection can disagree. Two blocks are added to 600-portchannel.yml. The first cables both members of PortChannel1 to e2e-metalbox-1, whose side is a LAG as well: an aggregate cabled to two standalone routed ports would not form. The peer address sits on that aggregate, not on the cabled members, which is the conventional way to model it. Two lookups would have to reach it and neither does -- the resolver's LAG member fallback is off for BGP on purpose, and nothing follows a member up to the peer's own aggregate -- so this pins the port channel peering unnumbered, and it moves the day either lookup changes. The numbered port-channel case cannot be reached from NetBox data at all, since a LAG interface is not cablable; the unit tests pin that one. The second gives the device a plain port with no address facing a metalbox port that has one, outside any Transfer prefix. With no local address there is nothing to source a numbered session from, so the peering is link-local and both address families are activated on Ethernet8. The two tables do not agree on who the peer is: the neighbour is keyed by the address found on the far end while the address families are keyed by the interface, so the golden records a session whose halves point at different names. That disagreement is as much the reason for this block as the peering mode is -- nothing else in tree captures it, and it moves the day the two are derived from one decision. e2e-metalbox-1 is the peer in both because it has no SONiC role and no managed-by-metalbox tag, so it never gets a golden of its own and the churn stays in this device's golden. Assisted-by: Claude:claude-opus-5 Signed-off-by: Roger Luethi <luethi@osism.tech>
berendt
force-pushed
the
sonic-e2e-v2-portchannel
branch
from
September 17, 2026 06:01
ae28276 to
d07d744
Compare
ideaship
marked this pull request as ready for review
September 17, 2026 06:54
![sourcery-ai[bot]](https://avatars.githubusercontent.com/in/48477?s=60&v=4){kind=small}
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Part of the series tracked in #2562, which explains the ordering and what each PR covers. Based on the preceding PR in the stack, so review only the top commits here.
Scenario overlay for port-channels, covering
PORTCHANNEL,PORTCHANNEL_MEMBERandPORTCHANNEL_INTERFACE.A second commit covers the BGP peering modes. The port-channel device
modelled an uncabled LAG, so both its BGP tables were empty and the neighbour
loops were never entered — no golden in the set distinguished a numbered
session from an unnumbered one. Two blocks are added: one cables both
PortChannel1 members to a peer whose side is a LAG as well, pinning the
port-channel peering unnumbered; the other gives the device a plain port with
no address facing a peer port that has one, which is link-local for the same
reason.
That second block also pins a shape worth knowing about before reading the
golden: the generator keys
BGP_NEIGHBORby the address found on the far endbut keys
BGP_NEIGHBOR_AFby the interface, so the two halves of that sessionpoint at different names. The change that would have derived both from one
decision was withdrawn as a fix without a reachable defect, and the check that
flagged it is reverted at the bottom of this stack. These goldens are now the
only place in tree where the shape is recorded.