Advanced
Mailing List Archive

Mailing List Archive

  1. Home >
  2. Linux Virtual Server>
  3. Users
icmp-redirects, hung connection, tcpdump
justin at mail
Jan 11, 2001, 3:10 PM
Post #1 of 19 (4724 views)
Permalink
Well, after a couple days of investigation I have found lots of little
problems with my LVS:

1 firewall with NAT (FW)
1 LVS box with NAT (LB)
1 real server (RS)

FW:
eth2: 4.18.45.98
eth1: 192.168.0.254
eth1:0: 192.168.1.1

LVS:
eth0: 192.168.0.34
eth0:0: 192.168.1.2

RS:
eth0: 192.168.0.135

A common wire connects FW:eth1, LVS and RS.

So, a packet shows up at 4.18.45.98:80. It gets rewritten for dest
192.168.1.2:80 by FW. LVS receives it and it's rewritten for dest
192.168.0.135:80. Then RS receives it and responds. Soon after this, LVS
decides 'RS should just talk to FW directly' and issues an ICMP-REDIRECT.
Arrgghh.
I read the HOWTO and it says 'I think because the director is a NAT box,
icmp redirects are off.' I'm thinking maybe I turned on some kernel option
when compiling (I've got 2.2.18 with the DEC 30 1.0.3 patch) like 'Optimize
as router not host...?'
In section 9.5 of the HOWTO it says 'For 2.2.13 the ipvs patch handles this
[icmp redirect problem].' This doesn't appear to be the case.
Fortunately!, since I'm not using the config. scripts, I found the line in
the HOWTO that indicates how to disable the icmp-redirect syndrome on the
director:
echo 0 > /proc/sys/net/ipv4/conf/eth0/send_redirects

However, even after this was done, my director was still sending out
ICMP-redirects...?!
Another question: one test client is at IP 192.168.1.3, on the same wire as
everything else. When the RS arps for the address 192.168.1.3, it gets a
reply from my client. Is it then ignoring the default gw (LVS:192.168.0.34)
and just trying to respond directly to the client? According to the HOWTO
this shouldn't happen, but I can't think of any other reason why my
connection is hanging. Unfortunately, the version of tcpdump that I have
(default one with RedHat 6.2) _doesn't_ print out both MACs with the -e
option (supposed to print link-level data). It only prints one full MAC, and
then either 0:0:0:0:0:0 or 0:0:0:0:0:1 for the other. Is this some kind of
shorthand? Seems like a bug...?

... Well, I downloaded the latest tcpdump (v3.6.1, RedHat's is 3.4):
www.tcpdump.org

It fixes the -e problem.

Rather than testing my local (same wire) client, I then tested with an
outside client (OC). Indeed, the ICMP-redirects are taking place, _and_ the
RS is paying attention to them:

OC
|
FW
|
---LVS
|
---RS

1. OC Syn
2. RS Syn/Ack
3. LVS ICMP-Redir; this first one appears not to take immediate effect, thus
I get a successful connection
4. OC Ack
I then simply close the telnet connection from the OC.
5. OC Fin/Ack
6. RS Ack
7. LVS ICMP-Redir; this one does the damage
8. RS Fin to FW MAC (instead of LVS MAC)
9. FW Reset to RS

As you can see, either the first or 2nd redirect is causing the RS to try to
FIN the connection with the FW rather than the LVS. Grrrr.
Is there any way to stop this madness without resorting to two NICs on my
LVS? Two NICs is no problem, but the HOWTO states this is not necessary...

If anyone has similar experience/fixes please respond!
Thanks for all your help!
Justin
Re: icmp-redirects, hung connection, tcpdump [ In reply to ]
michael_e_brown at dell
Jan 11, 2001, 3:29 PM
Post #2 of 19 (4657 views)
Permalink
On Thu, 11 Jan 2001, Justin M. Mahoney wrote:

> in the HOWTO that indicates how to disable the icmp-redirect syndrome on
> the director:
> echo 0 > /proc/sys/net/ipv4/conf/eth0/send_redirects
>
Add
echo 0 > /proc/sys/net/ipv4/conf/all/send_redirects
echo 0 > /proc/sys/net/ipv4/conf/default/send_redirects
before the above line
RE: icmp-redirects, hung connection, tcpdump [ In reply to ]
justin at mail
Jan 11, 2001, 3:59 PM
Post #3 of 19 (4663 views)
Permalink
HECK YEAH!

> echo 0 > /proc/sys/net/ipv4/conf/all/send_redirects

This indeed worked.
Thank you so much, long live Linux, this is the greatest day I've had this
week!
I've been spending _days_ trying to get this thing working. It's been a
rather expensive venture for my company, but I'm willing to do it in order
to PROVE that Linux can replace those overpriced F5/Cisco/Alteon routers.
Hallelujah and hail to the king baby ---> Linux.
:)
Justin

-----Original Message-----
From: Julian Anastasov [mailto:ja@ssi.bg]
Sent: Thursday, January 11, 2001 4:47 PM
To: Justin M. Mahoney
Cc: lvs-users@LinuxVirtualServer.org
Subject: Re: icmp-redirects, hung connection, tcpdump



Hello,

On Thu, 11 Jan 2001, Justin M. Mahoney wrote:

> echo 0 > /proc/sys/net/ipv4/conf/eth0/send_redirects

You need two lines, the missing one is:

echo 0 > /proc/sys/net/ipv4/conf/all/send_redirects

Regards

--
Julian Anastasov <ja@ssi.bg>
Re: icmp-redirects, hung connection, tcpdump [ In reply to ]
ja at ssi
Jan 11, 2001, 5:47 PM
Post #4 of 19 (4660 views)
Permalink
Hello,

On Thu, 11 Jan 2001, Justin M. Mahoney wrote:

> echo 0 > /proc/sys/net/ipv4/conf/eth0/send_redirects

You need two lines, the missing one is:

echo 0 > /proc/sys/net/ipv4/conf/all/send_redirects

> However, even after this was done, my director was still sending out
> ICMP-redirects...?!
> Another question: one test client is at IP 192.168.1.3, on the same wire as
> everything else. When the RS arps for the address 192.168.1.3, it gets a
> reply from my client. Is it then ignoring the default gw (LVS:192.168.0.34)
> and just trying to respond directly to the client? According to the HOWTO
> this shouldn't happen, but I can't think of any other reason why my

Your RS ARPs for 192.168.1.3 because the LVS box redirects it
to this address. The HOWTO is not correct. LVS handles correctly the
ICMP messages related to existing connections but the ICMP redirect
problem is an ipchains-routing problem and it is still _not_ fixed.
This is only a masquerading problem. The dumb nat handles it correctly.
And I don't see an easy fix. The simple solution is the above two
commands.

> Is there any way to stop this madness without resorting to two NICs on my
> LVS? Two NICs is no problem, but the HOWTO states this is not necessary...

IMO, the HOWTO should be fixed.

> If anyone has similar experience/fixes please respond!

I don't have problems using one NIC with masquerading. The trick
is both ends not to have direct routes (not to share same logical
networks), the routes must point to the masq box.

> Thanks for all your help!
> Justin


Regards

--
Julian Anastasov <ja@ssi.bg>
Re: icmp-redirects, hung connection, tcpdump [ In reply to ]
idf at weewannabe
Jan 11, 2001, 7:38 PM
Post #5 of 19 (4660 views)
Permalink
>...It's been a
> rather expensive venture for my company, but I'm willing to do it in order
> to PROVE that Linux can replace those overpriced F5/Cisco/Alteon routers.
> Hallelujah and hail to the king baby ---> Linux.

I am a complete LVS newbie.

Is this really a realistic assesment, or just overjoy ?

Are there any comparitive white papers on LVS versus the "competition."

Regards,

Ivan
Re: icmp-redirects, hung connection, tcpdump [ In reply to ]
lorn_kay at hotmail
Jan 11, 2001, 10:30 PM
Post #6 of 19 (4663 views)
Permalink
>From: "Ivan Figueredo" > > Hallelujah and hail to the king baby ---> Linux. > >I am a complete LVS newbie. > >Is this really a realistic assesment, or just overjoy ?

No this is an acurate statement :-)

>Are there any comparitive white papers on LVS versus the "competition." There has been some discussion on the list, check out this search on WLBS: http://marc.theaimsgroup.com/?l=linux-virtual-server&w=2&r=1&s=WLBS&q=b"]http://marc.theaimsgroup.com/?l=linux-virtual-server&w=2&r=1&s=WLBS&q=b WLBS link: http://www.microsoft.com/ntserver/ntserverenterprise/exec/feature/WLBS/"]http://www.microsoft.com/ntserver/ntserverenterprise/exec/feature/WLBS/ Linux + LVS + Apache = a FREE, powerful, fault-tolerant, scalable Web Server solution. You just have to sacrifice some of the time you are now spending trying to understand the Microsoft Licensing agreements and use it instead on developing a Linux solution that does exactly what you want. :-) --K
Get your FREE download of MSN Explorer at http://explorer.msn.com"]http://explorer.msn.com
Re: icmp-redirects, hung connection, tcpdump [ In reply to ]
mack at ncifcrf
Jan 12, 2001, 6:51 AM
Post #7 of 19 (4655 views)
Permalink
echo 0 > /proc/sys/net/ipv4/conf/all/send_redirects
echo 0 > /proc/sys/net/ipv4/conf/default/send_redirects
echo 0 > /proc/sys/net/ipv4/conf/eth0/send_redirects

> Your RS ARPs for 192.168.1.3 because the LVS box redirects it
> to this address. The HOWTO is not correct.

My understanding was that icmp redirects were handled with LVS for 2.2.12.
I take it that this is not correct. The redirects are not handled and
the director needs these three lines when configuring VS-NAT for all
kernels.

Do I have it now?

Joe

--
Joseph Mack mack@ncifcrf.gov
Re: icmp-redirects, hung connection, tcpdump [ In reply to ]
mack at ncifcrf
Jan 12, 2001, 6:56 AM
Post #8 of 19 (4657 views)
Permalink
> This is only a masquerading problem.

hmm. You only need to handle redirects for VS-NAT and not for VS-DR and
VS-Tun?

Joe

--
Joseph Mack mack@ncifcrf.gov
Re: icmp-redirects, hung connection, tcpdump [ In reply to ]
michael_e_brown at dell
Jan 12, 2001, 11:59 AM
Post #9 of 19 (4658 views)
Permalink
On Fri, 12 Jan 2001, Julian Anastasov wrote:
>
> Yes, if all/send_redirects is 1 every <device>/send_redirects
> is ignored. So, if we leave it 1 redirects are sent. To stop them we
> need all=0 && <device>=0. default/send_redirects is the value that will
> be inherited from each new interface that is created.


How about a patch to the HOWTO? This way, the unwary cannot get into
trouble...

--- LVS-HOWTO-991205 Thu Jan 11 16:31:25 2001
+++ LVS-HOWTO-MEB Fri Jan 12 12:58:01 2001
@@ -9,6 +9,7 @@
v0.7 1 Dec 99, fixes to "arp problem" write up
(no updates needed for LVS v0.9.5, 29Nov99 release)
v0.8 3 Dec 99, Horms' method added for VS-DR
+v0.8.1 12 Jan 01 mebrown added info for conf/all/send_redirects

comments/feedback/fixes/contributions to Joe

@@ -4875,6 +4876,8 @@
The configure.pl script turns off icmp redirects on the director
using sysctl

+ echo 0 > /proc/sys/net/ipv4/conf/all/send_redirects
+ echo 0 > /proc/sys/net/ipv4/conf/default/send_redirects
echo 0 > /proc/sys/net/ipv4/conf/eth0/send_redirects
)
Re: icmp-redirects, hung connection, tcpdump [ In reply to ]
mack at ncifcrf
Jan 12, 2001, 12:54 PM
Post #10 of 19 (4658 views)
Permalink
On Fri, 12 Jan 2001, Julian Anastasov wrote:

> > Do I have it now?
>
> Yes, if all/send_redirects is 1 every <device>/send_redirects

thanks will put it in the HOWTO

Joe
--
Joseph Mack mack@ncifcrf.gov
Re: icmp-redirects, hung connection, tcpdump [ In reply to ]
ja at ssi
Jan 12, 2001, 1:41 PM
Post #11 of 19 (4661 views)
Permalink
Hello,

On Fri, 12 Jan 2001, Joseph Mack wrote:

>
> echo 0 > /proc/sys/net/ipv4/conf/all/send_redirects
> echo 0 > /proc/sys/net/ipv4/conf/default/send_redirects
> echo 0 > /proc/sys/net/ipv4/conf/eth0/send_redirects
>
> > Your RS ARPs for 192.168.1.3 because the LVS box redirects it
> > to this address. The HOWTO is not correct.
>
> My understanding was that icmp redirects were handled with LVS for 2.2.12.
> I take it that this is not correct. The redirects are not handled and
> the director needs these three lines when configuring VS-NAT for all
> kernels.

The redirects are handled in net/ipv4/route.c:ip_route_input_slow(),
i.e. from the routing and before reaching LVS (in LOCAL_IN):

if (out_dev == in_dev && err && !(flags&(RTCF_NAT|RTCF_MASQ)) &&
(IN_DEV_SHARED_MEDIA(out_dev)
|| inet_addr_onlink(out_dev, saddr, FIB_RES_GW(res))))
flags |= RTCF_DOREDIRECT;

Here RTCF_NAT && RTCF_MASQ are flags used from the dumb nat code
but the masquerading defined with ipchains -j MASQ does not set such
or some of these flags. The result: the redirect is sent according to
the conf/{all,<device>}/send_redirects from ip_rt_send_redirect() and
ip_forward() from net/ipv4/ip_forward.c. So, the meaning is: if we are
going to forward packet and the in_dev is same as out_dev we redirect
the sender to the directly connected destination which is on the same
shared media. The ipchains code in the FORWARD chain is reached too late
to avoid sending these redirects. They are already sent when the -j MASQ
is detected.

>
> Do I have it now?

Yes, if all/send_redirects is 1 every <device>/send_redirects
is ignored. So, if we leave it 1 redirects are sent. To stop them we
need all=0 && <device>=0. default/send_redirects is the value that will
be inherited from each new interface that is created.

The logical operation between conf/all/<var> and
conf/<device>/<var> is different for each var. The used operation is
specified in /usr/src/linux/include/linux/inetdevice.h

For send_redirects it is '||'. For others, for example for
conf/{all,<device>}/hidden), it is '&&'

So, for the two logical operations we have:

For &&:

all <dev> result
------------------------------
0 0 0
0 1 0
1 0 0
1 1 1

For ||:

all <dev> result
------------------------------
0 0 0
0 1 1
1 0 1
1 1 1


When a new interface is created we have two choices:

1. to set conf/default/<var> to the value that we want each new
created interface to inherit

2. to create the interface in this way:

ifconfig eth0 0.0.0.0 up

and then to set the value before assigning the address:
echo <val> > conf/eth0/<var>
ifconfig eth0 192.168.0.1 up

but this is risky especially for the tunnel devices, for example, if
you want to play with var rp_filter.

For the other devices this is a safe method if there is no
problem with the default value before assigning the IP address. The
first method can be the safest one but you have to be very careful.

> Joe
>
> --
> Joseph Mack mack@ncifcrf.gov


Regards

--
Julian Anastasov <ja@ssi.bg>
Re: icmp-redirects, hung connection, tcpdump [ In reply to ]
ja at ssi
Jan 12, 2001, 2:11 PM
Post #12 of 19 (4664 views)
Permalink
Hello,

On Fri, 12 Jan 2001, Joseph Mack wrote:

>
> > This is only a masquerading problem.
>
> hmm. You only need to handle redirects for VS-NAT and not for VS-DR and
> VS-Tun?

Yes, only for VS-NAT the packets from the real servers hit
the forward chain, i.e. the outgoing packets. VS-DR and VS-TUN
receive packets only to LOCAL_IN, i.e. the FORWARD chain, where the
redirect is sent, is skipped. The incoming packets for LVS/NAT use
ip_route_input() for the forwarding, so they can hit the FORWARD chain
too and to generate ICMP redirects after the packet is translated.
So, the problem always exists for LVS/NAT, for packets in the both
directions because after the packets are translated we always use
ip_forward to send the packets to the both ends.

I'm not sure but may be the old LVS versions used
ip_route_input() to forward the DR traffic to the real servers.
But this was not true for the TUN method. This call to ip_route_input()
can generate ICMP redirects and may be you are right that for the
old LVS versions this is a problem for DR. Looking in the Changelog
it seems this change occured in LVS version 0.9.4, near Linux 2.2.13.
So, in the HOWTO there is something that is true: there is no ICMP
redirect problem for LVS/DR starting from Linux 2.2.13 :) But the
problems remains for LVS/NAT even in the latest kernel. But this
change in LVS is not created to solve the ICMP redirect problem. Yes,
the problem is solved for DR but the goal was to speedup the forwarding
for the DR method by skipping the forward chain. When the forward
chain is skipped the ICMP redirect is not sent.

> Joe
>
> --
> Joseph Mack mack@ncifcrf.gov


Regards

--
Julian Anastasov <ja@ssi.bg>
Re: icmp-redirects, hung connection, tcpdump [ In reply to ]
ja at ssi
Jan 12, 2001, 2:31 PM
Post #13 of 19 (4655 views)
Permalink
Hello,

On Fri, 12 Jan 2001, Michael E Brown wrote:

> On Fri, 12 Jan 2001, Julian Anastasov wrote:
> >
> > Yes, if all/send_redirects is 1 every <device>/send_redirects
> > is ignored. So, if we leave it 1 redirects are sent. To stop them we
> > need all=0 && <device>=0. default/send_redirects is the value that will
> > be inherited from each new interface that is created.
>
>
> How about a patch to the HOWTO? This way, the unwary cannot get into
> trouble...

Yes, may be something like this:

--- LVS_2.2.13-HOWTO.orig Wed Dec 1 05:58:51 1999
+++ LVS_2.2.13-HOWTO Fri Jan 12 21:23:36 2001
@@ -4651,7 +4651,7 @@
doesn't need to pass through a router to reach the LVS, you won't
have such a symptom. :)

-Only when LVS/DR is used and there is only one interface to
+Only when LVS/DR and LVS/NAT are used and there is only one interface to
receive packets for VIP and to connect the real server, there is
a need to suppress the ICMP redirects of the interface.

@@ -4659,8 +4659,13 @@
The configure.pl script turns off icmp redirects on the director
using sysctl

+ echo 0 > /proc/sys/net/ipv4/conf/all/send_redirects
+ echo 0 > /proc/sys/net/ipv4/conf/default/send_redirects
echo 0 > /proc/sys/net/ipv4/conf/eth0/send_redirects
)
+
+Starting from LVS 0.9.4 the ICMP redirect for LVS/DR method is
+suppressed but the problems remains for LVS/NAT.

(Wensong)
In the reverse direction, replies coming back from the realserver


But may be I have an old version of this HOWTO, so please
make another patch from the both pieces. I assume I'm right that the
problem exists for the LVS/NAT method too. May be this needs testing.

> --- LVS-HOWTO-991205 Thu Jan 11 16:31:25 2001
> +++ LVS-HOWTO-MEB Fri Jan 12 12:58:01 2001
> @@ -9,6 +9,7 @@
> v0.7 1 Dec 99, fixes to "arp problem" write up
> (no updates needed for LVS v0.9.5, 29Nov99 release)
> v0.8 3 Dec 99, Horms' method added for VS-DR
> +v0.8.1 12 Jan 01 mebrown added info for conf/all/send_redirects
>
> comments/feedback/fixes/contributions to Joe
>
> @@ -4875,6 +4876,8 @@
> The configure.pl script turns off icmp redirects on the director
> using sysctl
>
> + echo 0 > /proc/sys/net/ipv4/conf/all/send_redirects
> + echo 0 > /proc/sys/net/ipv4/conf/default/send_redirects
> echo 0 > /proc/sys/net/ipv4/conf/eth0/send_redirects
> )


Regards

--
Julian Anastasov <ja@ssi.bg>
Re: icmp-redirects, hung connection, tcpdump [ In reply to ]
mack.joseph at epa
Jan 14, 2001, 10:16 AM
Post #14 of 19 (4654 views)
Permalink
Julian Anastasov wrote:

> I don't have problems using one NIC with masquerading. The trick
> is both ends not to have direct routes (not to share same logical
> networks), the routes must point to the masq box.

About the send-redirects problem again.

(Assuming the client is directly connected
to the director, ie no router between the director and client)...

In the HOWTO I tell people not to set up the real-servers
and client on the same network, to prevent the real-server
connecting directly to the client.

Is this the problem being addressed here? i.e.
so that people can have their real-servers and client on the same network.

Joe
--
Joseph Mack PhD, Senior Systems Engineer, Lockheed Martin
contractor to the National Environmental Supercomputer Center,
mailto:mack.joseph@epa.gov ph# 919-541-0007, RTP, NC, USA
Re: icmp-redirects, hung connection, tcpdump [ In reply to ]
mack.joseph at epa
Jan 14, 2001, 12:14 PM
Post #15 of 19 (4665 views)
Permalink
> > Is this the problem being addressed here? i.e.
> > so that people can have their real-servers and client on the same network.
>
> Yes, I didn't tested this exotic setup with LVS/NAT but
> configurations with masquerading between physically connected (but
> not logically connected) networks works when send_redirects is 0.

OK

thanks Joe

--
Joseph Mack PhD, Senior Systems Engineer, Lockheed Martin
contractor to the National Environmental Supercomputer Center,
mailto:mack.joseph@epa.gov ph# 919-541-0007, RTP, NC, USA
Re: icmp-redirects, hung connection, tcpdump [ In reply to ]
mack at ncifcrf
Jan 14, 2001, 12:25 PM
Post #16 of 19 (4656 views)
Permalink
On Sun, 14 Jan 2001, Julian Anastasov wrote:

> > Is this the problem being addressed here? i.e.
> > so that people can have their real-servers and client on the same network.

hmm, I tested this way back in the stone age of LVS and found that turning
off redirects didn't work (I put it in the HOWTO even). Of course I didn't
record exactly what I did. Maybe I only turned off redirects for each
device, rather than running the separate instructions for all, default and
eth0.

What's the difference between all, default and eth0?

Joe

--
Joseph Mack mack@ncifcrf.gov
Re: icmp-redirects, hung connection, tcpdump [ In reply to ]
ja at ssi
Jan 14, 2001, 1:10 PM
Post #17 of 19 (4656 views)
Permalink
Hello,

On Sun, 14 Jan 2001, Joseph Mack wrote:

> Julian Anastasov wrote:
>
> > I don't have problems using one NIC with masquerading. The trick
> > is both ends not to have direct routes (not to share same logical
> > networks), the routes must point to the masq box.
>
> About the send-redirects problem again.
>
> (Assuming the client is directly connected
> to the director, ie no router between the director and client)...

Yes, physically connected but they don't share logical connection,
i.e. both hosts use the masq box to reach the other end. For example:

MASQ box:
eth0: 10.0.0.1
eth0:0 10.0.0.100 VIP
eth0:1 192.168.0.1
*/send_redirects=0

Real server:
eth0: 192.168.0.2
def gw 192.168.0.1

Client:
eth0: 10.0.0.3

LVS Request:
10.0.0.3 -> 10.0.0.100

>
> In the HOWTO I tell people not to set up the real-servers
> and client on the same network, to prevent the real-server
> connecting directly to the client.

Yes, they don't need LVS/NAT for directors with one interface
but it should work if LVS/DR is not suitable for some user needs.

>
> Is this the problem being addressed here? i.e.
> so that people can have their real-servers and client on the same network.

Yes, I didn't tested this exotic setup with LVS/NAT but
configurations with masquerading between physically connected (but
not logically connected) networks works when send_redirects is 0.

> Joe


Regards

--
Julian Anastasov <ja@ssi.bg>
Re: icmp-redirects, hung connection, tcpdump [ In reply to ]
ja at ssi
Jan 15, 2001, 2:20 AM
Post #18 of 19 (4660 views)
Permalink
Hello,

On Sun, 14 Jan 2001, Joseph Mack wrote:

> On Sun, 14 Jan 2001, Julian Anastasov wrote:
>
> > > Is this the problem being addressed here? i.e.
> > > so that people can have their real-servers and client on the same network.
>
> hmm, I tested this way back in the stone age of LVS and found that turning
> off redirects didn't work (I put it in the HOWTO even). Of course I didn't
> record exactly what I did. Maybe I only turned off redirects for each
> device, rather than running the separate instructions for all, default and
> eth0.
>
> What's the difference between all, default and eth0?

http://marc.theaimsgroup.com/?l=linux-virtual-server&m=97932487110806&w=2

When the kernel needs to check for one feature (send_redirects for
example) it uses such calls: if (IN_DEV_TX_REDIRECTS(in_dev)) ...
These macros are defined in /usr/src/linux/include/linux/inetdevice.h
The macro returns a value using expression from all/<var> and <dev>/<var>
So, these macros check for example for:

all/send_redirects || eth0/send_redirects
or
all/hidden && eth0/hidden

when you create eth0 for first time using ifconfig eth0 ... up
default/send_redirects is copied to eth0/send_redirects from the
kernel, internally. I.e. default/ contains the initial values
the device inherits when it is created. This is the safest way a
device to appear with correct conf/<dev>/ values.

When we put value in all/<var> you can assume that we set the <var>
for all devices in this way:

all/<var> the macro returns:
for && 0 0
for && 1 the value from <dev>/<var>
for || 0 the value from <dev>/<var>
for || 1 1


This scheme allows the different devices to have different values
for their vars. For example, if we set 0 to all/send_redirects, the 3th
line applies to the values, i.e. the result from the macro is the real
value in <dev>/send_redirects. If we set 1 to all/send_redirects
according to the 4th line, the macro always returns 1 regardless
of the <dev>/send_redirects

> Joe
>
> --
> Joseph Mack mack@ncifcrf.gov


Regards

--
Julian Anastasov <ja@ssi.bg>
Re: icmp-redirects, hung connection, tcpdump [ In reply to ]
ja at ssi
Jan 15, 2001, 2:20 AM
Post #19 of 19 (4655 views)
Permalink
Hello,

On Sun, 14 Jan 2001, Joseph Mack wrote:

> On Sun, 14 Jan 2001, Julian Anastasov wrote:
>
> > > Is this the problem being addressed here? i.e.
> > > so that people can have their real-servers and client on the same network.
>
> hmm, I tested this way back in the stone age of LVS and found that turning
> off redirects didn't work (I put it in the HOWTO even). Of course I didn't
> record exactly what I did. Maybe I only turned off redirects for each
> device, rather than running the separate instructions for all, default and
> eth0.
>
> What's the difference between all, default and eth0?

http://marc.theaimsgroup.com/?l=linux-virtual-server&m=97932487110806&w=2

When the kernel needs to check for one feature (send_redirects for
example) it uses such calls: if (IN_DEV_TX_REDIRECTS(in_dev)) ...
These macros are defined in /usr/src/linux/include/linux/inetdevice.h
The macro returns a value using expression from all/<var> and <dev>/<var>
So, these macros check for example for:

all/send_redirects || eth0/send_redirects
or
all/hidden && eth0/hidden

when you create eth0 for first time using ifconfig eth0 ... up
default/send_redirects is copied to eth0/send_redirects from the
kernel, internally. I.e. default/ contains the initial values
the device inherits when it is created. This is the safest way a
device to appear with correct conf/<dev>/ values.

When we put value in all/<var> you can assume that we set the <var>
for all devices in this way:

all/<var> the macro returns:
for && 0 0
for && 1 the value from <dev>/<var>
for || 0 the value from <dev>/<var>
for || 1 1


This scheme allows the different devices to have different values
for their vars. For example, if we set 0 to all/send_redirects, the 3th
line applies to the values, i.e. the result from the macro is the real
value in <dev>/send_redirects. If we set 1 to all/send_redirects
according to the 4th line, the macro always returns 1 regardless
of the <dev>/send_redirects

> Joe
>
> --
> Joseph Mack mack@ncifcrf.gov


Regards

--
Julian Anastasov <ja@ssi.bg>

©2024 GT.net. A Gossamer Threads company.
5th Floor, 455 Granville St., Vancouver, BC V6C 1T1, Canada | Legal