From: Mike Hammett
Date: Fri, 5 Jun 2020 08:17:26 -0500 (CDT)
> I've been wondering a similar thing for how to take advantage of the 150k -
> 250k hardware routes the CRS317 now has in
> v7 beta. That many routes should cover the peering tables for most operators,
> maybe even transit's customer
Yeah, as I mentioned this was a few years ago.
=)
-Original Message-
From: Saku Ytti
Sent: Monday, June 15, 2020 8:54 AM
To: Drew Weaver
Cc: William Herrin ; brad dreisbach ;
nanog@nanog.org
Subject: Re: Partial vs Full tables
Hey Drew,
> The only time we have ever noticed any s
Hey Drew,
> The only time we have ever noticed any sort of operational downside of using
> uRPF loose was when NTTs router in NYC thought a full table was only 500,000
> routes a few years back.
If NTT is 2914 this can no longer happen and it is difficult to see
2914 would ever go back to uRPF.
. =)
-Original Message-
From: NANOG On Behalf Of William Herrin
Sent: Thursday, June 11, 2020 12:18 PM
To: brad dreisbach
Cc: nanog@nanog.org
Subject: Re: Partial vs Full tables
On Thu, Jun 11, 2020 at 9:08 AM brad dreisbach wrote:
> uRPF absolutely kills the pps performance or your hardware
Hi all,
>
> Loose mode RPF will essentially drop traffic received on the interface if the
> router does not have any route for. (will not match a default or a discard
> route, at least in IOS-XR)
>
> As Bill has pointed out, this may drop traffic from some peering networks that
> are not in the
On 12/Jun/20 04:01, Michael Hare wrote:
> Mark (and others),
>
> I used to run loose uRPF on peering/transit links for AS3128 because I used
> to think that tightening the screws was always the "right thing to do".
>
> I instrumented at 60s granularity with vendor J uRPF drop counters on the
se URPF. YMMV.
-Michael
> -Original Message-
> From: NANOG On Behalf Of Mark Tinka
> Sent: Thursday, June 11, 2020 12:14 PM
> To: nanog@nanog.org
> Subject: Re: Partial vs Full tables
>
>
>
> On 10/Jun/20 19:31, William Herrin wrote:
>
> >
> >
Wow. Full distorted vision of reality mode here…
uRPF doesn’t “break” anything. I stand by that. It’s not a religious position.
It’s an operational experience. One that I have multitudes of real world
examples of it working to SOLVE issues.
You seem to be willfully ignorant about how real netwo
On Thu, Jun 11, 2020 at 9:35 AM Brian Johnson wrote:
> You are a dismissive little twit aren’t you. :/
Someone stood up and said, "Nope, nothing I did could possibly have
broken anything." I'm pretty sure that someone was you but feel free
to call me on it if I'm mistaken.
Look, at the risk of d
On 11/Jun/20 00:41, Job Snijders wrote:
>
> Back to basics: as Ytti suggested earlier in the thread, it might be more
> sensible to generate your own default route based on a 'stable anchor prefix'
> coming from the ISP rather than accepting the default your ISP originates
> towards you.
Th
On 10/Jun/20 19:31, William Herrin wrote:
>
> Sorry, it'd be pre-coffee if I drank coffee and I was overly harsh
> here. Let me back up:
>
> The most basic spoofing protection is: don't accept remote packets
> pretending to be from my IP address.
>
> Strict mode URPF extends this to networks: d
> On Jun 10, 2020, at 6:40 PM, brad dreisbach wrote:
>
> On Thu, Jun 11, 2020 at 12:01:38AM +0200, Baldur Norddahl wrote:
>> Am I correct in assuming loose mode RPF only drops packets from unannounced
>> address space in the global routing table? And the downside of doing so is
>> that sometim
You are a dismissive little twit aren’t you. :/
> On Jun 11, 2020, at 9:56 AM, William Herrin wrote:
>
> On Thu, Jun 11, 2020 at 6:25 AM Brian Johnson
> wrote:
>> I fully understand that I have not “broken” anything.
>
> Handwaving, la la la, only sunshine in the sky. Got it.
>
> -Bill
>
>
On Thu, Jun 11, 2020 at 9:08 AM brad dreisbach wrote:
> uRPF absolutely kills the pps performance or your hardware due to the packet
> having to be recirculated to do the check(at least this is the case on every
> platform that ive ever tested it on). use acl's to protect your edge.
Hi Brad,
Don
On Thu, Jun 11, 2020 at 12:01:38AM +0200, Baldur Norddahl wrote:
Am I correct in assuming loose mode RPF only drops packets from unannounced
address space in the global routing table? And the downside of doing so is
that sometimes we do receive packets from that address space, usually back
scatte
On 6/10/20 6:01 PM, Baldur Norddahl wrote:
> Am I correct in assuming loose mode RPF only drops packets from
> unannounced address space in the global routing table? And the downside
> of doing so is that sometimes we do receive packets from that address
> space, usually back scatter from tracerout
On Thu, Jun 11, 2020 at 6:25 AM Brian Johnson wrote:
> I fully understand that I have not “broken” anything.
Handwaving, la la la, only sunshine in the sky. Got it.
-Bill
--
William Herrin
b...@herrin.us
https://bill.herrin.us/
> On Jun 10, 2020, at 3:05 PM, William Herrin wrote:
>
> On Wed, Jun 10, 2020 at 11:20 AM Brian Johnson
> wrote:
>> Disagree with Bill here. It will depend on the complexity of the network as
>> to use of uRPF in any mode (loose or strict). In general, I never use uRPF
>> on transit links
Once upon a time, William Herrin said:
> On Wed, Jun 10, 2020 at 3:02 PM Baldur Norddahl
> wrote:
> > Am I correct in assuming loose mode RPF only drops packets from unannounced
> > address space in the global routing table?
>
> Actually, I'm not sure since my plan around RPF is "10 foot pole."
On Wed, Jun 10, 2020 at 3:02 PM Baldur Norddahl
wrote:
> Am I correct in assuming loose mode RPF only drops packets from unannounced
> address space in the global routing table?
Actually, I'm not sure since my plan around RPF is "10 foot pole." Is
"loose mode" really just filtering packets the c
On Tue, Jun 9, 2020, at 08:04, Mark Tinka wrote:
> On 5/Jun/20 18:49, Saku Ytti wrote:
> > The comparison isn't between full or default, the comparison is
> > between static default or dynamic default. Of course with any default
> > scenario there are more failure modes you cannot route around. But
Am I correct in assuming loose mode RPF only drops packets from unannounced
address space in the global routing table? And the downside of doing so is
that sometimes we do receive packets from that address space, usually back
scatter from traceroute or other ICMP messages.
Currently about 25% of t
On Wed, Jun 10, 2020 at 11:20 AM Brian Johnson wrote:
> Disagree with Bill here. It will depend on the complexity of the network as
> to use of uRPF in any mode (loose or strict). In general, I never use uRPF on
> transit links and use pure filters to ensure accurate filters are in place.
> uRP
Disagree with Bill here. It will depend on the complexity of the network as to
use of uRPF in any mode (loose or strict). In general, I never use uRPF on
transit links and use pure filters to ensure accurate filters are in place.
uRPF may be used internally in either mode to great advantage and
On Wed, Jun 10, 2020 at 9:43 AM William Herrin wrote:
> The answer is "no," you're not running reverse-path filtering on a BGP
> speaker, not even in loose mode, because that's STUPID.
Sorry, it'd be pre-coffee if I drank coffee and I was overly harsh
here. Let me back up:
The most basic spoofin
On Wed, Jun 10, 2020 at 9:25 AM Robert Blayzor wrote:
> One caveat that may or may not play into this is if you use uRPF (loose)
> on your transit links.
Hi Robert,
The answer is "no," you're not running reverse-path filtering on a BGP
speaker, not even in loose mode, because that's STUPID. At
On 6/4/20 11:00 PM, James Breeden wrote:
> And before I get asked why not just run full tables, I'm looking at
> regional approaches to being able to use smaller, less powerful routers
> (or even layer3 switches) to run some areas of the network where we can
> benefit from summarization and full ta
Hello,
Some time ago we had a similar discussion on this list, in that
moment I shared a small study we did in LACNIC but we had it only in
Spanish. Here is the version in English (BGP: To filter or not to filter
by prefix size. That is the question ):
https://.acostasite.com/2019/07/
On 5/Jun/20 19:45, Chuck Anderson wrote:
>
> I do the above using routes to *.root-servers.net to contribute to the
> aggregate 0/0.
What about if you learn those via peering and not transit :-)?
Mark.
On 5/Jun/20 18:49, Saku Ytti wrote:
>
> The comparison isn't between full or default, the comparison is
> between static default or dynamic default. Of course with any default
> scenario there are more failure modes you cannot route around. But if
> you need default, you should not want to use
On 5/Jun/20 18:30, Michael Hare via NANOG wrote:
>
> I'm considering an approach similar to Tore's blog where at some point I keep
> the full RIB but selectively populate the FIB. Tore, care to comment on why
> you decided to filter the RIB as well?
We do this in the Metro, where FIB is lim
On Tue, 9 Jun 2020 at 02:22, Josh Hoppes wrote:
> Juniper Networks has also tried using Bloom filters.
>
> https://patents.google.com/patent/US20170187624
>
> I think the QFX10002 was the first product they made which used this approach.
>
> https://forums.juniper.net/t5/Archive/Juniper-QFX10002-
There are many different tries -- see here for some examples.
https://www.drdobbs.com/cpp/fast-ip-routing-with-lc-tries/184410638
And an enhancement to LC-tries
http://www.diva-portal.org/smash/record.jsf?pid=diva2%3A469814&dswid=-2401
Then there are radix-n (n-ary trie) lookups, e.g. radix-4 wou
Juniper Networks has also tried using Bloom filters.
https://patents.google.com/patent/US20170187624
I think the QFX10002 was the first product they made which used this approach.
https://forums.juniper.net/t5/Archive/Juniper-QFX10002-Technical-Overview/ba-p/270358
On Mon, Jun 8, 2020 at 1:45 P
On Mon, Jun 8, 2020 at 10:52 AM wrote:
> Every "fast" FIB implementation I'm aware of takes a set of prefixes, stores
> them in some sort of data structure, which can perform a longest-prefix
> lookup on the destination address and eventually get to an actual physical
> interface for forwarding
sage -
From: "Nick Hilliard"
To: "William Herrin"
Cc: "NANOG"
Sent: Monday, June 8, 2020 1:14:01 PM
Subject: Re: Partial vs Full tables
William Herrin wrote on 08/06/2020 18:53:
> 4 gigs and 2 cores is more than sufficient for a 1 gbps router at
> the current
On Mon, Jun 8, 2020 at 11:14 AM Nick Hilliard wrote:
> William Herrin wrote on 08/06/2020 18:53:
> > 4 gigs and 2 cores is more than sufficient for a 1 gbps router at
> > the current 800k routes
> 1gbps is residential access speed. Is this still useful in the dfz?
Not really the point. You can g
These are the first steps to optimization. Hysteresis is another.
They work in ideal cases. However, when coding, we need to consider
all cases. How do you set the timer?
The timer has to anticipate the future. It's like an automatic
transmission. It can't anticipate the future. However, the worst
On Mon, Jun 08, 2020 at 07:14:01PM +0100, Nick Hilliard wrote:
> William Herrin wrote on 08/06/2020 18:53:
> >4 gigs and 2 cores is more than sufficient for a 1 gbps router at
> >the current 800k routes
>
> 1gbps is residential access speed. Is this still useful in the dfz?
Yes, it is.
... JG
--
William Herrin wrote on 08/06/2020 18:53:
4 gigs and 2 cores is more than sufficient for a 1 gbps router at
the current 800k routes
1gbps is residential access speed. Is this still useful in the dfz?
Nick
On Sun, Jun 7, 2020 at 11:07 PM Saku Ytti wrote:
> I'll take my imagination boat from the dry docks and sail to 2035. Lot
> of people still run Jericho ANET, it is the new CAT6500 PFC3. DFZ
> won't fit it anymore without redundant-specifics.
> Are we at all concerned that someone in the DFZ advert
On 08.06.2020 07.56, Jakob Heitz (jheitz) via NANOG wrote:
FIB compression comes with some risks.
When routes churn, there are certain cases when you have to decompress the FIB.
Then, the FIB must have the space, or else OOPS.
If a set of compressed routes has to change to decompress some and
On 08.06.2020 08.04, Saku Ytti wrote:
On Mon, 8 Jun 2020 at 00:55, Ryan Woolley wrote:
order of 2x) on even very-well-connected routers. This is implemented
by Arista in the feature that Yang linked to with the URL containing
"fib-compression", but the actual command is better named: "ip f
On Mon, 8 Jun 2020 at 00:55, Ryan Woolley wrote:
> order of 2x) on even very-well-connected routers. This is implemented
> by Arista in the feature that Yang linked to with the URL containing
> "fib-compression", but the actual command is better named: "ip fib
> compression redundant-specifics f
FIB compression comes with some risks.
When routes churn, there are certain cases when you have to decompress the FIB.
Then, the FIB must have the space, or else OOPS.
If a set of compressed routes has to change to decompress some and compress a
different set to improve overall compression, there i
On Fri, Jun 5, 2020 at 9:50 PM William Herrin wrote:
>
> On Fri, Jun 5, 2020 at 6:08 PM Yang Yu wrote:
> > On Fri, Jun 5, 2020 at 10:39 AM William Herrin wrote:
> > > Speak of which, did anyone ever implement FIB compression? I seem to
> > > remember the calculations looked really favorable for
> On Jun 5, 2020, at 2:11 PM, Ryan Rawdon wrote:
>
>
>> On Jun 4, 2020, at 11:00 PM, James Breeden wrote:
>>
>> I have been doing a lot of research recently on operating networks with
>> partial tables and a default to the rest of the world. Seems like an easy
>> enough approach for regi
ot;Tore Anderson" , nanog@nanog.org
Sent: Friday, June 5, 2020 8:07:52 PM
Subject: Re: Partial vs Full tables
On Fri, Jun 5, 2020 at 10:39 AM William Herrin wrote:
> Speak of which, did anyone ever implement FIB compression? I seem to
> remember the calculations looked really favorable
On Fri, Jun 5, 2020 at 6:08 PM Yang Yu wrote:
> On Fri, Jun 5, 2020 at 10:39 AM William Herrin wrote:
> > Speak of which, did anyone ever implement FIB compression? I seem to
> > remember the calculations looked really favorable for the leaf node
> > use case (like James') where the router sits a
On Fri, Jun 5, 2020 at 10:39 AM William Herrin wrote:
> Speak of which, did anyone ever implement FIB compression? I seem to
> remember the calculations looked really favorable for the leaf node
> use case (like James') where the router sits at the edge with a small
> number of more or less equiva
fre. 5. jun. 2020 20.12 skrev Ryan Rawdon :
>
>
> Shortly after filtering, we started occasionally finding destinations that
> were unreachable over the Internet (generally /24) due to:
I have observed this too.
I know of no router that can do this, but you need the router to
automatically acce
> On Jun 4, 2020, at 11:00 PM, James Breeden wrote:
>
> I have been doing a lot of research recently on operating networks with
> partial tables and a default to the rest of the world. Seems like an easy
> enough approach for regional networks where you have maybe only 1 upstream
> transit a
On Fri, Jun 05, 2020 at 10:20:00AM -0700, William Herrin wrote:
> On Fri, Jun 5, 2020 at 9:49 AM Saku Ytti wrote:
> > The comparison isn't between full or default, the comparison is
> > between static default or dynamic default. Of course with any default
> > scenario there are more failure modes
On Fri, Jun 5, 2020 at 10:30 AM Tore Anderson wrote:
> In the end I felt that running in production with the RIB and the FIB
> perpetually out of sync was too much of a hack, something that I would
> likely come to regret at a later point in time. That approach never
> made it out of the lab.
Spe
* Michael Hare
> I'm considering an approach similar to Tore's blog where at some
> point I keep the full RIB but selectively populate the FIB. Tore,
> care to comment on why you decided to filter the RIB as well?
Not «as well», «instead».
In the end I felt that running in production with the R
On Fri, 5 Jun 2020 at 20:20, William Herrin wrote:
> It's a little more nuanced than that. You probably don't want to
> accept a default from your transit but you may want to pin defaults
> (or a set of broad routes as I did) to "representative" routes you do
> accept from your transit. By "pin"
On Fri, Jun 5, 2020 at 9:49 AM Saku Ytti wrote:
> The comparison isn't between full or default, the comparison is
> between static default or dynamic default. Of course with any default
> scenario there are more failure modes you cannot route around. But if
> you need default, you should not want
Hey Michael,
On Fri, 5 Jun 2020 at 19:37, Michael Hare wrote:
> Just because DFZ role device can advertise loopback unconditionally in IGP
> doesn't mean the DFZ actually has a valid eBGP or iBGP session to another
> DFZ. It may be contrived but could this not be a possible way to blackhole
Saku-
> In internal network, instead of having a default route in iBGP or IGP,
> you should have the same loopback address in every full DFZ router and
> advertise that loopback in IGP. Then non fullDFZ routers should static
> route default to that loopback, always reaching IGP closest full DFZ
>
st-ix.com
>
> --
> *From: *"James Breeden"
> *To: *nanog@nanog.org
> *Sent: *Thursday, June 4, 2020 10:00:51 PM
> *Subject: *Partial vs Full tables
>
> I have been doing a lot of research recently on operating networks with
> partial t
On Thu, Jun 4, 2020 at 8:02 PM James Breeden wrote:
> I come to NANOG to get feedback from others who may be doing this. We have
> 3 upstream transit providers and PNI and public peers in 2 locations. It'd
> obviously be easy to transition to doing partial routes for just the peers,
> etc, but I'
om: "James Breeden"
To: nanog@nanog.org
Sent: Thursday, June 4, 2020 10:00:51 PM
Subject: Partial vs Full tables
I have been doing a lot of research recently on operating networks with partial
tables and a default to the rest of the world. Seems like an easy enough
approach for regiona
* Saku Ytti
> On Fri, 5 Jun 2020 at 11:23, Tore Anderson wrote:
>
> > Sure you can, you just ask them. (We did.)
>
> And is it the same now? Some Ytti didn't 'fix' the config last night?
> Or NOS change which doesn't do conditional routes? Or they
> misunderstood their implementation and it doe
On Fri, 5 Jun 2020 at 11:23, Tore Anderson wrote:
> Sure you can, you just ask them. (We did.)
And is it the same now? Some Ytti didn't 'fix' the config last night?
Or NOS change which doesn't do conditional routes? Or they
misunderstood their implementation and it doesn't actually work like
the
* Saku Ytti
> On Fri, 5 Jun 2020 at 10:48, Tore Anderson wrote:
>
> > We started taking defaults from our transits and filtering most of the
> > DFZ over three years ago. No regrets, it's one of the best decisions we
> > ever made. Vastly reduced both convergence time and CapEx.
>
> Is this ver
On Fri, 5 Jun 2020 at 10:48, Tore Anderson wrote:
> We started taking defaults from our transits and filtering most of the
> DFZ over three years ago. No regrets, it's one of the best decisions we
> ever made. Vastly reduced both convergence time and CapEx.
Is this verbatim? I don't think there
* James Breeden
> I come to NANOG to get feedback from others who may be doing this. We
> have 3 upstream transit providers and PNI and public peers in 2
> locations. It'd obviously be easy to transition to doing partial
> routes for just the peers, etc, but I'm not sure where to draw the
> line o
On Thu, Jun 4, 2020 at 8:04 PM James Breeden wrote:
> I have been doing a lot of research recently on operating networks with
> partial tables and a default to the rest of the world. Seems like an easy
> enough approach for regional networks where you have maybe only 1 upstream
> transit and some
I have been doing a lot of research recently on operating networks with partial
tables and a default to the rest of the world. Seems like an easy enough
approach for regional networks where you have maybe only 1 upstream transit and
some peering.
I come to NANOG to get feedback from others who
69 matches
Mail list logo
