In article <1146978035.524253.300970@j73g2000cwa.googlegroups. com>,
Alex Vinokur 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.

In article <1146978035.524253.300970@j73g2000cwa.googlegroups. com>,
"Alex Vinokur" wrote:

> Here is a routing table on PC.
>
> ================================================== =========================
> 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?

The same one, of course. Routing is based only on destination address.

--
Barry Margolin, barmar@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 ***

Walter Roberson wrote:
> In article <1146978035.524253.300970@j73g2000cwa.googlegroups. com>,
> Alex Vinokur 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?



Alex Vinokur
email: alex DOT vinokur AT gmail DOT com
http://mathforum.org/library/view/10978.html
http://sourceforge.net/users/alexvn

In article <1146990455.590438.169310@j73g2000cwa.googlegroups. com>,
"Alex Vinokur" wrote:

> Walter Roberson wrote:
> > In article <1146978035.524253.300970@j73g2000cwa.googlegroups. com>,
> > Alex Vinokur 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.

--
Barry Margolin, barmar@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 ***

"Barry Margolin" wrote in message news:barmar-1B0C41.04325007052006@comcast.dca.giganews.com...
> In article <1146990455.590438.169310@j73g2000cwa.googlegroups. com>,
> "Alex Vinokur" wrote:
[snip]
> > 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.
>
[snip]

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?



--
Alex Vinokur
email: alex DOT vinokur AT gmail DOT com
http://mathforum.org/library/view/10978.html
http://sourceforge.net/users/alexvn

In article <445e1469$0$24995$834e42db@reader.greatnowhere.com>,
Alex Vinokur 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.]

In article ,
roberson@hushmail.com (Walter Roberson) wrote:

> In article <445e1469$0$24995$834e42db@reader.greatnowhere.com>,
> Alex Vinokur 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.

--
Barry Margolin, barmar@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 wrote:
> Walter Roberson wrote:
> > In article <1146978035.524253.300970@j73g2000cwa.googlegroups. com>,
> > Alex Vinokur 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.

"Alex Vinokur" wrote:

> Here is a routing table on PC.
>
> ================================================== =========================
> 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

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

Albert Manfredi wrote:
> "Alex Vinokur" wrote:
>
> > Here is a routing table on PC.
> >
> > ================================================== =========================
> > 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
>
> 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

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

Albert Manfredi wrote:
> "Alex Vinokur" wrote:
>
> > Here is a routing table on PC.
> >
> > ================================================== =========================
> > 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
>
> 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

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_anonymous@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.

> 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

Albert Manfredi wrote:
> q_q_anonymous@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

In article ,
Albert Manfredi 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.

This should be done based on the 2nd entry in the table since that is
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 wrote:
> Here is a routing table on PC.
>
> ================================================== =========================
> 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 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 . :

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?





Alex Vinokur
email: alex DOT vinokur AT gmail DOT com
http://mathforum.org/library/view/10978.html
http://sourceforge.net/users/alexvn

In article <1147094052.871711.220640@u72g2000cwu.googlegroups. com>, Alex Vinokur wrote:

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

In article , roberson@hushmail.com (Walter Roberson) writes:
> In article ,
> Albert Manfredi 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.

q_q_anonymous@yahoo.co.uk wrote:

> 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