Weak host model vs .interface down

Weak host model vs .interface down

[Joakim Tjernlund]

Linux uses the weak host model which makes the IP addresses part of the system
rather than the interface. However consider this:

System A, eth0 connected to the network
# > ifconfig eth0 192.168.1.16
# > ifconfig eth1 192.168.1.17 down

System B
# > ping 192.168.1.17
PING 192.168.1.17 (192.168.1.17) 56(84) bytes of data.
64 bytes from 192.168.1.17: icmp_seq=1 ttl=64 time=0.618 ms

Isn't it a bit much to respond on 192.168.1.17 when its interface is down?
I even tried to set rp_filter=1 for all interfaces and that didn't help
either(not that I should need to)

   Jocke

[PATCH net-next-2.6] ipv4: sysctl to block responding on down interface

[Stephen Hemminger]

When Linux is used as a router, it is undesirable for the kernel to process
incoming packets when the address assigned to the interface is down.
The initial problem report was for a management application that used ICMP
to check link availability.

The default is disabled to maintain compatibility with previous behavior.
This is not recommended for server systems because it makes fail over more
difficult, and does not account for configurations where multiple interfaces
have the same IP address.

Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>

---
 Documentation/networking/ip-sysctl.txt |   10 ++++++++++
 include/linux/inetdevice.h             |    2 ++
 net/ipv4/devinet.c                     |    1 +
 net/ipv4/route.c                       |    7 +++++++
 4 files changed, 20 insertions(+)

--- a/include/linux/inetdevice.h	2010-05-28 08:35:11.000000000 -0700
+++ b/include/linux/inetdevice.h	2010-06-11 08:35:55.237028136 -0700
@@ -37,6 +37,7 @@ enum
 	IPV4_DEVCONF_ACCEPT_LOCAL,
 	IPV4_DEVCONF_SRC_VMARK,
 	IPV4_DEVCONF_PROXY_ARP_PVLAN,
+	IPV4_DEVCONF_LINKFILTER,
 	__IPV4_DEVCONF_MAX
 };
 
@@ -140,6 +141,7 @@ static inline void ipv4_devconf_setall(s
 #define IN_DEV_ARP_ANNOUNCE(in_dev)	IN_DEV_MAXCONF((in_dev), ARP_ANNOUNCE)
 #define IN_DEV_ARP_IGNORE(in_dev)	IN_DEV_MAXCONF((in_dev), ARP_IGNORE)
 #define IN_DEV_ARP_NOTIFY(in_dev)	IN_DEV_MAXCONF((in_dev), ARP_NOTIFY)
+#define IN_DEV_LINKFILTER(in_dev)	IN_DEV_MAXCONF((in_dev), LINKFILTER)
 
 struct in_ifaddr {
 	struct in_ifaddr	*ifa_next;
--- a/net/ipv4/devinet.c	2010-06-01 08:39:12.000000000 -0700
+++ b/net/ipv4/devinet.c	2010-06-11 08:37:03.921248294 -0700
@@ -1416,6 +1416,7 @@ static struct devinet_sysctl_table {
 		DEVINET_SYSCTL_RW_ENTRY(ARP_ACCEPT, "arp_accept"),
 		DEVINET_SYSCTL_RW_ENTRY(ARP_NOTIFY, "arp_notify"),
 		DEVINET_SYSCTL_RW_ENTRY(PROXY_ARP_PVLAN, "proxy_arp_pvlan"),
+		DEVINET_SYSCTL_RW_ENTRY(LINKFILTER, "link_filter"),
 
 		DEVINET_SYSCTL_FLUSHING_ENTRY(NOXFRM, "disable_xfrm"),
 		DEVINET_SYSCTL_FLUSHING_ENTRY(NOPOLICY, "disable_policy"),
--- a/net/ipv4/route.c	2010-06-11 08:13:13.000000000 -0700
+++ b/net/ipv4/route.c	2010-06-11 08:14:28.486271886 -0700
@@ -2152,6 +2152,13 @@ static int ip_route_input_slow(struct sk
 		goto brd_input;
 
 	if (res.type == RTN_LOCAL) {
+		int linkf = IN_DEV_LINKFILTER(in_dev);
+
+		if (linkf && !netif_running(res.fi->fib_dev))
+			goto no_route;
+		if (linkf > 1 && !netif_carrier_ok(res.fi->fib_dev))
+			goto no_route;
+
 		err = fib_validate_source(saddr, daddr, tos,
 					     net->loopback_dev->ifindex,
 					     dev, &spec_dst, &itag, skb->mark);
--- a/Documentation/networking/ip-sysctl.txt	2010-06-11 08:14:46.889751310 -0700
+++ b/Documentation/networking/ip-sysctl.txt	2010-06-11 08:15:35.508471622 -0700
@@ -832,6 +832,16 @@ rp_filter - INTEGER
 	Default value is 0. Note that some distributions enable it
 	in startup scripts.
 
+link_filter - INTEGER
+        0 - Allow packets to be received for the address on this interface
+	even if interface is disabled or no carrier.
+
+	1 - Ignore packets received if interface associated with the incoming
+	address is down.
+
+	2 - Ignore packets received if interface associated with the incoming
+	address is down or has no carrier.
+
 arp_filter - BOOLEAN
 	1 - Allows you to have multiple network interfaces on the same
 	subnet, and have the ARPs for each interface be answered

Re: [PATCH net-next-2.6] ipv4: sysctl to block responding on down interface

[David Miller]

From: Stephen Hemminger <shemminger@vyatta.com>
Date: Fri, 11 Jun 2010 08:48:54 -0700

> The initial problem report was for a management application that used ICMP
> to check link availability.

That application is buggy, and even if we apply this patch it will
only properly function when speaking to systems in a non-default
configuration.  And, it would be a non-default setting which, by your
own admission below, cannot function properly in valid interface
configurations.

It's easier to fix the app to work in all cases than to add another
sysctl knob hack for a segment of the world that can't seem to wrap
their head around the fact that our behavior is valid, specified, and
an explicit design decision meant to increase the chances of
successful communication between two systems.

> The default is disabled to maintain compatibility with previous behavior.
> This is not recommended for server systems because it makes fail over more
> difficult, and does not account for configurations where multiple interfaces
> have the same IP address.

The fact that the syctl knob, when enabled, can't even function properly
in this "multiple interfaces with same address" case is another reason I
have decided to not apply this.

Re: [PATCH net-next-2.6] ipv4: sysctl to block responding on down interface

[Stephen Hemminger]

On Tue, 22 Jun 2010 10:15:37 -0700 (PDT)
David Miller <davem@davemloft.net> wrote:

> From: Stephen Hemminger <shemminger@vyatta.com>
> Date: Fri, 11 Jun 2010 08:48:54 -0700
> 
> > The initial problem report was for a management application that used ICMP
> > to check link availability.
> 
> That application is buggy, and even if we apply this patch it will
> only properly function when speaking to systems in a non-default
> configuration.  And, it would be a non-default setting which, by your
> own admission below, cannot function properly in valid interface
> configurations.

It is a remote management system not a local application.
The management system is stupid, but it is hard to argue with
customers that other system is broken. 

> It's easier to fix the app to work in all cases than to add another
> sysctl knob hack for a segment of the world that can't seem to wrap
> their head around the fact that our behavior is valid, specified, and
> an explicit design decision meant to increase the chances of
> successful communication between two systems.
> 
> > The default is disabled to maintain compatibility with previous behavior.
> > This is not recommended for server systems because it makes fail over more
> > difficult, and does not account for configurations where multiple interfaces
> > have the same IP address.
> 
> The fact that the syctl knob, when enabled, can't even function properly
> in this "multiple interfaces with same address" case is another reason I
> have decided to not apply this.

We already have sysctl knobs that exist to work around broken printer TCP,
middleboxes and other broken stacks; my opinion this is just another one
of those types of workarounds.

Re: [PATCH net-next-2.6] ipv4: sysctl to block responding on down interface

[David Miller]

From: Stephen Hemminger <shemminger@vyatta.com>
Date: Wed, 30 Jun 2010 13:55:35 -0700

>> The fact that the syctl knob, when enabled, can't even function properly
>> in this "multiple interfaces with same address" case is another reason I
>> have decided to not apply this.
> 
> We already have sysctl knobs that exist to work around broken printer TCP,
> middleboxes and other broken stacks; my opinion this is just another one
> of those types of workarounds.

But that sysctl knob for the printer workaround doesn't break legitimate
configurations like this one does.

Re: [PATCH net-next-2.6] ipv4: sysctl to block responding on down interface

[Joakim Tjernlund]

Stephen Hemminger <shemminger@vyatta.com> wrote on 2010/06/11 17:48:54:
>
> When Linux is used as a router, it is undesirable for the kernel to process
> incoming packets when the address assigned to the interface is down.
> The initial problem report was for a management application that used ICMP
> to check link availability.
>
> The default is disabled to maintain compatibility with previous behavior.
> This is not recommended for server systems because it makes fail over more
> difficult, and does not account for configurations where multiple interfaces
> have the same IP address.
>
> Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>

Ping David et. all?
I too want this.

 Jocke

Re: [PATCH net-next-2.6] ipv4: sysctl to block responding on down interface

[Eric Dumazet]

Le lundi 28 juin 2010 à 21:03 +0200, Joakim Tjernlund a écrit :
> Stephen Hemminger <shemminger@vyatta.com> wrote on 2010/06/11 17:48:54:
> >
> > When Linux is used as a router, it is undesirable for the kernel to process
> > incoming packets when the address assigned to the interface is down.
> > The initial problem report was for a management application that used ICMP
> > to check link availability.
> >
> > The default is disabled to maintain compatibility with previous behavior.
> > This is not recommended for server systems because it makes fail over more
> > difficult, and does not account for configurations where multiple interfaces
> > have the same IP address.
> >
> > Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
> 
> Ping David et. all?
> I too want this.

You probably missed David reply

http://permalink.gmane.org/gmane.linux.network/164494

Re: [PATCH net-next-2.6] ipv4: sysctl to block responding on down interface

[Joakim Tjernlund]

Eric Dumazet <eric.dumazet@gmail.com> wrote on 2010/06/28 21:42:01:
>
> Le lundi 28 juin 2010 à 21:03 +0200, Joakim Tjernlund a écrit :
> > Stephen Hemminger <shemminger@vyatta.com> wrote on 2010/06/11 17:48:54:
> > >
> > > When Linux is used as a router, it is undesirable for the kernel to process
> > > incoming packets when the address assigned to the interface is down.
> > > The initial problem report was for a management application that used ICMP
> > > to check link availability.
> > >
> > > The default is disabled to maintain compatibility with previous behavior.
> > > This is not recommended for server systems because it makes fail over more
> > > difficult, and does not account for configurations where multiple interfaces
> > > have the same IP address.
> > >
> > > Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
> >
> > Ping David et. all?
> > I too want this.
>
> You probably missed David reply
>
> http://permalink.gmane.org/gmane.linux.network/164494

Sure did, don't know how that happened, sorry.

Reading David's reply I do wonder about the current behaviour. Why
is it so important to keep responding to an IP address when the
admin has put the interface holding that IP address into administratively
down state? I don't think the weak host model stipulates that it must be so, does it?

To me it "ifconfig eth0 down" means not only to stop using the I/F but
also any IP address associated with the I/F. I was rather surprised that
it didn't work that way. I don't see any way to make Linux stop responding to
that IP other that removing it completely from the system, which is rather
awkward.

Note, I don't mean that the same should be applied for the No Carrier case, just
ifconfig down.

 Jocke

Re: [PATCH net-next-2.6] ipv4: sysctl to block responding on down interface

[Mitchell Erblich]

On Jun 28, 2010, at 2:09 PM, Joakim Tjernlund wrote:

> Eric Dumazet <eric.dumazet@gmail.com> wrote on 2010/06/28 21:42:01:
>> 
>> Le lundi 28 juin 2010 à 21:03 +0200, Joakim Tjernlund a écrit :
>>> Stephen Hemminger <shemminger@vyatta.com> wrote on 2010/06/11 17:48:54:
>>>> 
>>>> When Linux is used as a router, it is undesirable for the kernel to process
>>>> incoming packets when the address assigned to the interface is down.
>>>> The initial problem report was for a management application that used ICMP
>>>> to check link availability.
>>>> 
>>>> The default is disabled to maintain compatibility with previous behavior.
>>>> This is not recommended for server systems because it makes fail over more
>>>> difficult, and does not account for configurations where multiple interfaces
>>>> have the same IP address.
>>>> 
>>>> Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
>>> 
>>> Ping David et. all?
>>> I too want this.
>> 
>> You probably missed David reply
>> 
>> http://permalink.gmane.org/gmane.linux.network/164494
> 
> Sure did, don't know how that happened, sorry.
> 
> Reading David's reply I do wonder about the current behaviour. Why
> is it so important to keep responding to an IP address when the
> admin has put the interface holding that IP address into administratively
> down state? I don't think the weak host model stipulates that it must be so, does it?
> 
> To me it "ifconfig eth0 down" means not only to stop using the I/F but
> also any IP address associated with the I/F. I was rather surprised that
> it didn't work that way. I don't see any way to make Linux stop responding to
> that IP other that removing it completely from the system, which is rather
> awkward.
> 
> Note, I don't mean that the same should be applied for the No Carrier case, just
> ifconfig down.
> 
> Jocke
> 
> 
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Hey guys, isn't the support of magic pkts/ Energy star require the receipt
of pkts while the intf is down?

Mitchell Erblich

Re: [PATCH net-next-2.6] ipv4: sysctl to block responding on down interface

[Joakim Tjernlund]

Mitchell Erblich <erblichs@earthlink.net> wrote on 2010/06/28 23:28:29:
>
>
> On Jun 28, 2010, at 2:09 PM, Joakim Tjernlund wrote:
>
> > Eric Dumazet <eric.dumazet@gmail.com> wrote on 2010/06/28 21:42:01:
> >>
> >> Le lundi 28 juin 2010 à 21:03 +0200, Joakim Tjernlund a écrit :
> >>> Stephen Hemminger <shemminger@vyatta.com> wrote on 2010/06/11 17:48:54:
> >>>>
> >>>> When Linux is used as a router, it is undesirable for the kernel to process
> >>>> incoming packets when the address assigned to the interface is down.
> >>>> The initial problem report was for a management application that used ICMP
> >>>> to check link availability.
> >>>>
> >>>> The default is disabled to maintain compatibility with previous behavior.
> >>>> This is not recommended for server systems because it makes fail over more
> >>>> difficult, and does not account for configurations where multiple interfaces
> >>>> have the same IP address.
> >>>>
> >>>> Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
> >>>
> >>> Ping David et. all?
> >>> I too want this.
> >>
> >> You probably missed David reply
> >>
> >> http://permalink.gmane.org/gmane.linux.network/164494
> >
> > Sure did, don't know how that happened, sorry.
> >
> > Reading David's reply I do wonder about the current behaviour. Why
> > is it so important to keep responding to an IP address when the
> > admin has put the interface holding that IP address into administratively
> > down state? I don't think the weak host model stipulates that it must be so, does it?
> >
> > To me it "ifconfig eth0 down" means not only to stop using the I/F but
> > also any IP address associated with the I/F. I was rather surprised that
> > it didn't work that way. I don't see any way to make Linux stop responding to
> > that IP other that removing it completely from the system, which is rather
> > awkward.
> >
> > Note, I don't mean that the same should be applied for the No Carrier case, just
> > ifconfig down.
> >
> > Jocke
> >
> >
> > --
> > To unsubscribe from this list: send the line "unsubscribe netdev" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
> Hey guys, isn't the support of magic pkts/ Energy star require the receipt
> of pkts while the intf is down?

No idea, but if so, does it need to process IP pkgs destined for
the IP address in question and pass these up to user space?

 Jocke

Re: [PATCH net-next-2.6] ipv4: sysctl to block responding on down interface

[David Miller]

From: Joakim Tjernlund <joakim.tjernlund@transmode.se>
Date: Mon, 28 Jun 2010 23:09:02 +0200

> To me it "ifconfig eth0 down" means not only to stop using the I/F
> but also any IP address associated with the I/F.

IP addresses are associated with the host, not a particular interface.

Therefore the state of the interface should not influence the behavior
of the IP address.

If you want the IP address to stop being responded to, delete the IP
address.

Re: [PATCH net-next-2.6] ipv4: sysctl to block responding on down interface

[Joakim Tjernlund]

David Miller <davem@davemloft.net> wrote on 2010/06/28 23:57:44:
>
> From: Joakim Tjernlund <joakim.tjernlund@transmode.se>
> Date: Mon, 28 Jun 2010 23:09:02 +0200
>
> > To me it "ifconfig eth0 down" means not only to stop using the I/F
> > but also any IP address associated with the I/F.
>
> IP addresses are associated with the host, not a particular interface.
>
> Therefore the state of the interface should not influence the behavior
> of the IP address.
>
> If you want the IP address to stop being responded to, delete the IP
> address.

This is an strict interpretation of the weak host model and does not
answer my questions. Mind to elaborate why such a strict view and
what is gained by answering on an IP address which has been "downed"?
What types of apps use this property?

 Jocke

Re: [PATCH net-next-2.6] ipv4: sysctl to block responding on down interface

[David Miller]

From: Joakim Tjernlund <joakim.tjernlund@transmode.se>
Date: Tue, 29 Jun 2010 01:30:26 +0200

> This is an strict interpretation of the weak host model and does not
> answer my questions. Mind to elaborate why such a strict view and
> what is gained by answering on an IP address which has been "downed"?

IP addresses are never "downed" just as your default route is not
"downed" when you take down an interface.

Rather, hosts are configured with an IP address and when they are so
configured they respond to it and can generate local application
sourced packets with that IP address as a source.

And what this means is that even in situations where hosts are
slightly mis-configured communication between them can still be
possible.  That's the goal of the weak host model, to get a host
respond to IP datagrams in every situation where such an act is
plausible.

All of the design decisions we've made in the networking in this area
are meant to increase the likelyhood of successful communication
between two hosts.

And in the 10+ years this behavior has existed, I know for sure that
people have ended up with a working networking because of the way we
do things.

So from that perspective it doesn't matter one iota what you or any
other particular entity wish things to be, since 10+ years of having
this behavior is ingrained enough that changing it is guarenteed to
break someone's setup so we absolutely can't do it.

This topic comes up at least once every few months, therefore someone
should post a FAQ somewhere because it's tiring to explain over and
over again why this is a good design decision and why the default
behavior is never going to change.

The RFCs allow both models equally, and just because many other
system does things the other way doesn't make it any better or more
valid than what Linux is doing.

Re: [PATCH net-next-2.6] ipv4: sysctl to block responding on down interface

[Andi Kleen]

Joakim Tjernlund <joakim.tjernlund@transmode.se> writes:

> Stephen Hemminger <shemminger@vyatta.com> wrote on 2010/06/11 17:48:54:
>>
>> When Linux is used as a router, it is undesirable for the kernel to process
>> incoming packets when the address assigned to the interface is down.
>> The initial problem report was for a management application that used ICMP
>> to check link availability.
>>
>> The default is disabled to maintain compatibility with previous behavior.
>> This is not recommended for server systems because it makes fail over more
>> difficult, and does not account for configurations where multiple interfaces
>> have the same IP address.
>>
>> Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
>
> Ping David et. all?
> I too want this.

Doesn't arpfilter enable this already? If you set in on the still up
interfaces those will not answer to other IP addresses.

This only works on the ARP level, so it has to wait until the arp
cache in the remote host times out.

-Andi
-- 
ak@linux.intel.com -- Speaking for myself only.

Re: [PATCH net-next-2.6] ipv4: sysctl to block responding on down interface

[Joakim Tjernlund]

Andi Kleen <andi@firstfloor.org> wrote on 2010/07/01 13:23:21:
>
> Joakim Tjernlund <joakim.tjernlund@transmode.se> writes:
>
> > Stephen Hemminger <shemminger@vyatta.com> wrote on 2010/06/11 17:48:54:
> >>
> >> When Linux is used as a router, it is undesirable for the kernel to process
> >> incoming packets when the address assigned to the interface is down.
> >> The initial problem report was for a management application that used ICMP
> >> to check link availability.
> >>
> >> The default is disabled to maintain compatibility with previous behavior.
> >> This is not recommended for server systems because it makes fail over more
> >> difficult, and does not account for configurations where multiple interfaces
> >> have the same IP address.
> >>
> >> Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
> >
> > Ping David et. all?
> > I too want this.
>
> Doesn't arpfilter enable this already? If you set in on the still up
> interfaces those will not answer to other IP addresses.
>
> This only works on the ARP level, so it has to wait until the arp
> cache in the remote host times out.

I tried that but it didn't work, but I didn't think of clearing
the ARP cache.
Anyhow, such methods seems worse than just doing ifconfig 0.0.0.0

  Jocke

Re: Weak host model vs .interface down

[Rick Jones]

Joakim Tjernlund wrote:
> Linux uses the weak host model which makes the IP addresses part of the system
> rather than the interface. However consider this:
> 
> System A, eth0 connected to the network
> # > ifconfig eth0 192.168.1.16
> # > ifconfig eth1 192.168.1.17 down
> 
> System B
> # > ping 192.168.1.17
> PING 192.168.1.17 (192.168.1.17) 56(84) bytes of data.
> 64 bytes from 192.168.1.17: icmp_seq=1 ttl=64 time=0.618 ms
> 
> Isn't it a bit much to respond on 192.168.1.17 when its interface is down?

As you said at the beginning, the weak end system model presumes the IP address 
is part of the system.  Seems to me that means unless one removes the IP address 
from the system it is reasonable for the system to continue to respond to that 
IP address.  Regardless of what happens to any individual interface.

Now, I wouldn't expect it to continue to respond to 192.168.1.17 through eth1, 
but if eth0 is indeed connected to the same broadcast domain, given the 
following of the weak end-system model, continuing to respond seems consistent 
with enthusiasticaly following the weak end-system model.

rick jones

Re: Weak host model vs .interface down

[Joakim Tjernlund]

Rick Jones <rick.jones2@hp.com> wrote on 2010/06/11 18:32:20:
> Joakim Tjernlund wrote:
> > Linux uses the weak host model which makes the IP addresses part of the system
> > rather than the interface. However consider this:
> >
> > System A, eth0 connected to the network
> > # > ifconfig eth0 192.168.1.16
> > # > ifconfig eth1 192.168.1.17 down
> >
> > System B
> > # > ping 192.168.1.17
> > PING 192.168.1.17 (192.168.1.17) 56(84) bytes of data.
> > 64 bytes from 192.168.1.17: icmp_seq=1 ttl=64 time=0.618 ms
> >
> > Isn't it a bit much to respond on 192.168.1.17 when its interface is down?
>
> As you said at the beginning, the weak end system model presumes the IP address
> is part of the system.  Seems to me that means unless one removes the IP address
> from the system it is reasonable for the system to continue to respond to that
> IP address.  Regardless of what happens to any individual interface.

The weak model doesn't go into such detail, it is assumption/impl. detail
to assume that the ip address still is part of the system even when the interface
is down. One could just as well define interface down as temporarly removing
the IP address from the system too. This makes make much more sense to me and
if you always want the system to answer on a IP adress you make it an IP alias.

Since the current behaviour is a problem to me and routers in general, can
we change this? What is the current usage model which needs it to stay as is?

>
> Now, I wouldn't expect it to continue to respond to 192.168.1.17 through eth1,
> but if eth0 is indeed connected to the same broadcast domain, given the
> following of the weak end-system model, continuing to respond seems consistent
> with enthusiasticaly following the weak end-system model.

Dosnt matter if it is in the same broadcast domain, you can use a bridge
interface or dummy interface too. It will still respond to 192.168.1.17
I can't find a way disable this behaviour, can you?

Re: Weak host model vs .interface down

[Rick Jones]

> The weak model doesn't go into such detail, it is assumption/impl. detail
> to assume that the ip address still is part of the system even when the interface
> is down. One could just as well define interface down as temporarly removing
> the IP address from the system too. This makes make much more sense to me and
> if you always want the system to answer on a IP adress you make it an IP alias.
> 
> Since the current behaviour is a problem to me and routers in general, can
> we change this? What is the current usage model which needs it to stay as is?

Router != end-system  so I wouldn't think the weak or strong end-system model 
would apply to a router.  I think Stephen already posted a patch to allow that 
for when one's box was a router rather than an end-system.

rick jones
It's a router!
No, it's an end-system!
...
http://snltranscripts.jt.org/75/75ishimmer.phtml

Re: Weak host model vs .interface down

[Joakim Tjernlund]

Rick Jones <rick.jones2@hp.com> wrote on 2010/06/11 19:13:42:
>
> > The weak model doesn't go into such detail, it is assumption/impl. detail
> > to assume that the ip address still is part of the system even when the interface
> > is down. One could just as well define interface down as temporarly removing
> > the IP address from the system too. This makes make much more sense to me and
> > if you always want the system to answer on a IP adress you make it an IP alias.
> >
> > Since the current behaviour is a problem to me and routers in general, can
> > we change this? What is the current usage model which needs it to stay as is?
>
> Router != end-system  so I wouldn't think the weak or strong end-system model
> would apply to a router.  I think Stephen already posted a patch to allow that
> for when one's box was a router rather than an end-system.

Not really an anwser to what I was asking but I choose to read that as
you agree with me. The rest is an impl. detail. :)
Stephen's patch is good but I would not mind making I/F down removing the
IP address from the system unconditionally.

 Jocke

Re: Weak host model vs .interface down

[Mark Smith]

On Fri, 11 Jun 2010 21:41:45 +0200
Joakim Tjernlund <joakim.tjernlund@transmode.se> wrote:

> Rick Jones <rick.jones2@hp.com> wrote on 2010/06/11 19:13:42:
> >
> > > The weak model doesn't go into such detail, it is assumption/impl. detail
> > > to assume that the ip address still is part of the system even when the interface
> > > is down. One could just as well define interface down as temporarly removing
> > > the IP address from the system too. This makes make much more sense to me and
> > > if you always want the system to answer on a IP adress you make it an IP alias.
> > >
> > > Since the current behaviour is a problem to me and routers in general, can
> > > we change this? What is the current usage model which needs it to stay as is?
> >
> > Router != end-system  so I wouldn't think the weak or strong end-system model
> > would apply to a router.  I think Stephen already posted a patch to allow that
> > for when one's box was a router rather than an end-system.
> 
> Not really an anwser to what I was asking but I choose to read that as
> you agree with me. The rest is an impl. detail. :)
> Stephen's patch is good but I would not mind making I/F down removing the
> IP address from the system unconditionally.
> 

I've asked the same question a few years back and got the same answer.
I accept the strong host / weak host argument, however I've also
thought about the problem a bit more, and why people get confused about
it.

The problem is the mental model. Assigning an IP address to an
interface implies that the IP address as attached and associated with
the interface and therefore the state of the interface. That is
certainly the case for people like me who work with networking
equipment, typically routers, which follow the strong host model. It is
very convenient to know that by shutting down an interface the
associated IP address stops working too. Other measures, such as
ACLing, or writing down and deleting and then having put it back, are
relatively much more effort and error prone.

While I'm sure past operational history is likely to make this
impractical, it would be far more intuitive for weak host model IP
address assignments to be made to a single, forced always up virtual
interface on the host, and strong host IP address assignments made to
any other "non-weak host" interfaces.

It'd be an interesting experiment to see if loopback could be used as a
"host interface" in the weak host model.

Regards,
Mark.

Re: Weak host model vs .interface down

[Joakim Tjernlund]

Mark Smith <lk-netdev@lk-netdev.nosense.org> wrote on 2010/06/12 01:57:48:
>
> On Fri, 11 Jun 2010 21:41:45 +0200
> Joakim Tjernlund <joakim.tjernlund@transmode.se> wrote:
>
> > Rick Jones <rick.jones2@hp.com> wrote on 2010/06/11 19:13:42:
> > >
> > > > The weak model doesn't go into such detail, it is assumption/impl. detail
> > > > to assume that the ip address still is part of the system even when the interface
> > > > is down. One could just as well define interface down as temporarly removing
> > > > the IP address from the system too. This makes make much more sense to me and
> > > > if you always want the system to answer on a IP adress you make it an IP alias.
> > > >
> > > > Since the current behaviour is a problem to me and routers in general, can
> > > > we change this? What is the current usage model which needs it to stay as is?
> > >
> > > Router != end-system  so I wouldn't think the weak or strong end-system model
> > > would apply to a router.  I think Stephen already posted a patch to allow that
> > > for when one's box was a router rather than an end-system.
> >
> > Not really an anwser to what I was asking but I choose to read that as
> > you agree with me. The rest is an impl. detail. :)
> > Stephen's patch is good but I would not mind making I/F down removing the
> > IP address from the system unconditionally.
> >
>
> I've asked the same question a few years back and got the same answer.
> I accept the strong host / weak host argument, however I've also
> thought about the problem a bit more, and why people get confused about
> it.
>
> The problem is the mental model. Assigning an IP address to an
> interface implies that the IP address as attached and associated with
> the interface and therefore the state of the interface. That is
> certainly the case for people like me who work with networking
> equipment, typically routers, which follow the strong host model. It is
> very convenient to know that by shutting down an interface the
> associated IP address stops working too. Other measures, such as
> ACLing, or writing down and deleting and then having put it back, are
> relatively much more effort and error prone.

Very well put!

>
> While I'm sure past operational history is likely to make this
> impractical, it would be far more intuitive for weak host model IP
> address assignments to be made to a single, forced always up virtual
> interface on the host, and strong host IP address assignments made to
> any other "non-weak host" interfaces.
>
> It'd be an interesting experiment to see if loopback could be used as a
> "host interface" in the weak host model.

Or you can use the dummy I/F too. I have used lo/dummy to assign a host/system
address and it works fine. I am not aware of any limitations but if there are
I am sure someone will point them out :)

 Jocke

Re: Weak host model vs .interface down

[Mitchell Erblich]

On Jun 11, 2010, at 10:06 AM, Joakim Tjernlund wrote:

> Rick Jones <rick.jones2@hp.com> wrote on 2010/06/11 18:32:20:
>> Joakim Tjernlund wrote:
>>> Linux uses the weak host model which makes the IP addresses part of the system
>>> rather than the interface. However consider this:
>>> 
>>> System A, eth0 connected to the network
>>> # > ifconfig eth0 192.168.1.16
>>> # > ifconfig eth1 192.168.1.17 down
>>> 
>>> System B
>>> # > ping 192.168.1.17
>>> PING 192.168.1.17 (192.168.1.17) 56(84) bytes of data.
>>> 64 bytes from 192.168.1.17: icmp_seq=1 ttl=64 time=0.618 ms
>>> 
>>> Isn't it a bit much to respond on 192.168.1.17 when its interface is down?
>> 
>> As you said at the beginning, the weak end system model presumes the IP address
>> is part of the system.  Seems to me that means unless one removes the IP address
>> from the system it is reasonable for the system to continue to respond to that
>> IP address.  Regardless of what happens to any individual interface.
> 
> The weak model doesn't go into such detail, it is assumption/impl. detail
> to assume that the ip address still is part of the system even when the interface
> is down. One could just as well define interface down as temporarly removing
> the IP address from the system too. This makes make much more sense to me and
> if you always want the system to answer on a IP adress you make it an IP alias.
> 
> Since the current behaviour is a problem to me and routers in general, can
> we change this? What is the current usage model which needs it to stay as is?
> 
>> 
>> Now, I wouldn't expect it to continue to respond to 192.168.1.17 through eth1,
>> but if eth0 is indeed connected to the same broadcast domain, given the
>> following of the weak end-system model, continuing to respond seems consistent
>> with enthusiasticaly following the weak end-system model.
> 
> Dosnt matter if it is in the same broadcast domain, you can use a bridge
> interface or dummy interface too. It will still respond to 192.168.1.17
> I can't find a way disable this behaviour, can you?
> 
> --

Guys

Isn't this the diff between models of a host/end system and a 
router/intermediate system?

Can you verify that xmit capability on the intf is disabled with the 
down arg?

IMO, One possible behaviour is to allow the receipt of a magic
packet to bring up a down system for the "energy star protocol".

Mitchell Erblich



		

		
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Weak host model vs .interface down

[Joakim Tjernlund]

Mitchell Erblich <erblichs@earthlink.net> wrote on 2010/06/11 21:50:14:
>
>
> On Jun 11, 2010, at 10:06 AM, Joakim Tjernlund wrote:
>
> > Rick Jones <rick.jones2@hp.com> wrote on 2010/06/11 18:32:20:
> >> Joakim Tjernlund wrote:
> >>> Linux uses the weak host model which makes the IP addresses part of the system
> >>> rather than the interface. However consider this:
> >>>
> >>> System A, eth0 connected to the network
> >>> # > ifconfig eth0 192.168.1.16
> >>> # > ifconfig eth1 192.168.1.17 down
> >>>
> >>> System B
> >>> # > ping 192.168.1.17
> >>> PING 192.168.1.17 (192.168.1.17) 56(84) bytes of data.
> >>> 64 bytes from 192.168.1.17: icmp_seq=1 ttl=64 time=0.618 ms
> >>>
> >>> Isn't it a bit much to respond on 192.168.1.17 when its interface is down?
> >>
> >> As you said at the beginning, the weak end system model presumes the IP address
> >> is part of the system.  Seems to me that means unless one removes the IP address
> >> from the system it is reasonable for the system to continue to respond to that
> >> IP address.  Regardless of what happens to any individual interface.
> >
> > The weak model doesn't go into such detail, it is assumption/impl. detail
> > to assume that the ip address still is part of the system even when the interface
> > is down. One could just as well define interface down as temporarly removing
> > the IP address from the system too. This makes make much more sense to me and
> > if you always want the system to answer on a IP adress you make it an IP alias.
> >
> > Since the current behaviour is a problem to me and routers in general, can
> > we change this? What is the current usage model which needs it to stay as is?
> >
> >>
> >> Now, I wouldn't expect it to continue to respond to 192.168.1.17 through eth1,
> >> but if eth0 is indeed connected to the same broadcast domain, given the
> >> following of the weak end-system model, continuing to respond seems consistent
> >> with enthusiasticaly following the weak end-system model.
> >
> > Dosnt matter if it is in the same broadcast domain, you can use a bridge
> > interface or dummy interface too. It will still respond to 192.168.1.17
> > I can't find a way disable this behaviour, can you?
> >
> > --
>
> Guys
>
> Isn't this the diff between models of a host/end system and a
> router/intermediate system?

Not sure what you mean here, but there is no such assumtion in
the models.

>
> Can you verify that xmit capability on the intf is disabled with the
> down arg?

umm, isn't that true by definition? if an I/F is put into down state, it
cannot xmit nor receive.

>
> IMO, One possible behaviour is to allow the receipt of a magic
> packet to bring up a down system for the "energy star protocol".

isn't that something totally different? I cannot se how that relates
to the matter at hand.

 Jocke