-
Notifications
You must be signed in to change notification settings - Fork 94
Implement select IGP parameters on the primary loopback interface #2656
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
* 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
@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? |
I like cleaned up attributes, so yes I would prefer to remove them altogether |
There was a problem hiding this 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?
There was a problem hiding this 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.
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
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
Fixes #2625 and solves #2624