>> Big network ..... GW ---- Small network >> With split horizon, only the routing table of the small network is sent >> over the slow link.
> split horizon only helps in the GW → "Big network" direction, but cannot > do anything in the "Big network" → GW direction. That's right. We're reducing total traffic by 50%, but the resulting load is hightly asymmetric. > A B C D ---- E > | | | | > ------------- > If there are n neighbours, for each new or retracted route, there will be > n broadcast messages, instead of just one with split horizon. In principle, you're right. But in practice, you're not setting up routers to have just one interface: A' B' C' | | | A B C D ---- E | | | | +---+---+---+ In this case, the route flap is going to be reannounced by each router on the other interface, and so we're back at a (roughly) 50% reduction. > This may be significant if the shared medium is slow (emulated by a VPN) Ah, I see. You're performing routing both in the VPN (tinc) and in Babel, and the two routing algorithms are interacting in unpleasant ways. Ideally, you wouldn't do that -- you'd use the VPN for point-to-point links only, and let Babel take care of the routing. If for some reason you insist on routing inside tinc and want Babel to take care of the resulting mess, you could modify Babel to send multiple unicasts instead of a single multicast (for updates only -- hellos still need to be multicast). I'd be willing to accept a patch that does that (configured by setting the maximum number of unicasts before we switch to multicast) assuming it's clean enough and avoids code duplication. Perhaps related, Ray Hunter said the following on the Homenet list: Multicast has issues on some link topologies (e.g. where it has to be emulated), and in situations where devices attempt to sleep for as long as possible. So even though link-local multicast may be part of the IPv6 base spec, it may be desirable to avoid use of multicast traffic where possible. e.g. a routing protocol could perform initial neighbor discovery using multicast, but then switch to unicast when maintaining individual neighbor associations on the longer term, or for exchanging information with specific neighbors. -- Juliusz _______________________________________________ Babel-users mailing list [email protected] http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/babel-users
