Use different external interace name when VLAN ID=0 #233
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
In case VLAN ID=0 NSM won't create a VLAN subinterface.
In fact, the base interface might not even be a VLAN interface.
So let Remote VLAN NSE create an interace with the name "ext"
in such cases.
Testing VLAN ID=0 requires NSM 1.4.0 uplift including an NSC patch to disable data-path healing: #231
Also, prior to starting NSM vpp forwarders the device selector config map must be updated to contain the VLAN interface(s) to be used.
Example:
Note: Occasionally vpp "fails to learn" all the interfaces in the device selector config map (could be more common when device selector contains more interfaces). In which case the external interface won't be created in the fe container.
Important: Currently vpp forwarder will quit processing the devices whenever it encounters an interface that does not exist on the host (not considered a fatal error). Devices are stored in a map (which does not guarantee any ordering when iterating), thus even using the same device selector config map different NSM starts might or might not experience the above problem.
Check the interfaces by entering the vpp forwarder container and then fetching the known interfaces through vppcli: