IMHO, no, it's not worth it... at least, not unless you have a larger budget than mine, a larger department than mine, and possibly more skilled operators than I am.
I don't even grok how this is supposed to work - the only place I "peer" in the classical sense is my local IX; all my other "peers" are ALSO either downstream or upstream networks for me. (e.g. my NREN regional affiliate, who is a lateral peer for many prefixes, but also an upstream access network to reach the national, and then global, REN[s]) If a router doesn't have a default route, and also doesn't have full tables, I can't use it for downstream customers even if they're BGP peers; they're expecting me to either provide full tables, or act as a default gateway. Do people in other parts of the world have access (both physical and logical) to enough bilateral peering (and budgets...) that it makes sense to deploy a router per peer? For the NREN case, it's not full tables, and it's not default routes, but it's still a pretty big table. And they're the location of the "triangle" routing where I have several downstream clients who also peer directly with them. I'm both a lateral "peer" AND a downstream customer to them... so they tried to turn on uRPF on the L3 interfaces towards me and, well, bad things happened to our mutual customers' traffic. Admittedly this was triggered by the downstream customer doing questionable things with different-length prefixes, but the fact remains uRPF causes (sometimes partial) outages anywhere you have multi-path "downstream" clients. And based on the topology, I cannot conceive of any set of ACLs that I could feasibly apply to inbound traffic on the peering link with my NREN affiliate, which makes it... more difficult to be BCP/MARNS-compliant. Commercial traffic regularly transits R&D unexpectedly, and vice-versa: path asymmetry is common here. -Adam P.S. the topology in question was as simple as this. Cust. advertised /N to me, but /N+1 to the R&D side, so traffic started taking an unanticipated detour via the R&D side. IRR/RPKI does not solve this: it was a legitimate advertisement. ┌─────┐ ┌───┐ ┌────────►│MRnet├────►│R&D│ │ └─────┘ └───┘ │ ▲ │ │ ┌─┴───┐ ┌──┴───┐ ┌──────────┐ │Cust.├────►│MERLIN├───►│Commercial│ └─────┘ └──────┘ └──────────┘ Adam Thompson Consultant, Infrastructure Services [1593169877849] 100 - 135 Innovation Drive Winnipeg, MB, R3T 6A8 (204) 977-6824 or 1-800-430-6404 (MB only) athomp...@merlin.mb.ca<mailto:athomp...@merlin.mb.ca> www.merlin.mb.ca<http://www.merlin.mb.ca/> ________________________________ From: NANOG <nanog-bounces+athompson=merlin.mb...@nanog.org> on behalf of Randy Bush <ra...@psg.com> Sent: October 1, 2021 12:28 To: Mark Tinka <mark@tinka.africa> Cc: North American Network Operators' Group <nanog@nanog.org> Subject: Re: [External] Re: uPRF strict more > A partial table with no default is perfectly fine for a peering router. > > As long as your peering router knows how to get to your prefixes and > those of your customers, as well as the prefixes of the networks you > peer with, you're good to go. in fact, this seems to be the modern conservative style for some years. i sometimes wonder if it is worth the config pain. randy
