|
This is for the HOWTO, any comments, clarifications, additions?
can someone answer my questions - they're on lines starting with
"->"
Thanks Joe
The director sits between 2 networks, the realserver network and the
outside world.
Bridging has been proposed several times on the list for the director.
Currently there is no obvious way to use bridging on the director, or
no-one has rewritten the bridging code to make it useful for a director.
Here's a summary of bridging as it relates to LVS directors.
A bridge is a layer-2 device for connecting 2 physically separate networks.
Being a layer-2 device, a bridge only looks at the MAC addresses on a packet.
The bridge doesn't look at the IPs and has no information about routing
at the IP level. Here's a bridge with 2 NICs connecting 2 networks.
<verb>
network A
-------------------------------
|
|
| eth0
-------------
| |
| bridge |
| |
-------------
| eth1
|
|
--------------------------------
network B
</verb>
In one implementation (the transparent bridge) the bridge determines
the network location of hosts by inspecting the src MAC addresses of
packets.
Since the bridge only inspects the MAC addresses on packets, the IPs
on the hosts in network
A and network B, can belong to the same or different IP networks/netmasks.
A bridge can be used to separate traffic. If all hosts are on 192.168.1.0/24
but most of the packets are passed between 2 hosts, these two hosts
can be put on one of the networks and the rest on the other network.
At the same time the bridge connects separate networks, without adding
route table entries on the hosts in the two networks.
So bridging allows connection of different physical networks without
requiring route entries (needed if a router had been used instead),
but keeps the traffic off networks that don't need to hear them.
About transparent bridging from the howstuffworks site
http://www.howstuffworks.com/lan-switch4.htm
and from cisco (including an explanation of the spanning tree algorithm)
http://www.cisco.com/univercd/cc/td/doc/cisintwk/ito_doc/transbdg.htm
About bridging from the internet encyclopedia at freesoft
www.freesoft.org/CIE/Topics/30.htm
transparent proxy with bridging from the Transparent Proxy with Linux and Squid
mini-HOWTO
http://www.tldp.org/HOWTO/mini/TransparentProxy-7.html
In Linux, bridging is implemented by proxy-arp and called pseudo bridging
http://www.tldp.org/HOWTO/Adv-Routing-HOWTO-16.html (from the Advanced Routing
HOWTO).
Packets passed by earlier implementations of proxy-arp are not seen by iptables
and
can't be filtered.
->(Does this help for the director?)
Here's some more on proxy-arp.
http://www.sjdjweis.com/linux/proxyarp/
With proxy-arp running on the setup above, eth1 would be configured to reply to
arp
requests for an IP on network A allowing packets from network B to be sent to
that
host on network A.
The difference between bridging with Linux and bridging with dedicated layer-2
hardware is that Linux acts at the IP and higher layers.
What happens is kernel version and implementation dependent and it not well
controlled.
Initially I thought that bridging could be used to send packets through the
director to 0/0 from a realserver in LVS-DR, thus solving the
<ref id="martian" name="martian problem">. Julian told me that
the packets would still be seen by the upper layers and the packets
would still be seen as martians.
Then Kate (aka John Looney) asked if bridging could be used to put a director
infront of a functioning server, to make an LVS, without breaking service
to the clients accessing that server.
<quote>John P. Looney 18 Apr 2002<p>
The director is configured to listen for the IPs of the real servers at
the internal side of the network bridge, and pass them on, with some
intelligence.
<verb>
RS1 RS2 RS3
| | |
\--------------/
|
DR/Bridge
|
router
|
Clients
RS1=original webserver (ip 293.2.2.1/26)
RS2=new webserver (ip 293.2.2.2/26)
RS3=new webserver (ip 293.2.2.3/26)
DR =Director (ip 293.2.2.4/26)
router (ip 293.2.2.63/26 and 293.2.3.63/26)
</verb>
Note the router is not on the same physical network as the realservers,
but is on the same logical network.
So, when a connection comes in for RS1 (293.2.2.1), the router sends out an ARP
request. The DR answers with it's own MAC, and transparently forwards all
</quote>
Julian Anastasov <tt/ja@xxxxxx/ 18 Apr 2002
not with the director's MAC when bridging
is used.
<quote>
connections on to RS1/RS2/RS3 depending on it's load balancing algorithm.
The real servers still have their gateway set to be the router.
</quote>
By using the bridging code you have to stick with the
following rules:
<enum>
<item>it is Layer 2, i.e. the decisions to do something with the packet
are based entirely on the link layer protocol info (until you
patch the code, of course)
<item>at link layer level we have broadcast/multicast/unicast addresses
<item>all received non-unicast frames are passed to the IP stack and to all
other bridge ports
<item>all unicast frames are passed to the IP stack or to the
appropriate bridge port according to the destination link layer
address
<item>Linux IP does not accept packets destined to foreign lladdr
->Julian, is the lladdr==MAC for ethernet?
<item>Linux does not send ICMP replies for frames not destined to
our lladdr (one of the reasons not to see ICMP errors against
UDP broadcsts, for example, for missing listener)
<item>Linux TCP accepts frames destined only to our lladdr
<item>Linux does not forward packets not destined to our lladdr
</enum>
To put this in the LVS space (we assume the Director is using
bridging and is between the uplink router and the real servers):
- according to (3) we can't stop the broadcast ARPs reaching
the real servers and they to reply to the requestor (the router),
<em>i.e.</em> we can't avoid the ARP problem for DR and TUN methods.
- according to (4) the real servers can reach the router directly
without disturbing the director's rp_filter. As result, the bridging
helps the director to pass the LVS-DR replies from the real servers
to the uplink router
- the uplink router sees one LAN because the bridging code passes
all frames preserving the original source link layer addresses
We can say that the default bridging behavior is not
the desired one for all cases. There are some useful modes we
can require from the bridging. For example, in one mode we can
grab all IP packets (even packets destined to foreign lladdrs)
and to feed them to the upper layers and to rely on the proper
routing rules for filtering, etc. The bonus is that you don't need
to place your IPs, routes, etc on the bridging interfaces, you don't
need to implement firewalling specificaly designed for the
bridged ports, etc, etc.
--
Joseph Mack PhD, Senior Systems Engineer, Lockheed Martin
contractor to the National Environmental Supercomputer Center,
mailto:mack.joseph@xxxxxxx ph# 919-541-0007, RTP, NC, USA
|
