Re: constant FEC errors juniper mpc10e 400g

[Joel Busch via NANOG]

In my reading the 400GBASE-R Physical Coding Sublayer (PCS) always 
includes the FEC. This is defined in clause 119 of IEEE Std 802.3-2022, 
and most easily seen in "Figure 119–2—Functional block diagram" if you 
don't want to get buried in the prose. Nothing there seems to imply that 
the FEC is optional.


I'd be happy to be corrected though. It may well be that there is a 
method to reading these tomes, that I have not discovered yet. It is the 
first time I dove deep into any IEEE standard.


Best regards
Joel

On 17.04.2024 21:47, Tom Beecher wrote:

Isn't FEC required by the 400G spec?

On Wed, Apr 17, 2024 at 3:45 PM Aaron Gould <mailto:aar...@gvtc.com>> wrote:


__

i did.  Usually my NANOG and J-NSP email list gets me a quicker
solution than JTAC.

-Aaron

On 4/17/2024 2:37 PM, Dominik Dobrowolski wrote:

Open a JTAC case,
That looks like a work for them


Kind Regards,
Dominik

W dniu śr., 17.04.2024 o 21:36 Aaron Gould mailto:aar...@gvtc.com>> napisał(a):

We recently added MPC10E-15C-MRATE cards to our MX960's to upgrade our 
core to 400g.  During initial testing of the 400g interface (400GBASE-FR4), I 
see constant FEC errors.  FEC is new to me.  Anyone know why this is occurring? 
 Shown below, is an interface with no traffic, but seeing constant FEC errors.  
This is (2) MX960's cabled directly, no dwdm or anything between them... just a 
fiber patch cable.



{master}
me@mx960> clear interfaces statistics et-7/1/4

{master}
me@mx960> show interfaces et-7/1/4 | grep rror | refresh 2
---(refreshed at 2024-04-17 14:18:53 CDT)---
   Link-level type: Ethernet, MTU: 1514, MRU: 1522, Speed: 400Gbps, 
BPDU Error: None, Loop Detect PDU Error: None, Loopback: Disabled, Source 
filtering: Disabled,
 Bit errors 0
 Errored blocks 0
   Ethernet FEC statistics  Errors
 FEC Corrected Errors0
 FEC Uncorrected Errors  0
 FEC Corrected Errors Rate   0
 FEC Uncorrected Errors Rate 0
---(refreshed at 2024-04-17 14:18:55 CDT)---
   Link-level type: Ethernet, MTU: 1514, MRU: 1522, Speed: 400Gbps, 
BPDU Error: None, Loop Detect PDU Error: None, Loopback: Disabled, Source 
filtering: Disabled,
 Bit errors 0
 Errored blocks 0
   Ethernet FEC statistics  Errors
 FEC Corrected Errors 4302
 FEC Uncorrected Errors  0
 FEC Corrected Errors Rate   8
 FEC Uncorrected Errors Rate 0
---(refreshed at 2024-04-17 14:18:57 CDT)---
   Link-level type: Ethernet, MTU: 1514, MRU: 1522, Speed: 400Gbps, 
BPDU Error: None, Loop Detect PDU Error: None, Loopback: Disabled, Source 
filtering: Disabled,
 Bit errors 0
 Errored blocks 0
   Ethernet FEC statistics  Errors
 FEC Corrected Errors 8796
 FEC Uncorrected Errors  0
 FEC Corrected Errors Rate 146
 FEC Uncorrected Errors Rate 0
---(refreshed at 2024-04-17 14:18:59 CDT)---
   Link-level type: Ethernet, MTU: 1514, MRU: 1522, Speed: 400Gbps, 
BPDU Error: None, Loop Detect PDU Error: None, Loopback: Disabled, Source 
filtering: Disabled,
 Bit errors 0
 Errored blocks 0
   Ethernet FEC statistics  Errors
 FEC Corrected Errors15582
 FEC Uncorrected Errors  0
 FEC Corrected Errors Rate 111
 FEC Uncorrected Errors Rate 0
---(refreshed at 2024-04-17 14:19:01 CDT)---
   Link-level type: Ethernet, MTU: 1514, MRU: 1522, Speed: 400Gbps, 
BPDU Error: None, Loop Detect PDU Error: None, Loopback: Disabled, Source 
filtering: Disabled,
 Bit errors 0
 Errored blocks 0
   Ethernet FEC statistics  Errors
 FEC Corrected Errors20342
 FEC Uncorrected Errors  0
 FEC Corrected Errors Rate 256
 FEC Uncorrected Errors Rate 0

{master}
me@mx960> show interfaces et-7/1/4 | grep "put rate"
   Input rate : 0 bps (0 pps)
   Output rate: 0 bps (0 pps)

{master}
me@mx960> show interfaces et-7/1/4
Physical interface: et-7/1/4, Enabled, Physical link is Up
   

Re: Unimus as NCM (Network Configuration Management) Tool

[Joel Busch via NANOG]

On 04.04.2024 09:06, Mark Tinka wrote:
RANCID works perfectly for Cisco, Juniper, Arista, Brocade (Foundry) and 
HP.


They are also known to support other obscure vendors.


Can confirm for Cisco.

We use it for ECI (now Ribbon) gear as well, just with our local 
modifications. We copied the Juniper scripts and modified them to not 
set some CLI states and to adapt the commands that are run. It's not 
that complicated to modify.


Joel Busch
AS559 SWITCH

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: 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 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 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 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: Any info on AT 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 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: Any info on AT 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 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: 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: 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: 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: 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: 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: 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: 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

Searchable archives of the list?

[Joel M Snyder]

This seems an absurd question but … “where are the searchable archives of this 
list?”  I have found an innumerable set of archives and copies of archives 
broken into months, but I cannot find a way to search the content of the list 
archive (short of downloading the archives and grepping from there). 

Is there a searchable archive someplace maintained by nanog?  And if so… how 
about updating the nanog web pages about this list with a pointer? 

And finally, the question I was searching to avoid asking on the list: does 
anyone have any experience, good or bad, with leasing out unused IPv4 space 
through ipway?

Thanks, 


jms
---
Joel M Snyder - Opus One - j...@opus1.com

Re: 202212160543.AYC Re: eMail Conventions

[Joel Esler via NANOG]

> On Dec 16, 2022, at 12:04 PM, ic  wrote:
> 
> Hi there,
> 
>> On 16 Dec 2022, at 17:13, William Herrin > > wrote:
>> 
>> Most email clients assume that a change to the subject line (other
>> than adding "Re:" to the front) indicates that the sender wants to
>> discuss a new topic related to but meaningly different from the last.
> 
> Although I generally agree that changing the Subject line without reason is 
> an annoyance, I didn’t notice any issue with it until I came across this 
> thread, which wasn’t broken in my mail client (Apple’s Mail.app).

As a user of Mail.app as well, it is not broken for me either.  However, reason 
being — Mail does not use just the subject to thread.  I used to nerd out about 
email (top + bottom posting, etc) so the details of how Apple Mail threads have 
been lost in my ADHD riddled brain, but — that’s why.

> 
> This led me to a few tests, and FWIW even Mutt seems happy with the Subject 
> changing and still threads the emails appropriately.
> 
> In my experience, threading is done by clients looking for the In-Reply-To: 
> header, not subject. Subject is a heuristic fallback, in case In-Reply-To is 
> absent.
> 
> Some email clients (although I don’t remember which ones) remove In-Reply-To: 
> when the Subject: is changed (that might go as far back as my Gnus Oort days).
> 

…. and now that I wrote the above email response, I think you’re right.  
In-Reply-To:  I believe, is how Mail.app does it. (And several others)

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: 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: 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

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: What say you, nanog re: Starlink vs 5G?

[Joel Esler via NANOG]

> On Jun 24, 2022, at 3:38 PM, Owen DeLong via NANOG  wrote:
> 
> It’s not entirely clear, without knowing the technical details of the 
> Starlink modulation scheme whether or not they could successfully share the 
> 12Ghz spectrum.
> 
> I have no reason to disbelieve their claims.


Exactly.  Why would they lie?

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

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: 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: Flow collection and analysis

[Joel Esler via NANOG]

Are you asking for commercial solutions?  Free solutions?  Open Source?

> On Jan 25, 2022, at 10:46 AM, David Bass  wrote:
> 
> Wondering what others in the small to medium sized networks out there are 
> using these days for netflow data collection, and your opinion on the tool?
> 
> Thanks!

Re: Coverage of the .to internet outage

[Joel M Snyder]

Got an Intelsat press release which may be of interest to folks 
following the situation in Tonga.  I wish I could include just a URL, 
but they sent it to be as text so I am including the full thing:

---
FOR IMMEDIATE RELEASE: January 21, 2022

Intelsat and Partners Bring Emergency Connectivity to Tonga

McLean, Va. – Intelsat, operator of the world’s largest integrated 
satellite and terrestrial network, in cooperation with Telstra and Spark 
deployed emergency communications services to support humanitarian aid 
to Tonga and the archipelago for Digicel Tonga and Tonga Communications 
Corporation.


The undersea volcano, Hunga-Tonga-Hunga-Ha’apai, erupted on Jan. 15, 40 
miles north of Tonga’s capital, Nuku’alofa. The volcanic explosion and 
subsequent tsunami knocked out the undersea internet cables, 
disconnecting the region of 100,000 as residents sought higher ground 
with the onslaught of rising water and dangerously high waves.


Intelsat is providing space-based broadband connectivity on Horizons 3e 
and Intelsat 18, while partners, Telstra and Spark, are providing the 
ground infrastructure, including VSAT hubs at their teleports, uplink, 
internet access and remote kits.


The services provided are now fully provisioned expanding broadband and 
voice services.


Additionally, Intelsat is providing services in conjunction with Optus 
to the New Zealand Defence Force, who will provide humanitarian support 
in Tonga.


“Communications infrastructure is essential to assisting the residents, 
coordinating medical staff and providing supplies, clean food and water 
and basic human needs,” said Intelsat CEO Stephen Spengler. “Our hearts 
go out to the residents of Tonga and all impacted by this devastation, 
and we’re working with our partners to play a role in supporting the 
community in their time of need.”


Intelsat’s swift response is a testament to its communications 
infrastructure over the Pacific Islands, operational efficiencies, and 
longstanding commitment to serving the region. It is the quintessential 
demonstration of satellite solutions’ near-instantaneous communications 
activation in areas where disasters have crippled terrestrial networks.


In 2019, Tonga lost internet access for nearly two weeks when a 
fiber-optic cable was severed. Intelsat played a significant role in 
restoring the island's restoration connectivity by providing satellite 
capacity on Horizons 3e and Intelsat18 at that time.


--
Joel M Snyder, 1404 East Lind Road, Tucson, AZ, 85719
Senior Partner, Opus One   Phone: +1 520 324 0494
j...@opus1.comhttp://www.opus1.com/jms

Re: OpenDNS contact

[Joel Esler via NANOG]

Tell your friend to head over to talosintelligence.com/support and file a 
dispute.  


— 
Sent from my  iPad

> On Nov 19, 2021, at 08:41, Mark Costlow  wrote:
> 
> Does anyone have a contact within OpenDNS?  A friend's business is in
> extreme pain because a false-positive blacklisting and he hasn't been
> able to find a human to appeal to.
> 
> The source of the bad initial report has retracted it and the usual "remove
> me from this blacklist" form has been filled out, but they're still hurting.
> 
> Thanks,
> 
> Mark
> -- 
> Mark Costlow| Southwest Cyberport | Fax:   +1-505-232-7975
> che...@swcp.com | Web:   www.swcp.com | Voice: +1-505-232-7992

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: 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: 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: DMVPN via Internet or Private APN

[Joel M Snyder]

I offer a question to help me settle an internal debate. As a network
engineer for a large enterprise, do you choose ISP flexibility or ISP
security when you build an OOB network? 


Flexibility.  (will not joke about immense problem of including the 
words "ISP" and "security" in same sentence, unless accompanied by the 
phrase "complete and total absence of" as well)


My particular area of concentration the last decade or so has been large 
multi-national WANs.  I've been fortunate enough to see entire waves of 
deployment and redeployment, which has added a thick layer of scarring.


One of the lessons that I take away from these deployments is that 
anything which is not pure "Internet" IP must be avoided, because if it 
doesn't bite you in the *ss on day 1, it will on day 1,000 or 10,000.


Providers love to deliver a customized service, and in small deployments 
(such as connecting offices within a metropolitan area) I can see the 
value.  But whether the provider is creating lock-in (sinister 
conspiracy theory) or just wants to give you a better service 
(optimistic world view theory), it *always* ends up being a problem 
sooner or later.


I can pull a dozen anecdotes out where this happened and cost between $ 
and  to deal with, but my long-term experience is that the more 
vanilla the pipe, the better off you will be in the long run especially 
as the clock ticks past years and years.


There are certainly issues with having multiple contracts, and the 
overhead of handling hundreds of semi-overlapping and slightly different 
bills and contact points is not to be dismissed lightly; it is a BIG 
deal especially for larger organizations with high internal costs for 
administrative overhead.  Providers also claim better pricing on big 
contracts, but rarely is this true, because of the sharp and continuous 
drop in costs for Internet worldwide.


Go with vanilla.  It's easier to pour syrup and nuts on top than it is 
to dig out those disgusting frozen marshmallow chunks from the rocky 
road someone committed to.



jms

--
Joel M Snyder, 1404 East Lind Road, Tucson, AZ, 85719
Senior Partner, Opus One   Phone: +1 520 324 0494
j...@opus1.comhttp://www.opus1.com/jms

Re: 60ms cross continent

[Joel M Snyder]

On Jul 8, 2020, at 3:05 AM, Mark Tinka  wrote:

>Satellite earth stations are not irrelevant, however. They still do get
>used to provide satellite-based TV services, and can also be used for
>media houses who need to hook up to their network to broadcast video
>when reporting in the region (even though uploading a raw file back
>home over the Internet is where the tech. has now gone).

Oh man I wish that were wholly true... Satellite/VSAT has another very
very important attribute: it's not subject to the whims of the local
government or regulators.  So when there's an election or some unrest or
coup or the prime minister has very bad flatulence, and some person says
"turn off the Internet," your non-terrestrial connection is there so
that you can continue to do business.

Right now I'm in the middle of a project installing more than 300 VSATs,
replacing an incumbent provider, and the rationale for all that money
and all that equipment and all that work is "the bits must flow."

(Plus, there are also still many places outside of capital cities in the
world where the Internet is truly awful and if you want bits, you have
to bring your own)

jms

-- 
Joel M Snyder, 1404 East Lind Road, Tucson, AZ, 85719
Senior Partner, Opus One   Phone: +1 520 324 0494
j...@opus1.comhttp://www.opus1.com/jms

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/
> 

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: 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: 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: 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: 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: 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: 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: 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: 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: 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: Colo in Africa

[Joel M Snyder]

Ken:

>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?

Africa is a tough nut to crack.  I have been building networks there for 
clients for decades and the first thing to understand is that Africa is 
BIG.  Geographically, you can fit the US, Europe, and Canada (and have 
room to spare).  Typical Mercator maps make it look much smaller than it 
really is.  Anyway, my point here is that you should not be thinking 
about Africa as "a region" or "a continent."


When a lot of people say "Africa," they really mean "South Africa" (the 
small country), and there is great connectivity there---but positioning 
yourself in South Africa doesn't really help you any more to get to 
Ghana (for example) than being in the Netherlands.


If you really are thinking AFRICA as in AFRICA, you probably should use 
an approach that divides it into regions.  You can break it up however 
you want, but if you start with 4 regions (Southern, Northern, Western, 
Eastern/Central) you'll have chunks that actually hold together from a 
telecoms point of view pretty well.


My best experiences (and these are about 3 years out of date) have been 
in Jo'burg (Southern), Nairobi/Addis (Eastern/Central), Ghana (Western), 
and Egypt (Northern), but there is a lot of interest and a lot of 
progress so getting some ground knowledge would be a good idea.


The real bandwidth is submarine cables that go up and down the coasts 
--- you can find some maps of these of varying accuracy and quality --- 
while actual E/W and N/S connectivity in the center of the continent is 
much more limited.


There are a number of Internet-promoting organizations in Africa---you 
can start with ISOC and Afrinic that sponsor a number of projects aimed 
at increasing capacity there, but you'll find a bunch of people trying 
to do good things.  If you are mostly interested in South Africa, 
there's NAPAfrica and SAFNOG (Southern African equivalent of NANOG) as 
information sources.


Anyway: I can get more specific, but it's hard to really offer 
super-specific advice on a vague question because, you know, Africa. 
That's a big topic.


jms


--
Joel M Snyder, 1404 East Lind Road, Tucson, AZ, 85719
Senior Partner, Opus One   Phone: +1 520 324 0494
j...@opus1.comhttp://www.opus1.com/jms

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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: Catalyst 4500 listening on TCP 6154 on all interfaces

[Spaans, Joel H]

This has not been my experience. TAC specifically has an option when opening a 
case to "Ask a question". It's purpose is for non-outage queries such as these. 
I've asked them things such as "How many ARP entries does an ASA 5585X 
support?" Sometimes I find conflicting information so I need to ask TAC or I'm 
just too busy to find the answer. 

I've learned not to be hesitant to engage them, we pay for the support after 
all. 

Yes, sometimes you will get an engineer who is not helpful. Let them close the 
case and open another case or insist that the case be moved to another 
engineer. 

-Original Message-
From: NANOG  On Behalf Of 
frederic.jut...@sig-telecom.net
Sent: Monday, May 7, 2018 10:45 AM
To: Jay Farrell ; nanog@nanog.org
Subject: Re: Catalyst 4500 listening on TCP 6154 on all interfaces

I've been told that the TAC center will not take the time to answer as it's not 
a 'real' problem, service affecting issue.
And the Cisco community forum on that topic was useless (nobody answer to a 
person which already open a topic about this issue 10 months ago).
But you are the 4rd person to tell me to open a TAC, I could have tried first.
In the meantime Cisco contact me off-list, so I will try with them.




On 07.05.2018 16:59, Jay Farrell via NANOG wrote:
> Just a wild thought – why not open a TAC case with Cisco and ask them?
>
> On Mon, May 7, 2018 at 3:06 AM, frederic.jut...@sig-telecom.net < 
> frederic.jut...@sig-telecom.net> wrote:
>
>>> - a nsa backdoor :-)
>> it would be a very bad backdoor as it's really easy to see the port 
>> listening...
>>
>>
>>> - a default active service
>> Maybe, but a service which is not officially registered:
>> https://www.iana.org/assignments/service-names-port-numbers/service-n
>> ames-
>> port-numbers.xhtml?search=6154
>>
>> in contrary to the SMI (zero touch feature on tcp 4786) which is 
>> registered since almost 10y:
>> https://www.iana.org/assignments/service-names-port-numbers/service-n
>> ames-
>> port-numbers.xhtml?search=4786
>>
>>
>>
>> Could it be possible that this kind of tcp port is not registered by 
>> Iana because it meant to be used for internal communication only 
>> (internal to the device), or should you register any port usage (even
>> 'private') ?
>>
>>
>> And yes I've tried to reset to default the config, shutdown all 
>> interface, remove all L3 ip/feature (no ip blabla), and I still see 
>> by default 2 TCP ports on listening state:
>>
>> Cat4500-SUP7L-E#sh ip prot
>> *** IP Routing is NSF aware ***
>>
>> Cat4500-SUP7L-E#
>> Cat4500-SUP7L-E#sh run | in ip
>>  address-family ipv4
>>  address-family ipv6
>> no ip routing
>> ip vrf Liin-vrf
>> no ip mfib
>> no ip bootp server
>> no ip dhcp-client broadcast-flag
>> no ip igmp snooping
>> no ipv6 traffic interface-statistics
>>  no ip address
>>  no ip route-cache
>>  no ip address
>>  no ip route-cache
>> no ip forward-protocol nd
>> no ip http server
>> no ip http secure-server
>> Cat4500-SUP7L-E#
>> Cat4500-SUP7L-E#
>> Cat4500-SUP7L-E#show tcp br all
>> TCB   Local Address   Foreign Address (state)
>> 5B40BB30  0.0.0.0.4786   *.* LISTEN
>> 5CD5D2D8  0.0.0.0.6154   *.* LISTEN
>> Cat4500-SUP7L-E#
>>
>>
>>
>> I will now try to negate all potential active service from the 'show 
>> run all' config but it's not optimal as for example 'vstack' (port 
>> 4786) does not appear in the default config so it would not be 
>> disable by this trivial method.
>>
>>
>> Fred
>>
>>
>> On 05.05.2018 13:22, marcel.durega...@yahoo.fr wrote:
>>> As the zero touch feature is on TCP 4786 (SMI), I vote for either:
>>>
>>> - a nsa backdoor :-)
>>> - a default active service
>>>
>>> Have you tried to zeroize the config and restart then check if TCP 
>>> 6154 is still on LISTEN state ?
>>>
>>>
>>> -
>>> Marcel
>>>
>>>
>>>
>>> On 03.05.2018 06:51, frederic.jut...@sig-telecom.net wrote:
 Hi,

 We have Cat 4500 series on SUP7L-E with IOS/XE 03.06.02.E/152(2).E2 
 which have TCP port 6154 listening on all interfaces.

 Any idea what it could be ?

 #show tcp brief all
 TCB   Local Address   Foreign Address
>>  (state)
 ...
 5A529430  0.0.0.0.6154


 #show tcp tcb 5A529430
 Connection state is LISTEN, I/O status: 1, unread input bytes: 0 
 Connection is ECN Disabled, Mininum incoming TTL 0, Outgoing TTL 
 255 Local host: 0.0.0.0, Local port: 6154 Foreign host: UNKNOWN, 
 Foreign port: 0 Connection tableid (VRF): 1 Maximum output segment 
 queue size: 50

 Enqueued packets for retransmit: 0, input: 0  mis-ordered: 0 (0 
 bytes)

 Event Timers (current time is 0xF58354):
 Timer  StartsWakeupsNext
 Retrans 0  0 0x0
 TimeWait0  0 0x0
 

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: Are any of you starting to get AI robocalls?

[joel jaeggli]

On 4/3/18 3:32 PM, William Herrin wrote:
> Howdy.
>
> Have any of you started to get AI robocalls? I've had a couple of
> calls recently where I get the connect silence of a predictive dialer
> followed by a woman speaking with call center background noise. She
> gives her name and asks how I'm doing. The first time it happened it
> seemed off for reasons I can't quite articulate, so I asked: "Are you
> a robot or a person?" She responded "yes" and then launched in to a
> sales pitch. The next time I asked, "where can I direct your call?"
> She responded "that's good" and launched in to her pitch.
They're more in the domain of artificially stupid but yes.

https://www.theverge.com/2018/1/1/16837814/robocall-spam-phone-call-increase-2017-ftc-report

The anti spoofing/spam app I have that screens calls to several DIDs I
have pointed at one phone reports a dozen or so calls per day.

I would generally assume that the current rate will hasten the demise of
the remaining pots services.
> Regards,
> Bill Herrin
>
>

Re: Yet another Quadruple DNS?

[joel jaeggli]

On 3/29/18 10:59 AM, Stephen Satchell wrote:
> In regards to: spoofing DNS to 8.8.8.8 et al
>
> On 03/29/2018 09:26 AM, Baldur Norddahl wrote:
>> Running your own resolver will not work.
>
> Why won't it work?  I run a Linux box with BIND 9 set up as a
> recursive resolver.  Are you saying that the rogues will also capture
> requests to the root DNS servers, as described in the hints file?
All destination port 53 udp packets.

Re: IPv6 Unique Local Addresses

[Joel Whitehouse]

On 03/02/2018 02:40 PM, Matthew Kaufman wrote:

Exactly what Matt Harris says here... ULA is free. Space obtained from ARIN
is not. You want to discourage someone from doing the right thing, charge a
lot for that.



The ARIN fee schedule for an ASN and a /40 has an amortized annual cost 
approximately equal to a 2TB hard drive.  Is that really too much to 
bear for a business running a critical network service?


--
Joel Whitehouse

Re: BCP 38 addendum

[joel jaeggli]

On 3/1/18 10:57 AM, Todd Crane wrote:
> Question:
> Since we cannot count on everyone to follow BCP 38 or investigate their 
> abuse@, I was thinking about the feasibility of using filtering to prevent 
> spoofing from peers’ networks.
>
> With the exception of a few edge cases, would it be possible to filter 
> inbound traffic allowing only packets with source addresses matching the 
> peer’s BGP announcement?  Theoretically it should be a two way street to any 
> address I can receive from, thus if I can’t send to it, I shouldn't be 
> receiving from it. I realize this is not currently a feature of any router 
> (to my knowledge), but could it be implemented into some NOSs fairly easily 
> and jerry-rigged into others for the time being.
you can build ACLs from IRR objects  just like you can build prefix
lists. for customers this is just as feasible as controlling what routes
you accept from them.

unlike URPF strict  this will not cause an outage every time a prefix is
withdrawn but traffic continues to flow (which is a normal and healthy
part of doing maintenance).

on the other hand it means your prefix lists will have to be rather up
to date and your peers will likely have to be very up to date with their
customers. since failures for inclusion will cause black holes.

you can't do this on on and MLPE exchange where you export routes unless
you want to cause an outage everytime a new peer is added.

there is also the problem of the number of cam slots these IP acls chew up.

bgpq3 -P AS-FOO
> This would allow us to peer with OVH et al, and not worry as much. 
> Furthermore, whereas BCP 38 is reliant upon everybody, this could 
> significantly reduce amplification attacks with even just a handful of 
> adopters.
The source addresses of attack traffic associated with for example
memcached (and in fact virtually all reflection attacks) are not spoofed.
>
> —Todd
>
>> On Feb 28, 2018, at 6:52 PM, Job Snijders  wrote:
>>
>> On Tue, Feb 27, 2018 at 09:52:54PM +, Chip Marshall wrote:
>>> On 2018-02-27, Ca By  sent:
 Please do take a look at the cloudflare blog specifically as they
 name and shame OVH and Digital Ocean for being the primary sources
 of mega crap traffic

 https://blog.cloudflare.com/memcrashed-major-amplification-attacks-from-port-11211/

 Also, policer all UDP all the time... UDP is unsafe at any speed.
>>> Hi, DigitalOcean here. We've taken steps to mitigate this attack on
>>> our network.
>> NTT too has deployed rate limiters on all external facing interfaces on
>> the GIN backbone - for UDP/11211 traffic - to dampen the negative impact
>> of open memcached instances on peers and customers.
>>
>> The toxic combination of 'one spoofed packet can yield multiple reponse
>> packets' and 'one small packet can yield a very big response' makes the
>> memcached UDP protocol a fine example of double trouble with potential
>> for severe operational impact.
>>
>> Kind regards,
>>
>> Job




signature.asc
Description: OpenPGP digital signature

Re: MTU to CDN's

[joel jaeggli]

On 1/8/18 2:55 PM, Dovid Bender wrote:

> Hi,
>
> N00b here trying to understand why certain CDN's such as Cloudfare have
> issues where my MTU is low. For instance if I am using pptp and the MTU is
> at 1300 it wont work. If I increase to 1478 it may or may not work.
PMTUD has a lot of trouble working reliability when the destination of
the PTB  is a stateless load-balancer.

If your tunnel or host clamps the mss  to the appropriate value it can
support. it is highly likely that connection attempts to the same
destination will work fine.
> TIA.
>

Re: Any experience with FS hardware out there?

[joel jaeggli]

On 1/5/18 10:50 AM, Bryan Holloway wrote:
Fiberstore is rolling out some CRAZY cheap 100Gbps switches, and I'm 
curious if anyone in the community has any thoughts or real-life world 
experience with them.


E.g.: https://www.fs.com/products/69340.html

For the price point, it's almost in the "too good to be true" category.
The COGS on a single ASIC tomahawk switch was is in $5000-7000 range. so 
it's consistent with a low value add reseller of merchant silicon. that 
silicon is getting older (tomahawk 3 was announced in anticipation of 
2018) so we can presume they are getting cheaper. I generally have a 
favorable experience of FS but then I buy optics and cables, not 
switches so your mileage may vary.


Naturally it claims to support an impressive range of features 
including BGP, IS-IS, OSPF, MPLS, VRFs, blah blah blah.
The software stack is Broadcom ICOS. if you're not familiar with that I 
start looking at that. if it meets you needs that's cool. if not you 
might be looking at cumulus or onos. That said Broadcom does enough to 
get their customers (whitebox odms) out the door, not necessarily the 
customers of those odms so your recourse to a developer is kind of 
limited which you get a from a vendor more involved in the software 
stack. A lot of those choices here depend on how responsible you want to 
be for what's running inside the box.
There was an earlier discussion about packet buffer issues, but, 
assuming for a second that it's not an issue, 
It can be avoided, but for people used to running all 10Gb/s cut-through 
trident 2s kind of hot, some of consequences are kind of impressive. 4 
much smaller buffers and the virtual assurance that you'll be doing rate 
conversion eats into the forwarding budget.
can anyone say they've used these and/or the L2/L3 features that they 
purportedly support?


Thanks!
    - bryan

Re: 40G and 100G optics options

[joel jaeggli]

On 12/19/17 10:24, Sabri Berisha wrote:
> - On Dec 18, 2017, at 9:49 AM, Fredrik Korsbäck hu...@nordu.net wrote:
>
>> This is the "failure" of us (the business) choosing QSFP as the de-factor
>> formfactor for 100G, there is not power in
>> that cage to make 10km+ optics in an easy way. If we would have pushed for 
>> CFP4
>> as the "last" formfactor in 100G land we
>> would be much better off.
> How about OSFP? The OSFP MSA has a large number of backers, including 
> Juniper, Arista, Finisar and Google. 
>
> It's the vendors that chose to go for QSFP due to the density options in a 
> single RU chassis.
osfp is potentially 540W in the front panel of a 1ru switch which poses
it's own engineering challenges.
>
> Thanks,
>
> Sabri
>




signature.asc
Description: OpenPGP digital signature

Re: Multi lane optics

[joel jaeggli]

On 12/19/17 08:45, Tyler Conrad wrote:
> This blog has a pretty good runthrough -
> http://fmad.io/blog-100g-ethernet.html
> 
> Scroll down to "100G PROTOCOLS".
> 
> On Tue, Dec 19, 2017 at 8:38 AM, Baldur Norddahl 
> wrote:
> 
>> Hello,
>>
>> Some optics are implemented with multiple lasers such as QSFP+ with 4x 10G
>> = 40G or QSFP28 with 4x 25G = 100G. How is the ethernet traffic load
>> balanced between those lanes? Is it bit by bit or more like LACP (packet by
>> packet)?
>>
>> I need to make sure my solution will handle 10G streams correctly. We have
>> a problem with N x 10G and LACP because our L2VPN MPLS endpoints are
>> lacking the flow label support. If I sell a 10G circuit to a customer and
>> uses a L2VPN to transport his port, everything may go on the same sub
>> channel. LACP will not load balance correctly, because it only sees the
>> outer MAC address for hashing, which is the same for all packets.
>>
>> Now we are worried that multi lane optics might have the exact same
>> problem.

100G frames are striped across the 4 x 25G lanes either with or without
fec. That operates as one link from the vantage point of the ethernet frame.

The fec (reed solomon coding generally) offers protection against bit
errors at the expense of some latency.

>> Regards,
>>
>> Baldur
>>
>>
> 

Re: 40G and 100G optics options

[joel jaeggli]

On 12/18/17 09:01, Baldur Norddahl wrote:
> Hi
>
> What options are available for 40G QSFP+ and 100G QSFP28 for 10+ km
> links?
>
> I see a lot of switches offered with QSFP+ and QSFP28. But I do not
> seem to find the necessary optics to build the links I want.
>
> For example, take a look at the options available at Fiberstore:
>
> https://www.fs.com/c/generic-40g-qsfp-891
>
> Generic Compatible 40GBASE-LR4 and OTU3 QSFP+ 1310nm 10km LC
> Transceiver for SMF
> $340
>
> Generic Compatible 40GBASE-ER4 and OTU3 QSFP+ 1310nm 40km LC
> Transceiver for SMF
> $1500
>
> https://www.fs.com/c/generic-qsfp28-100g-transceivers-2858
>
> Generic Compatible QSFP28 100GBASE-LR4 1310nm 10km Transceiver
> $1999
>
> Generic Compatible QSFP28 100GBASE-ER4 1310nm 40km Transceiver
> $7000
>
> That is it. Four modules and the 40km are prohibitive expensive. The
> situation at other vendors appears to be similar.
>
> I need stronger modules that can do more than 10 km without being
> extremely expensive. Or DWDM modules in the 1550 nm band so I can use
> external amplifiers. Am I looking in the wrong place? Is this expected
> to be available in the near future?
qsfp28 is heavily constrained by power budget. The inability to put a
serdes in the package does also very much constrain the form factor
since it's 4x25 wavelengths.

cfp2-aco is the approach that stops paying for the DSP with every optic
(DCO does that) gets you long haul single wave, DWDM and tunables, but
it's  a bit of an incovenient form-factor for fixed configuration 1ru
switches.
>
> Regards,
>
> Baldur
>




signature.asc
Description: OpenPGP digital signature

Re: Companies using public IP space owned by others for internal routing

[joel jaeggli]

On 12/17/17 14:30, Robert Webb wrote:
> Will anyone comment on the practice of large enterprises using non RFC1918 IP 
> space that other entities are assigned by ARIN for internal routing?
>
> Just curious as to how wide spread this might be. I just heard of this 
> happening with a large ISP and never really thought about it until now.
every time I seen a traceroute with 11/8 22/8 26/8 in it I am duly
impressed.
> Robert
>




signature.asc
Description: OpenPGP digital signature

Re: Arista Layer3

[joel jaeggli]

On 11/30/17 13:00, Ken Chase wrote:
>   >Arista DCS-7280SRA-48C6 is a 1ru box.??
>   >
>   >Has a nominally million route fib, Jericho+ 8GB of packet buffer.
>   >control-plane is 8GB of ram andAMD GX-424CC SOC which is 4 core 2.4ghz.
>   >We do direct fib injection with bird rather than the arista bgpd but the
>   >control-plane is capable of managing quite a few bgp sessions.
>   >
>   >the 1/2ru 7280CR2K-30 and 60 are 2m route fib boxes with still heftier
>   >control planes but they're a different class of box being all 100G and
>   >requiring multi-chip/internal fabrics.
>
> Sounds pretty good - hows your power draw on that thing? Why'd you pick Bird
> in this case?
this a standard sr that's moderately busy but not exactly slammed, I'm
be impressed if you could triple that at full tilt.

#show environment power
Power  Input    Output   Output
Supply  Model    Capacity  Current  Current  Power    Status
---  -   
-
1   PWR-500AC-R   500W    0.35A    5.27A    62.8W Ok
2   PWR-500AC-R   500W    0.32A    4.81A    56.4W Ok
Total   --   1000W   --   --   119.1W --

bird had memory footprint going with it as well as some local
modification and we hacked addpath into it a few years ago. filtering
poilcy is something we programmatically generate and interact with via
agents so a traditional style monolithic config isn't that useful.


> /kc
>
>
>   >> /kc
>   >>
>   >> On Thu, Nov 30, 2017 at 10:45:09AM -0800, Tyler Conrad said:
>   >>   >For Enterprise/DC, it works great. For service provider, they're not 
> 100%
>   >>   >yet. The main issue is going to be around VRFs, as there's no 
> interaction
>   >>   >between them (at least in the code version I'm on, that may have 
> changed
>   >>   >recently or be changing soon). They'll work great as a P-Router, but 
> if you
>   >>   >need a PE with route leaking I'd look at another vendor.
>   >>   >
>   >>   >I use a couple pairs of 7280SRs as edge routers/border leaves. 
> Multiple
>   >>   >full table feeds without any issue.
>   >>   >
>   >>   >On Thu, Nov 30, 2017 at 10:36 AM, Romeo Czumbil 
>    >>   >> wrote:
>   >>   >
>   >>   >> So I've been using Arista as layer2 for quite some time, and I'm 
> pretty
>   >>   >> happy with them.
>   >>   >> Kicking the idea around to turn on some Layer3 features but I've 
> been
>   >>   >> hearing some negative feedback.
>   >>   >> The people that I did hear negative feedback don't use Arista 
> themselves.
>   >>   >> (they just heard)
>   >>   >>
>   >>   >> So do we have any Arista L3 people out here that can share some 
> negatives
>   >>   >> or positives?
>   >>   >>
>   >>   >> Use case: Just some MPLS IPv4/IPv6 routing, l2vpn OSPF/BGP
>   >>   >> Maybe 20k routes (no full internet routes)
>   >>   >> 7050 Series
>   >>   >> 7280 Series
>   >>   >>
>   >>   >> -Romeo
>   >>   >>
>   >>
>   >
>   >
>
>
>
>




signature.asc
Description: OpenPGP digital signature

Re: Arista Layer3

[joel jaeggli]

On 11/30/17 11:17, Ken Chase wrote:
> Back to this discussion! :) Arista as a viable full-table PE router. Was 
> hoping
> for better experience reports since last mention.
>
> To make the Q bit more general, are there any PE routers yet that can handle 
> 3-8
> full feeds and use an amp and 1U or so instead of 5 and 4U? Or we're ito 
> whitebox/
> open routers still for that (bird/openbgp?) or microtiks?

Arista DCS-7280SRA-48C6 is a 1ru box. 

Has a nominally million route fib, Jericho+ 8GB of packet buffer.
control-plane is 8GB of ram andAMD GX-424CC SOC which is 4 core 2.4ghz.
We do direct fib injection with bird rather than the arista bgpd but the
control-plane is capable of managing quite a few bgp sessions.

the 1/2ru 7280CR2K-30 and 60 are 2m route fib boxes with still heftier
control planes but they're a different class of box being all 100G and
requiring multi-chip/internal fabrics.
> /kc
>
> On Thu, Nov 30, 2017 at 10:45:09AM -0800, Tyler Conrad said:
>   >For Enterprise/DC, it works great. For service provider, they're not 100%
>   >yet. The main issue is going to be around VRFs, as there's no interaction
>   >between them (at least in the code version I'm on, that may have changed
>   >recently or be changing soon). They'll work great as a P-Router, but if you
>   >need a PE with route leaking I'd look at another vendor.
>   >
>   >I use a couple pairs of 7280SRs as edge routers/border leaves. Multiple
>   >full table feeds without any issue.
>   >
>   >On Thu, Nov 30, 2017 at 10:36 AM, Romeo Czumbil 
>    >> wrote:
>   >
>   >> So I've been using Arista as layer2 for quite some time, and I'm pretty
>   >> happy with them.
>   >> Kicking the idea around to turn on some Layer3 features but I've been
>   >> hearing some negative feedback.
>   >> The people that I did hear negative feedback don't use Arista themselves.
>   >> (they just heard)
>   >>
>   >> So do we have any Arista L3 people out here that can share some negatives
>   >> or positives?
>   >>
>   >> Use case: Just some MPLS IPv4/IPv6 routing, l2vpn OSPF/BGP
>   >> Maybe 20k routes (no full internet routes)
>   >> 7050 Series
>   >> 7280 Series
>   >>
>   >> -Romeo
>   >>
>




signature.asc
Description: OpenPGP digital signature

Re: Commodity routers/switches

[joel jaeggli]

On 11/19/17 07:36, Mike Hammett wrote:
> Which is sad because I believe there are a ton of people using old gear 
> (lacking modern features and security) because the old gear meets price and 
> performance requirements. Although obviously much smaller networks (and thus 
> potential with each one), it's easy to say there are more 1G\10G ISPs than 
> there are 100G ISPs. 
Feature demand drives per port costs that are not very competitively
achieved on 1Gb/s switches. On the plus side the per-port cost of the
10Gb/s and mixed 10/100Gb/s switches with usefully rich features
continues to slide. Some use of L2 devices for port demux for bigger
iron has been done in the past, I imagine it still works for a number of
use cases (cisco sells fabric extenders under a similar rational).
>
>
>
> - 
> Mike Hammett 
> Intelligent Computing Solutions 
> http://www.ics-il.com 
>
> Midwest-IX 
> http://www.midwest-ix.com 
>
> - Original Message -
>
> From: "Fredrik Korsbäck"  
> To: nanog@nanog.org 
> Sent: Sunday, November 19, 2017 1:46:53 AM 
> Subject: Re: Commodity routers/switches 
>
> On 2017-11-19 02:55, mike.l...@gmail.com wrote: 
>> Howdy! 
>>
>> Looking to replace some edge routers for my small ISP. With all the various 
>> SDN platforms available along with various choices of bare-metal hardware 
>> platforms, im thinking i may go this route instead of going with 
>> Cisco/Juniper/Etc. 
>>
>> I only need a handful of 10G uplinks. The SuperMicro SSE-G3648B and the 
>> Penguin Arctica Network switches appear to fit my needs. 
>>
>> I am eyeing Cumulus Linux to run on these, but that isn’t set in stone. 
>>
>> They’ll likely be getting 2 full tables along with some peers. 
>>
>> Has anyone run SuperMicro or Penguin hardware with Cumulus in this type of 
>> scenario? 
>>
>> What were your experiences? How is BGP convergence time on x86 hardware 
>> these days? 
>>
>> Any insight would be appreciated. 
>>
>> Thank You, 
>> Mike 
>>
> Replacing a edge-router with a switch is nothing new, however make sure you 
> actually replace it with the correct one. 
>
> The Supermicro looks like any generic Helix4-switch and is a ToR-switch for 
> the datacenter. Its not very fitting for 
> edge-routing. It does not have buffers at all and would make your sub-speed 
> connections perform like shit, and also it 
> has a tiny LPM table so you wont be able to fit anywhere near a full table in 
> there 
>
> It seems that you want a cost-effective 1G solution given that you linked 
> SSE-G3648B? 
>
> Merchant-switch silicon and edge-routing isn't very competitive on 1G/10G, 
> both because traditional legacy-routers is 
> somewhat cheap for 1G applications and also that 1G is virtually non-existant 
> in datacenter enviroments these days so 
> its hard to leverage the economy-of-scale from there on these swithces. 
>
> Look at Nokias portfolio for 1G/10G routers, they still care in that segment 
> and is in Europe a very popular choice for 
> broadband buildouts, as is Huaweis smaller NetEngines but that might not fly 
> that well in the US. Juniper MX150 might 
> also work depending on how much 1G you need, but you likely need more. 
>
> If you bump it up a notch to 10G/100G or 100G only the market for 
> routing-merchant-silicon looks much better. I guess 
> the most famous platform is the Arista 7280R that was the first 
> Broadcom-based box that accepted 1M routes, had big 
> buffers and didnt cost the equivalent of a bunch of new cars for a 1Tbit of 
> capacity like J/C/N/H would charge you for a 
> equivalent linecard to their edge-portfolios. 
>
> Cisco quickly released NCS550 productline as an answer, Huawei released 
> CE6870-line (but didnt do the LEM/LPM hack that 
> C/A did for full tables to protect NetEngine BU), Juniper pushes QFX10K which 
> is somewhat equal to a Broadcom 
> Jericho-based box. The only Whitebox-vendor i know off that actually has a 
> Jericho (qumran) based box is Agema with the 
> AGC7648S, not sure which stand-alone NOS that actually supports this box 
> fully. 
>
> Now Jericho+ is also out and Jericho2 is around the corner so i guess we will 
> see alot bigger and even more competetive 
> switch-routers based on these chips. But it doesent really help much if you 
> are operating in 1G/10G space. 
>
>
>
>




signature.asc
Description: OpenPGP digital signature

Re: Commodity routers/switches

[joel jaeggli]

On 11/18/17 17:55, mike.l...@gmail.com wrote:
> Howdy!
>
> Looking to replace some edge routers for my small ISP. With all the various 
> SDN platforms available along with various choices of bare-metal hardware 
> platforms, im thinking i may go this route instead of going with 
> Cisco/Juniper/Etc.
>
> I only need a handful of 10G uplinks. The SuperMicro SSE-G3648B and the 
> Penguin Arctica Network switches appear to fit my needs.
>
> I am eyeing Cumulus Linux to run on these, but that isn’t set in stone.
>
> They’ll likely be getting 2 full tables along with some peers.
afaik if these are consistent with other t2/tomahawk/helix switches
they're roughly 200K alpm routes installed or as few as 16K. if you
install selected routes and otherwise default  or this is a peering only
router, that can get you pretty far but it's not a full table by any means.

https://docs.cumulusnetworks.com/display/DOCS/Routing (cumulous details
on route table size and alpm routes)
> Has anyone run SuperMicro or Penguin hardware with Cumulus in this type of 
> scenario?  
>
> What were your experiences? How is BGP convergence time on x86 hardware these 
> days?

control plane on the switches mentioned about is 2GB of ram and a dual
core atom, so it's fine more or less for a datacenter TOR. It's not
particularly powerful. I find out particular tooling doesn't run that
well in 4GB any more so your milage may vary.

the supermicro should bear a striking  resemblance to the dell 3048 that
was splayed open here

http://eoinpk.blogspot.com/2015/08/under-hood-of-dell-s3048-on.html

>
> Any insight would be appreciated.
>
> Thank You,
> Mike
>




signature.asc
Description: OpenPGP digital signature

Re: IPv6 first hop security on a budget?

[joel jaeggli]

On 11/11/17 09:14, Fernando Gont wrote:
> On 05/05/2017 08:27 PM, Joel Whitehouse wrote:
>> What's a good budget option for switching a small lab or office ipv6
>> with RA Guard, DHCP6 snooping, and ICMP6 snooping?
>>
> 
> If you do deploy this, please take a look at the issues discussed in
> RFC7113. Similar stuff is likely to apply to DHCPv6 snooping et al.

experiences vary, if you're looking to experience them first hand, warts
implementation details and all, juniper ex2300c, cisco 3560cx are both
small variants of both providers lower-end layer2/3 switches and are
relatively inexpensive, fairly feature rich platforms.

https://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst2960cx_3650cx/software/release/15-2_3_e/configuration/guide/b_1523e_consolidated_2960cx_3560cx_cg/b_consolidated_152ex_2960-X_cg_chapter_011.pdf

https://www.juniper.net/documentation/en_US/junos/topics/reference/configuration-statement/router-advertisement-guard-edit-fo.html

joel

> Thanks!
> 
> Best regards,
> 

Re: What's the point of prepend communities?

[joel jaeggli]

On 10/26/17 10:58, Jason Lixfeld wrote:
> Hi,
>
> Of all the ISPs that I am familiar with that have a BGP community structure 
> usable by their peering partners and/or downstream customers, among other 
> things, they allow the customer to signal the ISP to prepend their own AS to 
> the as-path of a particular prefix announcement.
>
> What functionality does a provider prepend support that is otherwise lost in 
> the absence of such a feature, but all the while, the customer would be able 
> to prepend their own AS to the same prefix announcement anyway?
It has no effect on the provider itself since they prefer customer
routes anyway.

prepending towards a peer of your provider is to encourage them to
select an alternative (shorter) path.

prepending when it works is preferable to no export since the later
doesn't leave that provider available for fallback.
> Is this a relic from before ISPs allowed for local preference adjustment, or 
> is there actually a use case for this?
local pref and med is um local to your upstream.
> Thanks!
>
>




signature.asc
Description: OpenPGP digital signature

Re: California fires: smart speakers and emergency alerts

[joel jaeggli]

On 10/14/17 22:01, valdis.kletni...@vt.edu wrote:
> On Fri, 13 Oct 2017 18:50:51 -0700, Joe Hamelin said:
>> I would think that Amazon knows where my Echo is since it's the same IP
>> that I order (way too much crap) from.
> 
> It knows the usual delivery address.  That's not necessarily the same thing.

It pairs with your phone via bluetooth, also wifi geolocation (e.g.
skyhook) tends to be fairly accurate in moderately high density
residential environments.

Google DNS64 misconfigured?

[Joel Whitehouse]

I had an ipv6-only lab environment cease being able to browse much of 
the internet on Monday.  Tracked the issue down to google's public DNS64 
service; the following queries should return DNS64 responses from the 
64:9bff::/96 prefix, however, I'm getting 0 DNS64 answers from dig on 
both their servers for the last 60 hours:


dig @2001:4860:4860::64 ipv4only.arpa 
dig @2001:4860:4860::6464 ipv4only.arpa 

DNS works fine, just not DNS64.  A forum topic [0] suggests this 
behavior might be intermittent but no official response from google 
there.  Is google's public DNS64 down for anyone else?



[0] 
https://groups.google.com/d/topic/public-dns-discuss/dD_lSPfqXHA/discussion

--
Joel Whitehouse

Re: pd table vs 6296

[joel jaeggli]

On 9/21/17 18:59, Randy Bush wrote:
> say i want to use pd to a fairly large aggregation.  the router has to
> hold the pd table.  it sees some routers have limited table size, e.g.
> 1k.  so what's a poor boy to do?  the classic ipv4 solution would be
> 6296 .  are folk doing pd scaling?  how?
>
> randy   
>
This is kind of in the neighborhood of stupid pet tricks, but I've done
it to substantially increase the table size in a non-pd scenario, so
there is that.

In an accommodating switch, program a particular prefix length (say 56
or 48 ending on a byte offset) to be installed and matched in the exact
match table. Voila your PD routes are now host routes, and the table for
VLSM routes is free for other purposes.

1. Isn't this robbing peter to pay paul? - yes

2. Is this some kind of strange classful addressing hetrodoxy? - not
really, masks just happen to be expensive.

3. How does this work with variable length prefix delegation? - all PD
prefixes are the same (maximum) size and you install them in the routing
table accordingly> what the end system asks for and what they do with it
when you route it to them are both their business. A decent (not
necessarily high end) L3 switch will let you partition the CAM  in
several variations that are more or less appropriate for this application.





signature.asc
Description: OpenPGP digital signature

Re: 100G QSFP28 DAC cables - experience

[joel jaeggli]

On 9/6/17 00:17, Jiri Prochazka wrote:
> Hi folks,
>
> I'm wondering if anyone have (either positive or negative) experience
> with 100G QSFP28 DAC cables?
I found the ones we tested to be substantially more finicky particularly
at 5 meter then 10gig dacs, adding 4 x 25 sfp28 breakout on the other
end probably isn't a help. We went with AOCs for the equivalent (3, 5
meter) lengths.
> Is there anyone who is using 100G DAC in large scale and would
> recommend it (which means there are no issues compared to SR4 links)?
>
> I'm thinking about cables with lenght up to 1m, not more.
>
> We have had quite bad experience with 10G DAC in the past - but I do
> not want to be slave of the past.
>
>
10g dacs were less reliable then I would have preferred for  3 5 7 meter
distances but they were tolerable especially if you leave the bundles
alone, 25g was sufficiently less so at least in testing that we didn't
try it in the field, being at the limits at 5m was a sufficient
problemthat it ruled out some adjacent rack arrangements. so we're all
optical for 25/100
>
> Thank you for your thoughts!
>
>
>
> Jiri
> 
>




signature.asc
Description: OpenPGP digital signature

Re: 100G - Whitebox

[Joel Jaeggli]

> On Aug 20, 2017, at 08:45, Mike Hammett  wrote:

> 
> Any particular hardware platforms to go towards or avoid? Broadcom Tomahawk 
> seems to be quite popular with varying control planes. LINX went Edgecore, 
> which was on my list given my experience with other Accton brands. Fiberstore 
> has a switch where they actually publish the pricing vs. a bunch of mystery. 

Tomahawk and tomahawk 2 have precious little in the form of packet packet 
buffer (e.g. As little as 4 x 4MB for original tomahawk) which might be a 
problem in a environment where you need to rate convert 100G attached peers to 
a big bundle of 10s).

White box Broadcom dnx / jericho is somewhat less common but does exist.

That 40s are less popular I think is no surprise. They were / are largely 
consigned to datacenter applications.

> Thoughts? 
> 
> 
> 
> 
> - 
> Mike Hammett 
> Intelligent Computing Solutions 
> http://www.ics-il.com 
> 
> Midwest-IX 
> http://www.midwest-ix.com 
> 

Re: Point 2 point IPs between ASes

[joel jaeggli]

On 6/28/17 15:44, William Herrin wrote:
> On Wed, Jun 28, 2017 at 5:09 PM, Thomas Bellman  wrote:
>
>> On 2017-06-28 17:03, William Herrin wrote:
>>
>>> The common recommendations for IPv6 point to point interface numbering
>> are:
>>> /64
>>> /124
>>> /126
>>> /127
>> I thought the only allowed subnet prefix lengths for IPv6 were /64 and
>> /127.  RFC 4291 states:
>>
>>For all unicast addresses, except those that start with the binary
>>value 000, Interface IDs are required to be 64 bits long and to be
>>constructed in Modified EUI-64 format.
>>
>> (and addresses starting with 000 are only used for special things,
>> like the localhost address ::1).  And then RFC 6164 adds /127 to
>> the allowed prefix lengths.
>>
>> I know that many devices allow you to configure any subnet size,
>> but is there any RFC allowing you to use e.g. /124 or /126?
>>
> Hi Thomas,
>
> AFAICT, the IETF has not caught up with operations practice... 
there's a certain amount of style drift, I think the rfc series actually
captures quite a bit of it.
> and
> operations practice itself is still in flux. I do see some discussion of
> longer-than-/64 prefixes in RFC 7421.
I'm not so sure about that, While operators have a variety of
preferences some of which I fix quixotic; which were formed as much as 2
decades ago. it's been about 6 years since we had a standards track
consensus describing the rational for numbering point-to-point links out
of /127s (6164). Which is long enough for text books to have been
updated, silicon implemntations of tcams to use exact match instead of
longest match lookups for your connected  neighbor on a /127 and so on.
likewise mitigations for ND exhaustion attacks exist even if they are
not universally implemented or perfect so some if not all the motivation
for short prefixes has been ameliorated. one can argue that concern in
rfc3627 (subnet router anycast) is entirely irrelevant for point to
point links (the rfc is now historic for that reason) which was the
major motivation for /126 vs /127 14 years ago.

in other news isps that apparently haven't run out of ipv4 addresses are
still assigning me /30 point-to-point links.
> The difference between theory and practice? In theory, there is no
> difference.
>
> IPv6 overall is designed to support CIDR addressing at any netmask. Correct
> implementations may not assume that any given interface will host a /64.
> Some specific protocols (like SLAAC) intentionally do not work if the
> interface ID is not exactly 64 bits. Others become more difficult than
> necessary if the prefix is not on a nibble boundary (the /CIDR number is
> not evenly divisible by 4).
>
> In the mean time, the options that have come out of OPERATIONS activity for
> point to point connections have converged on the above 4.
>
> Regards,
> Bill Herrin
>
>
>




signature.asc
Description: OpenPGP digital signature

Re: Point 2 point IPs between ASes

[joel jaeggli]

On 6/28/17 18:10, Olivier Benghozi wrote:
> Well, /112 is not a stupid option (and is far smarter than /64): it contains 
> the whole last nibble of an IPv6, that is x:x:x:x:x:x:x:1234.
> You always put 1 or 2 at the end, and if needed you are still able to address 
> additional stuff would the point-to-point link become a LAN.
> And you don't throw away billions of addresses like with /64.
If you were subnetting down from /64 for the purposes of preventing ndp
exhaustion or to protect the control plane  on either yours or your
customers platforms then a /112 is pretty useless because 16 bits is
harmful enough.

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

https://tools.ietf.org/html/rfc6164
>> On 29 jun 2017 at 02:32, William Herrin  wrote :
>>
>> On Wed, Jun 28, 2017 at 8:01 PM, Aaron Gould  wrote:
>>
>>> I think this is funny... I have (4) 10 gig internet connections and here's
>>> the maskings for my v6 dual stacking...
>>>
>>> /126 - telia
>>> /64  - att
>>> /112 - cogent
>>> /127 - twc/charter/spectrum
>> 112... Could be worse I suppose. They could have picked 113.
>




signature.asc
Description: OpenPGP digital signature

Re: Reliability of Juniper MIC3-3D-1X100GE-CFP and CFP in general

[Joel Jaeggli]

Sent from my iPhone

> On Jun 22, 2017, at 07:38, Eric Dugas  wrote:
> 
> Hello,
> 
> We're planning to phase out some 10G link-aggregations in favor of 100G
> interfaces. We've been looking at buying MIC3-3D-1X100GE-CFP, MPC3E and
> Fiberstore CFPs.
> 
> I've been told that CFPs (in general) weren't that reliable. They were
> kinda "replaced" almost a year and a half or so after its introduction by
> CFP2 and then by CFP4 and so on. Size and power consumption aside, are the
> MIC3-3D-1X100GE-CFP and CFP modules reliable at all? Are they the SFP-TX of
> the 100GBase?

CFP has been around a while, like 8 years at this point. CFP2 and CFP4 are 
significantly smaller have accordingly lower power budgets and do not include 
the DSP on board (the linecard for cfp/2/4/8 differs significantly respecting 
level of integration components and so forth and also port count).

Apart from the resulting low port density per card, which makes them unsuitable 
for a number applications they're mature products at this point.
> 
> Eric
> 

Re: Internet connectivity in Nigeria

[Joel Jaeggli]

Sent from my iPhone

> On Jun 18, 2017, at 12:29, Sina Owolabi  wrote:
> 
> PCCW? I dont think I've heard of them

Pccw would be sat3 glo1 and wacs maybe others.

http://mediafiles.pccwglobal.com/images/downloads/Inf_map.pdf

Their looking glass can give you some idea into their reach with Nigeria with a 
little experimentation.

http://lookingglass.pccwglobal.com/

That said sat3 and glo1 combined have something like an order of magnitude less 
capacity than wacs so the survival / utility of any of the older systems when 
losing the newest ones is probably less than complete.

> 
> On Sun, Jun 18, 2017 at 8:10 PM, Rod Beck
>  wrote:
>> 
>> PCCW has a strong presence in Africa and they are easy to work with.
>> 
>> 
>> - R.
>> 
>> 
>> From: NANOG  on behalf of Sina Owolabi
>> 
>> Sent: Sunday, June 18, 2017 8:59:41 PM
>> To: nanog@nanog.org list
>> Subject: Internet connectivity in Nigeria
>> 
>> Hi All
>> 
>> Currently having a terrible situation in Nigeria where the GLO1 and
>> MainOne cables appear to be both down.
>> Can anyone suggest a good Nigerian ISP with redundancies enough to
>> overcome at least two of the following dying out?
>> 
>> SAT-3
>> WACS
>> GLO1
>> ACE
>> MainOne
>> 
>> Please dont say MTN or any of the Nigerian telcos, except there are no
>> other options, customer service will leave you trying to commit bodily
>> harm.
> 

Re: BCP38/84 and DDoS ACLs

[joel jaeggli]

On 5/26/17 10:24, Kody Vicknair wrote:
> When I was doing some research in regards to the same subject I ran across 
> this doc. I've found it to be very helpful.
>
> http://nabcop.org/index.php/DDoS-DoS-attack-BCOP
Causally applied RPF checks applied to transit and peer interfaces
especially exchange fabrics have a very high-liklihood of blackholing
traffic you wanted particularly during maintenance if not casually
implemented. A very careful read rfc3704/bcp 84 is a necessary part of
implementing bcp 38 filters.

>
>
> Kody Vicknair
> Network Engineer
>
> Tel:985.536.1214
> Fax:985.536.0300
> Email:  kvickn...@reservetele.com
>
> Reserve Telecommunications
> 100 RTC Dr
> Reserve, LA 70084
>
> _
>
> Disclaimer:
> The information transmitted, including attachments, is intended only for the 
> person(s) or entity to which it is addressed and may contain confidential 
> and/or privileged material which should not disseminate, distribute or be 
> copied. Please notify Kody Vicknair immediately by e-mail if you have 
> received this e-mail by mistake and delete this e-mail from your system. 
> E-mail transmission cannot be guaranteed to be secure or error-free as 
> information could be intercepted, corrupted, lost, destroyed, arrive late or 
> incomplete, or contain viruses. Kody Vicknair therefore does not accept 
> liability for any errors or omissions in the contents of this message, which 
> arise as a result of e-mail transmission. .
>
> -Original Message-
> From: NANOG [mailto:nanog-bounces+kvicknair=reservetele@nanog.org] On 
> Behalf Of Roland Dobbins
> Sent: Friday, May 26, 2017 12:20 PM
> To: nanog@nanog.org
> Subject: Re: BCP38/84 and DDoS ACLs
>
>
> On 26 May 2017, at 22:39, Graham Johnston wrote:
>
>> I am looking for information regarding standard ACLs that operators
>> may be using at the internet edge of their network, on peering and
>> transit connections,
> These .pdf presos may be of interest:
>
> 
>
> 
>
> They talk about iACL and tACL design philosophy.
>
> What traffic you should permit/deny on your network is, of course, 
> situationally-specific.  Depends on what kind of network it is, what 
> servers/services/applications/users you have, et. al.  You may need one set 
> of ACLs at the peering/transit edge, and other, more specific ACLs, at the 
> IDC distribution gateway, customer aggregation gateway, et. al.
>
> ---
> Roland Dobbins 
>




signature.asc
Description: OpenPGP digital signature

Re: Carrier classification

[joel jaeggli]

On 5/15/17 10:01 PM, Ken Chase wrote:
> so cogent has no routes to some amount of v6? ie no routes
> to some prefixes?

it's easy enough to test

TestRouter Location Hostname / IP Address   

2607:f8b0:4005:801::200e
Go!
Tue May 16 04:00:27.010 UTC
% Network not in table

http://www.cogentco.com/en/network/looking-glass

They're not the sole provider with a hole in their routing table, nor is
that the only hole. I would probably choose not to single home behind
any nominally SFI carrier, but on the other hand how useful such carrier
is in the first place has a lot to do with can they offload the traffic
you choose to send them, which is a different problem and should be
assessed accordingly.


> /kc
> 
> On Mon, May 15, 2017 at 07:56:14PM -0700, Large Hadron Collider said:
>   >My terminology of tiers are:
>   >
>   >Tier 1 - is in few or no major disputes, has no transit, and is able to
>   >access over three nines percent of the internet
>   >
>   >Tier 2 - as Tier 1, but has transit.
>   >
>   >Cogent is neither on v6, and I have no clue about v4.
>   >
>   >HE is probably Tier 2 on v4, and is Tier 1 on v6.
>   >
>   >
>   >On 15/05/2017 19:27, Ca By wrote:
>   >> On Mon, May 15, 2017 at 6:44 PM Bradley Huffaker  
> wrote:
>   >>
>   >>> On Sun, May 14, 2017 at 09:24:18AM +0200, Mark Tinka wrote:
>    Nowadays, I'm hearing this less and less, but it's not completely gone.
>   >>> Putting aside the question of their importance, there is a small number
>   >>> of ISPs that do no pay for transit. If you don't call them Tier 1, what
>   >>> do you call them? Transit Free Providers (TFPs)?
>   >>
>   >> I think the broader and more relevant question is -- Does it matter who
>   >> pays who ? Why name an irrelevant characteristic?
>   >>
>   >> Cogent may not buy transit but i would not purchase their service since
>   >> they fail to have full internet reach (google and HE)
>   >>
>   >> And xyz incumbent may have a poor network, but they may get free peering 
> or
>   >> may get paid-peering because of their incumbent / monopoly status... that
>   >> is not a reason for me to purchase from them or think they are an elite
>   >> tier 1.
>   >>
>   >> The dynamica of the day are more around reach and quality, not some 
> legacy
>   >> measure of how market-failure facilitate anti-social behavior
>   >>
>   >>
>   >>
>   >>> --
>   >>> the value of a world model is not how accurately it captures reality
>   >>> but how often it leads us to take appropriate action
>   >>>
>   >
> 




signature.asc
Description: OpenPGP digital signature

IPv6 first hop security on a budget?

[Joel Whitehouse]

What's a good budget option for switching a small lab or office ipv6 
with RA Guard, DHCP6 snooping, and ICMP6 snooping?

Re: Covering prefix blackholing traffic to one of its covered prefixes....

[Joel Jaeggli]

Sent from my iPhone

> On Apr 23, 2017, at 08:59, Steven Wallace  wrote:
> 
> We have dual-homed sites that only accept routes from their peers, and 
> default to their transit provider. A site may receive a covering prefix from 
> a peer, but since they are not accepting the full table from their transit 
> provider they don’t see the covered (i.e., more specific). In some cases the 
> peer announcing the covering prefix blackholes traffic to the covered prefix.

If you announce a route in general you should expect to route it.

Assuming this is the intended behavior of both parties announcing the covering 
aggregate and the more specific. The site should either drop the offending peer 
route forcing it to transit, or take full feed from it's transit. And let the 
longest match win.

> Is this accepted behavior, or should a peer announcing a covering prefix 
> always delver packets to its covered routes?

Generally but there are exceptions.

> 
> Does this happen often?
> 
> Thanks!
> 
> Steven Wallace
> Indiana University

Re: google ipv6 routes via cogent

[joel jaeggli]

On 3/2/17 3:42 PM, Jared Mauch wrote:
> Yes. Most providers can send you just their customer routes. If they send you 
> full routes you want to discriminate customer vs peer routes. This is 
> typically done with communities and is worthwhile as most people have 
> capacity on customer links but via peer it may not always be the case. 
>
> As is usual YMMV
It's relatively straight-forward to take a full table feed and accept
into your fib only the routes you want from that table.

I presented on variant of that based on my need for partial fib peering
switches; but other reasons for doing so exist, e.g. defailt +
te-overrides, prefix filters weighted by per prefix utilization and so on.

In general I'd get the full table and the default if you intend to take
the default but need recourse to over-rides (for example if your fib
won't hold full table is an element of the design). if the Rib won't
hold three full tables well that's a different sort of problem, and this
may be the wrong router platform.

joel
> Jared Mauch
>
>> On Mar 2, 2017, at 2:52 PM, Aaron Gould <aar...@gvtc.com> wrote:
>>
>> Yes, thanks, I am going to do that.  But, is there a middle ground between 
>> being default only and full routes ?  Like is it advantageous for me to ask 
>> for partial routes (like their routes and direct peers and default route) ?  
>> This way I don't have millions of routes but I guess only a few hundred 
>> thousand or less?  Let me know please.
>>
>> -Aaron
>




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: 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

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: 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

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: 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: 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