Hi all,
You'll have to excuse me if i'm replicating questions asked before;
i've googled till I died and couldn't find anything on the list archives
on this subject.
I'm having a little problem with my bridge and its interaction with a
'Windows Load Balanced Server' (whoopee, guess where the problem
lies ;) ). To give a little background, we've got a windows server
hosted on a bridged lan behind our linux firewall (kern: 2.4.21). The ip
of the server itself is an alias shared by 3 load balanced windows
machines.
The symptoms of our problem are that incoming web traffic to our
firewall is being dnatted to the internal ip and that traffic is being
passed out of all the bridged interfaces. This is happening because the
bridge does not have a mac address nextentry for what the kernel
believes is the mac address of that machine. The bridge doesn't have a
mac address for it because when our box makes an arp request for the ip
address, all three windows servers' reply at the same time, with the
same arp layer address, but with differing ether addresses; e.g.
1 0.000000 00:50:c2:11:34:9d -> ARP Who has 10.0.0.21? Tell
10.0.0.1
2 0.000108 00:08:02:a1:e6:a1 -> ARP 10.0.0.21 is at
03:bf:0a:00:00:15
3 0.000112 00:08:02:47:be:16 -> ARP 10.0.0.21 is at
03:bf:0a:00:00:15
4 0.000136 00:02:a5:eb:f8:45 -> ARP 10.0.0.21 is at
03:bf:0a:00:00:15
This seems to confuse the bridge somewhat (at least it seems that way to
me, but could be the intended behaviour); as the bridge updates it's arp
tables with the ether source addresses ('pointing' to the correct
physical interface); yet the kernel arp tables contain the arp layer
address (03:bf) 'pointing' to the bridge; e.g:
# brctl showmacs br0
port no mac addr is local? ageing timer
2 00:02:a5:eb:f8:45 no 0.15
2 00:08:02:a1:e6:a1 no 0.12
2 00:08:02:47:be:16 no 0.01
# arp -n
Address HWtype HWaddress Flags Mask Iface
10.0.0.21 ether 03:BF:0A:00:00:15 C br0
As I see it:
When packets are dnatted to the internal ip, the kernel modifies the
destination ip and ethernet address of the packet to send to 03:bf; it's
then passed to the bridge, the bridge can't correlate the 03:bf hardware
address with any particular interface, fails 'open' and sends the frame
out of all the interfaces on the bridge (to the 03:bf ether address).
I think quite obviously, this is the fault of the windows machines
replying in unison with differing ether addresses to arp addresses, but
I was wondering if there was a way to workaround the problem (and moving
away from windows isn't a solution, at least for our client).
The most obvious method I could see is to set a static mac addr entry
for the offending 03:bf address out of the right interface in the
forwarding database; yet I'm unable to find any documentation on how to
do so.
I've gone so far to look at the bridge-utils and kernel bridging code
but alas, could not find that particular functionality; though the
presence of is_static in the forwarding database (struct
net_bridge_fdb_entry) would lead me to believe maybe it's is possible??.
So I ask, whether there is such functionality, if so how so; or if not
has anyone got any good ideas... (doing it this way, would be a 'clean'
solution for me; though i'll probably try ebtables as a last resort, if
I can't figure this out).
Thanks in advance,
Matt
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url :
http://lists.linux-foundation.org/pipermail/bridge/attachments/20040514/e6c4926b/attachment.pgp
On Fri, 14 May 2004 15:35:29 +0100 Matthew Hall <matt@ecsc.co.uk> wrote:> Hi all, > You'll have to excuse me if i'm replicating questions asked before; > i've googled till I died and couldn't find anything on the list archives > on this subject. > > I'm having a little problem with my bridge and its interaction with a > 'Windows Load Balanced Server' (whoopee, guess where the problem > lies ;) ). To give a little background, we've got a windows server > hosted on a bridged lan behind our linux firewall (kern: 2.4.21). The ip > of the server itself is an alias shared by 3 load balanced windows > machines. > The symptoms of our problem are that incoming web traffic to our > firewall is being dnatted to the internal ip and that traffic is being > passed out of all the bridged interfaces. This is happening because the > bridge does not have a mac address nextentry for what the kernel > believes is the mac address of that machine. The bridge doesn't have a > mac address for it because when our box makes an arp request for the ip > address, all three windows servers' reply at the same time, with the > same arp layer address, but with differing ether addresses; e.g. > > 1 0.000000 00:50:c2:11:34:9d -> ARP Who has 10.0.0.21? Tell 10.0.0.1 > 2 0.000108 00:08:02:a1:e6:a1 -> ARP 10.0.0.21 is at 03:bf:0a:00:00:15 > 3 0.000112 00:08:02:47:be:16 -> ARP 10.0.0.21 is at 03:bf:0a:00:00:15 > 4 0.000136 00:02:a5:eb:f8:45 -> ARP 10.0.0.21 is at 03:bf:0a:00:00:15 > > This seems to confuse the bridge somewhat (at least it seems that way to > me, but could be the intended behaviour); as the bridge updates it's arp > tables with the ether source addresses ('pointing' to the correct > physical interface); yet the kernel arp tables contain the arp layer > address (03:bf) 'pointing' to the bridge; e.g: > > # brctl showmacs br0 > port no mac addr is local? ageing timer > 2 00:02:a5:eb:f8:45 no 0.15 > 2 00:08:02:a1:e6:a1 no 0.12 > 2 00:08:02:47:be:16 no 0.01 > > # arp -n > Address HWtype HWaddress Flags Mask Iface > 10.0.0.21 ether 03:BF:0A:00:00:15 C br0 > > > As I see it: > When packets are dnatted to the internal ip, the kernel modifies the > destination ip and ethernet address of the packet to send to 03:bf; it's > then passed to the bridge, the bridge can't correlate the 03:bf hardware > address with any particular interface, fails 'open' and sends the frame > out of all the interfaces on the bridge (to the 03:bf ether address). > > I think quite obviously, this is the fault of the windows machines > replying in unison with differing ether addresses to arp addresses, but > I was wondering if there was a way to workaround the problem (and moving > away from windows isn't a solution, at least for our client). > > > The most obvious method I could see is to set a static mac addr entry > for the offending 03:bf address out of the right interface in the > forwarding database; yet I'm unable to find any documentation on how to > do so. > I've gone so far to look at the bridge-utils and kernel bridging code > but alas, could not find that particular functionality; though the > presence of is_static in the forwarding database (struct > net_bridge_fdb_entry) would lead me to believe maybe it's is possible??. > So I ask, whether there is such functionality, if so how so; or if not > has anyone got any good ideas... (doing it this way, would be a 'clean' > solution for me; though i'll probably try ebtables as a last resort, if > I can't figure this out). > > Thanks in advance, > Matt >What is the (pseudo) hardware address of the bridge (ie ifconfig br0)? Also, how is IP setup on the linux box. You need to assign an IP address to the bridge (br0) and not to the the ethernet ports (eth0,eth1,eth2...)
As you deduced, the way the MS load balancer works is to have a single IP address mapped to a multicast address. Then when a TCP connection starts it responds with an ARP packet to redirect traffic from that host.> When packets are dnatted to the internal ip, the kernel modifies the > destination ip and ethernet address of the packet to send to 03:bf; it's > then passed to the bridge, the bridge can't correlate the 03:bf hardware > address with any particular interface, fails 'open' and sends the frame > out of all the interfaces on the bridge (to the 03:bf ether address).Since it is a multicast address, it isn't bound to any particular interface. The simplest fix would be to just add filtering rule to block that address leaking back out other interfaces.