[listerr]

Explanation

Our port channel numbers for member LAGs have always started from 100 to distinguish them from non-member LAGs, or LAGs configured elsewhere.

When configuring a LAG, IXP Manager's current behaviour always starts from 1 and automatically allocates either 1, or the next highest number after 1. In our case, it sets a default of 1 when adding a LAG.

This means we always have to:

• Edit IXP Manager's default allocation
• Log in to the appropriate switch, find the next available channel number
• Manually add it to IXP Manager

This update eliminates these manual admin steps.

Functionality

This PR updates IXP Manager with two new settings to tell it the correct range to assign our member LAG port channel numbers.

Examples:

1. Auto-allocate the next available unused port channel for the relevant switch, starting from 100.

IXP_FE_CHANNELGROUP_START=100

2. "Auto mode" : A start of 0 will auto-allocate the next available unused port channel, starting from the lowest currently used port channel for the relevant switch. If no channel numbers have been allocated, start from 1.

IXP_FE_CHANNELGROUP_START=0

3. A start of 1 will auto-allocate the next next available unused port channel, starting from 1 (this has been set as the default, to preserve the current behaviour if unset.)

IXP_FE_CHANNELGROUP_START=1

4. End range

Since the end value of 1000 was hard-coded, I've made this configurable too (it's conceivable that someone could use "only high LAG numbers" to mean "non-member/ISLs" etc or their device can use channel group numbers > 1000. (Arista supports the range 1-99999.) The default is set to 1000 to preserve the current behaviour if unset.

IXP_FE_CHANNELGROUP_END=1000

In addition to the above, I have:

• ensured unit tests all run without error
• ran psalm and corrected any static analysis issues
• ensured all relevant template output is escaped to avoid XSS attached with <?= $t->ee( $data ) ?> or equivalent
• ensured appropriate checks against user privilege / resources accessed

[afk11]

Hi @listerr, thanks for the PR!

I saw one or two minor things here I'd like to touch up so I wanted to double check if you are OK with me pushing commits to your PR's? I'll only really do it if it's minor / not going to change the substance of the PR

It saves me opening a follow up PR and I don't like using 'request changes' on something minor

Let me know, I'll comment them for now anyway

[listerr]

hi @afk11 - Looks reasonable. I have no issues with tweaks to PRs as you see fit. I've done another commit anyway just to check I've understood it correctly. Thanks!

[afk11]

Pushed commit allowing settings to be unset via settings controller form - will mean we revert back to defaults of 1 and 1000