Re: [External] Re: uPRF strict more
On 10/1/21 19:28, Randy Bush wrote: in fact, this seems to be the modern conservative style for some years. i sometimes wonder if it is worth the config pain. If having routers dedicated to peering, transit or edge functions is worth the extra pain, in lieu of doing it all on one box? Mark.
Re: [External] Re: uPRF strict more
On 10/1/21 20:17, Adam Thompson wrote: 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? Certainly not a router per peer, but a peering router per city, where it may connect to one or more exchange points. This is what we do. Granted, it does increase your budgeting complexity, but in our case, over time, the delineation has actually simplified operations that the architecture has paid itself back many times over. In the real world, this is not always possible, and I understand that a peering router for some networks may also be providing transit as well as edge functions. This is quite normal, even though it can create other complexities depending on whom the eBGP session is with - which then lends itself to running parts or all of the Internet in VRF's and all that hocus pocus. When we tried this sort of thing at a previous job some 14 years ago, it was just simpler to have separate routers each handling transit, peering and customer edge. Mark.
Re: [External] Re: uPRF strict more
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 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 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 side, so traffic started taking an unanticipated > detour via the R side. IRR/RPKI does not solve this: it was a legitimate > advertisement. > ┌─┐ ┌───┐ >┌►│MRnet├►│R│ >│ └─┘ └───┘ >│▲ >││ > ┌─┴───┐ ┌──┴───┐┌──┐ > │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 on behalf of > Randy Bush > Sent: October 1, 2021 12:28 > To: Mark Tinka > Cc: North American Network Operators' Group > 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
Re: [External] Re: uPRF strict more
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 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 side, so traffic started taking an unanticipated detour via the R side. IRR/RPKI does not solve this: it was a legitimate advertisement. ┌─┐ ┌───┐ ┌►│MRnet├►│R│ │ └─┘ └───┘ │▲ ││ ┌─┴───┐ ┌──┴───┐┌──┐ │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 on behalf of Randy Bush Sent: October 1, 2021 12:28 To: Mark Tinka Cc: North American Network Operators' Group 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
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
Re: [External] Re: uPRF strict more
On 10/1/21 01:51, Valdis Klētnieks wrote: Am I insufficently caffienated, or is uRPF the least of your problems if you don't have a full table *and* don't have a default route? 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. Mark.
Re: [External] Re: uPRF strict more
On Thu, 30 Sep 2021 18:12:51 +0200, Mark Tinka said: > I should have said "If you don't plan to run a full BGP table on a > device without a default a route as well, Am I insufficently caffienated, or is uRPF the least of your problems if you don't have a full table *and* don't have a default route? pgp5WFYI4WSQ6.pgp Description: PGP signature
Re: [External] Re: uPRF strict more
- On Sep 30, 2021, at 9:13 AM, Andrew Smith andrew.william.sm...@gmail.com wrote: Hi, > In Ciscoland, you do have to explicitly state that the default route is > eligible > for URPF verification, otherwise you'll get unexpected traffic drops. > ip verify unicast source reachable-via any allow-default Customer: We need a way to prevent spoofing. Dev: Sure, I created a new feature: "ip verify unicast" Customer: We're dropping legitimate traffic! Dev: Oops, sorry about that. Here, a new feature: "ip verify unicast source reachable-via any" Customer: But but but, we don't have a full BGP table! Dev: Oh well... "ip very unicast source reachable via any allow-default" Thanks, Sabri
RE: [External] Re: uPRF strict more
Hi > > > What it does allow is for *deliberate* blackholing for traffic; if you > > null-route a prefix, you now block incoming traffic from that subnet > > as well. This can be useful and it is how we are using URPF. > > I don't think it is implied here, but just for clarification this is > implementation > detail. Loose and blackhole route does not imply this behaviour, It might, it > might not, depending on vendor/implementation. > JunOS by default considers null route as loose path satisfied, and you need > 'set forwarding-options rpf-loose-mode-discard family X' to behave like you > explain. Yes even in cisco land for Ios XR SBRTBH you need set next-hop discard in route policy. You cannot use recursive lookup to null in urpf Brian
Re: [External] Re: uPRF strict more
On Thu, 30 Sept 2021 at 19:00, Hunter Fuller via NANOG wrote: > What it does allow is for *deliberate* blackholing for traffic; if you > null-route a prefix, you now block incoming traffic from that subnet > as well. This can be useful and it is how we are using URPF. I don't think it is implied here, but just for clarification this is implementation detail. Loose and blackhole route does not imply this behaviour, It might, it might not, depending on vendor/implementation. JunOS by default considers null route as loose path satisfied, and you need 'set forwarding-options rpf-loose-mode-discard family X' to behave like you explain. -- ++ytti
Re: [External] Re: uPRF strict more
In Ciscoland, you do have to explicitly state that the default route is eligible for URPF verification, otherwise you'll get unexpected traffic drops. ip verify unicast source reachable-via any allow-default And yes, it's main purpose is for implementing source-based remotely-triggered blackhole (SRTBH). On Thu, Sep 30, 2021 at 10:58 AM Hunter Fuller via NANOG wrote: > On Thu, Sep 30, 2021 at 12:08 AM Mark Tinka wrote: > > If you don't plan to run a full BGP table on a device, don't enable > uRPF, even loose-mode. > > At least in Ciscoland, loose URPF checks will pass if you have a > default route. So I do not think it could result in inadvertent > blackholing of traffic. > > What it does allow is for *deliberate* blackholing for traffic; if you > null-route a prefix, you now block incoming traffic from that subnet > as well. This can be useful and it is how we are using URPF. > > > -- > Hunter Fuller (they) > Router Jockey > VBH M-1A > +1 256 824 5331 > > Office of Information Technology > The University of Alabama in Huntsville > Network Engineering >
Re: [External] Re: uPRF strict more
On 9/30/21 17:56, Hunter Fuller wrote: On Thu, Sep 30, 2021 at 12:08 AM Mark Tinka wrote: If you don't plan to run a full BGP table on a device, don't enable uRPF, even loose-mode. At least in Ciscoland, loose URPF checks will pass if you have a default route. So I do not think it could result in inadvertent blackholing of traffic. What it does allow is for *deliberate* blackholing for traffic; if you null-route a prefix, you now block incoming traffic from that subnet as well. This can be useful and it is how we are using URPF. Agreed. I should have said "If you don't plan to run a full BGP table on a device without a default a route as well, don't enable uRPF, even loose-mode". Principally, we don't run default on any of our service routers. Technically, we point default to the bin on all our service routers, as that's the fastest way for the router to handle illegal traffic it "could" receive. Mark.
Re: [External] Re: uPRF strict more
On Thu, Sep 30, 2021 at 12:08 AM Mark Tinka wrote: > If you don't plan to run a full BGP table on a device, don't enable uRPF, > even loose-mode. At least in Ciscoland, loose URPF checks will pass if you have a default route. So I do not think it could result in inadvertent blackholing of traffic. What it does allow is for *deliberate* blackholing for traffic; if you null-route a prefix, you now block incoming traffic from that subnet as well. This can be useful and it is how we are using URPF. -- Hunter Fuller (they) Router Jockey VBH M-1A +1 256 824 5331 Office of Information Technology The University of Alabama in Huntsville Network Engineering
