Re: [External] Re: uPRF strict more

[Adam Thompson <athompson () merlin mb ca>]

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)
athompson () merlin mb ca<mailto:athompson () merlin mb ca>
www.merlin.mb.ca<http://www.merlin.mb.ca/>
________________________________
From: NANOG <nanog-bounces+athompson=merlin.mb.ca () nanog org> on behalf of Randy Bush <randy () 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