My problem is not with the prefixes assigned to the interfaces of HNCP routers itself, my problem is with the prefixes provided to attached hosts.
If I understand HNCP right then the "uplink" will announce a prefix which should be used by all routers for the attached hosts. The problem will appear if HNCP learns about this prefix through DNCP but the routing protocol cannot provide a route to the uplink (because hysteresis decided one of the links is too bad). I wonder if HNCP routers should apply all addresses/prefixes to its local interfaces, but should check for an existing route to the HNCP router that announce the prefix before providing it via DHCP or RA to hosts. This would not create a dependency loop between routing protocol and HNCP because the routing protocol does only advertise the addresses/prefixes configured on the HNCP interfaces. But it would prevent HNCP to announce a prefix that is not reachable via the routing protocol. Henning Rogge On Wed, Aug 26, 2015 at 11:33 AM, Juliusz Chroboczek <[email protected]> wrote: >> It is not uncommon for wireless links to use some kind of hysteresis >> on a routing protocol. The problem/feature of D/HNCP is that it is >> independent of the routing protocol... so it does not know. > > I'm not sure I'm following you. > > All that shncpd does is to announce attached prefixes over the routing > protocol. It is then the routing protocol's business to pick a path to > one of the routers advertising the prefix (or to drop all such routes, if > the link quality has collapsed too much). > > -- Juliusz _______________________________________________ homenet mailing list [email protected] https://www.ietf.org/mailman/listinfo/homenet
