Autunomous system filtering?
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 spano@datacast.it
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) <SNIP> 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
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 <max@stucchi.ch> Sender: "NANOG" <nanog-bounces@nanog.org>Date: Fri, 18 Nov 2016 19:36:53 To: <nanog@nanog.org> Reply-To: max@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) <SNIP> 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
On Fri, Nov 18, 2016 at 1:39 PM, <spano@datacast.it> 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
participants (4)
-
Giuseppe Spanò - Datacast Srl -
Massimiliano Stucchi -
spano＠datacast.it
-
Yang Yu