2

It seems like I have a generic problem, but can't find any solution - every solution that I found so far on internets doesn't work for me. Let me first try to explain what I am trying to do - I have a linux box with three interfaces - one is uplink going to provider and two others are supposed to be two physical parts of a single logical network. So I have the following:

br0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1488 inet 10.0.0.1 netmask 255.0.0.0 broadcast 10.255.255.255 ether 00:24:9b:04:3b:a7 txqueuelen 0 (Ethernet) RX packets 102156 bytes 8545914 (8.1 MiB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 44194 bytes 7959306 (7.5 MiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 eth1: flags=4419<UP,BROADCAST,RUNNING,PROMISC,MULTICAST> mtu 1488 ether 00:24:9b:04:3f:ae txqueuelen 1000 (Ethernet) RX packets 56553 bytes 4992101 (4.7 MiB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 15920 bytes 4418268 (4.2 MiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 eth2: flags=4419<UP,BROADCAST,RUNNING,PROMISC,MULTICAST> mtu 1488 ether 00:24:9b:04:3b:a7 txqueuelen 1000 (Ethernet) RX packets 56298 bytes 7582661 (7.2 MiB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 64175 bytes 8148316 (7.7 MiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

br0 is bridging eth1 and eth2 and also is supposed to have a static address used as a gateway. Now here is the problem - if I am on gateway and I try to ping a box in segment attached to eth2 - everything works - arp is resolved and icmp flows, but if I am trying to ping something in eth1 segment - I see arp requests on eth2 and obviously nothing happens.

So in general my problem is that bridge is using only ONE MAC address - the one that eth2 has. Any pointers to documentation that I might have missed or suggestions are welcome!

Thanks!

Additional information as requested:

# ip r sh default dev ppp0 scope link 10.0.0.0/8 dev br0 proto kernel scope link src 10.0.0.1 192.168.101.115 dev ppp0 proto kernel scope link src 192.168.6.59 # ip link sh 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN mode DEFAULT link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN mode DEFAULT qlen 1000 link/ether da:f3:53:e3:69:84 brd ff:ff:ff:ff:ff:ff 3: tunl0: <NOARP> mtu 1480 qdisc noop state DOWN mode DEFAULT link/ipip 0.0.0.0 brd 0.0.0.0 4: eth1: <BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> mtu 1488 qdisc pfifo_fast master br0 state UP mode DEFAULT qlen 1000 link/ether 00:24:9b:04:3f:ae brd ff:ff:ff:ff:ff:ff 5: eth2: <BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> mtu 1488 qdisc pfifo_fast master br0 state UP mode DEFAULT qlen 1000 link/ether 00:24:9b:04:3b:a7 brd ff:ff:ff:ff:ff:ff 6: br0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1488 qdisc noqueue state UP mode DEFAULT link/ether 00:24:9b:04:3b:a7 brd ff:ff:ff:ff:ff:ff 12: ppp0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1492 qdisc pfifo_fast state UNKNOWN mode DEFAULT qlen 3 link/ppp # brctl show bridge name bridge id STP enabled interfaces br0 8000.00249b043ba7 no eth1 eth2

Ok, a short update depending on the order of ifconfig/brctl addif - I can make it send packets either via eth1 or via eth2.

Improve this question
4
  • 1
    It is supposed to use only one mac. Please post the output of ip r sh, ip link sh and brctl show. Commented May 23, 2013 at 19:19
  • added to original post Commented May 23, 2013 at 19:30
  • That looks quite sane. Are there, by any means, "special" component in that server's environment which could somehow create a bridging loop? I've noted that MTU is 1488. Can it be related? Also dmesg could have interesting messages about the interfaces/bridge. Though I can't think of a single thing which would stop the arp request going out all the interfaces: it's broadcast traffic and should be flooded on all the UP ports (you have stp disabled so no forwarding/blocked state to consider). Commented May 23, 2013 at 19:55
  • The only special thing I can think of is that eth1/eth2 are USB cards, that is the only "special" thing about the system - nothing wireless or anything - just plain USB ethernet cards. dmesg doesn't have much:[ 15.060000] br0: port 2(eth2) entering forwarding state [ 15.070000] br0: port 2(eth2) entering forwarding state [ 15.070000] br0: port 1(eth1) entering forwarding state [ 15.080000] br0: port 1(eth1) entering forwarding state ` Interesting to mention is that if I remove eth2 from bridge and only eth1 is left then eth1 is selected... Commented May 23, 2013 at 20:02

1 Answer 1

Reset to default
0

I don't know about USB NICs, but it's common for WLAN cards to drop any outgoing frames with a source MAC which isn't theirs.

Your broadcasted ARP request may be leaving br0 with source MAC a7. eth2 also happens to have MAC a7 so it forwards the frame, however eth1 has MAC ae so it drops the frame.

You could confirm this by changing the MAC of the bridge manually (ip link set dev br0 address <MAC>), first to the ae MAC and seeing if your "working" interface switches from eth2 to eth1, then to some new random MAC and seeing if neither interface forwards traffic.

Improve this answer
1
  • This is not exactly a case if I change MAC not to belong to either interface I still see packets going out from eth2: [root@daemonhouse ~]# tcpdump -X -vvv -ni eth2 host 10.0.1.101 tcpdump: WARNING: eth2: no IPv4 address assigned tcpdump: listening on eth2, link-type EN10MB (Ethernet), capture size 65535 bytes 19:58:17.421134 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 10.0.1.101 tell 10.0.0.1, length 28 0x0000: 0001 0800 0604 0001 0024 cafe babe 0a00 .........$...... 0x0010: 0001 0000 0000 0000 0a00 0165 ...........e - mac is set to 00:24:ca:fe:ba:be Commented May 24, 2013 at 12:46

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.