From the last couple of hours there is a high noise ongoing on the outage
mailing list (which is a bit focused on outages within the US) about
Century Link / Level3 AS3356 outage.
As of now people are reporting of outage + fact that stale routes are still
visible. Level3 is one of the upstreams of many Indian networks like Airtel
AS9498, Jio AS64049, Sify AS9583 etc. Besides a lot of downstreams behind
Details about the outage are not very clear so far but likely limited to US
and Europe. Expect issues in connectivity with content and eyeballs in
---------- Forwarded message ---------
From: Lukas Tribus via Outages <outages(a)outages.org>
Date: Sun, Aug 30, 2020 at 6:03 PM
Subject: [outages] 3356 does not WITHDRAW bgp routes
As previously mentioned by Stephen Flynn, 3356 does not WITHDRAW stale
bgp routes, can be confirmed with AT&T's route server at (telnet
Stale routes from 1 hour + are still announced by 3356.
This is causing blackholing.
Outages mailing list
we are facing google mail attachment issue
after complain to our upstream provider He told us that everyone was having
problems from the Google side
who is facing this issue?
Dishawaves Infonet Pvt. Ltd.
Cell - 94266 55866 |HelpDesk - 99042 56666
302, Matrix, Near Divyabhaskar Press, Corporate Road, Prahalad nagar,
Ahmedabad - 380015
Please consider the environment before printing this e-mail.
Swapneel and I are doing a two day webinar on RIPE Atlas.
It will be from 2pm to 3pm on 18th and 19th Aug. If you want to learn how
to check routing of your network from various other networks in India and
across the world this is for you!
Using RIPE Atlas a provider can trace from 80+ probes spread across various
networks in India and 11000+ probes spread across the world.
Details of the webinar are here
In response to feedback from operational security communities,
CAIDA's source address validation measurement project
(https://spoofer.caida.org) is automatically generating monthly
reports of ASes originating prefixes in BGP for systems from which
we received packets with a spoofed source address.
We are publishing these reports to network and security operations
lists in order to ensure this information reaches operational
contacts in these ASes.
This report summarises tests conducted within ind.
Inferred improvements during Jul 2020:
ASN Name Fixed-By
24560 AIRTELBROADBAND 2020-07-11
55836 RELIANCEJIO-IN 2020-07-13
Further information for the inferred remediation is available at:
Source Address Validation issues inferred during Jul 2020:
ASN Name First-Spoofed Last-Spoofed
24560 AIRTELBROADBAND 2016-03-12 2020-07-23
9498 BBIL-AP 2016-11-01 2020-07-21
55836 RELIANCEJIO-IN 2017-03-03 2020-07-30
24186 RAILTEL 2018-12-08 2020-07-26
Further information for these tests where we received spoofed
packets is available at:
Please send any feedback or suggestions to spoofer-info(a)caida.org
Hello INNOG community!
As many of you might be aware - there's a major effort ongoing for
deploying RPKI across the globe. At my daytime job (at Hurricane Electric /
AS6939) we recently deployed RPKI validation. Many other large networks
have also deployed RPKI in the last few months including but not limited to
AT&T, KPN, GTT, Telia, Cognet, NTT, Seacom besides many larger exchanges.
As far as I can see Tata Communications global AS6453 also seems to be
dropping a large number of invalids (likely from their peers) besides ACT
broadband which is also dropping invalids across a large part of its
*Deploying RPKI essentially has two key parts: *
1. Signing your own prefixes / Creating RPKI ROAs
Here you sign your prefixes. It's similar to IRR route object but
technically much better as it's a cryptographic signature which can be
easily validated by a supported router. Having your own prefixes signed
saves you from a possible hijack attempt of your prefixes. If anyone
hijacks your unsigned prefixes, the announcement would be visible almost
across the globe but if they are signed, you can expect most of the
networks I listed above to be dropping those invalids.
2. Dropping invalids
Here you are expected to drop prefixes (of others) which you see do not
carry a valid RPKI ROA. This part requires the support of RPKI in your
Both of these steps are independent of each other. A network can create
ROAs without validating or vice versa. As of now when looking across South
and East Asia, we (India) seems to be lagging quite badly on ROA creation.
There are around 42k prefixes visible in the global table from India and
out of this only 5k are signed i.e just 12%. Comparing this to our
neighbours - Bangladesh is at 82%, Myanmar at 78%, Nepal & Sri Lanka at
90%, Pakistan at 73%and Taiwan + Mangolia are at 90%+ levels.
[image: Screenshot 2020-07-18 at 1.44.36 AM.png]
I have created a public dashboard to track the deployment across Asia with
a focus on India. If interested, you can check it here:
*If you are a network operator with IP addresses, please consider the
1. Create an RPKI ROAs for your prefixes. If your resources are from
APNIC, you can do that at My APNIC portal. If your resources are from
IRINN, you can request IRINN to create ROAs for your prefixes (similar to
the way you request for the route objects). You would need to inform IRINN
for the Prefix + origin ASN you would like to use to originate it +
the max allowed subnet mask (like /24 or /23...whatever upto size you wish
to use in announcing prefix).
2. Check out the invalids in India table published here:
If you see any of your prefixes here, please consider fixing those.
These announcements are already being rejected by various large networks
and will cause issues for your customers.
If you would like to read more about RPKI, this documentation can be a good
start: https://rpki.readthedocs.io/en/latest/rpki/introduction.html and if
you are wondering if your hardware is supported for dropping invalids, this
one covers it:
Feel free to write back here if you have any questions.