Re: [External] Re: uPRF strict more

[Saku Ytti <saku () ytti fi>]

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 <athompson () 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)
> athompson () merlin mb ca
> 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



-- 
  ++ytti