Let's start with the obvious one: is there a reason you couldn't add "allocation: p2p" to the global P2P pool?

I suggested that in the past (#1611) but you disagreed at the time. Happy to revisit

Let's start with the obvious one: is there a reason you couldn't add "allocation: p2p" to the global P2P pool?

I suggested that in the past (#1611) but you disagreed at the time. Happy to revisit

Well, thanks for pointing that out ;) The problem was (and still is) that using P2P allocation strategy on a VLAN link masks the fact that an IRB VLAN has a single prefix. Not specifying the p2p allocation strategy crashes the allocation process, alerting the user to the fact that something weird is going on.

And now we uncovered another gotcha: you're doing too much tweaking. I never got that far because I stumbled on the "new global pool" showstopper.

This PR models the peerlink as a regular lag link with a VLAN trunk, enabling the full suite of Netlab features to be configured between the peers:

Is there supposed to be a default VLAN to be used on that link for the global IP routing, or is it just a VLAN trunk like any other trunk?

Note: Arubacx templates are modified but will need further adjustments and testing (like defining the vlan that gets created for peering, similar to eos)

There's a showstopper right there ;)

IP assignment to a routed vlan is achieved by creating a vlan in irb mode with a prefix, overriding the mode to route at the interface level

There's absolutely no need for that. Peer links are established between devices of the same type anyway, and if a device does not support mixed trunks, they you use IRB for the global IP routing VLAN. Any further device-specific limitations can be addressed in device quirks.

Please (always) try to modify the minimum amount of data structures necessary. We're learned the hard way that doing anything else creates unpredictable effects in the future.

• All vlans need to be allowed on the peerlink, I prefer to do this implicitly rather than explicitly list all vlans used in the topology because the latter may create "unsupported" scenarios (such as mixed trunks on Dell OS10).

I have no problem with this (just skip the VLAN assignment on the peer link), but it has to be documented.

It would be nicer to have "allow all VLANs" syntax, such that we could avoid lag module specific modifications to the vlan template

I don't see a need for the "allow all" trunks from the topology perspective, but I have no problem with an internal flag like vlan._all_vlans that would be used in VLAN configuration templates instead of checking the peerlink interface name or type.

• Global p2p pool could not be used due to the lack of a 'p2p' allocation strategy

As you can assign any pool to any VLAN, I fail to see why this is relevant ;)

• Global p2p pool could not be used due to the lack of a 'p2p' allocation strategy

As you can assign any pool to any VLAN, I fail to see why this is relevant ;)

I did try it - it results in an address allocation failure for the topology/input/lag-mlag-m_to_m.yml test case

Please (always) try to modify the minimum amount of data structures necessary. We're learned the hard way that doing anything else creates unpredictable effects in the future.

Ironically, this is exactly the reason why I opted for a separate mlag_p2p addressing pool, rather than add allocation: p2p to the existing global p2p one. It results in the minimum amount of change to the installed base

Is there supposed to be a default VLAN to be used on that link for the global IP routing, or is it just a VLAN trunk like any other trunk?

All VLANs - including the default VLAN - need to be allowed on the peerlink. On Cumulus the default VLAN is not used for IP routing - no IP address assigned to it - but removing it causes test cases to fail (without clear indications of why)

BTW, there's no need to set allocation: p2p on the P2P pool. You can set prefix.allocation on any link (or VLAN) and still get the IPv4/IPv6 address assigned from the pool. For example:

provider: clab

nodes:
  a:
    device: frr
    id: 33
  b:
    device: linux
    id: 44

links:
- interfaces: [ a,b ]
  prefix.allocation: p2p

You can set prefix.allocation on any link

I did try that first too, but it didn't seem to work. I'll try again

Update: Here's why that didn't work in this case #2090