The layer2 provisioner API reports the wrong port name for interfaces on different switches

[rfc1036]

ISSUE TYPE

Bug Report

OS

Ubuntu 24.04 LTS

VERSION

define( 'APPLICATION_VERSION', '6.4.1' );
define( 'APPLICATION_VERDATE', '2024060900' );

SUMMARY

When a VLAN interface has two physical ports on different switches configured, the v4/provisioner/layer2interfaces/switch-name/$switch.json API returns an incorrect port name for the second switch port.

STEPS TO REPRODUCE

My procedure to migrate a member to a different switch is:

1. add the new physical port to the existing VLAN interface
2. ignore the warning saying that this is not supported because the ports are in different switches
3. generate the configuration for the new switch using data from the L2 provisioner API
4. move the fiber
5. remove the old physical port

At step 3 both the old and the new interface are configured in IXP manager.

EXPECTED RESULTS

The API should return the correct port for the switch.

ACTUAL RESULTS

The API returns the name of the first port also for the second switch.

IMPORTANCE

Not being able to automatically generate the configuration for a new switch port significantly increases the risk of configuration mistakes.

[barryo]

So, for the record, not a bug but a feature request because:

ignore the warning saying that this is not supported because the ports are in different switches

What are you ultimately trying to achieve here? Is it a port migration? The way we'd handle that is:

1. edit the existing physical port and change the switch/switchport to the new one
2. deploy configuration to new switch

I.e. we wouldn't have old and new at the same time.

[rfc1036]

Yes, the ultimate goal is migrating the port.
Just editing the port is sub optimal because it needs to be coordinated tightly with the data center activity (and causes loss of statistics?).

[barryo]

We'll look at the issue for sure.

Regarding the process, I can only speak to how we typically do these. For us, we'd never have two ports enabled for a member during a migration for fear of l2 loops / etc. You never know what's on the member end of the link. So we always co-ordinate on time and the process for us is:

1. member drains traffic on old port
2. member disables old port [i.e. onus is on the member to take their port down]
3. we see port down / member tells us and then we disable the old port on our end.
4. swap switch/switchport on physical interface
5. new port already enabled in quarantine lan usually, member configures new port and we test pings and follow quarantine
6. deploy new config to push to production
7. member up on new port

Statistics wise - adding two physical interfaces won't solve that as the mrtg config stores the data in dedicated physical interface files. I.e. old port data in old phys int file and new port data in new phys int file. The only time their combined is if the port is a lag.

[rfc1036]

BTW, I have noticed that also parameters like speed and status refer to the first port.