[181005] in North American Network Operators' Group
Re: AS4788 Telecom Malaysia major route leak?
daemon@ATHENA.MIT.EDU (joel jaeggli)
Sat Jun 13 14:07:37 2015
X-Original-To: nanog@nanog.org
To: Mark Tinka <mark.tinka@seacom.mu>, =?UTF-8?Q?J=c3=bcrgen_Jaritsch?=
<jj@anexia.at>, "nanog@nanog.org" <nanog@nanog.org>
From: joel jaeggli <joelja@bogus.com>
Date: Sat, 13 Jun 2015 11:07:18 -0700
In-Reply-To: <557C0871.6030800@seacom.mu>
Errors-To: nanog-bounces@nanog.org
This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--meREBc6nA2JIo1RHEdRA7t0encu5jpi1G
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable
On 6/13/15 3:39 AM, Mark Tinka wrote:
>=20
>=20
> On 12/Jun/15 22:25, J=FCrgen Jaritsch wrote:
>> This is the official feedback:
>>
>>
>>
>> Level 3's network, alongside some other ISP's, experienced service dis=
ruptions affecting customers in Europe, Asia and multiple other markets. =
IP, Voice and Content Delivery Network (CDN) services were affected for L=
evel 3. The root cause of the issue was isolated to a third party Interne=
t Service Provider in Asia that leaked internet routes resulting in traff=
ic being sent to a destination that could not route them, which affected =
IP, Voice and CDN services in multiple markets. The issue has been resolv=
ed, but the provider continues working to determine the specific root cau=
se of the incident. At this time, customer services are restored with the=
exception of any that pose any possible risk to the Level 3 network. Mai=
ntaining a reliable, high-performing network for our customers is our top=
priority. Level 3 will continue to work with the provider to prevent a r=
ecurrence.
>=20
> While I agree that TM needs to look into its operational procedures, I
> think Level(3) needs to shoulder more of the blame, and not simply pass=
> the buck to TM.
if you localpref your customer up, you should probably not be willing to
accept the whole internet from them.
> TM has several more upstreams other than Level(3). Assuming their issue=
> affected all their border routers, we did not see an issue via their
> other upstreams other than Level(3) - although this is conjecture on my=
> part.
they also have ~ 180 ASNs in their downstream cone who presumably get a
full table have the export policy that did the business in this case
applied all the time.
> Level(3) should have filtered at the time they were turning up TM.
> Simple as that.
>=20
> We all know we should never trust customers. So...
>=20
> Mark.
>=20
--meREBc6nA2JIo1RHEdRA7t0encu5jpi1G
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.22 (Darwin)
Comment: GPGTools - http://gpgtools.org
iEYEARECAAYFAlV8cVcACgkQ8AA1q7Z/VrIhnACfQeB4xdAQ2TCfXswuoIKQSE6f
YbwAn1+1kt6d0dUp9ASrw1qkPICTHGiR
=5Ytx
-----END PGP SIGNATURE-----
--meREBc6nA2JIo1RHEdRA7t0encu5jpi1G--
