|
Hello,
On Thu, 18 Apr 2002, John P. Looney wrote:
> 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.
>
>
> 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)
>
> 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 293.2.2.1, the router sends out an ARP
> request. The DR answers with it's own MAC, and transparently forwards all
The answer is not with the director's MAC when bridging
is used.
> 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. Very cool
> idea. No idea how to do it.
By using the bridging code you have to stick with the
following rules:
1. 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)
2. at link layer level we have broadcast/multicast/unicast addresses
3. all received non-unicast frames are passed to the IP stack and to all
other bridge ports
4. all unicast frames are passed to the IP stack or to the
appropriate bridge port according to the destination link layer
address
5. Linux IP does not accept packets destined to foreign lladdr
6. 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)
7. Linux TCP accepts frames destined only to our lladdr
8. Linux does not forward packets not destined to our lladdr
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 to reach to
the real servers and they to reply to the requestor (the router),
i.e. 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 brX interfaces, you don't
need to implement firewalling specificaly designed for the
bridged ports, etc, etc.
> Kate
Regards
--
Julian Anastasov <ja@xxxxxx>
|
