-
Notifications
You must be signed in to change notification settings - Fork 1.3k
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
lib: Introducing interface type to struct interface #14799
base: master
Are you sure you want to change the base?
Conversation
lib/if.h
Outdated
IF_MACVLAN, /* MAC VLAN interface*/ | ||
IF_VETH, /* VETH interface*/ | ||
IF_BOND, /* Bond */ | ||
IF_BOND_SLAVE, /* Bond Slave*/ |
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.
There's no such interface type as BOND_SLAVE.
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.
Overall, as you directly assign this type from enum zebra_iftype
, I think it's much better to move enum zebra_iftype
to a library and use a single type in lib and zebra. Otherwise there's a huge chance that the types will become out of sync.
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.
Sure, will remove the BOND_SLAVE.
As to moving/consolidating the enum zebra_iftype at one place in if.h, it involves lots of files to be touched. The work is in progress and i will raise a subsequent MR to do that work.
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.
It's used in just 5 files, all of them in zebra. I don't see any reason to merge this as-is, instead of using a shared enum from lib/if.h everywhere. The current solution is too error-prone.
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.
Sure, let me work on a cleaner solution and upload the changes
d4fa74a
to
9c556b4
Compare
Adding new field (interface type like Vlan,SVI,VRR etc..) in the struct interface to inform all zebra clients like ospf/bgp. This can help protocols take appropriate action based on a specific interface type. Ticket #3668878 Signed-off-by:.Chirag Shah.<[email protected]> Signed-off-by: Rajasekar Raja <[email protected]>
9c556b4
to
fb6a54e
Compare
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.
Where is this interface type is gonna be used? For now, it's just an abandoned new struct member?
There is a bug/requirement to make the MACVLAN interface (vlan##-v0) ospf passive if configured via ospf network statement. A cleaner solution is to let the clients/protocols know the interface type to take action as needed. |
This sounds like what is really needed is a better If a user has multiple MACVLAN devices and is not using the main device at all, they may well want to have OSPF enabled on some of the interfaces… Also, what is preventing the user from either using interface based OSPF config, or putting |
This PR is stale because it has been open 180 days with no activity. Comment or remove the |
Adding new field (interface type like Vlan,SVI,VRR etc..) in the struct interface to inform all zebra clients like ospf/bgp.
This can help protocols take appropriate action based on a specific interface type.
Ticket #3668878
Signed-off-by:.Chirag Shah.[email protected]
Signed-off-by: Rajasekar Raja [email protected]