Re: [Bridge] Packet reflection breaks Linux bridge

[Thomas Glanzmann <thomas@glanzmann.de>]

Hello Bart,

> > http://serverfault.com/questions/518254/linux-container-bridge-filters-arp-reply

> The author answered his own question stating it was an issue in his
> network :-)

that is true. 

> ebtables -t nat -A PREROUTING -s 00:50:56:98:12:ed -i eth1 -j DROP
> Use PREROUTING so that the Linux bridge fdb isn't updated.

Thank you a lot for this line. I just tried it and it works:

(miniwheezy64) [~]           ebtables -t nat -A PREROUTING -s 00:50:56:98:12:ed -i eth1 -j DROP
(miniwheezy64) [~] tcpdump -e -n -i vpn ether host 00:50:56:98:12:ed
tcpdump: WARNING: vpn: no IPv4 address assigned
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on vpn, link-type EN10MB (Ethernet), capture size 65535 bytes
05:27:59.786228 00:50:56:98:12:ed > 03:bf:0a:40:67:2a, ethertype IPv4 (0x0800), length 98: 10.64.103.250 > 10.64.103.42: ICMP echo request, id 14490, seq 29, length 64
05:27:59.786768 00:15:5d:b1:45:71 > 00:50:56:98:12:ed, ethertype IPv4 (0x0800), length 98: 10.64.103.42 > 10.64.103.250: ICMP echo reply, id 14490, seq 29, length 64
05:27:59.786787 00:15:5d:67:ac:93 > 00:50:56:98:12:ed, ethertype IPv4 (0x0800), length 98: 10.64.103.42 > 10.64.103.250: ICMP echo reply, id 14490, seq 29, length 64
05:27:59.787041 00:15:5d:67:ab:5f > 00:50:56:98:12:ed, ethertype IPv4 (0x0800), length 98: 10.64.103.42 > 10.64.103.250: ICMP echo reply, id 14490, seq 29, length 64
...

As you can see the system is totally broken. It even sends its unicast packets
three times back. A wonder that anything works in this broadcast domain. And
the MAC is learned on the rigth port:

(miniwheezy64) [~] brctl showmacs br0 | grep -i 00:50:56:98:12:ed
  2     00:50:56:98:12:ed       no                 0.28

> A better solution is probably to fix your network.

I agree. The problem is that it is _not_ _my_ network. I identified two
Microsoft Exchange servers which are part of two different load
balancing clusters running on Hyper-V as the culprit. They do not only
reflect all broadcast packets that they see, but also the unicast
packets. So when I do a unicast connection to them using ICMP or TCP,
all packets get reflected. So what I'm looking for now is a workaround
to carry out the migration. Because of the feedback provided by Michael,
Stephen and you, now I have three:

        - SNAT the broadcast packets that come from the far side of the
          bridge, and SNAT the unicast packets going to the systems
          which do reflect all packages that they can see.

                ebtables -t nat -F
                ebtables -t nat -A POSTROUTING -d ff:ff:ff:ff:ff:ff -o eth1 -j snat --to-source 00:50:56:98:0a:22
                ebtables -t nat -A POSTROUTING -d 03:bf:0a:40:67:80 -o eth1 -j snat --to-source 00:50:56:98:0a:22
                ebtables -t nat -A POSTROUTING -d 03:bf:0a:40:67:2a -o eth1 -j snat --to-source 00:50:56:98:0a:22

        - Use the newest code and pin the mac address of the far side
          machines to the right interface.

        - Use the ebtables PREROUTING statement to filter the packets
          out before they reach the bridge:

          ebtables -t nat -A PREROUTING -s 00:50:56:98:12:ed -i eth1 -j DROP

Far side I call systems behind the OpenVPN bridge on the virtual
network.

I agree that the above is fighting the symptoms and not resolving the
real problem. I don't like that. However I'm not allowed to reconfigure
the Exchange Microsoft Cluster, so I work with that. I have informed the
people reasonable for it and the network administrators and hope that
they take care of the problem.

Cheers,
        Thomas