Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Appearance settings

Add peer interface annotation for physical interfaces#191

Open
felix-kaestner wants to merge 1 commit intomainironcore-dev/network-operator:mainfrom
annotationironcore-dev/network-operator:annotationCopy head branch name to clipboard
Open

Add peer interface annotation for physical interfaces#191
felix-kaestner wants to merge 1 commit intomainironcore-dev/network-operator:mainfrom
annotationironcore-dev/network-operator:annotationCopy head branch name to clipboard

Conversation

@felix-kaestner
Copy link
Contributor

@felix-kaestner felix-kaestner commented Feb 18, 2026

This patch introduces the PhysicalInterfaceNeighborLabel label which
references the peer Interface resource on the other end of a physical
link. The label can be used by users to declare expected cabling, or
by controllers to reflect actual cabling discovered via neighbor
discovery protocols (e.g., LLDP).

The label value must be the name of another Interface resource in the
same namespace. It is only valid for interfaces of type Physical.

Additionally, a PhysicalInterfaceNeighborRawAnnotation annotation is
introduced for interfaces connected to unmanaged devices (devices
without an Interface resource). The annotation value format is
"chassisID::portID" where chassisID is the LLDP chassis identifier
and portID is the LLDP port identifier.

Both the label and annotation are mutually exclusive - an interface
cannot have both set at the same time.

@felix-kaestner felix-kaestner requested a review from a team as a code owner February 18, 2026 21:54
@hardikdr hardikdr added the area/metal-automation Automation processes within the Metal project. label Feb 19, 2026
@hardikdr hardikdr added this to Roadmap Feb 19, 2026
Comment on lines +66 to +70
// InterfacePeerAnnotation references the peer Interface resource on the other end of a physical link.
// The value must be a reference to another Interface resource in the format "namespace/name"
// or just "name" (for same-namespace references).
// This annotation is only valid for interfaces of type Physical.
const InterfacePeerAnnotation = "networking.metal.ironcore.dev/peer-interface"
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think aggregated interfaces should be allowed too: "An An LLDP agent can be configured on an IEEE 802.1AX™ Aggregated Port and/or on any number of the physical ports belonging to the Aggregation" [IEEE8021AB-2016]. May be we could leave a note here or extend the commit message if we want to enforce this condition for now.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would expect that configuring LLDP on an Aggregate Interface, would lead to configuring it's member Interfaces. As the Aggregate Interface is a logical/virtual construct, for me it's not directly related to the physical cabling, so in this case I would expect that annotation to be on the members instead and not on the aggregate. But I'm happy to discuss.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fair point. We also discussed it in our alignment and we won't consider link aggregation. In this context, what do you think about renaming the Annotation to PhysicalInterfaceNeighborAnnotation = "networking.metal.ironcore.dev/interface-neighbor". This would also be more consistent with the LLDP terminology.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done. I've also changed this from an annotation to a label (PhysicalInterfaceNeighborLabel) with a same-namespace constraint. This enables filtering via kubectl get interfaces -l networking.metal.ironcore.dev/interface-neighbor=<name> and avoids the / character issue that labels have with the namespace/name format.

Comment on lines +66 to +70
// InterfacePeerAnnotation references the peer Interface resource on the other end of a physical link.
// The value must be a reference to another Interface resource in the format "namespace/name"
// or just "name" (for same-namespace references).
// This annotation is only valid for interfaces of type Physical.
const InterfacePeerAnnotation = "networking.metal.ironcore.dev/peer-interface"
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I like using the reference to another resource here. However, I am wondering how we will deal with those interfaces that have peers outside our control and for which we do not have an Interface resource. We won't have a way to verify the cabling.

Copy link
Contributor

@nikatza nikatza Feb 19, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We also discussed this and our use case includes also verifying the cabling of interfaces connected to other devices and interfaces that we do not control. Usually the neighbor is a combination of the chassisID or sysName (typically the first since that one is mandatory), and the portId, which is the MAC, the ifAliasor ifName (typically the last one).

So in principle we would like to support both a reference to a physical interface and some sort of string. While this is not immediately pressing, its probably considering this already. What do you think?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Added PhysicalInterfaceNeighborRawAnnotation for this use case. The format is chassisID::portID (e.g., spine-switch-01::Ethernet48 or 00:1a:2b:3c:4d:5e::Ethernet1/1). This remains an annotation since the value can exceed the 63-character label limit with long chassis/port identifiers.

The label and raw annotation are mutually exclusive - the webhook rejects interfaces that have both set.

@SchwarzM
Copy link

do we want to use an annotation in this case ? this makes it harder for cli tools to display / filter for it correctly I think

@felix-kaestner
Copy link
Contributor Author

do we want to use an annotation in this case ? this makes it harder for cli tools to display / filter for it correctly I think

@SchwarzM Changed to a label with a same-namespace constraint - the value is now just the interface name (no namespace prefix). This enables filtering while keeping the value label-compatible.

This patch introduces the `PhysicalInterfaceNeighborLabel` label which
references the peer Interface resource on the other end of a physical
link. The label can be used by users to declare expected cabling, or
by controllers to reflect actual cabling discovered via neighbor
discovery protocols (e.g., LLDP).

The label value must be the name of another Interface resource in the
same namespace. It is only valid for interfaces of type Physical.

Additionally, a `PhysicalInterfaceNeighborRawAnnotation` annotation is
introduced for interfaces connected to unmanaged devices (devices
without an Interface resource). The annotation value format is
"chassisID::portID" where chassisID is the LLDP chassis identifier
and portID is the LLDP port identifier.

Both the label and annotation are mutually exclusive - an interface
cannot have both set at the same time.
@github-actions
Copy link

github-actions bot commented Mar 3, 2026

Merging this branch will increase overall coverage

Impacted Packages Coverage Δ 🤖
github.com/ironcore-dev/network-operator/api/core/v1alpha1 0.00% (ø)
github.com/ironcore-dev/network-operator/internal/webhook/core/v1alpha1 89.47% (+1.84%) 👍

Coverage by file

Changed files (no unit tests)

Changed File Coverage Δ Total Covered Missed 🤖
github.com/ironcore-dev/network-operator/api/core/v1alpha1/groupversion_info.go 0.00% (ø) 0 0 0
github.com/ironcore-dev/network-operator/internal/webhook/core/v1alpha1/interface_webhook.go 93.62% (+10.28%) 47 (+23) 44 (+24) 3 (-1) 🎉

Please note that the "Total", "Covered", and "Missed" counts above refer to code statements instead of lines of code. The value in brackets refers to the test coverage of that file in the old version of the code.

Changed unit test files

  • github.com/ironcore-dev/network-operator/internal/webhook/core/v1alpha1/interface_webhook_test.go

Copy link
Contributor

@nikatza nikatza left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice, thanks for the update!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

area/metal-automation Automation processes within the Metal project.

Projects

Status: No status

Development

Successfully merging this pull request may close these issues.

4 participants

Morty Proxy This is a proxified and sanitized view of the page, visit original site.