Hey Adam, Peer is homonym, in this context peer refers to a BGP session with whom you exchange your customer routes with, and it implies absence of customers and transit in the same router. Whereas you interpreted peer in its wider meaning of any BGP session.
On Fri, 1 Oct 2021 at 21:21, Adam Thompson <athomp...@merlin.mb.ca> wrote: > > 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 > > 100 - 135 Innovation Drive > Winnipeg, MB, R3T 6A8 > (204) 977-6824 or 1-800-430-6404 (MB only) > athomp...@merlin.mb.ca > 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 -- ++ytti
