Amsterdam/London Underesea Cables

[Rod Beck]

Hi,


I am trying to determine which undersea cables used for London/Amsterdam 
traffic are the most reliable - fewest outages due to shunt faults and other 
problems.


Looks like most of the traffic traverses the following systems:

Farland North

UK-Netherlands

Ulysses

Circe North

Concerto


My recollection, which is foggy, is that Circe North was rebuilt due to 
repeated shunt faults.


Feel free to contact me offlist so you can share the good, the bad, and the 
ugly. [😊]


Roderick Beck

Director of Global Sales

United Cable Company

www.unitedcablecompany.com

85 Király utca, 1077 Budapest

rod.b...@unitedcablecompany.com

36-30-859-5144


[1467221429846_image002.jpg][1467221477350_image005.png]

Re: Subject: Paging Olav van Doorn, Jan Willem Meijer, and Rutger Bevaart

[Rutger Bevaart]

Hi Ronald,

You obviously managed to find us ;-) 

All our contact details are on peeringdb.com, our corporate website, LinkedIn, 
etc. We should be pretty easy to reach. The message you sent to our 24x7 NOC 
was marked as “spam”, ironic.

Thank you for bringing this to my attention, we’ve asked the customer for 
clarification on this and in the meantime blocked offending prefixes. We update 
our filters based on RADB entries which is why these were accepted (valid route 
entries exist), I’ll evaluate if we need to do more than that.

Cheers,
Rutger

Re: pay.gov and IPv6

[Lee]

On 11/17/16, Carl Byington  wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
>
> On Thu, 2016-11-17 at 15:32 -0500, Lee wrote:
>> That's fine, but until someone is willing to work with them don't
>> expect it to get fixed.
>
> I am working with pay.gov.c...@clev.frb.org, trying to explain the
> problem. They seem to think I should provide "application name and ID"
> before they can research this.

They probably want that so they know where to route the ticket.  I
pointed them at
  https://tools.ietf.org/html/rfc4890#page-14
and suggested they have someone on the network team use ipv6 to
connect to pay.gov over a 1280 byte MTU link.  Hopefully that's enough
to get the ticket routed to the correct group.

> I responded as below. I will let you know
> if there is any progress on this.

I'd appreciate that.
And thanks for being willing to work with them to fix the problem.

Lee


> It is 100% reproducible here - and
> should be reproducible from anywhere with a slightly smaller than normal
> MTU.
>
>
>
> We try to get to https://www.pay.gov/public/home - which fails. I
> presume that is before there is any application name or ID.
>
> Try to reach that page from a browser on a machine with ipv6
> connectivity that goes thru a tunnel with a 1300 byte MTU. It will fail.
>
>
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v2.0.14 (GNU/Linux)
>
> iEYEAREKAAYFAlguP8oACgkQL6j7milTFsFgrQCfY2QLE0njiSRIILTzR4Fjpk3c
> F3AAnjZj8+3W51Qr9e1oGWAxrUC8Pnf3
> =UpN0
> -END PGP SIGNATURE-
>
>
>

Re: pay.gov and IPv6

[Sean Donelan]

On Thu, 17 Nov 2016, Mark Andrews wrote:

Why the hell should validating resolver have to work around the
crap you guys are using?  DO YOUR JOBS which is to use RFC COMPLIANT
servers.  You get PAID to do DNS because people think you are
compentent to do the job.  Evidence shows otherwise.

https://ednscomp.isc.org/compliance/gov-full-report.html show the broken
servers for .gov.  It isn't hard to check.



Engineer complains the universe doesn't match his assumptions.

Re: Amsterdam/London Underesea Cables

[Pierfrancesco Caci]

> "Rod" == Rod Beck  writes:


Rod> Hi,
Rod> I am trying to determine which undersea cables used for
Rod> London/Amsterdam traffic are the most reliable - fewest outages due to
Rod> shunt faults and other problems.

I'm surprised repeaters are needed at all, the Channel is not that wide
after all. 



-- 
Pierfrancesco Caci, ik5pvx

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 19 Nov, 2016

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

Analysis Summary


BGP routing table entries examined:  623487
Prefixes after maximum aggregation (per Origin AS):  220779
Deaggregation factor:  2.82
Unique aggregates announced (without unneeded subnets):  302048
Total ASes present in the Internet Routing Table: 55250
Prefixes per ASN: 11.28
Origin-only ASes present in the Internet Routing Table:   36327
Origin ASes announcing only one prefix:   15324
Transit ASes present in the Internet Routing Table:6538
Transit-only ASes present in the Internet Routing Table:164
Average AS path length visible in the Internet Routing Table:   4.3
Max AS path length visible:  36
Max AS path prepend of ASN ( 55644)  31
Prefixes from unregistered ASNs in the Routing Table:64
Unregistered ASNs in the Routing Table:  20
Number of 32-bit ASNs allocated by the RIRs:  16184
Number of 32-bit ASNs visible in the Routing Table:   12385
Prefixes from 32-bit ASNs in the Routing Table:   50127
Number of bogon 32-bit ASNs visible in the Routing Table:   386
Special use prefixes present in the Routing Table:0
Prefixes being announced from unallocated address space:407
Number of addresses announced to Internet:   2832026276
Equivalent to 168 /8s, 205 /16s and 74 /24s
Percentage of available address space announced:   76.5
Percentage of allocated address space announced:   76.5
Percentage of available address space allocated:  100.0
Percentage of address space in use by end-sites:   98.3
Total number of prefixes smaller than registry allocations:  205446

APNIC Region Analysis Summary
-

Prefixes being announced by APNIC Region ASes:   157521
Total APNIC prefixes after maximum aggregation:   42753
APNIC Deaggregation factor:3.68
Prefixes being announced from the APNIC address blocks:  171530
Unique aggregates announced from the APNIC address blocks:70096
APNIC Region origin ASes present in the Internet Routing Table:5184
APNIC Prefixes per ASN:   33.09
APNIC Region origin ASes announcing only one prefix:   1152
APNIC Region transit ASes present in the Internet Routing Table:942
Average APNIC Region AS path length visible:4.3
Max APNIC Region AS path length visible: 34
Number of APNIC region 32-bit ASNs visible in the Routing Table:   2490
Number of APNIC addresses announced to Internet:  759721284
Equivalent to 45 /8s, 72 /16s and 109 /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:187964
Total ARIN prefixes after maximum aggregation:89402
ARIN Deaggregation factor: 2.10
Prefixes being announced from the ARIN address blocks:   194317
Unique aggregates announced from the ARIN address blocks: 89233
ARIN Region origin ASes present in the Internet Routing Table:16138
ARIN Prefixes per ASN:12.04
ARIN Region origin A

Autunomous system filtering?

[Giuseppe Spanò - Datacast Srl]

Hi!

We are experiencing a strange issue with announcements from our AS207029.
On Sept. 16th we began to announce our prefixes 185.85.20.0/22 through our 
upstream provider AS28716 (E-Planet). Everything worked correctly.

Suddenly during the night between 17th and 18th Sept. the visibility of those 
prefixes dropped heavily (source: ripe stats) and we began experiencing big 
issues with our customers. We decided then to differentiate the announcements 
as it follows:

AS2876 announces 185.85.20.0/23
AS207029 announces 185.85.22.0/23 (those prefixes are idle at the moment)

essentially we split the /22 into two /23 so to keep monitored our AS 
propagation.
What’s happening is interesting:

prefixes announced by AS2876 are regularly spread everywhere, those announced 
by AS207029 not.
For example, we can see network 185.85.22.0/23 from HE looking glasses, but we 
cannot see it into Cogent, Level3 or Split looking glasses.

It seems an AS filtering is acting somewhere, and this looks a bit weird to me.
Did this ever happen to any of you? Do you have ideas?

Our upstream provider (that owns peering sessions with all the above providers) 
opened tickets to them, but if Network Engineers from Cogent, Level3 or Split 
should be reading this, could they kindly have a look into their filter 
configurations?

Thank you to all of you for your kind attention.

Regards,



Giuseppe Spanò - Datacast Srl
sp...@datacast.it

Re: pay.gov and IPv6

[Florian Weimer]

* Mark Andrews:

> The DNSSEC testing is also insufficient.  9-11commission.gov shows
> green for example but if you use DNS COOKIES (which BIND 9.10.4 and
> BIND 9.11.0 do) then servers barf and return BADVERS and validation
> fails.  QWEST you have been informed of this already.
>
> Why the hell should validating resolver have to work around the
> crap you guys are using?

The protocol doesn't have proper version negotation, and again and
again, implementers have tried to force backwards-incompatible
implementations on the Internet at large.

Re: pay.gov and IPv6

[Carl Byington]

> > I am working with pay.gov.c...@clev.frb.org, trying to explain the
> problem.

The intersection of government bureaucracy and technical issues is
frustrating to say the least. I just sent the message below, but have no
expectation that it will change anything. 

==

On Fri, 2016-11-18 at 12:39 +, CLEV Pay Gov wrote:
> It would be best to discuss this via phone.  Please contact our help
> desk at the number below and we could see if there's anything we could
> do over the phone to help troubleshoot.

That is hopeless. Verbal technical discussions rarely work unless both
sides can see the same text. Have you ever tried (while talking on the
phone) to get someone to type in clev.frb.org without making a bunch of
mistakes in the spelling??

Anyway, just for my amusement, I did call 800-624-1373, Option #2, and
am on the line now, trying to explain this. 10 minutes and counting. Ok,
there does not seem to be any overall ticket for "pay.gov does not work
at all". They refuse to open a tech support ticket.


> If not, we may need to open a ticket for our technical support.

Please open a ticket, and attach the following text for your tech
support folks. Alternatively, have them look at the "pay.gov and ipv6"
thread on nanog:

http://mailman.nanog.org/pipermail/nanog/2016-November/thread.html



www.pay.gov has an IPv6 address of 2605:3100:fffd:100::15, but that
machine or its upstream routers are filtering icmpv6 messages. That web
site is not accessible from systems with an MTU of 1280 bytes.

The test case is:

echo -e 'GET /public/home HTTP/1.0\n' | \
openssl s_client -servername www.pay.gov -ign_eof -connect \
'[2605:3100:fffd:100::15]:443'

Run that (or just use a browser to try https://www.pay.gov) from a
system with a 1500 byte MTU, and it works. Run it from a system with
upstream connectivity via a tunnel, so the path MTU is smaller, and it
fails. Such tunnels are common for IPv6.

Please stop filtering icmpv6.

Re: Autunomous system filtering?

[Massimiliano Stucchi]

Hi,

On 18/11/16 19:04, Giuseppe Spanò - Datacast Srl wrote:

> AS2876 announces 185.85.20.0/23
> AS207029 announces 185.85.22.0/23 (those prefixes are idle at the moment)

> It seems an AS filtering is acting somewhere, and this looks a bit weird to 
> me.
> Did this ever happen to any of you? Do you have ideas?

I think this might be due to missing route: objects for your announcements.

I see that you created them for the separate /23s a few hours ago, so
you should wait for the upstreams to pick them, which might happen in
the next 24 hours, so they can adjust their filters.  You could also
hope that some engineers pick it up here on list - as you asked - and
adjusts filters before the scheduled time comes.

Ciao!

-- 

Massimiliano Stucchi
MS16801-RIPE



signature.asc
Description: OpenPGP digital signature

China to HK providers you like?

[John A. Kilpatrick]

It's been a while since I've had to look at mainland China connectivity - 
what is the current situation for point-to-point business circuits from 
China domestic locations to a datacenter in HK?  Does anyone have 
providers they like?



--
   John A. Kilpatrick
j...@hypergeek.net | http://www.hypergeek.net/
 remember:  no obstacles/only challenges

R: Re: Autunomous system filtering?

[spano]

Thank you Massimiliano.

Consider that when we were announcing the whole /22 everything was working 
correctly, then suddenly some ASs stopped to accept our prefixes. That's why we 
decided to split the network and announce prefixes with different AS. Moreover 
the /23 announced by AS2876 spreaded correctly, even if the object has been 
created at the same time as the other...

Ciao! :)
Le mail ti raggiungono ovunque con BlackBerry® from Vodafone!

-Original Message-
From: Massimiliano Stucchi 
Sender: "NANOG" Date: Fri, 18 Nov 2016 19:36:53 
To: 
Reply-To: m...@stucchi.ch
Subject: Re: Autunomous system filtering?


Hi,

On 18/11/16 19:04, Giuseppe Spanò - Datacast Srl wrote:

> AS2876 announces 185.85.20.0/23
> AS207029 announces 185.85.22.0/23 (those prefixes are idle at the moment)

> It seems an AS filtering is acting somewhere, and this looks a bit weird to 
> me.
> Did this ever happen to any of you? Do you have ideas?

I think this might be due to missing route: objects for your announcements.

I see that you created them for the separate /23s a few hours ago, so
you should wait for the upstreams to pick them, which might happen in
the next 24 hours, so they can adjust their filters.  You could also
hope that some engineers pick it up here on list - as you asked - and
adjusts filters before the scheduled time comes.

Ciao!

-- 

Massimiliano Stucchi
MS16801-RIPE

Re: pay.gov and IPv6

[JORDI PALET MARTINEZ]

I tested from my home and happy eyeballs is not falling back to IPv4.

So, I tend to suspect that is not ICMPv6 filtering, but something else, such as 
wrong load balancer or ECMP configuration.

Regards,
Jordi


-Mensaje original-
De: NANOG  en nombre de Carl Byington 

Responder a: 
Fecha: sábado, 19 de noviembre de 2016, 3:22
Para: 
Asunto: Re: pay.gov and IPv6


> > I am working with pay.gov.c...@clev.frb.org, trying to explain the
> problem.

The intersection of government bureaucracy and technical issues is
frustrating to say the least. I just sent the message below, but have no
expectation that it will change anything. 

==

On Fri, 2016-11-18 at 12:39 +, CLEV Pay Gov wrote:
> It would be best to discuss this via phone.  Please contact our help
> desk at the number below and we could see if there's anything we could
> do over the phone to help troubleshoot.

That is hopeless. Verbal technical discussions rarely work unless both
sides can see the same text. Have you ever tried (while talking on the
phone) to get someone to type in clev.frb.org without making a bunch of
mistakes in the spelling??

Anyway, just for my amusement, I did call 800-624-1373, Option #2, and
am on the line now, trying to explain this. 10 minutes and counting. Ok,
there does not seem to be any overall ticket for "pay.gov does not work
at all". They refuse to open a tech support ticket.


> If not, we may need to open a ticket for our technical support.

Please open a ticket, and attach the following text for your tech
support folks. Alternatively, have them look at the "pay.gov and ipv6"
thread on nanog:

http://mailman.nanog.org/pipermail/nanog/2016-November/thread.html



www.pay.gov has an IPv6 address of 2605:3100:fffd:100::15, but that
machine or its upstream routers are filtering icmpv6 messages. That web
site is not accessible from systems with an MTU of 1280 bytes.

The test case is:

echo -e 'GET /public/home HTTP/1.0\n' | \
openssl s_client -servername www.pay.gov -ign_eof -connect \
'[2605:3100:fffd:100::15]:443'

Run that (or just use a browser to try https://www.pay.gov) from a
system with a 1500 byte MTU, and it works. Run it from a system with
upstream connectivity via a tunnel, so the path MTU is smaller, and it
fails. Such tunnels are common for IPv6.

Please stop filtering icmpv6.









**
IPv4 is over
Are you ready for the new Internet ?
http://www.consulintel.es
The IPv6 Company

This electronic message contains information which may be privileged or 
confidential. The information is intended to be for the use of the 
individual(s) named above. If you are not the intended recipient be aware that 
any disclosure, copying, distribution or use of the contents of this 
information, including attached files, is prohibited.

Re: Re: Autunomous system filtering?

[Yang Yu]

On Fri, Nov 18, 2016 at 1:39 PM,   wrote:

> Consider that when we were announcing the whole /22 everything was working 
> correctly, then suddenly some ASs stopped to accept our prefixes. That's why 
> we decided to split the network and announce prefixes with different AS. 
> Moreover the /23 announced by AS2876 spreaded correctly, even if the object 
> has been created at the same time as the other...


around 11/16 16:00UTC, 185.85.20.0/22's originating ASN changed from
AS28716 to AS207029

The route object for 185.85.20.0/22 had origin changed from AS28716 to
AS207029 at 2016-11-16T15:09:22Z but AS207029 was not in AS-RETELIT
(it is now 2016-11-18T14:34:44Z). So when AS28716's upstreams rebuilt
the inbound filter, 185.85.20.0/22 got dropped.

When AS28716's upstreams update the filter again, 185.85.22.0/23
should become visible. It looks like the route object for
185.85.20.0/22 has been deleted.

Is there a whowas service for routing registries?


Yang

Re: China to HK providers you like?

[Rod Beck]

PCCW might be a good choice given that Hong Kong is the gateway to China.



From: NANOG  on behalf of John A. Kilpatrick 

Sent: Friday, November 18, 2016 7:54 PM
To: nanog@nanog.org
Subject: China to HK providers you like?


It's been a while since I've had to look at mainland China connectivity -
what is the current situation for point-to-point business circuits from
China domestic locations to a datacenter in HK?  Does anyone have
providers they like?


--
John A. Kilpatrick
j...@hypergeek.net | http://www.hypergeek.net/
Hypergeek.net
www.hypergeek.net
A lot of this ride covered the area from my Sunday ride last weekend. We headed 
south along Blossom Hill until it turned into Santa Theresa - going in the 
opposite ...


  remember:  no obstacles/only challenges

Re: pay.gov and IPv6

[Mark Andrews]

In message <87twb4slol@mid.deneb.enyo.de>, Florian Weimer writes:
> * Mark Andrews:
> 
> > The DNSSEC testing is also insufficient.  9-11commission.gov shows
> > green for example but if you use DNS COOKIES (which BIND 9.10.4 and
> > BIND 9.11.0 do) then servers barf and return BADVERS and validation
> > fails.  QWEST you have been informed of this already.
> >
> > Why the hell should validating resolver have to work around the
> > crap you guys are using?
> 
> The protocol doesn't have proper version negotation, and again and
> again, implementers have tried to force backwards-incompatible
> implementations on the Internet at large.

The servers talk EDNS.  They server signed zones which require EDNS
support.  These are EDNS version 0 queries.  BADVERS is the response
code for when you receive a EDNS version field higher than the one
you implement and it requires that you use EDNS to send the rcode.

The query has a EDNS version field of 0.  The response has a EDNS
version field of 0.  The response has a rcode of BADVERS.

Yes, the behaviour of how to handle unknown options was clarified
in RFC 6891.  With RFC 2671 nameserver developer had a choice to
make

* BADVERS was never a sensible response however.  BADVERS had explict
  instructions for when it should be sent and they didn't include "if
  there is a EDNS option you don't understand return BADVERS".  If you
  thought the version field was wrong then that made it a malformed
  request which should elicit a FORMERR.

* FORMERR also wasn't a good idea.  RFC 2671 didn't say that no
  options could be added to a EDNS version 1 query but I can see if
  you thought EDNS version 0 was not allowed to have EDNS options
  that it could be seen as a malformed record.  Unless you know the
  format of the option you can't sensibly return FORMERR on it.

* NOTIMP would have made sense before RFC 6891 was published but we never
  saw a implementation that did this.

* Echoing back the option made some sense, though sending a option that
  you don't understand is risky.

* Ignoring the option also made sense.  This is what RFC 6891 says
  to do and matches the unknown EDNS flags behaviour.

* Ask the working group / IETF.

I wouldn't be complaining about it if they were only supporting
plain DNS.  You can tell the difference between a server that
supports EDNS and one that doesn't.  They behave differently.

Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org