On Wed, 5 Apr 2000, Christopher W. Curtis wrote:
> "Dr. Michael Weller" wrote:
>
> > This is a common misunderstanding (also on configuring dedicated routing
> > hardware): A static route is a static route is a static route...
> >
> > The routing statement just tells where to forward the packets with this
> > destination to. The routing of TCP/IP works completely distributed. Each
> > host only knows about the next hop and so the route taken between hosts
> > might even differ for packets going in the different directions. It has no
> > clue about what the destination does or does not with the packets.
> >
> > So what you want to achieve can only be done by a routing protocol.
>
> Well, this isn't really true. I used to have both gateways installed as
> a metric 1, and when one when down, the other would take over. I could
> tell the difference by doing a tracepath and seeing different gateways
> being used, without any change in my routing tables.
Hmm, I've problems believing that, maybe if both gateways were on
different nets and linux noticed the corresponding network card went down
?
> Now, this works for me, but the problem is that which one Linux choses
> is done by order of definition (minor nit) and then there is no way to
> bring it to the other gateway when I bring it back up, except to delete
> the stable one and then re-add it. I thought that I could do this by
> specifying a metric.
This sounds more sensible.. so you say linux uses always the last
setting.. maybe it should silently remove the overridden one than, or just
refuse to add the new root (to tell the admin he does something which
won't work)
> If this is not possible, and dynamic routes are better managed by
> routed/gated, then can I safely say that the metric value is completely
> useless if you're not running these?
Hmm, yes, I think so, except when they maybe used for load balancing among
different routes.
> I don't know much about TCP/IP, but I know that TCP reports 'Host
> Unreachable' messages, and I would think that using these it could use a
Who would generate these messages? When the gateway is on the same
ethernet as the linux host and he send messages there he simply gets no
answer. The Host Unreachable messages are generated if a gateway does not
know a next hop to route the message too. They also go back to the
originator of the packet. The tcp packet does not carry the list of passed
routers on it and as I said the way back does not necessarily take the
same route. In addition each router would need detailed status information
to know which packets and connections it forwarded (which it doesn't for
performance).
> next route with a higher metric, since it already will choose a
> different route with the same metric. I haven't thought it out much,
> but if a route was marked unreachable, it wouldn't seem unreasonable
> that Linux intermittently poll this route (once a minute?) to see if a
> lower-metric route that went awry came back. (Perhaps route is wrong,
> but host and gateway should be able to work like this.)
Well, what you describe is in most part exactly what a routing protocol
does. If you need this dynamic behaviour setup a routing protocol between
the necessary gateways. For your situation a specific script sending some
pings and setting up routes every few seconds might just do it as well.
I'd run a script which in a loop pings both hosts and sets the default
route to the one which answers. (Make it a little bit more elaborate to
change the route only if the active router changes). BTW, of course any
data coming back to you needs to take the other route too.. (or is this
some fancy masquerading setup?) so this can normally only work if all
routing hosts have some routing protocol running and know about each
other.
However, there is no reason to put this check route and modify settings
process in the kernel. A userlevel tool can do it easily and there are
some.
--
Michael Weller: [EMAIL PROTECTED], [EMAIL PROTECTED],
or even [EMAIL PROTECTED] If you encounter an eowmob account on
any machine in the net, it's very likely it's me.
-
To unsubscribe from this list: send the line "unsubscribe linux-net" in
the body of a message to [EMAIL PROTECTED]
