Re: Looking for recommendations for a dedicated ping responder

[Jon Lewis]

On Fri, 9 Sep 2016, Jared Mauch wrote:




On Sep 9, 2016, at 4:08 PM, Dan White  wrote:

We're being caught up in some sort of peering dispute between Level 3 and
Google (in the Dallas area), and we've fielded several calls from larger
customers complaining of 40-50% packet loss (to 8.8.8.8) when there appears
to be no actual service impacting loss.

We currently suggest customers use a Linux server to ping against, or
another public host.

Ideally we'd like to use a hardware based ICMP system for customer use -
Accedian NIDs are good at this (exceptionally low jitter) accept they
throttle at 500 pings per second.


I know that the NETNOD folks did NTP in a FPGA that can do 4x 10GE,
perhaps that card and code could be used to do 40G ICMP responder?


The trouble is, LOTS of people want to ping something "out on the 
internet" to verify their connectivity, and things like GOOG's 8.8.8.8 
DNS servers are a popular lighthouse.  I know from first hand experience 
(dealing with customers complaining about it), that GOOG, at least at some 
of the anycast nodes for the service, polices ICMP echo requests aimed at

8.8.8.8 due to the quantity of those unwanted packets.

Having a cheap/small/powerful device that can be used as a ping target, 
and getting the masses to use it are two very different things.


Dan, are your customers missing DNS responses, or just echo replies from 
8.8.8.8?  If the latter, ask what they'd do if thousands of people pinged 
one of their servers constantly.


--
 Jon Lewis, MCP :)   |  I route
 |  therefore you are
_ http://www.lewis.org/~jlewis/pgp for PGP public key_

Re: Looking for recommendations for a dedicated ping responder

[Christopher Morrow]

On Fri, Sep 9, 2016 at 4:17 PM, Jared Mauch  wrote:

>
> > On Sep 9, 2016, at 4:08 PM, Dan White  wrote:
> >
> > We're being caught up in some sort of peering dispute between Level 3 and
> > Google (in the Dallas area), and we've fielded several calls from larger
> > customers complaining of 40-50% packet loss (to 8.8.8.8) when there
> appears
> > to be no actual service impacting loss.
> >
> > We currently suggest customers use a Linux server to ping against, or
> > another public host.
> >
> > Ideally we'd like to use a hardware based ICMP system for customer use -
> > Accedian NIDs are good at this (exceptionally low jitter) accept they
> > throttle at 500 pings per second.
>
> I know that the NETNOD folks did NTP in a FPGA that can do 4x 10GE,
> perhaps that card and code could be used to do 40G ICMP responder?
>
>
or, alternately test some useful application instead? I mean, 'wget' will
tell you stats about the bw/etc... apache-bench will as well, and you can
probably whip up some custom python/etc that'd do the same sort of thing.

Re: Looking for recommendations for a dedicated ping responder

[Jared Mauch]

> On Sep 9, 2016, at 4:08 PM, Dan White  wrote:
> 
> We're being caught up in some sort of peering dispute between Level 3 and
> Google (in the Dallas area), and we've fielded several calls from larger
> customers complaining of 40-50% packet loss (to 8.8.8.8) when there appears
> to be no actual service impacting loss.
> 
> We currently suggest customers use a Linux server to ping against, or
> another public host.
> 
> Ideally we'd like to use a hardware based ICMP system for customer use -
> Accedian NIDs are good at this (exceptionally low jitter) accept they
> throttle at 500 pings per second. 

I know that the NETNOD folks did NTP in a FPGA that can do 4x 10GE,
perhaps that card and code could be used to do 40G ICMP responder?

- Jared

Re: Looking for recommendations for a dedicated ping responder

[Dan White]

We're being caught up in some sort of peering dispute between Level 3 and
Google (in the Dallas area), and we've fielded several calls from larger
customers complaining of 40-50% packet loss (to 8.8.8.8) when there appears
to be no actual service impacting loss.

We currently suggest customers use a Linux server to ping against, or
another public host.

Ideally we'd like to use a hardware based ICMP system for customer use -
Accedian NIDs are good at this (exceptionally low jitter) accept they
throttle at 500 pings per second. 


On 09/09/16 15:00 -0500, Josh Reynolds wrote:

Can you elaborate?

On Sep 9, 2016 2:54 PM, "Dan White"  wrote:


Are there any products you're using which are dedicated to responding to
customer facing pings?


--
Dan White
BTC Broadband
Network Admin Lead
Ph  918.366.0248 (direct)   main: (918)366-8000
Fax 918.366.6610email: dwh...@olp.net
http://www.btcbroadband.com

Re: Looking for recommendations for a dedicated ping responder

[Josh Reynolds]

Can you elaborate?

On Sep 9, 2016 2:54 PM, "Dan White"  wrote:

> Are there any products you're using which are dedicated to responding to
> customer facing pings?
>
> --
> Dan White
> BTC Broadband
> Network Admin Lead
> Ph  918.366.0248 (direct)   main: (918)366-8000
> Fax 918.366.6610email: dwh...@olp.net
> http://www.btcbroadband.com
>

Re: Looking for recommendations for a dedicated ping responder

[Laszlo Hanyecz]

On 2016-09-09 19:52, Dan White wrote:

Are there any products you're using which are dedicated to responding to
customer facing pings?


PaaS (pong-as-a-service)?

Looking for recommendations for a dedicated ping responder

[Dan White]

Are there any products you're using which are dedicated to responding to
customer facing pings?

--
Dan White
BTC Broadband
Network Admin Lead
Ph  918.366.0248 (direct)   main: (918)366-8000
Fax 918.366.6610email: dwh...@olp.net
http://www.btcbroadband.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,
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 10 Sep, 2016

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

Analysis Summary


BGP routing table entries examined:  608869
Prefixes after maximum aggregation (per Origin AS):  219887
Deaggregation factor:  2.77
Unique aggregates announced (without unneeded subnets):  297693
Total ASes present in the Internet Routing Table: 54797
Prefixes per ASN: 11.11
Origin-only ASes present in the Internet Routing Table:   36393
Origin ASes announcing only one prefix:   15419
Transit ASes present in the Internet Routing Table:6519
Transit-only ASes present in the Internet Routing Table:176
Average AS path length visible in the Internet Routing Table:   4.3
Max AS path length visible:  54
Max AS path prepend of ASN ( 55644)  51
Prefixes from unregistered ASNs in the Routing Table:60
Unregistered ASNs in the Routing Table:  15
Number of 32-bit ASNs allocated by the RIRs:  15349
Number of 32-bit ASNs visible in the Routing Table:   11885
Prefixes from 32-bit ASNs in the Routing Table:   47401
Number of bogon 32-bit ASNs visible in the Routing Table:68
Special use prefixes present in the Routing Table:0
Prefixes being announced from unallocated address space:402
Number of addresses announced to Internet:   2827227492
Equivalent to 168 /8s, 132 /16s and 17 /24s
Percentage of available address space announced:   76.4
Percentage of allocated address space announced:   76.4
Percentage of available address space allocated:  100.0
Percentage of address space in use by end-sites:   98.2
Total number of prefixes smaller than registry allocations:  197756

APNIC Region Analysis Summary
-

Prefixes being announced by APNIC Region ASes:   156029
Total APNIC prefixes after maximum aggregation:   42960
APNIC Deaggregation factor:3.63
Prefixes being announced from the APNIC address blocks:  169453
Unique aggregates announced from the APNIC address blocks:68913
APNIC Region origin ASes present in the Internet Routing Table:5199
APNIC Prefixes per ASN:   32.59
APNIC Region origin ASes announcing only one prefix:   1164
APNIC Region transit ASes present in the Internet Routing Table:947
Average APNIC Region AS path length visible:4.4
Max APNIC Region AS path length visible: 54
Number of APNIC region 32-bit ASNs visible in the Routing Table:   2361
Number of APNIC addresses announced to Internet:  759442244
Equivalent to 45 /8s, 68 /16s and 43 /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:183621
Total ARIN prefixes after maximum aggregation:89506
ARIN Deaggregation factor: 2.05
Prefixes being announced from the ARIN address blocks:   189303
Unique aggregates announced from the ARIN address blocks: 88433
ARIN Region origin ASes present in the Internet Routing Table:16204
ARIN Prefixes per ASN:11.68

Israeli Online Attack Service ‘vDOS’ Earned $600,000 in Two Years

[Doug Barton]

vDOS — a “booter” service that has earned in excess of $600,000 over the 
past two years helping customers coordinate more than 150,000 so-called 
distributed denial-of-service (DDoS) attacks designed to knock Web sites 
offline — has been massively hacked, spilling secrets about tens of 
thousands of paying customers and their targets.


http://krebsonsecurity.com/2016/09/israeli-online-attack-service-vdos-earned-60-in-two-years/

Re: Amazon Contact

[Daniel Corbe]

> On Sep 8, 2016, at 1:54 PM, Shon Elliott  wrote:
> 
> Hi everyone,
> 
> Sorry for having to ask this, but I haven't been able to chase down anyone 
> from Amazon. Can someone from Amazon who might be watching the list who deals 
> with the Amazon Instant Video, FireTV, Music, and other streaming media 
> sections please contact me off-list regarding a serious issue? I would 
> appreciate it very much.
> 
> 
> Kind Regards,
> Shon Elliott, KK6TOO
> selli...@getunwired.com
> 
> 
> 


I also need to chase down someone from Amazon.  None of my customers seem to be 
able to access websites hosted on AWS.  Including www.netflix.com and 
www.amazon.com proper.

-Daniel

Re: Use of unique local IPv6 addressing rfc4193

[Octavio Alvarez]

On 09/08/2016 04:09 PM, Pshem Kowalczyk wrote:
> With NAT I have a single entry/exit point to those infrastructure subnets
> which can be easily policed.

I have used NAT in IPv4 scenarios as an alternative for lack of routing
control in the return direction.

However, this does not mean that this is the correct, best or orthodox
way, even for IPv4, much less in IPv6.

So, even though you can hack your way using NAT, this is really a
routing problem, not an addressing problem. And you will just create
problems for your users, your developers, yourself and third parties.

> If I give them public IPs then they're routable and potentially can reach
> the internet via devices that don't police the traffic.

First: this can happen with NAT too. If other devices have access to the
Internet, they can just NAT themselves even if the third-party exit has
a private address.

Second: private addresses can reach the Internet too. Many devices and
ISPs don't block RFC5375-sourced packets from the Internet. So they can
go out, although they can't come back. This is enough to create
unsourceable attacks.

In both cases NAT isn't really solving any of your problems fully. It's
just a misconception.

> My real question is does anyone bother with the fc00::/7 addressing or do
> you use your public space (and police that)?

I use public address space and I have made sure I have a single point of
exit and return for my traffic.

If I understood your concerns correctly, then I'd add that if the user
forces traffic through third-party exit points, service is not
guaranteed, as the third party may BCP38-filter it. If you want to
absolutely prevent that, NAT will not help. You'll need other techniques.

Best regards and good luck!