EmbeddedRelated.com
Forums

Ethernet routing to a second subnet from a wintel machine

Started by Didi January 31, 2011
Didi <dp@tgi-sci.com> wrote:
> On Feb 2, 1:35&nbsp;am, Martijn Lievaart <m...@rtij.nl.invlalid> wrote: >> I'm not sure RFCs forbid this behavior, but I'm darn sure the RFCs don't >> require this behavior. > > You claim you know that?
I'm pretty sure Martijn has read most of the relevant ones a couple of times (for that matter, so have I and I likewise can't imagine such a requirement, but I haven't gone and checked specially so I may be wrong and it wouldn't be the first time that my imagination was lacking).
>> It's a well known trick for not fully implemented tcp/ip stacks to behave >> this way. Any serious implementation does *not* behave this way. > > So how many not fully implemented stacks do you know which behave > this way. Can you give us some examples. > >> Again, I do not know what the RFCs actually require, but I do know that >> this 'trick' does not work on most ip stacks. > > It is not a trick. Just a routing policy which may be set this > or that way. On the DPS stack it can, that is. Not on the > ones you know, I already got that.
Adding a static entry to the ARP table is not "a routing policy" by any stretch of the imagination. Routing has happened long before ARP takes place. ARP resolves IP addresses to lower layer (often Ethernet) addresses. I think not running ARP for an address which is not local (ie: no address in the same network on any interface) is a reasonable (also in terms of performance) decision for a network stack to make. - Philip -- Philip Paeps Please don't email any replies philip@paeps.cx I follow the newsgroup. I mean, I wouldn't pay more than a couple of quid to see me, and *I'm* me. -- (Terry Pratchett, alt.fan.pratchett)
On Feb 2, 7:17=A0pm, Philip Paeps <philip+use...@paeps.cx> wrote:
> .... > Adding a static entry to the ARP table is not "a routing policy" by any > stretch of the imagination.
IP routing has taken place. Ethernet has not.
> ...=A0I think > not running ARP for an address which is not local (ie: no address in the =
same
> network on any interface) is a reasonable (also in terms of performance) > decision for a network stack to make.
So do I. You may want to understand the posts prior to replying. Dimiter ------------------------------------------------------ Dimiter Popoff Transgalactic Instruments http://www.tgi-sci.com ------------------------------------------------------ http://www.flickr.com/photos/didi_tgi/sets/72157600228621276/
On Mon, 31 Jan 2011 09:53:11 -0800, Didi wrote:

>> I'm not sure why you need a static ARP entry. > > Well that is straight forward enough. On my DPS machines, outbound packets > will route according to an entry (or "subnet", ARP table entries are > maskable) > in the ARP table; if no routing entry is found in the ARP table, the > packet > will go down its respective subnet gateway if it belongs there; if it is > on the same subnet and there was no ARP entry for it, a network ARP query > will be initiated. > I expected similar behaviour from windows; but no, the manually set ARP > entry is ignored.
ARP and routing are quite separate issues. Routing is an IP-layer feature. The routing table tells the computer the next "hop" (the interface and possibly the gateway) for a given IP address. You can view the routing table (in XP at least) with "route print" from a command prompt, and can modify it via "route add" etc. ARP provides hardware-layer (Ethernet etc) addresses for a given IP address. If your routing table specifies that a given IP address should be routed via the default gateway, then any ARP entries for that IP address won't make the slightest bit of difference, as the computer will never request an ARP entry for the IP address, it will request one for the gateway. An ARP entry only matters for a host which is, according to the routing table, on the same network segment. A typical routing table for a desktop PC will have a network route (no gateway) for each interface, corresponding to the interface's IP address and subnet mask, a default route via a gateway, a route for 127.0.0.0/8 via the loopback interface, plus broadcast/multicast routes. If you have a device on a different subnet (either on the other side of a router, or on the same segment but with an IP address outside of the range specified by the local interface's address and subnet mask), you need to add a route to it, otherwise packets will get sent to the default gateway. ARP won't change this. On Windows XP, go to Control Panel, Network Connections, Local Area Connection 1 (or whatever number corresponds to the appropriate ethernet interface) > Properties, Internet Protocol (TCP/IP), Properties, Advanced, IP Settings (tab), Add..., and add an IP address and subnet mask for the network (i.e. IP address range) corresponding to the device with which you wish to communicate. Where ARP /will/ work is if the local system doesn't know about the gateway but has a default route which simply refers to the local network. In that situation, a router can perform proxy ARP for any number of other networks, or even the entire internet, with the effect that every host on the internet appears to be on the same ethernet segment so far as routing is concerned. A host sending a packet to a given IP address notes that the IP address is part of the local network, requests its ethernet address via ARP, and (hopefully) the gateway replies with its own ethernet address. This practice is generally avoided because it can result in large ARP tables (there'll be an entry for every IP address) and it's easy to get into ARP fights if there is more than one router. However, it does provide a simple means of "zero configuration" networking: only the routers need to know any routing information; other hosts just spit packets onto the network.
On Feb 2, 9:38=A0pm, Nobody <nob...@nowhere.com> wrote:
> On Mon, 31 Jan 2011 09:53:11 -0800, Didi wrote: > .... > ARP and routing are quite separate issues.
ARP and IP routing are separate indeed.
> Routing is an IP-layer feature. The routing table tells the computer the > next "hop" (the interface and possibly the gateway) for a given IP addres=
s. This is how IP routing works indeed. It only involves IP addresses, however; there is more routing to take place at the lower levels.
> ARP provides hardware-layer (Ethernet etc) addresses for a given IP > address.
Yes, calling it routing - as I did - may be unusual but in essence it is that. It does work in conjunction with the IP address and the separating line between the two can depend on the context.
> If your routing table specifies that a given IP address should be routed > via the default gateway, then any ARP entries for that IP address won't > make the slightest bit of difference, as the computer will never request > an ARP entry for the IP address, it will request one for the gateway.
Indeed. But if you **manually** set an ARP entry for an IP address in the table (like I explained in my first post, one day I will get tired of initiating threads...) because you know this IP address is on the same wire routing towards the gateway rather than the specified MAC address will at best double the network traffic for that address. Dimiter ------------------------------------------------------ Dimiter Popoff Transgalactic Instruments http://www.tgi-sci.com ------------------------------------------------------ http://www.flickr.com/photos/didi_tgi/sets/72157600228621276/
Didi <dp@tgi-sci.com> wrote:
> On Feb 2, 9:38&nbsp;pm, Nobody <nob...@nowhere.com> wrote: >> If your routing table specifies that a given IP address should be routed >> via the default gateway, then any ARP entries for that IP address won't >> make the slightest bit of difference, as the computer will never request >> an ARP entry for the IP address, it will request one for the gateway. > > Indeed. But if you **manually** set an ARP entry for an IP address in the > table (like I explained in my first post, one day I will get tired of > initiating threads...) because you know this IP address is on the same wire > routing towards the gateway rather than the specified MAC address will at > best double the network traffic for that address.
Adding a static ARP entry does not tell the IP stack anything though. The IP stack will try to find a route to the destination address in the IP header in the routing table. If it doesn't find a specific route, the packet will be sent to the default router. Only if you have a route to the network, will your entry be found. The ARP lookup happens _after_ an IP routing decision has been taken, not before. If you have no route to the network (such as a network route by virtue of having an address in the same network on an interface) the routing decision will be to use the default router. You can add a hundred arbitrary static arp entries. If you have no routes pointing to them, they won't ever be consulted. - Philip -- Philip Paeps Please don't email any replies philip@paeps.cx I follow the newsgroup.
Didi <dp@tgi-sci.com> wrote:
> On Feb 2, 7:17&nbsp;pm, Philip Paeps <philip+use...@paeps.cx> wrote: >> Adding a static entry to the ARP table is not "a routing policy" by any >> stretch of the imagination. > > IP routing has taken place. Ethernet has not.
I don't understand what you mean by this statement. Ethernet is not routed.
>> ...&nbsp;I think not running ARP for an address which is not local (ie: no >> address in the same network on any interface) is a reasonable (also in >> terms of performance) decision for a network stack to make. > > So do I. You may want to understand the posts prior to replying.
I understand perfectly well what you're trying to do, but it will not work because your assumptions are wrong. The network stack does not go and walk over the entire ARP table after it has made a routing decision. It will only go and find the entry for the routing decision it has taken (or can an ARP who-has if no ARP entry is there). - Philip -- Philip Paeps Please don't email any replies philip@paeps.cx I follow the newsgroup.
On 2011-02-02, Didi <dp@tgi-sci.com> wrote:
> On Feb 2, 9:38?pm, Nobody <nob...@nowhere.com> wrote: > >> Routing is an IP-layer feature. The routing table tells the computer the >> next "hop" (the interface and possibly the gateway) for a given IP address. > > This is how IP routing works indeed. It only involves IP addresses, > however; there is more routing to take place at the lower levels. > >> ARP provides hardware-layer (Ethernet etc) addresses for a given IP >> address. > > Yes, calling it routing - as I did - may be unusual but in essence it > is that. It does work in conjunction with the IP address and the > separating line between the two can depend on the context.
Yes, it is definitely slack use of terminology - the IEEE 802 standards make no mention of routing except in the context of laying cables. They do mention routers but they are treated as simply another ethernet node for all that it matters. I wouldn't characterise it as routing-like either - the destination MAC address is more of a tag than anything else. At its heart ethernet is still based on the idea of a common access network medium, conceptually at least. The transmitting station simply places the frame on the wire and expects it to arrive at the destination without any real consideration as to how it is to actually get there. It may well arrive at many other nodes as well but that is neither here nor there since it will be discarded in short order, typically within the NIC. Anything that breaks the common access topology - that's bridges or switches for the most part - must do so in a way that is transparent to the network nodes. The only time I can think of you would usually want ARP for something not on the local network would be for proxy ARP, where the router will respond with _it's_ MAC when there is an ARP for a remote IP address. From then on packets to that host get sent to the router which forwards them on as normal. Proxy ARP simplifies the nodes (which need no routing tables) but at the cost of more processing, network broadcasts and a lack of redundancy. It used to be fairly common but I haven't seen it for probably a decade at least. -- Andrew Smallshaw andrews@sdf.lonestar.org
On Feb 3, 12:53=A0pm, Philip Paeps <philip+use...@paeps.cx> wrote:
> Didi <d...@tgi-sci.com> wrote: > .... > > Indeed. But if you **manually** set an ARP entry for an IP address in t=
he
> > table (like I explained in my first post, one day I will get tired of > > initiating threads...) because you know this IP address is on the same =
wire
> > routing towards the gateway rather than the specified MAC address will =
at
> > best double the network traffic for that address.
I will make a last try - although I solved my problem before all that theory talk nobody asked for began.
> Adding a static ARP entry does not tell the IP stack anything though.
It does tell that this IP address is on the same wire. Whether the IP layer implementation is smart enough to grasp that is another matter.
> The IP stack will try to find a route to the destination address in the I=
P
> header in the routing table.
Routing can be implemented in more than a single way. In my DPS based implementation I have chosen to route to objects (i.e. the destination for an IP address range from the table is an object - DPS runtime object, not to be confused with compiler/hll generated code). Since this object can be different for different address ranges, different routing decision policies can be taken, including taking advantage of knowledge of the lower than IP level. Has not failed me for many years.
> ... If it doesn't find a specific route, the packet > will be sent to the default router.
I know this is how the stacks on windows and linux work. This means double traffic for nodes on the same wire (to make it easier to understand think an old single 10 MbpS coax) but on different subnets - at best, it can happen that the router won't cooperate at all, is the likelier case actually. Now I was pointed to a registry hack which allowed windows (xp) to more or less have a second IP address on the subnet of interest which solves my problem (which was lack of connectivity, not the dual traffic). It is not quite stable, dhcp renew at times begins to fail and only reset helps (neither disable/enable, nor release/renew works). But I can live with that for now. Then windows' dhcp renew is clunky and disruptive anyway so not such a huge difference. Dimiter ------------------------------------------------------ Dimiter Popoff Transgalactic Instruments http://www.tgi-sci.com ------------------------------------------------------ http://www.flickr.com/photos/didi_tgi/sets/72157600228621276/
In article <71503ca6-1aaa-49ce-a10c-19f853a1b68e@k32g2000vbn.googlegroups.com>,
Didi  <dp@tgi-sci.com> wrote:
>On Feb 3, 12:53&#4294967295;pm, Philip Paeps <philip+use...@paeps.cx> wrote: >> Didi <d...@tgi-sci.com> wrote: >> .... >> > Indeed. But if you **manually** set an ARP entry for an IP address in the >> > table (like I explained in my first post, one day I will get tired of >> > initiating threads...) because you know this IP address is on the same wire >> > routing towards the gateway rather than the specified MAC address will at >> > best double the network traffic for that address. > >I will make a last try - although I solved my problem before all that >theory talk nobody asked for began. > >> Adding a static ARP entry does not tell the IP stack anything though. > >It does tell that this IP address is on the same wire. Whether >the IP layer implementation is smart enough to grasp that is >another matter.
No, it tells you the mac address of the station that corresponds to the IP. The way you tell IP that it is on the same wire is to add an address and a netmask to an interface.
>> The IP stack will try to find a route to the destination address in the IP >> header in the routing table. > >Routing can be implemented in more than a single way. In my DPS based >implementation I have chosen to route to objects (i.e. the destination >for >an IP address range from the table is an object - DPS runtime object, >not to be confused with compiler/hll generated code). Since this >object >can be different for different address ranges, different routing >decision >policies can be taken, including taking advantage of knowledge of >the lower than IP level. Has not failed me for many years. > >> ... If it doesn't find a specific route, the packet >> will be sent to the default router. > >I know this is how the stacks on windows and linux work. This means >double traffic for nodes on the same wire (to make it easier to >understand
If you hairpin traffic, yes. But if you do it correctly, this is not the case. It is not a very good idea to have multiple, disjoint nets on the same wire that only has one or a few gateway machines.
>think an old single 10 MbpS coax) but on different subnets - at best, >it can happen that the router won't cooperate at all, is the likelier >case actually. > >Now I was pointed to a registry hack which allowed windows (xp) to >more or less >have a second IP address on the subnet of interest which solves my >problem (which was lack of connectivity, not the dual traffic). >It is not quite stable, dhcp renew at times begins to fail >and only reset helps (neither disable/enable, nor release/renew >works). But I can live with that for now. Then windows' dhcp renew is >clunky and disruptive anyway so not such a huge difference.
What is wrong with actually following the specs as they were dsigned, and have the router work as it should? -- mrr
On Feb 4, 5:06=A0am, Didi <d...@tgi-sci.com> wrote:
> On Feb 3, 12:53=A0pm, Philip Paeps <philip+use...@paeps.cx> wrote: > > > Didi <d...@tgi-sci.com> wrote: > > .... > > > Indeed. But if you **manually** set an ARP entry for an IP address in=
the
> > > table (like I explained in my first post, one day I will get tired of > > > initiating threads...) because you know this IP address is on the sam=
e wire
> > > routing towards the gateway rather than the specified MAC address wil=
l at
> > > best double the network traffic for that address. > > I will make a last try - although I solved my problem before all that > theory talk nobody asked for began. > > > Adding a static ARP entry does not tell the IP stack anything though. > > It does tell that this IP address is on the same wire. Whether > the IP layer implementation is smart enough to grasp that is > another matter.
I'm pretty sure it's not an issue of how smart the implementation is, but that routing based on the ARP tables is simply wrong. If there are two subnets on the wire, and you want to talk to both, you should have two IPs (one in each subnet) defined for the NIC.
> > The IP stack will try to find a route to the destination address in the=
IP
> > header in the routing table. > > Routing can be implemented in more than a single way. In my DPS based > implementation I have chosen to route to objects (i.e. the destination > for > an IP address range from the table is an object - DPS runtime object, > not to be confused with compiler/hll generated code). Since this > object > can be different for different address ranges, different routing > decision > policies can be taken, including taking advantage of knowledge of > the lower than IP level. Has not failed me for many years. > > > ... If it doesn't find a specific route, the packet > > will be sent to the default router. > > I know this is how the stacks on windows and linux work. This means > double traffic for nodes on the same wire (to make it easier to > understand > think an old single 10 MbpS coax) but on different subnets - at best, > it can happen that the router won't cooperate at all, is the likelier > case actually. > > Now I was pointed to a registry hack which allowed windows (xp) to > more or less > have a second IP address on the subnet of interest which solves my > problem (which was lack of connectivity, not the dual traffic). > It is not quite stable, dhcp renew at times begins to fail > and only reset helps (neither disable/enable, nor release/renew > works). But I can live with that for now. Then windows' dhcp renew is > clunky and disruptive anyway so not such a huge difference.
I think you've misunderstood the hack. There is no problem having multiple subnets on a wire, and multiple IPs on a single NIC (in one or multiple subnets). And doing so in Windows is trivial (just select static addresses, enter the "advanced" panel, and add as many as you like). SO if your host is aware of all the subnets on the local wire, and has IPs on all of them, it can directly send packets to all of the other hosts on those subnets, without any intervention by a router. The only time a router is required is if a host is *not* aware of all the subnets on a wire, but the router is, and then the router will, *ahem*, route. What the hack does is to allow both some static IPs/subnets *and* a DHCP assigned IP and subnet on a single NIC, which Windows does not normally allow.