Re: DamnTest: ignore

[Andrew Kirch]

Is this the thread where I go for the high score in profanity?
You know, for testing purposes?

Owen: I think that NANOG would get huge value from syndicating my Facebook
wall, don't you?

On Fri, Sep 11, 2015 at 1:43 AM, Owen DeLong  wrote:

> Is Damn supposed to get through or is it supposed to get dammed up in the
> system?
>
> Owen
>
> > On Sep 10, 2015, at 11:43 , Josh Luthman 
> wrote:
> >
> > cogeco.com is to blame
> >
> >
> >
> > Josh Luthman
> > Office: 937-552-2340
> > Direct: 937-552-2343
> > 1100 Wayne St
> > Suite 1337
> > Troy, OH 45373
> >
> > On Thu, Sep 10, 2015 at 2:28 PM, Nathan Anderson 
> wrote:
> >
> >> On Thu, Sep 10, 2015, mikea wrote:
> >>
> >>> This post includes the word Damn.
> >>>
> >>> damn
> >>
> >> Well, dayum.
> >>
> >> -- Nathan
> >>
> >>
>
>

Re: Extraneous "legal" babble--and my reaction to it.

[Mike Hale]

I see black on white...

On Thu, Sep 10, 2015 at 6:35 PM, Keith Medcalf  wrote:
>
>> "Email Disclaimers: Legal Effect in American Courts"
>> - http://www.rhlaw.com/blog/legal-effect-of-boilerplate-email-disclaimers/
>
> Dark grey text on a black background is unreadable.
> Plonk goes the website.
>
>
>
>



-- 
09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0

Re: WiFI on utility poles

[Bryan Fields]

On 9/10/15 1:15 PM, Mike Hammett wrote:
> The tower-deployed AP can see the cable wireless APs for miles and can see
> a few dozen of them at any one time. Given the goal of full modulation at
> all times for optimal use of spectrum and dollars, the ever increasing
> noise from the cable APs makes this a challenge. You need 25 to 30 dB to
> maintain full modulation and that's increasingly difficult when you hear
> cable APs everywhere at -70.

Frankly this is what the WISP's get for deploying on Part 15 spectrum.
It's a race to the bottom, and always has been.

In 1999-2000 2.4 Part 15 was golden with FHSS, and we played nice with the
Karlnet guys.  Then the muni's came in with their 2.4 networks and killed 2.4
for anything decent.  Canopy operators came in like a thousand people blinking
in unison and crapped up 5.8.  We all retreated to 5.3 and then 5.4 opened up
and life was good.

900 was never an option as even in rural areas you had to deal with paging at
929 mhz blowing out the front end of your receiver.  We made it work with
stupid long antennas and horizontal polarization, but that was only to go 2
miles through trees.  Remember waverider?

Now it's happening again; get licensed spectrum or go home.
-- 
Bryan Fields

727-409-1194 - Voice
727-214-2508 - Fax
http://bryanfields.net

Re: NetFlow - path from Routers to Collector

[James Bensley]

On 1 September 2015 at 16:33, Serge Vautour  wrote:
> Hello,
>
> For those than run Internet connected routers, how do you get your NetFlow 
> data from the routers to your collectors? Do you let the flow export traffic 
> use the same links as your customer traffic to route back to central 
> collectors? Or do you send this traffic over private network management type 
> path? If you send this traffic over the "Internet" (within your AS), are you 
> worried about security?
>
> Thanks,
> Serge


Hi Serge,

Not encountered any worries regarding security, typically
NetFow/ipfix/sFlow/etc is inside a management MPLS VPN so it is
segregated from customer VPNs through the network.

For the physical transport of the data, collecting the data via your
OOB network is probably preferred however "it depends".

Do you use NetFlow internally only or offer it as a chargeable
service? Do you also graph traffic stats via SNMP too? And so on and
so forth...

In past experience, NetFlow data was exported over the productive
links (the links also carrying customer data being measured using
NetFlow) without issue. I recall two occasions a DDoS disrupted the
NetFlow collecting because the DDoS traversed those links that are
being monitored and carrying their own NetFlow traffic. However SNMP
graphing was via the OOB network so we didn't really lose any vital
visibility. So we could still see from the like 1000% increase in
traffic which links along the network were being affected. A distress
call from the customer being DDoS also helps :)

Another part of the "it depends" puzzle is how much data you are
collecting via NetFlow? Again in a part experience we were testing
collecting everything (as much as we could), every single packet
header (no payload data though), rather than sampling say 1 in 10
packets for example. We only got as far as testing this in the lab but
one issue it threw up was we could generate several Mbps of NetFlow
traffic. Some PoPs have ADSL for OOB and wouldn't have been able to
support that so sites with ADSL or 3G OOB links would need the OOB
link upgrading, that required additional Capex, cue management budget
wrestle, blah blah...

Cheers,
James.

Cisco ASA

[A MEKKAOUI]

HI

 

Do you know any seller of Cisco ASA (used and new) please? Please contact me
offline.

 

Thank you

 

KARIM M.

 

RE: Cisco ASA

[Murat Kaipov]

Hello Dear.
You can you cisco partner locator
https://tools.cisco.com/WWChannels/LOCATR/openBasicSearch.do
It will be more productively. 

-Original Message-
From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of A MEKKAOUI
Sent: Friday, September 11, 2015 3:51 PM
To: 'NANOG'
Subject: Cisco ASA

HI

 

Do you know any seller of Cisco ASA (used and new) please? Please contact me
offline.

 

Thank you

 

KARIM M.

 

RE: NetFlow - path from Routers to Collector

[Erik Sundberg]

Mainly management type traffic over an Out of band Management Network. This way 
during and outage we don't miss any Netflow and SNMP Queries and more 
importantly we can still access the router.

In the past I have also setup a Management VRF, but tend to stay away from 
this. During an outage you end up losing data or visibility while routes 
reconverge.

-Original Message-
From: NANOG [mailto:nanog-bounces+esundberg=nitelusa@nanog.org] On Behalf 
Of James Bensley
Sent: Friday, September 11, 2015 3:35 AM
To: se...@nbnet.nb.ca; nanog@nanog.org
Subject: Re: NetFlow - path from Routers to Collector

On 1 September 2015 at 16:33, Serge Vautour  wrote:
> Hello,
>
> For those than run Internet connected routers, how do you get your NetFlow 
> data from the routers to your collectors? Do you let the flow export traffic 
> use the same links as your customer traffic to route back to central 
> collectors? Or do you send this traffic over private network management type 
> path? If you send this traffic over the "Internet" (within your AS), are you 
> worried about security?
>
> Thanks,
> Serge


Hi Serge,

Not encountered any worries regarding security, typically 
NetFow/ipfix/sFlow/etc is inside a management MPLS VPN so it is segregated from 
customer VPNs through the network.

For the physical transport of the data, collecting the data via your OOB 
network is probably preferred however "it depends".

Do you use NetFlow internally only or offer it as a chargeable service? Do you 
also graph traffic stats via SNMP too? And so on and so forth...

In past experience, NetFlow data was exported over the productive links (the 
links also carrying customer data being measured using
NetFlow) without issue. I recall two occasions a DDoS disrupted the NetFlow 
collecting because the DDoS traversed those links that are being monitored and 
carrying their own NetFlow traffic. However SNMP graphing was via the OOB 
network so we didn't really lose any vital visibility. So we could still see 
from the like 1000% increase in traffic which links along the network were 
being affected. A distress call from the customer being DDoS also helps :)

Another part of the "it depends" puzzle is how much data you are collecting via 
NetFlow? Again in a part experience we were testing collecting everything (as 
much as we could), every single packet header (no payload data though), rather 
than sampling say 1 in 10 packets for example. We only got as far as testing 
this in the lab but one issue it threw up was we could generate several Mbps of 
NetFlow traffic. Some PoPs have ADSL for OOB and wouldn't have been able to 
support that so sites with ADSL or 3G OOB links would need the OOB link 
upgrading, that required additional Capex, cue management budget wrestle, blah 
blah...

Cheers,
James.



CONFIDENTIALITY NOTICE: This e-mail transmission, and any documents, files or 
previous e-mail messages attached to it may contain confidential information 
that is legally privileged. If you are not the intended recipient, or a person 
responsible for delivering it to the intended recipient, you are hereby 
notified that any disclosure, copying, distribution or use of any of the 
information contained in or attached to this transmission is STRICTLY 
PROHIBITED. If you have received this transmission in error please notify the 
sender immediately by replying to this e-mail. You must destroy the original 
transmission and its attachments without reading or saving in any manner. Thank 
you.

routability of longer-then-24 prefixes out of ARIN's 23.128/10 block

[Emile Aben]

Hi,

We took another peek at routability of longer-then-24-prefixes from
ARIN's 23.128/10 block:

https://labs.ripe.net/Members/emileaben/has-the-routability-of-longer-than-24-prefixes-changed

In case people missed previous announcements about this IPv4 address block:
Per ARIN policy this block is set aside to facilitate IPv6 deployment.
It is subject to a minimum size allocation of /28 and a maximum size
allocation of /24

best regards,
Emile Aben
RIPE NCC

Re: WiFI on utility poles

[Mike Hammett]

I'm not suggesting that WISPs have exclusive-use spectrum at all. It isn't 
necessary, just cooperation and design best practices. For example, there 
aren't likely to be any people a hundred or two hundred feet in the air where 
the towers are, so why do the cable companies' radiation patterns include up 
there? Get yourself some higher gain antennas that focus their power in the 
lower 180* of elevation. I do understand that the cables these are typically 
mounted to will sway, so just put the AP closer to the pole where the sway will 
be less. 

Where would you suggest WISPs deploy? In spectrum that costs so much that it 
ruins the business model of being a WISP? Say there's a new WISP that wants to 
start, how could they possibly get spectrum if Clear bought it all up 10 years 
ago? At least there's potential with the upcoming 3550 - 3650 MHz. Then again, 
the licensed channels are tiny, so real amounts of bandwidth can't really be 
delivered. The government has been crapping on the TVWS for the last ten years 
as well. Then the areas that have foliage issues will have some relief, but 
there's always some special interest or another rearing their heads in the way, 
spewing FUD. 

Canopy operators are WISPs and their platform has been one of the most 
successful WISP platforms. So successful in fact that sync capability has been 
on the demanded features list for all other vendors. 


Spoken by a WISP that's been running in rural and suburban areas for the past 
11 years. 




- 
Mike Hammett 
Intelligent Computing Solutions 
http://www.ics-il.com 



Midwest Internet Exchange 
http://www.midwest-ix.com 


- Original Message -

From: "Bryan Fields"  
To: "Mike Hammett" , "Scott Helms"  
Cc: "Corey Petrulich" , "Kenneth 
Falkenstein" , "NANOG mailing list" 
 
Sent: Friday, September 11, 2015 2:56:18 AM 
Subject: Re: WiFI on utility poles 

On 9/10/15 1:15 PM, Mike Hammett wrote: 
> The tower-deployed AP can see the cable wireless APs for miles and can see 
> a few dozen of them at any one time. Given the goal of full modulation at 
> all times for optimal use of spectrum and dollars, the ever increasing 
> noise from the cable APs makes this a challenge. You need 25 to 30 dB to 
> maintain full modulation and that's increasingly difficult when you hear 
> cable APs everywhere at -70. 

Frankly this is what the WISP's get for deploying on Part 15 spectrum. 
It's a race to the bottom, and always has been. 

In 1999-2000 2.4 Part 15 was golden with FHSS, and we played nice with the 
Karlnet guys. Then the muni's came in with their 2.4 networks and killed 2.4 
for anything decent. Canopy operators came in like a thousand people blinking 
in unison and crapped up 5.8. We all retreated to 5.3 and then 5.4 opened up 
and life was good. 

900 was never an option as even in rural areas you had to deal with paging at 
929 mhz blowing out the front end of your receiver. We made it work with 
stupid long antennas and horizontal polarization, but that was only to go 2 
miles through trees. Remember waverider? 

Now it's happening again; get licensed spectrum or go home. 
-- 
Bryan Fields 

727-409-1194 - Voice 
727-214-2508 - Fax 
http://bryanfields.net 

Re: routability of longer-then-24 prefixes out of ARIN's 23.128/10 block

[William Herrin]

On Fri, Sep 11, 2015 at 9:23 AM, Emile Aben  wrote:
> We took another peek at routability of longer-then-24-prefixes from
> ARIN's 23.128/10 block:
>
> https://labs.ripe.net/Members/emileaben/has-the-routability-of-longer-than-24-prefixes-changed

Good work. Thanks!

TLDR: 90%-100% visibility for /24, 10%-30% visibility for longer.

Regards,
Bill Herrin

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

Status of Inerail?

[Tobin Burnham]

Does anyone know the status of Inerail (AS33031)?

All of their ASNs and prefixes disappeared on 9/1/2015 according to
http://bgp.he.net/AS33031

All of the contact emails I found seemed to have been hosted under the ASNs
and prefixes attributed to Inerail which are now gone from the Internet.

I was looking for information on the Philadelphia Internet Exchange which I
think they are/were running.

Re: Status of Inerail?

[Job Snijders]

On Thu, Sep 10, 2015 at 10:53:01PM -0400, Tobin Burnham wrote:
> Does anyone know the status of Inerail (AS33031)?

No, but their NLNOG RING node is offline too: inerail01.ring.nlnog.net

> All of their ASNs and prefixes disappeared on 9/1/2015 according to
> http://bgp.he.net/AS33031
> 
> All of the contact emails I found seemed to have been hosted under the
> ASNs and prefixes attributed to Inerail which are now gone from the
> Internet.

You could try n...@inerail.net for which MX is handled by google.

Kind regards,

Job

Ethical Obligations in Internet Operations

[Jan Schaumann]

Hello,

I'm currently preparing a talk on "Ethical Obligations in Internet
Operations"[1] for Velocity NY in October.  In preparation, I've put
together a short, anonymous survey for people involved in "Internet
Operations":

https://docs.google.com/forms/d/1UmJtkj1dsFVjZx2yBC6zZZi1tIuObuVZxQd3oWxGk4o/viewform

After circling this survey in the SysAdmin/DevOps/SRE communities, I'd
love to get some feedback from the people who are operating the core
infrastructure of the internet, ie your esteemed selves.

If you could take the five minutes to fill out this form, that would be
a great help for me.

If you'd like to share this in your social or professional circles,
that'd be wonderful, too.  You could:

- forward this email
- directly forward or link to the form above
- link to
  https://www.netmeister.org/blog/velocity-ny2015-questionnaire.html for
  a bit more context
- retweet / quote either of these tweets:
  https://twitter.com/jschauma/status/628393619196641280
  https://twitter.com/jschauma/status/628646443033694208

Of course I also welcome comments directly to me via email.  Any and all
feedback will be treated entirely confidentially.

Many thanks in advance for your help!
-Jan

[1] https://www.netmeister.org/blog/velocity-ny2015-accepted.html 

Weekly Routing Table Report

[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, AusNOG, SANOG, PacNOG,
CaribNOG and the RIPE Routing Working Group.

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 12 Sep, 2015

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

Analysis Summary


BGP routing table entries examined:  562922
Prefixes after maximum aggregation (per Origin AS):  210448
Deaggregation factor:  2.67
Unique aggregates announced (without unneeded subnets):  273421
Total ASes present in the Internet Routing Table: 51406
Prefixes per ASN: 10.95
Origin-only ASes present in the Internet Routing Table:   36646
Origin ASes announcing only one prefix:   16108
Transit ASes present in the Internet Routing Table:6404
Transit-only ASes present in the Internet Routing Table:170
Average AS path length visible in the Internet Routing Table:   4.5
Max AS path length visible:  45
Max AS path prepend of ASN ( 55644)  41
Prefixes from unregistered ASNs in the Routing Table:  1080
Unregistered ASNs in the Routing Table: 411
Number of 32-bit ASNs allocated by the RIRs:  10940
Number of 32-bit ASNs visible in the Routing Table:8356
Prefixes from 32-bit ASNs in the Routing Table:   31443
Number of bogon 32-bit ASNs visible in the Routing Table:19
Special use prefixes present in the Routing Table:1
Prefixes being announced from unallocated address space:438
Number of addresses announced to Internet:   2808516288
Equivalent to 167 /8s, 102 /16s and 142 /24s
Percentage of available address space announced:   75.9
Percentage of allocated address space announced:   75.9
Percentage of available address space allocated:  100.0
Percentage of address space in use by end-sites:   97.6
Total number of prefixes smaller than registry allocations:  185904

APNIC Region Analysis Summary
-

Prefixes being announced by APNIC Region ASes:   142701
Total APNIC prefixes after maximum aggregation:   39688
APNIC Deaggregation factor:3.60
Prefixes being announced from the APNIC address blocks:  150100
Unique aggregates announced from the APNIC address blocks:59677
APNIC Region origin ASes present in the Internet Routing Table:5093
APNIC Prefixes per ASN:   29.47
APNIC Region origin ASes announcing only one prefix:   1206
APNIC Region transit ASes present in the Internet Routing Table:892
Average APNIC Region AS path length visible:4.4
Max APNIC Region AS path length visible: 38
Number of APNIC region 32-bit ASNs visible in the Routing Table:   1618
Number of APNIC addresses announced to Internet:  752237184
Equivalent to 44 /8s, 214 /16s and 58 /24s
Percentage of available APNIC address space announced: 87.9

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, 131072-135580
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:180262
Total ARIN prefixes after maximum aggregation:88353
ARIN Deaggregation factor: 2.04
Prefixes being announced from the ARIN address blocks:   183222
Unique aggregates announced from the ARIN address blocks: 86012
ARIN Region origin ASes present in the Internet Routing Table:16575
ARIN Prefixes per ASN:

Re: BGAN Optimized Laptops

[Mark Milhollan]

On Thu, 10 Sep 2015, Matthew Petach wrote:

>Just wanted to clear one point up...
>
>The web is *not* a "push" model; it's a "pull" model.

Mostly true, yet there's that little bit that makes it not total truth.

HTTP/2 has push, where instead of waiting for a browser to decide which 
elements to fetch a server can send anything it likes, the basic theory 
being that "everyone" will request certain/all objects so sending them 
without waiting for the requests will enhance performance.  HTTP/2 -- 
derived from / started as SPDY -- became a standard in May and is 
supported by various servers and clients.

WebSockets should probably be mentioned as well.

And the even older content replacing push (ca '95) -- though seldom used 
it is still supported by some browsers.


/mark

The Cidr Report

[cidr-report]

This report has been generated at Fri Sep 11 21:14:56 2015 AEST.
The report analyses the BGP Routing Table of AS2.0 router
and generates a report on aggregation potential within the table.

Check http://www.cidr-report.org/2.0 for a current version of this report.

Recent Table History
Date  PrefixesCIDR Agg
04-09-15566067  307402
05-09-15566061  307392
06-09-15565794  307423
07-09-15566335  307606
08-09-15566475  307703
09-09-15565912  307968
10-09-15566536  310111
11-09-15571301  310413


AS Summary
 51682  Number of ASes in routing system
 20503  Number of ASes announcing only one prefix
  5598  Largest number of prefixes announced by an AS
AS4538 : ERX-CERNET-BKB China Education and Research Network 
Center,CN
  120969728  Largest address span announced by an AS (/32s)
AS4134 : CHINANET-BACKBONE No.31,Jin-rong Street,CN


Aggregation Summary
The algorithm used in this report proposes aggregation only
when there is a precise match using the AS path, so as 
to preserve traffic transit policies. Aggregation is also
proposed across non-advertised address space ('holes').

 --- 11Sep15 ---
ASnumNetsNow NetsAggr  NetGain   % Gain   Description

Table 571610   310390   26122045.7%   All ASes

AS22773 3181  174 300794.5%   ASN-CXA-ALL-CCI-22773-RDC -
   Cox Communications Inc.,US
AS4538  5598 2804 279449.9%   ERX-CERNET-BKB China Education
   and Research Network
   Center,CN
AS6389  2695   70 262597.4%   BELLSOUTH-NET-BLK -
   BellSouth.net Inc.,US
AS17974 2710   90 262096.7%   TELKOMNET-AS2-AP PT
   Telekomunikasi Indonesia,ID
AS39891 2474   20 245499.2%   ALJAWWALSTC-AS Saudi Telecom
   Company JSC,SA
AS7545  2930  636 229478.3%   TPG-INTERNET-AP TPG Telecom
   Limited,AU
AS28573 2263  133 213094.1%   NET Serviços de Comunicação
   S.A.,BR
AS9394  2099  205 189490.2%   CTTNET China TieTong
   Telecommunications
   Corporation,CN
AS4766  3004 1274 173057.6%   KIXS-AS-KR Korea Telecom,KR
AS10620 3369 1647 172251.1%   Telmex Colombia S.A.,CO
AS9808  1592   78 151495.1%   CMNET-GD Guangdong Mobile
   Communication Co.Ltd.,CN
AS6983  1739  247 149285.8%   ITCDELTA - Earthlink, Inc.,US
AS4755  2042  559 148372.6%   TATACOMM-AS TATA
   Communications formerly VSNL
   is Leading ISP,IN
AS20115 1881  408 147378.3%   CHARTER-NET-HKY-NC - Charter
   Communications,US
AS3356  2547 1224 132351.9%   LEVEL3 - Level 3
   Communications, Inc.,US
AS9498  1387  119 126891.4%   BBIL-AP BHARTI Airtel Ltd.,IN
AS18566 2147  956 119155.5%   MEGAPATH5-US - MegaPath
   Corporation,US
AS4323  1589  405 118474.5%   TWTC - tw telecom holdings,
   inc.,US
AS4788  1220   69 115194.3%   TMNET-AS-AP TM Net, Internet
   Service Provider,MY
AS4812  1575  524 105166.7%   CHINANET-SH-AP China Telecom
   (Group),CN
AS7303  1563  522 104166.6%   Telecom Argentina S.A.,AR
AS7552  1427  388 103972.8%   VIETEL-AS-AP Viettel
   Corporation,VN
AS4808  1544  512 103266.8%   CHINA169-BJ CNCGROUP IP
   network China169 Beijing
   Province Network,CN
AS22561 1374  347 102774.7%   CENTURYLINK-LEGACY-LIGHTCORE -
   CenturyTel Internet Holdings,
   Inc.,US
AS8151  1839  814 102555.7%   Uninet S.A. de C.V.,MX
AS8402  1011   24  98797.6%   CORBINA-AS OJSC "Vimpelcom",RU
AS38197 1444  462  98268.0%   SUNHK-DATA-AS-AP Sun Network
   (Hong Kong) Li

BGP Update Report

[cidr-report]

BGP Update Report
Interval: 03-Sep-15 -to- 10-Sep-15 (7 days)
Observation Point: BGP Peering with AS131072

TOP 20 Unstable Origin AS
Rank ASNUpds %  Upds/PfxAS-Name
 1 - AS9829   285339  5.8% 192.8 -- BSNL-NIB National Internet 
Backbone,IN
 2 - AS38197  139160  2.9%  95.6 -- SUNHK-DATA-AS-AP Sun Network 
(Hong Kong) Limited,HK
 3 - AS22059  127076  2.6%   18153.7 -- -Reserved AS-,ZZ
 4 - AS150594989  1.9%   11873.6 -- DNIC-AS-01505 - Headquarters, 
USAISC,US
 5 - AS53271   83037  1.7%4613.2 -- PHENIXCITYCABLE - Phenix 
Cable,US
 6 - AS21669   60362  1.2%6036.2 -- NJ-STATEWIDE-LIBRARY-NETWORK - 
New Jersey State Library,US
 7 - AS370956427  1.2%2089.9 -- NET-CITY-SA - City of San 
Antonio,US
 8 - AS199367   48572  1.0%   48572.0 -- AS_GBP Globe Business 
Publishing Limited,GB
 9 - AS10620   48284  1.0%  17.9 -- Telmex Colombia S.A.,CO
10 - AS800139492  0.8% 391.0 -- NET-ACCESS-CORP - Net Access 
Corporation,US
11 - AS25563   33722  0.7%8430.5 -- WEBLAND-AS Webland AG,CH
12 - AS28   31963  0.7%   15981.5 -- PIRUM-AS Pirum Systems 
Limited,GB
13 - AS840231641  0.7%  28.0 -- CORBINA-AS OJSC "Vimpelcom",RU
14 - AS30295   31095  0.6%3886.9 -- 2ICSYSTEMSINC - 2iC Systems 
Inc.,CA
15 - AS56115   30677  0.6% 432.1 -- NGGL-BD New Generation Graphics 
Limited,BD
16 - AS131090   30494  0.6% 448.4 -- CAT-IDC-4BYTENET-AS-AP 
 CAT TELECOM Public Company Ltd,CAT
,TH
17 - AS56636   29958  0.6%   29958.0 -- ASVEDARU VEDA Ltd.,RU
18 - AS24323   28924  0.6% 556.2 -- AAMRA-NETWORKS-AS-AP aamra 
networks limited,BD
19 - AS14522   27664  0.6%  50.1 -- Satnet,EC
20 - AS39891   26737  0.6%  16.8 -- ALJAWWALSTC-AS Saudi Telecom 
Company JSC,SA


TOP 20 Unstable Origin AS (Updates per announced prefix)
Rank ASNUpds %  Upds/PfxAS-Name
 1 - AS199367   48572  1.0%   48572.0 -- AS_GBP Globe Business 
Publishing Limited,GB
 2 - AS56636   29958  0.6%   29958.0 -- ASVEDARU VEDA Ltd.,RU
 3 - AS22059  127076  2.6%   18153.7 -- -Reserved AS-,ZZ
 4 - AS200671   17130  0.3%   17130.0 -- SKOK-JAWORZNO SKOK Jaworzno,PL
 5 - AS28   31963  0.7%   15981.5 -- PIRUM-AS Pirum Systems 
Limited,GB
 6 - AS150594989  1.9%   11873.6 -- DNIC-AS-01505 - Headquarters, 
USAISC,US
 7 - AS25563   33722  0.7%8430.5 -- WEBLAND-AS Webland AG,CH
 8 - AS404937867  0.2%7867.0 -- FACILITYSOURCEINC - 
FacilitySource,US
 9 - AS31357   14081  0.3%7040.5 -- TOMICA-AS Tomsk Information and 
Consulting Agency,RU
10 - AS375906639  0.1%6639.0 -- BCA-ASN,AO
11 - AS21669   60362  1.2%6036.2 -- NJ-STATEWIDE-LIBRARY-NETWORK - 
New Jersey State Library,US
12 - AS380004664  0.1%4664.0 -- CRISIL-AS [CRISIL 
Limited.Autonomous System],IN
13 - AS53271   83037  1.7%4613.2 -- PHENIXCITYCABLE - Phenix 
Cable,US
14 - AS374737841  0.2%3920.5 -- TELESOM,SO
15 - AS30295   31095  0.6%3886.9 -- 2ICSYSTEMSINC - 2iC Systems 
Inc.,CA
16 - AS201752   11583  0.2%3861.0 -- NLTG-AS NL Telecoms Group 
S.L.,ES
17 - AS242373746  0.1%3746.0 -- 
SIAM-CITY-CEMENT-PUBLIC-COMPANY-LIMITED Siam City Cement Public Company Limited 
(SCCC),TH
18 - AS1344383720  0.1%3720.0 -- AIRAAIFUL-AS-AP Aira & Aiful 
Public Company Limited,TH
19 - AS34   3223  0.1%3223.0 -- UDELNET - University of 
Delaware,US
20 - AS593162105  0.0%2105.0 -- AOL-BD aamra Outsourcing Ltd.,BD


TOP 20 Unstable Prefixes
Rank Prefix Upds % Origin AS -- AS Name
 1 - 76.191.107.0/24   63732  1.3%   AS22059 -- -Reserved AS-,ZZ
 2 - 64.34.125.0/2463334  1.2%   AS22059 -- -Reserved AS-,ZZ
 3 - 209.212.8.0/2460348  1.2%   AS21669 -- NJ-STATEWIDE-LIBRARY-NETWORK - 
New Jersey State Library,US
 4 - 185.19.144.0/22   48572  1.0%   AS199367 -- AS_GBP Globe Business 
Publishing Limited,GB
 5 - 192.135.223.0/24  39270  0.8%   AS8001  -- NET-ACCESS-CORP - Net Access 
Corporation,US
 6 - 185.38.132.0/24   31961  0.6%   AS28 -- PIRUM-AS Pirum Systems 
Limited,GB
 7 - 61.7.155.0/24 30302  0.6%   AS131090 -- CAT-IDC-4BYTENET-AS-AP 
 CAT TELECOM Public Company Ltd,CAT
,TH
 8 - 195.128.159.0/24  29958  0.6%   AS56636 -- ASVEDARU VEDA Ltd.,RU
 9 - 162.218.160.0/21  23086  0.5%   AS53271 -- PHENIXCITYCABLE - Phenix 
Cable,US
10 - 162.218.162.0/23  21738  0.4%   AS53271 -- PHENIXCITYCABLE - Phenix 
Cable,US
11 - 24.38.128.0/2019424  0.4%   AS53271 -- PHENIXCITYCABLE - Phenix 
Cable,US
12 - 24.38.128.0/2218761  0.4%   AS53271 -- PHENIXCITYCABLE - Phenix 
Cable,US
13 - 155.133.79.0/24   17130  0.3%   AS200671 -- SKOK-JAWORZNO SKOK Jaworzno,PL
14 - 78.140.0.0/18 14079  0.3%   AS31357 -- TOMICA-

"Access Denied" when hitting https://www.apple.com issue over IPv4 and 6

[Frank Bulk]

Monitoring system reporting this since 11:11 pm U.S. Central

 

 



 

root@nagios:/tmp# wget -6 www.apple.com

--2015-09-12 00:17:55--  http://www.apple.com/

Resolving www.apple.com... 2001:590:1807:187::c77, 2001:590:1807:186::c77

Connecting to www.apple.com|2001:590:1807:187::c77|:80... connected.

HTTP request sent, awaiting response... 403 Forbidden

2015-09-12 00:17:55 ERROR 403: Forbidden.

 

root@nagios:/tmp# wget -6 https://www.apple.com

--2015-09-12 00:17:59--  https://www.apple.com/

Resolving www.apple.com... 2001:590:1807:186::c77, 2001:590:1807:187::c77

Connecting to www.apple.com|2001:590:1807:186::c77|:443... connected.

HTTP request sent, awaiting response... 403 Forbidden

2015-09-12 00:17:59 ERROR 403: Forbidden.

 

root@nagios:/tmp# wget -4 www.apple.com

--2015-09-12 00:18:35--  http://www.apple.com/

Resolving www.apple.com... 23.197.157.15

Connecting to www.apple.com|23.197.157.15|:80... connected.

HTTP request sent, awaiting response... 403 Forbidden

2015-09-12 00:18:35 ERROR 403: Forbidden.

 

root@nagios:/tmp# wget -4 https://www.apple.com

--2015-09-12 00:19:07--  https://www.apple.com/

Resolving www.apple.com... 23.197.157.15

Connecting to www.apple.com|23.197.157.15|:443... connected.

HTTP request sent, awaiting response... 403 Forbidden

2015-09-12 00:19:07 ERROR 403: Forbidden.

 

root@nagios:/tmp#

 

 

Frank

Re: "Access Denied" when hitting https://www.apple.com issue over IPv4 and 6

[Shrdlu]

On 9/11/2015 10:19 PM, Frank Bulk wrote:

Monitoring system reporting this since 11:11 pm U.S. Central


[snippy]


Resolving www.apple.com... 2001:590:1807:187::c77, 2001:590:1807:186::c77

Connecting to www.apple.com|2001:590:1807:187::c77|:80... connected.

HTTP request sent, awaiting response... 403 Forbidden

2015-09-12 00:17:55 ERROR 403: Forbidden.


Entertaining. You could always call Apple Care, and let them know.

(800) 694-7466

--
"You don't manage people; you manage things. You lead people."
Admiral Grace Hopper, USN