Skip to content

Conversation

ipspace
Copy link
Owner

@ipspace ipspace commented Sep 4, 2025

  • The loopback data is checked as a new 'loopback' type to allow IGP modules to register a subset of link/interface attributes as begin valid on the loopback interface
  • The loopback interface must be validated with the top-level 'validate_attributes' function, otherwise the module attributes are not recognized.
  • Loopback data is thus checked first as a dict/bool within the node data, and then rechecked against the new 'loopback' type (assuming the 'loopback' attribute is not set to True/False).
  • The 'module attribute can be False' list is extended to include the 'loopback' data type
  • We have to deal with 'is the IGP set to False on loopback' in numerous places within the generic routing code until we finally remove 'igp: False' data in 'remove_unused_igp' function
  • To make that work, the 'add_loopback_igp' call had to be moved, resulting in IGP information appearing on the loopback interface even when the IGP module is removed from the node.

Fixes #2625 and solves #2624

* The loopback data is checked as a new 'loopback' type to allow
  IGP modules to register a subset of link/interface attributes as
  begin valid on the loopback interface
* The loopback interface must be validated with the top-level
  'validate_attributes' function, otherwise the module attributes
  are not recognized.
* Loopback data is thus checked first as a dict/bool within the
  node data, and then rechecked against the new 'loopback' type
  (assuming the 'loopback' attribute is not set to True/False).
* The 'module attribute can be False' list is extended to include
  the 'loopback' data type
* We have to deal with 'is the IGP set to False on loopback' in
  numerous places within the generic routing code until we finally
  remove 'igp: False' data in 'remove_unused_igp' function
* To make that work, the 'add_loopback_igp' call had to be moved,
  resulting in IGP information appearing on the loopback interface
  even when the IGP module is removed from the node.

Fixes #2625 and solves #2624
@ipspace
Copy link
Owner Author

ipspace commented Sep 4, 2025

@DanPartelly -- this should solve your "I only want one IGP on the loopback" challenge

@jbemmel -- instead of leaving IGP attributes on the loopback (current behavior, now with "passive" flag) when the IGP module is removed from the node due to being useless (as in: no external interfaces are using it), I could remove them. Any thoughts?

@jbemmel
Copy link
Collaborator

jbemmel commented Sep 4, 2025

@jbemmel -- instead of leaving IGP attributes on the loopback (current behavior, now with "passive" flag) when the IGP module is removed from the node due to being useless (as in: no external interfaces are using it), I could remove them. Any thoughts?

I like cleaned up attributes, so yes I would prefer to remove them altogether

Copy link
Collaborator

@jbemmel jbemmel left a comment

Choose a reason for hiding this comment

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

Loopbacks in VRFs next?

Copy link
Collaborator

@DanPartelly DanPartelly left a comment

Choose a reason for hiding this comment

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

Thank you.This is a nice surprise, didn't expected anyone to work on this untill after 25.09.

@ipspace ipspace merged commit 9e3724d into dev Sep 5, 2025
12 checks passed
@ipspace ipspace deleted the lb-intf-attr branch September 5, 2025 09:25
ipspace added a commit that referenced this pull request Sep 30, 2025
Using the infrastructure created in #2656, the VRF module validation of
the loopback interface data allows module-specific loopback parameters.

The extra loopback VRF parameters are copied into the interface data
when the VRF module creates VRF loopback interfaces in the node data.

Also:
* Add 'bgp.advertise' as a valid loopback parameter as we have no
  VRF equivalent of 'bgp.advertise_loopback' node parameter.
* Add VRF loopback OSPF area to a transformation test
* Create a new error test that checks the VRF loopback validation code

Implements #2659
ipspace added a commit that referenced this pull request Oct 5, 2025
Using the infrastructure created in #2656, the VRF module validation of
the loopback interface data allows module-specific loopback parameters.

The extra loopback VRF parameters are copied into the interface data
when the VRF module creates VRF loopback interfaces in the node data.

Also:
* Add 'bgp.advertise' as a valid loopback parameter as we have no
  VRF equivalent of 'bgp.advertise_loopback' node parameter.
* Add VRF loopback OSPF area to a transformation test
* Create a new error test that checks the VRF loopback validation code

Implements #2659
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Loopback validation code should accept interface- and module attributes
3 participants