Bridge topology not working

[ldelossa]

Hello.

Trying a simple bridge topology:

name: bridge-topology

topology:
   nodes:
     linux1:
       kind: linux
       image: alpine:latest
     bridge1:
       kind: bridge

   links:
     - endpoints: ["linux1:eth1", "bridge1:port1"]

My goal here is to have a Linux container with its own network namespace.
A bridge in the host network namespace.
One side of the container's veth should be plugged into the bridge.

I create the bridge manually.

I keep getting these errors:

sudo make deploy
ip link add bridge1 type bridge
containerlab deploy
INFO[0000] Containerlab v0.56.0 started                 
INFO[0000] Parsing & checking topology file: xfrm-dev.clab.yaml 
Error: interface bridge1:port1 is defined via topology but does already exist: <nil>
make: *** [Makefile:3: deploy] Error 1

Apparently containerlab is checking if an interface already exists. Is this some kinda dependency issue I'm running into?

[ldelossa]

Sorry, I had some stale state on my workstation which left some links behind, they are now removed.

I still face an issue with the follow topology:

name: xfrm-devices-demo

topology:
  nodes:
    xfrm-demo-br:
      kind: bridge

    node-a:
      kind: linux
      image: nicolaka/netshoot:v0.13
      binds:
        - ./node-a/:/mnt

    node-b:
      kind: linux
      image: nicolaka/netshoot:v0.13
      binds:
        - ./node-b/:/mnt

  links:
    - endpoints: ["node-a:eth1", "xfrm-demo-br:port1"]
    - endpoints: ["node-b:eth1", "xfrm-demo-br:port2"]

In this topo, I wind up with node-a:eth1 plugged into the bridge, but not node-b:eth1.

bridge link
30: port1@if29: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9500 master xfrm-demo-br state disabled priority 32 cost 2 
34: veth2b05612@if33: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 master br-88373f50bbb0 state forwarding priority 32 cost 2 
36: veth56cc2ee@if35: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 master br-88373f50bbb0 state forwarding priority 32 cost 2 

The other veths are management veths.

[hellt]

without logs it is impossible to say anything

[moritzbeck13]

@ldelossa @hellt I have the same issue.

This is my topology definition:

name: ixp

topology:
  kinds:
    vyosnetworks_vyos:
      image: vyos:stream-2025.11

  nodes:
    peer-1:
      kind: vyosnetworks_vyos
    peer-2:
      kind: vyosnetworks_vyos
    route-server:
      kind: vyosnetworks_vyos
    peering-lan:
      kind: bridge
    transit-router:
      kind: vyosnetworks_vyos
    ixp-router:
      kind: vyosnetworks_vyos
    customer-1:
      kind: vyosnetworks_vyos
    customer-2:
      kind: vyosnetworks_vyos

  links:
    - endpoints: [ "peer-1:eth1", "peering-lan:eth1" ]
    - endpoints: [ "peer-2:eth1", "peering-lan:eth2" ]
    - endpoints: [ "route-server:eth1", "peering-lan:eth3" ]
    - endpoints: [ "peering-lan:eth4", "ixp-router:eth1" ]
    - endpoints: [ "transit-router:eth1", "ixp-router:eth2"]
    - endpoints: [ "ixp-router:eth3", "customer-1:eth1" ]
    - endpoints: [ "ixp-router:eth4", "customer-2:eth1" ]

This is the log output:

[info] [containerlab] Running: containerlab deploy -r docker -t /home/clab/ixp/ixp.clab.yml
[info] INFO Containerlab started version=0.72.0
[info] INFO Parsing & checking topology file=ixp.clab.yml
[info] interface peering-lan:eth1 is defined via topology but already exists: <nil>
[info] interface peering-lan:eth2 is defined via topology but already exists: <nil>

# ip link show peering-lan
34: peering-lan: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
    link/ether e6:ac:13:9f:d4:8c brd ff:ff:ff:ff:ff:ff

# bridge link show dev peering-lan

Funnily enough, this only happens for eth1 and eth2. All the other ones work fine.
I'm using the WSL image and already tried starting fresh.

[moritzbeck13]

I think I just figured it out: If an interface is in the host namespace (like those of bridges), they cannot have the same name as existing interfaces on the system. Otherwise it collides or something. The documentation also hints at this.