Re: 5G roadblock: labor

[Tom Beecher]

>
> You refer to a certain NR protocol.  (NR - New Radio).  It is
> possible to check in 3GPP specs what precisely does it mean an 'NR
> protocol'.  The questions to answer when searching would be something
> like: is it TDD or FDD?  Is it SC-FDMA?  And then compare these terms to
> what the iphone 11 does in these frequency bands.  Maybe iphone 11 does
> TDD in band 48 but does not do SC-FDMA (or something like that).
>
> I am not sure we can say that 'NR protocol' is like a message exchange
> like I know in DHCP for example.
>

5G NR the layer 1 radio access specification, just like LTE, GSM, etc. It
is defined in 3GPP spec series 38.

https://www.3gpp.org/DynaReport/38-series.htm


On Fri, Jan 17, 2020 at 2:34 PM Alexandre Petrescu <
alexandre.petre...@gmail.com> wrote:

> Mark, Shane,
>
> I do agree that listing a 3.5 GHz band of frequencies does not
> necessarily mean it's 5G.
>
> Bu I would like to further clarify, if you permit:
>
> 1. From the web: The band 71 (UHF range) seems to be for 4G _and_ 5G.
> Some descriptions on the web say so.
>
>  From the web: the band 42 (3400–3600MHz) is for CBRS in EU and Japan.
>
>  From the web: the band 48 (3550-3700MHz) is for CBRS in US (Citizens'
> band broadband service; I suppose something like voice between trucks)
>
> It is possible to check in 3GPP specs, ETSI specs and ARCEP public
> ambitions, whether or not the bands intended for 5G (and up for auction)
> fall within these frequency bands 71, 42 and 48.  My gut feeling is that
> the answer is yes.
>
> 2. You refer to a certain NR protocol.  (NR - New Radio).  It is
> possible to check in 3GPP specs what precisely does it mean an 'NR
> protocol'.  The questions to answer when searching would be something
> like: is it TDD or FDD?  Is it SC-FDMA?  And then compare these terms to
> what the iphone 11 does in these frequency bands.  Maybe iphone 11 does
> TDD in band 48 but does not do SC-FDMA (or something like that).
>
> I am not sure we can say that 'NR protocol' is like a message exchange
> like I know in DHCP for example.
>
> 3. you refer to a potential Qualcomm 5G modem in second half of year
> 2020.  I wonder whether there are public announcements for them?  Or
> will it be sufficient to firmware upgrade the iphone to make it carry a
> 5G label? (like Teslas are updated to software to make them self-driving
> or so; or like with software SIM cards).
>
> 4. I wonder whether some existing smartphone on the market (not an
> iphone, maybe a samsung or so) already features an entry in its table
> with a feature that makes it a '5G' smartphone.
>
> Alex
>
> Le 17/01/2020 à 06:05, Mark Tinka a écrit :
> >
> >
> > On 16/Jan/20 19:23, Shane Ronan wrote:
> >
> >> The iPhone 11 does not have a 5G (NR) capable modem. The 3.5Ghz freq
> >> support is for the CBRS bands in the US.
> >>
> >> Support for 5G is not just a freq band support, it requires a
> >> chipset/modem capable of support the NR protocol.
> >
> > Yes, exactly.
> >
> > Word is Apple should start shipping Qualcomm's 5G modems in 2H'20, and
> > its own in 2021.
> >
> > Personally, I'm not in any rush to buy a phone with 5G on it. Wi-fi or
> > existing 4G/LTE is fine for me.
> >
> > I'm due to upgrade my iPhones this year. I'll take whatever they come
> with.
> >
> > Mark.
> >
>

Re: 5G roadblock: labor

[Seth Mattinen]

On 1/17/20 02:13, Alexandre Petrescu wrote:
 From the web: the band 48 (3550-3700MHz) is for CBRS in US (Citizens' 
band broadband service; I suppose something like voice between trucks)



CBRS (and the soon to be former NN band) doesn't have anything to do 
with CB radios.

Re: cisco nexus 9000 cctrl ERROR

[Scott Weeks]

--- bs...@teamonesolutions.com wrote:From: Brandon Svec Anyone can create a Cisco login.  I would do that and check the bug tracking tool.  I did a quick search on your error message and came up with this:I was unaware that anyone could do that as I have been away from cisco for a good while now.  Thank you both for the quick response.  It helped a lot!scott

Re: De-bogonising 2a10::/12

[Mirjam Kuehne]

Dear colleagues,

Following the announcement of our plans to debogonise 2a10::/12, we have
now shared the results of the tests we've been carrying out to check the
usability of address space in this block. Read all about it on RIPE Labs:

https://labs.ripe.net/Members/emileaben/the-debogonisation-of-2a10-12

Kind regards,
Mirjam Kühne
RIPE NCC


On 16/01/2020 09:07, Emile Aben wrote:
> Dear colleagues,
> 
> We have now started de-bogonising 2a10::/12!
> 
> As part of this, we are announcing a couple of prefixes out of 2a10::/12
> from AS12654 (RIPE's Routing Information Service, RIS). Pingable targets
> have been configured in these prefixes, and we invite network operators
> to test for themselves whether this address space is reachable.
> 
> The simplest way to do this would be to perform a ping6 to 2a10:4::1 .
> 
> Using RIPE Atlas and RIS, we will also be carrying out our own tests in
> order to investigate connectivity and filtering for this address space.
> We plan to share our results with the RIPE community via RIPE Labs
> within the next few days.
> 
> For those who want to do other testing, beyond the basic test described
> above, we have a total of 8 targets available for this, with 2 different
> prefix lengths and all variations of having ROUTE objects in the RIPE DB
> and/or ROAs.
> 
> 2a10:3:4::1  /48 ROUTE object + ROA
> 2a10:3:5::1  /48 no ROUTE object + ROA
> 2a10:3:6::1  /48 ROUTE object + no ROA
> 2a10:3:7::1  /48 no ROUTE object + no ROA
> 
> 2a10:4::1/32 ROUTE object + ROA
> 2a10:5::1/32 no ROUTE object + ROA
> 2a10:6::1/32 ROUTE object + no ROA
> 2a10:7::1/32 no ROUTE object + no ROA
> 
> Kind regards,
> 
> Emile Aben
> RIPE NCC
> 

Re: 5G roadblock: labor

[Alexandre Petrescu]

Mark, Shane,

I do agree that listing a 3.5 GHz band of frequencies does not 
necessarily mean it's 5G.


Bu I would like to further clarify, if you permit:

1. From the web: The band 71 (UHF range) seems to be for 4G _and_ 5G. 
Some descriptions on the web say so.


From the web: the band 42 (3400–3600MHz) is for CBRS in EU and Japan.

From the web: the band 48 (3550-3700MHz) is for CBRS in US (Citizens' 
band broadband service; I suppose something like voice between trucks)


It is possible to check in 3GPP specs, ETSI specs and ARCEP public 
ambitions, whether or not the bands intended for 5G (and up for auction) 
fall within these frequency bands 71, 42 and 48.  My gut feeling is that 
the answer is yes.


2. You refer to a certain NR protocol.  (NR - New Radio).  It is 
possible to check in 3GPP specs what precisely does it mean an 'NR 
protocol'.  The questions to answer when searching would be something 
like: is it TDD or FDD?  Is it SC-FDMA?  And then compare these terms to 
what the iphone 11 does in these frequency bands.  Maybe iphone 11 does 
TDD in band 48 but does not do SC-FDMA (or something like that).


I am not sure we can say that 'NR protocol' is like a message exchange 
like I know in DHCP for example.


3. you refer to a potential Qualcomm 5G modem in second half of year 
2020.  I wonder whether there are public announcements for them?  Or 
will it be sufficient to firmware upgrade the iphone to make it carry a 
5G label? (like Teslas are updated to software to make them self-driving 
or so; or like with software SIM cards).


4. I wonder whether some existing smartphone on the market (not an 
iphone, maybe a samsung or so) already features an entry in its table 
with a feature that makes it a '5G' smartphone.


Alex

Le 17/01/2020 à 06:05, Mark Tinka a écrit :



On 16/Jan/20 19:23, Shane Ronan wrote:


The iPhone 11 does not have a 5G (NR) capable modem. The 3.5Ghz freq
support is for the CBRS bands in the US.

Support for 5G is not just a freq band support, it requires a
chipset/modem capable of support the NR protocol.


Yes, exactly.

Word is Apple should start shipping Qualcomm's 5G modems in 2H'20, and
its own in 2021.

Personally, I'm not in any rush to buy a phone with 5G on it. Wi-fi or
existing 4G/LTE is fine for me.

I'm due to upgrade my iPhones this year. I'll take whatever they come with.

Mark.

Re: IPv6 Prefix Delegation to customers.

[Steven Karp]

Brandon,

Juniper routers also snoop on via the built-in DHCP relay for the prefix 
delegation (PD).   The PD routes are inserted into the routing table as 
"access" routes with a next-hop of the WAN DHCP lease address for the CPE.  I 
normally configure all this in a BGP signaled L3VPN that automatically 
propagates these "access" routes to the routers through my MPLS network.  To 
link the PD pool of /48 prefixes to the right PE-CE access subnet, you create a 
shared-subnet in the DHCPv6 server that includes the /48 prefixes and the WAN 
prefix.

forwarding-options {
dhcp-relay {
dhcpv6 {
overrides {
allow-snooped-clients;
}
group group1 {
active-server-group server-group1;
relay-agent-interface-id {
use-option-82;
}
interface ae0.10;
}
server-group {
server-group1 {
   /* Central DHCPv6 servers */
2603:0:0:100::5;
2603:0:0:101::5;
}
}
}
forward-only;
server-group {
server-group1 {
10.10.10.11;
10.10.11.11;
}
}
group group1 {
active-server-group server-group1;
overrides {
allow-snooped-clients;
layer2-unicast-replies;
trust-option-82;
}
   /* I only enable route-suppression of access routes for IPv4 */
route-suppression {
access-internal;
}
interface ae0.10;
}
}
}


-Steven

On 1/16/20, 11:00 AM, "NANOG on behalf of Jared Mauch" 
 wrote:

Arista/Cisco have commands like this:

ipv6 dhcp relay install routes

You place on the interface to make this happen.

- Jared


> On Jan 16, 2020, at 11:27 AM, Chris Gross  
wrote:
> 
> In my environment I’ve been running Kea dhcp6 against Ciscos of varying 
platform (7600, ASR920, etc) and just them as a relay. In this case, the Cisco 
itself is installing a route as it snoops the relay action automatically. This 
was one of the harder things to wrap my head around before just slapping it in 
to see what happened and bam, routes. Router gets a WAN IP from the loopback 
via DHCPv6 as well, then gets PD assigned after.
> 
> interface Loopback10
> vrf forwarding CGNAT
> no ip address
> ipv6 address 2001:DB8::1/64
> !
> interface Vlan
> vrf forwarding CGNAT
> ip address 100.64.Y.Z 255.255.252.0
> ip helper-address global 10.0.Y.Z
> ip helper-address global 10.0.Y.Z
> ip flow ingress
> load-interval 30
> ipv6 address FE80::1 link-local
> ipv6 enable
> ipv6 nd router-preference High
> ipv6 dhcp relay destination 2001:DB8:0:A::BEEF source-address 
2001:DB8:YZ01::1
> ipv6 dhcp relay destination 2001:DB8:0:B::BEEF source-address 
2001:DB8:YZ01::1
> 
> S   2001:DB8:YZ00:3F00::/56 [1/0]
>  via FE80::4665:7FFF:FE14:EDC2, Vlan
>  
> Chris Gross
> Network Architect
>  
> From: NANOG  On Behalf Of Brandon Price
> Sent: Wednesday, January 15, 2020 9:01 PM
> To: nanog list 
> Subject: IPv6 Prefix Delegation to customers.
>  
> CAUTION: This email originated from outside NineStar Connect. Do not 
click links or open attachments unless you recognize the sender and know that 
the content is safe. If you have any concerns, click here to open a ticket with 
the NetAdmin team.
>  
>  
> Hey Nanog,
>  
> I am in the process of building out a FTTH proof of concept, and I would 
really like to offer each of my customers a /48 of IPv6.
> I’ve been able to announce my /32 to my upstreams, dual-stack all of my 
internal infrastructure no-problem, build v6 recursive name servers, etc.
> This was fairly straight-forward.
>  
> Where I am struggling is the Prefix Delegation part. How are most folks 
getting the PD subnets into their IGPs? In my environment I don’t run the DHCP 
server process on the router that is directly connected to the clients. I have 
seen documentation that cisco and juniper DHCPv6 processes are smart enough to 
insert that prefix into the routing table when they hand it out, but how is 
this handled in an environment with a central DHCP server? I do not currently 
run any PPPOE in my environment and I don’t use RADIUS for the subscriber 
management. I would really just like to stick to DHCP ideally.
>  
> If anyone has any pointers, I would appreciate it.
>  
> Brandon Price
> Senior Network Engineer
> City of Sherwood, Sherwood Broadband
> Desk: 503.625.4258
> Cell: 971.979.2182
>  
> This email may contain confidential information or privileged material 
and is intended for use solely by the above 

Re: Walmart GEOIP

[Norman Jester]

I have checked all of those things.
This is purely a geoip problem as the
settings are all English and cookies cleared.

> On Jan 16, 2020, at 11:23 AM, William Herrin  wrote:
> 
> Hi Norman,
> 
> At the risk of suggesting something obvious you've already considered:
> 
> What language setting do they have in their browser?
> Have they cleared their cookies and offline content?
> Is the recursive resolving DNS server they use in the U.S.?
> 
> Regards,
> Bill Herrin
> 
>> On Thu, Jan 16, 2020 at 11:05 AM Norman Jester  wrote:
>> 
>> I’m having an issue with a customer who
>> for some reason is sent to the Mexican
>> walmart site when they load it from USA.
>> 
>> If anyone knows which geoip service they use or have a contact in Walmart 
>> for geoip issues please advise on or off list. (May be helpful to others)
>> 
>> Norman
>> 
> 
> 
> -- 
> William Herrin
> b...@herrin.us
> https://bill.herrin.us/

Re: China Network Diversity

[Stephen M]

We weren't even able to deploy our own DWDM.

China (Beijing), like India (Mumbai), forced the use of their own transport 
equipment.

//please pardon any brevities - sent from mobile//


From: NANOG  on behalf of Rod 
Beck 
Sent: Thursday, January 16, 2020 8:55 AM
To: Gabe Cole; JASON BOTHE
Cc: nanog@nanog.org
Subject: Re: China Network Diversity

I think the issue is mainland China, not Hong Kong or Singapore.


From: NANOG  on behalf of JASON BOTHE via NANOG 

Sent: Thursday, January 16, 2020 5:30 PM
To: Gabe Cole 
Cc: nanog@nanog.org 
Subject: Re: China Network Diversity

I’ve had good luck with PCCW operating as my China liaison since we terminate a 
lot of circuits in Hong Kong and Singapore. It’s not cheap I’ll tell ya but 
they can get the info and deliver.

J~

On Jan 16, 2020, at 10:21, Gabe Cole  wrote:



We are trying to design a physically diverse network in China and have been 
challenged.  All of the major carriers say that they cannot provide us KMZs or 
similar detailed route information.  Has anyone been able to crack this code?

G. Gabriel Cole
RTE Group, Inc.
Strategic Consulting for Mission Critical Infrastructure
56 Woodridge Rd
Wellesley, MA 02482
US +1-617-303-8707
fax +1-781-209-5577
www.rtegroup.com
g...@rtegroup.com
skype:  ggabrielcole
Twitter:  @DataCenterGuru
Linked In:  http://www.linkedin.com/in/gabecole
Blog:  http://datacenterguru.blogspot.com/

The information contained herein is confidential and proprietary to RTE Group, 
Inc. It is intended for presentation to and permitted use solely by those 
person(s) to whom it has been transmitted by RTE Group, Inc. and it is 
transmitted to such person(s) solely for, conditional upon, and only to the 
extent necessary for use by such person(s) as part of their business 
relationship with RTE Group, Inc. or to further their respective evaluation(s) 
of a potential business relationship with RTE Group, Inc., and no other use, 
release, or reproduction of this information is permitted.

Sent via Superhuman

Re: cisco nexus 9000 cctrl ERROR

[Brandon Svec]

Anyone can create a Cisco login.  I would do that and check the bug tracking 
tool.  I did a quick search on your error message and came up with this:

Bug Search CSCvp48462
Help <>  |  Feedback <>
NXA-PDC-1100W-PI PSU fail log F0411,F0413 in N9K-C9336C-FX2
CSCvp48462
Description <>
Symptom:
NXA-PDC-1100W-PI PSU will occur F0411.F0413 PSU fail log in N9K-C9336C-FX2.

F0411 Power supply failed
F0413 power supply missing

it is not real PSU fail, but only log issue.
in show system internal kernel messages. we can see NACK error on PSU sensor.

[1274386.802885] cctrl ERROR: cctrl_wait_for_pmbio_busy_status@ 35:NACK error 
tmp_data 0x3b58d00 mask = 0x8000 
[1274386.802885] 
[1274386.812815] cctrl ERROR: cctrl2_delay_pmbio_read@ 277:final busy wait 
check failed pid = 8701 (pfmclnt) cs_reg 0x270 win_id 0 dev_addr 0x5a off 0x8d
[1274386.812818] cctrl ERROR: cctrl2_delay_pmbio_read@ 278:write data 
0x82b58d00 read data 0x82b58d00 tmp_maks 0x600 dlen = 2
[1274386.812822] CPU: 1 PID: 8701 Comm: pfmclnt Tainted: PW  O 
3.14.62.0.0insieme-0 #1
[1274386.812824]   88055cd37c18 817ead67 
fffb
[1274386.812829]  82b58d00 88055cd37ca8 c25ad00a 
0002
[1274386.812832]  005a 8805008d c25a5c17 
c9001035c421
[1274386.812836] Call Trace:
[1274386.812844]  [] dump_stack+0x68/0x91
[1274386.812865]  [] cctrl2_delay_pmbio_read+0x28a/0x350 [klm_cctrli2]
[1274386.812873]  [] ? cctrl_read_reg2+0x177/0x190 [klm_cctrli2]
[1274386.812877]  [] ? strstr+0x37/0x90
[1274386.812886]  [] cctrl_psu_handle_sensor+0x16d/0x1e0 [klm_cctrli2]
[1274386.812899]  [] cctrl_tor_scrimshaw_sensor_op+0x1fd/0x240 [klm_cctrli2]
[1274386.812910]  [] sys_srvc_cctrl_sensor_op+0x80/0x190 [klm_cctrli2]
[1274386.812918]  [] sysServices+0x22b/0x880 [klm_sse]
[1274386.812922]  [] ? free_debug_processing+0x17d/0x1c1
[1274386.812928]  [] ? ring_buffer_lock_reserve+0xb3/0xf0
[1274386.812933]  [] sse_compat_ioctl+0x102/0x120 [klm_sse]
[1274386.812938]  [] ? trace_buffer_unlock_commit+0x43/0x60
[1274386.812944]  [] compat_sys_ioctl+0x1dc/0x11f0
[1274386.812948]  [] ? syscall_trace_enter+0x162/0x1b0
[1274386.812951]  [] ia32_do_call+0x13/0x13

Conditions:
NXA-PDC-1100W-PI PSU in N9K-C9336C-FX2

Workaround:
NA

Further Problem Description:
NA

Customer Visible


Notifications

Save Bug

Open Support Case
Was the description about this Bug Helpful?(0)
Details <>
Last Modified:
Jan 13,2020
Status:
Open
Severity:
2 Severe
Product:(1)
Cisco Nexus 9000 Series Switches
Support Cases:
3

> On Jan 17, 2020, at 11:08 AM, Scott Weeks  wrote:
> 
> 
> 
> I don't have a login to cisco to find out what this 
> is and I'm having trouble finding anything about it 
> in search engines that doesn't require a login to 
> cisco.  I guess they only want certain folks to know 
> about it... :(  Does anyone know anything about this 
> and can explain it to me?  If not, I'll go join 
> cisco-nsp and ask there.
> 
> 
> %KERN-3-SYSTEM_MSG: [65292299.903992]  - kernel
> 
> %KERN-3-SYSTEM_MSG: [66730914.839059] cctrl ERROR: 
> cctrl_wait_for_pmbio_busy_status NACK error tmp_data 3b19600 - kernel
> 
> %KERN-3-SYSTEM_MSG: [67511639.312284] cctrl ERROR: 
> cctrl_wait_for_pmbio_busy_status NACK error tmp_data 1b18100 - kernel
> 
> 
> Those last numbers after tmp_data repeat over and over.
> 
> Thanks!
> scott

cisco nexus 9000 cctrl ERROR

[Scott Weeks]

I don't have a login to cisco to find out what this 
is and I'm having trouble finding anything about it 
in search engines that doesn't require a login to 
cisco.  I guess they only want certain folks to know 
about it... :(  Does anyone know anything about this 
and can explain it to me?  If not, I'll go join 
cisco-nsp and ask there.


%KERN-3-SYSTEM_MSG: [65292299.903992]  - kernel

%KERN-3-SYSTEM_MSG: [66730914.839059] cctrl ERROR: 
cctrl_wait_for_pmbio_busy_status NACK error tmp_data 3b19600 - kernel

%KERN-3-SYSTEM_MSG: [67511639.312284] cctrl ERROR: 
cctrl_wait_for_pmbio_busy_status NACK error tmp_data 1b18100 - kernel


Those last numbers after tmp_data repeat over and over.

Thanks!
scott

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, SANOG, PacNOG, SAFNOG
TZNOG, MENOG, BJNOG, SDNOG, CMNOG, LACNOG 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 18 Jan, 2020

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

Analysis Summary


BGP routing table entries examined:  791374
Prefixes after maximum aggregation (per Origin AS):  301457
Deaggregation factor:  2.63
Unique aggregates announced (without unneeded subnets):  387840
Total ASes present in the Internet Routing Table: 66740
Prefixes per ASN: 11.86
Origin-only ASes present in the Internet Routing Table:   57361
Origin ASes announcing only one prefix:   24165
Transit ASes present in the Internet Routing Table:9379
Transit-only ASes present in the Internet Routing Table:288
Average AS path length visible in the Internet Routing Table:   4.5
Max AS path length visible:  35
Max AS path prepend of ASN ( 53176)  31
Prefixes from unregistered ASNs in the Routing Table:  1313
Number of instances of unregistered ASNs:  1313
Number of 32-bit ASNs allocated by the RIRs:  30192
Number of 32-bit ASNs visible in the Routing Table:   24830
Prefixes from 32-bit ASNs in the Routing Table:  113996
Number of bogon 32-bit ASNs visible in the Routing Table:31
Special use prefixes present in the Routing Table:1
Prefixes being announced from unallocated address space:443
Number of addresses announced to Internet:   2852676736
Equivalent to 170 /8s, 8 /16s and 100 /24s
Percentage of available address space announced:   77.1
Percentage of allocated address space announced:   77.1
Percentage of available address space allocated:  100.0
Percentage of address space in use by end-sites:   99.4
Total number of prefixes smaller than registry allocations:  264746

APNIC Region Analysis Summary
-

Prefixes being announced by APNIC Region ASes:   210449
Total APNIC prefixes after maximum aggregation:   61270
APNIC Deaggregation factor:3.43
Prefixes being announced from the APNIC address blocks:  203980
Unique aggregates announced from the APNIC address blocks:84945
APNIC Region origin ASes present in the Internet Routing Table:   10291
APNIC Prefixes per ASN:   19.82
APNIC Region origin ASes announcing only one prefix:   2850
APNIC Region transit ASes present in the Internet Routing Table:   1543
Average APNIC Region AS path length visible:4.6
Max APNIC Region AS path length visible: 25
Number of APNIC region 32-bit ASNs visible in the Routing Table:   5344
Number of APNIC addresses announced to Internet:  768001280
Equivalent to 45 /8s, 198 /16s and 197 /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-141625
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:232092
Total ARIN prefixes after maximum aggregation:   107372
ARIN Deaggregation factor: 2.16
Prefixes being announced from the ARIN address blocks:   230025
Unique aggregates announced from the ARIN address blocks:116598
ARIN Region origin ASes present in the Internet Routing Table:18372
ARIN Prefixes per ASN:12.52
ARIN