From: La M. H. P. Y. <pi...@ba...> - 2002-12-18 06:20:04
|
On Tue, 17 Dec 2002 16:59:45 -0800 (PST), Sridhar Samudrala <sr...@us...> wr ote: > On Tue, 17 Dec 2002, La Monte Henry Piggy Yarroll wrote: > > > On Tue, 17 Dec 2002 07:48:28 -0600, Jon Grimm <jg...@us...> wrote: > > > Hello Thomas, > > > From the description of your testcase, I believe that you are seeing a > > > deficiency in our handling of failover for assymetric paths. > > > > Yes, and no. Two interfaces of a single host on the same subnet is > > almost always a bad idea. There are ARP-based interactions which can > > be really counter-intuitive and which vary from implementation to > > implementation. > > > > I suggest creating a second subnet for the second interface on host A > > and then attaching that subnet via a small router to 10.241.244.0/24. > > That gives you the same asymmetry without the problems of two > > interfaces on one subnet. > > With the 2 interfaces on different subnets, i think our > implementation should work fine even with the assymetry. With the > recent source address selection support(although it may not be > complete), we do cache a route entry for each destination address. I've not been keeping up. Sorry. > The following algorithm is used to obtain a route entry. > - [R0] When a new transport is created, a route entry is requested for the > corresponding destination address. > - [R1] The source address in the returned route entry is verified to see > if it matches one of the bind addresses. If so, the route entry is > cached in the transport and is used for all transmits over that transport. > - [R2] If the source address does not match any of the bind addresses, we > try to get another route entry for the (dest. address, one of the > bind address as the source address). > - [R3] Before doing a transmit, we validate that the route entry is still > valid. If not, the above process is repeated to get a new route entry. Ah, good! This makes bindx() work safely. Did you do this for both IPv4 and IPv6? The v6 address rules are a LOT of work--I'm not particularly happy with the set that Randy defined in his draft. Hmm... I THINK that this algorithm will never fail over to an alternate route for a given destination address. It depends on what "valid" means for a route. If a route is marked as "invalid" when SCTP decides it is unreachable, then redundant routes to the same destination will get used. The change I was suggesting would essentially replicate the transport structure for each route to a given destination. It does mean we need a separate shared congestion information structure for each destination address. Do we get that for free with a struct dst? > I hope the following picture shows the configuration that La Monte suggested. Nice artwork! Yes, that's exactly what I meant. I added interface names just in case. > +--------------+ +--------------+ +---------------+ > | Machine A |eth0 f1 | Router | | Machine B | > |10.241.245.1 +---------+ 10.241.245.10| eth0 | | > | |eth1 | | +-----+ 10.241.244.3 | > |10.241.244.1 +----+ | | | | | > | | | | 10.241.244.10| | | | > +--------------+ | +------+-------+ | +---------------+ > | | f2 | > | | | > +-----------+------------+ > > Let us see how the above algorithm works with the above setup. > > When both the interfaces are up on Machine A, the following route is > cached in the transport (src:10.241.244.1, dst:10.241.244.3) and all > the packets go through 10.241.244.1. > > When 10.241.244.1 is brought down, the cached route entry will be > become obsolete and a new route entry is requested for 10.241.244.3 > which should return (src:10.241.245.1, dst:10.241.245.10). This will > cause the packets to go through 10.241.245.1. Does Machine A have two static routes to 10.241.244.3 with different metrics? What subsystem makes the cached route entry obsolete? If Router and Machine A are exchanging routing packets, the routing subsystem takes care of it, but then we have little advantage to using SCTP--we are just waiting for the routing algorithm to converge. SCTP has to potential to fail over MUCH faster. I don't know how comfortable I am with SCTP making changes to the routing table. SCTP and e.g. RTP may have radically different ideas about what "unreachable" means... How do heartbeats work? Have we done anything to validate alternate routes? > I have to say that i haven't tried out this configuration, but i > feel that it should work. We should be able to make it work with static routes. > Thanks > Sridhar |