Unable to reassign network port
-
I suppose we should close this out here and these are my conclusions. Just to note this can be replicated to another 6100 but others cannot replicate it. So this issue varies between devices.
-
VLAN description changes cannot happen while the Interface is enabled. I first have to disable the interface, go back to the VLAN assignments and change the description there. Enable the interface again.
-
Any changes to the LAGG [adding a vlan, deleting a vlan, changing description] causes the LAGG to bounce. Any connectivity riding that LAGG will experience an outage. It shouldn't be like this as other vendors do not function like this so this really should be looked at. Its possible for other vendors to write proprietary code for LAGGs to avoid this issue?
-
Late last night i discovered that if you do not use a LAG but instead use a single interface trunked. any changes made to that trunk interface will result in a link bounce. Again, it shouldnt be this way but i managed to replicate it on another device.
Overall, using trunked interfaces on pf is very risky in a production environment as any changes to it result in a momentary blip. I am curious if this would happen to me on a 4100 as that has different NIC drivers i believe. I still strongly suspect the NIC is the issue.
-
-
The 4100 uses identical NICs to the 6100 (and 8200).
The config not applying has to be a result of one the packages you have installed. If you removed all the packages you would be at the same point I was testing from (almost) where it does not happen.
Steve
-
@stephenw10 I'm really beginning to dislike the fact you are always right
I removed pfblockerNG
I then went in to change the vlan description and wouldnt you know it.......Applied right away.
There is still an outage tho.
So this leaves me with two questions
- where do we go from here? Do i reach out to the package maintener to describe the problem and see if theres a fix?
- Is the port flapping just what happens and thats the nature of how lagg is implemented?
-
Ah, that's interesting...hmm let me think about that. It could be simply the time it takes to reload everything some how. I assume you do not see it take 5mins to reload the filter when pfBlocker is populated correctly?
Applying changes to a VLAN on the LAGG is likely to bounce the LAGG because it reapplies the interfaces and the properties are inherited. I'm not sure if that can be prevented entirely.
-
@stephenw10 does it take a long time for pfblocker to update you mean? No it’s quick. Maybe a minute or 2 at the most.
Can you load pfblocker on your test device and replicate? -
No I mean the filter load so if you go to Status > Filter Reload and initiate the load how long does it take? It should be seconds.
-
@stephenw10 Ah. Right now without pfblockerNG installed. Seconds. Max 5s or so.
-
@stephenw10 You are not going to believe this [or maybe you will]. Upgraded to 23.01. Installed pfblocker [not ng version].
All problems have now went away. I am able to change vlan descriptions with pfblcoker installed AND the lagg doesn't bounce when you do it....
At the very least there was clearly some buggy/inconsistent behavior on 22.05 but on 23.01 all the problems noted above are now gone. LAGG is stable regardless of changes made.You have no idea how relieved i am on all this. I do deploy LAGGs and its just terrifying that i couldn't make a change unless im under a maintenance window.
-
Nice! Yeah the changes to 23.01 are large and extensive. It doesn't surprise me that the issue has changed. It would have been nice to know exactly what was happening there but it's probably not worth digging much further unless it reappears.
Steve
-
@stephenw10 appreciate you Stephen. Thanks for all the support !
