Convert /32 stub interface into 'loopback' type

[jbemmel]

netlab/netsim/augment/links.py

Line 240 in df7818e

return(f'Static node address {node_link_data[af]} for node {node.name} does not include a host portion')

At this point, if 'lb' is True could we convert 'stub' into 'loopback':

# JvB: Turn 'stub' into 'loopback'
  if ifdata.get('type','stub') == 'stub':
    ifdata.type = 'loopback'

For srlinux I currently have to do this internally, as /32 addresses are not supported on regular interfaces.

Alternatively, what would be the way to declare additional loopback interfaces?

[ipspace]

I can't figure out why I added that particular code (apart from maybe "let's handle all possible scenarios") as you probably can't configure IPv4 /32 or IPv6 /128 on a physical interface of any sane platform.

However, if this becomes a mechanism that's in the netlab core (as opposed to SR Linux J2 template), then it needs to be documented and implemented on multiple platforms, and we need to know how to name loopbacks, and we might need yet another address pool... so let's start with the bigger picture.

Why would you need additional loopbacks (as opposed to stub links that create additional subnets to be advertised)? The whole "let's turn regular interfaces into loopbacks" SR Linux saga started because containerlab could not create stub networks, but that's solved now. Is there something else?

I think @ssasso had a similar challenge a while ago, but can't remember if that was just VRF loopbacks which got added or something else?

[jbemmel]

type: loopback already exists, it's used for vrf loopbacks. It's just not currently exposed to the user directly

Loopbacks are different than stub links - they are not associated with a physical port, so you can have many more of them.
You can assign /32 and/or /128 addresses. They have a purely virtual 'up' state.
Also, in VXLAN case loopbacks are advertised using the L3 VNI from the VRF, whereas stub links require/use a L2 VNI

Stub links generate veth pairs and dummy bridges, in my case I just need something to ping. And as a user my intention is to create a loopback interface - I know they exist, I've used them many times - and now Netlab is blocking me from creating one. That's just frustrating

[ipspace]

Loopbacks are different than stub links - they are not associated with a physical port, so you can have many more of them. You can assign /32 and/or /128 addresses. They have a purely virtual 'up' state. Also, in VXLAN case loopbacks are advertised using the L3 VNI from the VRF

Yeah, I've seen loopbacks before.

whereas stub links require/use a L2 VNI

I'm not so sure about that.

Stub links generate veth pairs and dummy bridges, in my case I just need something to ping. And as a user my intention is to create a loopback interface - I know they exist, I've used them many times - and now Netlab is blocking me from creating one. That's just frustrating

Nobody is blocking you. You could easily write a plugin, or a custom configuration template, or deal with stub networks that have zero neighbors in Jinja2 templates. Why do you find that frustrating?

[jbemmel]

It's not me I'm worried about, just the odd network engineer that is looking to use the tool without having to customize it.

I think most network engineers will have a rough idea in their mind of the configuration they're looking to build, and then it becomes an exercise of getting the tool to generate it. I think extra loopback interfaces are a concept that should be supported in netlab core

[ipspace]

OK, I will see how hard it would be to allow 'type: loopback' on links.

[ipspace]

Added in release 1.5.1