Re: Routed optical networks

[joel]

> On May 13, 2023, at 4:03 AM, Mark Tinka  wrote:
> 
> 
> 
> On 5/12/23 22:14, Mike Hammett wrote:
> 
>> "I remember 10y ago every presentation started from the claim that 100B of 
>> IoT would drive XXX traffic. It did not happen"
>> 
>> Often the type of people making these kinds of predictions that a tire 
>> pressure sensor generates 20 gigabytes of traffic a day.
> 
> I like growing old... your BS detector becomes so slick, you know to ignore 
> certain links, conferences, speakers, topics, meetings, slideware, e-mails, 
> colleagues and announcements without fear of actually missing out on trends, 
> because you know that in the end it will lead to nowhere real :-).


As a security guy.  The end of year “prediction for next year” papers are 
wearing me out.  As an author of several of the big ones, I’m over it too

Re: Office 365 Calendar support for macOS Calendar App (Mark Tinka)

[joel]

I had to do that awhile back as well when I was still on O365.  

> On May 23, 2023, at 10:49 AM, Kovich Greg via NANOG  wrote:
> 
> Long time Mac user and I found the same problem when I updated my computer 
> and laptop to the latest OS - Ventura.
> 
> While my phone still was able to see and manage events and invitations, the 
> Mac was blank.
> 
> Long story short - I removed the 0365 account and then restored it (userid / 
> password) and after a 30 minutes or so, my calendar events all repopulated 
> and I continue as before.
> 
> IDKWhy I had to go through this extra step, but everything is working as 
> expected now.
> Note: Mac Mail never had a problem with the transition to Ventura, only 
> Calendar.
> 
> Happy to help you Mark if you direct email me.
> 
> 
>> On May 23, 2023, at 7:00 AM, nanog-requ...@nanog.org wrote:
>> 
>> 
>> ** External email - Please consider with caution **
>> 
>> 
>> Send NANOG mailing list submissions to
>>   nanog@nanog.org
>> 
>> To subscribe or unsubscribe via the World Wide Web, visit
>>   https://mailman.nanog.org/mailman/listinfo/nanog
>> or, via email, send a message with subject or body 'help' to
>>   nanog-requ...@nanog.org
>> 
>> You can reach the person managing the list at
>>   nanog-ow...@nanog.org
>> 
>> When replying, please edit your Subject line so it is more specific
>> than "Re: Contents of NANOG digest..."
>> 
>> 
>> Today's Topics:
>> 
>>  1. Office 365 Calendar support for macOS Calendar App (Mark Tinka)
>> 
>> 
>> --
>> 
>> Message: 1
>> Date: Tue, 23 May 2023 13:42:56 +0200
>> From: Mark Tinka 
>> To: nanog@nanog.org
>> Subject: Office 365 Calendar support for macOS Calendar App
>> Message-ID: <818b9f7a-6e5d-d334-0ef8-50b3006eb9f4@tinka.africa>
>> Content-Type: text/plain; charset="utf-8"; Format="flowed"
>> 
>> Hi all.
>> 
>> It may just be me, or it may not, but figured I'd ask... it seems like
>> Microsoft's 365 cloud service does not support the native Calendar app
>> on macOS.
>> 
>> Oddly, it works without issue for the native Calendar app in iOS.
>> 
>> A bit of Googl'ing and speaking with some 365 customer admins. suggests
>> that "Microsoft do not support Apple products in 365", which sounds most
>> odd to me, as I know a number of Microsoft apps do run on macOS and iOS.
>> 
>> Am I off the mark, are others seeing the same, is this a known issue, is
>> it a non-issue?
>> 
>> Mark.
>> -- next part --
>> An HTML attachment was scrubbed...
>> URL: 
>> 
>> 
>> End of NANOG Digest, Vol 184, Issue 19
>> **
> 

Re: U.S. test of national alerts on Oct. 4 at 2:20pm EDT (1820 UTC)

[joel]

> On Oct 4, 2023, at 3:27 PM, Matthew Petach  wrote:
> 
> On Wed, Oct 4, 2023 at 12:25 PM Sean Donelan  > wrote:
>> 
>> Emergency alerts are built into all android, ios and other mobile phones 
>> sold in almost every country during the last 5 years.  GSM standards are 
>> global.  The U.S. finally changed "presidential alert" to "national alert" 
>> recently. 
> 
> Well, today's alert still showed up as "Presidential Alert", so I guess the 
> US hasn't quite finished changing over yet.  ^_^;
> (Samsung Galaxy phone)

Since only the President or the Director of FEMA can issue it…. It’s not too 
terrible.

Re: AWS WAF list

[joel]

There are other WAF lists available on AWS besides their native one.  Ones that 
have support.

> On Feb 20, 2024, at 16:18, George Herbert  wrote:
> 
> This is terrible advice, but you might need another netblock for the 
> eyeballs.  Possibly a small one with enterprise NAT, but something outside 
> the AWS list ranges...
> 
> 
> -George
> 
> On Mon, Feb 19, 2024 at 7:35 PM Justin H.  > wrote:
>> That matches my experience with these types of problems in the past.  
>> Especially when the end-users don't have a process for white-listing.  
>> 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 hope this can be resolved 
>> without account gymnastics. :)
>> 
>> Justin H.
>> 
>> Owen DeLong wrote:
>> > 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 no accountability or process for 
>> > redress of errors whatsoever. The impacted party isn’t a customer of the 
>> > WAF publisher, so they cant get any traction there. The WAF subscriber 
>> > blindly applies the WAF and it’s virtually impossible to track down anyone 
>> > there who even knows that they subscribe to such a thing, let alone get 
>> > them to take useful action.
>> >
>> > Best of luck.  The only thing I saw that worked while I was at Akamai was 
>> > a few entities subscribed to the WAF service and then complained about 
>> > getting blocked from their own web sites. Since they were then Akamai WAF 
>> > customers, they could get Akamai to take action.
>> >
>> > Crazy.
>> >
>> > Owen
>> >
>> >
>> >> On Feb 16, 2024, at 09:19, Justin H. > >> > wrote:
>> >>
>> >> Justin H. wrote:
>> >>> Hello,
>> >>>
>> >>> We found out recently that we are on the HostingProviderIPList (found 
>> >>> here 
>> >>> https://docs.aws.amazon.com/waf/latest/developerguide/aws-managed-rule-groups-ip-rep.html)
>> >>>  at AWS and it's affecting our customers' access to various websites.  
>> >>> We are a datacenter, and a hosting provider, but we have plenty of 
>> >>> enterprise customers with eyeballs.
>> >>>
>> >>> We're finding it difficult to find a technical contact that we can reach 
>> >>> since we're not an AWS customer.  Does anyone have a contact or advice 
>> >>> on a solution?
>> >> Sadly we're not getting any traction from standard AWS support, and end 
>> >> users of the WAF list like Reddit and Eventbrite are refusing to 
>> >> whitelist anyone.  Does anyone have any AWS contacts that might be able 
>> >> to assist?  Our enterprise customers are becoming more and more impacted.
>> >>
>> >> Justin H.
>> 
> 
> 
> --
> -george william herbert
> george.herb...@gmail.com 

Re: Any info on AT&T Wireless Outage?

[joel]

I read it as “someone pushed an ACL that wasn’t properly reviewed and it really 
screwed things up."

> On Feb 27, 2024, at 21:41, Mark Seiden  wrote:
> 
> aside from the official pablum that was released about an “incorrect process 
> used”
> (which says exactly nothing) does anyone actually know anything accurate and 
> more specific about the root cause?
> 
> (and why it took 11 hours to recover?)
> 
>> On Feb 22, 2024, at 11:15 AM, John Councilman  wrote:
>> 
>> From what I've read, they lost their database of SIM cards.  I could be 
>> wrong of course.
>> 
>> On Thu, Feb 22, 2024 at 2:02 PM Dorn Hetzel > > wrote:
>>> As widespread as it seemed to be, it feels like it would be quite a trick 
>>> if it were a single piece of hardware.  Firmware load that ended badly, I 
>>> wonder?
>>> 
>>> 
>>> On Thu, Feb 22, 2024 at 1:51 PM Leato, Gary via NANOG >> > wrote:
 Do you have the ability to expand on this at all? Do you mean a hardware 
 failure of some kind IE router, optitcs, etc?
 
  
 
 From: NANOG >>> > On Behalf Of R. Leigh Hennig
 Sent: Thursday, February 22, 2024 8:17 AM
 To: Robert DeVita mailto:radev...@mejeticks.com>>
 Cc: nanog@nanog.org 
 Subject: Re: Any info on AT&T Wireless Outage?
 
  
 
 Word around the campfire is that it’s a Cisco issue.
 
 
 
 
 On Feb 22, 2024, at 8:03 AM, Robert DeVita >>> > wrote:
 
  
 
 Reports have it starting at 4:30 a.m.. SOS on all phones..
 
  
 
  
 
  
 
 
 
 Robert DeVita
 
 CEO and Founder
 
 t: (469) 581-2160
  | 
 
 m: (469) 441-8864 
 e: radev...@mejeticks.com   
  | 
 
 w: mejeticks.com 
 a: 
 
 2323 N Akard Street
 
 , 
 
 Dallas
 
 , 
 
 75201
 
   
     
    
  
  
 
 
 
 The risk of trading futures and options can be substantial. All 
 information, publications, and material used and distributed by Advance 
 Trading Inc. shall be construed as a solicitation. ATI does not maintain 
 an independent research department as defined in CFTC Regulation 1.71. 
 Information obtained from third-party sources is believed to be reliable, 
 but its accuracy is not guaranteed by Advance Trading Inc. Past 
 performance is not necessarily indicative of future results.
> 

Re: Best TAC Services from Equipment Vendors

[joel]

You sir, not wrong.

> On Mar 11, 2024, at 10:04, michael brooks - ESC  
> wrote:
> 
> 
> >It may be a pain in the butt to get Cisco equipment, but their TAC is 
> >sublime.  If something is critical enough, and you push hard enough, Cisco 
> >will move heaven and earth to solve your issue.
> 
> But is this not the problem itself?
> 
> Strap in for an "I remember when" ...
> Once upon a time, I could call (specifically) Cisco TAC, knowing, without any 
> doubt, that my quality problem resolution was inbound, no questions asked. 
> That came to a crashing halt about 15 years ago when a TAC engineer wanted to 
> bounce our Voice VLAN SVI in the middle of an airport production day. I about 
> turned over my desk trying to wrest the remote control session back from him 
> before he hit enter on the shut. Since then, I have had to go through a not 
> insignificant evaluation period of TAC engineers before I let them take 
> control of a remote session, and it is now simply pure instinct to log SSH 
> sessions.
> 
> Fast forward and my user base is now ~45k people, not massive by any stretch, 
> but certainly not a small org, and we tend to buy Premium/Platinum support on 
> all of our critical applications. I truly do have to "push hard" and long to 
> get the attention of our support teams to get a seemingly simple problem 
> supported and solved. Our support is still in the dumper. Take, for instance, 
> a recent case with our replication/DR vendor. Our DR environment has been 
> offline for ~3 months, does that not scream "critical?" And yet, we are still 
> having engineers jump on a call to collect  the same data that the last 
> engineer jumped on a call to collect. One of our engineers, as has been 
> not-so-subtly alluded to, resorted to a screamfest to get the attention of 
> TAC, and not surprisingly that dressing-down got upper levels involved.
> 
> For good measure, major networking vendor possibly mentioned earlier spent 9 
> months, at the developer level, troubleshooting a multicast issue which 
> ultimately turned out to be PIM not configured on all interfaces in the path. 
> Yes, I felt like an idiot for not already checking that, but should not have 
> the first engineer on the phone asked this?
> 
> Admittedly, we are going through a rough patch in terms of support, but it is 
> not out of line with the past decade's experiences.
> 
> 
> michael brooks
> 
> On Thu, Mar 7, 2024 at 12:47 PM Joel Esler  <mailto:j...@joelesler.net>> wrote:
>> It may be a pain in the butt to get Cisco equipment, but their TAC is 
>> sublime.  If something is critical enough, and you push hard enough, Cisco 
>> will move heaven and earth to solve your issue.  
>> — 
>> Sent from my iPhone
>> 
>>> On Mar 6, 2024, at 13:42, Pascal Masha >> <mailto:pascalma...@gmail.com>> wrote:
>>> 
>>> 
>>> For us this has been the experience to a point where 100s of nodes( from 
>>> vendor x) had to be swapped out because no one had the patience anymore…
>>> 
>>> On Wed, 6 Mar 2024 at 21:29, >> <mailto:sro...@ronan-online.com>> wrote:
>>>> Interesting, this has never been my experience even with Cisco or Juniper, 
>>>> have always been able to escalate quickly to engineering. I wonder if it 
>>>> was related to the size of my accounts.
>>>> 
>>>> Shane
>>>> 
>>>> > On Mar 6, 2024, at 1:27 PM, Pascal Masha >>> > <mailto:pascalma...@gmail.com>> wrote:
>>>> > 
>>>> > Thought about it but so far I believe companies from China provide 
>>>> > better and fast TAC responses to their customers than the likes of Cisco 
>>>> > and perhaps that’s why some companies(where there are no 
>>>> > restrictions)prefer them for critical services. 
>>>> > 
>>>> > For a short period in TAC call you can have over 10 R&D engineers and 
>>>> > solutions provided in a matter of hours even if it involves software 
>>>> > changes.. while these other companies even before you get in a call with 
>>>> > a TAC engineer it’s hours and when they join you hear something like “my 
>>>> > shift ended 15 minutes ago, hold let me look for another engineer”. WHY? 
>>>> > Thoughts
> 
> This is a staff email account managed by Adams 12 Five Star Schools.  This 
> email and any files transmitted with it are confidential and intended solely 
> for the use of the individual or entity to whom they are addressed. If you 
> have received this email in error please notify the sender.

Re: Best TAC Services from Equipment Vendors

[joel]

> On Mar 11, 2024, at 12:54, michael brooks - ESC  
> wrote:
> 
>> It may be a pain in the butt to get Cisco equipment, but their TAC is 
>> sublime.  If something is critical enough, and you push hard enough, Cisco 
>> will move heaven and earth to solve your issue.  
> 
> >This was an amazing laugh on a Monday morning. Thanks! 
> 
> O crap, did I miss the sarcasm?
> 

You did not.  I think you have to know the magic incantation to get Cisco TAC 
to escalate to the magic level.

Re: etiquette for replying to daily digests

[joel]

> On Nov 8, 2024, at 15:58, William Herrin  wrote:
> 
>> On Nov 8, 2024, at 14:14, Alex Buie > > wrote:
>> I (and I'm sure many of you) subscribe to daily digests from NANOG to keep 
>> things concentrated. However, there are sometimes messages in the digest I'd 
>> like to reply to, and I don't want to be that guy who just replies to the 
>> digest and opens an ugly new thread.
> 
> On Fri, Nov 8, 2024 at 11:38 AM  > wrote:
>> Generally speaking, you want to trim the digest to the relevant posts, 
>> bottom posting your reponse (if you’re interested in nitpicking). This 
>> practice was prevalent until Microsoft Outlook introduced the top post 
>> culture. Let’s not go down that rabbit hole.
>> 
>> 
>> Additionally, editing the subject line to include what you’re responding 
>> about can be helpful.
> 
> This, and change your subscription to individual messages for the
> duration. You need the message-id and related headers to create a
> properly threaded reply and you don't have them. Few will notice and
> none will harangue you for starting a new thread with your first reply
> but if you do it with every reply it gets really old really fast.

See Bill, now you’re speaking my old school bottom posting, mutt using geek 
language.

Re: etiquette for replying to daily digests

[joel]

Generally speaking, you want to trim the digest to the relevant posts, bottom 
posting your reponse (if you’re interested in nitpicking). This practice was 
prevalent until Microsoft Outlook introduced the top post culture. Let’s not go 
down that rabbit hole.

Additionally, editing the subject line to include what you’re responding about 
can be helpful.



> On Nov 8, 2024, at 14:14, Alex Buie  wrote:
> 
> Hi all,
> 
> I (and I'm sure many of you) subscribe to daily digests from NANOG to keep 
> things concentrated. However, there are sometimes messages in the digest I'd 
> like to reply to, and I don't want to be that guy who just replies to the 
> digest and opens an ugly new thread.
> 
> Curious what workflow/process any of you use to do so, and what the 
> best/netizen-polite way is to end up with a reply that's appropriately 
> threaded. Do I just need to mirror the subject line?
> 
> 
> Alex Buie
> Senior Cloud Operations Engineer
> 
> 450 Century Pkwy # 100 Allen, TX 75013 
> 
> D: 469-884-0225 | www.cytracom.com 

Re: A plea to ignore abuse reports from "watchdogcyberdefense.com"

[joel]

Aww BlackICE.  I was talking to Robert not too long ago about this.  A simpler 
time.

> On Nov 6, 2024, at 11:01, Warren Kumari  wrote:
> 
> So, who here remembers "BlackICE Defender"?
> 
> It was MS Windows software which would watch for and protect against 
> "attacks", draw pretty charts and graphs, and also "report the attack to the 
> attackers ISP".
> 
> They did improve slightly over time, but things which it initially viewed as 
> an attack were nefarious things like "you sent me an ICMP echo-request"...
> 
> W
> 
> 
> On Tue, Nov 5 2024 at 10:21 PM, Mike Lewinski  > wrote:
>> We got two of these yesterday for addresses that are not ours. One was sort 
>> of adjacent... and seemed plausibly fat-fingered.
>> 
>> 204.144.161.0 ≠ 204.144.151.0
>> 
>> We will definitely filter out anything further. Thanks for the heads-up.
>> 

Re: Soooo..... Netflix

[joel]

Also, how far have we come that 65 MILLION streams were active at the same time 
and we’re like “omg, so bad!”

5 years ago, never possible.

That being said.  I watched it on my iPad with no problems whatsoever.  Not 
even one hiccup.  Meanwhile I had X open in a side by side and I saw people 
complaining about it.

> On Nov 18, 2024, at 09:08, Cooke, David via NANOG  wrote:
> 
> This email may contain proprietary information of BAE Systems and/or third 
> parties.
>  
> My experience over a home internet fiber connection wasn’t great (like 
> everyone else’s) but my son was watching it over his mobile device without 
> any issues.
>  
> From: NANOG  > On Behalf 
> Of Tom Beecher
> Sent: Monday, November 18, 2024 12:23 AM
> To: Mike Hammett mailto:na...@ics-il.net>>
> Cc: NANOG mailto:nanog@nanog.org>>
> Subject: Re: S. Netflix
>  
> 
> PHISHING ALERT
> This email has been sent from an account outside of the BAE Systems network.
> 
> Be aware that this could be a phishing attempt. For more guidance, search 
> "phishing email" on Connect. If you think this is a phishing email report it 
> using the "PhishMe" button on Outlook. 
>  
>  
> What were your educated observations, preferably with supporting data?
>  
> If it was capacity issues, they learned a hard lesson that you should have 
> other CDNs available to shed traffic over to if yours hits a problem that 
> can't be quickly solved in real time. 
>  
> If it was server/software/livestream technical , then /shrug. Fix those.  :) 
>  
>  
> On Sun, Nov 17, 2024 at 1:28 PM Mike Hammett  > wrote:
> Armchair quarterbacking...
> 
> Discussions I've seen from operators on Facebook shows some that had PNIs 
> that worked just fine, while others with PNIs and cache boxes didn't fare so 
> well. Some with just cache boxes were fine, while others were not.
> 
> What were your educated observations, preferably with supporting data?
> 
> Did we have a problem with congestion where the cache boxes phones home to, 
> and this they just fell over?
> 
> AWS used to be the data source of last resort. Did anyone notice congestion 
> going from AWS to cache boxes?
> 
> 
> 
> 
> -Mike HammettIntelligent Computing SolutionsMidwest Internet ExchangeThe 
> Brothers WISP
> BAE Systems will collect and process information about you that may be 
> subject to data protection laws. For more information about how we use and 
> disclose your personal information, how we protect your information, our 
> legal basis to use your information, your rights and who you can contact, 
> please refer to the relevant sections of our Privacy note at 
> www.baesystems.com/en/cybersecurity/privacy 
> 
> 
> Please consider the environment before printing this email. This message 
> should be regarded as confidential. If you have received this email in error 
> please notify the sender and destroy it immediately. Statements of intent 
> shall only become binding when confirmed in hard copy by an authorised 
> signatory. The contents of this email may relate to dealings with other 
> companies under the control of BAE Systems PLC, details of which can be found 
> at http://www.baesystems.com/Businesses/index.htm.
> 

Re: Chairman of Senate Intelligence Committee calls salt typhoon "worst telecom hack in our nation's history"

[joel]

> On Nov 26, 2024, at 12:26, Christopher Morrow  wrote:
> 
> On Tue, Nov 26, 2024 at 3:57 AM Eric Kuhnke  wrote:
>> 
>> Re: compromise of lawful intercept / CALEA related features:
> 
> Uhm, which of course 'no one saw coming'...
> 
>> 
>> https://archive.is/jZt59
>> 
>> Original URL: 
>> https://www.washingtonpost.com/national-security/2024/11/21/salt-typhoon-china-hack-telecom/
>> 
>> The hackers, part of a group dubbed Salt Typhoon, have been able to listen 
>> in on audio calls in real time and have in some cases moved from one telecom 
>> network to another, exploiting relationships of “trust,” said Sen. Mark R. 
>> Warner (D-Virginia), chairman of the Senate Intelligence Committee and a 
>> former telecom venture capitalist. Warner added that intruders are still in 
>> the networks.
> 
> also, this very same thing played out a tad smaller (maybe? no one
> really fessed up) in ~2002-3?
> admittedly the person that MAY NOT have just been a patsy for some
> other larger thing (nation-state-actor) but.. we probably won't know.

How could they have possibly hacked an intentional backdoor!?  No.  Get out.

Re: New home builders without wires

[joel]

If I ever build the next house, I’ll ensure that Ethernet is installed just as 
extensively as electric wiring.

> On Dec 5, 2024, at 10:23, Tom Deligiannis  wrote:
> 
> NDI or similar? I don't follow. Cable TV, Cable Internet and sat TV aren't 
> distributed (to homes) using NDI, they use coax.
> 
> On Thu, Dec 5, 2024 at 1:37 AM Joly MacFie  > wrote:
>> 
>> > How else would you distribute cable and sat tv?
>> NDI or similar
>> 
>> 
>> 
>> On Wed, Dec 4, 2024 at 1:15 PM Tom Deligiannis > > wrote:
>>> How else would you distribute cable and sat tv? I would never buy a home or 
>>> build a home if there weren't hard wired services to the home. The last 
>>> thing I want to do is run all media streaming and internet surfing through 
>>> a wireless 5g connection.
>>> 
>>> On Wed, Dec 4, 2024 at 8:13 AM Joly MacFie >> > wrote:
 Excuse my ignorance, but why, in this day and age, coax?
 
 Joly
 
 On Wed, Dec 4, 2024 at 7:14 AM Justin Streiner >>> > wrote:
> When we built our new house 3 years ago, I had the electrician pull Cat7 
> and coax to most of the rooms in the house, since it would be way easier 
> to do it before the drywall went up.  They initially resisted because 
> they had never worked with Cat7 before.  I struck a deal with them where 
> I bought the Cat7, they pulled it, and I terminated and tested it, and 
> they were OK with that.  Everything lands in the basement at our telco 
> demarc sits, and everything has been working perfectly since then.  The 
> rack where everything lands is also tied to the house ground.  I might 
> consider 5G as a backup to our terrestrial fiber option, but haven't gone 
> there yet.
> 
> The local electric utility tests our UPSs for free roughly once a month ;)
> 
> Thank you
> jms
> 
> On Tue, Dec 3, 2024 at 11:53 AM Sean Donelan  > wrote:
>> As some may remember from earlier this year, my friend was buying a new 
>> "semi-custom" home.  "Semi-custom" is a marketing term, meaning you get 
>> to 
>> choose (pay more) pre-determined builder options. It is not custom 
>> designed.
>> 
>> The home builder was not installing any wired broadband utilities in the 
>> new neighborhood.  No cable coax, no telephone DSL, no fiber optic. The 
>> only option was wireless, with a special deal with a specific 5G 
>> wireless 
>> cellular provider.
>> 
>> Originally, the builder's sales agent (i.e. the people working in the 
>> model home selling houses) said new homes didn't need (and would not 
>> have) 
>> a wired "demarc" location and no ethernet or coax outlets. Not my house, 
>> but I was surprised when I heard that. I like wired connections when 
>> possible for any fixed devices, and WiFi only for mobile devices.
>> 
>> I visited his new house over the Thanksgiving Holiday.
>> 
>> The sales agent was partially wrong and partially correct. Never believe 
>> the sales agent spiel.
>> 
>> The built house came with exactly FOUR wired ethernet outlets in the 
>> living room and each bedroom/office (x2 Cat6 jacks each outlet). But no 
>> wired DEMARC, no coax outlets, and no wired broadband utilities in the 
>> neighhood. The wired ethernet jacks were needed because the wireless 5G 
>> base station ended up in an upstairs bedroom window for signal strength 
>> reasons. The in-house wired ethernet was needed for a WiFi extender in 
>> the living room.
>> 
>> I wouldn't be happy, but it seems to work for his family. The 5G deal 
>> was 
>> cheaper than what he was paying at his old house.
>> 
>> According to the real estate realtor, not the builder's sales agent, 
>> broadband is now in the top three things home buyers want to know. Some 
>> states require the realtor MLS to disclose broadband access in the home 
>> listings. Broadband access disclosure not required in this state.
 
 
 
 --
 --
 Joly MacFie  +12185659365 
 --
 -
>> 
>> 
>> 
>> --
>> --
>> Joly MacFie  +12185659365 
>> --
>> -

Re: New home builders without wires

[joel]

Coaxial cable runs from the street to my house at my most recent purchase. All 
the “cable boxes” in the house are wireless. They are essentially whitelisted 
Android TV boxes.

— 
Joel Esler
Vice President, Security
ThreatSTOP

> On Dec 4, 2024, at 16:12, Jerry Cloe  wrote:
> 
> Even with broadcast, the need for coax (vs network) is going away. People 
> that use broadcast still want "cable type" services, mainly dvr and channel 
> guides. With so many options out there, TiVo, HDHomeRun, MythTV, many others, 
> all of them only need coax to the unit, then distribute via IP from there. 
> Still only need ethernet (or gasp, wifi) to most of the tv's.
>  
>  
> > But yeah, I would still run coax to each TV location -- even if you 
> 
> Broadcast television is still very much a thing. Monthly recurring cost 
> for an antenna is $0. Coax is the most common transmission line for this 
> purpose.
>  

Re: New home builders without wires

[joel]

I just wish I had the hook up at my local ISP (Armstrong).  They are currently 
running fiber to replace their Coax infrastructure, but they haven’t done it 
down my street yet.  I wish they would!

> On Dec 27, 2024, at 17:56, Mike Hammett  wrote:
> 
> "The builder/owner is responsible for construction between the ROW/property 
> line and the building."
> 
> and to the ISP, that's the most expensive part of the equation. It should 
> would be nice to not be financially responsible for that.
> 
> 
> 
> -
> Mike Hammett
> Intelligent Computing Solutions 
>   
>  
>  
> 
> Midwest Internet Exchange 
>   
>  
> 
> The Brothers WISP 
>   
> 
> From: "Sean Donelan" 
> To: "NANOG list" 
> Sent: Friday, December 27, 2024 4:36:36 PM
> Subject: Re[2]: New home builders without wires
> 
> On Fri, 27 Dec 2024, Aaron Wendel wrote:
> > When I built my house a few years ago I put a 0 entry hand hole with 2" 
> > conduit in the ROW in front and pulled 96 SM into the basement.  It takes a 
> > little convincing to get the providers to connect out there instead of 
> > running their own lines into my house but so far so good.
> 
> Things I learned.
> 
> In USA, the provider DEMARC used to be at the building wall (i.e. 
> 12-inches minimum point of entry inside the building). Fiber 
> providers sometimes install the ONT inside the wiring structured 
> infrastructure cabinet instead on the building outside wall now.
> 
> In many other countries, the DEMARC is at the ROW/property line. Comparing 
> broadband techniques between countries. The builder/owner is responsible 
> for construction between the ROW/property line and the building.
> 
> But if the neighborhood builder/developer has no broadband providers 
> (coax, telco or fiber) in the ROW, it doesn't matter.
> 
> In OECD broadband statistics, USA ranks 15th out of 36 countries. France 
> and South Korea are #1 and #2.

Re: Reliable GeoIP database

[joel]

100%.  We have certain things we do here at ThreatSTOP that isolate some 
locations based on the upstream provider because all of the GeoIP databases are 
wrong.

If we collectively understand that GeoIP is “best guess” or “best attempt” and 
not gospel, we’d all be better off.

— 
Joel Esler
Vice President, Security, Research, and Intelligence
ThreatSTOP

> On Feb 3, 2025, at 12:34, Dan Snyder  wrote:
> 
> I don't feel like there is any reliable GeoIP database. The protocol wasn't 
> designed for this and thus there is a lot of false information presented 
> about where IP addresses are located. 
> 
> On Mon, Feb 3, 2025 at 10:28 AM Dmitriy A.  <mailto:d...@prospectone.io>> wrote:
>> We've been dealing with geoip issues for quite a while and this is what we 
>> came up with, maybe it would be useful for you 
>> https://github.com/jsdelivr/globalping/blob/master/docs/geoip.md
>> 
>> But we're also in progress of updating the logic to include latency as an 
>> additional parameter.
>> 
>> On Mon, Feb 3, 2025, 12:20 Scott Q. > <mailto:qm...@top-consulting.net>> wrote:
>>> What are you guys using as a reliable GeoIP database ? I've tried Maxmind 
>>> and a few others, also checking against ARIN but there's tons of 
>>> differences.
>>> 
>>> For example: 1.2.9.0/24 <http://1.2.9.0/24> . ARIN says it belongs to China 
>>> Telecom but others say it's part of Russia: https://ipregistry.co/1.2.9.0 
>>> 
>>> How to handle such cases ?
>>> 
>>> Thanks!
>>> Scott​​

Re: TCP torture testing

[joel]

If you want to go nuts, check out Scapy

> On Jan 17, 2025, at 13:13, Brandon Martin  wrote:
> 
> Does anyone know of a good way to simulate oddball TCP happenings like:
> 
> * Out of order delivery
> * Variable delivery delays
> * (Especially) Unusual segmentation e.g. splitting part of a stream that 
> would and should normally be sent in a single segment into several smaller 
> segments sent back-to-back
> 
> And especially doing so with traffic from an existing TCP-speaking 
> application i.e. something like a TCP proxy that lets you deliberately mess 
> with the segmentation and delivery order.
> 
> My focus here isn't on volume of traffic but rather trying to tickle unusual 
> receive paths in my TCP/IP stack (which is not, for various reasons, a 
> mainstream well-known PC OS one) and how it interacts with the application.
> 
> There are lots of so-called "chaotic proxies" out there that do this sort of 
> thing to the degree that it's a bit overwhelming to get started.  I'm looking 
> for suggestions of things that have worked well for folks in this regard.
> 
> --
> Brandon Martin

Re: Anycast but for egress

[Joel Jaeggli]

On 7/27/21 10:54, Vimal wrote:
> (Unsure if this is the right forum to ask this question, but here goes:)
>
> From what I understand, IP Anycast can be used to steer traffic into a
> server that's close to the client.
>
> I am curious if anyone here has/encountered a setup where they use
> anycast IP on their gateways... to have a predictable egress IP for
> their traffic, regardless of where they are located?

Stateless outbound load-balancing setups exist.

Example you have two  or more nat44 / nat64 / cgnat boxes behind a
common ecmp path with the same destination IP(s).  this is normally so
that you have more boxes that accumulate state rather than being bound
to a single one.

>
> For example, a search engine crawler could in principle have the same
> IP advertised all over the world, but it looks like they don't...  I
> wonder why?

So this is a somewhat different problem...

There's  no assurance that when you initiate a connection that the
return path will return to the same instance of your anycast
announcement  when the server on the other side  replies.

Effectively the initiating party needs a unicast address or you need
some out of band path to get an errant packet back to the correct host.

> -- 
> Vimal
>

Re: Outbound Route Filtering (ORF) vendor support

[Joel Halpern]

You may want to examine the IDR lsit archive
https://mailarchive.ietf.org/arch/browse/idr/?q=orf
for discussion of the orf proposal and the difficulties people have with it.

Yours,
Joel

On 8/18/2021 1:10 PM, Douglas Fischer wrote:

Hello!

I also found a recent draft(expires Novembre 2021) about using Route 
Distinguisher as a Value on ORF.
https://datatracker.ietf.org/doc/draft-wang-idr-rd-orf/ 
<https://datatracker.ietf.org/doc/draft-wang-idr-rd-orf/>





Em qua., 18 de ago. de 2021 às 11:41, Humberto Galiza 
mailto:humbertogal...@gmail.com>> escreveu:


Hi,

Is anyone aware of any vendor that supports Outbound Route Filtering
(ORF) based on anything other than prefix-lists?

I found these two old IETF drafts (both expired :-/) which supported
the idea of filtering based on community and as-path respectively, but
I wasn't able to understand if they were ever discussed at the WG and
if there was any outcome of the discussion (I suspect the authors are
no longer even working with the mentioned companies in the drafts):

-
https://datatracker.ietf.org/doc/html/draft-chen-bgp-ext-community-orf-02
<https://datatracker.ietf.org/doc/html/draft-chen-bgp-ext-community-orf-02>
- https://datatracker.ietf.org/doc/html/draft-ietf-idr-aspath-orf-13
<https://datatracker.ietf.org/doc/html/draft-ietf-idr-aspath-orf-13>

Any info is very much appreciated.

Thanks,



--
Douglas Fernando Fischer
Engº de Controle e Automação

Re: Hi-Rise Building Fiber Suggestions

[Joel Jaeggli]

Sent from my iPhone

> On Feb 25, 2020, at 18:34, Norman Jester  wrote:
> 
> I’m in the process of choosing hardware
> for a 30 story building. If anyone has experience with this I’d appreciate 
> any tips.
> 
> There are two fiber pairs running up the building riser. I need to put a POE 
> switch on each floor using this fiber. 

In my experience with retrofitting existing structures, if you have access to 
the riser at each floor as it sounds like you do, you would typically drop in a 
new duct,  blow micro duct through it with a branch for each floor, have an MDF 
 or two In a utility spaces  and them you have the ability to reconfigure  the 
fiber as necessary to meet your present and future needs. 

You didn’t specify if the existing fiber is single or multi-mode however it is 
unlikely that the was enough slack built into two fiber runs to make 30 
additional splices so that approach seems dubious as a premise.

As you correctly surmise daisy chaining 30 switches is not an advisable network 
design practice.

> The idea is to cut the fiber at each floor and insert a switch and daisy 
> chain the switches together using one pair, and using the other pair as the 
> failover side of the ring going back to the source so if one device fails it 
> doesn’t take the whole string down.
> 
> The problem here is how many switches can be strung together and I would not 
> try more than 3 to 5. This is not something I typically do (stacking 
> switches). I have fears of STP and/or RSTP issue stacking past Ethernet 
> switch to switch limits (if they still exist??)
> 
> Is there a device with a similar protocol as the old 3com (now HP IDF) 
> stacking capability via fiber? 
> 
> I’d like to use something inexpensive as its to power ubiquiti wifi on each 
> floor.  Ideally if you know something I don’t about ubiquiti switches that 
> can do this I’d appreciate knowing.
> 
> Norman
> 
> 

Re: understanding IPv6

[Joel Halpern]

Just to clarify context, at this stage this is just Pascal's interesting 
idea for how to make ND work better on wireless.  No IETF working group 
has adopted this.  Various people seem to be interested, but it will be 
some time before we know if his approach gets traction.


The biggest difference between this and earlier changes along this line 
is that the wireless broadcast problem provides motivation for the 
change, where earlier efforts were more ~wouldn't it just be simpler if...~


Yours,
Joel Halpern

On 6/7/2020 2:28 PM, Etienne-Victor Depasquale wrote:
What I'm amazed at is the concept of multi-link subnet and the change in 
IP model being proposed.


See, for example, section 4 of 
https://tools.ietf.org/html/draft-thubert-6man-ipv6-over-wireless-05


Has anyone felt the same about the change being proposed? This swept 
away 25 years of thinking about IP subnets and IP links for me.


Etienne

On Sun, Jun 7, 2020 at 6:03 PM Brandon Martin <mailto:lists.na...@monmotha.net>> wrote:


On 6/7/20 6:01 AM, Denys Fedoryshchenko wrote:
 > There are very interesting and unobvious moments on IPv4 vs IPv6,
for
 > example related to battery lifetime in embedded electronics. In
ipv4,
 > many devices are forced to send "keepalives" so that the NAT
entry does
 > not disappear, with IPv6 it is not required and bidirectional
 > communications possible at any time. And in fact, it has a huge
impact
 > on the cost and battery life of IoT devices.
 > When I developed some IoT devices for clients, it turned out that if
 > "IPv6-only" is possible, this significantly reduces the cost of the
 > solution and simplify setup.

This is difficult to understate.  "People" are continually amazed
when I
show them that I can leave TCP sessions up for days at a time (with
properly configured endpoints) with absolutely zero keepalive traffic
being exchanged.

As amusingly useful as this may be, it pales in comparison to the
ability to do the same on deeply embedded devices running off small
primary cell batteries.  I've got an industrial sensor network product
where the device poll interval is upwards of 10 minutes, and even then
it only turns on its receiver.  The transmitter only gets lit up about
once a day for a "yes I'm still here" notification unless it has
something else to say.

In the end, we made it work across IPv4 by inserting an application
level gateway.  We just couldn't get reliable, transparent IPv6
full-prefix connectivity from any of the cellular telematics providers
at the time.  I don't know if this has changed.  For our application,
this was fine, but for mixed vendor "IoT" devices, it would probably
not
work out well.
-- 
Brandon Martin




--
Ing. Etienne-Victor Depasquale
Assistant Lecturer
Department of Communications & Computer Engineering
Faculty of Information & Communication Technology
University of Malta
Web. https://www.um.edu.mt/profile/etiennedepasquale

Re: Network card with relay in case of power failure

[Joel Jaeggli]

> On Jun 17, 2020, at 13:14, Dovid Bender  wrote:
> 
> Hi,
> 
> I am sorry if this is off topic.I was once demoed a network device that had 
> two interfaces. The traffic would go through the device. If there was a power 
> cut or some other malfunction there would be a relay that would physically 
> bridge the two network interfaces so the traffic would flow as if it was just 
> a network cable. Is anyone aware of such a network card or device?

that kind of device is an ethernet bypass tap.  the device is relay driven and 
closes when it loses power bypassing the in-band device.

there are others which require that they remain powered, but use a heatbeat of 
some flavor to detect failures and switch the path accordingly.

copper tap infrastructure has kind of fallen out of favor as ports have gotten 
faster (vs just spanning on a switch or router or passive optical taps) but it 
still exists.

gigamon / niagra and a number of white-box  tap manufactures make device that 
would be referred to as active bypass taps.

> 
> TIA.
> 
> 

Re: 60 ms cross-continent

[Joel Jaeggli]

Sent from my iPhone

> On Jun 20, 2020, at 9:27 AM, William Herrin  wrote:
> 
> Howdy,
> 
> Why is latency between the east and west coasts so bad? Speed of light
> accounts for about 15ms each direction for a 30ms round trip. Where
> does the other 30ms come from and why haven't we gotten rid of it?
> 
> c = 186,282 miles/second

This is c in a vacuum. Light transmission through a medium is slower. In the 
case of an optical fiber about 31% slower.

My lowest latency transit paths Palo Alto to the ashburn area are around 58ms.  
the great circle route for the two dcs involved is a distance 2408 miles which 
gives you a 39.6ms Lower bound.
 
The path isn’t quite a straight as that, but if you  eliminate the 6 routers in 
the path and count up the oeo regens I’m sure you can account most of the extra 
in the form of distance.

> 2742 miles from Seattle to Washington DC mainly driving I-90
> 
> 2742/186282 ~= 0.015 seconds
> 
> Thanks,
> Bill Herrin
> 
> -- 
> William Herrin
> b...@herrin.us
> https://bill.herrin.us/
> 

DNS & IP address management

[Joel Sommers]

Hello all -

I am a researcher at Colgate University, working with colleagues at the 
University of Wisconsin and Boston University on studying aspects of the DNS.

We're wondering if anyone here would be willing to share some insight into an 
apparent IP address management practice we have observed that is evident 
through the DNS.  In particular, we've seen a number of organizations that have 
a fairly large number of IPv4 addresses (typically all within the same /24 
aggregate or similar) all associated with a single FQDN, where the name is 
typically something like "reserved.52net.example.tld".  Besides the common 
"reserved" keyword in the FQDN, we also see names like 
"not-in-use.example.tld", again with quite a few addresses all mapped to that 
one name.  The naming appears to suggest that this is an on-the-cheap IP 
address management practice, but we are wondering if there are other 
operational reasons that might be behind what we observe.

Thank you for any insights you have -- please feel free to respond off-list.

Regards,
Joel Sommers

Re: are underwater routers a thing?

[Joel Jaeggli]

On 3/17/22 18:42, Michael Thomas wrote:
I was reading an article in the Economist about a new fiber route down 
the Red Sea from Israel and wondered if there were any branches off of 
those lines and where the routers were for them. The route kind of 
made it look like it was completely at sea, but it would kind of make 
sense to leave them at sea if you could put a router there.


There's a limited number of possible branches on a cable and as a result 
you just put the routers on the edges rather than in the middle. What 
you do put in the water is something like:


https://en.wikipedia.org/wiki/Submarine_branching_unit

The more the active electronics are at the ends rather than in the open 
ocean the greater the serviceability is and also over the lifetime of 
the cable the easier it is to upgrade it to higher capacity as the data 
bearing capacity of a given wavelength increases. The FLAG cable has had 
for example has has several capacity increases over it's service life 
which closing in on 25 years at this point.


Amplifiers are still necessary for longer spans but a lot of other logic 
is not. for situations where the distances are manageable passive 
unrepeated systems are greatly prefered because it keeps servicing due 
to electronic faults to a minimum and reduces the cost accordingly. see 
the recent tonga cable fault and repair for a passive system.


The mean depth of the worlds oceans is around ~3700 meters below MSL 
which means most service calls involve deploying to the proximate 
location of the fault, fishing around for a while and then carefully 
re-laying  several kilometers of cable on a splice has been made. which 
typically takes weeks.




Mike

Re: ISP data collection from home routers

[Joel Busch]

Hi Giovane

On 24.03.22 11:43, Giovane C. M. Moura via NANOG wrote:

Hello there,

Several years ago, a friend of mine was working for a large telco and 
his job was to detect which clients had the worst networking experience.


To do that, the telco had this hadoop cluster, where it collected _tons_ 
of data from home users routers, and his job was to use ML to tell the 
signal from the noise.


  I remember seeing a sample csv from this data, which contained 
_thousands_ of data fields (features) from each client.


I was _shocked_ by the amount of (meta)data they are able to pull from 
home routers. These even included your wifi network name _and_ password!

(it's been several years since then).



Creepy. And the provided CPE usually sucks too, what a deal...
I feel validated in preferring to use my own router at home.


And home users are _completely_ unaware of this.

So my question to you folks is:

- What's the policy regulations on this? I don't remember the features 
(thousands) but I'm pretty sure you could some profiling with it.



For the policies probably this is a good place to start if you are 
interested in US legislation (you didn't specify any location), as it's 
not federally regulated from what I gather:


https://www.ncsl.org/research/telecommunications-and-information-technology/2019-privacy-legislation-related-to-internet-service-providers.aspx



- Is anyone aware of any public discussion on this? I have never seen it.



I remember reading some discussion around ISPs selling browsing behavior 
data that they collect from their subscribers in the tech press during 
Pai's term as the head of the FCC. It was probably on Ars Technica or 
Techdirt.



Thanks,

Giovane Moura


Best,
Joel

--
Joel Busch, Network

SWITCH
Werdstrasse 2, P.O. Box, 8021 Zurich, Switzerland
phone +41 44 268 15 30, direct +41 44 268 16 58
https://switch.ch  https://swit.ch/linkedin  https://swit.ch/twitter

Re: FCC vs FAA Story

[Joel Jaeggli]

On 6/6/22 07:55, John R. Levine wrote:
Five years ago everyone knew that C band was coming.  A reasonable 
response would have been for the FAA to work with the FCC to figure 
out which altimeters might be affected (old cruddy ones, we now know), 
and come up with a plan and schedule to replace them. If the telcos 
had to pay some of the costs, they would have grumbled but done it.  
If the replacement schedule weren't done by now, they could live with 
that, too, so long as there were a clear date when it'd be done.


Instead the FAA stuck their fingers in their ears and said no, nothing 
can ever change, we can't hear you.  Are you surprised the telecom 
industry is fed up?


The US phased out leaded gas for everything but planes by 1996, and you 
still can't get an STC stating you can use an alternative fuel for some 
engines 24 years later.



Regards,
John Levine, jo...@taugh.com, Primary Perpetrator of "The Internet for 
Dummies",

Please consider the environment before reading this e-mail. https://jl.ly

Carrier Options in Bogota

[Joel Jaeggli]





> On Jul 1, 2022, at 6:50 AM, nanoguser99 via NANOG  wrote:
> 
> Nanog,
> 
> I need good connectivity to local eyeball networks there.  I've explored 
> Cogent, Lumen, and a local clled Telxius and results are all over the map.  
> Is there a provider that's 'well peered' with all the locals?  Hoping this 
> formats correctly but here's the results of ping tests on various looking 
> glasses to prefixes of the various locals.

Telxius is the present manifestation of Telefonica.

Internexa 262589 is the local domestic transit provider and offshoot of the 
Colombian national power company and is relatively well connected locally.

> 
> Local CarriersIP Prefix   Telxius Lumen   Cogent
> COLOMBIA TELECOMUNICACIONES S.A. ESP  152.200.0.0/14  22.025 ms   164ms   
> 115 ms
> Telmex Colombia S.A. (Claro)  190.144.0.0/14  14.319 ms   63ms115 ms
> Empresas Públicas de Medellín E.S.P.  201.220.30.0/23 94.264 ms   126 ms  
> 102 ms
> Movistar Colombia 186.116.14.0/24 38.894 ms   193ms   118 ms
> ETB - Colombia186.154.0.0/16  5.340 ms130ms   2.21 ms
> Columbus Networks Colombia138.121.12.0/24 60.212 ms   99ms89.8 ms
> Metrotel Colombia 190.1.128.0/19  20.989 ms   148ms   90.5 ms
> 
> Any advice?
> 
> -Nanoguser99
> 
> Sent with Proton Mail secure email.

Re: Jon Postel Re: 202210301538.AYC

[Joel Jaeggli]

some minor observations from the vantage point of a former AD inline.

On 11/2/22 17:48, Donald Eastlake wrote:

On Mon, Oct 31, 2022 at 12:03 PM Vasilenko Eduard
 wrote:

It is believed by many that 2 terms should be the maximum for one position of 
any chair (if it is a democracy).

Although this isn't a written guideline, many people believe that the
first 2 years in an Area Director position are sort of a probationary
period and as long as the AD does adequately, they should normally be
continued for a 2nd term, if they want it. Being continued for a 3rd
or later term should only be for superior performance and in the
absence of an apparently stronger alternative. Note the following


In my observed experience, it pretty much falls to a incumbent AD, to 
recruit alternatives, assuming they are doing a tolerable job of 
addressing the needs of their working groups. having done my 2 terms I 
found the role to be more one of middle management then of leadership, 
with the possible exception  of organizing and promoting new work 
organization around BOFs and working group formation.


ADs are highly dependent on WG chairs and senior individual contributors 
when it comes to advancing any particular activity.



-- Having served in one capacity or another on six Nomcoms over the
30 year history of the Nomcom system and I can assure you that there
are always at least 1 or 2 positions for which the Nomcom, after the
normal nomination period, has only zero or one possibilities to choose
between and it is common for NomCom to have to engage in substantial
recruiting (aka "arm twisting") to get more nominees from which to
choose. I just checked the NomCom pages and right now there are three
positions where, for the 2022-2024 term, the current NomCom has only
one person who has been nominated and agreed to run. So it isn't like
they have a vast pool of willing people to choose between.
-- Most former Area Directors say that there is a substantial
learning curve and it takes about a year before you are fully
effective as an Area Director. So, if ADs were limited to 1 term of 2
years, the IESG would only be 50 to 75% effective. With 2 terms of 2
years, it is more like 75 to 88% effective.


Also, serving as an AD is significantly detrimental to one's  own work 
in the IETF, both from a time perspective and respecting any chair, or 
other positions in one's area that you would give up in the process. As 
a volunteer activity there is a significant community service aspect too 
it. Unless your career goals involve a sympathetic employer and a goal 
of joining and staying in internet governance long term ADship has a 
significant impact on your ability to contribute to the IETF. I did my 4 
years, that was enough.




Furthermore, most Areas of the IETF have two co-ADs who tend to
moderate each other and many decisions are made by the IESG, which
consists of all the ADs, which is a further moderating effect.


It is evidently not the case for IETF - people stay in power for decades. It is 
just a fact that is not possible to dispute.
Yes, Nomcom is the mechanism for AD and above. I do not want to sort out how 
exactly it is performed.

Well, the NomCom system is well documented in a number of RFCs.

The most powerful single position in the IETF is the IETF Chair. As
you can see from the attached image only one person has served as IETF
Chair for as long as 8 years but as soon as the nomcom system was
started, they were replaced. After that, only one other person served
as long as 6 years, which was Russ Housley who I think was a
particularly good IETF Chair. All others have been limited to 2 or 4
years (1 or 2 terms). It would take a lot more work to do a similar
analysis for AD positions but I believe you would find that the length
of time in office for ADs was longer in the early days of the IETF and
is now rarely over 6 years.

In an earlier message, you said something about people retaining
positions due to networking with other people. Well, I would say that
is characteristic of all human organizations (unless you go with
strict Sortition). See my RFC 4144 "How to Gain Prominence and
Influence in Standards Organizations".


The IETF as a whole has activities (Working Groups) whose productivity 
on a given topic is largely driven by a small number of  individual 
contributors, these folks are entirely self-selected (authors, editors, 
collaborators, implentors). While there is not doubt quite a bit of 
survivor bias, networking and well as the capacity to be present (in 
person, remote) are necessary and rather expensive parts of advancing 
given pieces of work.






By the way, WG chairs have been put aside from any election mechanisms.

Yes, there are people who have served as co-Chair of an IETF Working
Group for long periods of time and there is currently no specific term
of office for a WG Chair. But these days most IETF WGs have two
co-Chairs, which has a moderating influence. Furthermore, Area
Dir

Re: BCP38 For BGP Customers

[Joel Halpern]

There is work a tthe IETF on an addon to RPKI called ASPA.  There is a 
draft that describes how the combiantion of ASPA and RPKI can be used to 
help with DDOS prevention.


There is also a working group at the IETF called SAVNET that is looking 
at what technological additions can be made to address the shortcomings 
in BCP 38.  In fairness, there is distinct disagreement as to what those 
shortcomings are, and whether the ideas being presented can help.  Input 
from more operators would be great.  (For completeness, I am a co-chair 
of that working group.)


Yours,

Joel

On 11/8/2022 9:39 AM, Brian Turnbow via NANOG wrote:

Hi Mike




This may not exist yet, but what about a uRPF-like feature that uses RPKI, IRR, 
etc. instead of current BGP feed?


There is rfc8704 that extends urpf
But I do not know of any commercial available solutions


Brian

Re: [EXTERNAL] Re: BCP38 For BGP Customers

[Joel Halpern]

The Internet Draft is at: 
https://datatracker.ietf.org/doc/html/draft-sriram-sidrops-bar-sav-01


Some slides that will be used to present thematerial on Friday are 
at:https://datatracker.ietf.org/meeting/115/materials/slides-115-savnet-lowering-improper-block-and-improper-admit-for-sav-the-bar-sav-approach


On 11/8/2022 12:17 PM, Compton, Rich A wrote:

Hi Joel, can you please point us to the IETF draft document that describes how a 
"combination of ASPA and RPKI can be used to help with DDoS prevention".  I was 
not able to find it.
Thanks!
-Rich

On 11/8/22, 8:05 AM, "NANOG on behalf of Joel Halpern"j...@joelhalpern.com>  wrote:


 CAUTION: The e-mail below is from an external source. Please exercise 
caution before opening attachments, clicking links, or following guidance.

 There is work a tthe IETF on an addon to RPKI called ASPA.  There is a
 draft that describes how the combiantion of ASPA and RPKI can be used to
 help with DDOS prevention.

 There is also a working group at the IETF called SAVNET that is looking
 at what technological additions can be made to address the shortcomings
 in BCP 38.  In fairness, there is distinct disagreement as to what those
 shortcomings are, and whether the ideas being presented can help.  Input
 from more operators would be great.  (For completeness, I am a co-chair
 of that working group.)

 Yours,

 Joel

 On 11/8/2022 9:39 AM, Brian Turnbow via NANOG wrote:
 > Hi Mike
 >
 >
 >
 >> This may not exist yet, but what about a uRPF-like feature that uses 
RPKI, IRR, etc. instead of current BGP feed?
 >
 > There is rfc8704 that extends urpf
 > But I do not know of any commercial available solutions
 >
 >
 > Brian

E-MAIL CONFIDENTIALITY NOTICE:
The contents of this e-mail message and any attachments are intended solely for 
the addressee(s) and may contain confidential and/or legally privileged 
information. If you are not the intended recipient of this message or if this 
message has been addressed to you in error, please immediately alert the sender 
by reply e-mail and then delete this message and any attachments. If you are 
not the intended recipient, you are notified that any use, dissemination, 
distribution, copying, or storage of this message or any attachment is strictly 
prohibited.

Re: Auth0 geolocation?

[Joel Esler]

I bet money it’s maxmind. — Sent from my iPhoneOn Apr 6, 2023, at 20:33, Tim Burke  wrote:




Anyone know who Auth0 is using for geolocation services? Have a customer reporting that Auth0, Lowes, Bank of America, and some other sites are reporting their IP in the wrong location. Checked the usual suspects,
BrothersWISP.com geolocation providers list, etcetera and they’re all showing in the correct location. 


Thanks,
Tim

Re: Northern Virginia has had enough with data centers

[Joel Halpern]

I will note that the grid in Loudoun county (arguably the center of the 
Northern Virginia data center boom) has actually gotten a LOT better 
than it was when I first moved here.  Some of that was rebuild started 
before the surge, due to just how bad it was.  But I am fairly sure that 
some of it is a side-effect of the build itself.


Yours,

Joel

On 6/23/2023 6:17 PM, Sean Donelan wrote:


Northern Virginia has about 275 data centers

The noise complaints are about HVAC fan noise (24-hour droning) from 
cooling towers or roof top farms of evaporative condensers.


The water complaints are about the one-use water cooling towers

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 centers.


And if you didn't know, some VC-funded companies can be a**-holes and 
not known for being good neighbors or anything besides making money.


And yes, I helped design & build several early data centers in NOVA :-)

https://www.washingtonpost.com/dc-md-va/2023/02/10/data-centers-northern-virginia-internet/ 

Re: QoS for Office365

[Joel Jaeggli]

> On Jul 9, 2019, at 07:19, Mark Tinka  wrote:
> 
> 
> 
> On 9/Jul/19 16:18, Ross Tajvar wrote:
>> I think the difficulty lies in appropriately marking the traffic. Like
>> Joe said, the IPs are always changing.
> 
> Does anyone know if they are reasonably static in an Express Route scenario?

Express route peering  with 12076 gives you more specific routes then you would 
otherwise see from 8075 (a /13 becomes a bunch of 17s etc) . it also gives you 
control over what region / application is exported to you.

My early experience as a customer with it was that there was on RPF check that 
I found to be a problem as a multihomed network.

> 
> Mark.
> 

Re: Colo in Africa

[Joel Jaeggli]

> On Jul 16, 2019, at 07:33, Ken Gilmour  wrote:
> 
> Hi Folks,
> 
> I work for a Security Analytics org and we're looking to build a small POP in 
> Africa. I am pretty clueless about the region so I was wondering if you could 
> help guide me in the right direction for research?
> 
> The challenges:
> Network needs to be able to receive millions of small PPS (as opposed to 
> serving smaller numbers of larger files).
> Can't be cloud (need bare metal servers / colo). We use the full capacity of 
> each server, all the time.
> Must have good connectivity to most of the rest of Africa
> We can initially only have one POP
> This is not like a normal website that we can just host on "any old 
> provider", the requirements are very different.
> 
> Is there a good location where we could either rent bare metal servers 
> (something like Internap - preferred) or colocate servers within Africa that 
> can serve most of the region?
> 
> "Good" is defined as an area with stable connectivity and power, no legal 
> restrictions on things like encryption, and good latency (sub 100ms) to the 
> rest of Africa.

100ms from most of the rest of Africa is going to be a bit dubious. If you draw 
a line horizontally through Senegal the costal stuff north of it can mostly be 
served in under 100ms from Europe.

While cross border terrestrial fiber exists most networks I’ve been exposed to 
have east west and north south connectivity Via submarine connected networks.  
This make it hard to locate one low latency spot in the middle.

NSRC has a project that can provide some background on terrestrial fiber.

https://afterfibre.nsrc.org/

The next best place to my mind for reach east and west is South Africa where 
you can pick up something of a diversity of transit find decent colo and pick 
up a few out of region peers if you locate near jinx or cinx which are both 
multi building connected exchanges.

> Our two closest POPs are in Singapore and The Netherlands, so I'd like 
> something closer to the middle that can serve the rest of Africa. Middle East 
> will be deployed after Africa.
> 
> I hope this is the right place to ask.
> 
> Thanks!
> 
> Ken

Re: netstat -s

[Joel Jaeggli]

On 7/17/19 17:54, Randy Bush wrote:

> do folk use `netstat -s` to help diagnose on routers/switches?

I suspect there's an unstated question here of should metrics reported
by netstat -s  which includes metrics from the kernel should include
metrics derived from from the asic counters.

I do / have occasionally used netstat or the values exposed to it from
the kernel which are generally also exposed via other metrics methods.

I would find it a little odd for ip counters in netstat for example to
include packets that do not hit the  kernel control plane, though I
could imagine someone wanting that.

> randy
>


pEpkey.asc
Description: application/pgp-keys

Re: Traffic visibility tools

[Joel Jaeggli]

On 7/24/19 09:16, Kenny Taylor wrote:
>
> Good morning,
>
>  
>
> I hate to pull away from the 44/8 fire (KJ6BSQ here, and former
> AMPRnet user), but I’d like to get some advice from the community on
> traffic visibility tools..
>
>  
>
> We use a pair of appliances called Exinda for traffic shaping and
> visibility.  The current appliances are end-of-support and the
> replacements are hugely expensive after GFI acquired Exinda.  Traffic
> shaping is less of a concern now, as circuit speeds have caught up
> with our users, but visibility is still a big need.  Those boxes do
> two things very well:  1) identification of FQDNs using SSL cert
> inspection on HTTPS traffic and 2) categorization of the traffic (i.e.
> Netflix, Youtube, etc.).  We have Netflow monitoring using PRTG, but
> seeing something like
> ‘ec2-34-214-76-39.us-west-2.compute.amazonaws.com’ in Netflow logs
> isn’t very useful.
>
tls 1.3 encrypted SNI  or QUIC and then DOH will eventually make https
opaque. Whether this is soon or not I guess is an open question but
passive inspection will probably become less useful over time. it seems
likely to cause industry / monitoring product change as well.
>
> We’re looking for something that could sit either inline or hang off a
> SPAN port, handle 5-10 Gbit of traffic, do the SSL cert FQDN
> identification, and preferably group results by site/subnet/category. 
> What would you guys recommend?
>
>  
>
> Thanks,
>
>  
>
> Kenny Taylor
>
> WAN Engineer
>
> Kern Community College District
>
>  
>


pEpkey.asc
Description: application/pgp-keys

Re: Security alert aggregator?

[Joel Whitehouse]

On 9/16/19 4:50 PM, David Hubbard wrote:
Curious if anyone knows of a security alert aggregation service?  For 
example, go and plug in all the various vendors hardware and software 
packages your enterprise uses, and then the service subscribes to all 
the random RSS feeds, CVE lists, vendor mailing lists, etc. to feed you 
the data instead of needing staff to write something custom, and then 
have checks to ensure the custom thing is still pulling from the right 
location, etc.


Thanks




There's always the US CERT Bulletins, which aggregate CVEs into a handy 
list and is published as an RSS feed:


https://www.us-cert.gov/ncas/bulletins

--
Joel Whitehouse
Software Developer
+1.319.521.7762

Re: IPv6 Pain Experiment

[Joel Halpern]

Folks should be aware that if you do not assume extreme pressure (which 
is what it is taking to get IPv6 deployed), it turns out to be quite 
hard to get the deployment incentives and structures for a 
map-and-encaps scheme to actually work for Internet-wide deployment.  It 
does work for a range of special cases.


Yours,
Joel

On 10/7/2019 10:58 PM, Michel Py wrote:

William Herrin wrote :
I was out to prove a point. I needed a technique that, at least in theory, 
would start working as a result of software
  upgrades alone, needing no configuration changes or other operator 
intervention. If I couldn't do that, my debate
opponent was right -- a greenfield approach to IPv6 made more sense despite the 
deployment challenge.


I think that, 12 years ago, you had the best mouse trap.


Map-encap, where you select a decapsulator (consult the map) and then send a 
tunneled packet (encapsulated) does
some cool stuff, but it's a pretty significant change to the network 
architecture. Definitely not configuration-free.


I am so painfully aware of this.

Michel.

TSI Disclaimer:  This message and any files or text attached to it are intended 
only for the recipients named above and contain information that may be 
confidential or privileged. If you are not the intended recipient, you must not 
forward, copy, use or otherwise disclose this communication or the information 
contained herein. In the event you have received this message in error, please 
notify the sender immediately by replying to this message, and then delete all 
copies of it from your system. Thank you!...

Re: Wikipedia drops support for old Android smartphones; mandates TLSv1.2 to read

[joel jaeggli]

On 12/31/19 07:10, Seth Mattinen wrote:
> On 12/31/19 12:50 AM, Ryan Hamel wrote:
>> Just let the old platforms ride off into the sunset as originally
>> planned like the SSL implementations in older JRE installs, XP, etc.
>> You shouldn't be holding onto the past.
> 
> 
> Because poor people anywhere on earth that might not have access to the
> newer technology don't deserve access to Wikipedia, right? Gotta make
> sure information is only accessible to those with means to keep "lesser"
> people out.

Argumentation on the basis of a tu quoque fallacy doesn't really add
much to the dicussion. Depreciating potentialy dangerous and definitely
obsolete protocols does not make you a hypocrite.

TLS 1.0 is genuinely hard to support at this point. Doing  so limits the
tooling you can use, It limits the CDNs that you can use. It forces you
to use obsolete codes bases.




signature.asc
Description: OpenPGP digital signature

Re: Wikipedia drops support for old Android smartphones; mandates TLSv1.2 to read

[joel jaeggli]

On 12/31/19 08:25, Seth Mattinen wrote:
> On 12/31/19 8:10 AM, joel jaeggli wrote:
>> Argumentation on the basis of a tu quoque fallacy doesn't really add
>> much to the dicussion. Depreciating potentialy dangerous and definitely
>> obsolete protocols does not make you a hypocrite.
> 
> 
> Then how about privilege?
> 
> If someone is living in a less-privileged situation (oppressive regime,
> state controlled ISP, extreme poverty, whatever) there's also a good
> chance that such people may not able to acquire newer/updated technology
> easily, perhaps not even legally at great risk. I will disagree with
> anyone's assertion that people in such conditions deserve to be
> disenfranchised.

You cite a hypothetical situation that may, but does not in my
experience exist, I work with customers who had populations of impacted
devices, so the consequences and timing of these transitions are
directly consequential to our customers.

Most CDNs turned off tls 1.0 by early to mid-2018. The  mobile devices
that still required it at the time and did not have an alternative were
a vanishingly small portion of the population then in use (for example
legacy docomo i-mode handsets), and the ones that cannot support it now
are still smaller,  Lacking support for SNI was a signification consumer
of address consumption in CDNs and that contributes to accessibility
cost and usability issues for websites  attempts at universal tls
deployment as well so we should be clear that there are plenty of people
who were disenfranchised by or burdened with otherwise unnecessary costs
by the need to support tls 1.0.

Most populations have recourse to application alternatives that can and
did extend their useful service life to tls 1.2 (current firefox
supports back to android 4.1 for example, Opera mini /mobile have much
larger market shares in bandwidth constrained environments and superior
performance on low end devices). tls 1.1 is not really far on the heels
of 1.0. hence you see this now.





signature.asc
Description: OpenPGP digital signature

Re: 5G roadblock: labor

[joel jaeggli]

On 1/2/20 06:09, Mike Hammett wrote:
> I know there are a couple companies doing it, but compute at the tower
> isn't going to go anywhere. It makes very little sense to put it at the
> tower when you can put it in one location per metro area.

The bottom of a tower is a fantastically expensive piece of real estate
to collocate something in. If you're financing the development of such
realestate it may sound great, but if you're leasing, it is sort of
outlandish, especially if you want .5KW per ru along with it.

If you set your latency budget artificially at 1ms, at .7 C photons
travel around 210km. If you draw a circle around the base of the tower
at 75KM it's quite feasible to achieve that assuming for the sake of
argument that it's necessary.

> 
> 
> -
> Mike Hammett
> Intelligent Computing Solutions
> http://www.ics-il.com
> 
> Midwest-IX
> http://www.midwest-ix.com
> 
> 
> *From: *"Brandon Butterworth" 
> *To: *jdambro...@gmail.com
> *Cc: *"North American Network Operators Group" 
> *Sent: *Wednesday, January 1, 2020 9:35:15 AM
> *Subject: *Re: 5G roadblock: labor
> 
> On Wed Jan 01, 2020 at 09:29:20AM -0500, jdambro...@gmail.com wrote:
>> Given the deployment of Wi-Fi into so many different applications
>> - your statement that 5G is to "replace" WiFi seems overly ambitious
> 
> We might think that but it is serious. They want to own it all
> and there is a small cabal of operators owning the spectrum so
> little room for new competitors.
> 
> Here's a project we did exploring some of the ambition
> https://www.bbc.co.uk/rd/blog/2019-02-5g-mobile-augmented-reality-bath
> 
> Previously we avoided the old Telco CDNs by sticking to regular
> Internet CDNs and building our own but edge compute (mobile CDN
> but a better name to compete with AWS) is more insidious as you
> may not be able to get the same result from CDNs out on the net.
> 
> Either the content providers or the external CDNs they use will
> have to pay to use the mobile CDN. How they will scale that at all
> those sites will be interesting to see.
> 
>> Perhaps preventing WiFi from further penetration is a better way
>> to look at it?
> 
> If the mobile companies are providing the WiFi routers they can
> control it (see LTE WiFi attempt) and one day replace it with
> 5G or 6G in all the things. If they make a better job of it than
> everyones devices fighting for 5GHz then they may succeed.
> 
> brandon
> 




signature.asc
Description: OpenPGP digital signature

Re: Latency, TCP ACKs and upload needs

[joel jaeggli]

On 4/19/16 6:29 PM, Jean-Francois Mezei wrote:
> As part of the ongoing CRTC hearings, the incumbents' claim that
> continued implementation of the current 5/1 standard would make Canada a
> world leader for broadband in the future.
> 
> A satellite company who currently can't even deliver its advertised 5/1
> now brags its next satellite will deliver 25/1.
> 
> So I have a few questions:
> 
> Considering a single download TCP connection. I am aware that modern TCP
> stacks will rationalize ACKs and send 1 ACK for every x packets
> received, thus reducing upload bandwidth requirements. Is this basically
> widespread and assumed that everyone has that ?

with an mss of 1460 the inbound packets for reasonably well packed flow
will be 36.5x larger than the acks which are 40 bytes.

sack rfc 2018 means you don't have to acknowledge all of the inbound
packets.

> Also, as you split available bandwidth between multiple streams, won't
> ack upload requirements increase because ACK rationalisation happens far
> less often sicne each TCP connection has its own context for ACKs?
> 
> When one considers the added latency of satellite links, does 25/1 make
> sense ?  (I need a sanity check to distinguish between marketing spin
> presented to the regulator and real life)

satellite vendors use various forms of tcp acceleration  which may
involve among other things having middle boxes that pre-emptively send
the ack, play with the window size etc.

> I noticed that in the USA, EXEDE Satellite advertises 12/3 plans and
> they are also on a VIA Sat satellite, presumably the same vehicle that
> Xplornet tries to deliver its measly 5/1 on. Would all beams be
> identical on a satellite or can they be configured differently with a
> ISP adjustable rate of upload/download inside the same spectrum ?
> 
> 
> 
> 
> Also, when you establish a TCP connection, do most stacks have a default
> window size that gives the sender enough "patience" to wait long enough
> for the ACK ?

retransmission timeouts are typically measure in seconds...

https://tools.ietf.org/html/rfc6298

and geostationary orbits typically have RTTs under 800ms.

> If sender sends packet 457, doesn't get ACK in time and resends 457,
> doesn't that also result in reduction in window size (the very opposite
> of what would be needed in high latency links) ?
> 
> And when the first ACK finally arrives, won't the sender assume this ACK
> was for the resent 457 ?   Or is satellite latency low enough that
> stacks all have enough default "patience" to wait for ACKs and this is a
> non issue ?
> 
> (Note Xplornet refused to answer questions on whether they operate
> special proxies at their gound stations to manage TCP connections to
> appear "close").

seems likely

> 
> 
> What i am trying to get at here is whether 25/1 on satellite, in real
> life with a few apps exchanging data, would actually be able to make use
> of the 25 download speed or whether the limited 1mbps upload would choke
> the downloads ?
> 




signature.asc
Description: OpenPGP digital signature

LDP flaps specifically present on ACX Juniper routers (ACX4000 and ACX1100)

[joel ahumuza]

Hi All,

We are experiencing an issue with ACX routers running on 12.3X54-D20.7
where the LDP sessions are continuously flapping, the logs indicate the
following;

Apr 21 03:36:31  hostname rpd[2299]: RPD_LDP_SESSIONDOWN: LDP session
x.x.x.x is down, reason: hold time expired
Apr 21 03:36:34  hostname rpd[2299]: RPD_LDP_NBRDOWN: LDP neighbor x.x.x.x
(lo0.0) is down
Apr 21 03:36:38  hostname rpd[2299]: RPD_LDP_NBRDOWN: LDP neighbor x.x.x.x
(lo0.0) is down
Apr 21 03:36:38  hostname rpd[2299]: RPD_LDP_SESSIONDOWN: LDP session
x.x.x.x is down, reason: all adjacencies down
Apr 21 03:55:34  hostname rpd[2299]: RPD_LDP_SESSIONDOWN: LDP session
x.x.x.x is down, reason: received notification from peer
Apr 21 03:55:34  hostname rpd[2299]: RPD_LDP_SESSIONDOWN: LDP session
x.x.x.x is down, reason: received notification from peer
Apr 21 03:55:35  hostname rpd[2299]: RPD_LDP_SESSIONDOWN: LDP session
x.x.x.x is down, reason: received notification from peer
Apr 21 03:55:35  hostname rpd[2299]: RPD_LDP_SESSIONDOWN: LDP session
x.x.x.x is down, reason: received notification from peer

Actions taken from our team was;
- Increase the hold time setting on the ldp enabled interfaces.
- Increase the time interval on the same ldp enabled interfaces.
- setting the ldp session protection setting on the ldp enabled loopback
interface.

Unfortunately the actions did not yield much since the flaps have been
ongoing.

Anyone have any Idea on what the problem / solution might be?

-- 
Blessings,

Joel Ahumuza
SkypeID - jl.hmz
+ 256-75-1040411 | + 256-78-2040411

Re: Cost-effectivenesss of highly-accurate clocks for NTP

[joel jaeggli]

On 5/15/16 10:05 AM, Eric S. Raymond wrote:
> Mel Beckman :
>> The upshot is that there are many real-world situations where
>> expensive clock discipline is needed. But IT isn't, I don't think,
>> one of them, with the exception of private SONET networks (fast
>> disappearing in the face of metro Ethernet).
> 
> Thank you, that was very interesting information.  I'm not used to thinking
> of IT as a relatively low-challenge environment!
> 
> You're implicitly suggesting there might be a technical case for
> replacing these T1/T3 trunks with some kind of VOIP provisioning less
> dependent on accurate time synch.  Do you think that's true?

APCO  and TETRA trunked radio  are mature systems, they do carry data,
but are somewhat lower bandwidth. Being TDM they are dependent on
accurate clocks.

LTE systems are used or envisioned being used for high bandwidth
applications.

> 




signature.asc
Description: OpenPGP digital signature

Re: Netflix VPN detection - actual engineer needed

[joel jaeggli]

HE's downstream cone does not include a whole lot of residential ISPs.
if you further exclude the ones that are multihomed you're left with a
pretty small subset. that said they (HE) can be and are a valuable peer
both in v4 and v6.

Personally I wouldn't single home to anything that looks tier-1ish but
your mileage may vary the residential operators I look  at tend to be
fairly diversly connected.

On 6/3/16 5:46 PM, Josh Reynolds wrote:
> You might be one of a handful.
> On Jun 3, 2016 7:35 PM, "Gary E. Miller"  wrote:
> 
>> Yo Spencer!
>>
>> On Fri, 3 Jun 2016 20:13:03 -0400
>> Spencer Ryan  wrote:
>>
>>> Yes but HE doesn't serve residential users directly.
>>
>> Really?  I am the only one?  Doubtful.
>>
>> RGDS
>> GARY
>> ---
>> Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
>> g...@rellim.com  Tel:+1 541 382 8588
>>
> 




signature.asc
Description: OpenPGP digital signature

Re: Netflix VPN detection - actual engineer needed

[joel jaeggli]

On 6/5/16 6:23 PM, Josh Reynolds wrote:
> Uhm, what? Where do you think ISPs get their transit exactly?

They buy from 2 or more wholesale transit providers and in general they
opportunistically peer, although scale helps a lot there.

> On Jun 5, 2016 8:17 PM, "joel jaeggli"  <mailto:joe...@bogus.com>> wrote:
> 
> HE's downstream cone does not include a whole lot of residential ISPs.
> if you further exclude the ones that are multihomed you're left with a
> pretty small subset. that said they (HE) can be and are a valuable peer
> both in v4 and v6.
> 
> Personally I wouldn't single home to anything that looks tier-1ish but
> your mileage may vary the residential operators I look  at tend to be
> fairly diversly connected.
> 
> On 6/3/16 5:46 PM, Josh Reynolds wrote:
> > You might be one of a handful.
> > On Jun 3, 2016 7:35 PM, "Gary E. Miller"  <mailto:g...@rellim.com>> wrote:
> >
> >> Yo Spencer!
> >>
> >> On Fri, 3 Jun 2016 20:13:03 -0400
> >> Spencer Ryan mailto:sr...@arbor.net>> wrote:
> >>
> >>> Yes but HE doesn't serve residential users directly.
> >>
> >> Really?  I am the only one?  Doubtful.
> >>
> >> RGDS
> >> GARY
> >>
> 
> ---
> >> Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
> >> g...@rellim.com <mailto:g...@rellim.com>  Tel:+1 541 382
> 8588 
> >>
> >
> 
> 




signature.asc
Description: OpenPGP digital signature

Re: Netflix VPN detection - actual engineer needed

[joel jaeggli]

On 6/7/16 6:55 AM, Cryptographrix wrote:
> As I said to Netflix's tech support - if they advocate for people to turn
> off IPv6 on their end, maybe Netflix should stop supporting it on their end.
> 
> It's in the air whether it's just an HE tunnel issue or an IPv6 issue at
> the moment, and if their tech support is telling people to turn off IPv6,
> maybe they should just instead remove their  records.

it clearly works with prefixes delegated from other isps.
...
http://i.imgur.com/sJUM7tn.png

> (or fail back to ipv4 when v6 looks like a tunnel)
> 
> 
> 
> On Tue, Jun 7, 2016 at 9:22 AM Mark Felder  wrote:
> 
>>
>>> On Jun 6, 2016, at 22:25, Spencer Ryan  wrote:
>>>
>>> The tunnelbroker service acts exactly like a VPN. It allows you, from any
>>> arbitrary location in the world with an IPv4 address, to bring traffic
>> out
>>> via one of HE's 4 POP's, while completely masking your actual location.
>>>
>>
>> Perhaps Netflix should automatically block any connection that's not from
>> a known residential ISP or mobile ISP as anything else could be a server
>> someone is proxying through. It's very easy to get these subnets -- the
>> spam filtering folks have these subnets well documented. /s
>>
>> --
>>   Mark Felder
>>   f...@feld.me
>>
>>
> 




signature.asc
Description: OpenPGP digital signature

Re: Netflix VPN detection - actual engineer needed

[joel jaeggli]

On 6/8/16 9:13 AM, Owen DeLong wrote:
> As of last week, I still wasn’t getting an IPv6 address by default on my 
> iPhone 6S+
> on T-Mobile.

turn off mobile hotspot...

> Just saying.
> 
> Owen
> 
>> On Jun 7, 2016, at 11:00 AM, Ca By  wrote:
>>
>> On Tuesday, June 7, 2016, Cryptographrix  wrote:
>>
>>> Very true - I was being a bit extremist out of frustration, but I think
>>> you're spot on - he.net tunnels and even 6to4 are toys to provide IPv6
>>> support, not actually IPv6 support.
>>>
>>> And I'm quite frustrated because there's so little actual v6 support, and
>>> I *do* actually need it on a daily basis for work.
>>>
>>> Because there's no actual ISP IPv6 support anywhere else (in parts of the
>>> US that *have* multiple ISPs), you can't even make the case to your ISP
>>> that it's a legitimate requirement for you because they know you're not
>>> really going to get v6 elsewhere.
>>>
>>>
>> I think we have different definitions of "no actual isp ipv6 support"
>>
>> Again, a helpful akamai blog
>> https://blogs.akamai.com/2016/06/four-years-since-world-ipv6-launch-entering-the-mainstream.html
>>
>> fixed line: Comcast, AT&T, TWC, just to name the largest in the nation have
>> meaningful deployments of ipv6. The only thing holding back greater
>> deployment for those networks are legacy CPE that will age out slowly.
>>
>> All 4 of the national mobile operator have ipv6 default on for most
>> new phone models.
>>
>> Yes, many gaps to fill still. But, on "my network" with shy of 70 million
>> users, everything has ipv6 except the iPhone, and that will change RSN. And
>> for users with v6, the majority of their traffic is ipv6 e2e since the
>> whales (google, fb, netflix, increasingly Akamai) are dual stack.
>>
>> CB
>>
>>
>>>
>>>
>>> On Tue, Jun 7, 2016 at 10:22 AM Ca By >> > wrote:
>>>


 On Tuesday, June 7, 2016, Cryptographrix >>> > wrote:

> As I said to Netflix's tech support - if they advocate for people to turn
> off IPv6 on their end, maybe Netflix should stop supporting it on their
> end.
>
> It's in the air whether it's just an HE tunnel issue or an IPv6 issue at
> the moment, and if their tech support is telling people to turn off IPv6,
> maybe they should just instead remove their  records.
>
> (or fail back to ipv4 when v6 looks like a tunnel)
>
>
 I think you need to reset your expectations of a free tunnel service.

 he.net tunnels are a toy for geeks looking to play with v6. In terms of
 Netflix subcriber base, it is amazing insignificant number of users.

 At the end of the day, anonymous tunnels, just like linux, are not
 supported by Netflix. And, he.net tunnel users are hurting ipv6 overall
 just like 6to4 by injecting FUD and other nonesense complexity For a
 toy.

 Move on to a real issue instead of beating this dead horse.

 CB


>
>
> On Tue, Jun 7, 2016 at 9:22 AM Mark Felder  wrote:
>
>>
>>> On Jun 6, 2016, at 22:25, Spencer Ryan  wrote:
>>>
>>> The tunnelbroker service acts exactly like a VPN. It allows you,
> from any
>>> arbitrary location in the world with an IPv4 address, to bring
> traffic
>> out
>>> via one of HE's 4 POP's, while completely masking your actual
> location.
>>>
>>
>> Perhaps Netflix should automatically block any connection that's not
> from
>> a known residential ISP or mobile ISP as anything else could be a
> server
>> someone is proxying through. It's very easy to get these subnets -- the
>> spam filtering folks have these subnets well documented. /s
>>
>> --
>>  Mark Felder
>>  f...@feld.me
>>
>>
>

> 
> 




signature.asc
Description: OpenPGP digital signature

Re: Detecting Attacks

[joel jaeggli]

On 6/10/16 10:39 PM, subashini hariharan wrote:
> Hello,
> 
> I am Subashini, a graduate student. I am interested in doing my project in
> Network Security. I have a doubt related to it.
> 
> The aim is to detect DoS/DDoS attacks using the application. I am going to
> use ELK (ElasticSearch, Logstash, Kibanna) for processing the logs (Log
> Analytics).
> 
> My doubt is regarding how do we generate logs for detecting this attack? As
> I am new to this process, I am not sure about it.

lots of dos simply isn't targeting the application layer or even the
host especially. So, that stuff will rarely bubble up via syslog for
example until machines start to run into trouble. rather it will be
exposed via flow data or the frequent collection of interface counters.

> Also, if it is possible to do any other attacks similar to this, you can
> please give a hint about it.
> 
> Could anyone please help with this, it would be a great help!!
> 




signature.asc
Description: OpenPGP digital signature

Re: Link-local v6 and mobile phones

[joel jaeggli]

On 6/15/16 8:56 AM, Willy MANGA wrote:
> Hello,
> 
> a little question :)
> 
> For mobile operators using v6 on their networks, how do you manage
> link-local communication between mobile phones ?

the link local address is bound to eps bearer the other end of which is
the p-gw.

so it's a point-to-point link.

so you say what about the radio bearer?

there are two kinds, the srb where signalling is present, and the user
data which is associated with an eps databearer.

> While I understand it's layer 2 related,  am i able for example to make
> ping sweep and be able to communicate directly with other phone (customer) ?

appart from your nexthop, no.

> 




signature.asc
Description: OpenPGP digital signature

Re: 1GE L3 aggregation

[joel jaeggli]

On 6/16/16 12:51 AM, Saku Ytti wrote:
> Hey,
> 
> I've been bit poking around trying to find reasonable option for 1GE
> L3 full BGP table aggregator. It seems vendors are mostly pushing
> Satellite/Fusion for this application.
> 
> I don't really like the added complexity and tight coupling
> Satellite/Fusion forces me. I'd prefer standards based routing
> redundancy to reduce impact of defects.
> 
> ASR9001 and MX104 are not an options, due to control-plane scale. New
> boxes in vendor pipeline are completely ignoring 1GE.
> 
> I've casually talked with other people, and it seems I'm not really
> alone here. My dream box would be 96xSFP + 2xQSFP28, with pretty much
> full edge features (BGP, LDP, ISIS, +1M FIB, +5M RIB, per-interface
> VLANs, ipfix or sflow, at least per-port QoS with shaper, martini
> pseudowires).
> 
> With tinfoil hat tightly fit on my head, I wonder why vendors are
> ignoring 1GE? Are business cases entirely driven now by Amazon,
> Google, Facebook and the likes? Are SP volumes so insignificant in
> comparison it does not make sense to produce boxes for them?
> Heck even 10GE is starting to become problematic, if your application
> is anything else than DC, because you can't choose arbitrary optics.

There's not a lot of innovation going on in lower end 1G chipsets. The
natural consequent of that is that you can build a high-end gig switch
or router around a chipset supporting 10Gb/s ports or feeds and speeds
your cogs are naturally going to be rather similar to the 10Gb/s offering.




signature.asc
Description: OpenPGP digital signature

Re: Quick question regarding: Problematic IPv6 Multicast traffic within an IX.

[joel jaeggli]

On 6/24/16 9:27 AM, Bob Evans wrote:
> 
> Is it true that managed Layer2 switches used by IX's can not block IPv6
> multicast ingress port traffic from broadcasting to all ports ?

you can filter multicast destination addresses by acl.

NDP you kinda need since it replaces ARP

RA's you can and should filter (icmp6 type 134)

> ___Yes , seen many IXs with IPv6 multicast continuing yet IPv4 multicast
> is blocked.
> 
> ___No , All should be able to bock IPv6 multicast.
> 
> ___Only a few specific managed switch manufacturers have this issue with
> IPv6 multicast broadcasting.
> 
> You're knowledge on this problem would be helpful.
> 
> Thank You in advance.
> 
> Bob Evans
> CTO
> 
> 
> 
> 
> 
> 




signature.asc
Description: OpenPGP digital signature

Re: Real world power consumption of a 7604-S or 7606-S

[joel jaeggli]

On 6/27/16 5:35 PM, Eric Kuhnke wrote:
> Yes, very much agreed, part of the reason why I'm looking to do the
> watts per linecard calculation is to illustrate how it's not healthy
> except in certain places. As an edge aggregation device in a very
> small city in a rural western US state where the electricity is 6
> cents/kWh, the 24x7 load from a 7604 that eats 950W with supervisors
> and a 6724SFP linecard is not so terrible. In this case the colo
> space for a 42U rack is sometimes literally free.
> 
> In a IX point/datacenter/colocation environment where rack and power
> costs real money, not so much.

2 x ( 4 x 10Gig)  linecards is really as fast as it goes no over-subscribed.

It's been rather a long time or possibly never since that platform was
cutting edge on a PPS/Watt basis.

Today at roughly double the power consumpution per slot you can have
between 16 and 36 hundred gig ports or 48 x 10gig at half the power
consumption.


> 
> On Mon, Jun 27, 2016 at 5:26 PM, Tom Hill 
> wrote:
> 
>> On 28/06/16 00:26, Eric Kuhnke wrote:
>>> Example: 7604S chassis with dual 2700W DC power - chassis and
>>> fans use how much power? 2 x RSP720-3CXL at 310W each WS-X6704
>>> with DFC4 - ???W each
>> 
>> Way too much, is the simple answer.
>> 
>> I did have a 7604 (non-S) with the same PSUs, 1x SUP720-3BXL, 1x 
>> WS-X6724-SFP and 1x WS-X6708-3CXL was drawing near 2kW.
>> 
>> It's not healthy, please consider how much you'll spend in
>> electricity vs. something else. For example, the ASR9001 uses a 5th
>> of the power.
>> 
>> 
>> Cisco do also have a power calculator, too. It's conservative but
>> not overly so:
>> 
>> http://cpc.cloudapps.cisco.com/cpc/launch.jsp
>> 
>> -- Tom
>> 
> 




signature.asc
Description: OpenPGP digital signature

Re: akamai abnormal spike

[joel jaeggli]

On 7/18/16 4:57 PM, Mike Hammett wrote:
> Several of my WISP colleagues have noticed this behavior (CDN sending
> way more traffic than the customer's pipe can handle) from (I
> believe) multiple CDNs. Not sure if it is intention on behalf of the
> CDN or an error, but it has been on-going for several months if not
> years.

It's not a healthy tcp flow if the number of packets associated with the
flow stays well in excess of the link capacity for a while... if you
have recourse to to l4 header flags you might find that it was an ack
flood or repeated retramission of the same PDUs. Either way someones
state machine has a bug.

joel

> 
> 
> 
> - Mike Hammett Intelligent Computing Solutions 
> http://www.ics-il.com
> 
> 
> 
> Midwest Internet Exchange http://www.midwest-ix.com
> 
> 
> - Original Message -
> 
> From: "Blake Hudson"  To: nanog@nanog.org Sent:
> Monday, July 18, 2016 8:49:21 AM Subject: Re: akamai abnormal spike
> 
> We noticed that on the 12th-14th we had multiple subscribers on
> ~5Mbps subscription rates that were being sent ~50Mbps of data
> sourced from TCP port 80 (apparently HTTP) from Limelight Networks'
> servers. The data did appear to be user requested, still not sure why
> TCP didn't throttle the data rate appropriately. The 50Mbps was
> distributed across multiple LLNW servers. Makes me wonder if the
> customer was requesting one batch of data and multiple servers were
> responding.
> 
> The issue cleared up on its own and I never was able to perform a
> full packet capture to investigate. I have not noticed the same
> behavior from Akamai servers.
> 
> Clayton Zekelman wrote on 7/18/2016 8:26 AM:
>> 
>> 
>> We noticed on the 12th and 13th there was a significant up tick in
>>  traffic served from our Akamai servers as well.
>> 
>> 
>> At 05:37 PM 13/07/2016, eric c wrote:
>>> Good afternoon,
>>> 
>>> Has anyone notice any abnormal spike in Akamai trafic in the last
>>> 24-48 hours compared to other days. I know it was black tuesday
>>> yesterday but traffic from last month didn't even come close to
>>> what we saw from Akamai.
>>> 
>>> We have some caching servers and even notice a spike to them as
>>> well.
>>> 
>>> Limelight even showed up on our network.
>>> 
>>> thanks eric
>> 
> 
> 




signature.asc
Description: OpenPGP digital signature

Re: CAIDA selected by FCC for internet performance measurement

[joel jaeggli]

On 8/12/16 1:41 PM, Scott Weeks wrote:
>
> --- s...@donelan.com wrote:
> From: Sean Donelan 
>
> CAIDA has submitted to the FCC its initial proposal for
> measuring internet interconnection point performance 
> metrics as part of the AT&T/DirecTV merger conditions.
>
> http://transition.fcc.gov/Daily_Releases/Daily_Business/2016/db0812/DA-16-909A1.pdf
> -
>
>
> I don't seem to be able to get the pdf referred to in the 
> above link to open correctly.
>
> https://ecfsapi.fcc.gov/file/108042516812991/MB%20Dkt%2014-90%20AT&T%20Inc.%20First%20Amended%20IME%20Report%20ECFS.PDF
opens fine in chrome created by Aspose.Pdf for .NET 10.2.0

> Anyone else get it to open?  I want to find out about 
> the methodology.
>
> scott
>
>

Re: charges for prefix filter updates (was Re: Any ISPs using AS852 for IP Transit?)

[joel jaeggli]

On 9/15/16 11:28 AM, Ken Chase wrote:
> I feel this can be a public topic:
>
> Rogers just charged us that for an update (one update, multiple entries).
> We had to go through their quotation machinery too, took like 4-5 days. 
> Additional
> time was wasted because we contacted their tech dept directly at the start. 
> (which
> is what I do for all my other upstreams...)
>
> Kinda brutal.
Coordination problems are a point of high friction and cost for low
margin products. I generally prefer that my providers be able to
generate prefix filters on the basis of route objects, If it's not part
of their service offering; how costs are assigned for service requests
is going to be part of contract negotiions.

joel

> Cogent and HE nor NAC or Yipes or Tata ever did that to us.
>
> Nickle and diming -- why, cuz transit is a cheap commodity now, gotta make the
> cash somewhere?
>
> That said Cogent offered us a static /26 along side our BGP years ago then 
> warned
> us it'd be $50/mo or something for that # of ips going forward. We didnt need 
> it
> so dispensed with it.
>
> /kc
>
>
> On Thu, Sep 15, 2016 at 02:07:01PM -0400, Jason Lixfeld said:
>   >If there are any ISPs who use TELUS/AS852 for IP Transit over BGP, I???d 
> be interested in hearing from you.
>   >
>   >I???d like to compare notes to see if you are also paying $250 for each 
> BGP prefix filter updated request, or if we???re the only ones???
>   >
>   >Thanks in advance!
>




signature.asc
Description: OpenPGP digital signature

Re: Providing transit to unallocated networks

[joel jaeggli]

On 9/27/16 5:46 PM, Alistair Mackenzie wrote:
> Thanks for this, it shows as
>
> apnic|ZZ|ipv4|103.***.***.0|1024|20160927|reserved||e-stats
>
> I expect this still stands with it being reserved?

 I'm not sure why you would bother obscuring it. What purpose does that
serve in furthering the discussion?

If it's not

route-views>show ip bgp 103.6.232.0/22
BGP routing table entry for 103.6.232.0/22, version 87113221
Paths: (1 available, best #1, table default)
  Not advertised to any peer
  Refresh Epoch 1
  3277 39710 20632 31133 58073
195.208.112.161 from 195.208.112.161 (194.85.4.4)
  Origin IGP, localpref 100, valid, external, best
  Community: 3277:39710 20632:65441 65535:65000
  rx pathid: 0, tx pathid: 0x0

What is it?

>
>
> William, it's 100% an apnic range and shows no org and is registered
> to the APNIC Hostmaster. This applies for both the ASN and the address
> space.
>
>
> On 28 September 2016 at 01:28, William Herrin  wrote:
>
>> On Tue, Sep 27, 2016 at 8:18 PM, Alistair Mackenzie  
>> wrote:
>>> I've come across a network which seem to be getting transit yet both the
>>> ASN and IP space is not allocated by the RIR.
>> Hi Alistair,
>>
>> There is still unicast address space that isn't allocated by any RIR?
>>
>> Seriously though, check all your bases. Is not the space unallocated
>> by all RIRs or just the one you expect to hold it?  If you have a
>> transit provider that's not playing by the rules, contact their
>> transit providers to complain and if you still don't get satisfaction,
>> I'd name and shame the lot of them. Failure to filter bad actors is
>> how prefix hijacking happens.
>>
>> Regards,
>> Bill Herrin
>>
>>
>>
>> --
>> William Herrin  her...@dirtside.com  b...@herrin.us
>> Owner, Dirtside Systems . Web: 
>>
>>
> On 28 September 2016 at 01:36, George Michaelson  wrote:
>
>> check if the block is in this file.
>>
>> http://labs.apnic.net/delegated-nro-extended
>>
>> If not, then the block is hijacked or being abused.
>>
>> the file format is a bit obscure: the ipv4 record is base-ip|hostcount
>> but converting that to prefix length is pretty simple.
>>
>> -G
>>
>> On Wed, Sep 28, 2016 at 10:18 AM, Alistair Mackenzie
>>  wrote:
>>> Hi,
>>>
>>> I've come across a network which seem to be getting transit yet both the
>>> ASN and IP space is not allocated by the RIR. It does appear at some
>> point
>>> that it was valid however this is no longer the case.
>>>
>>> The network is single homed and I tried asking the transit provider what
>>> their policy was on this but got no answer.
>>>
>>> Has anyone seen anything like this? What has happened in the past with
>>> things like this?
>>>
>>> Thanks,
>>> Alistair





signature.asc
Description: OpenPGP digital signature

Re: nexus N3K-C3064PQ vs juniper ex4500 in order to protect against ddos

[joel jaeggli]

On 9/30/16 12:42 PM, Pedro wrote:
> 
> Hello,
> 
> I have some idea to put switch before bgp router in order to terminate
> isp 10G uplinks on switch, not router. Main reason is that could be some
> kind of 1st level of defence against ddos, second reason, less
> important, save cost of router ports, do many port mirrors.

The distinction on cost of ports is somewhat germain when dealing with
things like span ports. maybe strictly speaking if the router platform
can handle line rate forwarding at minimum packet size it is just as
performant as the switch at both forwarding and probably acl application
(there are of course exceptions).  in general these switches has
substantially smaller port buffers then a router or high end l3 switch
platform (qfx10k or ptx for example) would have when spanning ports or
doing some statistical multiplexing. Which can be a liability.

A number of us no doubt use layer2/3 switches as customer aggregation or
indeed peering platforms. and suitability for such may depend on the mix
of hardware  and software features available as well as non-forwarding
attributes such as the amount of memory available. i have boxes for
example that have a full table rib but only default route for
non-customer routes. the prospects for gettting away with that sort of
thing with only 2GB of ram are growing increasingly dire.

So i would say this sort thing does work, and with some familiarity with
the platforms you become more comfortable with their limitations, but
it's not automatically the best route, and the additional bump in the
forwarding path is not free of costs or complexity.

> I think about N3K-C3064PQ or Juniper ex4500 because there are quite
> cheap and a lot of on Ebay.
> 
> I would like on nexus or juniper try use some feature:
> 
> -  limit udp, icmp, bum packets (bandwith,pps) at ingress tagged port or
> vlan
> -  create counters: passed and dropped packets, best way to get this
> counters via snmp oid, sent snmp traps, syslog etc in order to monitor
> or even as a action shut down port
> -  port mirror from many ports/vlans to multiple port (other anty ddos
> solutions)
> -  limited bgp but with flowspec to comunicate with another anty ddos
> devices
> 
> I'm also wondering how this feature above impact on cpu/whole switch. It
> can be some performance degradation ot all of this feature are done in
> hardware, with wirespeeed ? Which model will better to do this ?
> 
> Thanks for any advice,
> Pedro
> 
> ---
> Ta wiadomość została sprawdzona na obecność wirusów przez oprogramowanie
> antywirusowe Avast.
> https://www.avast.com/antivirus
> 
> 




signature.asc
Description: OpenPGP digital signature

Re: nested prefixes in Internet

[joel jaeggli]

On 10/10/16 9:04 AM, Roy wrote:
>
>
> The solution proposed allows ISP-B to use both paths at the same time,
> needs ISP-C to minimal changes, and has low impact on the global
> routing tables..  I have successfully used it in the past and my old
> company is still using it today.

Having two parties in control of a prefix announcement is a bit of a
disaster. ISP A becomes partitioned from isp B isp B does not withdraw
the covering aggregate and black-holes the of ISP A that lands on it's 
edge. bummer.

>
> .On 10/9/2016 11:50 PM, Martin T wrote:
>> Florian:
>>
>> as I told in my initial e-mail, ISP-B is multi-homed, i.e connected to
>> ISP-A(who leases the /24 to ISP-B from their /19 block) and also to
>> ISP-C. ISP-B wants to announce this /24 both to ISP-A and ISP-C.
>> That's the reason why either solution 1 or 2 in my initial e-mail is
>> needed.
>>
>> However, I would like to hear from Roy and Mel why do they prefer a
>> third option where ISP A announces the /19 and the /24 while ISP B
>> does just the /24.
>>
>>
>> thanks,
>> Martin
>>
>> On Wed, Oct 5, 2016 at 11:50 PM, Florian Weimer 
>> wrote:
>>> * Martin T.:
>>>
 Florian:

> Are the autonomous systems for the /19 and /24 connected directly?
 Yes they are.
>>> Then deaggregation really isn't necessary at all.
>>>
> (1) can be better from B's perspective because it prevents certain
> routing table optimizations (due to the lack of the covering prefix)
 What kind of routing table optimizations are possible if covering /19
 prefix is also present in global routing table?
>>> The /24 prefix could arguably be dropped and ignored for routing
>>> decisions.
>




signature.asc
Description: OpenPGP digital signature

Re: Dyn DDoS this AM?

[joel jaeggli]

On 10/21/16 3:21 PM, David Birdsong wrote:
> On Fri, Oct 21, 2016 at 2:58 PM, Randy Bush  wrote:
>
>> anyone who relies on a single dns provider is just asking for stuff such
>> as this.
>>
>> randy
>>
> I'd love to hear how others are handling the overhead of managing two dns
> providers. Every time we brainstorm on it, we see it as blackhole of eng
> effort WRT to keeping them in sync and and then waiting for TTLs to cut an
> entire delegation over.

Not all the ones you might choose based on scale support axfr... That's
a bit of a problem for the most traditional approach to this., of those 
that do it's straight-forward to use one as the master for another, or
use a hidden master. Your own master may have demonstrably lower
availability then one or the other of your providers. getting two well
considered choices to play nice with each other isn't that hard.





signature.asc
Description: OpenPGP digital signature

Re: CenturyLink in Advanced Talks to Merge With Level 3 Communications - Interweb is doomed

[joel jaeggli]

On 10/28/16 12:18 PM, Mel Beckman wrote:
> Level3 hasn't even finished migrating its TWTelecom customers to the L3 AS 
> yes, and it's been years. So I don't think you can expect any faster 
> transition for CL. 
3549 still exists...
>  -mel beckman
>
>> On Oct 28, 2016, at 2:16 PM, Timothy Lister  wrote:
>>
>> So if this went through, how would it happen? Does 3356 (L3) absorb 209's
>> (CL) infrastructure and slowly make customers change their peering config
>> to hit 3356 instead?
>>
>> You make a good point, I have at least a couple clients that peer to both
>> providers for redundancy. One of which just recently signed an agreement
>> with CenturyLink for the sole purpose of fail over.
>>
>> -Original Message-
>> Re: CenturyLink in Advanced Talks to Merge With Level 3 Communications -
>> Interweb is doomed
>> From: Jima 
>> To: 
> On 10/27/2016 12:36, Nevin Gonsalves via NANOG wrote:
> :-)
>> http://www.wsj.com/articles/centurylink-in-advanced-talks-to-merge-with-level-3-communications-1477589011
>>
>>
>> This is great! Except for all of their mutual customers who had circuits
>> from both for redundancy. (See also: Level 3's and TWTC's mutual
>> customers, and probably a long list of other M&A I'm not thinking of
>> off-hand.)
>>
>> OK, I lied about it being great anyway.
>>
>>  Jima
>>
>>
>>
>> -Original Message-
>> Re: CenturyLink in Advanced Talks to Merge With Level 3 Communications -
>> Interweb is doomed
>> From: Jima 
>> To: 





signature.asc
Description: OpenPGP digital signature

Re: pay.gov and IPv6

[joel jaeggli]

00:02:02.758900 IP6 2601:647:4201:.60962 >
2605:3100:fffd:100::15.443: Flags [S], seq 2375673666, win 65535,
options [mss 1440,nop,wscale 5,nop,nop,TS val 568401205 ecr
0,sackOK,eol], length 0

00:02:02.811619 IP6 2605:3100:fffd:100::15.443 >
2601:647:4201:.60962: Flags [S.], seq 2570148804, ack 2375673667,
win 4320, options [mss 1440,nop,nop,TS val 2246573166 ecr
568401205,sackOK,eol], length 0

it's happy to do 1440 which is unsprising, as1239 is probably not
therefore the source of the pmtud hole.

On 11/20/16 11:51 PM, JORDI PALET MARTINEZ wrote:
> Tested again from four different networks. Not working for me. > > Same in 
> other web sites hosted by 1&1 (for example
www.legalveritas.es). All their IPv6 web sites are broken, every time I
need to access their web sites, need to disable IPv6, I know how to do
that, but regular folks not. > > tbit from 2001:df0:4:4000::1:115 to
2001:8d8:100f:f000::2d5 > server-mss 1420, result: pmtud-fail > app:
http, url: http://diskmakerx.com/ > [  0.010] TX SYN 64  seq
= 0:0> [  0.286] RX SYN/ACK 64  seq = 0:1   
> [  0.286] TX 60  seq = 1:1> [  0.297]
TX233  seq = 1:1(173)> [  0.573]
RX 60  seq = 1:174  > [  0.799] RX  
1480  seq = 1:174(1420)> [  0.799] RX 73  seq =
1421:174(13)> [  0.799] RX   1480  seq = 1434:174(1420) 
> [  0.799] RX   1480  seq = 2854:174(1420)  > [  0.799] TX
PTB   1280  mtu = 1280 > [  0.799] RX   1480  seq =
4274:174(1420)  > [  0.799] RX   1480  seq = 5694:174(1420) 
> [  0.799] RX   1480  seq = 7114:174(1420)  > [  0.801]
RX   1480  seq = 8534:174(1420)  > [  0.809]
TX 60  seq = 174:1  > [  0.821] RX  
1480  seq = 9954:174(1420)  > [  0.824] RX   1480  seq =
11374:174(1420) > [  1.628] RX   1480  seq = 1:174(1420)   
> [  1.629] TX PTB   1280  mtu = 1280 > [  3.288]
RX   1480  seq = 1:174(1420)> [  3.288] TX PTB  
1280  mtu = 1280 > [  6.612] RX   1480  seq = 1:174(1420)   
> [  6.612] TX PTB   1280  mtu = 1280 > [ 13.252]
RX   1480  seq = 1:174(1420)> > > > Regards, > Jordi > >
> -Mensaje original- > De: Mark Andrews  >
Responder a:  > Fecha: lunes, 21 de noviembre de 2016,
1:26 > Para: Carl Byington  > CC:
,  > Asunto: Re: pay.gov
and IPv6 > > > In message
<1479686835.13553.4.ca...@ns.five-ten-sg.com>, Carl Byington writes:
> On Sun, 2016-11-20 at 10:51 +0100, JORDI PALET MARTINEZ wrote:
> > For example, you will not get this working if you have a lower MTU
> > than 1.500, which is quite normal, not just for tunnels, but also
> > because the PPP/others encapsulation in many access links:
>
> > http://diskmakerx.com/
>
> curl -6 -v http://diskmakerx.com/
>
> That works here via an he.net tunnel. Perhaps 1and1 fixed something.
>
> > And the advertised MSS was what?  On my box I'm seeing 1220 for
> > IPv6 compared with 1460 for IPv4.  1220 shouldn't see PMTU problems.
>
> > 1460 on the other hand will cause problems as more clients are
> > forced behind IPv4 as a service links.
>
> > 11:14:50.056215 IP 172.30.42.121.52280 > 217.160.0.214.80: Flags
> [S], seq 2115844511, win 65535, options [mss 1460,nop,wscale
> 4,nop,nop,TS val 538455715 ecr 0,sackOK,eol], length 0
> > 11:14:50.137770 IP6 2001:470:a001:4:c00d:3d8c:14e7:6de3.52282 >
> 2001:8d8:100f:f000::2d5.80: Flags [S], seq 4181372812, win 65535,
> options [mss 1220,nop,wscale 4,nop,nop,TS val 538455793 ecr
> 0,sackOK,eol], length 0
>
> > Mark
>
> > > > > -- > Mark Andrews, ISC > 1 Seymour St., Dundas
Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742
INTERNET: ma...@isc.org > > > > > >
** > IPv4 is over > Are you
ready for the new Internet ? > http://www.consulintel.es > The IPv6
Company > > This electronic message contains information which may be
privileged or confidential. The information is intended to be for the
use of the individual(s) named above. If you are not the intended
recipient be aware that any disclosure, copying, distribution or use of
the contents of this information, including attached files, is
prohibited. > > >





signature.asc
Description: OpenPGP digital signature

Re: Voice channels (FTTH, DOCSIS, VoLTE)

[joel jaeggli]

On 11/21/16 11:13 AM, Jean-Francois Mezei wrote:
> On 2016-11-21 02:53, Mikael Abrahamsson wrote:
>
>> Typically it travels on another "bearer" compared to Internet traffic.
>>
>> http://blog.3g4g.co.uk/2013/08/volte-bearers.html
>>
>> Think of bearers as "tunnels" between the mobile core network and the 
>> device. 
> Many thanks for the pointer. The fact that VoLTE has its own dedicated
> APN explains things.
>
> I am however a bit confused on the "bearer" term.
>
> Say a carrier has spectrum in 700Mhz  bands A and B  each 5mhz in each
> direction, bonded together as a single 10mhz (each way) channel.
>
> The docunment states:
> "R.92 requires the use of a particular set of radio bearers"

the radio bearers described are are the signaling radio bearers. their
existence is independent of of the link/mac layer configuration. The mac
layer layer (e-utra) exists below the l2 bearers.

https://en.wikipedia.org/wiki/E-UTRA
> Does this mean that a bearer is given specific spectrum within a block
> (such as a dedicated colour on a fibre) or that it is just given
> dedicated capacity on the single data channel formed by LTE compressing
> all of the spectrum into one big channel ?
>
> I though I understood the concept when the name "tunnel" had been
> mentioned because I understand that a handset estabishes a "hopping"
> tunnel with local IP which changes as you move from tower to tower, but
> the tunnel itself maintains a permanent IP connection that remains
> unchanged as you move from tower to tower. In such a concept, I could
> understand each tunnel (one to the data APN, one to the IMS/VoLTE APN)
> having bandwidth allocations.
these are URBs they are terminated between the UE and the P-GW
> But when the text brought up "radio bearer", I got confused again sicne
> radio implies breaking the spectrum apart, which would reduce LTE
> compression efficiency.
SRB and URB are the l2 presentation of the tunnels established for user
and signaling traffic.
>
>
>




signature.asc
Description: OpenPGP digital signature

Re: Voice channels (FTTH, DOCSIS, VoLTE)

[joel jaeggli]

On 11/21/16 3:12 PM, Jean-Francois Mezei wrote:
> On 2016-11-21 15:18, joel jaeggli wrote:
>
>
>> SRB and URB are the l2 presentation of the tunnels established for user
>> and signaling traffic.
> OK, so wth LTE, if carrier has 10mhz up and down, this represents a
> single chunk of spectrum providing one pipe ? (in fibre terms: a single
> light colour through one strand)
Not really the air interface uses OFDMA coding scheme, so it is both
divided into sub-carriers from 1.4 to 20mhz wide which are then also
scheduled accordingly.
> The "smoke and mirrors" is accomplished by having different tunnels
> inside that one pipe, with some tunnels granted QoS or other
> preferential treatment between the IMS/VoiP servers and the RAN ?
you kinda want you qos policy to apply end-to-end in the carrier
network, not just on the ran.
> When a handset sends a VolTE packet to the "IMS" APN, is there any
> preferential treatment given between the handset and the antenna ?
sure, hence the qos policy template on the radio bearer.
differing numbers of subcarriers and slots can be assigned to UE based
on the services they are using.

>  Or
> does preferential treatment begin at the RAN where the packet is
> recognized as going to "IMS" APN and going on the fast track to it ?
>
> or put another way. If everyone uploads a HD selfie movie at the same
> time, are handset uploads slowled with normal TCP flow control (drop a
> packet, no ack received, handset halves the TCP window size)?
Those flows going to have the best effort policy. but yes it is
reasonable to presume that in the event of congestion the best effort
queue will be preferentially dropped. likewise if you have voice and
data going at the same time they are not strictly speaking competing for
resources, because the volte radio bearer has a resource assigned to it
and the and the ip data bearer has a resource assigned to it.
> In other words, some router near antenna, to prioriotize packets to the
> IMS/VoLTE server, will flow control normal IP traffic to maintain
> sufficient upload capacity for VolTE traffic ?
>
> Or are the tunnels fixed in capacity such that unused capacity in one is
> never used by the other ?
>
>
>
> From a policy point of view, if I propose a net neutrality policy, I
> have to make sure it doesn't prevent normal VoLTE functioning, while
> preventing abuse of the ability for an incumbent to prioritize/zero-rate
> its own services.
> For instance:
>
>
> AT&T in USA zero rates voice but not video calls over VoLTE.
> Rogers in Canada zero rates both voice and video calls over VoLTE.
>
> So if VoLTE video travels to the same IMS as voice, and not through the
> normal IP APN, that means AT&T has to count the video traffic separately
> and add it. But if Video goes through the normal IP traffic APN, it gets
> counted fairly, like Skype packets, but Rogers then captures that
> netflow and later deducts it from the total usage.
>
> The issue here is that VoLTE is the new kid on the block with video
> capability and incumbents can use their power to displace competitors
> such as Skype/Facetime and that may constitute undue preference, unless
> the standards are such that they have no choice because that it how it
> has to work. (But AT&T shows that it can still count video and treat
> video calls fairly compared o skype video calls).
>
>




signature.asc
Description: OpenPGP digital signature

Re: Cogent Router code updates during height of ecommerce season?

[joel jaeggli]

On 12/9/16 11:30 AM, Justin Wilson wrote:
> Are they not doing these during maintenance windows? Anytime we get a notice 
> from Cogent, Level3, Att they are always during a maintenance window at least 
> a week ahead of time.  We have yet to see any maintenance window 
> notifications from Hurricane Electric.  Maybe our circuit has never had to 
> have one in a few years. Or maybe they have so much redundancy it doesn’t 
> matter and we never see the maintenance.  
FWIW I have a few Cogent circuits, The maintenance look normalish and
are all scheduled per their normal process, I aware of at least one
cisco bug related to source mac usage they had that was annoying if not
catastrophic since it was visible on our ports.
>
> Justin Wilson
> j...@mtin.net
>
> ---
> http://www.mtin.net Owner/CEO
> xISP Solutions- Consulting – Data Centers - Bandwidth
>
> http://www.midwest-ix.com  COO/Chairman
> Internet Exchange - Peering - Distributed Fabric
>
>> On Dec 8, 2016, at 11:09 AM, Drew Weaver  wrote:
>>
>> Hello,
>>
>> Over the last several days we have had interruptions at multiple times in 
>> our service with Cogent due to them performing router code updates on 
>> multiple nodes. I know that some companies put these sorts of updates on 
>> hold during the holiday season but I was wondering if anyone has heard of 
>> any unannounced security flaws that only larger companies such as Cogent 
>> would be privy to?
>>
>> I am certain that if you have heard of these flaws you cannot post the 
>> details but a simple yes or no about the existence of such a thing is plenty 
>> for me.
>>
>> Happy Holidays
>>
>> Thanks,
>> -Drew
>>
>




signature.asc
Description: OpenPGP digital signature

Re: Recent NTP pool traffic increase

[joel jaeggli]

On 12/15/16 3:07 PM, Dan Drown wrote:
> Quoting Jose Gerardo Perales Soto :
>> We've recently experienced a traffic increase on the NTP queries to
>> NTP pool project (pool.ntp.org) servers. One theory is that some
>> service provider NTP infraestructure failed approximately 2 days ago
>> and traffic is now being redirected to servers belonging to the NTP
>> pool project.
>>
>> Does anyone from the service provider community have any comments?
>
> To add some more numbers to this, I'm seeing 4x the usual NTP traffic
> to my server in pool.ntp.org, starting Dec 13.
>
> Top source ASNs by % of NTP traffic seen by my server (I don't have
> pre-Dec 13 traffic by ASN handy)
>
> sprint 4.0%
> verizon-wireless 3.4%
> tmobile 2.9%
> att-wireless 2.8%
> comcast 2.1%
> orange 1.8%
> sky 1.6%
> twc 1.0%
> att 1.0%
> swisscom 0.9%
> saudinet 0.8%
> virgin 0.6%
> opaltelecom 0.5%
> qwest 0.5%
> eli 0.2%
> verizon 0.2%
>
> Possibly related is the new iOS release.  Does the new iOS generate
> more NTP traffic?  Can anyone measure that?

IOS uses time.appple.com which is widely available.





signature.asc
Description: OpenPGP digital signature

Re: BCM5341x

[Joel Jaeggli]

Sent from my iPhone

> On Dec 24, 2016, at 15:51, Mike Hammett  wrote:
> 
> I've asked Broadcom directly, but being as though I don't have an intent to 
> buy tens of thousands of chips (or any at all), I don't expect I'll hear 
> back. I was hoping someone here would have some insight. 
> 
> Do any of you know what functionality is available on those chips? That's the 
> chip that powers the Ubiquiti 10G switches and I figured I would limit my 
> most aggressive feature requests to things they can actually deliver with the 
> platform as is. 
> 
> Other than things you just assume a managed switch has like 802.1p and 
> 802.1q, it mentions an advanced ContentAware™ Engine (which means?), IEEE1588 
> (sync over Ethernet), 802.1ag (OAM stuff), "Enhanced DoS attack statistics 
> gathering" (which means?), "IPv4/IPv6 L3 packet classification" (which 
> means?), etc. 
> 
> I'm sure there's an array of things to ask about, but MLAG and S-Flow are at 
> the top of my list at the moment. 

MCLAG is a control plane function. 

Sflow on devices that don't generate it in a distributed fashion is done but 
punting sampled packets to the control-plane for classification by an sflow 
agent. Sample rate is therefore contingent on adequate CPU and control-plane 
bandwidth.

The greyhound switch SOC may be hampered by the amount of CPU available 
locally, but the 2MB packet buffer also is probably cause for caution.

> https://www.broadcom.com/products/ethernet-connectivity/switch-fabric/bcm5341x/
>  
> 
> 
> 
> 
> - 
> Mike Hammett 
> Intelligent Computing Solutions 
> 
> Midwest Internet Exchange 
> 
> The Brothers WISP 
> 
> 

Re: Benefits (and Detriments) of Standardizing Network Equipment in a Global Organization

[joel jaeggli]

On 12/29/16 10:22 AM, valdis.kletni...@vt.edu wrote:
> On Thu, 29 Dec 2016 07:44:45 -0800, Leo Bicknell said:
> 
>> But I think the question others are trying to ask is a different
>> hyptothetical.  Say there are two vendors, of of which makes perfectly
>> good edge routers and core routers.  What are the pros to buying all
>> of the edge from one, and all of the core from the other?
> 
> The *original* question, which seems to have gotten lost, was:
> 
> Say you're doing business in 100 countries, with some stated level of
> possible autonomy for each business unit.
> 
> Is it better for upper corporate to say "all 100 national business units
> will use vendor A for edge devices and vendor B for routing", or "all 100
> business units shall choose, based on local conditions such as vendor
> support, a standard set of vendors for their operations"?
> 
> Stated differently, "Which causes more trouble - a mix of Vendor A in
> Denmark talking to Vendor B in Finland, or corporate mandating the use
> of Vendor Q even if Q doesn't have a support office in Kazakhstan while
> vendor F has an office in the building next door"?

ok I'll bite.

imho, repeatable patterns of deployment are a great  economic and
organizational simplification. imho that doesn't mean they are
identical. There may be generational differences even in what otherwise
would be cookie cutter deployments, e.g. because devices go end of sale,
new ones become available, regional vendor preference or vendor
diversification.

If these are centrally organized and operated or coordinated, then the
minimum number of variants possible considering the circumstances where
variation is is desirable. It minimizes the effort and training required
to deploy and operate the system.

If I were to take CDN pops as an example.

Inter-generational variation is necessary as are accommodations for
varying scale. the system is centrally coordinated and common operating
methods are necessary if these systems are to behave a cohesive whole.

Systems where deployment is less centralized, and local autonomy is
therefore necessary as for example occurs when local contractors use
their own equipment may come to different conclusions. e.g. that the
specification of  the minimum necessary common elements becomes the only
feasible approach. For example if you are an Uber driver your minim  IT
requirements are something like

Uber cell phone requirements
iPhone requirements to run the Uber driver app

Must be iPhone 4S, 5, 5C, 5S, 6, 6 Plus, 6S, 6S Plus, SE, 7, or 7 Plus
running iOS 8 or later versions
For best results: Use iPhone 5 or newer

Android requirements to run the Uber driver app

Any smart phone from 2013 or newer, running Android version 4.0 or newer
For best results: The phone should run Android 5.0 or newer




signature.asc
Description: OpenPGP digital signature

Re: Soliciting your opinions on Internet routing: A survey on BGP convergence

[joel jaeggli]

On 1/9/17 2:56 PM, Laurent Vanbever wrote:
> Hi NANOG,
> 
> We often read that the Internet (i.e. BGP) is "slow to converge". But how slow
> is it really? Do you care anyway? And can we (researchers) do anything about 
> it?
> Please help us out to find out by answering our short anonymous survey 
> (<10 minutes).
> 
> Survey URL: https://goo.gl/forms/JZd2CK0EFpCk0c272 
> 
> 
> 
> ** Background:
> 
> While existing fast-reroute mechanisms enable sub-second convergence upon 
> local outages (planned or not), they do not apply to remote outages happening 
> further away from your AS as their detection and protection mechanisms only 
> work locally.
> 
> Remote outages therefore mandate a "BGP-only" convergence which tends to be
> slow, as long streams of BGP UPDATEs (containing up to 100,000s of them) must
> be propagated router-by-router. Our initial measurements indicate that it can
> take state-of-the-art BGP routers dozens of seconds to process and propagate
> these large streams of BGP UPDATEs. During this time, traffic for important
> destinations can be lost.

One of the phenomena that is relatively easy to observe by withdrawing a
prefix entirely is the convergence towards longer and longer AS paths
until the route disappears entirely. that is providers that are further
away will remain advertising the route and in the interim their
neighbors  will ingest the available path will  until they too process
the withdraw. it can take a comically long time (like 5 minutes)  to see
the prefix ultimately disappear from the internet. When withdrawing a
prefix from a peer with which you have a single adjacency this can
easily happens in miniature.

> 
> ** This survey:
> 
> This survey aims at evaluating the impact of slow BGP convergence on
> operational practices. We expect the findings to increase the understanding of
> the perceived BGP convergence in the Internet, which could then help
> researchers to design better fast-reroute mechanisms.
> 
> We expect the questionnaire to be filled out by network operators whose job 
> relates
> to BGP operations. It has a total of 17 questions and should take less 10 
> minutes
> to answer. The survey and the collected data are anonymous (so please do *not*
> include information that may help to identify you or your organization). 
> All questions are optional, so if you don't like a question or don't know the 
> answer,
> please skip it.
> 
> A summary of the aggregate results will be published as a part of a scientific
> article later this year.
> 
> Thank you so much in advance, and we look forward to read your responses!
> 
> 
> Laurent Vanbever (ETH Zürich, Switzerland)
> 
> 
> PS: It goes without saying that we would be also extremely grateful if you 
> could
> forward this email to any operator you might know who may not read NANOG.
> 




signature.asc
Description: OpenPGP digital signature

Re: Apple Caching Server question

[joel jaeggli]

On 1/13/17 5:43 AM, lane.pow...@swat.coop wrote:
> I saw the apple caching server mentioned on an earlier thread. Is this 
> appropriate/functional/scaleable enough to implement as an ISP? It is an 
> intriguing idea. From the docs I could find, I couldn't tell if it was only 
> geared towards home / small business or if it could scale up to handle ISP 
> level traffic. 

It's a feature of macos server. You do get to register prefix with
apple, but I don't imagine colocating a mac mini is isp level traffic.

That said as714 peers extensively

https://www.peeringdb.com/net/3554

so picking them up works too.

> thanks, 
> Lane 
> 




signature.asc
Description: OpenPGP digital signature

Re: IPv6 BGP prefix filters

[joel jaeggli]

On 1/16/17 2:01 PM, Alistair Mackenzie wrote:
> Hi,
> 
> So recently I've come across an issue with a large ISP announcing a /22 and
> /25 of IPv6 space. We are currently filtering <28 and >48 which until now
> has worked fine for us.
> 
> What are others using as their prefix filters in the DFZ?

Currently the shortest prefix delegation to an RIR is a /12,  the
assigned global uni-cast range at present all fits within 2000::/3.

I currently apply   < 20,  > /48 but I also have recourse to default.

> Thanks,
> Alistair
> 




signature.asc
Description: OpenPGP digital signature

Re: External BGP Controller for L3 Switch BGP routing

[joel jaeggli]

On 1/16/17 6:53 AM, Tore Anderson wrote:
> * Saku Ytti
> 
>> On 16 January 2017 at 14:36, Tore Anderson  wrote:
>>
>>> Put it another way, my «Internet facing» interfaces are typically
>>> 10GEs with a few (kilo)metres of dark fibre that x-connects into my
>>> IP-transit providers' routers sitting in nearby rooms or racks
>>> (worst case somewhere else in the same metro area). Is there any
>>> reason why I should need deep buffers on those interfaces?  
>>
>> Imagine content network having 40Gbps connection, and client having
>> 10Gbps connection, and network between them is lossless and has RTT of
>> 200ms. To achieve 10Gbps rate receiver needs 10Gbps*200ms = 250MB
>> window, in worst case 125MB window could grow into 250MB window,  and
>> sender could send the 125MB at 40Gbps burst.
>> This means the port receiver is attached to, needs to store the 125MB,
>> as it's only serialising it at 10Gbps. If it  cannot store it, window
>> will shrink and receiver cannot get 10Gbps.
>>
>> This is quite pathological example, but you can try with much less
>> pathological numbers, remembering TridentII has 12MB of buffers.
> 
> I totally get why the receiver need bigger buffers if he's going to
> shuffle that data out another interface with a slower speed.
> 
> But when you're a data centre operator you're (usually anyway) mostly
> transmitting data. And you can easily ensure the interface speed facing
> the servers can be the same as the interface speed facing the ISP.

unlikely given that the interfaces facing the server is 1/10/25/50 and
the one facing the isp is n x 10 or n x 100

> So if you consider this typical spine/leaf data centre network topology
> (essentially the same one I posted earlier this morning):
> 
> (Server) --10GE--> (T2 leaf X) --40GE--> (T2 spine) --40GE-->
> (T2 leaf Y) --10GE--> (IP-transit/"the Internet") --10GE--> (Client)
> 
> If I understand you correctly you're saying this is a "suspect" topology
> that cannot achieve 10G transmission rate from server to client (or
> from client to server for that matter) because of small buffers on my
> "T2 leaf Y" switch (i.e., the one which has the Internet-facing
> interface)?

you can externalize the cost of the buffer at the expense of latency
from the t2, e.g. by enabling flow control faciing the host or other
high capacity device, or engaging in packet pacing on the server if the
network is fairly shallow.

If the question is how can I ensure high link utilization rather than
maximum throughput for this one flow, the buffer requirement  may be
substantially lower.

e.g. if you are sizing based on

buffer = (bandwidth delay * desired bandwidth) / sqrt(nr of flows)

http://conferences.sigcomm.org/sigcomm/2004/papers/p277-appenzeller1.pdf

rather than buffer = (bandwidth delay * bandwidth)

> If so would it solve the problem just replacing "T2 leaf Y" with, say,
> a Juniper MX or something else with deeper buffers?

broadcom jericho/ptx/qfx whatever sure it's plausible to have a large
buffer without using the feature rich extremely large fib asic.

> Or would it help to use (4x)10GE instead of 40GE for the links between
> the leaf and spine layers too, so there was no change in interface
> speeds along the path through the data centre towards the handoff to
> the IPT provider?

it can reduce the demand on the buffer, you can however multiplex two
our more flows that might otherwise run at 10Gb/s onto the same lag member.

> Tore
> 




signature.asc
Description: OpenPGP digital signature

Re: External BGP Controller for L3 Switch BGP routing

[joel jaeggli]

On 1/15/17 11:00 PM, Yucong Sun wrote:
> In my setup, I use an BIRD instance to combine multiple internet full
> tables,  i use some filter to generate some override route to send to my L3
> switch to do routing.  The L3 switch is configured with the default route
> to the main transit provider , if BIRD is down, the route would be
> unoptimized, but everything else remain operable until i fixed that BIRD
> instance.
> 
> I've asked around about why there isn't a L3 switch capable of handling
> full tables, I really don't understand the difference/logic behind it.

In practice there are several merchant silicon implmentations that
support the addition of external tcams. building them accordingly
increases the COGS and and various performance and packaging limitions.

arista 7280r and cisco ncs5500 are broadcom jericho based devices that
are packaged  accordingly.

Ethernet merchant silicon is heavily biased towards doing most if not
all the IO on the same asic, with limitations driven by gate size, die
size, heat dissipation pin count an so on.

There was a recent packet pushers episode with Pradeep Sindhu that
touched on some of these issues:

http://packetpushers.net/podcast/podcasts/show-315-future-networking-pradeep-sindhu/


> On Sun, Jan 15, 2017 at 10:43 PM Tore Anderson  wrote:
> 
>> Hi Saku,
>>

>> https://www.redpill-linpro.com/sysadvent/2016/12/09/slimming-routing-table.html
>>>
>>> ---
>>> As described in a prevous post, we’re testing a HPE Altoline 6920 in
>>> our lab. The Altoline 6920 is, like other switches based on the
>>> Broadcom Trident II chipset, able to handle up to 720 Gbps of
>>> throughput, packing 48x10GbE + 6x40GbE ports in a compact 1RU chassis.
>>> Its price is in all likelihood a single-digit percentage of the price
>>> of a traditional Internet router with a comparable throughput rating.
>>> ---
>>>
>>> This makes it sound like small-FIB router is single-digit percentage
>>> cost of full-FIB.
>>
>> Do you know of any traditional «Internet scale» router that can do ~720
>> Gbps of throughput for less than 10x the price of a Trident II box? Or
>> even <100kUSD? (Disregarding any volume discounts.)
>>
>>> Also having Trident in Internet facing interface may be suspect,
>>> especially if you need to go from fast interface to slow or busy
>>> interface, due to very minor packet buffers. This obviously won't be
>>> much of a problem in inside-DC traffic.
>>
>> Quite the opposite, changing between different interface speeds happens
>> very commonly inside the data centre (and most of the time it's done by
>> shallow-buffered switches using Trident II or similar chips).
>>
>> One ubiquitous configuration has the servers and any external uplinks
>> attached with 10GE to leaf switches which in turn connects to a 40GE
>> spine layer with. In this config server<->server and server<->Internet
>> packets will need to change speed twice:
>>
>> [server]-10GE-(leafX)-40GE-(spine)-40GE-(leafY)-10GE-[server/internet]
>>
>> I suppose you could for example use a couple of MX240s or something as
>> a special-purpose leaf layer for external connectivity.
>> MPC5E-40G10G-IRB or something towards the 40GE spines and any regular
>> 10GE MPC towards the exits. That way you'd only have one
>> shallow-buffered speed conversion remaining. But I'm very sceptical if
>> something like this makes sense after taking the cost/benefit ratio
>> into account.
>>
>> Tore
>>
> 




signature.asc
Description: OpenPGP digital signature

Re: Questions on IPv6 deployment

[joel jaeggli]

On 1/17/17 1:55 PM, William Herrin wrote:
> On Tue, Jan 17, 2017 at 4:07 PM, Matthew Huff  wrote:
>> The reason for allocating a /64 for a point to point link is due to various 
>> denial of service attack vectors.


if you mean allocating a /127, then... sure.

Neighbor discovery on point to point links could be a problem as is the
poential for looping behavior . There are of course ways other than
allocating a longer prefix to a point to point link to achieve that, 
e.g. disabling it. among other things You have to disable DAD anyway if
you ever plan to loop them up for testing.

these are detailed in

https://tools.ietf.org/html/rfc6164
>> Hi Matthew,
>>
>> I'm always interested in learning something new. Please explain the
>> DOS vectors you're referring to and how they're mitigated by
>> allocating a /64 to the point to point link.
>>
>>
>> Just do it.
> No. But if you offer a good reason, I'll factor your reason in to my
> considerations.
>
> Regards,
> Bill Herrin
>




signature.asc
Description: OpenPGP digital signature

Re: Passive Optical Network (PON)

[joel jaeggli]

On 1/21/17 8:44 AM, Kenneth McRae wrote:
> Greeting all,
>
> Is anyone out there using PON in a campus or facility environment?  I am 
> talking to a few vendors who are pushing PON as a replacement for edge 
> switching on the campus and in some cases, ToR switch in the DC.  Opinions on 
> this technology would be greatly appreciated.
The datacenter tor / host evironments I'm exposed to generally consider
10Gb/s or Nx10 to be the performance floor not the ceiling. To my
thinking 100gig lr4 results in a substantial reduction in
fiber/optic/port count which will in the long more than offset the
increased cost something that didn't really happen with 40gig.
> Thanks,
>
> Kenneth
>




signature.asc
Description: OpenPGP digital signature

Re: Akamai and Instagram Ranges

[joel jaeggli]

On 1/28/17 3:22 AM, Shahab Vahabzadeh wrote:
> Hello Hello,
> Can anybody help me to find out IP Address Ranges of Akamai and Instagram?
> I wanna do some optimizations on my cache side?
> Thanks
> 

Instagram should be exclusively https since 2014 or so.



signature.asc
Description: OpenPGP digital signature

Technical contact at Yahoo

[Joel Pinnow]

Sorry for the added noise, but I need to reach out to a technical contact
at Yahoo regarding incorrect geolocation on a /24 block. I've had no luck
getting in contact with anyone via WHOIS or other contact info.

Can someone from Yahoo please private email me at: jpin...@xipe.net

Thanks,
Joel

Re: IoT security

[joel jaeggli]

On 2/6/17 2:31 PM, William Herrin wrote:
> This afternoon's panel about IoT's lack of security got me thinking...
>
>
> On the issue of ISPs unable to act on insecure devices because they
> can't detect the devices until they're compromised and then only have
> the largest hammer (full account ban) to act...
>
> What about some kind of requirement or convention that upon boot and
> successful attachment to the network (and maybe once a month
> thereafter), any IoT device must _by default_ emit a UDP packet to an
> anycast address reserved for the purpose which identifies the device
> model and software build. The ISP can capture traffic to that anycast
> address, compare the data against a list of devices known to be
> defective and, if desired, respond with a fail message. If the IoT
> device receives the fail message, it must try to report the problem to
> its owner and remove its default route so that it can only communicate
> on the local lan.  The user can override the fail and if desired
> configure the device not to emit the init messages at all. But by
> default the ISP is allowed to disable the device by responding to the
> init message.
self identification is privacy hostile and tantamount to indicating a
willingness to be subverted (this is why we disable lldp on external
interfaces) even if it would otherwise be rather useful. the use of
modified eui64 addresses as part of v6 address selection hash basically
gone away for similar reasons.
> Would have to cryptographically sign the fail message and let the
> device query the signer's reputation or something like that to avoid
> the obvious security issue. Obvious privacy issues to consider.
> Anyway, throwing it out there as a potential discussion starting
> point.
>




signature.asc
Description: OpenPGP digital signature

Re: ticketmaster.com 403 Forbidden

[joel jaeggli]

On 2/6/17 8:49 AM, Suresh Ramasubramanian wrote:
> My guess is you have or had sometime in the long distant past a scalper 
> operating on your network, using automated ticket purchase bots.
>
> If you still have that scalper around, you might want to turf him.  If he’s 
> ancient history, saying so might induce them to remove the block.
Note that scalper bots benefit from pools of residential ip addresses to
work with in subverting the anti-bot countermeasures of ticket sale
platforms. so there are the legitimate possibility that subverted hosts
are being used for that sort of thing.
> --srs
>
> On 06/02/17, 8:45 AM, "nanog-boun...@nanog.org on behalf of 
> mike.l...@gmail.com"  mike.l...@gmail.com> wrote:
>
> Yup, i have a /22 that has the same problem. Support is useless...
> 
> > On Feb 6, 2017, at 08:35, Ethan E. Dee  wrote:
> > 
> > It gives me a Forbidden error.
> > It has for over a year.
> > There support says they are not allowed to me why by their policy.
> > it is across an entire /19.
> > I gave up after the fifth time and encourage the customers to call them 
> individually.
> > 
> >> On 02/06/2017 11:09 AM, Niels Bakker wrote:
> >> * charles.man...@charter.com (Manser, Charles J) [Mon 06 Feb 2017, 
> 16:21 CET]:
> >>> It seems that browsing to ticketmaster.com or any of the associated 
> IP addresses results in a 403 Forbidden for our customers today. Is anyone 
> else having this issue?
> >> 
> >> 
> http://help.ticketmaster.com/why-am-i-getting-a-blocked-forbidden-or-403-error-message/
>  
> >> 
> >> 
> >>-- Niels.
> > 
> 
>
>
>




signature.asc
Description: OpenPGP digital signature

Re: Hulu Peering

[joel jaeggli]

On 4/23/18 11:14 AM, craig washington wrote:
> Hey all,
>
>
> Just wondering if anyone peers with Hulu at any public exchange.
>
> I don't see anything on them in the peeringdb or anything that stands out 
> from a google search besides it looks like they may be doing something with 
> Equinix.
Hulu's streaming media bits come from a few CDNs.

My current cartoon network bits are coming from verizon digital media
services.
>
> Thanks
>
>
>

Re: Curiosity about AS3356 L3/CenturyLink network resiliency (in general)

[joel jaeggli]

On 5/17/18 6:24 AM, Mike Hammett wrote:
> I often question why\how people build networks the way they do. There's some 
> industry hard-on with having a few ginormous routers instead of many smaller 
> ones. I've learned that when building Internet Exchanges, the number of 
> networks that don't have BGP edge routers in major markets where they have a 
> presence is quite a bit larger than one would expect. I heard a podcast once 
> (I forget if it was Packet Pushers or Network Collective) postulating that 
> the reason why everything runs back to a few big ass routers is that someone 
> decided to spend a crap-load of money on big ass routers for bragging rights, 
> so now they have to run everything they can through them to A) "prove" their 
> purchase wasn't foolish and B) because they now can't afford to buy anything 
> else. 
There  seems to be a bit of overstatement with respect to how large
these are...

alcatel/nokia 7750 (L3's newer PE platform) is large but not outlandish
and they've been deployed for a couple years. it's relatively similar in
capacity  or a to to the devices that many of us interconnect with them
using.  Most of their customers probably though not always need less fib
then they need on a PE router.

There is a longer time-scale overhang from the choice to design of MPLS
core networks 15-20 years ago where PE routers have more to do fib wise
then do cores (which may well be larger and simpler, since most of what
they do is label switching), that drives the selection of what hardware
goes in the edge in ways than an IP only carrier might make different
choices (e.g. this big fib/queue/buffer router might have been a large
l3 switch).
> There's no reason why Tampa doesn't have a direct L3 adjacency to Miami, 
> Atlanta, Houston, and Charlotte over diverse infrastructure to all four. 
> Obviously there's room to add\drop from that list, but it gets the point 
> across. 
the number of paths available into and out a market seems somewhat
orthogonal to the number of routers.
>
>
> - 
> Mike Hammett 
> Intelligent Computing Solutions 
> http://www.ics-il.com 
>
> Midwest-IX 
> http://www.midwest-ix.com 
>
> - Original Message -
>
> From: "David Hubbard"  
> To: nanog@nanog.org 
> Sent: Wednesday, May 16, 2018 11:59:42 AM 
> Subject: Curiosity about AS3356 L3/CenturyLink network resiliency (in 
> general) 
>
> I’m curious if anyone who’s used 3356 for transit has found shortcomings in 
> how their peering and redundancy is configured, or what a normal expectation 
> to have is. The Tampa Bay market has been completely down for 3356 IP 
> services twice so far this year, each for what I’d consider an unacceptable 
> period of time (many hours). I’m learning that the entire market is served by 
> just two fiber routes, through cities hundreds of miles away in either 
> direction. So, basically two fiber cuts, potentially 1000+ miles apart, takes 
> the entire region down. The most recent occurrence was a week or so ago when 
> a Miami-area cut and an Orange, Texas cut (1287 driving miles apart) took IP 
> services down for hours. It did not take point to point circuits to out of 
> market locations down, so that suggests they even have the ability to be more 
> redundant and simply choose not to. 
>
> I feel like it’s not unreasonable to expect more redundancy, or a much 
> smaller attack surface given a disgruntled lineman who knows the routes could 
> take an entire region down with a planned cut four states apart. Maybe other 
> regions are better designed? Or are my expectations unreasonable? I carry 
> three peers in that market, so it hasn’t been outage-causing, but I use 3356 
> in other markets too, and have plans for more, but it makes me wonder if I 
> just haven't had the pleasure of similar outages elsewhere yet and I should 
> factor that expectation into the design. It creates a problem for me in one 
> location where I can only get them and Cogent, since Cogent can't be relied 
> on for IPv6 service, which I need. 
>
> Thanks 
>
>
>
>

Re: Need /24 (arin) asap

[Joel Mulkey]

A couple of suggestions on "cleanliness" checking:

-Here's a link to a quick-n-dirty Python script I made to check against a bunch 
of DNS blacklists: 
https://bigleafnetworks.box.com/s/ru1lsad2y9yom6q57bok2e3vlyxux2g5

-We once got caught after buying a "clean" block that was (unknowingly to us) 
on an old un-maintained blocklist called iblocklist. You can search that list 
here: https://www.iblocklist.com/search.php. They didn't respond to any contact 
attempts, and yet a number of carriers and hosts out there use those 
blocklists. In the end we had to re-purpose that block for internal use only 
and re-number a few customers.

Joel Mulkey
Founder and CEO
Bigleaf Networks - Cloud-first SD-WAN
www.bigleaf.net<http://www.bigleaf.net>

On Jun 11, 2018, at 7:32 AM, Stan Ouchakov 
mailto:st...@imaginesoftware.com>> wrote:

Hi Bryan and all,

Could you please recommend few places or vendors to check on cleanliness?

Thanks!

-Stan
646-827-4466


-Original Message-
From: Bryan Holloway mailto:br...@shout.net>>
Sent: Monday, June 11, 2018 10:31 AM
To: Stan Ouchakov 
mailto:st...@imaginesoftware.com>>; 
nanog@nanog.org<mailto:nanog@nanog.org>
Subject: Re: Need /24 (arin) asap

We've had good results working with Addrex.

I would still strongly recommend you do your due diligence for "cleanliness".


On 6/8/18 1:17 PM, Stan Ouchakov wrote:
Hi,

Can anyone recommend transfer market brokers for ipv4 addresses? Need clean /24 
asap. ARIN's waiting list is too long...

Thanks!


-Stan

Re: Time to add 2002::/16 to bogon filters?

[joel jaeggli]

I personally would love to see social pressure applied removing this
from the internet.

certain prominent google search results. e.g.
https://getipv6.info/display/IPv6/Linux+or+BSD+6to4+Relays probably also
could use some curation given the appropriateness of reling on a anycast
translator for your transition at this point.

On 6/18/18 2:08 PM, Job Snijders wrote:
> Dear all,
>
> TL;DR: Perhaps it is time to add 2002::/16 to our EBGP bogon filters?
>
> It is kind of strange that in the default-free zone (where we don’t
> announce defaults to each other) - we will propagate what is effectively an
> IPv4 default-route, in the IPv6 DFZ.
>
> IETF has politely abandoned the prefix:
> https://tools.ietf.org/html/rfc7526
>
> Wes George highlighted operational problems from accepting 2002::/16 on the
> data-plane slide 6:
> http://iepg.org/2018-03-18-ietf101/wes.pdf
>
> Is there still really any legit reason left to accept, or propagate,
> 2002::/16 on EBGP sessions in the DFZ?
>
> Kind regards,
>
> Job
>

Re: Time to add 2002::/16 to bogon filters?

[joel jaeggli]

On 6/18/18 6:18 PM, Jared Mauch wrote:
> I don’t believe most providers are intending to offer 6to4 as a global 
> service.  Even the large providers (eg: Comcast) seem to have disabled it ~4+ 
> years ago.  While I know there’s people on the internet that like to hang on 
> to legacy things, this is one that should end.  The networks and devices 
> today no longer require this sort of transition technology, and the networks 
> where it’s left won’t want it as it will be used for various bad things(tm).
At some point it transitions from being a legacy transition tool which
you really shouldn't be using to being an attractive nuisance, or worse
genuinely dangerous either for the sender or the receiver. personally I
think we've crossed that point and we have a responsibility to insure
proper burial.
> - Jared
>

Re: Proving Gig Speed

[joel jaeggli]

On 7/19/18 1:30 AM, Mark Tinka wrote:
>
> On 18/Jul/18 23:56, Keith Stokes wrote:
>
>> At least in the US, Jane also doesn’t really have a choice of her
>> electricity provider, so she’s not getting bombarded with advertising
>> from vendors selling “Faster WiFi” than the next guy. I don’t get to
>> choose my method of power generation and therefore cost per kWh. I’d
>> love to buy $.04 from the Pacific NW when I’m in the Southern US. 
> And that's why I suspect that 10Gbps to the home will become a reality
> not out of necessity, but out of a race on who can out-market the other.
>
> The problem for us as operators - which is what I was trying to explain
> - was that even though the home will likely not saturate that 10Gbps
> link, never mind even use 1% of it in any sustained fashion, we shall be
> left the burden of proving the "I want to see my 10Gbps that I bought,
> or I'm moving to your competitor" case over and over again.
>
> When are we going to stop feeding the monster we've created (or more
> accurately, that has been created for us)?
There is a point beyond which the network ceases to be a serious
imposition on what you are trying to do.

When it gets there, it fades into the background as a utility function.

The fact that multiple streaming audio / video applications in a
household doesn't have to routinely cheese people off point to the
threshold having been reached for the those applications at least in
fixed networks. For others it will it still be a while. When that 5GB
software update or a new purchased 25GB game takes 20 minutes to 
deliver that's a delay between intent and action that the user or
service operator might seek to minimize. Likewise, Latency or Jitter
associated with network resource contention impacts real-time
applications. When the network is sufficiently scaled / well behaved
that these applications can coexist without imposition that stops being
a point of contention.
> Mark.
>

Re: California fires: smart speakers and emergency alerts

[joel jaeggli]

On Thu, Jul 26, 2018 at 09:51:04AM -0700, Aaron C. de Bruyn via NANOG
wrote:
>
>> Capitalist solution: Build yet another IoT device that just does emergency
>> alerting.
>>
>> Someone with free time should start a kickstarter or something.  I'd
>> totally chip in.
>>
>> -A
It would be helpful if it worked when your celltower was down...

http://www.nws.noaa.gov/nwr/info/nwrsame.html

Re: tcp md5 bgp attacks?

[joel jaeggli]

On 8/14/18 2:38 PM, Randy Bush wrote:
> so we started to wonder if, since we started protecting our bgp
> sessions with md5 (in the 1990s), are there still folk trying to
> attack?
To recap for the purpose of my own edification and because hopefully
someone will relieve me of my assumptions.

The purpose of  of rfc 2385 tcp md5 digests is to keep in-window, tcp
segments that are spoofed from being ingested into the tcp stack. At the
time of it's writing (1998) some popular network operating systems did
not check  that the sequence number was in fact inside the window (so
that any tcp packet matching the 4 tupple would be ingested whether it
was in-window or not. Variously this improvement was supplemented with
the checking the TTL (https://tools.ietf.org/html/draft-gill-btsh-02),
checking whether the packet is actually in window, by ACLs that would
limit the impacts of  spoofing from off path attackers (you can't target
my multihop infracture sessions from outside my network for example),
and by filters that would limit the sort of thing you could inject into
bgp (rendering prefix hijacking moot) ).  I see broad evidence that MD5
values are extensively shared between sessions and effectively never
rekeyed (including cases where I've changed employers and the same asn
is using the same values for new peers). given the existance of
effective mitigations for the ibgp case, I've need seen a reason  to
employ it internally or to explore support for rfc 4808 mechnisms since
key rolling is effectively an external coordination problem.

Due to window checking and the ttl hack, the best vantage point for
launching an attack against a single hop ebgp sessions is as an on path
attacker (such that you would be able to identify source port and
window), layer-2 exchanges which flood unicast traffic (a hub I guess or
any public exchange with broken mac learning) would seem particularly
vulnerable since there are many on path neighbors. That is no longer a
normal topology. :/
> we were unable to find bgp mib counters.  there are igp interface
> counters, but that was not our immediate interest.  we did find
> that md5 failures are logged.
I can't quite get there either.

md5 failures I see quite a lot of, as peers that formerly have it
configured fail either temporarily or over longer timescales. md5
failures for unestablished connections aren't very interesting in this
case.

I have thousands of establish connections that last a very long time at
public exchange points, so the threat of tcp rsts to sessions is clearly
not being realized.
>
> looking at my logs for a few years, i find essentially nothing;
> two 'attackers,' one my own ibgp peer, and one that noted evildoer
> rob thomas, bgprs01.ord08.cymru.com.
>
> we would be interested in data from others.
>
> note that we are neither contemplating nor suggesting removing md5
> from [y]our bgp sessions.
>
> randy
>

Re: tcp md5 bgp attacks?

[joel jaeggli]

On 8/14/18 7:27 PM, Randy Bush wrote:
>
> < rathole >
> i am not much worried about a mesh which floods unicast.  can you even
> buy devices which support that any more?  a while back, i had to really
> dig in the closet to find one at 100mbps so i could shark mid-stream.
I'm not actually worried about it because it is rare, and not a feature,
that said, unicast flooding is in fact something we detect on exchanges
with a fair amount of frequency e.g. 2-3 a week across the exchanges
were we are present. That traffic gets discarded on our ingress but you
can count dport 179  packets in there that aren't yours. I certainly
wouldn't build a business model around gaining insight from that
information leakage (and the bulk of the traffic is whatever the
neighbor is exchanging, with someone else, from looking at mac's that
sort of thing tends to be one sided unless for example it's a whole switch).
>> I have thousands of establish connections that last a very long time
>> at public exchange points, so the threat of tcp rsts to sessions is
>> clearly not being realized.

Re: Puerto Rico Internet Exchange

[Joel Jaeggli]

> On Sep 13, 2018, at 1:27 PM, Mehmet Akcin  wrote:
> 
> It has been little over a year and we have been working on launching an 
> internet exchange in puerto rico but of course hurricane and other things got 
> in the way of achieving this.
> 
> We now have identified what we believe the right location (most of the isp’s 
> have presence in this location) backbone/ip transit connectivity, local team 
> to provide onsite support.
> 
> Having said that We have been engaged with several content delivery networks, 
> OTTs but general feedback was that Puerto Rico was not on their radar for 
> 2018 hence delayed launch. Now we are talking to same players about 2019 but 
> general answer seemed like people were satisfied enough to serve Puerto Rico 
> from Miami.
> 
> Perhaps we are talking to really big CDNs, OTTs and we should engage 
> differently however the level of interest is very low and I really don’t want 
> to “build and they will come” again ;-)
> 
> Bottom line is, if there was an IXP in Puerto Rico similar to ones in 
> Florida, I am trying to understand who would actually deploy (just speak to 
> your company only please) because most of my assumptions were proven wrong ;-)
> 
> I guess I want to ask two questions, given its location in caribbean, does 
> Puerto Rico need an internet exchange point? Would you join it?(it will be a 
> membership based IXP where members share cost)

Looking at it in my mind,  the decision point is really about how much traffic 
can be served by being there. It took a long time to recover to pre-hurricane 
levels. I would hope in the longer term that it’s a growth story and makes that 
more compelling, actually having a destination to put equipment in  and reach 
peers helps of course.

Having any anycast service, to me it looks like Puerto Rico has significant 
connectivity landing places other than Miami. Most likely due to America Movil 
MAC and PCCS or other landings in the US/BVI. We we see Puerto Rican networks 
reach us in Atlanta, DC area and even New York.


> 
> Mehmet
> 
> On Sat, Aug 12, 2017 at 4:27 AM Mehmet Akcin  > wrote:
> Hey there!
> 
> ... ok this time I am not going to call it PRIX ;) well name doesn't matter 
> really. Nearly 13 years ago I have attempted to start Puerto rico Internet 
> exchange in San Juan. I have lived there over 5 years and i just wanted to 
> really watch videos faster. The project somewhat died when i moved to LA but 
> now there are few interested party to start an internet exchange in Puerto 
> rico. The jsland historically had one of the slowest broadband/internet 
> services which seemed to have improved in recent years however as of 2017 
> there still is not an IX in Puerto rico.
> 
> We , 3-4 internet engineers (on island and remote) , want to look into 
> relaunch of this IX and hopefully find a way to keep local traffic exchanged 
> at high speeds and low cost. We need expertise, and people who want to help 
> any way they can.
> 
> We are trying to make this IX a not-for-profit one and we are looking at 
> opeeating models to adapt which has worked incredibly well like Seattle IX.
> 
> We are hoping the relaunch to happen sometime in 2018. Thanks in advance hope 
> to share more info and traffic data sometime , soon. Watch this space!
> 
> Mehmet
> --
> Mehmet
> +1-424-298-1903



signature.asc
Description: Message signed with OpenPGP

Re: NAT on a Trident/Qumran(/or other?) equipped whitebox?

[joel jaeggli]

On 10/16/18 08:55, Brandon Martin wrote:
> On 10/16/18 10:05 AM, James Bensley wrote:
>> NAT/PAT is an N:1 swapping (map) though so a state/translation table
>> is required to correctly "swap" back the return traffic. MPLS for
>> example is 1:1 mapping/action. NAT/PAT state tables tend to fill
>> quickly so to aid with this we also have timers to time out the
>> translations and free up space in the translation table, and also
>> track e.g. TCP RST or TCP FIN to remove entries from the table, so
>> it's not "just swapping".
> 
> I do wonder, though, if these popular switching ASICs are flexible
> enough in terms of their header matching and manipulation capabilities
> to handle packet mangling and forwarding in hardware for a given NAT
> state entry while punting anything that requires a state change to a CPU
> for inspection and state update.
> 
> You'd need a somewhat more powerful CPU than your typical L3 switch
> might have, but it seems like you'd still be able to offload the vast
> majority of the actual packet processing to hardware.

This is a flow cached router fundamentally. They exist. In that design
you burn your fib on flow entries rather than on nexthop routes. They
tend to explode at forwarding rates far lower than a typical ethernet
switch when their ability to accumulate new state is exercised.
riverstone RS circa 1999-2004 and various cisco products (sup 1a cat6k?)
did follow that model.

> State table size (on a typical "switching" ASIC) might be an issue
> before you could actually fill up a 10Gbps+ link with typical SP
> multi-user traffic flows, I guess, and given that a moderate-spec PC can
> keep up with 10Gbps without much issue these days, maybe it's a
> non-starter.




signature.asc
Description: OpenPGP digital signature

Re: Stupid Question maybe?

[Joel Halpern]

History of non-contiguous network masks, as I observed it.

The rules did not prohibit discontiguous network masks.  But no one was 
sure how to make them work.  In particular, how to allocate subnets from 
discontiguous networks in a sensible fashion.


In the early 90s, during the efforts to solve the swamp and classful 
exhaustion problems, Paul Francis (then Tsuchia) and I each worked out 
table structures that would allow for discontiguous masks with 
well-defined "prefixes" / "parents".  Both approaches were based on 
extensions of Knuth's Patricia trees.  (It took some interesting 
analysis and extensions.)


When we were done, other folks looked at the work (I don't know if the 
Internet Drafts are still in repositories, but they shoudl be.)  And 
concluded that while this would work, no network operations staff would 
ever be able to do it correctly.  So as a community we decided not to go 
down that path.


Yours,
Joel

On 12/18/18 5:12 PM, David Edelman wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

I seem to remember that before the advent of VLSM and CIDR there was no 
requirement for the 1 bits in the netmask to be contiguous with no intervening 
0 bits and there was always someone who tested it out on a production network 
just to prove a point (usually only once)

Dave

- -Original Message-
From: NANOG  On Behalf Of Naslund, Steve
Sent: Tuesday, December 18, 2018 3:37 PM
To: nanog@nanog.org
Subject: RE: Stupid Question maybe?

It is a matter of machine readability vs human readability.  Remember the IP 
was around when routers did not have a lot of horsepower.  The dotted decimal 
notation was a compromise between pure binary (which the equipment used) and 
human readability.  VLSM seems obvious now but in the beginning organizing 
various length routes into very expensive memory and low horsepower processors 
meant that it was much easier to break routes down along byte boundaries.  This 
meant you only had four different lengths of route to deal with.  It was 
intended to eliminate multiple passes sorting the tables.  I am not quite sure 
what you mean about interspersing zeros, that would be meaningless.  Remember 
that it is a mask.  The address bits which are masked as 1s are significant to 
routing.  The bits that are masked with 0s are the host portion and don't 
matter to the network routing table.

Steven Naslund
Chicago IL



/24 is certainly cleaner than 255.255.255.0.

I seem to remember it was Phil Karn who in the early 80's suggested that 
expressing subnet masks as the number of bits from the top end of the address word 
was efficient, since subnet masks were always a series of ones followd >by 
zeros with no interspersing, which was incorporated (or independently invented) 
about a decade later as CIDR a.b.c.d/n notation in RFC1519.
- Brian

-BEGIN PGP SIGNATURE-

iF0EARECAB0WIQQP+UHquEepll566aqXCCyZOY1FIQUCXBlw1AAKCRCXCCyZOY1F
IYkTAJ98Gh+IGhDcyIB92H9JyWtbCVDhugCfZXq60pnHCqttKfw2fpUCBagTxYo=
=RimM
-END PGP SIGNATURE-

Re: Initial ARIN IPv4 membership and resource request

[Joel Whitehouse]

On 2/6/19 2:53 PM, Nathanael Catangay Cariaga wrote:
Dear NANOG, does someone here have a breakdown of the initial ARIN fees 
/ cost assuming I'll be requesting an initial block of /22 IPv4 resource?



Regards,

-nathan



See ARIN's official fee schedule at:

https://www.arin.net/fees/fee_schedule.html

Re: Network Speed Testing and Monitoring Platform

[Joel Jaeggli]

> On Jan 16, 2019, at 08:52, Colton Conor  wrote:
> 
> As an internet service provider with many small business and residential 
> customers, our most common tech support calls are speed related. Customers 
> complaining on slow speeds, slowdowns, etc.
> 
> We have a SNMP and ping monitoring platform today, but that mainly tells us 
> up-time and if data is flowing across the interface. We can of course see the 
> link speed, but customer call in saying the are not getting that speed. 
> 
> We are looking for a way to remotely test customers internet connections 
> besides telling the customer to go to speedtest.net, or worse sending a tech 
> out with a laptop to do the same thing.

So one of the properties of customer experience of internet performance is that 
their first hop is not going to be exposed in testing from the CPE. This is one 
of the enduring motivations of internet speed tests run inside clients.

Setting aside claims about buffer bloat. Radio interfaces can have dramatic 
impact on the first hop latency that propagate to everything upstream.

> 
> What opensource and commercial options are out there? 
> 

Re: ICMPv6 "too-big" packets ignored (filtered ?) by Cloudflare farms

[Joel Jaeggli]

Sent from my iPhone

> On Mar 4, 2019, at 22:26, Mark Andrews  wrote:
> 
> 
> 
>> On 5 Mar 2019, at 5:18 pm, Mark Tinka  wrote:
>> 
>> 
>> 
>>> On 5/Mar/19 00:25, Mark Andrews wrote:
>>> 
>>> 
>>> Then Cloudflare should negotiate MSS’s that don’t generate PTB’s if
>>> they have installed broken ECMP devices.  The simplest way to do that
>>> is to set the interface MTUs to 1280 on all the servers.  Why should
>>> the rest of the world have to put up with their inability to purchase
>>> devices that work with RFC compliant data streams.
>> 
>> I've had this issue with cdnjs.cloudflare.com for the longest time at my
>> house. But as some of you may recall, my little unwanted TCP MSS hack
>> for IPv6 last weekend fixed that issue for me.
>> 
>> Not ideal, and I so wish IPv6 would work as designed, but…
> 
> It does work as designed except when crap middleware is added.  ECMP
> should be using the flow label with IPv6.  It has the advantage that
> it works for non-0-offset fragments as well as 0-offset fragments and
> also works for transports other than TCP and UDP.  This isn’t a protocol
> failure.  It is shitty implementations.

Your mobile carrier’s stateless  tcp accelerator should stop sending  acks with 
a zero flow label so we can actually identify them as part of the same flow...

There a lot of headwind in the real world for using the flow label as a hash 
component.

> 
>> Mark.
> 
> -- 
> Mark Andrews, ISC
> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> PHONE: +61 2 9871 4742  INTERNET: ma...@isc.org
> 
> 

Re: ICMPv6 "too-big" packets ignored (filtered ?) by Cloudflare farms

[Joel Jaeggli]

Sent from my iPhone

> On Mar 5, 2019, at 01:31, Saku Ytti  wrote:
> 
>> On Tue, Mar 5, 2019 at 12:26 AM Mark Andrews  wrote:
>> 
>> Then Cloudflare should negotiate MSS’s that don’t generate PTB’s if
>> they have installed broken ECMP devices.  The simplest way to do that
> 
> Out of curiosity does that imply you are aware of non-broken ECMP
> devices, which are able to hash on the embedded original packet?

Parsing the icmp payload was something we considered in  rfc7690 but wasn’t one 
the approaches we pursued (we broadcasted the ptb to all hosts on the 
segment(s) behind the load balancers in our original implementation).

It actually seems like it is becoming feasible to do in an Ethernet switch ASIC 
like tofino if that is what you want to burn real estate on. Being worthwhile 
is another matter.


> 
> -- 
>  ++ytti
> 

Re: How threading works (was Re: Root Cause Re: 202401102221.AYC Re: Streamline The CG-NAT Re: 202401100645.AYC Re: IPv4 address block)

[Joel Esler]

Things you have to remember.  Not everyone uses thunderbird.  Not every mail client threads like thunderbird.  — Sent from my iPhoneOn Jan 13, 2024, at 17:39, Abraham Y. Chen  wrote:

  

  
  
Hi, Bryan:

  
0)    Thank you so much
for coming to the rescue!!! 
  

  
1)    Basically trained
as a radio frequency hardware engineer, I am only capable of
using software as tools necessary for my work. For eMail, I have
been using ThunderBird ever since its beginning. With my own
time-stamping Subject line discipline, I never needed its
threading function. When I received complaints last year, I
experimented threading on it and found that it was doing just
fine. Whether I prefixed or suffixed the timestamps to the
Subject line could not break it. I requested counter examples
from those who were having difficulties with my MSGs, but
received none. Frustrated but not able to do anything, I went
back to continue my EzIP work, leaving this subject in the back
burner of my mind. This time around, the problem popped up again
in the midst of large number of MSG exchanges. I am so relieved
that you presented the threading on the NANOG eMail server that
mirrors what I saw on my own PC. So, we now have a common
reference for everyone to look at this phenomenon. (Why no one else knew about this facility?) 
  

  
2)    From the Wikipedia
explanation of RFC5822, I as a ThunderBird user, really have
nothing to do with the Message-ID that it puts on my MSGs nor
how does it make use of such to display the threads. And, my
Subject line style can't affect it either. So, why some
colleagues are having difficulties with just my eMails, but
seemly not from others? Could this be caused by the large number
of MSGs within a short period of time that amplified this issue?
From another feedback, I realized that some colleagues may be
using plain text text editors or alike for eMail, because they
could not see color nor italic emphasizing of my text. Could
such be related to this issue?
  

  
I would appreciate very
much if you could advance my education with some explanations
after perhaps discussions with those offended by my MSGs. 
  


Regards,

  

  
Abe (2024-01-13 17:37)



 







On
  1/12/24 3:04 PM, Mu wrote: 
  Would it be possible for you to reply
in-thread, rather than creating a new thread with a new subject
line every time you reply to someone? 

Trying to follow the conversation becomes very difficult for no
reason. 
  
  
  Threading has nothing to do with subject lines.  RFC822 (now 5822)
  specifies how this works based on message ID.  This thread
  displays fine in threaded mode in my MUA and in the archives. 
  
  https://en.wikipedia.org/wiki/Conversation_threading
  
  https://mailman.nanog.org/pipermail/nanog/2024-January/thread.html
  
  
  If people could please reply to threads properly, inline and
  trimming non relevant text, it would make following discussion
  much easier. 
  



  Virus-free.www.avast.com 

Re: Any info on AT&T Wireless Outage?

[Joel Esler]

/me waves my hand dismissingly— Sent from my iPhoneOn Feb 29, 2024, at 14:55, Javier J  wrote:Where did you see this? Erik Prince was on the PBD podcast saying he has a 70% chance in his head it was China. I tend to learn towards human error from my experience in the IT biz.- JOn Wed, Feb 28, 2024 at 10:58 AM  wrote:I read it as “someone pushed an ACL that wasn’t properly reviewed and it really screwed things up."On Feb 27, 2024, at 21:41, Mark Seiden  wrote:aside from the official pablum that was released about an “incorrect process used”(which says exactly nothing) does anyone actually know anything accurate and more specific about the root cause?(and why it took 11 hours to recover?)On Feb 22, 2024, at 11:15 AM, John Councilman  wrote:From what I've read, they lost their database of SIM cards.  I could be wrong of course.On Thu, Feb 22, 2024 at 2:02 PM Dorn Hetzel  wrote:As widespread as it seemed to be, it feels like it would be quite a trick if it were a single piece of hardware.  Firmware load that ended badly, I wonder?On Thu, Feb 22, 2024 at 1:51 PM Leato, Gary via NANOG  wrote:






Do you have the ability to expand on this at all? Do you mean a hardware failure of some kind IE router, optitcs, etc? 

From: NANOG advance-trading@nanog.org>
On Behalf Of R. Leigh Hennig
Sent: Thursday, February 22, 2024 8:17 AM
To: Robert DeVita 
Cc: nanog@nanog.org
Subject: Re: Any info on AT&T Wireless Outage?

 Word around the campfire is that it’s a Cisco issue.




On Feb 22, 2024, at 8:03 AM, Robert DeVita  wrote:
 

Reports have it starting at 4:30 a.m.. SOS on all phones..

 

 

 


















Robert DeVita









CEO and Founder

















t: (469) 581-2160



 | 



m: (469) 441-8864

















e: radev...@mejeticks.com



 | 



w: mejeticks.com













a: 







2323 N Akard Street



, 



Dallas



, 



75201




















































































 



The risk of trading futures and options can be substantial. All information, publications, and material used and distributed by Advance Trading Inc. shall be construed as a solicitation. ATI does not maintain an independent research department as defined in
 CFTC Regulation 1.71. Information obtained from third-party sources is believed to be reliable, but its accuracy is not guaranteed by Advance Trading Inc. Past performance is not necessarily indicative of future results.

Re: Best TAC Services from Equipment Vendors

[Joel Esler]

It may be a pain in the butt to get Cisco equipment, but their TAC is sublime.  If something is critical enough, and you push hard enough, Cisco will move heaven and earth to solve your issue.  — Sent from my iPhoneOn Mar 6, 2024, at 13:42, Pascal Masha  wrote:For us this has been the experience to a point where 100s of nodes( from vendor x) had to be swapped out because no one had the patience anymore…On Wed, 6 Mar 2024 at 21:29,  wrote:Interesting, this has never been my experience even with Cisco or Juniper, have always been able to escalate quickly to engineering. I wonder if it was related to the size of my accounts.

Shane

> On Mar 6, 2024, at 1:27 PM, Pascal Masha  wrote:
> 
> Thought about it but so far I believe companies from China provide better and fast TAC responses to their customers than the likes of Cisco and perhaps that’s why some companies(where there are no restrictions)prefer them for critical services. 
> 
> For a short period in TAC call you can have over 10 R&D engineers and solutions provided in a matter of hours even if it involves software changes.. while these other companies even before you get in a call with a TAC engineer it’s hours and when they join you hear something like “my shift ended 15 minutes ago, hold let me look for another engineer”. WHY? Thoughts

Re: Current diameter of the Internet?

[joel jaeggli]

On 7/19/24 15:07, Sean Donelan wrote:


What is the current estimated diameter of the Internet?

Maximum (worst-case) RTT edge-to-edge?

Most public latency data is now edge-to-cloud, not edge-to-edge. Cloud 
engineers have done a great job, and edge-to-cloud less than 1-sec RTT.


Where have the long-slow pipes gone?

https://www.cloudping.co/grid

https://learn.microsoft.com/en-us/azure/networking/azure-network-latency?tabs=Americas%2CWestUS 



https://www.verizon.com/business/terms/latency/



The RTT across geostationary satellites has remained stubbornly constant 
we just don't use them unless there's no other alternative. A colleague 
sent me a trace the other day while flying from hawaii to los vegas that 
was otherwise performant but still incurs the overhead.