Re: Purchased IPv4 Woes

[Mike Hale]

It looks like Spamhaus has your entire /16.

https://stat.ripe.net/163.182.192.0%2F18#tabId=anti-abuse



On Fri, Mar 10, 2017 at 10:01 PM, Laurent Dumont
 wrote:
> Out of curiosity, who were the previous owner(s), it seems that ARIN only
> shows the current owner with any history? If it was a Chinese/Russian block,
> you might be out of luck.
>
>
>
> On 03/10/2017 12:00 PM, Pete Baldwin wrote:
>>
>> Hi All,
>>
>> Hopefully this is not taken in bad taste.   Our organization purchased
>> some IP space last year (163.182.192.0/18 to be specific), and it appears
>> that this block must have been used for less-than-admirable purposes in the
>> past.
>>
>> We have been trying to clean up the reputation where possible, and we do
>> not appear to be on any blacklists, but we do appear to be blocked from a
>> lot of networks across the US/Canada.I am noticing a lot of name servers
>> blocking our requests, many web servers, gaming servers, mail etc.
>>
>> This is a transition block for us to move towards v6 everywhere, but we
>> have many systems that will need to rely on this block of space for some
>> time to come.
>>
>> We are a small rural co-op ISP in Ontario, and I am just writing this
>> email as an extra plea so that if you happen to run a network that has this
>> entire range on your naughty list, we would appreciate you giving it another
>> chance.  I can be contacted on or off list, thanks.
>>
>>
>



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

Re: Purchased IPv4 Woes

[Laurent Dumont]

Out of curiosity, who were the previous owner(s), it seems that ARIN 
only shows the current owner with any history? If it was a 
Chinese/Russian block, you might be out of luck.



On 03/10/2017 12:00 PM, Pete Baldwin wrote:

Hi All,

Hopefully this is not taken in bad taste.   Our organization 
purchased some IP space last year (163.182.192.0/18 to be specific), 
and it appears that this block must have been used for 
less-than-admirable purposes in the past.


We have been trying to clean up the reputation where possible, and we 
do not appear to be on any blacklists, but we do appear to be blocked 
from a lot of networks across the US/Canada.I am noticing a lot of 
name servers blocking our requests, many web servers, gaming servers, 
mail etc.


This is a transition block for us to move towards v6 everywhere, but 
we have many systems that will need to rely on this block of space for 
some time to come.


We are a small rural co-op ISP in Ontario, and I am just writing this 
email as an extra plea so that if you happen to run a network that has 
this entire range on your naughty list, we would appreciate you giving 
it another chance.  I can be contacted on or off list, thanks.

Re: Multi-CDN Strategies

[Ryan Landry]

Some folks just let Cedexis do the work.

https://www.cedexis.com/solutions/multi-cdn/

On Fri, Mar 10, 2017 at 09:27 Chris Grundemann 
wrote:

> Hail NANOG;
>
> Is anyone here leveraging multiple CDN providers for resiliency and have
> best practices or other advice they'd be willing to share?
>
> Thanks,
> ~Chris
>
> --
> @ChrisGrundemann
> http://chrisgrundemann.com
>

AIMS Data Center - Cyberjaya - Malaysia

[Rod Beck]

Gentlemen and Ladies,

Looking for a customer list with a focus on carriers and ISPs.


Thanks!


- Roderick.

Re: Multi-CDN Strategies

[Chris Woodfield]

I have some experience with this; a few things off the top of my head:

- It’s usually best to leverage some sort of “smart” DNS  to handle CNAME 
distribution, giving you the ability to weight your CNAME distribution vs. only 
using one CDN all the time, or prefer different CDNs in various global regions. 
I’ve had decent experience with Dyn here, but Route53 has all the features 
you’d want as well. If possible, write tooling towards your DNS provider’s API 
to automate your failovers.

- Weight your distribution such that you never have one CDN turned off 
completely; you’ll want a small trickle of user traffic hitting every CDN so 
that the caches won’t be cold when you switch over to it.

- Make sure you have a distributed metrics service (ThousandEyes, WebMetrics, 
et al) testing your CDNs individually as well as the external hostname.

- Stay away from HTML- or Header-munging features when possible; stick with 
feature sets that are common (and implementable in similar ways) across your 
providers. (Similar advice goes for multi-vendor *anything*, TBH)

I could keep going, but if so, I might as well stick them into a powerpoint and 
submit a talk for Bellevue :)

-C

> On Mar 10, 2017, at 9:25 AM, Chris Grundemann  wrote:
> 
> Hail NANOG;
> 
> Is anyone here leveraging multiple CDN providers for resiliency and have
> best practices or other advice they'd be willing to share?
> 
> Thanks,
> ~Chris
> 
> -- 
> @ChrisGrundemann
> http://chrisgrundemann.com

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,
MENOG, SAFNOG, SdNOG, BJNOG, CaribNOG 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 11 Mar, 2017

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

Analysis Summary


BGP routing table entries examined:  639763
Prefixes after maximum aggregation (per Origin AS):  249160
Deaggregation factor:  2.57
Unique aggregates announced (without unneeded subnets):  308424
Total ASes present in the Internet Routing Table: 56466
Prefixes per ASN: 11.33
Origin-only ASes present in the Internet Routing Table:   48885
Origin ASes announcing only one prefix:   21729
Transit ASes present in the Internet Routing Table:7581
Transit-only ASes present in the Internet Routing Table:211
Average AS path length visible in the Internet Routing Table:   4.3
Max AS path length visible:  41
Max AS path prepend of ASN ( 55644)  36
Prefixes from unregistered ASNs in the Routing Table:69
Numnber of instances of unregistered ASNs:   70
Number of 32-bit ASNs allocated by the RIRs:  17648
Number of 32-bit ASNs visible in the Routing Table:   13695
Prefixes from 32-bit ASNs in the Routing Table:   55367
Number of bogon 32-bit ASNs visible in the Routing Table:45
Special use prefixes present in the Routing Table:0
Prefixes being announced from unallocated address space:408
Number of addresses announced to Internet:   2837876068
Equivalent to 169 /8s, 38 /16s and 141 /24s
Percentage of available address space announced:   76.7
Percentage of allocated address space announced:   76.7
Percentage of available address space allocated:  100.0
Percentage of address space in use by end-sites:   98.5
Total number of prefixes smaller than registry allocations:  213848

APNIC Region Analysis Summary
-

Prefixes being announced by APNIC Region ASes:   174984
Total APNIC prefixes after maximum aggregation:   50104
APNIC Deaggregation factor:3.49
Prefixes being announced from the APNIC address blocks:  174317
Unique aggregates announced from the APNIC address blocks:71873
APNIC Region origin ASes present in the Internet Routing Table:7908
APNIC Prefixes per ASN:   22.04
APNIC Region origin ASes announcing only one prefix:   2220
APNIC Region transit ASes present in the Internet Routing Table:   1131
Average APNIC Region AS path length visible:4.4
Max APNIC Region AS path length visible: 41
Number of APNIC region 32-bit ASNs visible in the Routing Table:   2748
Number of APNIC addresses announced to Internet:  760936068
Equivalent to 45 /8s, 90 /16s and 246 /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:194699
Total ARIN prefixes after maximum aggregation:93351
ARIN Deaggregation factor: 2.09
Prefixes being announced from the ARIN address blocks:   197144
Unique aggregates announced from the ARIN address blocks: 90309
ARIN Region origin ASes present in the Internet Routing Table:17824
ARIN Prefixes per ASN:11.06
ARIN Region o

Re: Bitly Contact?

[Livingood, Jason]

Contact person found! Thanks NANOG! ☺

On 3/10/17, 12:13 PM, "NANOG on behalf of Livingood, Jason" 
 wrote:

Anyone on the NANOG list here from Bitly? I’m trying to find a contact.

Thanks
Jason

Multi-CDN Strategies

[Chris Grundemann]

Hail NANOG;

Is anyone here leveraging multiple CDN providers for resiliency and have
best practices or other advice they'd be willing to share?

Thanks,
~Chris

-- 
@ChrisGrundemann
http://chrisgrundemann.com

Bitly Contact?

[Livingood, Jason]

Anyone on the NANOG list here from Bitly? I’m trying to find a contact.

Thanks
Jason

Purchased IPv4 Woes

[Pete Baldwin]

Hi All,

Hopefully this is not taken in bad taste.   Our organization 
purchased some IP space last year (163.182.192.0/18 to be specific), and 
it appears that this block must have been used for less-than-admirable 
purposes in the past.


We have been trying to clean up the reputation where possible, and we do 
not appear to be on any blacklists, but we do appear to be blocked from 
a lot of networks across the US/Canada.I am noticing a lot of name 
servers blocking our requests, many web servers, gaming servers, mail etc.


This is a transition block for us to move towards v6 everywhere, but we 
have many systems that will need to rely on this block of space for some 
time to come.


We are a small rural co-op ISP in Ontario, and I am just writing this 
email as an extra plea so that if you happen to run a network that has 
this entire range on your naughty list, we would appreciate you giving 
it another chance.  I can be contacted on or off list, thanks.



--


-

Pete Baldwin
Tuckersmith Communications
(P) 519-565-2400
(C) 519-441-7383

critical mass update on IPv6

[Ca By]

Just update for those that care.

As you may know, all the major cellular providers in the USA (VZ, AT&T,
T-Mobile, Sprint) support IPv6 by default on many models of phones.
Comcast and AT&T and other large broadband players also have IPv6 widely
deployed by default

http://www.worldipv6launch.org/measurements/

Most of the major (elephants) content is IPv6 (Google, FB, Netflix, ...)

And now the other end in the cloud is coming along nicely

https://aws.amazon.com/blogs/aws/aws-ipv6-update-global-support-spanning-15-regions-multiple-aws-services/

https://docs.microsoft.com/en-us/azure/load-balancer/load-balancer-ipv6-overview

https://cloud.google.com/compute/docs/load-balancing/ipv6

Not to mention that Digital Ocean , Softlayer / IBM, Linode, and others
also support IPv6

And now you are seeing ipv4 lose support in various classes of products
like set-top boxes (
http://corporate.comcast.com/comcast-voices/world-ipv6-launch-four-years-later-taking-stock-and-looking-forward
) and static IPs (
https://www.theregister.co.uk/2017/03/10/verizon_running_out_of_ipv4_addresses/
)

Re: RNP Santa Catarina Point of Presence (PoP-SC)

[Leandro de Lima Camargo]

Have you tried contacting from this website?
https://www.pop-sc.rnp.br/home/equipe/ 




Regards,
Leandro de Lima Camargo


> On Mar 92017, at 5:24 AM, James Bensley  wrote:
> 
> Hi All,
> 
> Anyone from RNP on-list that can reach out to me off-list, minor
> technical problem in your network.
> 
> Thanks,
> James.