Skip to content

Manage the lifecycle of an (internal-only) bridge  #2267

@mzagozen

Description

@mzagozen

I recently started using the bridge node kind to connect multiple nodes to the same access domain. In other words, I use the bridge to connect multiple containerlab nodes defined in the same topology, and not connect the bridge to any external or other interfaces on the host. The documentation states you're supposed to bring up the bridge yourself. This makes perfect sense when the bridge is connected to interfaces outside of control of containerlab - the user will need to set up those anyway. But for the use case where the bridge only connects to containerlab nodes (like in the br01 example), I feel it would make for a better user experience if containerlab attempts to take ownership of the entire lifecycle for the bridge.

For instance, if a bridge node exists the topology, for the deploy and destroy commands:

  • [deploy] containerlab creates the bridge if it does not exist
  • [deploy] containerlab connects node endpoints as listed to the bridge
  • [destroy] containerlab removes the node endpoints it created on the bridge
  • [destroy] containerlab removes the bridge if no interfaces remain connected to the bridge on topology destroy, after having removed the nodes

WDYT? I am not super familiar with containerlab internals, but I am guessing these operations would need to be serialized before and after concurrently processing nodes?

Metadata

Metadata

Assignees

Labels

No labels
No labels

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions