Indeed, someone was recently complaining that FRR is unhappy with a peer with router-id from class E range…
Cheers, Jeff > On Sep 9, 2022, at 09:30, Saku Ytti <s...@ytti.fi> wrote: > > On Fri, 9 Sept 2022 at 09:31, Crist Clark <cjc+na...@pumpky.net> wrote: > >> As I said in the original email, I realize router IDs just need to be >> unique in >> an AS. We could have done random ones with IPv4, but using a well chosen > > In some far future this will be true. We meet eBGP speakers across the > world, and not everyone supports route refresh, _TODAY_, I suspect > mostly because internally developed eBGP implementations and > developers were not very familiar with how real life BGP works. > RFC6286 is not supported by all common implementations, much less > uncommon. And even for common implementations it requires a very new > image (20.4 for Junos, many are even in 17.4 still). > > So while we can consider BGP router-id to be only locally significant > when RFC6286 is implemented, in practice you want to be defensive in > your router-id strategy, i.e. avoid at least scheme of 1,2,3,4,5,6... > on thesis that will be common scheme and liable to increase support > costs down the line due to collision probability being higher. While > it might also add commercial advantage for transit providers, to have > low router-id to win billable traffic. > >> And to get even a little more specific about our particular use case and >> the >> suggestion here to build the device location into the ID, we're >> generally not > > I would strongly advise against any information-to-ID mapping schemes. > This adds complexity and reduces flexibility and requires you to know > the complete problem ahead of time, which is difficult, only have > rules you absolutely must have. I am sure most people here have > experience having too cutesy addressing schemes some time in their > past, where forming an IP address had unnecessary rules in them, which > just created complexity and cost in future. > If you can add an arbitrary 32b ID to your database, this problem > becomes very easy. If not, it's tricky. > > -- > ++ytti
