I am hoping someone can give me a clue on where to look next. This is a 2610 connected directly (via crossover) to a cellular internet device. With the device set to offer the public cellular net assigned IP via DHCP, the router works fine. However, with the device set to offer a private IP, the address is assigned, and the arp table populated but the router can't route to/through it. The config and some debug/show command outputs are attached. Any help would be greatly appreciated!!
I will try to better explain. The device directly connected to the ethernet port via crossover cable is an Airlink Raven. It is an EVDO Internet access device with a single Ethernet port. The device offers 2 options for the internal lan host/s. DHCP, offering a private IP address, which it then NATs to the public address it was assigned when it powered up and registered on the cellular network. Or, it can pass the public address to the internal host (router) via DHCP. I have about 220 of these devices currently deployed using the private addressing scheme. Unfortunately, I have a hand full doing what I have posted above. They are all using 2610 and 2610XM routers with IOS versions 12.3-10 and 12.3-12b. I have included the DHCP output as well as the routing and ARP table to show that the Raven device does indeed assign a DHCP address and gateway(itself). What really concerns me is that even when I try and ping the Raven device at 192.168.13.31, the debug reports "unroutable". I don't see how this can be possible as the device is directly connected and defined in the arp table and is the gateway which just assigned the address to the Ethernet. I first tried to blame this on the Raven devices, but now after some debugging, I believe it to be a router issue due to the "unroutable" output. Only a few seem to have this problem (~10 of 200+), and it goes away if I set the Raven device to assign the public address via DHCP to the router. Unfortunately, I really need to use the private addressing internally. I hope this helps to explain a little better. Again, thanks for your time.