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.

w1nter
  • 21
  • 2
  • 1
    It is supposed to use only one mac. Please post the output of `ip r sh`, `ip link sh` and `brctl show`. – skarap May 23 '13 at 19:19
  • added to original post – w1nter May 23 '13 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). – skarap May 23 '13 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... – w1nter May 23 '13 at 20:02

1 Answers1

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.

suprjami
  • 3,536
  • 21
  • 29
  • 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 – w1nter May 24 '13 at 12:46