|
Hello,
On Mon, 13 Aug 2001, Noah Roberts wrote:
> dummy0 is set as noarp VIP on real servers.
> director has two routes to real servers, the world net which it has the VIP
> as its IP, and the LAN which it uses private IPs to talk with the real
> servers.
For the abbreviations:
http://www.linuxvirtualserver.org/Joseph.Mack/HOWTO/LVS-HOWTO-1.html#ss1.3
You have only VIP configured on the director. In most of the cases
this is enough, eg. to accept the incoming traffic from the uplink
router. When you play with the real servers on the same subnet you need
another unique IP (DIP) because the same VIP is locally configured on the
real servers and they treat any packets with saddr=VIP coming from the
director (in fact, from everywhere but the other real servers use their
RIP) as "source martians" - they are dropped.
> The real servers can talk to each other and the router on the world net and
> everyone talks on the LAN.
> The real server can ping the VIP but have no arp entry for it. The
> directory cannot ping either RS and has an (incomplete) arp entry for them
> after.
> Pings go in and out of all machines on all interfaces with that one
> exception....obviously the RS's are pinging their own VIP on the dummy and
> responding to that iface when the director attempts to ping.
> route does not show the dummy iface.
I don't believe the director sends pings. It can't resolve
the RIPs because its packets (the ARP probes "who has RIPx tell VIP") are
silently dropped from the real servers.
> BTW this is direct routing.....
Yes, using hidden feature ...
> Dir---------
> eth0 Link encap:Ethernet HWaddr 00:D0:70:01:40:2C
> inet addr:192.168.5.1 Bcast:192.168.5.255 Mask:255.255.255.0
> eth1 Link encap:Ethernet HWaddr 00:D0:70:01:40:F9
> inet addr:63.225.190.129 Bcast:63.255.255.255
Check the above Bcast.
> Mask:255.255.255.248
> RS1-------
> dummy0 Link encap:Ethernet HWaddr 00:00:00:00:00:00
> inet addr:63.225.190.129 Bcast:63.255.255.255
> Mask:255.255.255.255
> UP BROADCAST RUNNING NOARP MTU:1500 Metric:1
> eth0 Link encap:Ethernet HWaddr 00:A0:C9:89:24:D3
> inet addr:192.168.5.2 Bcast:192.168.5.255 Mask:255.255.255.0
> eth1 Link encap:Ethernet HWaddr 00:D0:B7:1A:BD:AC
> inet addr:63.225.190.131 Bcast:63.255.255.255
> Mask:255.255.255.248
again Bcast
> from director....
> ping -v 63.225.190.131
> PING 63.225.190.131 (63.225.190.131): 56 data bytes
Yes, I can assume that the ARP probes are received in the
real servers but are dropped there.
> --- 63.225.190.131 ping statistics ---
> 10 packets transmitted, 0 packets received, 100% packet loss
>
> new arp entry....
> 63.225.190.131 (incomplete)
> eth1
>
>
> from rs1....
> ping -v 63.225.190.129
> PING 63.225.190.129 (63.225.190.129): 56 data bytes
> 64 bytes from 63.225.190.129: Echo Request
>
> 64 bytes from 63.225.190.129: icmp_seq=0 ttl=255 time=1190.8 ms
> 64 bytes from 63.225.190.129: Echo Request
>
> 64 bytes from 63.225.190.129: icmp_seq=1 ttl=255 time=217.6 ms
> 64 bytes from 63.225.190.129: Echo Request
>
> 64 bytes from 63.225.190.129: icmp_seq=2 ttl=255 time=43.8 ms
>
> --- 63.225.190.129 ping statistics ---
> 3 packets transmitted, 3 packets received, 0% packet loss
> round-trip min/avg/max = 43.8/484.0/1190.8 ms
>
> no new arp entries....nothing for 63.225.190.129.
ping to local address usually succeeds. ARP does not play here.
So, you have to select another IP from 63.225.190.128/29
network as DIP or to switch to another subnet for the LAN talks (and
not to try to ping the external net).
Regards
--
Julian Anastasov <ja@xxxxxx>
|
