RE: Static Routing 172.16.0.0/32

2017-12-08 Thread Keith Medcalf

And thank god for that.  Since Microsoft stopped diddle-farting with Windows 98 
is was never infested with the UDP "Execute Payload with NT AUTHORITY\SYSTEM" 
flag that appeared in all later versions of Windows TCP/IP stack.

As Windows 98 worked on the day after Microsoft stopped diddling with it, so it 
will work on that day + N, for every value of N.

The most wonderful thing that can happen to a Microsoft product is that they 
stop diddling with it for at that point it stops being a moving target that 
works differently from one minute to the next.  Additionally, features cannot 
be removed from the product as usually happens with each downgrade (I think 
Microsoft calls them upgrades) of the products.

---
The fact that there's a Highway to Hell but only a Stairway to Heaven says a 
lot about anticipated traffic volume.


>-Original Message-
>From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Job
>Snijders
>Sent: Friday, 8 December, 2017 15:47
>To: Ken Chase
>Cc: nanog@nanog.org
>Subject: Re: Static Routing 172.16.0.0/32
>
>On Fri, Dec 8, 2017 at 10:44 PM, Ken Chase  wrote:
>> why not use 192.0.2.0/24 addrs?
>>
>> lots of other ranges you could probably use safely.
>>
>>https://en.wikipedia.org/wiki/Reserved_IP_addresses
>>
>> Using .0 you're asking to exercise bugs and undefined
>implimentation choices
>> of various tcp stacks and resolvers out there on myriad devices.
>Clever collision
>> avoidance, but relies on a prayer.
>
>Please stop spreading Fear, Uncertainty and Doubt about valid CIDR
>addresses. :-)
>
>> (IIRC try setting an NS record to resolve to 127.0.0.255 on windows
>95 - it
>> used to lock the OS up fun times. Someone had pointed some
>popular domain
>> at us by accident, and having no entry and no negative caching of
>the day
>> meant we were being hammerred on our 10mbps uplink, had to set
>something to
>> get cached, so we did... several hours later a microsoft engineer
>called us
>> and pleaded with us to use a different IP. :)
>
>Microsoft ended support for Windows 95 on December 31th 2001
>
>Kind regards,
>
>Job





RE: Static Routing 172.16.0.0/32

2017-12-08 Thread Kate Gerry
In this example only semi-new devices with current OSes are accessing 
172.16.0.0, concerns over old devices or a BSD4.2 machine hitting it is highly 
unlikely.

To clarify Ryan's statement, the device in question is our software repository 
where we store OS software updates, for only recent versions of software, so it 
should not be an issue. Since we have multiple locations, and multiple software 
stores, we use 172.16.0.0 as the AnyCast address.

I am glad that we have been able to stir up such a discussion, Ryan and I had 
the same conversation here so I am glad that he brought it to the group.

--
Kate Gerry
Network & Facilities Director 
+1 (888) 578-2372 x206 / k...@quadranet.com 
QuadraNet, Inc. / Dedicated Servers, Colocation, Cloud, QuadraNet Vest DDoS 
Protection
Datacenters in Los Angeles, Dallas, Miami, Atlanta, Chicago & New Jersey


-Original Message-
From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Ken Chase
Sent: Friday, December 8, 2017 3:03 PM
To: Job Snijders 
Cc: nanog@nanog.org
Subject: Re: Static Routing 172.16.0.0/32

Right - usage of network and broadcast addresses will suddenly make all the 
ToiletPaperLink devices upgrade themselves to a new firmware that the devs 
released posthaste to handle them properly...

I like your upgrade-by-force ideas! (no, I do. Screw bad implimentations, let 
them be binned!) (Tell me about your v6 adoption plans now.)

The Win95 thing was just a personal example of how these things can express 
themselves...  was a good laugh at the time. The incidence and hilarity of 
similar events has not materially changed in the intervening decades, we'll all 
note.

Have fun with your .0's people! Let us know how your support dept likes em.

/kc

On Fri, Dec 08, 2017 at 10:47:09PM +, Job Snijders said:
  >On Fri, Dec 8, 2017 at 10:44 PM, Ken Chase  wrote:
  >> why not use 192.0.2.0/24 addrs?
  >>
  >> lots of other ranges you could probably use safely.
  >>
  >>https://en.wikipedia.org/wiki/Reserved_IP_addresses
  >>
  >> Using .0 you're asking to exercise bugs and undefined implimentation 
choices
  >> of various tcp stacks and resolvers out there on myriad devices. Clever 
collision
  >> avoidance, but relies on a prayer.
  >
  >Please stop spreading Fear, Uncertainty and Doubt about valid CIDR
  >addresses. :-)
  >
  >> (IIRC try setting an NS record to resolve to 127.0.0.255 on windows 95 - it
  >> used to lock the OS up fun times. Someone had pointed some popular 
domain
  >> at us by accident, and having no entry and no negative caching of the day
  >> meant we were being hammerred on our 10mbps uplink, had to set something to
  >> get cached, so we did... several hours later a microsoft engineer called us
  >> and pleaded with us to use a different IP. :)
  >
  >Microsoft ended support for Windows 95 on December 31th 2001
  >
  >Kind regards,
  >
  >Job

--
Ken Chase - Guelph Canada



Re: Static Routing 172.16.0.0/32

2017-12-08 Thread Ken Chase
Right - usage of network and broadcast addresses will suddenly make all the
ToiletPaperLink devices upgrade themselves to a new firmware that the devs
released posthaste to handle them properly...

I like your upgrade-by-force ideas! (no, I do. Screw bad implimentations, let 
them
be binned!) (Tell me about your v6 adoption plans now.)

The Win95 thing was just a personal example of how these things can express
themselves...  was a good laugh at the time. The incidence and hilarity of
similar events has not materially changed in the intervening decades, we'll
all note.

Have fun with your .0's people! Let us know how your support dept likes em.

/kc

On Fri, Dec 08, 2017 at 10:47:09PM +, Job Snijders said:
  >On Fri, Dec 8, 2017 at 10:44 PM, Ken Chase  wrote:
  >> why not use 192.0.2.0/24 addrs?
  >>
  >> lots of other ranges you could probably use safely.
  >>
  >>https://en.wikipedia.org/wiki/Reserved_IP_addresses
  >>
  >> Using .0 you're asking to exercise bugs and undefined implimentation 
choices
  >> of various tcp stacks and resolvers out there on myriad devices. Clever 
collision
  >> avoidance, but relies on a prayer.
  >
  >Please stop spreading Fear, Uncertainty and Doubt about valid CIDR
  >addresses. :-)
  >
  >> (IIRC try setting an NS record to resolve to 127.0.0.255 on windows 95 - it
  >> used to lock the OS up fun times. Someone had pointed some popular 
domain
  >> at us by accident, and having no entry and no negative caching of the day
  >> meant we were being hammerred on our 10mbps uplink, had to set something to
  >> get cached, so we did... several hours later a microsoft engineer called us
  >> and pleaded with us to use a different IP. :)
  >
  >Microsoft ended support for Windows 95 on December 31th 2001
  >
  >Kind regards,
  >
  >Job

-- 
Ken Chase - Guelph Canada


Re: Static Routing 172.16.0.0/32

2017-12-08 Thread Jason Kuehl
+1 for gross comment.

On Fri, Dec 8, 2017 at 2:57 PM, Hunter Fuller  wrote:

> I think I'd rate this one as "gross but technically not breaking any rules
> I suppose." (I couldn't find any at first glance, anyway.)
>
> On Fri, Dec 8, 2017 at 1:55 PM Ryan Hamel 
> wrote:
>
> > Greetings,
> >
> > A colleague of mine has static routed 172.16.0.0/32 to a usable IP
> > address, to have a single known IP address be static routed to a regions
> > closest server. While I understand the IP address does work (pings and
> what
> > not), I don't feel this should be the proper IP address used, but
> something
> > more feasible like a usable IP in a dedicated range (172.31.0.0/24 for
> > example).
> >
> > I would to hear everyone's thoughts on this, as this the first IP address
> > in an RFC1918 range.
> >
> > Thanks,
> >
> > --
> > Ryan Hamel
> > ryan.ha...@quadranet.com | +1 (888) 578-2372 <(888)%20578-2372>
> > QuadraNet, Inc. | Dedicated Servers, Colocation, Cloud
> >
> > --
>
> --
> Hunter Fuller
> Network Engineer
> VBH Annex B-5
> +1 256 824 5331
>
> Office of Information Technology
> The University of Alabama in Huntsville
> Systems and Infrastructure
>



-- 
Sincerely,

Jason W Kuehl
Cell 920-419-8983
jason.w.ku...@gmail.com


Re: Static Routing 172.16.0.0/32

2017-12-08 Thread Ryan Hamel
> At some point, some chucklehead  is going to look at that .0.0 and mentally 
> think /16, and things will go pear-shaped pretty quickly

Same for a /12, which is RFC1918.

 Original message 
From: valdis.kletni...@vt.edu
Date: 12/8/17 1:46 PM (GMT-08:00)
To: Ryan Hamel 
Cc: nanog@nanog.org
Subject: Re: Static Routing 172.16.0.0/32

On Fri, 08 Dec 2017 03:13:57 +, Ryan Hamel said:
> Greetings,

> A colleague of mine has static routed 172.16.0.0/32 to a usable IP address,
> to have a single known IP address be static routed to a regions closest 
> server.
> While I understand the IP address does work (pings and what not), I don't feel
> this should be the proper IP address used, but something more feasible like a
> usable IP in a dedicated range (172.31.0.0/24 for example).

Probably depends on what your colleague is trying to do.  Nothing in the
rules says the .0 address on a subnet is reserved (though you're in for a
surprise if there's any gear still on the net with a 4.2BSD stack).

> I would to hear everyone's thoughts on this, as this the first IP address in
> an RFC1918 range.

> At some point, some chucklehead  is going to look at that .0.0 and mentally 
> think /16, and things will go pear-shaped pretty quickly


Re: Static Routing 172.16.0.0/32

2017-12-08 Thread Ryan Hamel
I'm not implying HTTP, I'm implying a static route at each sites private layer 
3 router (it'll move to BGP in the future). The repository server listens on 
the IP as well.

My original question was the fact of using 172.16.0.0/32 as a usable IP address 
(not even caring about anycast).


 Original message 
From: William Herrin 
Date: 12/8/17 1:45 PM (GMT-08:00)
To: Ryan Hamel 
Cc: nanog@nanog.org
Subject: Re: Static Routing 172.16.0.0/32

On Fri, Dec 8, 2017 at 4:37 PM, Ryan Hamel 
> wrote:
> 1. A single known ip address that redirects to the closest internal repo 
> server. 172.16.0.0/32 redirects to a usable subnet ip 
> in 172.16.xx.xx by static route.

Hi Ryan,

Maybe if would help if you write the extended version because that's about as 
clear as mud. First you asked about routing. Now you imply HTTP.

Regards,
Bill Herrin


--
William Herrin  her...@dirtside.com 
 b...@herrin.us
Dirtside Systems . Web: 


Re: Static Routing 172.16.0.0/32

2017-12-08 Thread Ryan Hamel
1. A single known ip address that redirects to the closest internal repo 
server. 172.16.0.0/32 redirects to a usable subnet ip in 172.16.xx.xx by static 
route.

2. Internal private network that is reachable by clients.

 Original message 
From: William Herrin 
Date: 12/8/17 1:34 PM (GMT-08:00)
To: Ryan Hamel 
Cc: nanog@nanog.org
Subject: Re: Static Routing 172.16.0.0/32



On Thu, Dec 7, 2017 at 10:13 PM, Ryan Hamel 
> wrote:
A colleague of mine has static routed 172.16.0.0/32 to a 
usable IP address, to have a single known IP address be static routed to a 
regions closest server. While I understand the IP address does work (pings and 
what not), I don't feel this should be the proper IP address used, but 
something more feasible like a usable IP in a dedicated range 
(172.31.0.0/24 for example).

Hi Ryan,

Some clarifications:

1. You say, "static routed to a regions closest server." What do you mean by 
that? A static-routed anycast address?

2. In what reachability context? Is this a private network? An ISP network 
where the reachability should be the ISP and its customers?

Regards,
Bill Herrin


--
William Herrin  her...@dirtside.com 
 b...@herrin.us
Dirtside Systems . Web: 


Re: Static Routing 172.16.0.0/32

2017-12-08 Thread Job Snijders
On Fri, Dec 8, 2017 at 10:44 PM, Ken Chase  wrote:
> why not use 192.0.2.0/24 addrs?
>
> lots of other ranges you could probably use safely.
>
>https://en.wikipedia.org/wiki/Reserved_IP_addresses
>
> Using .0 you're asking to exercise bugs and undefined implimentation choices
> of various tcp stacks and resolvers out there on myriad devices. Clever 
> collision
> avoidance, but relies on a prayer.

Please stop spreading Fear, Uncertainty and Doubt about valid CIDR
addresses. :-)

> (IIRC try setting an NS record to resolve to 127.0.0.255 on windows 95 - it
> used to lock the OS up fun times. Someone had pointed some popular domain
> at us by accident, and having no entry and no negative caching of the day
> meant we were being hammerred on our 10mbps uplink, had to set something to
> get cached, so we did... several hours later a microsoft engineer called us
> and pleaded with us to use a different IP. :)

Microsoft ended support for Windows 95 on December 31th 2001

Kind regards,

Job


Re: Static Routing 172.16.0.0/32

2017-12-08 Thread Ken Chase
why not use 192.0.2.0/24 addrs?

lots of other ranges you could probably use safely.

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

Using .0 you're asking to exercise bugs and undefined implimentation choices
of various tcp stacks and resolvers out there on myriad devices. Clever 
collision
avoidance, but relies on a prayer.

(IIRC try setting an NS record to resolve to 127.0.0.255 on windows 95 - it
used to lock the OS up fun times. Someone had pointed some popular domain
at us by accident, and having no entry and no negative caching of the day
meant we were being hammerred on our 10mbps uplink, had to set something to
get cached, so we did... several hours later a microsoft engineer called us
and pleaded with us to use a different IP. :)

/kc


On Fri, Dec 08, 2017 at 05:25:58PM -0500, William Herrin said:
  >On Fri, Dec 8, 2017 at 4:50 PM, Ryan Hamel  wrote:
  >>
  >> I'm not implying HTTP, I'm implying a static route at each sites private
  >layer 3 router (it'll move to BGP in the future). The repository server
  >listens on the IP as well.
  >>
  >> My original question was the fact of using 172.16.0.0/32 as a usable IP
  >address (not even caring about anycast).
  >
  >> Internal private network that is reachable by clients.
  >
  >Hi Ryan,
  >
  >Clients meaning employee computers or clients meaning other networks who
  >subscribe to your service and connect with a VPN?
  >
  >The the former, save yourself grief and use a different /32.
  >
  >For the latter, it's semi-clever. It neatly avoids the problem of customers
  >using the same RFC1918 addresses as you. Even if they're using a subnet
  >like 172.16.0.0/24, a /32 route can usually override that one address
  >without ill effect.
  >
  >It's only semi-clever because the .0 address is a corner case in the code
  >and corner cases are where bugs are most likely to happen.  And if you're
  >sending clients from that address to another host with a regular 172.16
  >address anyway...
  >
  >Regards,
  >Bill Herrin
  >
  >
  >
  >
  >>
  >>
  >>  Original message 
  >> From: William Herrin 
  >> Date: 12/8/17 1:45 PM (GMT-08:00)
  >> To: Ryan Hamel 
  >> Cc: nanog@nanog.org
  >> Subject: Re: Static Routing 172.16.0.0/32
  >>
  >> On Fri, Dec 8, 2017 at 4:37 PM, Ryan Hamel 
  >> wrote:
  >> > 1. A single known ip address that redirects to the closest internal repo
  >> server. 172.16.0.0/32 redirects to a usable subnet ip in 172.16.xx.xx by
  >> static route.
  >>
  >> Hi Ryan,
  >>
  >> Maybe if would help if you write the extended version because that's about
  >> as clear as mud. First you asked about routing. Now you imply HTTP.
  >>
  >> Regards,
  >> Bill Herrin
  >>
  >>
  >> --
  >> William Herrin  her...@dirtside.com  b...@herrin.us
  >> Dirtside Systems . Web: 
  >>
  >
  >
  >
  >-- 
  >William Herrin  her...@dirtside.com  b...@herrin.us
  >Dirtside Systems . Web: 

-- 
Ken Chase - m...@sizone.org Guelph Canada


Re: Static Routing 172.16.0.0/32

2017-12-08 Thread William Herrin
On Fri, Dec 8, 2017 at 4:50 PM, Ryan Hamel  wrote:
>
> I'm not implying HTTP, I'm implying a static route at each sites private
layer 3 router (it'll move to BGP in the future). The repository server
listens on the IP as well.
>
> My original question was the fact of using 172.16.0.0/32 as a usable IP
address (not even caring about anycast).

> Internal private network that is reachable by clients.

Hi Ryan,

Clients meaning employee computers or clients meaning other networks who
subscribe to your service and connect with a VPN?

The the former, save yourself grief and use a different /32.

For the latter, it's semi-clever. It neatly avoids the problem of customers
using the same RFC1918 addresses as you. Even if they're using a subnet
like 172.16.0.0/24, a /32 route can usually override that one address
without ill effect.

It's only semi-clever because the .0 address is a corner case in the code
and corner cases are where bugs are most likely to happen.  And if you're
sending clients from that address to another host with a regular 172.16
address anyway...

Regards,
Bill Herrin




>
>
>  Original message 
> From: William Herrin 
> Date: 12/8/17 1:45 PM (GMT-08:00)
> To: Ryan Hamel 
> Cc: nanog@nanog.org
> Subject: Re: Static Routing 172.16.0.0/32
>
> On Fri, Dec 8, 2017 at 4:37 PM, Ryan Hamel 
> wrote:
> > 1. A single known ip address that redirects to the closest internal repo
> server. 172.16.0.0/32 redirects to a usable subnet ip in 172.16.xx.xx by
> static route.
>
> Hi Ryan,
>
> Maybe if would help if you write the extended version because that's about
> as clear as mud. First you asked about routing. Now you imply HTTP.
>
> Regards,
> Bill Herrin
>
>
> --
> William Herrin  her...@dirtside.com  b...@herrin.us
> Dirtside Systems . Web: 
>



-- 
William Herrin  her...@dirtside.com  b...@herrin.us
Dirtside Systems . Web: 


Re: Static Routing 172.16.0.0/32

2017-12-08 Thread William Herrin
On Fri, Dec 8, 2017 at 4:37 PM, Ryan Hamel  wrote:
> 1. A single known ip address that redirects to the closest internal repo
server. 172.16.0.0/32 redirects to a usable subnet ip in 172.16.xx.xx by
static route.

Hi Ryan,

Maybe if would help if you write the extended version because that's about
as clear as mud. First you asked about routing. Now you imply HTTP.

Regards,
Bill Herrin


-- 
William Herrin  her...@dirtside.com  b...@herrin.us
Dirtside Systems . Web: 


Re: Static Routing 172.16.0.0/32

2017-12-08 Thread William Herrin
On Thu, Dec 7, 2017 at 10:13 PM, Ryan Hamel 
wrote:

> A colleague of mine has static routed 172.16.0.0/32 to a usable IP
> address, to have a single known IP address be static routed to a regions
> closest server. While I understand the IP address does work (pings and what
> not), I don't feel this should be the proper IP address used, but something
> more feasible like a usable IP in a dedicated range (172.31.0.0/24 for
> example).
>

Hi Ryan,

Some clarifications:

1. You say, "static routed to a regions closest server." What do you mean
by that? A static-routed anycast address?

2. In what reachability context? Is this a private network? An ISP network
where the reachability should be the ISP and its customers?

Regards,
Bill Herrin


-- 
William Herrin  her...@dirtside.com  b...@herrin.us
Dirtside Systems . Web: 


Re: Static Routing 172.16.0.0/32

2017-12-08 Thread Job Snijders
On Fri, 8 Dec 2017 at 23:09, Christopher Morrow 
wrote:

> On Fri, Dec 8, 2017 at 3:02 PM, Job Snijders  wrote:
>
Nothing wrong with using xxx.0 or xxx::0 in the context of a host route
>> (/32 or /128).
>>
>
> note that in times past (perhaps even now marked historical) there were
> platforms which got unhappy with network/broadcast addresses being used as
> host addresses...
>
> At least some windows platforms balked at .0 or .255 host addresses (even
> if that address was 'off-net' from them).
>
> maybe this is all history though :)
>

It is 2017... if you encounter such platforms you take them out back and
“set them free”. :-)

We can, and must, expect CIDR compliance these days.

Kind regards,

Job


Re: Static Routing 172.16.0.0/32

2017-12-08 Thread Christopher Morrow
On Fri, Dec 8, 2017 at 3:02 PM, Job Snijders  wrote:

> Nothing wrong with using xxx.0 or xxx::0 in the context of a host route
> (/32 or /128).
>

note that in times past (perhaps even now marked historical) there were
platforms which got unhappy with network/broadcast addresses being used as
host addresses...

At least some windows platforms balked at .0 or .255 host addresses (even
if that address was 'off-net' from them).

maybe this is all history though :)


Re: Static Routing 172.16.0.0/32

2017-12-08 Thread valdis . kletnieks
On Fri, 08 Dec 2017 03:13:57 +, Ryan Hamel said:
> Greetings,

> A colleague of mine has static routed 172.16.0.0/32 to a usable IP address,
> to have a single known IP address be static routed to a regions closest 
> server.
> While I understand the IP address does work (pings and what not), I don't feel
> this should be the proper IP address used, but something more feasible like a
> usable IP in a dedicated range (172.31.0.0/24 for example).

Probably depends on what your colleague is trying to do.  Nothing in the
rules says the .0 address on a subnet is reserved (though you're in for a
surprise if there's any gear still on the net with a 4.2BSD stack).

> I would to hear everyone's thoughts on this, as this the first IP address in
> an RFC1918 range.

At some point, some chucklehead  is going to look at that .0.0 and mentally 
think /16,
and things will go pear-shaped pretty quickly



pgpARlFxa0l_N.pgp
Description: PGP signature


Re: Static Routing 172.16.0.0/32

2017-12-08 Thread Job Snijders
Nothing wrong with using xxx.0 or xxx::0 in the context of a host route
(/32 or /128).


Re: Static Routing 172.16.0.0/32

2017-12-08 Thread Hunter Fuller
I think I'd rate this one as "gross but technically not breaking any rules
I suppose." (I couldn't find any at first glance, anyway.)

On Fri, Dec 8, 2017 at 1:55 PM Ryan Hamel  wrote:

> Greetings,
>
> A colleague of mine has static routed 172.16.0.0/32 to a usable IP
> address, to have a single known IP address be static routed to a regions
> closest server. While I understand the IP address does work (pings and what
> not), I don't feel this should be the proper IP address used, but something
> more feasible like a usable IP in a dedicated range (172.31.0.0/24 for
> example).
>
> I would to hear everyone's thoughts on this, as this the first IP address
> in an RFC1918 range.
>
> Thanks,
>
> --
> Ryan Hamel
> ryan.ha...@quadranet.com | +1 (888) 578-2372 <(888)%20578-2372>
> QuadraNet, Inc. | Dedicated Servers, Colocation, Cloud
>
> --

--
Hunter Fuller
Network Engineer
VBH Annex B-5
+1 256 824 5331

Office of Information Technology
The University of Alabama in Huntsville
Systems and Infrastructure


Static Routing 172.16.0.0/32

2017-12-08 Thread Ryan Hamel
Greetings,

A colleague of mine has static routed 172.16.0.0/32 to a usable IP address, to 
have a single known IP address be static routed to a regions closest server. 
While I understand the IP address does work (pings and what not), I don't feel 
this should be the proper IP address used, but something more feasible like a 
usable IP in a dedicated range (172.31.0.0/24 for example).

I would to hear everyone's thoughts on this, as this the first IP address in an 
RFC1918 range.

Thanks,

--
Ryan Hamel
ryan.ha...@quadranet.com | +1 (888) 578-2372
QuadraNet, Inc. | Dedicated Servers, Colocation, Cloud



Re: Poor speed to AWS

2017-12-08 Thread Luke
Hey Eric, have you tried contacting their NOC?

amzn-noc-cont...@amazon.com 
https://peeringdb.com/net/1418 

> On 7 Dec 2017, at 13:08, Eric Dugas  wrote:
> 
> Anyone from AWS can contact me off-list? We peer with AS16509 in Montreal and 
> Toronto and get really good speed to US-EAST-1, US-EAST-2 and of course 
> CA-CENTRAL-1 but anything else outside the east coast (US-WEST-1 and 
> US-WEST-2 more precisely) is about ten times slower even on multi-threaded 
> HTTP(S) or SCP/SFTP transfers. Goes through two of our transit providers, 
> Telia and Zayo.
> 
> Thanks
> Eric



Re: Qrator Radar - Peerings

2017-12-08 Thread Alexander Azimov
Job, thank you for the intro. :)

Dear Mike, the radar project is operating its own BGP collector system
which improves when we have more sessions and loses data, when BGP sessions
are going down. While it's overall amount is constantly growing (it reached
400 a month ago), there are sessions that disconnect from our RR.
Visibility of peering relations is most vulnerable in this case because
they are not globally visible. So, when one ISP shutdowns session there may
be a decrease in numbers of peers for this ISP and its providers.

At the moment we are not contacting users when BGP session goes down, maybe
we should reconsider these politics.

6 дек. 2017 г. 5:47 PM пользователь "Job Snijders" 
написал:

On Wed, 6 Dec 2017 at 15:42, Mike Hammett  wrote:

> I haven't brought it up with them, no. I didn't think it was a mass issue
> until last night. I wanted to check with other users before I went to them.
> Maybe I should have done the opposite.



Yes, you should’ve. The Qrator folks are good people.

Kind regards,

Job


Geolocation: IPv4 Subnet blocked by HULU, and others

2017-12-08 Thread Michael Crapse
I am a local WISP. And my customers have trouble reaching Hulu, Disney now,
and previously netflix and amazon prime(both resolved).
I have emailed, mailed, and called both HULU and Disney now to get my
196.53.96.0/22 subnet unblacklisted as a VPN provider(no longer so) from
their services. They have replied saying it takes 3-5 days to resolve the
issue, that was several weeks ago. Can i get contact from those two
services that can help my customers reach their services, thank you.


Thank you for the help.
-Michael


Weekly Routing Table Report

2017-12-08 Thread Routing Analysis Role Account
This is an automated weekly mailing describing the state of the Internet
Routing Table as seen from APNIC's router in Japan.

The posting is sent to APOPS, NANOG, AfNOG, SANOG, PacNOG, SAFNOG, CaribNOG
TZNOG, MENOG, BJNOG, SDNOG, CMNOG, LACNOG, IRNOG and the RIPE Routing WG.

Daily listings are sent to bgp-st...@lists.apnic.net

For historical data, please see http://thyme.rand.apnic.net.

If you have any comments please contact Philip Smith .

Routing Table Report   04:00 +10GMT Sat 09 Dec, 2017

Report Website: http://thyme.rand.apnic.net
Detailed Analysis:  http://thyme.rand.apnic.net/current/

Analysis Summary


BGP routing table entries examined:  674032
Prefixes after maximum aggregation (per Origin AS):  262246
Deaggregation factor:  2.57
Unique aggregates announced (without unneeded subnets):  326110
Total ASes present in the Internet Routing Table: 59288
Prefixes per ASN: 11.37
Origin-only ASes present in the Internet Routing Table:   51190
Origin ASes announcing only one prefix:   22549
Transit ASes present in the Internet Routing Table:8098
Transit-only ASes present in the Internet Routing Table:243
Average AS path length visible in the Internet Routing Table:   4.4
Max AS path length visible:  30
Max AS path prepend of ASN ( 23679)  26
Prefixes from unregistered ASNs in the Routing Table:89
Number of instances of unregistered ASNs:89
Number of 32-bit ASNs allocated by the RIRs:  20830
Number of 32-bit ASNs visible in the Routing Table:   16674
Prefixes from 32-bit ASNs in the Routing Table:   68623
Number of bogon 32-bit ASNs visible in the Routing Table:10
Special use prefixes present in the Routing Table:1
Prefixes being announced from unallocated address space:350
Number of addresses announced to Internet:   2861476514
Equivalent to 170 /8s, 142 /16s and 170 /24s
Percentage of available address space announced:   77.3
Percentage of allocated address space announced:   77.3
Percentage of available address space allocated:  100.0
Percentage of address space in use by end-sites:   98.8
Total number of prefixes smaller than registry allocations:  223308

APNIC Region Analysis Summary
-

Prefixes being announced by APNIC Region ASes:   185027
Total APNIC prefixes after maximum aggregation:   53147
APNIC Deaggregation factor:3.48
Prefixes being announced from the APNIC address blocks:  184153
Unique aggregates announced from the APNIC address blocks:76925
APNIC Region origin ASes present in the Internet Routing Table:8526
APNIC Prefixes per ASN:   21.60
APNIC Region origin ASes announcing only one prefix:   2392
APNIC Region transit ASes present in the Internet Routing Table:   1230
Average APNIC Region AS path length visible:4.5
Max APNIC Region AS path length visible: 29
Number of APNIC region 32-bit ASNs visible in the Routing Table:   3394
Number of APNIC addresses announced to Internet:  767380514
Equivalent to 45 /8s, 189 /16s and 76 /24s
APNIC AS Blocks4608-4864, 7467-7722, 9216-10239, 17408-18431
(pre-ERX allocations)  23552-24575, 37888-38911, 45056-46079, 55296-56319,
   58368-59391, 63488-64098, 64297-64395, 131072-137529
APNIC Address Blocks 1/8,  14/8,  27/8,  36/8,  39/8,  42/8,  43/8,
49/8,  58/8,  59/8,  60/8,  61/8, 101/8, 103/8,
   106/8, 110/8, 111/8, 112/8, 113/8, 114/8, 115/8,
   116/8, 117/8, 118/8, 119/8, 120/8, 121/8, 122/8,
   123/8, 124/8, 125/8, 126/8, 133/8, 150/8, 153/8,
   163/8, 171/8, 175/8, 180/8, 182/8, 183/8, 202/8,
   203/8, 210/8, 211/8, 218/8, 219/8, 220/8, 221/8,
   222/8, 223/8,

ARIN Region Analysis Summary


Prefixes being announced by ARIN Region ASes:201752
Total ARIN prefixes after maximum aggregation:97101
ARIN Deaggregation factor: 2.08
Prefixes being announced from the ARIN address blocks:   203119
Unique aggregates announced from the ARIN address blocks: 95080
ARIN Region origin ASes present in the Internet Routing Table:18043
ARIN Prefixes per ASN:   

FCC Seeks Comment on 2017 Hurricane Season Response Efforts

2017-12-08 Thread Sean Donelan


PUBLIC SAFETY AND HOMELAND SECURITY BUREAU SEEKS COMMENT ON
RESPONSE EFFORTS UNDERTAKEN DURING 2017 HURRICANE SEASON
PS Docket No. 17-344
Comments Due: January 22, 2018
Reply Comments Due: February 21, 2018

https://www.fcc.gov/document/fcc-seeks-comment-2017-hurricane-season-response-efforts

A. Questions Regarding Impacts to Communications Infrastructure

B. Questions Regarding the FCC’s Response

C. Questions Regarding Communications Service User Experience

D. Questions Regarding Communications Service Provider Experience