Ethernet routing to a second subnet from a wintel machine

I don't know what a "DPS" is, but just because it supports such manual ARP entries is no indication whatsoever that such techniques are valid and follow the RFCs. It could easily be that you have found a way to trick the DPS into doing something useful but non-standard. However, as I said, I don't know for sure that this is non-standard.

It's nice to know that it is possible, but it's not exactly intuitive or easy to configure... But thanks for the info - I will remember that it is possible to do it this way.

I occasionally have need of more than one IP on the same interface, but I have done that by using VirtualBox machines and choosing to bridge the virtual machine's network card to the host's main physical interface. The extra IP is then the main IP in the virtual machine (Linux, Windows, whatever).

I assume you mean the Registry hack is not intuitive because the standard method of assigning multiple static IP's is both easy and intuitive.

Open the network connectoid that you wish to modify, click on Internet Protocol, click on Properties, enter the first IP and related parameters, then click Advanced and enter as many additional IP addresses as you need. When done, OK your way out.

That works too, but IMHO is overkill for such a simple task.

Now I've learned two things today - thanks again.

Did you read the TAP-Win32 suggestion I made in an earlier post? If my theory is correct, it should give you a way to get a DHCP address and a static address without a registry hack - it should also let you have multiple DHCP addresses, if that is something you want. I'll give it a shot sometime from within a virtual machine.

For the OP's case, then yes it is overkill, which is why I didn't suggest it.

Usually when I am doing some sort of fiddling on the network for which this kind of thing is useful, I prefer to work within a virtual machine anyway. It saves the risk of mucking things up on my main system, and lets me use whatever OS is most suitable for the job in hand (which is typically Linux for these sorts of things).

ot

DPS (Data Processing System) is the OS running on our products.

When claiming incompatibility to an RFC you have to quote which one and perhaps give some details. I have "tricked" it (if implementing the thing can be called that) when the need arose, at the beginning it had - can still have - the same behaviour as windows, it was just a little easier to do - and p[erhaps beneficial on huge broadcast domains where searching the cached ARP table for each outbound packet may be not such a good idea. But for the vast majority of cases most of us face in everyday life this is just some additional functionality.

Dimiter

------------------------------------------------------ Dimiter Popoff Transgalactic Instruments

------------------------------------------------------

I saw that, thanks. I haven't had a need to try it myself, but it looks like it should work.

I am /not/ claiming that it is incompatible with an RFC. I am merely saying that I suspect it might be, and that the fact that the manual ARP method works on one particular system is no indication that it is allowed by the RFCs or that it should be implemented in other systems.

I am not even saying that if it against the RFCs then it's a bad idea - just that if it is against the RFCs, then you can't expect other systems to support this method.

I haven't read the relevant RFCs, or even looked up their numbers, and I am quite happy to be told that I'm wrong here. I'm just suggesting ideas to consider.

I'm not sure RFCs forbid this behavior, but I'm darn sure the RFCs don't require this behavior.

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.

Again, I do not know what the RFCs actually require, but I do know that this 'trick' does not work on most ip stacks.

HTH, M4

You claim you know that?

So how many not fully implemented stacks do you know which behave this way. Can you give us some examples.

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.

Dimiter

------------------------------------------------------ Dimiter Popoff Transgalactic Instruments

------------------------------------------------------

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

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

IP routing has taken place. Ethernet has not.

same

So do I. You may want to understand the posts prior to replying.

Dimiter

------------------------------------------------------ Dimiter Popoff Transgalactic Instruments

------------------------------------------------------

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.

ARP and IP routing are separate indeed.

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.

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.

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

------------------------------------------------------

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

I don't understand what you mean by this statement. Ethernet is not routed.

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

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 snipped-for-privacy@sdf.lonestar.org

he

wire

at

I will make a last try - although I solved my problem before all that theory talk nobody asked for began.

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.

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.

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

------------------------------------------------------

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.

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.

What is wrong with actually following the specs as they were dsigned, and have the router work as it should?

-- mrr

the

e wire

l at

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.

IP

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,

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.