Weak host model vs .interface down
Subsystems (4)
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 1/1 ipv4: sysctl to block responding on down interface
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.
--- 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(+)
include/linux/inetdevice.h +2 -0
@@ -37,6 +37,7 @@ enumIPV4_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;
net/ipv4/devinet.c +1 -0
@@ -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"),
net/ipv4/route.c +7 -0
@@ -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);
Documentation/networking/ip-sysctl.txt +10 -0
@@ -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
David Miller
maintainerRe: [PATCH net-next-2.6] ipv4: sysctl to block responding on down interface
From: Stephen Hemminger <[email protected]>
Date: Fri, 11 Jun 2010 08:48:54 -0700
Quoted 2 lines
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.
Quoted 4 lines
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
Quoted 11 lines · On Tue, 22 Jun 2010 10:15:37 -0700 (PDT) David Miller <[email protected]>…
From: Stephen Hemminger <[email protected]>
Date: Fri, 11 Jun 2010 08:48:54 -0700Quoted 2 lines
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.
Quoted 6 lines
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.
Quoted 8 lines
Quoted 4 lines
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.
David Miller
maintainerRe: [PATCH net-next-2.6] ipv4: sysctl to block responding on down interface
From: Stephen Hemminger <[email protected]>
Date: Wed, 30 Jun 2010 13:55:35 -0700
Quoted 7 lines
Quoted 3 lines
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
In reply to Stephen HemmingerStephen Hemminger <[email protected]> wrote on 2010/06/11 17:48:54:
Quoted 6 lines
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.
Quoted 6 lines
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 <[email protected]>
Ping David et. all?
I too want this.
Jocke
Re: [PATCH net-next-2.6] ipv4: sysctl to block responding on down interface
Quoted 12 lines · Joakim Tjernlund
Stephen Hemminger <[email protected]> wrote on 2010/06/11 17:48:54:
Quoted 11 lines
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.
Quoted 4 lines
Quoted 1 line
Signed-off-by Stephen Hemminger <[email protected]>Ping David et. all?
I too want this.
You probably missed David reply
Re: [PATCH net-next-2.6] ipv4: sysctl to block responding on down interface
Eric Dumazet <[email protected]> wrote on 2010/06/28 21:42:01:
Quoted 14 lines · Joakim Tjernlund
Quoted 12 lines
Stephen Hemminger <[email protected]> wrote on 2010/06/11 17:48:54:
Quoted 11 lines
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.
Quoted 8 lines
Quoted 4 lines
Quoted 1 line
Signed-off-by Stephen Hemminger <[email protected]>Ping David et. all?
I too want this.You probably missed David reply
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
Quoted 40 lines · Joakim Tjernlund
Eric Dumazet <[email protected]> wrote on 2010/06/28 21:42:01:
Quoted 14 lines · Joakim Tjernlund
Quoted 12 lines
Stephen Hemminger <[email protected]> wrote on 2010/06/11 17:48:54:
Quoted 11 lines
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.
Quoted 8 lines
Quoted 4 lines
Quoted 1 line
Signed-off-by Stephen Hemminger <[email protected]>Ping David et. all?
I too want this.You probably missed David reply
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.
Quoted 7 lines
Jocke
--
To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [email protected]
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
Mitchell Erblich <[email protected]> wrote on 2010/06/28 23:28:29:
Quoted 47 lines · Joakim Tjernlund
Quoted 44 lines
Eric Dumazet <[email protected]> wrote on 2010/06/28 21:42:01:
Quoted 14 lines · Joakim Tjernlund
Quoted 12 lines
Stephen Hemminger <[email protected]> wrote on 2010/06/11 17:48:54:
Quoted 11 lines
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.
Quoted 8 lines
Quoted 4 lines
Quoted 1 line
Signed-off-by Stephen Hemminger <[email protected]>Ping David et. all?
I too want this.You probably missed David reply
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
Quoted 7 lines
Quoted 4 lines
--
To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.htmlHey 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
David Miller
maintainerRe: [PATCH net-next-2.6] ipv4: sysctl to block responding on down interface
In reply to Joakim TjernlundFrom: Joakim Tjernlund <[email protected]>
Date: Mon, 28 Jun 2010 23:09:02 +0200
Quoted 2 lines
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
David Miller <[email protected]> wrote on 2010/06/28 23:57:44:
Quoted 7 lines
From: Joakim Tjernlund <[email protected]>
Date: Mon, 28 Jun 2010 23:09:02 +0200Quoted 2 lines
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.
Quoted 7 lines
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
David Miller
maintainerRe: [PATCH net-next-2.6] ipv4: sysctl to block responding on down interface
From: Joakim Tjernlund <[email protected]>
Date: Tue, 29 Jun 2010 01:30:26 +0200
Quoted 3 lines
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
In reply to Joakim TjernlundQuoted 12 lines · Joakim Tjernlund
Stephen Hemminger <[email protected]> wrote on 2010/06/11 17:48:54:
Quoted 11 lines
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.
Quoted 4 lines
Quoted 1 line
Signed-off-by Stephen Hemminger <[email protected]>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
Signature · 1 line
[email protected] -- Speaking for myself only.
Re: [PATCH net-next-2.6] ipv4: sysctl to block responding on down interface
Andi Kleen <[email protected]> wrote on 2010/07/01 13:23:21:
Quoted 17 lines
Quoted 14 lines · Joakim Tjernlund
Stephen Hemminger <[email protected]> wrote on 2010/06/11 17:48:54:
Quoted 12 lines
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 <[email protected]>
Quoted 8 lines
Quoted 2 lines
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
Quoted 7 lines · 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
Quoted 6 lines
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 msIsn'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
Rick Jones <[email protected]> wrote on 2010/06/11 18:32:20:
Quoted 13 lines
Quoted 12 lines · 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 downSystem 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
Quoted 6 lines
Quoted 1 line
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?
Quoted 5 lines
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?
Quoted 8 lines
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
Rick Jones <[email protected]> wrote on 2010/06/11 19:13:42:
Quoted 7 lines
Quoted 7 lines
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.
Quoted 6 lines
Quoted 2 lines
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
Quoted 11 lines · On Fri, 11 Jun 2010 21:41:45 +0200 Joakim Tjernlund…
Rick Jones <[email protected]> wrote on 2010/06/11 19:13:42:
Quoted 10 lines
Quoted 9 lines
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?
Quoted 9 lines
Quoted 3 lines
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.
Mark Smith <[email protected]> wrote on 2010/06/12 01:57:48:
Quoted 30 lines
Quoted 11 lines · On Fri, 11 Jun 2010 21:41:45 +0200 Joakim Tjernlund…
Rick Jones <[email protected]> wrote on 2010/06/11 19:13:42:
Quoted 10 lines
Quoted 9 lines
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?
Quoted 9 lines
Quoted 3 lines
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.
Quoted 9 lines
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!
Quoted 9 lines
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
Quoted 36 lines · Joakim Tjernlund
Rick Jones <[email protected]> wrote on 2010/06/11 18:32:20:
Quoted 13 lines
Quoted 12 lines · 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 downSystem 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 msQuoted 6 lines
Quoted 1 line
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?
Quoted 5 lines
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.
Quoted 5 lines
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
Quoted 3 lines
To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Mitchell Erblich <[email protected]> wrote on 2010/06/11 21:50:14:
Quoted 44 lines · Joakim Tjernlund
Quoted 41 lines
Rick Jones <[email protected]> wrote on 2010/06/11 18:32:20:
Quoted 13 lines
Quoted 12 lines · 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 downSystem 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 msQuoted 6 lines
Quoted 1 line
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?
Quoted 5 lines
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?
Quoted 6 lines
Quoted 1 line
--
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.
Quoted 3 lines
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.
Quoted 3 lines
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