[ In case you receive this as a duplicate, it is, I'm just resending
it unattached to the old thread (which might have caused it to
got misplaced by threading readers). SRB ]
[EMAIL PROTECTED] wrote:
>> but also that Host A uses 6.0.0.1 as the source address instead of
>> the 5.0.0.1 whenever it is making a connection to any address in the
>> range 4.3.2.0-255.
>The simplest way is to add route sort of:
>ip route add 4.3.2.0/24 via GW src 6.0.0.1
Suffice it to say, this works. However...
I *am* running all kinds of routing protocols (OSPF, BGP4, RIP) and
am running hosts with several ethernet cards. This means that there
are redundant routes all over the place. These redundant routes
are to be used when some equipment is turned off or rebooted.
Now, the problem thus becomes that I don't want static routes polluting
my routing tables. These static routes could at a certain point in
time become invalid.
Since, in order to use a specific source address, I need to
specify a gateway, however, this implies that the gateway in question
*must* be up, otherwise I cannot send packets to the route I'm
selecting the fixed source-IP adress for.
Trying to adjust here and not depend on the gateway, I already am doing this:
ip rule add pref 16383 table 127 from 0.0.0.0
ip rule add pref 16384 table 128
ip route add 1.8.5.0/24 via 10.0.1.5 src 1.2.3.27 table 127
ip route add throw 10.0.0.0/8 table 127
ip route add throw 1.2.3.0/27 table 127
ip route add default via 2.1.8.90 src 2.1.8.91 table 127
Gated is meddling in table 128 by itself.
Because of the "from 0.0.0.0" condition, this table/rule only applies
on the *initial* packets *originating* from this host. I.e. once
a TCP connection has been established, table 127 will not be
used anymore, and therefore the routing table managed by gated
will take over.
This is all fine and dandy, but it still means that originating:
a. ICMP packets
b. Locally unbound UDP packets
c. TCP-SYN-packets
are still subject to the gateways specified in table 127.
I.e. 1.8.5.0/24 becomes unreachable as soon as 10.0.1.5 goes down,
similarly the rest of the world (default) becomes unreachable as soon
as 2.1.8.90 goes down.
Is there a way to prevent depending on these gateways?
E.g. is it possible to have the kernel duplicate the packet and send it
to two different gateways at the same time?
Is it possible to specify the source without specifying the gateway?
I tried looking at the routing code in the kernel (2.2.10) to see if
this could easily be accomplished. It turns out to be not so easy.
It would involve choosing the source address first, then simply continue
the walk through the routing tables and pretending we haven't found a route
yet (except having already set the srcaddress of the packet/socket).
Any insight would be appreciated (I'd even settle for a:
- "Too convoluted with the current implementation to do easily".
- Hint as to how to approach the patch. ).
--
Sincerely, [EMAIL PROTECTED]
Stephen R. van den Berg (AKA BuGless).
"Your mouse has moved, Windows NT (tm) needs to be restarted in order for
this change to take effect. Reboot now? [Y]"
-
To unsubscribe from this list: send the line "unsubscribe linux-net" in
the body of a message to [EMAIL PROTECTED]
