Re: Turning off ARP in linux-2.4.0

Re: Turning off ARP in linux-2.4.0

[Bernd Eckenfels]

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/

Re: Turning off ARP in linux-2.4.0

[Andi Kleen]

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_flags&RTCF_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))))) {
 				n = neigh_event_ns(&arp_tbl, sha, &sip, dev);
 				if (n)
 					neigh_release(n);
+
+				/* no arpfilter for explicit proxy arps */ 
+				if (!p && IN_DEV_ARPFILTER(in_dev)&&
+				    arp_filter(sip,tip,dev))
+					goto out; 
 
 				if (skb->stamp.tv_sec == 0 ||
 				    skb->pkt_type == PACKET_HOST ||
Index: net/ipv4/proc.c
===================================================================
RCS file: /cvs/linux/net/ipv4/proc.c,v
retrieving revision 1.44
diff -u -u -r1.44 proc.c
--- net/ipv4/proc.c	2000/08/09 11:59:04	1.44
+++ net/ipv4/proc.c	2001/01/21 10:52:42
@@ -194,10 +194,18 @@
 		      " TCPAbortOnMemory TCPAbortOnTimeout TCPAbortOnLinger"
 		      " TCPAbortFailed TCPMemoryPressures\n"
 		      "TcpExt:");
-	for (i=0; i<offsetof(struct linux_mib, __pad)/sizeof(unsigned long); i++)
+	for (i=0; i<offsetof(struct linux_mib, __tcp_pad)/sizeof(unsigned long); i++)
 		len += sprintf(buffer+len, " %lu", fold_field((unsigned long*)net_statistics, sizeof(struct linux_mib), i));
 
 	len += sprintf (buffer + len, "\n");
+
+	len += sprintf(buffer + len, 
+				"IpExt: ArpFilter\n"
+				"IpExt: %lu\n",
+			  fold_field((unsigned long *)net_statistics,
+				     sizeof(struct linux_mib), 
+				     offsetof(struct linux_mib,ArpFilter)/
+				     sizeof(unsigned long))); 
 
 	if (offset >= len)
 	{
Index: net/ipv4/devinet.c
===================================================================
RCS file: /cvs/linux/net/ipv4/devinet.c,v
retrieving revision 1.39
diff -u -u -r1.39 devinet.c
--- net/ipv4/devinet.c	2000/12/10 22:24:11	1.39
+++ net/ipv4/devinet.c	2001/01/21 10:52:43
@@ -773,7 +773,12 @@
 static int inetdev_event(struct notifier_block *this, unsigned long event, void *ptr)
 {
 	struct net_device *dev = ptr;
-	struct in_device *in_dev = __in_dev_get(dev);
+	struct in_device *in_dev;
+	
+	if (!dev) 
+		return NOTIFY_DONE; 
+
+	in_dev = __in_dev_get(dev);
 
 	ASSERT_RTNL();
 
@@ -817,13 +822,31 @@
 	case NETDEV_CHANGENAME:
 		if (in_dev->ifa_list) {
 			struct in_ifaddr *ifa;
-			for (ifa = in_dev->ifa_list; ifa; ifa = ifa->ifa_next)
+			for (ifa = in_dev->ifa_list; ifa; ifa = ifa->ifa_next) { 
+				char oldname[IFNAMSIZ]; 
+				char *alias; 
+				memcpy(oldname, ifa->ifa_label, IFNAMSIZ);
+				alias = strchr(oldname, ':');
 				memcpy(ifa->ifa_label, dev->name, IFNAMSIZ);
+				if (alias) {
+					strncat(ifa->ifa_label,alias,IFNAMSIZ-1-strlen(ifa->ifa_label));
+					ifa->ifa_label[IFNAMSIZ-1] = '\0';
+				} 
+			} 
 			/* Do not notify about label change, this event is
 			   not interesting to applications using netlink.
 			 */
 		}
 		break;
+#if 0		
+	case NETDEV_REBOOT:
+		if (dev->flags & IFF_DYNAMIC ) { 
+			for_primary_ifa(in_dev) {
+				notifier_call_chain(&inetaddr_chain, NETDEV_REBOOT, ifa); 
+			} endfor_ifa(in_dev); 
+ 		}
+ 		break;
+#endif		
 	}
 
 	return NOTIFY_DONE;
@@ -1053,16 +1076,16 @@
          &proc_dointvec},
 	{NET_IPV4_CONF_PROXY_ARP, "proxy_arp",
          &ipv4_devconf.proxy_arp, sizeof(int), 0644, NULL,
-         &proc_dointvec},
-	{NET_IPV4_CONF_BOOTP_RELAY, "bootp_relay",
-         &ipv4_devconf.bootp_relay, sizeof(int), 0644, NULL,
          &proc_dointvec},
-        {NET_IPV4_CONF_LOG_MARTIANS, "log_martians",
+	{NET_IPV4_CONF_LOG_MARTIANS, "log_martians",
          &ipv4_devconf.log_martians, sizeof(int), 0644, NULL,
          &proc_dointvec},
 	{NET_IPV4_CONF_TAG, "tag",
 	 &ipv4_devconf.tag, sizeof(int), 0644, NULL,
 	 &proc_dointvec},
+	{NET_IPV4_CONF_ARPFILTER, "arp_filter",
+          &ipv4_devconf.arp_filter, sizeof(int), 0644, NULL,
+          &proc_dointvec},
 	 {0}},
 
 	{{NET_PROTO_CONF_ALL, "all", NULL, 0, 0555, devinet_sysctl.devinet_vars},{0}},
Index: include/net/snmp.h
===================================================================
RCS file: /cvs/linux/include/net/snmp.h,v
retrieving revision 1.17
diff -u -u -r1.17 snmp.h
--- include/net/snmp.h	2000/09/21 01:31:50	1.17
+++ include/net/snmp.h	2001/01/21 10:52:43
@@ -254,6 +254,9 @@
 	unsigned long	TCPAbortOnLinger;
 	unsigned long	TCPAbortFailed;
 	unsigned long	TCPMemoryPressures;
+	unsigned long	__tcp_pad[0];
+	unsigned long	ArpFilter;
+	unsigned long	__ip_pad[0];
 	unsigned long   __pad[0];
 } ____cacheline_aligned;
 
Index: Documentation/networking/ip-sysctl.txt
===================================================================
RCS file: /cvs/linux/Documentation/networking/ip-sysctl.txt,v
retrieving revision 1.17
diff -u -u -r1.17 ip-sysctl.txt
--- Documentation/networking/ip-sysctl.txt	2000/11/06 07:15:36	1.17
+++ Documentation/networking/ip-sysctl.txt	2001/01/21 10:52:44
@@ -345,14 +345,6 @@
 send_redirects - BOOLEAN
 	Send redirects, if router. Default: TRUE
 
-bootp_relay - BOOLEAN
-	Accept packets with source address 0.b.c.d destined
-	not to this host as local ones. It is supposed, that
-	BOOTP relay daemon will catch and forward such packets.
-
-	default FALSE
-	Not Implemented Yet.
-
 accept_source_route - BOOLEAN
 	Accept packets with SRR option.
 	default TRUE (router)
@@ -369,6 +361,10 @@
 
 	Default value is 0. Note that some distributions enable it
 	in startip scripts.
+
+arp_filter - BOOLEAN
+	Only answer ARP requests on this device when the routing table would 
+	send packets to the source it to the same device.
 
 Alexey Kuznetsov.
 kuznet@ms2.inr.ac.ru

-
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/

Re: Turning off ARP in linux-2.4.0

[Pete Elton]

> 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 majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Turning off ARP in linux-2.4.0

[Andi Kleen]

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 majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Turning off ARP in linux-2.4.0

[Pete Elton]

> 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 majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Turning off ARP in linux-2.4.0

[Andi Kleen]

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 majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Turning off ARP in linux-2.4.0

[Pete Elton]

> 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 majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Turning off ARP in linux-2.4.0

[Julian Anastasov]

	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 <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/

Re: Turning off ARP in linux-2.4.0

[Bernd Eckenfels]

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)      -- Bernd_Eckenfels@Wendelinusstrasse39.76646Bruchsal.de --
 ( .. )  ecki@{inka.de,linux.de,debian.org} http://home.pages.de/~eckes/
  o--o     *plush*  2048/93600EFD  eckes@irc  +497257930613  BE5-RIPE
(O____O)  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 majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Turning off ARP in linux-2.4.0

[Julian Anastasov]

	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/

Re: Turning off ARP in linux-2.4.0

[Pete Elton]

> > 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 majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Turning off ARP in linux-2.4.0

[Julian Anastasov]

	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/

Re: Turning off ARP in linux-2.4.0

[Bernd Eckenfels]

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/

Re: Turning off ARP in linux-2.4.0

[Julian Anastasov]

	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/

Re: Turning off ARP in linux-2.4.0

[Bernd Eckenfels]

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/

Re: Turning off ARP in linux-2.4.0

[Bernd Eckenfels]

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/

Re: Turning off ARP in linux-2.4.0

[Bernd Eckenfels]

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/

Re: Turning off ARP in linux-2.4.0

[NDias]

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/

Turning off ARP in linux-2.4.0

[Pete Elton]

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/