Re: Turning off ARP in linux-2.4.0
Hello, On Thu, 25 Jan 2001, Bernd Eckenfels wrote: > On Thu, Jan 25, 2001 at 01:02:32PM +0200, Julian Anastasov wrote: > > 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. > > It is a Linux News Group after all. So dont confuse us with Broken Operating > Systems. And of course we don't need a Hidden flag in Linux to solve other > Operating Systems Auto-Binding. I'm talking about ARP. /etc/ethers is outdated. ARP is widely used, especially in environments with many hosts on the LAN, for dynamic setups, etc. And the clusters are not a static configurations. > > 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 Manual is OK. It claims that -arp will work and it claims that on some > Linux Sytems it wont (i am not sure why it should not work on old kernels > but i accept it). It can work only in old kernels. -arp does not work in Linux 2.2+, in the way you want. > > -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. > > I am not sure about this, because of the neighbour alive discovery. I dont > know if a hard wired ARP Address will stop that. If we have static MAC entry in the requestor it is used, no ARP probes are sent. If we receive ARP probes we reply them. > > You are lucky to use Linux on all hosts. May be you have one > > extra uplink router (a Linux box)? > > You can turn off arp discovery on every reasonable pwerfull router. And I > dont see a situation where you want to build a HA/HP Cluster using you ISPs > Router as a core component and the ISP is not cooperating with you. But when VIP is moved on failover I'll need access to this router in the ISP :) So, I'll need one of the following three things: (1) the uplink router password (2) how can I send a page to the ISP admin (3) put own router > > 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. > > There is no hidden Feature in 2.4, thats why we have started the thread. And > for exactly this reason I suggested to use -arp. There is a reason to apply -arp in Linux 2.2+ only to devices that can talk ARP. So, your recommendation in Linux 2.2+ can be formulated in this way: "Use ifconfig eth0 -arp and maintain fresh copy in /etc/ethers on all hosts" :) Your suggestion can be valid may be for Linux 2.0 only (not tested). In 2.2+ altering the arp flag for lo or similar devices connected only to the host system is useless. An evidence for this behavior is the fact that when you try ifconfig lo -arp ifconfig lo:0 A.B.C.D netmask 255.255.255.255 you can ping this address from another host :) It is replied. Yep, I just tried it again in 2.4 for the test :) > Greetings > Bernd Regards -- Julian Anastasov <[EMAIL PROTECTED]> - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Turning off ARP in linux-2.4.0
On Thu, Jan 25, 2001 at 01:02:32PM +0200, Julian Anastasov wrote: > 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. It is a Linux News Group after all. So dont confuse us with Broken Operating Systems. And of course we don't need a Hidden flag in Linux to solve other Operating Systems Auto-Binding. > When you send the IPIP datagram again to real server in the > LAN you have the same problem. Yes, you are right, -arp is needed in that system, too. Or you need WAN Distributed Services. > 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 Manual is OK. It claims that -arp will work and it claims that on some Linux Sytems it wont (i am not sure why it should not work on old kernels but i accept it). > > -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. I am not sure about this, because of the neighbour alive discovery. I dont know if a hard wired ARP Address will stop that. > > 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? To the real server on the LAN, the server is the endpoint. As written in LVS Docs. > You are lucky to use Linux on all hosts. May be you have one > extra uplink router (a Linux box)? You can turn off arp discovery on every reasonable pwerfull router. And I dont see a situation where you want to build a HA/HP Cluster using you ISPs Router as a core component and the ISP is not cooperating with you. > > 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. There is no hidden Feature in 2.4, thats why we have started the thread. And for exactly this reason I suggested to use -arp. Greetings Bernd -- (OO) -- [EMAIL PROTECTED] -- ( .. ) ecki@{inka.de,linux.de,debian.org} http://home.pages.de/~eckes/ o--o *plush* 2048/93600EFD eckes@irc +497257930613 BE5-RIPE (OO) When cryptography is outlawed, bayl bhgynjf jvyy unir cevinpl! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Turning off ARP in linux-2.4.0
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
Re: Turning off ARP in linux-2.4.0
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
Re: Turning off ARP in linux-2.4.0
On Thu, Jan 25, 2001 at 01:02:32PM +0200, Julian Anastasov wrote: 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. It is a Linux News Group after all. So dont confuse us with Broken Operating Systems. And of course we don't need a Hidden flag in Linux to solve other Operating Systems Auto-Binding. When you send the IPIP datagram again to real server in the LAN you have the same problem. Yes, you are right, -arp is needed in that system, too. Or you need WAN Distributed Services. 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 Manual is OK. It claims that -arp will work and it claims that on some Linux Sytems it wont (i am not sure why it should not work on old kernels but i accept it). -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. I am not sure about this, because of the neighbour alive discovery. I dont know if a hard wired ARP Address will stop that. 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? To the real server on the LAN, the server is the endpoint. As written in LVS Docs. You are lucky to use Linux on all hosts. May be you have one extra uplink router (a Linux box)? You can turn off arp discovery on every reasonable pwerfull router. And I dont see a situation where you want to build a HA/HP Cluster using you ISPs Router as a core component and the ISP is not cooperating with you. 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. There is no hidden Feature in 2.4, thats why we have started the thread. And for exactly this reason I suggested to use -arp. Greetings Bernd -- (OO) -- [EMAIL PROTECTED] -- ( .. ) ecki@{inka.de,linux.de,debian.org} http://home.pages.de/~eckes/ o--o *plush* 2048/93600EFD eckes@irc +497257930613 BE5-RIPE (OO) When cryptography is outlawed, bayl bhgynjf jvyy unir cevinpl! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Turning off ARP in linux-2.4.0
Hello, On Thu, 25 Jan 2001, Bernd Eckenfels wrote: On Thu, Jan 25, 2001 at 01:02:32PM +0200, Julian Anastasov wrote: 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. It is a Linux News Group after all. So dont confuse us with Broken Operating Systems. And of course we don't need a Hidden flag in Linux to solve other Operating Systems Auto-Binding. I'm talking about ARP. /etc/ethers is outdated. ARP is widely used, especially in environments with many hosts on the LAN, for dynamic setups, etc. And the clusters are not a static configurations. 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 Manual is OK. It claims that -arp will work and it claims that on some Linux Sytems it wont (i am not sure why it should not work on old kernels but i accept it). It can work only in old kernels. -arp does not work in Linux 2.2+, in the way you want. -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. I am not sure about this, because of the neighbour alive discovery. I dont know if a hard wired ARP Address will stop that. If we have static MAC entry in the requestor it is used, no ARP probes are sent. If we receive ARP probes we reply them. You are lucky to use Linux on all hosts. May be you have one extra uplink router (a Linux box)? You can turn off arp discovery on every reasonable pwerfull router. And I dont see a situation where you want to build a HA/HP Cluster using you ISPs Router as a core component and the ISP is not cooperating with you. But when VIP is moved on failover I'll need access to this router in the ISP :) So, I'll need one of the following three things: (1) the uplink router password (2) how can I send a page to the ISP admin (3) put own router 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. There is no hidden Feature in 2.4, thats why we have started the thread. And for exactly this reason I suggested to use -arp. There is a reason to apply -arp in Linux 2.2+ only to devices that can talk ARP. So, your recommendation in Linux 2.2+ can be formulated in this way: "Use ifconfig eth0 -arp and maintain fresh copy in /etc/ethers on all hosts" :) Your suggestion can be valid may be for Linux 2.0 only (not tested). In 2.2+ altering the arp flag for lo or similar devices connected only to the host system is useless. An evidence for this behavior is the fact that when you try ifconfig lo -arp ifconfig lo:0 A.B.C.D netmask 255.255.255.255 you can ping this address from another host :) It is replied. Yep, I just tried it again in 2.4 for the test :) Greetings Bernd Regards -- Julian Anastasov [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Turning off ARP in linux-2.4.0
> > 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 Thanks for the link to the patch. I was able to get it patched into the 2.4.0 kernel and it worked great. Thanks. Pete - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Turning off ARP in linux-2.4.0
In article <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Turning off ARP in linux-2.4.0
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=1=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.1uplink router (GIP) 10.0.0.2director IP (DIP) 10.0.0.3one 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"
Re: Turning off ARP in linux-2.4.0
In article <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Turning off ARP in linux-2.4.0
In article [EMAIL PROTECTED] 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 [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Turning off ARP in linux-2.4.0
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-serverr=1w=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.1uplink router (GIP) 10.0.0.2director IP (DIP) 10.0.0.3one 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
Re: Turning off ARP in linux-2.4.0
In article [EMAIL PROTECTED] 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 [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Turning off ARP in linux-2.4.0
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 Thanks for the link to the patch. I was able to get it patched into the 2.4.0 kernel and it worked great. Thanks. Pete - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Turning off ARP in linux-2.4.0
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 <[EMAIL PROTECTED]> - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Turning off ARP in linux-2.4.0
In article <[EMAIL PROTECTED]> 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 -> [EMAIL PROTECTED] > --- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Turning off ARP in linux-2.4.0
In article <[EMAIL PROTECTED]> 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_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 [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Turning off ARP in linux-2.4.0
> On Tue, Jan 23, 2001 at 04:27:21PM -0800, Pete Elton wrote: > > Any ideas on how I can turn off the arping? I guess the thing that I > > I explained it in my last mail how to do it using arpfilter. I do not claim > that it is an elegant solution. > It's probably not worse a hack than hidden is in the first place though. I either missed that or did not understand it. I am now rereading your message Is that what you were referring to when you said only try to use policy routing hacks (not tested). e.g. tag all outgoing packets with a specific fwmark that redirects them to a specific routing table which does the real routing, and put no routes into the normal one used by arpfilter so that it doesnt' reply. I am not familiar with policy routing. Could you point me to some docs I could read or maybe even give a trivial example to start me on the right path? > > am most curious about is how it ending up being removed from the kernel > > in the first place. It must have been a decision that someone made. > > Either, we don't need that any more since we can do it this way, or > > we'll take it out since nobody uses it. > > It was only submitted to 2.2 a few months ago (=years after 2.3 branched), b > ut > never added to 2.4. Well that at least makes sense as to why it's not in there. Thank you for all of your help. Pete - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Turning off ARP in linux-2.4.0
On Tue, Jan 23, 2001 at 04:27:21PM -0800, Pete Elton wrote: > Any ideas on how I can turn off the arping? I guess the thing that I I explained it in my last mail how to do it using arpfilter. I do not claim that it is an elegant solution. It's probably not worse a hack than hidden is in the first place though. > am most curious about is how it ending up being removed from the kernel > in the first place. It must have been a decision that someone made. > Either, we don't need that any more since we can do it this way, or > we'll take it out since nobody uses it. It was only submitted to 2.2 a few months ago (=years after 2.3 branched), but never added to 2.4. -Andi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Turning off ARP in linux-2.4.0
> On Tue, Jan 23, 2001 at 03:50:36PM -0800, Pete Elton wrote: > The snippet you posted doesn't describe what ClusterThingy exactly wants > to do with ARPs. Well I think the main difference in what you implemented and what the cluster server thing is doing (I think) is it sounds like you can arp on a specific interface, but for the cluster server software to work, the node cannot arp at all since a separate machine is acting as a redirector and all incoming request go to that server first and are then pasted to a node. (how's that for a run on sentence) Here is what their documentation says about that explicitly. It appears just before the other section I quoted: Creating an alias has one problem: when another system on the network wants to send a packet to the IP address 10.0.0.99 on the same subnet, it sends an ARP broadcast to determine which computer has that IP address. The machine with that IP address is supposed to answer back with its IP address and corresponding MAC (hardware) address. But if all the nodes in the cluster have the same IP address, they are all going to answer this broadcast ARP message. So we have to tell all of the systems except for the primary ATM not to reply to those ARP requests. We want all traffic destined for the cluster to go through the primary ATM first. Part of the solution to this is to create the alias on the loopback interface instead of the Ethernet interface. The loopback interface is a network interface that has no hardware or physical network associated with it. So instead of creating the alias on eth0:1, you would add the alias to the loopback interface (lo) using the following command: # ifconfig lo:1 10.0.0.99 netmask 255.255.255.255 up 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. So only the ATM can ARP for the ip address of the web site. The 7 other servers cannot. So for the 2.2.18 kernel, I have the ipaddress aliased to the lo interface with the hidden sysctrl option set to 1 and everything works. When I try and bring one of the nodes up on the 2.4.0 kernel, I cannot keep it from ARPing so it fights with the ATM for all of the traffic and that causes problems. I hope that this makes more sense. Any ideas on how I can turn off the arping? I guess the thing that I am most curious about is how it ending up being removed from the kernel in the first place. It must have been a decision that someone made. Either, we don't need that any more since we can do it this way, or we'll take it out since nobody uses it. Pete - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Turning off ARP in linux-2.4.0
On Tue, Jan 23, 2001 at 03:50:36PM -0800, Pete Elton wrote: > Is there something that the arp_filter can do that will mirror this > functionality? The modification that you made to the documentation > was pretty straight forward in that the arp_filter was BOOLEAN, so > I think I implemented it right. The snippet you posted doesn't describe what ClusterThingy exactly wants to do with ARPs. Arpfilter was designed for multiple interfaces, to direct ARP replies to specific interfaces based on the routing table. If you have only a single interface and no other way to policy route the packet I think you can only try to use policy routing hacks (not tested). e.g. tag all outgoing packets with a specific fwmark that redirects them to a specific routing table which does the real routing, and put no routes into the normal one used by arpfilter so that it doesnt' reply. Admittedly it's quite a hack. Perhaps Alexey can suggest a better solution, he's the routing/arp guru. I guess it would be easier if arpfilter was able to select a special own routing table, but I was too chicken to implement that. -Andi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Turning off ARP in linux-2.4.0
> On Tue, Jan 23, 2001 at 01:50:27AM +0100, Bernd Eckenfels wrote: > > Another option is to ifconfig -arp the eth0 interface. I browsed through t > he > > IPv4 code and did not find any other goto out which can be configured besi > des > > 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 reac > h > > them. > > -arp means that the kernel will not put in link layer to the packets. > It's probably not what you want. Yes the option is misnamed. > > 2.2 has arpfilter, which will hopefully end up in 2.4 soon too. Here is a > patch. It allows to filter ARP replies based on the routing table. > > > -Andi Thanks for the patches. I patched the kernel and tried it and it still is reponding to arps even after I issued: echo 1 > /proc/sys/net/ipv4/conf/all/arp_filter echo 1 > /proc/sys/net/ipv4/conf/lo/arp_filter I do not know what the hidden interface did exactly and I am still unsure why it no longer shows up in the 2.4.0 kernel. Here is a clip from the TurboLinux ClusterServer manual that explains how to turn off the arping. Maybe it will clear up what I am trying to accomplish: Next you have to turn off ARP replies on the interface. How you accomplish that depends upon which Linux kernel version you are using. On UNIX systems and Linux 2.0 kernels, you can supply the -arp option to the ifconfig command when you bring up the interface. (Note that some UNIX and Linux systems may use a slightly different syntax, such as using noarp instead of -arp.) So in our example, we would use this command to configure the interface: # ifconfig lo:1 10.0.0.99 netmask 255.255.255.255 -arp Unfortunately, this method does not work in any Linux kernels more recent than the 2.0 series. For systems running kernel 2.2.14 and higher the -arp option does not work. Instead, you will have to use the /proc filesystem to turn off ARP replies. To do this, echo a 1 to the hidden file in /proc/sys/net/ipv4/conf/all and the hidden file for the interface you are using. Here is an example that will turn off ARP replies on the loopback interface: # echo 1 > /proc/sys/net/ipv4/conf/all/hidden # echo 1 > /proc/sys/net/ipv4/conf/lo/hidden Is there something that the arp_filter can do that will mirror this functionality? The modification that you made to the documentation was pretty straight forward in that the arp_filter was BOOLEAN, so I think I implemented it right. Any other ideas? Thanks for your help. Pete - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Turning off ARP in linux-2.4.0
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: [EMAIL PROTECTED] pvt. email: [EMAIL PROTECTED] *** 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 <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Turning off ARP in linux-2.4.0
On Tue, Jan 23, 2001 at 01:50:27AM +0100, Bernd Eckenfels wrote: > 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. -arp means that the kernel will not put in link layer to the packets. It's probably not what you want. Yes the option is misnamed. 2.2 has arpfilter, which will hopefully end up in 2.4 soon too. Here is a patch. It allows to filter ARP replies based on the routing table. -Andi Index: include/linux/sysctl.h === RCS file: /cvs/linux/include/linux/sysctl.h,v retrieving revision 1.110 diff -u -u -r1.110 sysctl.h --- include/linux/sysctl.h 2000/11/15 00:13:57 1.110 +++ include/linux/sysctl.h 2001/01/21 10:52:39 @@ -320,9 +320,9 @@ NET_IPV4_CONF_SHARED_MEDIA=7, NET_IPV4_CONF_RP_FILTER=8, NET_IPV4_CONF_ACCEPT_SOURCE_ROUTE=9, - NET_IPV4_CONF_BOOTP_RELAY=10, NET_IPV4_CONF_LOG_MARTIANS=11, - NET_IPV4_CONF_TAG=12 + NET_IPV4_CONF_TAG=12, + NET_IPV4_CONF_ARPFILTER=13, }; /* /proc/sys/net/ipv6 */ Index: include/linux/inetdevice.h === RCS file: /cvs/linux/include/linux/inetdevice.h,v retrieving revision 1.10 diff -u -u -r1.10 inetdevice.h --- include/linux/inetdevice.h 1999/08/20 11:00:32 1.10 +++ include/linux/inetdevice.h 2001/01/21 10:52:40 @@ -12,11 +12,11 @@ int accept_source_route; int rp_filter; int proxy_arp; - int bootp_relay; int log_martians; int forwarding; int mc_forwarding; int tag; + int arp_filter; void*sysctl; }; @@ -39,7 +39,6 @@ #define IN_DEV_MFORWARD(in_dev)(ipv4_devconf.mc_forwarding && (in_dev)->cnf.mc_forwarding) #define IN_DEV_RPFILTER(in_dev)(ipv4_devconf.rp_filter && (in_dev)->cnf.rp_filter) #define IN_DEV_SOURCE_ROUTE(in_dev)(ipv4_devconf.accept_source_route && (in_dev)->cnf.accept_source_route) -#define IN_DEV_BOOTP_RELAY(in_dev) (ipv4_devconf.bootp_relay && (in_dev)->cnf.bootp_relay) #define IN_DEV_LOG_MARTIANS(in_dev)(ipv4_devconf.log_martians || (in_dev)->cnf.log_martians) #define IN_DEV_PROXY_ARP(in_dev) (ipv4_devconf.proxy_arp || (in_dev)->cnf.proxy_arp) @@ -47,6 +46,9 @@ #define IN_DEV_TX_REDIRECTS(in_dev)(ipv4_devconf.send_redirects || (in_dev)->cnf.send_redirects) #define IN_DEV_SEC_REDIRECTS(in_dev) (ipv4_devconf.secure_redirects || (in_dev)->cnf.secure_redirects) #define IN_DEV_IDTAG(in_dev) ((in_dev)->cnf.tag) +#define IN_DEV_ARPFILTER(in_dev) (ipv4_devconf.arp_filter || \ +(in_dev)->cnf.arp_filter) + #define IN_DEV_RX_REDIRECTS(in_dev) \ ((IN_DEV_FORWARD(in_dev) && \ Index: net/ipv4/arp.c === RCS file: /cvs/linux/net/ipv4/arp.c,v retrieving revision 1.95 diff -u -u -r1.95 arp.c --- net/ipv4/arp.c 2001/01/10 18:26:53 1.95 +++ net/ipv4/arp.c 2001/01/21 10:52:42 @@ -311,6 +311,21 @@ kfree_skb(skb); } +static int arp_filter(__u32 sip, __u32 tip, struct device *dev) +{ + struct rtable *rt; + int flag = 0; + + if (ip_route_output(, sip, tip, 0, 0) < 0) + return 1; + if (rt->u.dst.dev != dev) { + SNMP_INC_STATS(net_statistics, ArpFilter); + flag = 1; + } + ip_rt_put(rt); + return flag; +} + static void arp_solicit(struct neighbour *neigh, struct sk_buff *skb) { u32 saddr; @@ -731,18 +746,25 @@ if (addr_type == RTN_LOCAL) { n = neigh_event_ns(_tbl, sha, , dev); - if (n) { + if (!n) + goto out; + if (!(IN_DEV_ARPFILTER(in_dev)&_filter(sip,tip,dev))) arp_send(ARPOP_REPLY,ETH_P_ARP,sip,dev,tip,sha,dev->dev_addr,sha); - neigh_release(n); - } + neigh_release(n); goto out; } else if (IN_DEV_FORWARD(in_dev)) { + struct pneigh_enqueue *p = NULL; if ((rt->rt_flags_DNAT) || (addr_type == RTN_UNICAST && rt->u.dst.dev != dev && -(IN_DEV_PROXY_ARP(in_dev) || pneigh_lookup(_tbl, , dev, 0 { +(IN_DEV_PROXY_ARP(in_dev) || (p=pneigh_lookup(_tbl, +, dev,
Re: Turning off ARP in linux-2.4.0
On Tue, Jan 23, 2001 at 01:50:27AM +0100, Bernd Eckenfels wrote: 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. -arp means that the kernel will not put in link layer to the packets. It's probably not what you want. Yes the option is misnamed. 2.2 has arpfilter, which will hopefully end up in 2.4 soon too. Here is a patch. It allows to filter ARP replies based on the routing table. -Andi Index: include/linux/sysctl.h === RCS file: /cvs/linux/include/linux/sysctl.h,v retrieving revision 1.110 diff -u -u -r1.110 sysctl.h --- include/linux/sysctl.h 2000/11/15 00:13:57 1.110 +++ include/linux/sysctl.h 2001/01/21 10:52:39 @@ -320,9 +320,9 @@ NET_IPV4_CONF_SHARED_MEDIA=7, NET_IPV4_CONF_RP_FILTER=8, NET_IPV4_CONF_ACCEPT_SOURCE_ROUTE=9, - NET_IPV4_CONF_BOOTP_RELAY=10, NET_IPV4_CONF_LOG_MARTIANS=11, - NET_IPV4_CONF_TAG=12 + NET_IPV4_CONF_TAG=12, + NET_IPV4_CONF_ARPFILTER=13, }; /* /proc/sys/net/ipv6 */ Index: include/linux/inetdevice.h === RCS file: /cvs/linux/include/linux/inetdevice.h,v retrieving revision 1.10 diff -u -u -r1.10 inetdevice.h --- include/linux/inetdevice.h 1999/08/20 11:00:32 1.10 +++ include/linux/inetdevice.h 2001/01/21 10:52:40 @@ -12,11 +12,11 @@ int accept_source_route; int rp_filter; int proxy_arp; - int bootp_relay; int log_martians; int forwarding; int mc_forwarding; int tag; + int arp_filter; void*sysctl; }; @@ -39,7 +39,6 @@ #define IN_DEV_MFORWARD(in_dev)(ipv4_devconf.mc_forwarding (in_dev)-cnf.mc_forwarding) #define IN_DEV_RPFILTER(in_dev)(ipv4_devconf.rp_filter (in_dev)-cnf.rp_filter) #define IN_DEV_SOURCE_ROUTE(in_dev)(ipv4_devconf.accept_source_route (in_dev)-cnf.accept_source_route) -#define IN_DEV_BOOTP_RELAY(in_dev) (ipv4_devconf.bootp_relay (in_dev)-cnf.bootp_relay) #define IN_DEV_LOG_MARTIANS(in_dev)(ipv4_devconf.log_martians || (in_dev)-cnf.log_martians) #define IN_DEV_PROXY_ARP(in_dev) (ipv4_devconf.proxy_arp || (in_dev)-cnf.proxy_arp) @@ -47,6 +46,9 @@ #define IN_DEV_TX_REDIRECTS(in_dev)(ipv4_devconf.send_redirects || (in_dev)-cnf.send_redirects) #define IN_DEV_SEC_REDIRECTS(in_dev) (ipv4_devconf.secure_redirects || (in_dev)-cnf.secure_redirects) #define IN_DEV_IDTAG(in_dev) ((in_dev)-cnf.tag) +#define IN_DEV_ARPFILTER(in_dev) (ipv4_devconf.arp_filter || \ +(in_dev)-cnf.arp_filter) + #define IN_DEV_RX_REDIRECTS(in_dev) \ ((IN_DEV_FORWARD(in_dev) \ Index: net/ipv4/arp.c === RCS file: /cvs/linux/net/ipv4/arp.c,v retrieving revision 1.95 diff -u -u -r1.95 arp.c --- net/ipv4/arp.c 2001/01/10 18:26:53 1.95 +++ net/ipv4/arp.c 2001/01/21 10:52:42 @@ -311,6 +311,21 @@ kfree_skb(skb); } +static int arp_filter(__u32 sip, __u32 tip, struct device *dev) +{ + struct rtable *rt; + int flag = 0; + + if (ip_route_output(rt, sip, tip, 0, 0) 0) + return 1; + if (rt-u.dst.dev != dev) { + SNMP_INC_STATS(net_statistics, ArpFilter); + flag = 1; + } + ip_rt_put(rt); + return flag; +} + static void arp_solicit(struct neighbour *neigh, struct sk_buff *skb) { u32 saddr; @@ -731,18 +746,25 @@ if (addr_type == RTN_LOCAL) { n = neigh_event_ns(arp_tbl, sha, sip, dev); - if (n) { + if (!n) + goto out; + if (!(IN_DEV_ARPFILTER(in_dev)arp_filter(sip,tip,dev))) arp_send(ARPOP_REPLY,ETH_P_ARP,sip,dev,tip,sha,dev-dev_addr,sha); - neigh_release(n); - } + neigh_release(n); goto out; } else if (IN_DEV_FORWARD(in_dev)) { + struct pneigh_enqueue *p = NULL; if ((rt-rt_flagsRTCF_DNAT) || (addr_type == RTN_UNICAST rt-u.dst.dev != dev -(IN_DEV_PROXY_ARP(in_dev) || pneigh_lookup(arp_tbl, tip, dev, 0 { +(IN_DEV_PROXY_ARP(in_dev) || (p=pneigh_lookup(arp_tbl, +tip, dev, 0) {
Re: Turning off ARP in linux-2.4.0
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: [EMAIL PROTECTED] pvt. email: [EMAIL PROTECTED] *** 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 [EMAIL PROTECTED] To: [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Turning off ARP in linux-2.4.0
On Tue, Jan 23, 2001 at 01:50:27AM +0100, Bernd Eckenfels wrote: Another option is to ifconfig -arp the eth0 interface. I browsed through t he IPv4 code and did not find any other goto out which can be configured besi des 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 reac h them. -arp means that the kernel will not put in link layer to the packets. It's probably not what you want. Yes the option is misnamed. 2.2 has arpfilter, which will hopefully end up in 2.4 soon too. Here is a patch. It allows to filter ARP replies based on the routing table. -Andi Thanks for the patches. I patched the kernel and tried it and it still is reponding to arps even after I issued: echo 1 /proc/sys/net/ipv4/conf/all/arp_filter echo 1 /proc/sys/net/ipv4/conf/lo/arp_filter I do not know what the hidden interface did exactly and I am still unsure why it no longer shows up in the 2.4.0 kernel. Here is a clip from the TurboLinux ClusterServer manual that explains how to turn off the arping. Maybe it will clear up what I am trying to accomplish: Next you have to turn off ARP replies on the interface. How you accomplish that depends upon which Linux kernel version you are using. On UNIX systems and Linux 2.0 kernels, you can supply the -arp option to the ifconfig command when you bring up the interface. (Note that some UNIX and Linux systems may use a slightly different syntax, such as using noarp instead of -arp.) So in our example, we would use this command to configure the interface: # ifconfig lo:1 10.0.0.99 netmask 255.255.255.255 -arp Unfortunately, this method does not work in any Linux kernels more recent than the 2.0 series. For systems running kernel 2.2.14 and higher the -arp option does not work. Instead, you will have to use the /proc filesystem to turn off ARP replies. To do this, echo a 1 to the hidden file in /proc/sys/net/ipv4/conf/all and the hidden file for the interface you are using. Here is an example that will turn off ARP replies on the loopback interface: # echo 1 /proc/sys/net/ipv4/conf/all/hidden # echo 1 /proc/sys/net/ipv4/conf/lo/hidden Is there something that the arp_filter can do that will mirror this functionality? The modification that you made to the documentation was pretty straight forward in that the arp_filter was BOOLEAN, so I think I implemented it right. Any other ideas? Thanks for your help. Pete - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Turning off ARP in linux-2.4.0
On Tue, Jan 23, 2001 at 03:50:36PM -0800, Pete Elton wrote: Is there something that the arp_filter can do that will mirror this functionality? The modification that you made to the documentation was pretty straight forward in that the arp_filter was BOOLEAN, so I think I implemented it right. The snippet you posted doesn't describe what ClusterThingy exactly wants to do with ARPs. Arpfilter was designed for multiple interfaces, to direct ARP replies to specific interfaces based on the routing table. If you have only a single interface and no other way to policy route the packet I think you can only try to use policy routing hacks (not tested). e.g. tag all outgoing packets with a specific fwmark that redirects them to a specific routing table which does the real routing, and put no routes into the normal one used by arpfilter so that it doesnt' reply. Admittedly it's quite a hack. Perhaps Alexey can suggest a better solution, he's the routing/arp guru. I guess it would be easier if arpfilter was able to select a special own routing table, but I was too chicken to implement that. -Andi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Turning off ARP in linux-2.4.0
On Tue, Jan 23, 2001 at 03:50:36PM -0800, Pete Elton wrote: The snippet you posted doesn't describe what ClusterThingy exactly wants to do with ARPs. Well I think the main difference in what you implemented and what the cluster server thing is doing (I think) is it sounds like you can arp on a specific interface, but for the cluster server software to work, the node cannot arp at all since a separate machine is acting as a redirector and all incoming request go to that server first and are then pasted to a node. (how's that for a run on sentence) Here is what their documentation says about that explicitly. It appears just before the other section I quoted: Creating an alias has one problem: when another system on the network wants to send a packet to the IP address 10.0.0.99 on the same subnet, it sends an ARP broadcast to determine which computer has that IP address. The machine with that IP address is supposed to answer back with its IP address and corresponding MAC (hardware) address. But if all the nodes in the cluster have the same IP address, they are all going to answer this broadcast ARP message. So we have to tell all of the systems except for the primary ATM not to reply to those ARP requests. We want all traffic destined for the cluster to go through the primary ATM first. Part of the solution to this is to create the alias on the loopback interface instead of the Ethernet interface. The loopback interface is a network interface that has no hardware or physical network associated with it. So instead of creating the alias on eth0:1, you would add the alias to the loopback interface (lo) using the following command: # ifconfig lo:1 10.0.0.99 netmask 255.255.255.255 up 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. So only the ATM can ARP for the ip address of the web site. The 7 other servers cannot. So for the 2.2.18 kernel, I have the ipaddress aliased to the lo interface with the hidden sysctrl option set to 1 and everything works. When I try and bring one of the nodes up on the 2.4.0 kernel, I cannot keep it from ARPing so it fights with the ATM for all of the traffic and that causes problems. I hope that this makes more sense. Any ideas on how I can turn off the arping? I guess the thing that I am most curious about is how it ending up being removed from the kernel in the first place. It must have been a decision that someone made. Either, we don't need that any more since we can do it this way, or we'll take it out since nobody uses it. Pete - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Turning off ARP in linux-2.4.0
On Tue, Jan 23, 2001 at 04:27:21PM -0800, Pete Elton wrote: Any ideas on how I can turn off the arping? I guess the thing that I I explained it in my last mail how to do it using arpfilter. I do not claim that it is an elegant solution. It's probably not worse a hack than hidden is in the first place though. am most curious about is how it ending up being removed from the kernel in the first place. It must have been a decision that someone made. Either, we don't need that any more since we can do it this way, or we'll take it out since nobody uses it. It was only submitted to 2.2 a few months ago (=years after 2.3 branched), but never added to 2.4. -Andi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Turning off ARP in linux-2.4.0
On Tue, Jan 23, 2001 at 04:27:21PM -0800, Pete Elton wrote: Any ideas on how I can turn off the arping? I guess the thing that I I explained it in my last mail how to do it using arpfilter. I do not claim that it is an elegant solution. It's probably not worse a hack than hidden is in the first place though. I either missed that or did not understand it. I am now rereading your message Is that what you were referring to when you said only try to use policy routing hacks (not tested). e.g. tag all outgoing packets with a specific fwmark that redirects them to a specific routing table which does the real routing, and put no routes into the normal one used by arpfilter so that it doesnt' reply. I am not familiar with policy routing. Could you point me to some docs I could read or maybe even give a trivial example to start me on the right path? am most curious about is how it ending up being removed from the kernel in the first place. It must have been a decision that someone made. Either, we don't need that any more since we can do it this way, or we'll take it out since nobody uses it. It was only submitted to 2.2 a few months ago (=years after 2.3 branched), b ut never added to 2.4. Well that at least makes sense as to why it's not in there. Thank you for all of your help. Pete - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Turning off ARP in linux-2.4.0
In article [EMAIL PROTECTED] 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-flagsIFF_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 [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Turning off ARP in linux-2.4.0
In article [EMAIL PROTECTED] 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 - [EMAIL PROTECTED] --- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Turning off ARP in linux-2.4.0
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 [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Turning off ARP in linux-2.4.0
In article <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Turning off ARP in linux-2.4.0
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 [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Turning off ARP in linux-2.4.0
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 [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Turning off ARP in linux-2.4.0
In article [EMAIL PROTECTED] 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 [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/