Re: AWS WAF list

ust be a reason why the web site chooses the WAF list to block out >> the victim? If so why not the victim to contact the website to request them >> to talk to the waf list provider to remove victim ip block? >> >> >> >> Edy >> >> >> >

Re: AWS WAF list

t;> We actually got a response from one WAF user to "connect to another >>> network to log in, then you should be able to use the site, because it's >>> just the login page that's protected". >>> >>> I am working with someone off-list, so I have ho

Re: AWS WAF list

The whole situation with these WAF as a service setups is a nightmare for the affected (afflicted) parties. I saw this problem from both sides when I was at Akamai. It’s not great from the service provider side, but it’s an absolute shit show for anyone on the wrong side of a block. There’s

Re: IPv6 uptake (was: The Reg does 240/4)

I can’t speak to Cisco as I don’t have recent experience there. Juniper, Linux, Palo Alto, and most others I’ve dealt with in the last 5 years pose no significant difference in writing policy for IPv6 vs. the process for IPv4. OwenOn Feb 17, 2024, at 10:23, Justin Streiner wrote:We went pretty

Re: IPv6 uptake (was: The Reg does 240/4)

> Think of it like this: you have a guard, you have a fence and you have > barbed wire on top of the fence. Can you secure the place without the > barbed wire? Of course. Can an intruder defeat the barbed wire? Of > course. Is it more secure -with- the barbed wire? Obviously. > NAT is like the

Re: IPv6 uptake (was: The Reg does 240/4)

Bill, same scenario, but instead of fat fingering an outbound rule, you fat finger a port map for inbound connections to a different host and get the destination address wrong. Still hacked. NAT doesn’t prevent fat fingers from getting you hacked, it just changes the nature of the required

Re: IPv6 uptake (was: The Reg does 240/4)

Most firewalls are default deny. Routers are default allow unless you put a filter on the interface. NAT adds nothing to security (Bill and I agree to disagree on this), but at best, it complicates the audit trail. Owen > On Feb 16, 2024, at 15:19, Jay R. Ashworth wrote: > > -

Re: IPv6 uptake (was: The Reg does 240/4)

> On Feb 16, 2024, at 14:20, Jay R. Ashworth wrote: > > - Original Message - >> From: "Justin Streiner" > >> 4. Getting people to unlearn the "NAT=Security" mindset that we were forced >> to accept in the v4 world. > > NAT doesn't "equal" security. > > But it is certainly a

Re: The Reg does 240/4

Mike, it’s true that Google used to be a lot less strict on IPv4 email than IPv6, but they want SPF and /or DKIM on everything now, so it’s mostly the same. There is less reputation data available for IPv6 and server reputation is a harder problem in IPv6, but reputation systems are becoming

Re: The Reg does 240/4

For everyone’s amusement: [root@owen log]# grep 'IPv6' maillog | wc -l 2648 [root@owen log]# grep 'IPv4' maillog | wc -l 0 Now admittedly, this isn’t really a fair report because sendmail doesn’t tag IPv4 address as “IPv4” like it does IPv6 addresses. e.g.: Feb 15 19:22:59 owen

Re: The Reg does 240/4

> On Feb 15, 2024, at 03:29, Christopher Hawker wrote: > >  > Owen, > > This is the first time we've presented this case so I'm uncertain as to how > you've come to the conclusion that I've "presented [my] case numerous times" > and that we "continue to persist". > It may be your first

Re: The Reg does 240/4

> On Feb 14, 2024, at 18:25, Stephen Satchell wrote: > > On 2/14/24 4:23 PM, Tom Samplonius wrote: >> The best option is what is happening right now: you can’t get new IPv4 >> addresses, so you have to either buy them, or use IPv6. The free market >> is solving the problem right now.

Re: The Reg does 240/4

11 AM > To: nanog@nanog.org > Subject: Re: The Reg does 240/4 > > It appears that William Herrin said: > >On Wed, Feb 14, 2024 at 9:23 AM Owen DeLong via NANOG > >wrote: > >> Think how many more sites could have IPv6 capability already if this > >> wasted e

Re: The Reg does 240/4

> > 1. RIRs, following > https://www.icann.org/resources/pages/allocation-ipv4-rirs-2012-02-25-en, > would request new /8s, and receive those allocations. I don’t think this applies any more. I could be wrong, but I think based on current practice, IANA would simply distribute 3 of the 16 /8s

Re: The Reg does 240/4

That experiment already failed with the original v6 adoption process. It’s been more than 20 years and all we have proven is that as long as people can have an excuse to avoid v6 deployment, they will continue to do so. Giving them another 20 years of excuses is a step against the collective

Re: The Reg does 240/4

This gift from the bad idea fairy just keeps on giving. You’ve presented your case numerous times. The IETF has repeatedly found no consensus for it and yet you persist. Think how many more sites could have IPv6 capability already if this wasted effort had been put into that, instead. OwenOn Feb

IPv6 Test Pages for Fortune 500 and Top 100 web sites are back

Don’t know how much anyone will still care about these pages as there are lots of other sources of similar data these days. However, I finally got around to fixing the two pages I maintain: http://www.delong.com/ipv6_fortune500.html and http://www.delong.com/ipv6_alexa500.html In the case of

Re: route: 0.0.0.0/32 in LEVEL3 IRR

> On Jan 31, 2024, at 23:19, Frank Habicht wrote: > > On 01/02/2024 01:45, Tom Beecher wrote: >> Seems a bit dramatic. Companies all over the world have been using other >> people's public IPs internally for decades. I worked at a place 20 odd years >> ago that had an odd numbering scheme

Re: route: 0.0.0.0/32 in LEVEL3 IRR

For many years, a large customer (telco/VOIP/ISP carrier that should have known better) of a former employer was using 11.0.0.0/8 as an extension of 10.0.0.0/8 and literally forced said employer to carry their routes to those prefixes in those tables (or lose an extremely lucrative contract).

Re: SOVC - BGp RPKI

SOVC appears to be a Cisco-specific acronym and it’s pretty certain that the OVC stands for Origin Validation Cache. My best intuition based on the research I’ve been able to do is that the S stands for Secure (on the pretense that RPKI and Origin Validation have something to do with security

Re: If I announce 192.0.2.0/24, do I need a discard route? (Looking for a reference…)

> On Jan 31, 2024, at 13:46, Warren Kumari wrote: > > > > > > On Wed, Jan 31, 2024 at 3:56 PM, William Herrin > wrote: >> On Wed, Jan 31, 2024 at 12:30 PM Warren Kumari > > wrote: >> >> So, let's say I'm announcing some address space (e.g

Re: If I announce 192.0.2.0/24, do I need a discard route? (Looking for a reference…)

> On Jan 31, 2024, at 12:30, Warren Kumari wrote: > > Hey all, > > This falls into the "Somebody is wrong on the Internet …" category. Doesn’t everything eventually end up there? > So, let's say I'm announcing some address space (e.g 192.0.2.0/24 > ), but I'm only

Re: SOVC - BGp RPKI

I’m not sure what the acronym is, but I believe it’s an origin validator connection. (bap rpki server) Owen > On Jan 31, 2024, at 05:16, Mohammad Khalil wrote: > > Greetings > Am have tried to find out what is the abbreviation for SOVC with no luck. > > #sh bgp ipv4 unicast rpki servers >

Re: Networks ignoring prepends?

> > When you twist a policy knob to move BGP off its defaults, you take > responsibility for making a better routing choice. And for correcting > that choice if it should prove faulty. What I've seen here in this > thread is a bunch of folks abdicating that responsibility. That's not >

Re: Networks ignoring prepends?

BGP is more of a PDVP (Policy Distance Vector Protocol). Policy will always override Distance in BGP and is pretty much the key difference between an EGP and an IGP. Once you recognize that, the rest makes much more sense. Owen > On Jan 23, 2024, at 14:29, William Herrin wrote: > > On

Re: Networks ignoring prepends?

> On Jan 23, 2024, at 10:47, Jay Borkenhagen wrote: > > William Herrin writes: >> >> The best path to me from Centurylink is: 3356 1299 20473 11875 >> >> The path Centurylink chose is: 3356 47787 47787 47787 47787 53356 >> 11875 11875 11875 >> >> Do you want to tell me again how that's a

Re: Networks ignoring prepends?

I’d bet that 47787 is a paying century link customer. As such, despite the ugliness of the path, CL probably local prefs everything advertised by them higher than any non-paying link. I’m willing to bet 1299 is peered and not paying CL. Sending bits for revenue is almost always preferable to

Re: Networks ignoring prepends?

And now you are faced with an object lesson as to why TE routes are so prevalent. Less specifics are your only functional alternative here. In most cases, you shouldn’t need more than 2 per prefix. Owen > On Jan 22, 2024, at 12:16, William Herrin wrote: > > On Mon, Jan 22, 2024 at 5:23 

Re: IRR information & BYOIP (Bring Your Own IP) with Cloud Providers

On Jan 21, 2024, at 16:10, Christopher Morrow wrote:On Sun, Jan 21, 2024, 5:39 PM Owen DeLong <o...@delong.com> wrote:On Jan 21, 2024, at 12:07, Christopher Morrow <morrowc.li...@gmail.com> wrote:On Fri, Jan 19, 2024, 4:55 PM Owen DeLong via NANOG <nanog@nanog.org> wrote:Soun

Re: IRR information & BYOIP (Bring Your Own IP) with Cloud Providers

On Jan 21, 2024, at 12:07, Christopher Morrow wrote:On Fri, Jan 19, 2024, 4:55 PM Owen DeLong via NANOG <nanog@nanog.org> wrote:Sounds like you’ve got a weird mix of route origination. Why wouldn’t you advertise to Google via BGP and have your prefix originate from your own ASN?I

Re: Stealthy Overlay Network Re: 202401100645.AYC Re: IPv4 address block

> 2)Philosophically, IPv6 and IPv4 are kind of like two religions, each > with its own believers. As long as the devotees of each focus on their > respective passion, the world will be peaceful. As soon as one camp imposes > its preference onto the other, friction starts. Unchecked, it can

Re: One Can't Have It Both Ways Re: Streamline the CG-NAT Re: EzIP Re: IPv4 address block

On 2024-01-19 04:02, Owen DeLong wrote: Any host connected to a reasonably well peered ISP (e.g. NOT Cogent) with IPv6 should be able to communicate with any other such host so long as the administrative policies on both sides permit it.

Re: Backward Compatibility Re: 202401100645.AYC Re: IPv4 address block

> On Jan 19, 2024, at 09:21, Charles Polisher wrote: > > Owen DeLong wrote: > > > Some, but not a lot. In the case of the DTMF transition, the > > network and handsets were all under the central control of a > > single provider at a time when the

Re: IRR information & BYOIP (Bring Your Own IP) with Cloud Providers

Sounds like you’ve got a weird mix of route origination. Why wouldn’t you advertise to Google via BGP and have your prefix originate from your own ASN? Owen > On Jan 19, 2024, at 02:39, kubanowy wrote: > > Hi, > We have our own prefix assignment from ARIN. We have our infrastructure in >

Re: okta probing

I think this is a new form of dDOS and it is sometimes performed by Bots. What they are achieving is annoying you. From your post, it appears to be working. It’s also possible (depending on the account name) that it’s a mistype. Owen > On Jan 12, 2024, at 17:50, Randy Bush wrote: > > can

Re: Backward Compatibility Re: 202401100645.AYC Re: IPv4 address block

> On Jan 15, 2024, at 09:37, Abraham Y. Chen wrote: > > Hi, Christopher" > > 1)" IPv6 is designed to replace IPv4. ": > Correct. But, this is not like Ten Commandments that God gave to his > children. Even such had not worked out in most cases. In real life, technical > backward

Re: One Can't Have It Both Ways Re: Streamline the CG-NAT Re: EzIP Re: IPv4 address block

Any host connected to a reasonably well peered ISP (e.g. NOT Cogent) with IPv6 should be able to communicate with any other such host so long as the administrative policies on both sides permit it. I have no difficulty directly reaching a variety of IPv6 hosts from the /48 in my home.

Re: IPv6 Traffic Re: IPv6? Re: Where to Use 240/4 Re: 202401100645.AYC Re: IPv4 address block

> On Jan 14, 2024, at 19:50, Abraham Y. Chen wrote: > > Hi, Ryan: > > 1) " ... it accounts for 40% of the traffic at Google. ": > > Perhaps you were referring to the following? > > https://www.google.com/intl/en/ipv6/statistics.html > > 2)If so, your quotation is

Re: Stealthy Overlay Network Re: 202401100645.AYC Re: IPv4 address block

Apologies, I failed to realize that we were still discussing the absurdity of 240/4 and thought we were talking IPv6. All my comments below apply to v6 progress. 240/4 remains in the who knows?/who cares? Category as far as I’m concerned. OwenOn Jan 12, 2024, at 22:51, Owen DeLong wrote:Windows

Re: Stealthy Overlay Network Re: 202401100645.AYC Re: IPv4 address block

Windows, Mac, Linux, bad are all done. Juniper, MikroTik, even Cisco are done.Most consumer routers sold in the last 2-3 years are done. Not sure what “hardware vendor” would be necessary beyond those. There are probably some little used corner cases of routers, os, etc. but for the most part, we

Re: IPv6? Re: Where to Use 240/4 Re: 202401100645.AYC Re: IPv4 address block

Frankly, I care less. No matter how you use whatever IPv4 space you attempt to cajole into whatever new form of degraded service, the simple fact remains. IPv4 is a degraded technology that only continues to get worse over time. NAT was bad. CGNAT is even worse (and tragically does nothing to

Re: 202401100645.AYC Re: IPv4 address block

At the time this was being considered, ARIN, APNIC, and RIPE NCC were each burning approximately 6 /8s per year. 240/4 is 16x/8, so with an RIR burn rate of 18 /8s per year (not counting LACNIC and AFRINIC which each accounted for <1 per year IIRC), it seemed the 240/4 lasting a year was an

Re: 202401100645.AYC Re: IPv4 address block

ARIN has been gutting IPv4 free-pool based policy left and right lately… Other RIRs have not been quite as aggressive, but have done some similar things. This, if for no other reason, makes it a bad idea to suddenly restore RIR IPv4 free pools. Just my $0.02. I’ve got as little power in the

Re: Interesting Ali Express web server behavior...

require 1,789,132 hosts to > exhaust the space. > > - Christopher H. > > On Sun, 10 Dec 2023 at 18:45, Sabri Berisha <mailto:sa...@cluecentral.net>> wrote: >> - On Dec 9, 2023, at 9:55 PM, Owen DeLong via NANOG nanog@nanog.org >> <mailto:nanog@na

Re: Interesting Ali Express web server behavior...

Turn my wifi off and now it works flawlessly. > > Are you using your comcast connection? > > -Mike > >> On Dec 9, 2023, at 21:17, Stephane Bortzmeyer wrote: >> >> On Sat, Dec 09, 2023 at 09:55:31PM -0800, >> Owen DeLong via NANOG wrote >> a message o

Interesting Ali Express web server behavior...

Phone: +1-844-347-2457 OrgTechEmail: disa.columbus.ns.mbx.hostmaster-dod-...@mail.mil OrgTechRef:https://rdap.arin.net/registry/entity/MIL-HSTMST-ARIN Which seems in line with the announcement of that address I’m seeing: owen@delong-fmt2-mx-01> show route 33.3.37.57 inet.0: 947480

Re: Outside plant - prewire customer demarc preference

> On Nov 28, 2023, at 07:27, Brandon Martin wrote: > > On 11/27/23 18:52, owen--- via NANOG wrote: >> Why would 1” be significantly harder to get than 3/4”? Both in EMT and PVC, >> it’s readily available to the best of my knowledge. > > Most residential electrical contractors are going to

Re: ipv6 address management - documentation

Spreadsheets are terrible for IPAM regardless of address length, but I am curious to know why you think IPv6 would be particularly worse than IPv4 in such a scenario? Owen > On Nov 16, 2023, at 10:02, Aaron Gould wrote: > > For years I've used an MS Excel spreadsheet to manage my IPv4

Re: Am I the only one who thinks this is disconcerting?

It can’t be legacy space, there is no such thing in IPv6. Legacy status only refers to IPv4 blocks that were issued by the predecessors to the current registry system and have not yet been placed under RIR contract. Owen > On Nov 13, 2023, at 12:57, Matt Corallo wrote: > > I'd be very

Am I the only one who thinks this is disconcerting?

https://dnsviz.net/d/10.159.192.in-addr.arpa/dnssec/ Seems to report a bunch of errors in the DS records for 192.in-addr.arpa held in the in-addr.arpa zone. I figured I’d wait a few days and try again the first few times I encountered this, but it’s persisted for more than two weeks now.

Re: [EXTERNAL] Charter DNS servers returning malware filtered IP addresses

> On Oct 30, 2023, at 07:58, Livingood, Jason > wrote: > > On 10/27/23, 19:01, "NANOG on behalf of Owen DeLong wrote: > >> If it’s such a reasonable default, why don’t any of the public resolvers >> (e.g. 1.1.1.1, 8.8.8.8, 9.9.9.9, etc.) do so? >&g

Re: Charter DNS servers returning malware filtered IP addresses

>> DNS isn’t the right place to attack this, IMHO. > > Why not (apart from a purity argument), and where should it happen instead? > As others pointed out, network operators have a vested interest in protecting > their customers from becoming victims to malware. Takedowns of the hostile

Re: [EXTERNAL] Charter DNS servers returning malware filtered IP addresses

> On Oct 27, 2023, at 14:20, John Levine wrote: > > It appears that Bryan Fields said: >> -=-=-=-=-=- >> -=-=-=-=-=- >> On 10/27/23 7:49 AM, John Levine wrote: >>> But for obvious good reasons, >>> the vast majority of their customers don't >> >> I'd argue that as a service provider

Re: RPKI unknown for superprefixes of existing ROA ?

In fairness, however, there is a natural tendency for many of those PNIs to be built in locations in common with IXPs and often they start as IXP connections and with growth of traffic end up migrating to PNIs for further expansion. Owen > On Oct 24, 2023, at 18:15, Randy Bush wrote: > >>

Re: RPKI unknown for superprefixes of existing ROA ?

Yes, but we weren’t talking about an IXP here. We’re talking about an ISP. Believe it or not, Job, there are parts of the internet that exchange traffic and move packets that are not IXPs. Owen > On Oct 22, 2023, at 11:48, Job Snijders via NANOG wrote: > > On Sun, 22 Oct 2023 at 20:33, Tom

Re: RPKI unknown for superprefixes of existing ROA ?

and not actually announcing the > covering prefix as well isn't a good thing to do. > > On Sun, Oct 22, 2023 at 1:39 PM Owen DeLong <mailto:o...@delong.com>> wrote: >> Look again, Tom. This is an attack vector using a LESS specific route. The >> /22 gets discarded, but a

Re: RPKI unknown for superprefixes of existing ROA ?

Look again, Tom. This is an attack vector using a LESS specific route. The /22 gets discarded, but a covering /0-/21 would not. OwenOn Oct 22, 2023, at 10:06, Tom Beecher wrote:And is it your belief that this addresses the described attack vector?AFAICT, it does not.Quoting myself : WITH the

Re: RPKI unknown for superprefixes of existing ROA ?

Actually, Job, the 1.2.0/20 would be the longest prefix announced for 1.2.4/24 and 1.2.7/24 in this case. It’s a rather clever end-run. The /20 won’t match the more specific as0 ROAs, so it gets accepted. The /24s either aren’t advertised or they get discarded as invalid. Of course, if RIRs were

Re: Acceptance of RPKI unknown in ROV

I ask because there was discussion at the ARIN meeting and Kevin Blumburg made the suggestion that “in 2024, routes will not be accepted without ROAs”. I didn’t think this was likely, but as someone with resources for which I cannot create ROAs, it is a concern. So far, I haven’t really seen a

Acceptance of RPKI unknown in ROV

A question for network operators out there that implement ROV… Is anyone rejecting RPKI unknown routes at this time? I know that it’s popular to reject RPKI invalid (a ROA exists, but doesn’t match the route), but I’m wondering if anyone is currently or has any plans to start rejecting routes

Re: Amir Golestan sentenced to 5 years in prison for IP theft scheme

Sadly, probably not. AUP violations are a civil, not a criminal matter. Fraud, OTOH, is a criminal matter. In the US, at least, people don’t go to prison for civil matters. Owen > On Oct 17, 2023, at 19:19, Mel Beckman wrote: > > So ARIN DB spammers should get at least a year or two,

Re: Add communities on direct routes in Juniper

I believe you need to add the communities either on the import policy which pulls in the direct route or the export policy to the neighbor(s) you want to feed the communities to. Owen > On Oct 15, 2023, at 05:51, Jason R. Rokeach via NANOG wrote: > > Hi Stanislav, > I believe this is what

Re: ARIN whois contact abuse from ipv4depot aka Silicon Desert International Inc

> On Oct 12, 2023, at 10:59, Niels Bakker wrote: > > * Laura Smith [Thu 12 Oct 2023, 19:01 CEST]: >> I mean, most (all ?) of the registries still can't be bothered to validate >> the information the resource holders post to the database. Last time I >> asked, e.g. RIPE about it, they

Re: maximum ipv4 bgp prefix length of /24 ?

> On Oct 12, 2023, at 01:42, Willy Manga wrote: > > . > >> On 12/10/2023 10:00, Owen DeLong wrote: >> [...] >>>> However, IF YY is paying attention, and YY wants to advertise >>>> 2001:db8::/32 as well as allow 2001:db8:8000::/36 and 2001

Re: maximum ipv4 bgp prefix length of /24 ?

> On Oct 11, 2023, at 19:18, Willy Manga wrote: > > . > > On 11/10/2023 03:52, Delong.com wrote: >> [...] >>> RPKI only asserts that a specific ASN must originate a prefix. It does >>> nothing to validate the authenticity of the origination. >> Nope… It ALSO asserts (or can assert) an

Re: maximum ipv4 bgp prefix length of /24 ?

Ratio of FIB to RIB is only part of the equation. IPv6 is NOT under the disaggregation pressure that IPv4 is under because there is no pressure (other than perhaps scarcity mentality from those that don’t properly understand IPv6) to dense-pack IPv6 assignments or undersize IPv6 allocations.

Re: maximum ipv4 bgp prefix length of /24 ?

f operators push > everything out to /48 "to counter hijacks" or other misguided reasons? > > On Wed, Oct 4, 2023 at 8:14 AM Owen DeLong via NANOG <mailto:nanog@nanog.org>> wrote: >> If you maximally disaggregate to /24, you end up with about 12M fib entries.

Re: maximum ipv4 bgp prefix length of /24 ?

> On Oct 4, 2023, at 03:18, Mark Tinka wrote: > >  > >> On 10/4/23 09:27, Elmar K. Bins wrote: >> >> >> Justin, >> >> I'm not sure you're not confusing scope here. >> >> Everybody and their sister accept smaller blocks from their customers; we're >> all talking about the DFZ here, not

Re: maximum ipv4 bgp prefix length of /24 ?

If you maximally disaggregate to /24, you end up with about 12M fib entries. At /25 this doubles and you double it again for every bit you move right. At /24, we are on borrowed time without walking right. Also, the CPU in most routers won’t handle the churn of a 10M prefix RIB. Owen > On

Re: ARIN email address (was cogent spamming directly from ARIN records?)

Problem with that theory is the ratio of collateral damage to pain inflicted. Filter or deeper cogent and they don’t feel anything themselves. Their customers _might_ miss being able to reach your customers (or you), but then it is Cogent’s customers that feel the pain the most and Cogent to a

Re: ARIN email address (was cogent spamming directly from ARIN records?)

I was one of the main people behind their suspension from ARIN whois for 6 months. They have not spammed me since. They’re probably afraid of another cake. Owen > On Oct 3, 2023, at 18:18, Mike Lyon wrote: > > Give it time :) > > -Mike > >> On Oct 3, 2023, at 18:0

Re: ARIN email address (was cogent spamming directly from ARIN records?)

But I seem to have finally gotten Cogent trained not to spam this one, so I think I’ll leave it as is. YMMV Owen > On Oct 3, 2023, at 08:52, Bryan Fields wrote: > > On 10/2/23 11:28 AM, Mel Beckman wrote: >> I believe they got the contact information from ARIN > > I'd suggest everyone use

Re: MX204 tunnel services BW

You can configure tunnel bandwidth everywhere, but you can’t configure a given tunnel everywhere, you have to assign it to a particular FPC/PIC/0. For example, with: set chassis fps 2 pic 3 tunnel-services bandwidth 10g You need to create gr-2/3/0 interfaces for tunnels to use that PFE. You can

Re: MX204 tunnel services BW

> On Oct 2, 2023, at 20:18, behrnsj...@yahoo.com wrote: > > > > -Original Message- > From: Delong.com > Sent: Monday, October 2, 2023 5:47 PM > To: behrnsj...@yahoo.com > Cc: nanog@nanog.org > Subject: Re: MX204 tunnel services BW > >> “Tunnel gets whatever bandwidth is left after

Re: maximum ipv4 bgp prefix length of /24 ?

Isn’t that pretty much what Geoff Huston has done with the weekly reports William quoted earlier in this thread?Sure, that’s from a limited set of perspectives, but it probably represents the minimum achievable compression in most circumstances. OwenOn Oct 2, 2023, at 06:41, Joshua Miller

Re: maximum ipv4 bgp prefix length of /24 ?

> On Oct 2, 2023, at 01:18, Nick Hilliard wrote: > > William Herrin wrote on 02/10/2023 08:56: >> All it means is that you have to keep an eye on your FIB >> size as well, since it's no longer the same as your RIB size. > > the point Jacob is making is is that when using FIB compression,

Re: maximum ipv4 bgp prefix length of /24 ?

First, no, a transient where all route disaggregating disappears from the global table is extraordinarily unlikely. Second, as I understand it, each update cycle results in rebuilding the fib from scratch rather than figuring out how to splice and dice it, so the computation required to cope

Re: maximum ipv4 bgp prefix length of /24 ?

Not sure why you think FIB compression is a risk or will be a mess. It’s a pretty straightforward task. Owen > On Sep 30, 2023, at 00:03, Mark Tinka wrote: > >  > >> On 9/30/23 01:36, William Herrin wrote: >> >> >> If I were designing the product, I'd size the SRAM with that in mind.

Re: maximum ipv4 bgp prefix length of /24 ?

> On Sep 29, 2023, at 15:14, William Herrin wrote: > > On Fri, Sep 29, 2023 at 3:11 PM Owen DeLong wrote: >> You continue to assume that there is a fast SRAM cache. I’m not sure >> that is true. I think that all of the FIB RAM on the line cards is fast SRAM >>

Re: maximum ipv4 bgp prefix length of /24 ?

> On Sep 29, 2023, at 14:48, William Herrin wrote: > > On Fri, Sep 29, 2023 at 2:13 PM Tom Beecher wrote: >>> My understanding of Juniper's approach to the problem is that instead >>> of employing TCAMs for next-hop lookup, they use general purpose CPUs >>> operating on a radix tree, exactly

Re: maximum ipv4 bgp prefix length of /24 ?

ter > the fact > > did anyone eat the cake? was it tasty? > > > Le 29 septembre 2023 20:55:00 UTC, Owen DeLong via NANOG a > écrit : >> I have known Mike for many years. I have my disagreements with him and my >> criticisms of him. >> >> Ho

Re: maximum ipv4 bgp prefix length of /24 ?

s/DMS/DFZ/ — Not sure how autocrrect did that without me noticing, apologies. > On Sep 29, 2023, at 14:11, Owen DeLong via NANOG wrote: > > /32s are perfectly valid in the DMS, but there is currently an IETF limit of > ~500M of them (the other 3.5B are not yet released to th

Re: maximum ipv4 bgp prefix length of /24 ?

> On Sep 29, 2023, at 13:43, William Herrin wrote: > > On Thu, Sep 28, 2023 at 10:29 PM Saku Ytti wrote: >> On Fri, 29 Sept 2023 at 08:24, William Herrin wrote: >>> Maybe. That's where my comment about CPU cache starvation comes into >>> play. I haven't delved into the Juniper line cards

Re: maximum ipv4 bgp prefix length of /24 ?

/32s are perfectly valid in the DMS, but there is currently an IETF limit of ~500M of them (the other 3.5B are not yet released to the RIRs, only 2000::/3). Owen > On Sep 29, 2023, at 12:54, Collider wrote: > > This thread is utter amateur hour. I too would rather /32s be valid in the > DFZ

Re: maximum ipv4 bgp prefix length of /24 ?

t; Hence, /48 proposition may become 20x worse for scale than proposed >> initially in this thread. >> Eduard >> From: NANOG [mailto:nanog-bounces+vasilenko.eduard=huawei@nanog.org] On >> Behalf Of Owen DeLong via NANOG >> Sent: Friday, September 29, 2023 7:11 AM >>

Re: maximum ipv4 bgp prefix length of /24 ?

lity to handle a 10M route table is known technology at this point, and its just a matter of the cost of the line cards. Owen > Eduard > From: NANOG [mailto:nanog-bounces+vasilenko.eduard=huawei@nanog.org] On > Behalf Of Owen DeLong via NANOG > Sent: Friday, September 29, 2023 7:11 AM &

Re: maximum ipv4 bgp prefix length of /24 ?

> On Sep 28, 2023, at 22:29, Saku Ytti wrote: > > On Fri, 29 Sept 2023 at 08:24, William Herrin wrote: > >> Maybe. That's where my comment about CPU cache starvation comes into >> play. I haven't delved into the Juniper line cards recently so I could >> easily be wrong, but if the number

Re: maximum ipv4 bgp prefix length of /24 ?

> > In principle, a company could make a business out of announcing a > large block from a bunch of peering points and then tunneling (vpn) > parts of it back to customers with sub-/24 assignments. With a broad > enough selection of peering points, the routing would not be too > inefficient. And

Re: maximum ipv4 bgp prefix length of /24 ?

et. > Yes, but let’s focus that investment where it makes sense. IPv4 isn’t that. Owen > > 29.09.2023 07:11 tarihinde Owen DeLong yazdı: >> Wouldn’t /48s be a better solution to this need? >> >> Owen >> >> >>> On Sep 28, 2023, at 14:25, VOLKAN SALİH

Re: maximum ipv4 bgp prefix length of /24 ?

CIDR and aggregation in the early 1990s was developed in response to AGS+ routers falling over under the strain of the global size back then. Since then, IPv4 has been a progressive loosing proposition and only gets worse every year. This proposal could certainly accelerate the rate at which it

Re: maximum ipv4 bgp prefix length of /24 ?

Wouldn’t /48s be a better solution to this need? Owen > On Sep 28, 2023, at 14:25, VOLKAN SALİH wrote: > > hello, > > I believe, ISPs should also allow ipv4 prefixes with length between /25-/27 > instead of limiting maximum length to /24.. > > I also believe that RIRs and LIRs should

Re: AFRINIC placed in receivership

> On Sep 15, 2023, at 06:30, Noah wrote: > > > > On Fri, 15 Sept 2023, 15:53 John Curran, > wrote: >> Noah - >> >> Indeed, that was a less than ideal situation – but I will note that the >> technical advisor was sent away by the Receiver once the Receiver was >>

Re: JunOS config yacc grammar?

FWIW, I find the config archival on-commit to be a very useful feature. I use it with SCP. Sadly, neither J nor C support doing this with an SSH private key on the router, you have to use a password. J at least encrypts the password if you do it right (…”URL” password “plain-text”). Cisco does

Re: IP range for lease

> On Jul 11, 2023, at 09:52, John Curran wrote: > > > >> On Jul 11, 2023, at 12:40 PM, Owen DeLong wrote: >> >> >>> On Jul 11, 2023, at 09:04, John Curran wrote: >>> >>> ... >>> >>> Of course, further policy

Re: IP range for lease

> On Jul 11, 2023, at 10:02, William Herrin wrote: > > On Tue, Jul 11, 2023 at 8:47 AM Owen DeLong via NANOG wrote: >>> – Leasing of IP address blocks independent of connectivity is not >>> explicitly recognized in ARIN number resource policy (i.e. there is no &

Re: IP range for lease

> On Jul 11, 2023, at 09:04, John Curran wrote: > > >> On Jul 11, 2023, at 11:47 AM, Owen DeLong wrote: >> >> Actually, I couldn’t find anything in the NRPM which leads me to believe >> that there is any distinction in the documentation requirements

Re: IP range for lease

> On Jul 10, 2023, at 10:22, John Curran wrote: > >> On Jul 5, 2023, at 10:06 PM, Owen DeLong via NANOG wrote: >> ... >> Opinions regarding leasing vary throughout the industry. In my opinion, >> since the shift to provider assigned addresses during the CID

Re: IP range for lease

Karin,Opinions regarding leasing vary throughout the industry. In my opinion, since the shift to provider assigned addresses during the CIDR efforts in the mid 1990s, the majority of addresses have been leased in one form or another. The only thing novel here is the leasing of addresses

Re: Northern Virginia has had enough with data centers

> On Jun 23, 2023, at 18:04, Michael Thomas wrote: > >  >> On 6/23/23 4:01 PM, Delong.com via NANOG wrote: >> The electric grid complaints are about the demand on the grid making the >> entire region less stable and proposed construction of new high-voltage >> tower corridors for data

Re: FCC Chair Rosenworcel Proposes to Investigate Impact of Data Caps

> On Jun 16, 2023, at 13:16, Michael Thomas wrote: > > > On 6/16/23 1:09 PM, Mark Tinka wrote: >> >> >> On 6/16/23 21:19, Josh Luthman wrote: >>> Mark, >>> >>> In my world I constantly see people with 0 fixed internet options. Many of >>> these locations do not even have mobile

  1   2   3   4   5   6   7   8   9   10   >