0

I'm trying to do a learning experiment with linux bridges. I wan't to create an isolated bridge on host without namespaces with the ability to debug interface connectivity.Setup

I want to be able ping dummy0 from dummy1 and in the opposite way ping -I dummy0 172.16.8.3

My configuration:

ip link add br0 type bridge
ip addr add 172.16.8.1/24 dev br0
ip link set dev br0 up
ip route add 172.16.8.0/24 dev br0 src 172.16.8.1 table 121
ip rule add oif br0 table 121

ip link add dummy0 type dummy
ip addr add 172.16.8.2/24 dev dummy0
ip link set dev dummy0 up
ip link set dev dummy0 master br0
ip route add 172.16.8.0/24 dev dummy0 src 172.16.8.2 table 122
ip route add default via 172.16.8.1 dev dummy0 table 122
ip rule add oif dummy0 table 122

ip link add dummy1 type dummy
ip addr add 172.16.8.3/24 dev dummy1
ip link set dev dummy1 up
ip link set dev dummy1 master br0
ip route add 172.16.8.0/24 dev dummy1 src 172.16.8.3 table 123
ip route add default via 172.16.8.1 dev dummy1 table 123
ip rule add oif dummy1 table 123

So, I have following:

root@x11spl-f-server-1:~# brctl show
bridge name     bridge id               STP enabled     interfaces
br0             8000.7a847996e153       no              dummy0
                                                        dummy1
root@x11spl-f-server-1:~# ip a s
...
6: br0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether 7a:84:79:96:e1:53 brd ff:ff:ff:ff:ff:ff
    inet 172.16.8.1/24 scope global br0
       valid_lft forever preferred_lft forever
    inet6 fe80::7884:79ff:fe96:e153/64 scope link
       valid_lft forever preferred_lft forever
7: dummy0: <BROADCAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc noqueue master br0 state UNKNOWN group default qlen 1000
    link/ether ca:9e:26:70:f4:1c brd ff:ff:ff:ff:ff:ff
    inet 172.16.8.2/24 scope global dummy0
       valid_lft forever preferred_lft forever
    inet6 fe80::c89e:26ff:fe70:f41c/64 scope link
       valid_lft forever preferred_lft forever
8: dummy1: <BROADCAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc noqueue master br0 state UNKNOWN group default qlen 1000
    link/ether 5a:9a:e1:70:ed:30 brd ff:ff:ff:ff:ff:ff
    inet 172.16.8.3/24 scope global dummy1
       valid_lft forever preferred_lft forever
    inet6 fe80::589a:e1ff:fe70:ed30/64 scope link
       valid_lft forever preferred_lft forever

root@x11spl-f-server-1:~# ip rule s
0:      from all lookup local
32763:  from all oif dummy1 lookup 123
32764:  from all oif br0 lookup 121
32765:  from all oif dummy0 lookup 122
32766:  from all lookup main
32767:  from all lookup default
root@x11spl-f-server-1:~# ip route s table 121
172.16.8.0/24 dev br0 scope link src 172.16.8.1
root@x11spl-f-server-1:~# ip route s table 122
default via 172.16.8.1 dev dummy0
172.16.8.0/24 dev dummy0 scope link src 172.16.8.2
root@x11spl-f-server-1:~# ip route s table 123
default via 172.16.8.1 dev dummy1
172.16.8.0/24 dev dummy1 scope link src 172.16.8.3
root@x11spl-f-server-1:~# brctl showmacs br0
port no mac addr                is local?       ageing timer
  2     5a:9a:e1:70:ed:30       yes                0.00
  2     5a:9a:e1:70:ed:30       yes                0.00
  1     ca:9e:26:70:f4:1c       yes                0.00
  1     ca:9e:26:70:f4:1c       yes                0.00
root@x11spl-f-server-1:~# ip route get 172.16.8.3 oif dummy0
172.16.8.3 dev dummy0 table 122 src 172.16.8.2 uid 0
    cache
root@x11spl-f-server-1:~# ip route get 172.16.8.2 oif dummy1
172.16.8.2 dev dummy1 table 123 src 172.16.8.3 uid 0
    cache

But unfortunately, I can't ping interfaces:

root@x11spl-f-server-1:~# ping -I dummy0 172.16.8.3
PING 172.16.8.3 (172.16.8.3) from 172.16.8.2 dummy0: 56(84) bytes of data.
^C
--- 172.16.8.3 ping statistics ---
2 packets transmitted, 0 received, 100% packet loss, time 1026ms

root@x11spl-f-server-1:~# ping -I dummy0 172.16.8.1
PING 172.16.8.1 (172.16.8.1) from 172.16.8.2 dummy0: 56(84) bytes of data.
^C
--- 172.16.8.1 ping statistics ---
2 packets transmitted, 0 received, 100% packet loss, time 1028ms

root@x11spl-f-server-1:~# ping -I dummy1 172.16.8.1
PING 172.16.8.1 (172.16.8.1) from 172.16.8.3 dummy1: 56(84) bytes of data.
^C
--- 172.16.8.1 ping statistics ---
3 packets transmitted, 0 received, 100% packet loss, time 2043ms

root@x11spl-f-server-1:~# ping -I dummy1 172.16.8.2
PING 172.16.8.2 (172.16.8.2) from 172.16.8.3 dummy1: 56(84) bytes of data.
^C
--- 172.16.8.2 ping statistics ---
2 packets transmitted, 0 received, 100% packet loss, time 1021ms

Interesting, if I specify IP address instead of interface it works:

root@x11spl-f-server-1:~# ping -I 172.16.8.2 172.16.8.3
PING 172.16.8.3 (172.16.8.3) from 172.16.8.2 : 56(84) bytes of data.
64 bytes from 172.16.8.3: icmp_seq=1 ttl=64 time=0.032 ms
64 bytes from 172.16.8.3: icmp_seq=2 ttl=64 time=0.046 ms
^C
--- 172.16.8.3 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1029ms
rtt min/avg/max/mdev = 0.032/0.039/0.046/0.007 ms

But there are no packets on br0 interface (weird).

root@x11spl-f-server-1:~# tcpdump -vvv -i br0
tcpdump: listening on br0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
^C
0 packets captured
0 packets received by filter
0 packets dropped by kernel

Please, can you help me to understood what I'm doing wrong

18
  • When you use -I with an address, it's not much different from "loopback ping" except that the source IP is different. -i lo will show you the traffics. While I have no idea how dummys work, it doesn't seem to make much sense to enslave them to a bridge anyway. But it won't work with veths either, apparently because at least by default, Linux does not replies to ARP requests with source IP that is a "local" IP. (Not sure if there's any sysctl or so you could mess with to get it work, if the whole setup could actually make any sense at all.)
    – Tom Yan
    Commented May 7 at 21:31
  • Is this other question similar to your current issue?
    – ErikF
    Commented May 7 at 22:31
  • Not really, this question is about the bridging issue, while in my case interface bridged successfully (see brctl showmacs output) I think, in my case, a problem somewhere in the routing tables. Commented May 8 at 6:58
  • @DmytroMalovanyi I suggest you actually try to get some ideas from the linked answer, otherwise you won't be going anywhere further. The lines brctl showmacs output in doesn't really "mean anything", especially when none of them has is local? being no. (Nevertheless, a non-local record there isn't equivalent to an ARP record in ip neigh.)
    – Tom Yan
    Commented May 8 at 8:05
  • Can you please explain why the same scenario with veth pairs with namespaces works, but with different routing tables - not? It's the main thing I try to understand with my setup Commented May 8 at 8:13

1 Answer 1

0

First off, a "dummy" interface basically does nothing with packets its told to send (but succeeds in sending them), and doesn't receive any packets. Thus, you can't ping anything on the interface and get a reply. (To an extent a dummy interface looks like a network segment with nothing else on it, except that it is much faster.)

But the next twist is that, since most networks can't see what they are sending, the operating system does special handling on anything sent to your own address. This -I interface form overrides routing, so the packet is "sent". With other forms, the packet is just handled locally, and you can get a ping reply.

The next twist is the bridge. With a bridge in place, the slave devices aren't routed to, and don't have usable addresses. Anything received from them is forwarded to the bridge driver. The bridge driver passes packets on to them when appropriate (which means broadcast packets including ARP and neighbor discovery, and packets to address from which packets have been received).

So, if you want to see packets involving one of your dummy interfaces, try something like ping 172.16.8.55. This should result in an ARP request being sent on the bridge, which it will then send to both dummy interfaces. This should be detectable with tcpdump. The ping -I interface commands are also visible to tcpdump.

If you want to see real traffic, you are going to need something on the other side of the enslaved devices. You could use veth and namespaces. You could use a tun/tap device, possibly with a network simulator. You could use some real network devices, if you have any.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .