On Mar 2, 2015, at 10:27 AM, <Paul_Koning at Dell.com> <Paul_Koning at Dell.com> wrote: On Mar 1, 2015, at 5:50 PM, Hans Vlems <hvlems at zonnet.nl> wrote: Paul, so if more decnet routers are heard of on the land, what happens with: A) the list that gets transmitted is truncated, the 32 most recent routers and the transmitting host itself are on it? B) the locally maintained list, is that also limited to 33 entries? Almost (A) but not quite. If more than the max routers show up on the Ethernet (whatever that limit is it can be set to less than 33), the excess are dropped first based on router priority, and if it s a tie then by address (higher address wins). See section 9.1.1 in the DNA Routing spec. The adjacency that s rejected as a result is logged event 4.16, with no reason code because the Netman spec forgot to define a specific reason code for this particular case. And yes, the locally maintained list is also limited. That s critical; distributed routing protocols require that all routers agree on the routing data (after transient differences due to changes propagating have settled out). Otherwise you end up with persistent loops. So the information that s transmitted to other routers and the information used for local computation must be the same. An analogous issue appears in link state routing (Phase V and other link state protocols derived from it, like OSPF). There, it is necessary for all routers to store the same link state the same map of the area. If some don t have enough memory to do that, some serious magic is required to ensure they are handled specially, since they can t calculate correct routes if they can t store all the inputs. This is why Phase V has special rules for overloaded routers. I remember when that issue was first raised, and the brainstorming that resulted in an attempt to arrive at a solution. The current one is due to Mike Shand, as I recall, and is incredibly simple; before that one, some much more complicated approaches were concocted by other members of the team. paul