Re: IP address aliases
- From: phil-news-nospam@xxxxxxxx
- Date: 14 Jun 2007 03:48:43 GMT
On Wed, 13 Jun 2007 16:28:57 +0200 Rainer Weikusat <rweikusat@xxxxxxxxxxx> wrote:
| phil-news-nospam@xxxxxxxx writes:
|> On Wed, 13 Jun 2007 03:41:08 -0000 ellis@xxxxxxx wrote:
|> | In article <f4m4ef125ah@xxxxxxxxxxxxxxxxx>, <phil-news-nospam@xxxxxxxx> wrote:
|> |
|> |>That's the say it should be. We're getting there. But we still have things
|> |>working as if we put _addresses_ on interfaces.
|> |
|> | I suspect the reasons for that are a bit historic. ;)
|>
|> I know so :-)
|>
|> But as long as we recognize it, and agree that forward is the direction
|> to be going, we can fix it.
|>
|> One fix we need is the ability to bind a subnet to an interface _without_
|> binding an address (to that interface). Then _any_ IP address can be added
|> or deleted at any time without impacting the association of subnet to an
|> interface. And _any_ subnet-to-interface association can be changed without
|> impacting what IP addresses are recognized by the system.
|
| I do not quite understand what you mean by 'associating a subnet with
| an interface'. You can creates routes to particular subnets that go
| through a particular interface, eg
|
| ip ro add 192.168.17.0/24 dev eth1
|
| without having an IP contained in this range bound to the interace.
| It is possible to bind and unbind such IPs on the particular interface
| without affecting the existing route.
So if all I do is make routes to specific interfaces (or nexthops on those
subnets for subnets not directly connected) and add IP addresses only to the
machine (not to any interface except for "lo" as the machine), this all works?
| But in the end, this just again means that a particular protocol
| address has to be associated with a host, which is defined as being a
| computer that does not try to police traffic depending on where it
| came from. And this simply isn't a remotely general case for
| multi-homed hosts. An IP network is a 'logicallly structured' thing,
| not an electrically structured one.
I agree ... it should be that way.
|> |>We should change these so that the only things that get put on
|> |>interfaces are _subnets_ along with a specification of which
|> |>gateway that subnet goes to, or no gateway for local on the
|> |>segment. Then let there be addresses added without any need to
|> |>say what interface. then let saying the interface be an option
|> |>documented to be a convenience that address the necessary subnet
|> |>to the interface if it is not already there. We still have a
|> |>ways to go to achieve this. So lets do it.
|> |
|> | It might help with some of the confusion. But it also make calls
|> | for my services go down and that'd be a Bad Thing ;)
|>
|> Changes should not impact that.
|>
|> If a process has a socket already bound, connected or listen, to an IP
|> address, and that IP address is deleted, the effect should _not_ close
|> or unbind the socket.
|
| In the real world, there is one important scenario where this actually
| happens, and that is when there is an interface whose associated
| protocol address was dynamically allocated by some external entity
| (ISP) and which changes 'frequently' and 'unpredictably'. If this
| happens, existing sockets using the old address as source address of
| TCP connections will be unaffected, meaning, connectivity will just
| wither away and the process trying to use the connection will continue
| to wait forever for something to happen on this connection. If this
| happens, the socket should decidedly 'become unbound', so that the
| processe has a chance to notice that its communication attempt has
| irrevocably failed and can take 'some appropriate action' (ie
| reconnect and retry).
I would expect some kind of timeout, eventually.
| This is important enough for the kind of devices I have to deal with
| that I have implemented it in the kernel for a second time. We
| actually had customer phonecalls because of devices that became
| inoperative just because of this 'feature'.
Timeouts need to be chosen carefully, too.
--
|---------------------------------------/----------------------------------|
| Phil Howard KA9WGN (ka9wgn.ham.org) / Do not send to the address below |
| first name lower case at ipal.net / spamtrap-2007-06-13-2239@xxxxxxxx |
|------------------------------------/-------------------------------------|
.
- References:
- IP address aliases
- From: phil-news-nospam
- Re: IP address aliases
- From: Grant Edwards
- Re: IP address aliases
- From:
- Re: IP address aliases
- From: phil-news-nospam
- Re: IP address aliases
- From:
- Re: IP address aliases
- From: phil-news-nospam
- Re: IP address aliases
- From: Rainer Weikusat
- IP address aliases
- Prev by Date: bh-handler latency issues
- Next by Date: Exact differences between Unix and Linux
- Previous by thread: Re: IP address aliases
- Next by thread: Re: IP address aliases
- Index(es):
Relevant Pages
|