public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
* Re: Turning off ARP in linux-2.4.0
@ 2001-01-23  0:50 Bernd Eckenfels
  2001-01-23  9:08 ` Andi Kleen
  0 siblings, 1 reply; 19+ messages in thread
From: Bernd Eckenfels @ 2001-01-23  0:50 UTC (permalink / raw)
  To: linux-kernel

In article <200101222059.MAA04984@tech1.nameservers.com> you wrote:
> Now for the long version of the problem.  I am using the TurboLinux 
> ClusterServer 6.0 product.  This product uses what they refer to as
> an advanced traffic manager that has the ip address of the web site
> aliased to eth0.  Thus this machine arps for the ip address and when it
> gets the http requests, it passes those requests to the nodes which have
> the same ip addressed aliased to their lo interface with arping turned off.

Well, the easises way of course is to have the internal cluster network on
another network card than the external load balancer. This will remove the arp
queries on their interface. But of course the back channel will be a bit more
delayed.

Another option is to ifconfig -arp the eth0 interface. I browsed through the
IPv4 code and did not find any other goto out which can be configured besides
the input FIB, which messing with is a bad thing since it wont accept the
packet at all.

so ifconfig -arp is the only option i could find which will help you. You need
to hardcode the arp entries for the real ip's of those web servers to reach
them.

Greetings
Bernd
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

^ permalink raw reply	[flat|nested] 19+ messages in thread
* Re: Turning off ARP in linux-2.4.0
@ 2001-01-25 11:02 Julian Anastasov
  2001-01-25 17:08 ` Bernd Eckenfels
  0 siblings, 1 reply; 19+ messages in thread
From: Julian Anastasov @ 2001-01-25 11:02 UTC (permalink / raw)
  To: Bernd Eckenfels; +Cc: linux-kernel


	Hello,

On 24 Jan 2001, Bernd Eckenfels wrote:

> > Not in Linux 2.2+, all addresses are replied. -arp only
> > means "don't talk ARP", in our case we talk through eth0, so we don't
> > want to stop it, right?
>
> why not? if you hard wire the MAC Address of your web servers to all other
> hosts (i dont asume you have a lot of them on the high speed cluster
> interconnect network, that would defeat the purpose totally). After all, thats
> what /etc/ethers is for (for ages).

	In the uplink router too if you control it. Don't forget one thing.
We are talking about high availability setups where the director is not
one. There are backup servers too. On failover the VIP is moved. And we
can't always control the uplink router. And very often the incoming traffic
is replied through the same router from the real servers.

> > They come/go from/through eth0. We don't use ifconfig eth0 -arp
>
> why not?

	If you don't like ARP and can alter /etc/ethers on you hosts
you are lucky. I know that you can build working setup in this way ...
until something is broken and you have to change the MAC-IP tables
on failover.

> > Run ifconfig eth0 0.0.0.0 up and you will create connections
> > with saddr=shared_address (hidden=0), even when it is configured
> > on loopback device.
>
> Yes, but why dont you simply assign an ip address to eth0? It wont change the
> situation if you turn ARP off. And the answer to an incoming packet will
> always use the destination from the request as the source of the response.
> After all you do not open outgoing connections in the cluster mode.

	Hey, the world is not only Linux. Sometimes the people build
clusters using different hardware and software. If your solution works
for your setup we can't claim it is universal.

> >> Well.. another solution would be to use the ipip system instead of the arp
> >> redirection, right?
>
> > No. Forget about the ARP flag. This is not Linux 2.0. The
>
> I was talking about IPIP targeting instead of MAC targeting as an alternative.

	When you send the IPIP datagram again to real server in the
LAN you have the same problem. If you send it to the end of the world
you don't have problems. I was talking about the 1st case. For which
case your are talking about?

> > hidden flag emulates Linux 2.0. In Linux 2.2+ all addresses are reported,
> > with some exceptions: LOOPBACK and MULTICAST. The device type and
> > its ARP flag are not involved in the decision.
>
> We are talking about Linux 2.4 which has the problem not to support that
> stupid hidden stuff. And it is, as i tried to explain not needed if you can do
> -arp. Hey, this was quoted in the manual in the first post.

	You can't always use -arp!!! Read above. Fix the manual! BTW
in this thread I don't see wrong docs. Which ones claim this?

> > The setup (think about a web cluster):
>
> As i described a few posts ago to andi it works with -arp on eth0 instead of
> hidden (after all the original question was a solution to avoid the missing
> hidden syscall)

	-arp can work if you maintain a fresh copy in /etc/ethers and
when you don't use ARP. But then you don't need to set -arp flag. The
setup will work without setting -arp to lo or eth, right? If you don't
use ARP why to stop it in the interface? In theory we will not see any
ARP packets, even from the uplink router.

> > - the real servers ignore/don't reply when the broadcasted
> > probes are for VIP (hidden=1)
> or they dont replay because arp is turned off... see.. its the same solution

	Here is the problem. If the real servers see broadcast ARP
request for a shared address they reply. The ARP flag can't help you.
Send a patch to the docs you read about this solution. It is not working
in Linux 2.2+. You have to stop the ARP probes for shared addresses in all
uplink routers and in all clients on the LAN that can connect to the
cluster VIP, for example for DataBase healthchecks. You can do it with
/etc/ethers analog or using routes.

> > 2. director forwards (after scheduling) the packet to one of the
> > real servers without changing it (this is not a NAT forwarding method)
>
> it is changing the packets MAC destination address (or using an IPIP tunnel).

	Tunnel to where? To real server in the LAN or to another
real server?

> > - the wrong ARP probe (hidden=0)
> > who-has 10.0.0.1 tell 10.0.0.100
>
> it wont. it has turned arp off and it has the address of 10.0.0.1 in the arp
> table (by /etc/ethers).

	Agreed, if you use /etc/ethers

> > Where is the problem:
>
> There is less problems in my setup than in yours.

	You are lucky to use Linux on all hosts. May be you have one
extra uplink router (a Linux box)?

> > About the autoselection. Sometimes it can happen! Addresses
>
> I dont know which auto selection you arer talking about. A tcp socket will
> auto seect the source address if there was no local bind. In that case it will
> ALWAYS use the local address of the device the route to the target is locked
> at. Normally thats the first address of the ethernet card which is connected
> to the default gateway.

	Don't rely on this. Are you sure how the devices are ordered?
Just add a dummy interface and you will see. Put there a shared address
and the fun begins. But again, this is risky but is not fatal. As you
said, you always have eth0 up. Just don't rmmod it.

> > Complex enough?
>
> i think you make yourself problems.

	This is a solution for most of the users. Others, like you, have
simpler solutions. It depends on the setup. If your setup does not require
the hidden feature, very good. But the other users require it.

> > I will not enter in more details here because, I repeat, the setups
> > can be very complex.
>
> I wonder why they get so complicated in the last few month. Somebody is
> overcomplicating it. And as I said and as you can read on your own web page,

	They are not complicated more in 2.4. The current handling in 2.4
is same. I already said that the net maintainers are planning other
features for 2.4 and the hidden feature is not considered. Until then
there is no difference between the kernels and the hidden feature can
be used even in 2.4.

> IPIP is alays available.

	Read this page again. This method has the same problems:

http://www.linuxvirtualserver.org/arp.html

It is named "ARP problem in LVS/TUN and LVS/DR"

> Greetings
> Bernd

BTW, please CC to me!

Regards

--
Julian Anastasov <ja@ssi.bg>

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

^ permalink raw reply	[flat|nested] 19+ messages in thread
* Re: Turning off ARP in linux-2.4.0
@ 2001-01-25  0:19 Julian Anastasov
  0 siblings, 0 replies; 19+ messages in thread
From: Julian Anastasov @ 2001-01-25  0:19 UTC (permalink / raw)
  To: Bernd Eckenfels; +Cc: linux-kernel


	Hello,

On 24 Jan 2001, Bernd Eckenfels wrote:

> > The problem is complex and can't be solved with ifconfig -arp
>
> why?

Search for "arp" in the LVS mailing list:

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

This problem is analyzed from many perspectives. The solution is
in production from 2.2.14+ and 2.3.41+

> > The needs for clusters with shared addresses include:
>
> > 1. block ARP replies for such addresses
>
> -arp will do that

	Not in Linux 2.2+, all addresses are replied. -arp only
means "don't talk ARP", in our case we talk through eth0, so we don't
want to stop it, right? Nobody talks ARP through "lo", why we need to
set -arp in lo, it is -arp by default. lo is only an interface where
we add the shared addresses and it is perfect because we can add
not only shared addresses but also shared networks:

ip addr add VIP_NET/24 dev lo scope host

> > 2. don't announce these addresses in the ARP probes (can be achieved
> > using ip addr add IP brd + dev lo scope host)
>
> i guess -arp will disable neighbour alive probes, too?

	They come/go from/through eth0. We don't use ifconfig eth0 -arp

> > 3. don't autoselect such addresses (for source addresses)
>
> This is not done if you do not use a route through that ip

	Run ifconfig eth0 0.0.0.0 up and you will create connections
with saddr=shared_address (hidden=0), even when it is configured
on loopback device.

> So where is the problem with -arp?
>
> Well.. another solution would be to use the ipip system instead of the arp
> redirection, right?

	No. Forget about the ARP flag. This is not Linux 2.0. The
hidden flag emulates Linux 2.0. In Linux 2.2+ all addresses are reported,
with some exceptions: LOOPBACK and MULTICAST. The device type and
its ARP flag are not involved in the decision. hidden=1 returns the
behaviour to Linux 2.0 for the users that need it but only to specific
devices, i.e. there is control over this feature.

	Here is the ARP problem for shared addresses, described in
all its aspects.

	The setup (think about a web cluster):

- one uplink router
- one director (the only host that advertises the shared address)
- many internal (real servers) that have the same shared address but
it is not advertised (hidden=1)
- one NIC on each host (director, real servers)

	The addresses:

A.B.C.D		client address (CIP), somewhere deeply in 0.0.0.0/0
		or on the same LAN, for example 10.0.0.4
10.0.0.1	uplink router (GIP)
10.0.0.2	director IP (DIP)
10.0.0.3	one of the real servers (RIP)
10.0.0.100	The virtual (shared) IP

	The events:

1.1 the uplink sends ARP probe (when the client is external)

	who-has 10.0.0.100 tell 10.0.0.1

	- only the director replies:

	10.0.0.100 is-at DIP_MAC

	- the real servers ignore/don't reply when the broadcasted
	probes are for VIP (hidden=1)

1.2 the LAN client performs the same actions as the uplink router

2. director forwards (after scheduling) the packet to one of the
real servers without changing it (this is not a NAT forwarding method)

3. the real server delivers locally the traffic with daddr=VIP

4. the real server wants to reply to the client address CIP, so it
resolves its next hop (the uplink router):

	- the wrong ARP probe (hidden=0)
	who-has 10.0.0.1 tell 10.0.0.100
			      ^^^^^^^^^^

	Where is the problem:

	this ARP probe replaces the entry in the uplink router's
	neighbour cache for VIP. So, the uplink router will send
	the next packets not to the director but to the real server.

	- the right ARP probe (hidden=1)
	who-has 10.0.0.1 tell 10.0.0.3
			      ^^^^^^^^

	This probe replaces only the entry for 10.0.0.3 in the uplink
	router (if any exists). It is unique, so there is no problem.

	What we have done: we announced unique address in our ARP
	probe because we don't want to replace the entry for the
	shared address in the receiver.

These were the events that occur in one cluster with shared addresses.

	About the autoselection. Sometimes it can happen! Addresses
even from lo can be selected as source addresses in the outgoing
connections, for example. Are there any restriction for this?
ppp0 is -arp too, why its addresses can be autoselected? The hidden
flag forbids such addresses to be "autoselected" because you can
raise unexpected problems when creating connections from these
addresses. If the other connection end uses ARP probes to resolve
the shared address our connection will be replied through the
director (the host that advertises the shared address). But the
director does not know anything about this newly initiated connection
and the result is only troubles. If you know what are you doing you
can bind to such address, so the restriction is not fatal (should be
if some "smart" applications walk the list with the addresses and
decide to bind to a shared address).

	Complex enough?

So, the "ARP problem" in environment with shared IP addresses can be
formulated in this way:

- block the ARP replies in the hosts that don't advertise the shared
address (the real servers in the cluster). "There must be only one".

- the same hosts can't announce the shared addresses as source for
the ARP probes

- the same hosts better not to allow selecting shared addresses for
innocent outgoing connections


All possibles setups and the problems are explained in the LVS web site:

http://www.linuxvirtualserver.org/

I will not enter in more details here because, I repeat, the setups
can be very complex. The LVS mailing list is open for such discussions.
I know that the net gurus understand the problem and we can't talk
more on this issue. We have an agreement why the hidden feature can't
go so easy in 2.4 as in 2.2.

> Greetings
> Bernd


Regards

--
Julian Anastasov <ja@ssi.bg>

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

^ permalink raw reply	[flat|nested] 19+ messages in thread
* Re: Turning off ARP in linux-2.4.0
@ 2001-01-25  0:08 Bernd Eckenfels
  0 siblings, 0 replies; 19+ messages in thread
From: Bernd Eckenfels @ 2001-01-25  0:08 UTC (permalink / raw)
  To: linux-kernel

In article <Pine.LNX.4.30.0101242303310.956-100000@u.domain.uli> you wrote:
>> -arp will do that

> 	Not in Linux 2.2+, all addresses are replied. -arp only
> means "don't talk ARP", in our case we talk through eth0, so we don't
> want to stop it, right?

why not? if you hard wire the MAC Address of your web servers to all other
hosts (i dont asume you have a lot of them on the high speed cluster
interconnect network, that would defeat the purpose totally). After all, thats
what /etc/ethers is for (for ages).

> 	They come/go from/through eth0. We don't use ifconfig eth0 -arp

why not?

> 	Run ifconfig eth0 0.0.0.0 up and you will create connections
> with saddr=shared_address (hidden=0), even when it is configured
> on loopback device.

Yes, but why dont you simply assign an ip address to eth0? It wont change the
situation if you turn ARP off. And the answer to an incoming packet will
always use the destination from the request as the source of the response.
After all you do not open outgoing connections in the cluster mode.
>>
>> Well.. another solution would be to use the ipip system instead of the arp
>> redirection, right?

> 	No. Forget about the ARP flag. This is not Linux 2.0. The

I was talking about IPIP targeting instead of MAC targeting as an alternative.

> hidden flag emulates Linux 2.0. In Linux 2.2+ all addresses are reported,
> with some exceptions: LOOPBACK and MULTICAST. The device type and
> its ARP flag are not involved in the decision.

We are talking about Linux 2.4 which has the problem not to support that
stupid hidden stuff. And it is, as i tried to explain not needed if you can do
-arp. Hey, this was quoted in the manual in the first post.

> 	The setup (think about a web cluster):

As i described a few posts ago to andi it works with -arp on eth0 instead of
hidden (after all the original question was a solution to avoid the missing
hidden syscall)

> 	- the real servers ignore/don't reply when the broadcasted
> 	probes are for VIP (hidden=1)
or they dont replay because arp is turned off... see.. its the same solution

> 2. director forwards (after scheduling) the packet to one of the
> real servers without changing it (this is not a NAT forwarding method)

it is changing the packets MAC destination address (or using an IPIP tunnel).

> 4. the real server wants to reply to the client address CIP, so it
> resolves its next hop (the uplink router):

> 	- the wrong ARP probe (hidden=0)
> 	who-has 10.0.0.1 tell 10.0.0.100

it wont. it has turned arp off and it has the address of 10.0.0.1 in the arp
table (by /etc/ethers).

> 	Where is the problem:

There is less problems in my setup than in yours.

> 	About the autoselection. Sometimes it can happen! Addresses

I dont know which auto selection you arer talking about. A tcp socket will
auto seect the source address if there was no local bind. In that case it will
ALWAYS use the local address of the device the route to the target is locked
at. Normally thats the first address of the ethernet card which is connected
to the default gateway.

> 	Complex enough?

i think you make yourself problems.

> I will not enter in more details here because, I repeat, the setups
> can be very complex.

I wonder why they get so complicated in the last few month. Somebody is
overcomplicating it. And as I said and as you can read on your own web page,
IPIP is alays available.

Greetings
Bernd
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

^ permalink raw reply	[flat|nested] 19+ messages in thread
* Re: Turning off ARP in linux-2.4.0
@ 2001-01-24  9:21 Julian Anastasov
  2001-01-25  0:30 ` Pete Elton
  0 siblings, 1 reply; 19+ messages in thread
From: Julian Anastasov @ 2001-01-24  9:21 UTC (permalink / raw)
  To: Pete Elton; +Cc: linux-kernel


	Hello,

On 22 Jan 2001, Pete Elton wrote:

> In the 2.2 kernel, I could do the following:
> echo 1 > /proc/sys/net/ipv4/conf/all/hidden
> echo 1 > /proc/sys/net/ipv4/conf/lo/hidden
>
> The 2.4 kernel does not have these sysctl files any more.  Why was
> this functionality taken out?  or was it simply moved to another place
> in the proc filesystem?  How can I accomplish the same thing I was
> doing in the 2.2 kernel in the 2.4 kernel?

	You can use this temporary solution (the same patch ported to
2.3.41+):

http://www.linuxvirtualserver.org/arp.html
http://www.linuxvirtualserver.org/hidden-2.3.41-1.diff

	It is not ported to 2.4 because it touches code in the
IP address autoselection that is in the fast path. This
autoselection code is going to be changed and the required support
can't be ported.

	The problem is complex and can't be solved with ifconfig -arp

	The needs for clusters with shared addresses include:

1. block ARP replies for such addresses
2. don't announce these addresses in the ARP probes (can be achieved
using ip addr add IP brd + dev lo scope host)
3. don't autoselect such addresses (for source addresses)


Regards

--
Julian Anastasov <ja@ssi.bg>

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

^ permalink raw reply	[flat|nested] 19+ messages in thread
* Re: Turning off ARP in linux-2.4.0
@ 2001-01-24  8:32 Bernd Eckenfels
  0 siblings, 0 replies; 19+ messages in thread
From: Bernd Eckenfels @ 2001-01-24  8:32 UTC (permalink / raw)
  To: linux-kernel

In article <Pine.LNX.4.30.0101240857420.1024-100000@u.domain.uli> you wrote:
> 	The problem is complex and can't be solved with ifconfig -arp

why?

> 	The needs for clusters with shared addresses include:

> 1. block ARP replies for such addresses

-arp will do that

> 2. don't announce these addresses in the ARP probes (can be achieved
> using ip addr add IP brd + dev lo scope host)

i guess -arp will disable neighbour alive probes, too?

> 3. don't autoselect such addresses (for source addresses)

This is not done if you do not use a route through that ip

So where is the problem with -arp?

Well.. another solution would be to use the ipip system instead of the arp
redirection, right?

Greetings
Bernd
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

^ permalink raw reply	[flat|nested] 19+ messages in thread
* Re: Turning off ARP in linux-2.4.0
@ 2001-01-24  4:07 Bernd Eckenfels
  0 siblings, 0 replies; 19+ messages in thread
From: Bernd Eckenfels @ 2001-01-24  4:07 UTC (permalink / raw)
  To: linux-kernel

In article <200101240027.QAA14665@tech1.nameservers.com> you wrote:
> So in the setup I have, we have an ATM which gets all incoming requests
> for the web site.  And then we have 7 other machines that get the
> requests passed onto them by the ATM.

You can hardwire the ARP entry of your redirector to your Router. In that case
the router will not ask the shared media about the Owner of the IP.

> Any ideas on how I can turn off the arping? 

why dont u use -arp as you can read it in the manual and as i written in my
post. I dont see a reason why it should not work.

Actually:


calista:/home/ecki# tcpdump -n -e -i eth0 arp &
[1] 26211
calista:/home/ecki# ping 10.0.0.7
PING 10.0.0.7 (10.0.0.7) from 10.0.0.3 : 56(84) bytes of data.
05:05:23.678782 0:0:c0:78:72:df ff:ff:ff:ff:ff:ff 0806 42: arp who-has 10.0.0.7 tell 10.0.0.3

--- 10.0.0.7 ping statistics ---
1 packets transmitted, 0 packets received, 100% packet loss
calista:/home/ecki# 
calista:/home/ecki# 05:05:24.670230 0:0:c0:78:72:df ff:ff:ff:ff:ff:ff 0806 42: arp who-has 10.0.0.7 tell 10.0.0.3

calista:/home/ecki# 05:05:25.670215 0:0:c0:78:72:df ff:ff:ff:ff:ff:ff 0806 42: arp who-has 10.0.0.7 tell 10.0.0.3

calista:/home/ecki# ifconfig eth0 -arp
calista:/home/ecki# 
calista:/home/ecki# ping 10.0.0.9
PING 10.0.0.9 (10.0.0.9) from 10.0.0.3 : 56(84) bytes of data.

--- 10.0.0.9 ping statistics ---
1 packets transmitted, 0 packets received, 100% packet loss
calista:/home/ecki# 

as you can see after using -arp my kernel will no longer issue 3 arp requests
for (not existing in my case) hosts.

And i do habe 2.4.0 with 3com ethernet.

Greetings
Bernd



> -------------------------------------------------------------------------------
>    Achtung: diese Newsgruppe ist eine unidirektional gegatete Mailingliste.
>      Antworten nur per Mail an die im Reply-To-Header angegebene Adresse.
>                    Fragen zum Gateway -> newsmaster@inka.de.
> -------------------------------------------------------------------------------
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

^ permalink raw reply	[flat|nested] 19+ messages in thread
* Re: Turning off ARP in linux-2.4.0
@ 2001-01-24  4:02 Bernd Eckenfels
  0 siblings, 0 replies; 19+ messages in thread
From: Bernd Eckenfels @ 2001-01-24  4:02 UTC (permalink / raw)
  To: linux-kernel

In article <20010124011011.A12252@gruyere.muc.suse.de> you wrote:
> The snippet you posted doesn't describe what ClusterThingy exactly wants
> to do with ARPs. 

Andi, it is simple. There are 3 machines on one net with the same IP Address.
Two of them run a web server and one of them a packet redirector. The packet
redirector will ARP for the address. Receive the packet from the Border router
and put it back on the wire destinated to one of the both other systems. The
other systems will receive it and process it with the OS stack, respond back
to the server. That way the load balancer only needs to pass 2-3 packets for
each http request in usermode to the load balanced servers.

/usr/src/linux-2.4.0/net/ipv4/arp.c

void arp_send(int type, int ptype, u32 dest_ip, 
              struct net_device *dev, u32 src_ip, 
              unsigned char *dest_hw, unsigned char *src_hw,
              unsigned char *target_hw)
{
        struct sk_buff *skb;
        struct arphdr *arp;
        unsigned char *arp_ptr;

        /*
         *      No arp on this interface.
         */
        
        if (dev->flags&IFF_NOARP)
                return;

and


/*
 *      The hardware length of the packet should match the hardware length
 *      of the device.  Similarly, the hardware types should match.  The
 *      device should be ARP-able.  Also, if pln is not 4, then the lookup
 *      is not from an IP number.  We can't currently handle this, so toss
 *      it. 
 */  
        if (in_dev == NULL ||
            arp->ar_hln != dev->addr_len    || 
            dev->flags & IFF_NOARP ||
            skb->pkt_type == PACKET_OTHERHOST ||
            skb->pkt_type == PACKET_LOOPBACK ||
            arp->ar_pln != 4)
                goto out;

Greetings
Bernd
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

^ permalink raw reply	[flat|nested] 19+ messages in thread
* Re: Turning off ARP in linux-2.4.0
@ 2001-01-23 13:19 NDias
  0 siblings, 0 replies; 19+ messages in thread
From: NDias @ 2001-01-23 13:19 UTC (permalink / raw)
  To: elton; +Cc: linux-kernel


I'm very new to this list, and usually lurk for quite awhile before
posting, however I think I can assist here. The 2.4.0 kernel I'm looking at
does give you the option of implementing sysctl support. Please see the
Configure.help in the Documentation section:

Sysctl support
CONFIG_SYSCTL
The sysctl interface provides a means of dynamically changing
certain kernel parameters and variables on the fly without requiring
a recompile of the kernel or reboot of the system. The primary
interface consists of a system call, but if you say Y to "/proc
file system support", a tree of modifiable sysctl entries will be
generated beneath the /proc/sys directory. They are explained in the
files in Documentation/sysctl/. Note that enabling this option will
enlarge the kernel by at least 8 KB.

Hope this helps.

Neal Dias

UNIX Systems Administrator
Sunglass Hut International, MIS Dept.
office: (305) 648-6479
mobile: (786) 368-5742
wk. email: NDias@sunglasshut.com
pvt. email: emperor.1@netzero.net


*******************************************************************************

Whoever fights monsters should see to it that in the process he does not
become a monster. And when you look into an abyss, the abyss also looks
into you. -Nietzsche

Any opinions expressed above or below are entirely my own and may not
reflect those of my employers.

The information contained in this e-mail message is confidential, intended
only for the receipt and use of the individual(s) or entity(s) named above.
If the reader of this email message is not the intended recipient, or the
employee or agent responsible for its delivery to the intended and or
addressed recipient, you are hereby notified that any review,
dissemination, distribution or copying of this communication is strictly
prohibited except at the express consent of its author.






                                                                                                                              
                    Pete Elton                                                                                                
                    <elton@iqs.net>                 To:     linux-kernel@vger.kernel.org                                      
                    Sent by:                        cc:                                                                       
                    linux-kernel-owner@vger.        Subject:     Turning off ARP in linux-2.4.0                               
                    kernel.org                                                                                                
                                                                                                                              
                                                                                                                              
                    01/22/01 03:59 PM                                                                                         
                                                                                                                              
                                                                                                                              




I have searched the previous posts and have not found a solution to
the problem that I am facing.

The short problem is that I need a way to turn off arping for the lo
interface in the 2.4.0 kernel.

In the 2.2 kernel, I could do the following:
echo 1 > /proc/sys/net/ipv4/conf/all/hidden
echo 1 > /proc/sys/net/ipv4/conf/lo/hidden

The 2.4 kernel does not have these sysctl files any more.  Why was
this functionality taken out?  or was it simply moved to another place
in the proc filesystem?  How can I accomplish the same thing I was
doing in the 2.2 kernel in the 2.4 kernel?

Now for the long version of the problem.  I am using the TurboLinux
ClusterServer 6.0 product.  This product uses what they refer to as
an advanced traffic manager that has the ip address of the web site
aliased to eth0.  Thus this machine arps for the ip address and when it
gets the http requests, it passes those requests to the nodes which have
the same ip addressed aliased to their lo interface with arping turned off.

TurboLinux is not helping me with the 2.4 kernel.  I imagine it is because
they know nothing about it and were not planning ahead by following the
development of the 2.3 kernel, so I thought I would ask the guys who really
know what is going on.

I know that you are all very busy, but any help that you can provide
is greatly appreciated.

Pete Elton

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/




-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

^ permalink raw reply	[flat|nested] 19+ messages in thread
* Turning off ARP in linux-2.4.0
@ 2001-01-22 20:59 Pete Elton
  0 siblings, 0 replies; 19+ messages in thread
From: Pete Elton @ 2001-01-22 20:59 UTC (permalink / raw)
  To: linux-kernel


I have searched the previous posts and have not found a solution to 
the problem that I am facing.

The short problem is that I need a way to turn off arping for the lo 
interface in the 2.4.0 kernel.

In the 2.2 kernel, I could do the following:
echo 1 > /proc/sys/net/ipv4/conf/all/hidden 
echo 1 > /proc/sys/net/ipv4/conf/lo/hidden 

The 2.4 kernel does not have these sysctl files any more.  Why was
this functionality taken out?  or was it simply moved to another place
in the proc filesystem?  How can I accomplish the same thing I was
doing in the 2.2 kernel in the 2.4 kernel?  

Now for the long version of the problem.  I am using the TurboLinux 
ClusterServer 6.0 product.  This product uses what they refer to as
an advanced traffic manager that has the ip address of the web site
aliased to eth0.  Thus this machine arps for the ip address and when it
gets the http requests, it passes those requests to the nodes which have
the same ip addressed aliased to their lo interface with arping turned off.

TurboLinux is not helping me with the 2.4 kernel.  I imagine it is because
they know nothing about it and were not planning ahead by following the 
development of the 2.3 kernel, so I thought I would ask the guys who really
know what is going on.

I know that you are all very busy, but any help that you can provide
is greatly appreciated.

Pete Elton

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

^ permalink raw reply	[flat|nested] 19+ messages in thread
end of thread, other threads:[~2001-01-25 21:12 UTC | newest]

Thread overview: 19+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2001-01-23  0:50 Turning off ARP in linux-2.4.0 Bernd Eckenfels
2001-01-23  9:08 ` Andi Kleen
2001-01-23 23:50   ` Pete Elton
2001-01-24  0:10     ` Andi Kleen
2001-01-24  0:27       ` Pete Elton
2001-01-24  0:38         ` Andi Kleen
2001-01-24  0:49           ` Pete Elton
  -- strict thread matches above, loose matches on Subject: below --
2001-01-25 11:02 Julian Anastasov
2001-01-25 17:08 ` Bernd Eckenfels
2001-01-25 23:13   ` Julian Anastasov
2001-01-25  0:19 Julian Anastasov
2001-01-25  0:08 Bernd Eckenfels
2001-01-24  9:21 Julian Anastasov
2001-01-25  0:30 ` Pete Elton
2001-01-24  8:32 Bernd Eckenfels
2001-01-24  4:07 Bernd Eckenfels
2001-01-24  4:02 Bernd Eckenfels
2001-01-23 13:19 NDias
2001-01-22 20:59 Pete Elton

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox