You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Add ability to specify "Parent Interface" for "Virtual" Interface Type. Allow "Virtual" Interface type to be part of the LAG interface. Use similar UI as for setting "Parent Lag".
See mockup below:
Use Case
In my case SRIOV Virtual Functions are used for Network Adapters (10, 50 and 100Gbit/s) to simplify management, partition traffic and allow granular bandwidth control. For all intends and purposes the virtual function interface behaves similarly to a regular interface that is connected to the switch (with its own MAC, IP and VLAN), but it shares the “same link” as a parent interface (physical function).
Being able to assign an optional "Parent Interface" to the "Virtual" one will greatly simplify the process of debugging network issues, as I will be able find the exact parent interface the virtual interface "resides on". Together with that, I use virtual functions as part of the bond interface and the current virtual interface model prevents the virtual interface to be part of the LAG.
As a bonus feature this will also allow to model shared BMC/IMPI interfaces closer to the real world scenario without converting Interface Mac Address field to list as proposed in #4867.
Database Changes
TBD
External Dependencies
None
The text was updated successfully, but these errors were encountered:
Seems like this would be addressed by #1519, so I'm going to close this out. Please feel free to add any additional comments/concerns under that issue.
Environment
Proposed Functionality
Add ability to specify "Parent Interface" for "Virtual" Interface Type. Allow "Virtual" Interface type to be part of the LAG interface. Use similar UI as for setting "Parent Lag".
See mockup below:
Use Case
In my case SRIOV Virtual Functions are used for Network Adapters (10, 50 and 100Gbit/s) to simplify management, partition traffic and allow granular bandwidth control. For all intends and purposes the virtual function interface behaves similarly to a regular interface that is connected to the switch (with its own MAC, IP and VLAN), but it shares the “same link” as a parent interface (physical function).
Being able to assign an optional "Parent Interface" to the "Virtual" one will greatly simplify the process of debugging network issues, as I will be able find the exact parent interface the virtual interface "resides on". Together with that, I use virtual functions as part of the bond interface and the current virtual interface model prevents the virtual interface to be part of the LAG.
As a bonus feature this will also allow to model shared BMC/IMPI interfaces closer to the real world scenario without converting Interface Mac Address field to list as proposed in #4867.
Database Changes
TBD
External Dependencies
None
The text was updated successfully, but these errors were encountered: