Which entry of the routing table was selected?
Alex Vinokur
===========================================================================
Active Routes:
Network Destination Netmask Gateway Interface
Metric
0.0.0.0 0.0.0.0 138.139.0.1 138.139.92.167
20
10.1.1.0 255.255.255.0 10.1.1.125 10.1.1.125
20
10.1.1.125 255.255.255.255 127.0.0.1 127.0.0.1
20
10.255.255.255 255.255.255.255 10.1.1.125 10.1.1.125
20
127.0.0.0 255.0.0.0 127.0.0.1 127.0.0.1 1
138.139.0.0 255.255.0.0 138.139.92.167 138.139.92.167
20
138.139.92.167 255.255.255.255 127.0.0.1 127.0.0.1
20
138.139.255.255 255.255.255.255 138.139.92.167 138.139.92.167
20
224.0.0.0 240.0.0.0 10.1.1.125 10.1.1.125
20
224.0.0.0 240.0.0.0 138.139.92.167 138.139.92.167
20
255.255.255.255 255.255.255.255 10.1.1.125 10.1.1.125 1
255.255.255.255 255.255.255.255 138.139.92.167 138.139.92.167 1
Default Gateway: 138.139.0.1
===========================================================================
Persistent Routes:
None
Messages were sent to IP-destination = 10.1.1.1 using UDP Sockets
1. Messages were sent from IP-source = 10.1.1.125
IP-destination = 10.1.1.1 has received these messages.
The messages were routed according to second entry of the routing
table:
Network Destination Netmask Gateway Interface
Metric
10.1.1.0 255.255.255.0 10.1.1.125 10.1.1.125
20 // Second entry
2. Messages were sent from IP-source = 138.139.92.167
IP-destination = 10.1.1.1 has received these messages too.
According to which entry of the routing table were the messages
routed in this case?
Alex Vinokur
email: alex DOT vinokur AT gmail DOT com
http://mathforum.org/library/view/10978.html
http://sourceforge.net/users/alexvn
Walter Roberson
>2. Messages were sent from IP-source = 138.139.92.167
> IP-destination = 10.1.1.1 has received these messages too.
> According to which entry of the routing table were the messages
>routed in this case?
The source IP is not considered in the routing decisions.
Barry Margolin
"Alex Vinokur" <ale...@users.sourceforge.net> wrote:
The same one, of course. Routing is based only on destination address.
--
Barry Margolin, bar...@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
*** PLEASE don't copy me on replies, I'll read them in the group ***
Alex Vinokur
What is the "Interface" column? Is there any connection between
"Interface" and source IP in a message sent?
Barry Margolin
"Alex Vinokur" <ale...@users.sourceforge.net> wrote:
> Walter Roberson wrote:
> > In article <1146978035.5...@j73g2000cwa.googlegroups.com>,
> > Alex Vinokur <ale...@users.sourceforge.net> wrote:
> > >Here is a routing table on PC.
> >
> > >2. Messages were sent from IP-source = 138.139.92.167
> > > IP-destination = 10.1.1.1 has received these messages too.
> > > According to which entry of the routing table were the messages
> > >routed in this case?
> >
> > The source IP is not considered in the routing decisions.
>
> What is the "Interface" column? Is there any connection between
> "Interface" and source IP in a message sent?
If the application doesn't call bind() to specify the source address of
an outgoing connection, the address of the outgoing interface will be
used as the default.
Alex Vinokur
> In article <1146990455.5...@j73g2000cwa.googlegroups.com>,
> "Alex Vinokur" <ale...@users.sourceforge.net> wrote:
> > What is the "Interface" column? Is there any connection between
> > "Interface" and source IP in a message sent?
>
> If the application doesn't call bind() to specify the source address of
> an outgoing connection, the address of the outgoing interface will be
> used as the default.
>
Suppose, the application does call bind() to specify the source IP address in a message to be sent.
Let the "Interface" column of the routing table contain only three different IP addresses:
* 138.139.92.167
* 10.1.1.125
* 127.0.0.1
1) Does it mean that the source IP address can be only one of those IP addresses (138.139.92.167, 10.1.1.125, 127.0.0.1)?
2) If the answer on the previous question is "Yes", does it mean that "Interface" IP address in selected entries must be equal the
source IP address, i.e.,
* only entries with Interface IP = 138.139.92.167 is selected for source IP address = 138.139.92.167;
* only entries with Interface IP = 10.1.1.125 is selected for source IP address = 10.1.1.125;
* only entries with Interface IP = 127.0.0.1 is selected for source IP address = 127.0.0.1?
--
Walter Roberson
Alex Vinokur <ale...@users.sourceforge.net> wrote:
>Suppose, the application does call bind() to specify the source IP
>address in a message to be sent.
>Let the "Interface" column of the routing table contain only three
>different IP addresses:
>1) Does it mean that the source IP address can be only one of those IP
>addresses (138.139.92.167, 10.1.1.125, 127.0.0.1)?
No. A sufficiently privileged process can create raw packets with
whatever IP address is desired.
>2) If the answer on the previous question is "Yes", does it mean that
>"Interface" IP address in selected entries must be equal the
>source IP address, i.e.,
>* only entries with Interface IP = 138.139.92.167 is selected for source
>IP address = 138.139.92.167;
>* only entries with Interface IP = 10.1.1.125 is selected for source IP
>address = 10.1.1.125;
>* only entries with Interface IP = 127.0.0.1 is selected for source IP
>address = 127.0.0.1?
No, we told you already that the source IP is not considered in
normal routing decisions. [In many systems, it is possible to replace
the normal routing process with one which routes based on "policies"
that might examine e.g. the source IP address, or destination port,
or even the content.]
Barry Margolin
robe...@hushmail.com (Walter Roberson) wrote:
> In article <445e1469$0$24995$834e...@reader.greatnowhere.com>,
> Alex Vinokur <ale...@users.sourceforge.net> wrote:
> >Suppose, the application does call bind() to specify the source IP
> >address in a message to be sent.
> >Let the "Interface" column of the routing table contain only three
> >different IP addresses:
>
> >1) Does it mean that the source IP address can be only one of those IP
> >addresses (138.139.92.167, 10.1.1.125, 127.0.0.1)?
>
> No. A sufficiently privileged process can create raw packets with
> whatever IP address is desired.
But ordinary applications calling bind() can only specify one of those
addresses. Any other address should result in an EADDRNOTAVAIL error I
think.
q_q_an...@yahoo.co.uk
Alex Vinokur wrote:
> Walter Roberson wrote:
> > In article <1146978035.5...@j73g2000cwa.googlegroups.com>,
> > Alex Vinokur <ale...@users.sourceforge.net> wrote:
> > >Here is a routing table on PC.
> >
> > >2. Messages were sent from IP-source = 138.139.92.167
> > > IP-destination = 10.1.1.1 has received these messages too.
> > > According to which entry of the routing table were the messages
> > >routed in this case?
> >
> > The source IP is not considered in the routing decisions.
>
> What is the "Interface" column? Is there any connection between
> "Interface" and source IP in a message sent?
>
i missed, did anybody mention interface column?
when I say router, I don't mean your 'home router'. - if you use one.
the thing with the modem built in.
your comp and router are the same box. The Network interface they each
use is the same. And has an IP. Interface is 'network interface'.
Type route print, you'll see the interface column, adjacent to the
gateway column.
typilcally, a router has all the diff ports, each is an interface. same
thing. Though your comp which is doubling as a router, has only 1
physical interface. Also, it has a logical interface 127.0.0.1
Anything sent to 127.0.0.0 255.255.255.0 goes there.
I guess all win xp comps double up as routers. though typically only
have 1 physical interface. When you send a packet, it goes to the
router (so hasn't gone far ;-) ). the router doesn't check to even see
that it came from 'the same box'. I guess in this case, your router
doesn't really have an ip. ('cos if it did it'd be teh same as the
comps). It's network interfaces that have IPs, so, there's no clash
there. There's only 1 network interface, being used as both a comp's
network interface and a router's network interface.
What confuses me, is, there isn't a physical interface on your comp and
the router, connecting your comp to the router. (it's the same box).
It has to be a logical interface and its IP must be for example
192.168.1.2 The same IP as the physical interface on your router
connecting it to the outside(your "home router"/modem box).
So it seems to me like there are 2 interfaces, one physical, one
logical, with the same ip. I wonder if that theory is right.
Albert Manfredi
Aside from implementing any additional packet filtering algorithms,
which I think the thread went on a tangent to discuss, I think I
disagree with some of the replies you got.
This first example is of a message from an interface on IP subnet
10.1.1.0 to the same IP subnet. So the second entry is used. It looks
like the PC also has an IP address of 10.1.1.125, which is already sits
in this 10.1.1.0 network.
> 2. Messages were sent from IP-source = 138.139.92.167
> IP-destination = 10.1.1.1 has received these messages too.
> According to which entry of the routing table were the messages
> routed in this case?
This second example is a message from another IP subnet, 138.139.0.0 to
the IP subnet 10.1.1.0. So interface 138.139.92.167 had to find a router
to the 10.1.1.0 subnet, and the first entry:
0.0.0.0 0.0.0.0 138.139.0.1 138.139.92.167 20
as well as the last entry:
Default Gateway: 138.139.0.1
are used.
Bert
q_q_an...@yahoo.co.uk
i'm with previous answers, that the second entry is used.
I only agree that 138.139.92.167 is on another subnet, so had to find a
router to the 10.1.1.0 subnet
However, 138.139.92.167 had its own routing table or bit of IP logic,
to find its router, and the packet arrived at the computer/router whose
routing table has been printed. Now, where will it be routed.
The ans is, second entry.
The default route is only chosen when a more specific one doesn't
exist. So first entry is not used. In this case, the second entry
10.1.1.0 is more specific, so it's chosen, and it's sent out again, to
reach local comp 10.1.1.1
q_q_an...@yahoo.co.uk
i'm with previous answers, that the second entry is used.
Albert Manfredi
> i'm with previous answers, that the second entry is used.
>
> I only agree that 138.139.92.167 is on another subnet, so had to find a
> router to the 10.1.1.0 subnet
By the looks of the routing table, 138.139.92.167 is another interface
of the SAME machine. And the messages were sent out of both interfaces
of this PC, it seems to me.
> However, 138.139.92.167 had its own routing table or bit of IP logic,
> to find its router, and the packet arrived at the computer/router whose
> routing table has been printed. Now, where will it be routed.
> The ans is, second entry.
>
> The default route is only chosen when a more specific one doesn't
> exist. So first entry is not used. In this case, the second entry
> 10.1.1.0 is more specific, so it's chosen, and it's sent out again, to
> reach local comp 10.1.1.1
Consider what happens to your logic when 138.139.92.167 is just another
NIC on this PC, though.
Bert
q_q_an...@yahoo.co.uk
Albert Manfredi wrote:
> q_q_an...@yahoo.co.uk wrote:
>
> > i'm with previous answers, that the second entry is used.
> >
> > I only agree that 138.139.92.167 is on another subnet, so had to find a
> > router to the 10.1.1.0 subnet
>
> By the looks of the routing table, 138.139.92.167 is another interface
> of the SAME machine. And the messages were sent out of both interfaces
> of this PC, it seems to me.
>
ah, you're right
thanks for the significant correction
> > However, 138.139.92.167 had its own routing table or bit of IP logic,
> > to find its router, and the packet arrived at the computer/router whose
> > routing table has been printed. Now, where will it be routed.
> > The ans is, second entry.
> >
> > The default route is only chosen when a more specific one doesn't
> > exist. So first entry is not used. In this case, the second entry
> > 10.1.1.0 is more specific, so it's chosen, and it's sent out again, to
> > reach local comp 10.1.1.1
>
> Consider what happens to your logic when 138.139.92.167 is just another
> NIC on this PC, though.
>
> Bert
Looking at what I think is your reason for saying first entry.
in order to have that source ip, (you think?) it had to have gone
through the first entry, the default route.. But why! there's a more
specific route. I'm not sure if that was your reason. But I kind of
run into that hole , and I can't fill it.
I think it's still the second entry.
the router receives the packet from that comp , it doesn't know that
it's kind of local. Doesn't matter. And it routes it out the second
entry, the most specific 10.1.1.0 10.1.1.125
The source IP is still 138.139.92.167 because that represents the
source ip of the comp that sent the packet, rather than the source ip
of the interface that the router sent the packet from.
Perhaps the comp can use any source ip it wants, when sending to the
router. Sicne the comp and router are connected logically and kind of
locally, it doesn't go out any interface to go from comp to router. So
this an unusual case where the box is the comp/router, and, for this
case, the source ip represents the source ip of one of the computer's
NICs, but not necessarily the NIC that the packet was sent out of. The
comp doesn't send the packet out. The purpose of that source ip is not
to say which NIC to send out of. But to ensure that packets received in
reply come back to the source.
Also. - for argument of second entry
A router doesn't know if it receives a packet from the same box ('cos
doubling up as a comp). Or from another computer. It acts exactly the
same.
What I wrote also explains how it acts exactly the same.
Thanks
Walter Roberson
Albert Manfredi <albert.e...@nospam.com> wrote:
>This second example is a message from another IP subnet, 138.139.0.0 to
>the IP subnet 10.1.1.0. So interface 138.139.92.167 had to find a router
>to the 10.1.1.0 subnet, and the first entry:
>0.0.0.0 0.0.0.0 138.139.0.1 138.139.92.167 20
>as well as the last entry:
>Default Gateway: 138.139.0.1
>are used.
No, the more specific entry gets used. If the destination is not
in the ARP table, then an ARP will be needed.
If a packet came in from a 10.1.1 source IP destined for
138.139, then which interface would it have come in on? If it
came in over the 138.139 interface then you have asymmetric routing
and things are allowed to break in that case. If it came in over
the 10.1.1 interface then the MAC would have been learned when
the packet was received.
So if there is a 138.139 packet to go out the 10.1.1 interface
then the MAC would normally be there for a reply packet
[unless the ARP entry timed out.] Neglecting the timeout case
for the moment, for a 138.139 packet to want to go out 10.1.1
and if there is no ARP entry, then the packet must be a new
flow. This is where it starts to get a bit messy.
In -most- operating systems, when an ARP needs to go out with
a particular source IP, the subnet broadcast address for that IP
is used, and if the destination is in a different subnet then
either you get no answer (and the flow fails) or else a device
proxy-ARPs in order to act as a router to get the packets to the
proper place.
In Windows 2000 and XP (and possibly a few others), if the the gateway
for an interface is in a different subnet, then an ARP for the gateway
is sent to the "all stations" broadcast IP (255.255.255.255), which
then answers directly [which it can do by reading the MAC off of the
ARP packet], and you get conversations flowing at layer 2 even
though the layer 3 is funky. This process is not invalid, but
it is unusual.
rex_ro...@lycos.com
the most specific match for the destination. Moreover, the source IP
should not matter or affect the way in which the destination entry is
picked up from the routing table.
Regards
Rex
Alex Vinokur
Walter Roberson wrote:
[snip]
> No, we told you already that the source IP is not considered in
> normal routing decisions. [In many systems, it is possible to replace
> the normal routing process with one which routes based on "policies"
> that might examine e.g. the source IP address, or destination port,
> or even the content.]
We consider only applications that have to call bind() to specify the
source address of an outgoing connection.
Part 1. Settings
Table 1.1. Routing table
=====================================================================================
Active Routes:
Network Destination Netmask Gateway Interface
Metric Entry#
-------------------------------------------------------------------------------------
A B C D
E
-------------------------------------------------------------------------------------
0.0.0.0 0.0.0.0 138.139.0.1 138.139.92.167
20 R1
10.1.1.0 255.255.255.0 10.1.1.125 10.1.1.125
20 R2
10.1.1.125 255.255.255.255 127.0.0.1 127.0.0.1
20 R3
10.255.255.255 255.255.255.255 10.1.1.125 10.1.1.125
20 R4
127.0.0.0 255.0.0.0 127.0.0.1 127.0.0.1 1
R5
138.139.0.0 255.255.0.0 138.139.92.167 138.139.92.167
20 R6
138.139.92.167 255.255.255.255 127.0.0.1 127.0.0.1
20 R7
138.139.255.255 255.255.255.255 138.139.92.167 138.139.92.167
20 R8
224.0.0.0 240.0.0.0 10.1.1.125 10.1.1.125
20 R9
224.0.0.0 240.0.0.0 138.139.92.167 138.139.92.167
20 R10
255.255.255.255 255.255.255.255 10.1.1.125 10.1.1.125 1
R11
255.255.255.255 255.255.255.255 138.139.92.167 138.139.92.167 1
R12
Default Gateway: 138.139.0.1
=====================================================================================
Persistent Routes:
None
> ipconfig
Ethernet adapter Local Area Connection 2:
Connection-specific DNS Suffix . :
IP Address. . . . . . . . . . . . : 10.1.1.125
Subnet Mask . . . . . . . . . . . : 255.255.255.0
Default Gateway . . . . . . . . . :
Ethernet adapter Local Area Connection:
Connection-specific DNS Suffix . : <name>
IP Address. . . . . . . . . . . . : 138.139.92.167
Subnet Mask . . . . . . . . . . . : 255.255.0.0
Default Gateway . . . . . . . . . : 138.139.0.1
Part 2. Tests
Table 2.1. Messages sent and received using UDP
sockets
=========================================================================================
|| Receiver
Sender
||------------------------------------------------------------------------
|| 138.139.92.167 : 10.1.1.125 : 127.0.0.1 |
138.18.198.178 | 10.1.1.1
-----------------------------------------------------------------------------------------
A || B : C : D | E
| F
-----------------------------------------------------------------------------------------
138.139.92.167 || Received : Received : Received | Received
| Received
10.1.1.125 || Received : Received : Received | Received
| Received
127.0.0.1 || Received : Received : Received | Not
Received | Not Received
=========================================================================================
Table 2.2. Routing for Table 2.1
==================================================================================================================
| | Entries of routing table for the
Receiver | Entry selected with longest prefix
| | per Interface according to
| among Interfaces
| | (Netmask && ReceiverIP) ==
DestinationIP |------------------------------------
Sender | Receiver
|-------------------------------------------| Interface equal to :
Among
| | 138.139.92.167 : 10.1.1.125 :
127.0.0.1 | SourceIP : all Interfaces
------------------------------------------------------------------------------------------------------------------
A | B | C : D : E
| F : G
------------------------------------------------------------------------------------------------------------------
138.139.92.167 | 138.139.92.167 | R6, R1 : : R7
| R6 (16 bits) : R7 (32 bits)
| 10.1.1.125 | R1 : R2 : R3
| R1 ( 0 bits) : R3 (32 bits)
| 127.0.0.1 | R1 : : R5
| R1 ( 0 bits) : R5 ( 8 bits)
| 138.18.198.178 | R1 : :
| R1 ( 0 bits) : R1 ( 0 bits)
| 10.1.1.1 | R1 : R2 :
| R1 ( 0 bits) : R2 (24 bits)
---------------|-----------------|----------------:------------:-------------|------------------------------------
10.1.1.125 | 138.139.92.167 | R6, R1 : : R7
| - : R7 (32 bits)
| 10.1.1.125 | R1 : R2 : R3
| R2 (24 bits) : R3 (32 bits)
| 127.0.0.1 | R1 : : R5
| - : R5 ( 8 bits)
| 138.18.198.178 | R1 : :
| - : R1 ( 0 bits)
| 10.1.1.1 | R1 : R2 :
| R2 (24 bits) : R2 (24 bits)
---------------|-----------------|----------------:------------:-------------|------------------------------------
127.0.0.1 | 138.139.92.167 | R6, R1 : : R7
| R7 (32 bits) : R7 (32 bits)
| 10.1.1.125 | R1 : R2 : R3
| R3 (32 bits) : R3 (32 bits)
| 127.0.0.1 | R1 : : R5
| R5 ( 8 bits) : R5 ( 8 bits)
==================================================================================================================
Table 2.3. Question: What are routing table's entries selected
for Table 2.1?
=========================================================================================
|| Receiver
Sender
||------------------------------------------------------------------------
|| 138.139.92.167 : 10.1.1.125 : 127.0.0.1 |
138.18.198.178 | 10.1.1.1
-----------------------------------------------------------------------------------------
A || B : C : D | E
| F
-----------------------------------------------------------------------------------------
138.139.92.167 || R7 or R6? : R3 or R1? : R5 or R1? | R1
| R2 or R1?
10.1.1.125 || R7? : R3 or R2? : R5? | R1?
| R2
127.0.0.1 || R7 : R3 : R5 | -
| -
=========================================================================================
P.S. It seems that the "Interface" column of routing doesn't matter
(for applications calling bind()
to specify the source address of an outgoing connection)? Is it truth?
Walter Roberson
>Walter Roberson wrote:
>[snip]
>> No, we told you already that the source IP is not considered in
>> normal routing decisions. [In many systems, it is possible to replace
>> the normal routing process with one which routes based on "policies"
>> that might examine e.g. the source IP address, or destination port,
>> or even the content.]
>We consider only applications that have to call bind() to specify the
>source address of an outgoing connection.
My response still holds. The potential alternative routing processes
I mention in my aside have nothing to do with whether bind() was
used or not. I don't know of any Windows software to do the
alternative routings, but it might exist. (It is fairly common in Linux,
as it is integrated into one of the common pieces of firewall software.)
> Part 2. Tests
Somehow I'm not surprised that homework or assignments or cert study
is behind these questions.
In future, if your questions come from an outside source, then
indicate what the source is, and tell us *your* reasoning about
the answer. People here are willing to -assist- others in their
learning processes, but are not willing to do their work for them.
bri...@encompasserve.org
> In article <Iyx1F...@news.boeing.com>,
> Albert Manfredi <albert.e...@nospam.com> wrote:
>
>>This second example is a message from another IP subnet, 138.139.0.0 to
>>the IP subnet 10.1.1.0. So interface 138.139.92.167 had to find a router
>>to the 10.1.1.0 subnet, and the first entry:
This sounds like some kind of hideous confusion about the interface
column in the Windows routing table printout -- as if the entries
in the routing table are only valid for traffic received on
the interface that is mentioned there.
Actually, the interface column simply selects an output interface.
This usually only becomes important when a particular next-hop
gateway address falls within the connected address range associated
with more than one interface. (e.g. two NICs on one subnet).
> In -most- operating systems, when an ARP needs to go out with
> a particular source IP, the subnet broadcast address for that IP
> is used, and if the destination is in a different subnet then
> either you get no answer (and the flow fails) or else a device
> proxy-ARPs in order to act as a router to get the packets to the
> proper place.
The subnet broadcast address? For ARP?
ARP is not IP.
ARP does not use IP.
> In Windows 2000 and XP (and possibly a few others), if the the gateway
> for an interface is in a different subnet, then an ARP for the gateway
> is sent to the "all stations" broadcast IP (255.255.255.255), which
> then answers directly [which it can do by reading the MAC off of the
> ARP packet], and you get conversations flowing at layer 2 even
> though the layer 3 is funky. This process is not invalid, but
> it is unusual.
The "all stations" broadcast IP? For ARP?
ARP is not IP
ARP does not use IP.
For good or ill, ARP uses the FF.FF.FF.FF.FF.FF broadcast address at
the link layer. Not the subnet broadcast address at the IP layer.
Or the all stations broadcast address at the IP layer.
Albert Manfredi
> Looking at what I think is your reason for saying first entry.
> in order to have that source ip, (you think?) it had to have gone
> through the first entry, the default route.. But why! there's a more
> specific route. I'm not sure if that was your reason. But I kind of
> run into that hole , and I can't fill it.
Yes, that was my thinking. Since one of the the source addresses was in
fact the 138.139.92.167 address, the message was forced to use that
interface.
I had suspected that this machine had two NICs, one on the 138.139.0.0
subnet and one on the 10.1.1.0 subnet (and I think that was confimed
now). And there is an external router between these two subnets as
well. So if a packet were forced to use the 138.139.92.167 interface
and was addressed to something in the 10.1.1.0 network, that packet
would then use the external router to find its destination.
I'm not saying this would be the normal default way of sending messages
from the PC to the 10.1.1.1 destination. I'm just saying that is how
they appear to have been sent. There's nothing impossible about forcing
packets out one of two NICs in a dual-homed host, even if that's not
the most efficient route.
Bert
Albert Manfredi
> If a packet came in from a 10.1.1 source IP destined for
> 138.139, then which interface would it have come in on?
It depends on whether the PC is set up as a router, and hosts on
10.1.1.0 know that it's a router, or whether the PC is just operating
as a dual-homed host.
In the former case, the packet from the 10.1.1.0 subnet to the
138.139.92.167 would go via the 10.1.1.125 interface of the PC. In the
latter case, the packet has to find that external router, and the hosts
on 10.1.1.0 would know about that other router. (The one with
138.139.1.1 address on the 138.139.0.0 subnet.)
> In Windows 2000 and XP (and possibly a few others), if the the gateway
> for an interface is in a different subnet, then an ARP for the gateway
> is sent to the "all stations" broadcast IP (255.255.255.255), which
> then answers directly [which it can do by reading the MAC off of the
> ARP packet], and you get conversations flowing at layer 2 even
> though the layer 3 is funky. This process is not invalid, but
> it is unusual.
I don't think ARP has anything to do with what the situation is here,
but just for interest:
ARP doesn't use IP addresses for delivering ARP frames. ARP is not an
IP protocol at all. ARP requests are always sent to a MAC all 1s
broadcast destination address. What happens is that inside the ARP
frame are the source and destination IP addresses. Hopefully, in cases
where the same wire supports multiple IP subnets (i.e. not the case in
this thread), an ARP reply is only sent when the requestor is in the
same IP subnet as the responder.
Even if one link layer supports multiple IP subnets, a packet going
between two different IP subnets on that wire have to go through the
router. So ARP is not involved, other than to find the hardware address
of the router.
Bert
Alex Vinokur
"Walter Roberson" <robe...@hushmail.com> wrote in message news:IOJ7g.139587$WI1.19193@pd7tw2no...
> In article <1147094052.8...@u72g2000cwu.googlegroups.com>, Alex Vinokur <ale...@users.sourceforge.net> wrote:
> >We consider only applications that have to call bind() to specify the
> >source address of an outgoing connection.
>
> My response still holds. The potential alternative routing processes
> I mention in my aside have nothing to do with whether bind() was
> used or not. I don't know of any Windows software to do the
> alternative routings, but it might exist. (It is fairly common in Linux,
> as it is integrated into one of the common pieces of firewall software.)
>
>
> > Part 2. Tests
>
> Somehow I'm not surprised that homework or assignments or cert study
> is behind these questions.
No homework/assignments/cert study is behind these questions.
>
> In future, if your questions come from an outside source, then
> indicate what the source is,
The source is me.
> and tell us *your* reasoning about
> the answer. People here are willing to -assist- others in their
> learning processes, but are not willing to do their work for them.
I came across incomprehensible (to me) traffic of UDP messages relatively the routing table.
--
Alex Vinokur
>
> Walter Roberson wrote:
> [snip]
> > No, we told you already that the source IP is not considered in
> > normal routing decisions. [In many systems, it is possible to replace
> > the normal routing process with one which routes based on "policies"
> > that might examine e.g. the source IP address, or destination port,
> > or even the content.]
>
>
> We consider only applications that have to call bind() to specify the
> source address of an outgoing connection.
The text with the example can be downloaded as separate file at
http://groups.google.com/group/sources/msg/8c110fe7d284e617 (file routing-table.txt).
--
q_q_an...@yahoo.co.uk
I guess windows does that(forcing or choosing between 2 equally
efficient routes) using the Metric. If so, (if it can choose between
unequally efficient routes nad force to the less effiicient) then, even
in this case, it looks ilke the metric is the same for efficieint and
the inefficent rotue . So effiicient route should be chosen.
Besides using the metric to force (which I only guess at). Maybe it's
poss for a prog to send a packet bypassing the router aspect of the
computer. But then it doesn't get 'routed'. Or it does, but not using a
routing table and nto using that one. Though anyhow, I dont thin'
that's the case here.
is there a hole in my view of reasoning the second entry? (that the
source ip represents the ip of the comp, not the interface of the
router that the packet goes out of).
Albert Manfredi
> is there a hole in my view of reasoning the second entry? (that the
> source ip represents the ip of the comp, not the interface of the
> router that the packet goes out of).
I could be wrong about this, but as far as I know, if a host transmits
an IP datagram out of a given interface, the IP Source Address is the
address of that interface. Not some other interface the host may also
have.
In this example, the PC *may* be operating as a router, in which case
the situation is a little murkier. If the host is set up as a router,
but is only transmitting IP datagrams it generates internally, why would
it ever use the IP source address of the "wrong" interface? I don't
think this should ever happen. When routers transfer routing protocol
messages among themselves, for example, don't they always use the source
IP of the port the datagram originates from?
Bert
bri...@encompasserve.org
> <q_q_an...@yahoo.co.uk> wrote:
>
>> is there a hole in my view of reasoning the second entry? (that the
>> source ip represents the ip of the comp, not the interface of the
>> router that the packet goes out of).
>
> I could be wrong about this, but as far as I know, if a host transmits
> an IP datagram out of a given interface, the IP Source Address is the
> address of that interface. Not some other interface the host may also
> have.
>
> In this example, the PC *may* be operating as a router, in which case
> the situation is a little murkier. If the host is set up as a router,
> but is only transmitting IP datagrams it generates internally, why would
> it ever use the IP source address of the "wrong" interface?
Consider a multi-homed PC configured to operate as a DNS server.
In the typical case, DNS uses UDP port 53.
The server PC has interface 1.1.1.1 and 2.2.2.2.
A client, at 7.7.7.7 sends a DNS query to 1.1.1.1. The DNS server
software does its thing and generates a reply packet addressed to
7.7.7.7.
If the DNS software does not specify the source IP address for the
response packet, the TCP stack will fill in the source IP address
by default. If the packet is routed out the 1.1.1.1 interface,
the source address will be 1.1.1.1 and all is well.
If the packet is routed out the 2.2.2.2 interface the source
address on the response will be 2.2.2.2 and the client will
ignore it. The client is expecting a response from 1.1.1.1 after all.
In order to avoid this problem, DNS software takes pains to
generate reply packets with the source address that the client
addressed the original query to.
This may well be the "wrong" interface in your sense.
q_q_an...@yahoo.co.uk
I haven't really studied routing protocols , (though they only
populate/fill routing tables).
But I think if a router generaets a packet, (not forwarding), then it
probably would use the ip of the interface it sends the packet out of.
(though I guess it needn't, there's no reason not to). But in this
case, the router isn't generating the packet, the comp generates it and
the router forwards it.
I think rotuers don't know or care what port the ip datagram originates
from - unless they originated it. They don't ever change the source IP
of the packet they receive. They don't even look at it. As far as the
router is concerned, it's not generated internally, it's received from
a computer.. It's not generated by the router. If it were generated by
the router then the origianl ip would prob be the interface it's sent
out from. But in this case, the packet is generated by the computer.
(if it were generated by a router, I guess the question would say so)
So, the software in the computer chose one of the comp's IPs. For a
good reason or no reason. heh, maybe the software didn't even notice
the comp had 2 NICS . Or maybe the software just didn't care.Any of the
comp's IPs will do Infact, a good reason for not caring, is if it'll
still be routed the same anyway (so same efficiency) - which if it is
second entry, then it is.
I imagine a sort of logical connection between comp and router. using
logical interfaces. In whose IPs match those on those shared NICs.
Either one logical interface with - imagine 2 ips - or. 2 logcial
interfaces with those ips. Key is, it orgiinates with the comp and
get sent to the router. The router treats it just as any other comp
physically connected to the router. Maybe somebody that knows behind
the scenes can fill in here?
I think I once made a worse thought , I think it was mistake. The key
is The routing table is for INCOMING messages. When that router
receives and so routes a packet, it had to be an incomign message.
If the router were generating its own packet, then maybe it'd be an
outgoing message and not routed at all. Perhaps that's the case with
routing protocol messages.
Vernon Schryver
Albert Manfredi <albert.e...@nospam.com> wrote:
>I could be wrong about this, but as far as I know, if a host transmits
>an IP datagram out of a given interface, the IP Source Address is the
>address of that interface. Not some other interface the host may also
>have.
That is wrong unless you think of a multi-homed host as a multi-part
system. If you consider a multi-homed system (even if only multi-homed
by interface "aliases") as several separate virtual hosts, one for each
interface, plus an additional virtual or imaginary router, then your
model fits. An application running on a virtual host sends packets
only from its virtual interface, but the virtual router routes or
forwards those packets out any of the real interfaces.
That model has some oddities that would need patching. The imaginary
router does not decrement the IP TTL as it would if it were a real
router. Many applications must be modeled as distributed, because the
same application state that affects packets emitted from one
virtual/internal interface can affect packets emitted from another
interface.
Vernon Schryver v...@rhyolite.com
Albert Manfredi
> Consider a multi-homed PC configured to operate as a DNS server.
>
> In the typical case, DNS uses UDP port 53.
>
> The server PC has interface 1.1.1.1 and 2.2.2.2.
>
> A client, at 7.7.7.7 sends a DNS query to 1.1.1.1. The DNS server
> software does its thing and generates a reply packet addressed to
> 7.7.7.7.
>
> If the DNS software does not specify the source IP address for the
> response packet, the TCP stack will fill in the source IP address
> by default. If the packet is routed out the 1.1.1.1 interface,
> the source address will be 1.1.1.1 and all is well.
>
> If the packet is routed out the 2.2.2.2 interface the source
> address on the response will be 2.2.2.2 and the client will
> ignore it. The client is expecting a response from 1.1.1.1 after all.
>
> In order to avoid this problem, DNS software takes pains to
> generate reply packets with the source address that the client
> addressed the original query to.
>
> This may well be the "wrong" interface in your sense.
Interesting example. If the server is DNS, the message transfers are
UDP, and I suppose that works fine. If the server were something that
needed TCP, the result wouldn't be quite so good. But, good point. It
happens.
In this case, then, it would have been possible for the packet with
source IP 138.139.92.176 to be coming out the 1.1.1.125 interface port
of the PC, and use the routing table entry everyone else seemed to
prefer.
Bert
Vernon Schryver
Albert Manfredi <albert.e...@nospam.com> wrote:
>> In order to avoid this problem, DNS software takes pains to
>> generate reply packets with the source address that the client
>> addressed the original query to.
>>
>> This may well be the "wrong" interface in your sense.
>
>Interesting example. If the server is DNS, the message transfers are
>UDP, and I suppose that works fine. If the server were something that
>needed TCP, the result wouldn't be quite so good.
On the contrary, TCP to a multi-homed host is an even better example
precisely because a TCP server can never change to the "right" IP source
address. Regardless of the interface on which a TCP SYN arrives and
regardless of the source address of the SYN-ACK, the SYN-ACK will be
sent via the interface that routing says is best. That is true even
if it is the "wrong" interface.
Vernon Schryver v...@rhyolite.com
Albert Manfredi
> On the contrary, TCP to a multi-homed host is an even better example
> precisely because a TCP server can never change to the "right" IP source
> address. Regardless of the interface on which a TCP SYN arrives and
> regardless of the source address of the SYN-ACK, the SYN-ACK will be
> sent via the interface that routing says is best. That is true even
> if it is the "wrong" interface.
But how are the two directions expected to remain symmetric? If in one
direction the packets are addressed correctly, but in the return
direction they are expected to go along a bogus route, how does that
work? Are the routers expected to maintain this special return path
state for the duration of the session? And if so, and one router along
the way fails, aren't you guaranteeing the session will fail?
If I remember right, in the DNS example, the response from the server
went out on a different interface, not the same as the one on which the
query arrived. I can see that working for a unidirectional protocol,
because the only problem there is a make-believe source IP in packets
along the return path. There's no necessary tight couplling between the
two directions. So the only possibilities I can see are that the
routers maintain state for this session, to make both directions go
along the same path, or that asymmetric paths are okay for TCP. (I know
asymmetric TCP can work, but I thought it was only done in sort of
weird situations.)
Bert
Barry Margolin
"Albert Manfredi" <bert...@hotmail.com> wrote:
> Vernon Schryver wrote:
>
> > On the contrary, TCP to a multi-homed host is an even better example
> > precisely because a TCP server can never change to the "right" IP source
> > address. Regardless of the interface on which a TCP SYN arrives and
> > regardless of the source address of the SYN-ACK, the SYN-ACK will be
> > sent via the interface that routing says is best. That is true even
> > if it is the "wrong" interface.
>
> But how are the two directions expected to remain symmetric? If in one
> direction the packets are addressed correctly, but in the return
> direction they are expected to go along a bogus route, how does that
> work? Are the routers expected to maintain this special return path
> state for the duration of the session? And if so, and one router along
> the way fails, aren't you guaranteeing the session will fail?
The two directions don't have to be symmetric.
Except under special circumstances, routing is simply by destination
address. There's nothing "bogus" about the return route being different
from the forward route.
Consider the following diagram, where A and B are the addresses of the
server's two interfaces. Client sends a request to A, so it will take
the path through routers R1 and R2. The server may send the reply back
via R3, since that's the shorter path. So it will go out interface B,
but the source address will still be A.
Client
|
---------------------
| |
R1 R3
| |
R2 |
| |
| |
------ ------
| |
|-----Server---|
A B
The only time this may cause a problem is if R3 implements "reverse path
verification", a form of anti-spoofing that blocks traffic if it doesn't
arrive on the interface that would be used to send traffic back to the
source address. This type of filtering is generally only valid on
connections to singly-homed leaf nodes or subnets. When multi-homing is
involved, you can't use such simplistic filtering because asymmetric
routing is normal.
Vernon Schryver
Albert Manfredi <bert...@hotmail.com> wrote:
>> On the contrary, TCP to a multi-homed host is an even better example
>But how are the two directions expected to remain symmetric? If in one
>direction the packets are addressed correctly, but in the return
>direction they are expected to go along a bogus route, how does that
>work?
What's that about a bogus route? I don't understand the other person's
situation. I'm only responding to what I thought was your claim that
the source address in an IP packet must always match the IP address
of the host interface from which it is sent.
> Are the routers expected to maintain this special return path
>state for the duration of the session?
Who said anything about special paths? What paths are not special?
> And if so, and one router along
>the way fails, aren't you guaranteeing the session will fail?
Well, if the route breaks and there is no replacement, then yes,
the TCCP session will fail.
>If I remember right, in the DNS example, the response from the server
>went out on a different interface, not the same as the one on which the
>query arrived.
I don't recall that as being critical in the DNS example, but it
can happen.
> I can see that working for a unidirectional protocol,
>because the only problem there is a make-believe source IP in packets
>along the return path. There's no necessary tight couplling between the
>two directions. So the only possibilities I can see are that the
>routers maintain state for this session, to make both directions go
>along the same path, or that asymmetric paths are okay for TCP. (I know
>asymmetric TCP can work, but I thought it was only done in sort of
>weird situations.)
Such situations are not at all wierd for multi-homed hosts. They can
be seen as the reason to pay for multi-homing.
Asymmetric paths are okay for TCP, because TCP doesn't know about them.
I trust you'd have no problem with packets going out the "wrong" interface
of a router if the "right" interface is broken and the "wrong" interface
is the start of a usable path to the destination.
So what's wrong with combining a router with a host in a single box?
Vernon Schryver v...@rhyolite.com
Albert Manfredi
> The two directions don't have to be symmetric.
>
> Except under special circumstances, routing is simply by destination
> address. There's nothing "bogus" about the return route being different
> from the forward route.
>
> Consider the following diagram, where A and B are the addresses of the
> server's two interfaces. Client sends a request to A, so it will take
> the path through routers R1 and R2. The server may send the reply back
> via R3, since that's the shorter path. So it will go out interface B,
> but the source address will still be A.
>
> Client
> |
> ---------------------
> | |
> R1 R3
> | |
> R2 |
> | |
> | |
> ------ ------
> | |
> |-----Server---|
> A B
Yes, I understood that if asymmetric paths are acceptable, then clearly
the source IP of the packet doesn't need to point to the true source
port used by the machine.
> The only time this may cause a problem is if R3 implements "reverse path
> verification", a form of anti-spoofing that blocks traffic if it doesn't
> arrive on the interface that would be used to send traffic back to the
> source address. This type of filtering is generally only valid on
> connections to singly-homed leaf nodes or subnets. When multi-homing is
> involved, you can't use such simplistic filtering because asymmetric
> routing is normal.
Dual-homing is often used for improved reliability. There are of course
different strategies one can use. If one uses TCP instead of UDP, one
strategy might be to keep two parallel sessions open at all times. The
reason to do this is to prevent a single failure from breaking the
logical link.
If asymmetric paths are allowed to occur, this strategy would not work.
There would be no way to guarantee that the two simultaneous sessions
are taking different paths. A single failure would potentially break
both links. I'm not sure how to achieve "active redundancy" with TCP,
unless one can guarantee that dual-homed hosts use the proper source
address one each of their interfaces.
Bert
Albert Manfredi
> I trust you'd have no problem with packets going out the "wrong" interface
> of a router if the "right" interface is broken and the "wrong" interface
> is the start of a usable path to the destination.
> So what's wrong with combining a router with a host in a single box?
Routers don't change the source IP of packets from a host, so that's
not a problem. However, to make the correct analogy, I'd have big
problems with routers using unpredictable interfaces. If I set up a
network to operate in a predictable way as failures occur, I need to
know that routers select the "correct" routes in each case.
Bert
Vernon Schryver
Albert Manfredi <bert...@hotmail.com> wrote:
>
>> I trust you'd have no problem with packets going out the "wrong" interface
>> of a router if the "right" interface is broken and the "wrong" interface
>> is the start of a usable path to the destination.
>> So what's wrong with combining a router with a host in a single box?
>
>Routers don't change the source IP of packets from a host, so that's
>not a problem.
No source IP addresses are being "changed." The host is merely picking
one IP addresses and using an interface other than a very naive and
wrong model of the host might predict.
(Let's not worry about NAT routers that do change the source IP address
of packets from a host.)
> However, to make the correct analogy, I'd have big
>problems with routers using unpredictable interfaces. If I set up a
>network to operate in a predictable way as failures occur, I need to
>know that routers select the "correct" routes in each case.
That is exactly what is happening in the multi-homed host case. The
host picks the source IP address for its IP datagram. It then picks
an outgoing network interface or wire for the datagram using exactly
the same algorithms as a router. Some multi-homed hosts will even use
the same routing protocols to inform those algorithems.
Vernon Schryver v...@rhyolite.com
Vernon Schryver
Albert Manfredi <bert...@hotmail.com> wrote:
>Dual-homing is often used for improved reliability. There are of course
>different strategies one can use. If one uses TCP instead of UDP, one
>strategy might be to keep two parallel sessions open at all times. The
>reason to do this is to prevent a single failure from breaking the
>logical link.
>
>If asymmetric paths are allowed to occur, this strategy would not work.
>There would be no way to guarantee that the two simultaneous sessions
>are taking different paths. A single failure would potentially break
>both links. I'm not sure how to achieve "active redundancy" with TCP,
>unless one can guarantee that dual-homed hosts use the proper source
>address one each of their interfaces.
None of that is consistent with how multi-homed IP hosts work or could
possibly work. It seems to be based on the mistaken assumption that
IP is a virtual circuit protocol like ATM. IP is about packet switching
instead of circuit switching. Perhaps the fundamental difference is
that in circuit switching the ends of the circuit have some control
and a pretty good idea of the paths their data follow, but in packet
switching, the hosts just toss their data out and just hope the next
hop will pass it along in approximately the right direction. That is
why the IP packet header includes a TTL field but the ATM cell header
doesn't.
Vernon Schryver v...@rhyolite.com
Albert Manfredi
> >There would be no way to guarantee that the two simultaneous sessions
> >are taking different paths. A single failure would potentially break
> >both links. I'm not sure how to achieve "active redundancy" with TCP,
> >unless one can guarantee that dual-homed hosts use the proper source
> >address one each of their interfaces.
Vernon Schryver wrote:
>
> None of that is consistent with how multi-homed IP hosts work or could
> possibly work. It seems to be based on the mistaken assumption that
> IP is a virtual circuit protocol like ATM. IP is about packet switching
> instead of circuit switching. Perhaps the fundamental difference is
> that in circuit switching the ends of the circuit have some control
> and a pretty good idea of the paths their data follow, but in packet
> switching, the hosts just toss their data out and just hope the next
> hop will pass it along in approximately the right direction. That is
> why the IP packet header includes a TTL field but the ATM cell header
> doesn't.
This is going rather far afield of the original thread, but I think
you're being overly pessimistic. The only requirement for this to work,
with TCP, is that the source IP of packets be the IP address of the
actual port that transmitted the packet.
There's plenty of fussing going on as we speak, in IPv6, to figure out
which of the multiple available IPv6 source addresses should be used in
specific sessions. It is going to depend in part on where the network
is at the other end of the session link. And even more interesting, the
specific case of a multihomed host came up. The problem is, some IPv6
addresses might not have scope compatible with the other end of the
link.
This is related. The relationship between port used and source address
matters. Sure, circuit-switched techniques make the redundant data path
comms more clear-cut. But in a controlled network, i.e. not the
Internet, the path taken by packets in normal conditions should be very
predictable. I just don't think this is so absurd.
Bert
Martijn Lievaart
> Yes, I understood that if asymmetric paths are acceptable, then clearly
> the source IP of the packet doesn't need to point to the true source
> port used by the machine.
I think you mean s/port/interface/. In that case, stop thinking of an
interface having an IP adress. That is a big step, but one that will help
you keep your sanity. Think of a machine having the IP address, it is much
more accurate[0].
The coupling between an IP address an an interface is used only in a few
specific instances.
- When a locally generated packet doesn't have a source address, the
address of the outgoing interface is used[1].
- When responding to an arp request[2].
- To add the correct route to the routing table[3].
Other than that, don't think of an interface as "having" an address. The
machine has addresses and the routing tables route the packet through a
specific interface.
M4
[0] Except in the so called "strong ended IP model". In that model all I
say is wrong. However I have never seen an IP stack implement that model,
so better forget this footnote.
[1] Strictly speaking, this is not correct. What if an interface has
multiple IP adresses? Which one should be choosen? The first? There are
situations where that is wrong. In Linux, the source address is determined
by the routing table to avoid this problem[4].
[2] But nothing stops an IP stack to respond on all interfaces to arp
requests for all IPs of that machine. In fact, this is not uncommon. So
even there the coupling is not so strict[4].
[3] And again, this is not exactly an interface property, but a side
effect of setting up the interface[4].
[4] And even this is not completely correct, but hey, let's not make it
even more complex!
--
Redundancy is a great way to introduce more single points of failure.
Rick Jones
> Think of a machine having the IP address, it is much more
> accurate[0].
> [0] Except in the so called "strong ended IP model". In that model
> all I say is wrong. However I have never seen an IP stack implement
> that model, so better forget this footnote.
Depending on which stacks you've seen you may have seen it and not
noticed it :)
HP-UX 11 and later offers the Strong End System Model via an ndd
setting. The default is the "weak" end system model. Later versions
have a "firm" end-system model. Firm end-system in HP-UX means that
source IP is part of the route selection, but the restriction on
datagrams arriving on interfaces with matching IP(s) is relaxed to be
like the "weak" end system model.
I suspect that Solaris 2 and later also offers the strong end-system
model with the weak as the default. I've no idea if it does something
akin to a "firm" one.
rick jones
--
a wide gulf separates "what if" from "if only"
these opinions are mine, all mine; HP might not want them anyway... :)
feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH...
Albert Manfredi
> In that case, stop thinking of an
> interface having an IP adress.
Yes, it appears it has come to this. Yet we know that while maybe a
single MAC addresses can be associated with multiple interfaces in one
host (which is fine as long as they're in different IP subnets), IP
addresses are instead associated strictly with an interface of the
machine. Here's the quote from RFC 791, where "local address" is the MAC
address:
The local address, assigned by the local network, must allow for a
single physical host to act as several distinct internet hosts.
That is, there must be a mapping between internet host addresses and
network/host interfaces that allows several internet addresses to
correspond to one interface. It must also be allowed for a host to
have several physical interfaces and to treat the datagrams from
several of them as if they were all addressed to a single host.
The IP address identifies an interface. Multiple IP addresses can
identify that same interface. Multiple interfaces cannot be identified
by the same IP address.
You're saying in practice this isn't so, at least when it comes to
assigning IP source addresses to packets.
> The coupling between an IP address an an interface is used only in a
> few
> specific instances.
> - When a locally generated packet doesn't have a source address, the
> address of the outgoing interface is used[1].
> - When responding to an arp request[2].
> - To add the correct route to the routing table[3].
>
> Other than that, don't think of an interface as "having" an address.
> The
> machine has addresses and the routing tables route the packet through
> a
> specific interface.
>
> M4
>
> [0] Except in the so called "strong ended IP model". In that model all
> I
> say is wrong. However I have never seen an IP stack implement that
> model,
> so better forget this footnote.
>
> [1] Strictly speaking, this is not correct. What if an interface has
> multiple IP adresses? Which one should be choosen? The first? There
> are
> situations where that is wrong. In Linux, the source address is
> determined
> by the routing table to avoid this problem[4].
This is an issue that needs to be fixed correctly, especially in IPv6.
> [2] But nothing stops an IP stack to respond on all interfaces to arp
> requests for all IPs of that machine. In fact, this is not uncommon.
> So
> even there the coupling is not so strict[4].
>
> [3] And again, this is not exactly an interface property, but a side
> effect of setting up the interface[4].
>
> [4] And even this is not completely correct, but hey, let's not make
> it
> even more complex!
>
> --
> Redundancy is a great way to introduce more single points of failure.
Bert
Vernon Schryver
Albert Manfredi <bert...@hotmail.com> wrote:
>> IP is about packet switching
>> instead of circuit switching. Perhaps the fundamental difference is
>> that in circuit switching the ends of the circuit have some control
>> and a pretty good idea of the paths their data follow, but in packet
>> switching, the hosts just toss their data out and just hope the next
>> hop will pass it along in approximately the right direction.
>This is going rather far afield of the original thread, but I think
>you're being overly pessimistic.
Only a circuit switching advocate would think I'm being pessimistic
or saying anything negative about packet switching. A packet switching
advocate thinks tossing packets in the ocean of routers and hoping
they'll be passed in the right direction is a good thing and better
than circuit switching. Given the popularity of VoIP among the
telephants, most of the old "Bell Heads" have either died or become
packet switching collaborators.
> The only requirement for this to work,
>you're being overly pessimistic. The only requirement for this to work,
>with TCP, is that the source IP of packets be the IP address of the
>actual port that transmitted the packet.
You keep saying that, but it remains wrong, both for anything related
how to standard TCP might work and to how TCP actually works.
>There's plenty of fussing going on as we speak, in IPv6, to figure out
>which of the multiple available IPv6 source addresses should be used in
>specific sessions. It is going to depend in part on where the network
>is at the other end of the session link. And even more interesting, the
>specific case of a multihomed host came up. The problem is, some IPv6
>addresses might not have scope compatible with the other end of the
>link.
Yes, but that's all irrelevant (except for the craziness smoke, vapor,
and nonsense of splicing NAT into every host in the IPv6 Internet).
Once a TCP 4-tuple is chosen, it cannot, does not, and does not need
to change even if a multi-homed host loses interface that had owned
of the IPv{4,6} addresses in the 4-tuple.
>This is related. The relationship between port used and source address
>matters. Sure, circuit-switched techniques make the redundant data path
>comms more clear-cut. But in a controlled network, i.e. not the
>Internet, the path taken by packets in normal conditions should be very
>predictable. I just don't think this is so absurd.
Absurd or not, IP is what it is. By your notions now as years ago
when we argued about ATM, neither the Internet nor any except the
most trivial, private (small-I) internet is what you consider a
controlled network. The essense of packet switching is not controlling
the path. If you control or even know the path, then you have a
circuit, and that's not packet switching.
Assymetric routes are a fact of life and not necessarily bad.
Unpredictable routing is a Good Thing(tm), even if it is why Van
Jacobson invented traceroute and why `ping -R` used LSRR back when
that used to work.
Vernon Schryver v...@rhyolite.com
Anne & Lynn Wheeler
v...@calcite.rhyolite.com (Vernon Schryver) writes:
> Only a circuit switching advocate would think I'm being pessimistic
> or saying anything negative about packet switching. A packet
> switching advocate thinks tossing packets in the ocean of routers
> and hoping they'll be passed in the right direction is a good thing
> and better than circuit switching. Given the popularity of VoIP
> among the telephants, most of the old "Bell Heads" have either died
> or become packet switching collaborators.
we were called in to consult with this small client/server startup
that wanted to do payments on their server
http://www.garlic.com/~lynn/aadsm5.htm#asrn2
http://www.garlic.com/~lynn/aadsm5.htm#asrn3
they had this technology they called SSL and were looking at taking
payment message definitions from a cricuit-based infrastructure and
mapping it into a purely packet environment with this thing called a
payment gateway (i've periodically claimed it may be the first SOA
... service oriented architecture).
very early testing, there was a problem called into the trouble desk.
the trouble desk had been used to doing first level problem
determination in a telco provisioned circuit-based infrastructure.
after 3hrs of concerted effort, they finally closed the trouble ticket
as NTF (no trouble found).
we had to go back and do some detailed analysis of all kinds of
possible failure modes and then develop some amount of software and
diagnostic procedures to even marginally compensate for not having a
telco provisioned operation. at least for the server to payment
gateway, we had fair amount of sign-off and authority and could see
that it got done.
part of it had been based on having done detailed vulnerability
analysis of tcp/ip when were were starting our ha/cmp product
in the late 80s
http://www.garlic.com/~lynn/subtopic.html#hacmp
minor topic drift on recent thread re: reliable connections/communication
http://www.garlic.com/~lynn/aadsm23.htm#21 Reliable Connections Are Not
http://www.garlic.com/~lynn/2006i.html#16 blast from the past, reliable communication
http://www.garlic.com/~lynn/2006i.html#17 blast from the past on reliable communication
http://www.garlic.com/~lynn/2006i.html#18 blast from the past on reliable communication
http://www.garlic.com/~lynn/2006i.html#19 blast from the past on reliable communication
http://www.garlic.com/~lynn/2006i.html#20 blast from the past on reliable communication
http://www.garlic.com/~lynn/2006i.html#21 blast from the past on reliable communication
--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
Martijn Lievaart
> In comp.protocols.tcp-ip Martijn Lievaart <m...@remove.this.part.rtij.nl> wrote:
>> Think of a machine having the IP address, it is much more
>> accurate[0].
>
>> [0] Except in the so called "strong ended IP model". In that model
>> all I say is wrong. However I have never seen an IP stack implement
>> that model, so better forget this footnote.
>
> Depending on which stacks you've seen you may have seen it and not
> noticed it :)
Spot on.
> HP-UX 11 and later offers the Strong End System Model via an ndd
> setting. The default is the "weak" end system model. Later versions
> have a "firm" end-system model. Firm end-system in HP-UX means that
> source IP is part of the route selection, but the restriction on
> datagrams arriving on interfaces with matching IP(s) is relaxed to be
> like the "weak" end system model.
Ah, but HP also tried redefining how PMTUD works, then added another
setting that allowed PMTUD as the rest of the world does it. Their "weak"
end model was broken so this sounds as if the "firm" model is also how the
rest of the world does "weak".
The problem is a host with two (or more) ip addresses in different subnets
on the same interface. Selecting a source address for outgoing packets
must depend on the destination address in this case, or more precise on
the route the outgoing packets take. So in my view, source address
selection is a function of routing. In older HP-UXen HP got this wrong and
always used the first address of the interface.
> I suspect that Solaris 2 and later also offers the strong end-system
> model with the weak as the default. I've no idea if it does something
> akin to a "firm" one.
It is to long since I played with Solaris.
M4
Martijn Lievaart
> "Martijn Lievaart" <m...@remove.this.part.rtij.nl> wrote:
>
>> In that case, stop thinking of an
>> interface having an IP adress.
>
> Yes, it appears it has come to this. Yet we know that while maybe a
> single MAC addresses can be associated with multiple interfaces in one
> host (which is fine as long as they're in different IP subnets), IP
> addresses are instead associated strictly with an interface of the
> machine. Here's the quote from RFC 791, where "local address" is the MAC
> address:
>
> The local address, assigned by the local network, must allow for a
> single physical host to act as several distinct internet hosts.
> That is, there must be a mapping between internet host addresses and
> network/host interfaces that allows several internet addresses to
> correspond to one interface. It must also be allowed for a host to
> have several physical interfaces and to treat the datagrams from
> several of them as if they were all addressed to a single host.
I fail to see the relevance of this quote.
> The IP address identifies an interface. Multiple IP addresses can
> identify that same interface. Multiple interfaces cannot be identified
> by the same IP address.
>
> You're saying in practice this isn't so, at least when it comes to
> assigning IP source addresses to packets.
This isn't so at all. Look at IP unnumbered in Ciscos IOS. I was amazed
when I first saw tun interfaces under Linux with the same IP address as my
ethernet interface, wich is essentially the same as Ciscos IP unnumbered.
Mulitple interfaces can have the same IP addres, in fact it is pretty
common. Multiple interfaces on multipoint interfaces probably should have
different IP addresses, due to the arp to interface mapping, although I'm
not completely sure about that.
M4
Rick Jones
> Ah, but HP also tried redefining how PMTUD works, then added another
> setting that allowed PMTUD as the rest of the world does it.
I presume you are refering to the "it seemed like a good idea at the
time" "use an ICMP echo request to probe the PMTU mechanism that was
in earlier HP-UX 11 (and certain MacOS stacks - I forgot about that
initially - and perhaps even Solaris since they all shared a common
ancestor)? IIRC that was an il-fated attempt to avoid PTMU blackholes
and indeed in the end had undesirable properties and was nuked.
> Their "weak" end model was broken so this sounds as if the "firm"
> model is also how the rest of the world does "weak".
I'm a bit confused here - are you trying to equate weak end system
with PMTUD behaviour?
rick jones
--
denial, anger, bargaining, depression, acceptance, rebirth...
where do you want to be today?
Albert Manfredi
>> You're saying in practice this isn't so, at least when it comes to
>> assigning IP source addresses to packets.
>
> This isn't so at all. Look at IP unnumbered in Ciscos IOS. I was
> amazed
> when I first saw tun interfaces under Linux with the same IP address
> as my
> ethernet interface, wich is essentially the same as Ciscos IP
> unnumbered.
Thanks guys (also Vernon, Rick, and Barry). Useful discussion. Even if I
was viciously accused of being a circuit switching guy. ;)
Bert
Martijn Lievaart
>> Their "weak" end model was broken so this sounds as if the "firm"
>> model is also how the rest of the world does "weak".
>
> I'm a bit confused here - are you trying to equate weak end system
> with PMTUD behaviour?
No, as I explained HPUX used to select the wrong source address on
multinetted interfaces. Nothing against HPUX, it's one of the nicer OSses
I worked with. But I consider both the PMTU ping strategy as well as
selecting the wrong source address as bugs, that's the only eqation.
q_q_an...@yahoo.co.uk
Martijn Lievaart wrote:
> On Wed, 10 May 2006 09:22:04 -0700, Albert Manfredi wrote:
>
> > Yes, I understood that if asymmetric paths are acceptable, then clearly
> > the source IP of the packet doesn't need to point to the true source
> > port used by the machine.
>
> I think you mean s/port/interface/. In that case, stop thinking of an
> interface having an IP adress.
but they do have IP addresses. They just don't find the path-The router
finds the path.
The IP is usually only for identifiying the interface. And they don't
usually write their ip in. except, I guess, as you say below.
But isn't it silly and unrealistic to pretend that they don't have IP
addresses when they do. It's not like it causes a big problem in
understanding. It's largely only for identification, as you yourself
indicate by listing when the ip is written into the packet.
I was suprised when I read that cisco router's interfaces had IP
addresses. that's because all I had was a 'home router' so I was
actually connecting to a switch connected to effectively, a real router
interface. - A brouter I suppose
<snip>
> The coupling between an IP address an an interface is used only in a few
> specific instances.
> - When a locally generated packet doesn't have a source address, the
> address of the outgoing interface is used[1].
> - When responding to an arp request[2].
> - To add the correct route to the routing table[3].
>
ok
<snip>