Well, I got far more answers than I ever expected, and it was heartening
to find that a few people thought things should work the way I thought
they did.
The original question was:
> This is a more general networking question, but I'm asking here because
> the crowd here's pretty smart and I'm trying to do this on a Sun. :)
> Anyway, I'm trying to add a static route to a remote network, but I keep
> getting "network is unreachable". The topography looks like this:
>
> +--------+ +--------+ +--------+ +-------+ +-----------+
> | sun | | router1| | router2| | host | | other net |
> | 108.10 |---|108.62 |---|62.254 |---|42.26 |---|x.x.2.2 |
> | | | 62.137| | 42.254| |x.x.2.1| | x.x.2.0|
> +--------+ +--------+ +--------+ +-------+ +-----------+
>
> Basically, I want to add a route on the sun pointing to "host" for any
> packets intended for the x.x.2.0 net. If I do a 'route add x.x.2.0
> 158.187.42.26 #' with any metric value for '#', I get
> "add net x.x.2.0: gateway 158.187.42.26: Network is unreachable"
>
> The "x.x.2.0" net is not officially assigned within our enterprise and its
> not really feasible to make it so.
>
> Is there a way to do this routing?
I got twenty-some responses to this dilemma, and almost all of them came
down to either putting next-hops into each router or having my LAN group
officially assign a range of IPs for the problem subnet. It turns out
that entries in /etc/gateways and the kernel routing table are supposed to
be entries for remote networks with gateways that are on the same physical
network as the local machine. I had thought that by putting in a gateway
that was on a remote network, the local machine and all intermediate
routers would resolve the next hop until the packet got to the designated
gateway. This is not the case, unfortunately. To do the static-route
method, I'd have to do something like this (based on the diagram above):
sun# route add x.x.2.0 158.187.108.62
router1# route add x.x.2.0 158.187.62.254
router2# route add x.x.2.0 158.187.42.254
host# route add x.x.2.0 x.x.2.1
This method would work, but it becomes *way* too high-maintenance for more
than a couple of these networks. The only real solution is to properly
assign IPs for the target subnet and then let the normal routing protocols
take their course.
Thanks to these people for taking the time to reply to me:
"Robert T. Clift" <rclift@nswc.navy.mil>
Peter Polasek <pete@cobra.brass.com>
Sean Ward <sdward@uswest.com>
Bill Townsley <billt@dat.com>
"Iskander, Tim" <ISKANDER@infimed.com>
Stephen Frost <sfrost@mitretek.org>
"James O'Reilly SSDS, Inc." <jpo@tesla.wcpss.net>
Bill Benedetto <bbenedetto@goodyear.com>
ROBIN_BROWN@phl.com
"Robert T. Clift" <rclift@nswc.navy.mil>
Mitch Adair <mitch@acan.net>
Eugene Kramer <eugene@uniteq.com>
Parthasarathi Palanisami <sarathip@cisco.com>
Birger Wathne <birger@sdata.no>
"K.Ravi" <RAVKRISH.IN.ORACLE.COM.ofcmail@in.oracle.com>
r.vanderhave@PTT-Telecom.NL
Hooman Abrishami <habrish1@osf1.gmu.edu>
Art Freeman <Art.Freeman@ing-barings.com>
"Robert G. Ferrell" <rferrell@usgs.gov>
Amjad Zamil <amjadz@sts.com.jo>
Shriman Gurung <SG@datcon.co.uk>
Sorry the summary took so long. Thanks again to everybody who helped!
Regards,
B
_____________________________________________________________________________
B r i a n L a l o r blalor@hcirisc.cs.binghamton.edu
http://hcirisc.cs.binghamton.edu/~blalor Spam me not.
To get my pgp key, put "get pgp key" in the subject of your message
Brain: Pinky, are you pondering what I'm pondering?
Pinky: Uh, I think so, Brain, but burlap chafes me so.
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:12:36 CDT