Skip to content
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

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

raja-rajasekar
Copy link
Contributor

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]

lib/if.h Outdated
IF_MACVLAN, /* MAC VLAN interface*/
IF_VETH, /* VETH interface*/
IF_BOND, /* Bond */
IF_BOND_SLAVE, /* Bond Slave*/
Copy link
Contributor

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.

Copy link
Contributor

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.

Copy link
Contributor Author

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.

Copy link
Contributor

@idryzhov idryzhov Nov 15, 2023

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.

Copy link
Contributor Author

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

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]>
Copy link
Member

@ton31337 ton31337 left a 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?

@raja-rajasekar
Copy link
Contributor Author

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.

@eqvinox
Copy link
Contributor

eqvinox commented Nov 17, 2023

There is a bug/requirement to make the MACVLAN interface (vlan##-v0) ospf passive

This sounds like what is really needed is a better secondary indicator?

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 ip ospf passive on the MACVLAN devices?

Copy link

This PR is stale because it has been open 180 days with no activity. Comment or remove the autoclose label in order to avoid having this PR closed.

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

Successfully merging this pull request may close these issues.

4 participants