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
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
13 matches
Mail list logo
