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?
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
──┘
>
>
> 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
&g
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 ro
> 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
Android<https://aka.ms/AAb9ysg>
From: Brian Johnson
Sent: Friday, October 1, 2021 8:31:15 AM
To: Adam Thompson
Cc: Amir Herzberg ; Randy Bush ; North
American Network Operators' Group
Subject: Re: uPRF strict more
For strict-mode... Completely
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
> Amir Herzberg
> Sent: September 28, 2021 20:06
> To: Randy Bush
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
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
- 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
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
>
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
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
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
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
On 9/29/2021 5:30 PM, Sabri Berisha wrote:
- On Sep 29, 2021, at 8:03 AM, Blake Hudson bl...@ispn.net wrote:
Hi Blake,
200 deny ip 10.0.0.0 0.255.255.255 any (91057035 matches)
210 deny ip 172.16.0.0 0.15.255.255 any (1366408 matches)
220 deny ip 192.168.0.0 0.0.255.255
On 9/29/21 20:14, Phil Bedard wrote:
Disclosure I work for Cisco and try to look after some of their
peering guidelines.
Agree with Adam’s statement, use uRPF on edge DIA customers. Using it
elsewhere on the network eventually is going to cause some issue and
its usefulness today is
On 9/29/21 19:07, Adam Thompson wrote:
We just ran into a typical case where uRPF caused a partial outage for
one of my customers: the customer is multi-homed, with another
provider that I'm *also* connected to. Customer advertised a
longer-prefix to the other guy, so I started sending
On 9/29/21 23:36, Anoop Ghanwani wrote:
This is not true for all ASICs. Some ASICs choose to incur the
penalty in a different way, e.g., by halving the prefix tables. The
prefix table is then duplicated so that uRPF SA and forwarding DA
lookups can happen in parallel. What kind of
- On Sep 29, 2021, at 8:03 AM, Blake Hudson bl...@ispn.net wrote:
Hi Blake,
> 200 deny ip 10.0.0.0 0.255.255.255 any (91057035 matches)
> 210 deny ip 172.16.0.0 0.15.255.255 any (1366408 matches)
> 220 deny ip 192.168.0.0 0.0.255.255 any (18325538 matches)
These could perhaps be
On Wed, Sep 29, 2021 at 11:38:19PM +0200, Baldur Norddahl wrote:
On Wed, 29 Sept 2021 at 22:07, Jean St-Laurent via NANOG
wrote:
Thanks a lot for sharing.
So 100 Gbps at line rate with 80B frames is about ~150 Mpps.
100 Gbps at line rate with 208B frames is about ~60 Mpps.
It's a
On Wed, 29 Sept 2021 at 22:07, Jean St-Laurent via NANOG
wrote:
> Thanks a lot for sharing.
>
> So 100 Gbps at line rate with 80B frames is about ~150 Mpps.
>
> 100 Gbps at line rate with 208B frames is about ~60 Mpps.
>
> It's a significant penalty.
>
Full rate small packets would be an attack
> Jean
>
> -Original Message-
> From: brad dreisbach
> Sent: September 29, 2021 3:33 PM
> To: Jean St-Laurent
> Cc: 'brad dreisbach' ; 'Phil Bedard' <
> bedard.p...@gmail.com>; 'North American Network Operators' Group' <
> nanog@nanog.org>
> Subject:
American Network Operators' Group'
Subject: Re: uPRF strict more
On Wed, Sep 29, 2021 at 04:07:19PM -0400, Jean St-Laurent wrote:
>Thanks a lot for sharing.
>
>So 100 Gbps at line rate with 80B frames is about ~150 Mpps.
>
>100 Gbps at line rate with 208B frames is about ~6
dreisbach' ; 'Phil Bedard' ;
'North American Network Operators' Group'
Subject: Re: uPRF strict more
On Wed, Sep 29, 2021 at 02:54:43PM -0400, Jean St-Laurent wrote:
>Hi Brad,
>
>I'd be interested to hear more about this pps penalty. Do we talk about 5%
>penalty or something closer to
Sent: September 29, 2021 2:35 PM
To: Phil Bedard
Cc: North American Network Operators' Group
Subject: Re: uPRF strict more
On Wed, Sep 29, 2021 at 06:14:21PM +, Phil Bedard wrote:
Disclosure I work for Cisco and try to look after some of their peering
guidelines.
Agree with Adam’s statement
Sent: September 29, 2021 2:35 PM
To: Phil Bedard
Cc: North American Network Operators' Group
Subject: Re: uPRF strict more
On Wed, Sep 29, 2021 at 06:14:21PM +, Phil Bedard wrote:
>Disclosure I work for Cisco and try to look after some of their peering
>guidelines.
>
>Agree
American Network Operators' Group
Subject: Re: uPRF strict more
We just ran into a typical case where uRPF caused a partial outage for one of
my customers: the customer is multi-homed, with another provider that I'm also
connected to. Customer advertised a longer-prefix to the other guy, so I
, Randy Bush
Cc: North American Network Operators' Group
Subject: Re: uPRF strict more
We just ran into a typical case where uRPF caused a partial outage for one of
my customers: the customer is multi-homed, with another provider that I'm also
connected to. Customer advertised a longer-prefix
...@merlin.mb.ca<mailto:athomp...@merlin.mb.ca>
www.merlin.mb.ca<http://www.merlin.mb.ca/>
From: NANOG on behalf of Amir
Herzberg
Sent: September 28, 2021 20:06
To: Randy Bush
Cc: North American Network Operators' Group
Subject: Re: uPRF strict more
Randy, gr
On 9/29/2021 9:27 AM, Mark Tinka wrote:
On 9/29/21 16:21, Blake Hudson wrote:
I do not use uRPF on upstream/transit/IX links or with multi-homed
customers - or anywhere else where traffic could be asymmetrical; I
prefer to use stateless ACLs at these locations.
On peering and transit
On 9/29/21 16:21, Blake Hudson wrote:
I do not use uRPF on upstream/transit/IX links or with multi-homed
customers - or anywhere else where traffic could be asymmetrical; I
prefer to use stateless ACLs at these locations.
On peering and transit routers, on ports facing the remote side, we
As an eyeball network operator (Cable, DSL, Fiber) we use uRPF strict
mode on customer facing ports on the BRAS gear. Our access gear also
tends to include source address verification via DHCP snooping (as well
as limits on the number of DHCP leases and/or MAC addresses each
customer is
On Tue, 28 Sep 2021 17:47:41 -0700
Randy Bush wrote:
> do folk use uPRF strict mode?
Presumably you mean uRPF. As of a few months ago, the .edu I was doing
netops at, Juniper's 'rpf-check' option was set on all the edge
interfaces where there were only end hosts. This is strict mode. The
uRPF Strict mode was always suppose a widget for source address validation
(SAV). Just like DHCP Lease Query (DOCSIS), the TR-69 ACLs, general ACLs, and
other vendor specific widgets. Like all widgets, there are places where it
works and other place were it does not. The key principle is to
On 9/29/21 11:12, Nick Hilliard wrote:
urpf has its place if your network config build processes aren't
automated to the point that it's no longer necessary. It would be a
net security loss to the internet not to have it widely implemented on
access devices.
As little as 12 months
On 9/29/21 08:03, Saku Ytti wrote:
Vast majority of access ports are stubby, with no multihoming or
redundancy. And uRPF strict is indeed used often here, but answer very
rarely if ever applies for non-stubby port.
Having said that, I'm not convinced anyone should use uRPF at all.
Because
On 9/29/21 02:47, Randy Bush wrote:
do folk use uPRF strict mode? i always worried about the multi-homed
customer sending packets out the other way which loop back to me; see
RFC 8704 §2.2
We do loose-mode for BGP customers, regardless of whether they are
single- or multi-homed.
We do
Hi,
> Having said that, I'm not convinced anyone should use uRPF at all.
> Because you should already know what IP addresses are possible behind the
> port, if you do, you can do ACL, and ACL is significantly lower cost in PPS
> in a
> typical modern lookup engine.
>
uRPF still has it's place
Saku Ytti wrote on 29/09/2021 07:03:
Having said that, I'm not convinced anyone should use uRPF at all.
Because you should already know what IP addresses are possible behind
the port, if you do, you can do ACL, and ACL is significantly lower
cost in PPS in a typical modern lookup engine.
urpf
Vast majority of access ports are stubby, with no multihoming or
redundancy. And uRPF strict is indeed used often here, but answer very
rarely if ever applies for non-stubby port.
Having said that, I'm not convinced anyone should use uRPF at all.
Because you should already know what IP addresses
Randy, great question. I'm teaching that it's very rarely, if ever,
used (due to high potential for benign loss); it's always great to be
either confirmed or corrected...
So if anyone replies just to Randy - pls cc me too (or, Randy, if you could
sum up and send to list or me - thanks!)
Amir
--
42 matches
Mail list logo
