Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
rfc1036 opened this issue Aug 28, 2024 · 4 comments
Labels

Comments

@rfc1036
Copy link

rfc1036 commented Aug 28, 2024

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 barryo added the Feature label Aug 28, 2024
@barryo
Copy link
Member

barryo commented Aug 28, 2024

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
Copy link
Author

rfc1036 commented Aug 28, 2024

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
Copy link
Member

barryo commented Aug 28, 2024

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
Copy link
Author

rfc1036 commented Aug 29, 2024

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants