<div dir="ltr">It seems TATA has stopped announcing the /24. NTT and Cogent now see the <a href="http://209.58.0.0/17">209.58.0.0/17</a> and traceroutes aren't taking the scenic route anymore. Thank you everyone that helped!</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Oct 5, 2020 at 12:08 PM Job Snijders <<a href="mailto:job@ntt.net">job@ntt.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Dear all,<br>
<br>
>From the website:<br>
<br>
Q: Why does AS 2914 still propagate some RPKI Invalid routes?<br>
<br>
A: On March 25th, 2020, the Global IP Network division of NTT Ltd. has<br>
completed a very important milestone in the deployment of RPKI<br>
throughout its network to date. Through this effort, AS 2914 no longer<br>
propagates a majority of RPKI invalid BGP routes that can potentially be<br>
received through the global Internet routing system.<br>
<br>
Currently, a number of technical caveats affects our ability for a 100%<br>
deployment. A limited number of RPKI invalid route announcements are<br>
still propagated to EBGP peers, at the moment of writing this the number<br>
is approximately 650 routes. We are developing technical workarounds and<br>
engaging vendors in order to enable us to gradually decrease this number<br>
in the coming months. We remain committed to global RPKI deployment, and<br>
we will provide updates on our progress from time to time as we work to<br>
reduce this number to zero.<br>
<br>
More information: <a href="https://www.gin.ntt.net/support-center/policies-procedures/routing-registry/" rel="noreferrer" target="_blank">https://www.gin.ntt.net/support-center/policies-procedures/routing-registry/</a><br>
<br>
We've reached out to tata, they are aware and working on it.<br>
<br>
Kind regards,<br>
<br>
Job<br>
<br>
On Mon, Oct 05, 2020 at 08:33:28PM +0200, Lukas Tribus wrote:<br>
> Hello,<br>
> <br>
> <br>
> On Mon, 5 Oct 2020 at 19:35, Jared Geiger via Outages<br>
> <<a href="mailto:outages@outages.org" target="_blank">outages@outages.org</a>> wrote:<br>
> ><br>
> > If anyone at TATA 6453 is watching, you're announcing <a href="http://209.58.46.0/24" rel="noreferrer" target="_blank">209.58.46.0/24</a> to NTT 2914 in Sydney causing traffic to your North American VOIP network to go through Australia. The rest of your announcements to your peers are for <a href="http://209.58.0.0/17" rel="noreferrer" target="_blank">209.58.0.0/17</a> which correctly keeps the traffic in North America. Filtering the /24 out of NTT's BGP feed fixed my latency and packet loss problem. NTT contacted the TATA NOC on my behalf but no one has fixed it yet.<br>
> <br>
> <br>
> Moving to outages-discussion@<br>
> <br>
> This is a RPKI invalid prefix, the ROA <a href="http://209.58.0.0/17" rel="noreferrer" target="_blank">209.58.0.0/17</a> has maxlength /17<br>
> with a creation date back in August. Unless there was a parallel /24<br>
> ROA just a few minutes ago, I don't get it why 174, 2914 and other<br>
> networks would carry this prefix in their table:<br>
> <br>
> <a href="http://lg.ring.nlnog.net/prefix_detail/lg01/ipv4?q=209.58.46.0/24" rel="noreferrer" target="_blank">http://lg.ring.nlnog.net/prefix_detail/lg01/ipv4?q=209.58.46.0/24</a><br>
> <br>
> <a href="https://rpki.cloudflare.com/?view=validator&validateRoute=6453_209.58.46.0%2F24" rel="noreferrer" target="_blank">https://rpki.cloudflare.com/?view=validator&validateRoute=6453_209.58.46.0%2F24</a><br>
> <br>
> <br>
> Looks like 6453 is originating a number of invalids actually, but I<br>
> would expect the ROV enabled networks to drop those prefixes:<br>
> <a href="https://bgp.he.net/AS6453#_prefixes" rel="noreferrer" target="_blank">https://bgp.he.net/AS6453#_prefixes</a><br>
> <br>
> <br>
> Thoughts?<br>
> <br>
> <br>
> <br>
> Lukas<br>
</blockquote></div>