On Wed, Aug 26, 2015 at 11:50 AM, Mikael Abrahamsson <[email protected]> wrote: > On Wed, 26 Aug 2015, Henning Rogge wrote: > >> 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. > > > Let me rephrase what I think you're saying and tell me if I'm correct: > > Your worry is that HNCP will determine neighbors and speak HNCP well enough, > but the routing protocol thinks the link is so bad, that it's effectively > has partitioned the network (because this was the only link connecting the > two (now) parts), and since there might be two uplinks, you want HNCP to > detect this partition, and only hand out ISP1 prefixes on the side where > ISP1 works, and only ISP2 prefixes, on the ISP2 side that works. Also, if > the network is partitioned, you want prefixes no longer reachable to be sent > corresponding RAs with zero lifetime etc, to make hosts no longer use them > for new connections?
This is a good example. > So one way of doing this would be for hnetd to check if the ISPx prefix (for > instance /56) is in the routing table, and if it isn't, it should not use it > to put addresses on interface etc, and if it goes away (at least for any > duration of time), stop using it. Yes. If DHCP server and radvd wait until the route to the prefix is available in the routing table, we keep the decision about "reachability" to the routing protocol without having a hard dependency on it. > I don't remember seeing this discussed anywhere, but it might very well be > something that should be done. I would imagine HNCP is reacting on ISP1 WAN > link going down and stopping to use the ISP1 prefix, but if there is a break > within the homenet (routing protocol wise), nothing is done as long as HNCP > is up. > > One way of solving this would be to create fate-sharing between HNCP and the > routing protocol. Ie, HNCP wouldn't do anything unless there is a valid > routing protocol adjacency with that neighbor (=fate sharing). Yes. HNCP has its own "control plane" (and it needs this control plane), but if we use the neighbor information within HNCP to decide if a prefix is reachable we might create a different view than the routing protocol, which has its own idea what is reachable and what not. Henning Rogge _______________________________________________ homenet mailing list [email protected] https://www.ietf.org/mailman/listinfo/homenet
