LVS
lvs-users
Google
 
Web LinuxVirtualServer.org

Re: ARP reply control

To: David Osborne <David.Osborne@xxxxxxxxxxxxxxxx>
Subject: Re: ARP reply control
Cc: lvs-users@xxxxxxxxxxxxxxxxxxxxxx
From: Julian Anastasov <ja@xxxxxx>
Date: Mon, 16 Jul 2001 20:04:17 +0300 (EEST)
        Hello,

On Mon, 16 Jul 2001, David Osborne wrote:

> Could someone please outline how to use iproute2 to ensure an LVS
> director with multiple network interfaces only sends ARP replies with
> the MAC address of the interface associated with a service's VIP?
>
> Our main director system usually responds with the MAC address of
> eth0, even for a VIP which is on eth1. It's running kernel 2.4.2 with
> ipvs-0.2.11.

        About the used device: check whether you can switch to using
rp_filter for your devices (all):

echo 1 > /proc/sys/net/ipv4/conf/all/rp_filter
echo 1 > /proc/sys/net/ipv4/conf/eth0/rp_filter
echo 1 > /proc/sys/net/ipv4/conf/eth1/rp_filter

        If not, try the same with "arp_filter".

        In Linux 2.2+ all devices respond to remote ARP probes no
matter the requested address is local or remote. In Linux, by placing
one IP on specific device you can achieve only:

- the IP address to be selected as source in IP talks when the route
through this device does not have preferred source address

- to hide shared address (hidden flag) by placing them on "hidden" device

- better dead gateway detection, for example, if this IP address is used
as gateway from other hosts and the device is marked down:

ifconfig eth0 down

        then the IP address becomes unreachable for the remote ARP probes

        I don't remember for other reasons one to place an IP address
to specific device. So, placing VIP on "unused" eth card (eth1) does
not solve the problem for the announced MAC. All devices reply to all
broadcast ARP probes until some policy is applied:

        by altering the 3 device flag you can tune the ARP behavoir:

rp_filter

        Source spoofing protection for all IP traffic (including ARP)

arp_filter

        Source spoofing protection against the ARP probes only, some
        good side effects for multipath routes

hidden

        Target address checking for the remote ARP probes and some
        control for our probes

> thanks
> --
> David Osborne                         david.osborne@xxxxxxxxxxxxxxxx
> Academic Computing Services     phone/voicemail: +44 (0)115 951 3397
> The University of Nottingham                fax: +44 (0)115 951 3358
> Nottingham NG7 2RD, UK          http://www.nottingham.ac.uk/~cczdao/


Regards

--
Julian Anastasov <ja@xxxxxx>



<Prev in Thread] Current Thread [Next in Thread>