Repository navigation
Conversation
Python test results63 tests 63 ✅ 6s ⏱️ Results for commit 9b8e101. ♻️ This comment has been updated with latest results. |
mfencik
left a comment
There was a problem hiding this comment.
Just a small thing, please test this in dev properly.
09c2c15 to
a266be6
Compare
The check was added to prevent the user from claiming a segmentation ID that happens to be the same as the parent port of this vlan. We don't want to allow that situation because the switch (stupidly) rejects that configuration. However, the way the check was implemented was too restrictive - it banned a range of thousands of VLAN IDs. It did successfully prevent all theoretical clashes present and future, but it also prevented legitimate configurations and caused an upset customer. We update this check so that it now compares the VLAN ID of the actual native VLAN on this trunk interface, and only raises an error if the user is configuring a number that would currently clash. The theoretical valid range is 1-4094 according to 802.1Q. However we would avoid VLAN 1, and we must avoid our nxos "reserved" vlan range 3872-3999. On Nexus 9000 NX-OS, Cisco treats VLANs 4048-4093 as their own. These might work, but even if they work today, they might randomly stop working at some future point. So this puts the realistic useable VLAN range at 2-3871 inclusive.
The theoretical valid range is 1-4094 according to 802.1Q. Avoiding VLANs that may be reserved/used by the switch: - Best practice is not to use VLAN1 for fear of cisco bugs and/or colliding with layer2 protocols, etc. - We must avoid our configured nxos "reserved" vlan range 3872-3999. - On Nexus 9000 NX-OS, Cisco anecdotally treats VLANs 4048-4093 as their own. These might work, but even if they work today, they might randomly stop working at some future point if they are used by the switch for some internal process. So this puts the realistic useable VLAN range at 2-3871 inclusive. In theory we could also allow use of 4000-4047 but the code only supports a single range of VLANs and it actually might make sense to reserve that "safe" range for future use by undercloud, perhaps as native VLAN on trunks or similar.
a266be6 to
4467443
Compare
The problem was that binding only checked the trunk when context.current contained the optional trunk_details extension. During VIF-attach path it evidently does not, so we should fetch from DB and validate separately there.
|
Two things I'd like addressed before this merges. 1. Release the dynamic segment when the native VLAN check fails In This is more reachable now than before. Subport tags used to be kept out of the segment allocation ranges, so a newly allocated native VLAN could never equal an existing tag. With the default range now We either need to run the collision check before allocating, or release the segment in the failure path. understack/python/neutron-understack/neutron_understack/understack_mech.py Lines 412 to 429 in 8498de8 2. Gate
Please gate it the same way the other precommit/postcommit paths do. understack/python/neutron-understack/neutron_understack/understack_mech.py Lines 190 to 193 in 8498de8 understack/python/neutron-understack/neutron_understack/trunk.py Lines 175 to 190 in 8498de8 |
|
My second comment was the second one as Milan and has been addressed. |
|
4ee9c29 a change to address my first comment if you want to cherry-pick that. |
The check was added to prevent the user from claiming a segmentation ID
that happens to be the same as the parent port of this vlan. We don't
want to allow that situation because the switch (stupidly) rejects that
configuration.
However, the way the check was implemented was too restrictive - it
banned a range of thousands of VLAN IDs. It did successfully prevent
all theoretical clashes present and future, but it also prevented
legitimate configurations and caused an upset customer.
We update this check so that it now compares the VLAN ID of the actual
native VLAN on this trunk interface, and only raises an error if the
user is configuring a number that would currently clash.
The theoretical valid range is 1-4094 according to 802.1Q.
However we would avoid VLAN 1, and we must avoid our nxos "reserved" vlan range 3872-3999.
On Nexus 9000 NX-OS, Cisco treats VLANs 4048-4093 as their own. These
might work, but even if they work today, they might randomly stop
working at some future point.
So this puts the realistic useable VLAN range at 2-3871 inclusive.
There was an existing config setting that seemed to do the right thing so I
piggy-backed on that rather than create another that does almost exactly
the same thing.
Result of testing in dev, first the setup:
openstack network create mynet-one openstack network create mynet-two openstack network create mynet-three openstack subnet create mynet-one --no-dhcp --subnet-range 192.168.1.0/24 --network mynet-one openstack subnet create mynet-three --no-dhcp --subnet-range 192.168.3.0/24 --network mynet-three --gateway none openstack subnet create mynet-two --no-dhcp --subnet-range 192.168.2.0/24 --network mynet-two --gateway none openstack port create myserver-mynet-one --network mynet-one openstack port create myserver-mynet-three --network mynet-three openstack port create myserver-mynet-two --network mynet-two openstack network trunk create myserver-trunk --parent-port myserver-mynet-one openstack network trunk set myserver-trunk --subport port=myserver-mynet-two,segmentation-type=vlan,segmentation-id=1802 openstack server create steve-test --port myserver-mynet-one --image 5048de36-4c01-4047-b638-195e639cb1e3 --flavor gp2.smallNow note that the above would not have worked on the previous code, we get the follwing error:
With the new code as per this PR, we are able to use vlan IDs outside the previous comfort zone.
I observed that the server was set up with a trunk on the switch having native vlan 1804.
We can now test the collision detection:
Here we note that using the native VLAN is rejected, whereas using other vlans is allowed.