PHWinfo - Afficher un message - Which entry of the routing table was selected?

08/05/2006, 07h33

In article <Iyx1Fy.DG9@news.boeing.com>,
Albert Manfredi <albert.e.manfredi@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.

08/05/2006, 07h33	#15
Walter Roberson Messages: n/a Hébergeur:	Re: Which entry of the routing table was selected? In article <Iyx1Fy.DG9@news.boeing.com>, Albert Manfredi <albert.e.manfredi@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.