Registry Working Group

[Bill Owens <>]

Glad to hear the filtering won’t start just yet, although I have to say that whatever update they did this afternoon has cleaned up all the false errors that we were seeing – the remaining invalid routes really are missing their IRR objects.

 

I just looked through the portal and can’t find any reference to the AS-SET, but I do have it in our PeeringDB record, and I’m sure I gave it to them in email while we were setting up the connection originally. We’ve been publishing the AS-SET for a long time just to document the ASes behind us, even though we knew the rest of the IRR objects weren’t up to snuff. For one thing it was a shorthand way of telling prospective peers about what traffic we would be bringing to them, and I think it helped to have it in PeeringDB even when the rest of the config wasn’t ready. I didn’t find anyone who filtered on it until Google (but we don’t peer with HE).

 

Bill.

 

From: Jeff Bartig <>
Date: Monday, August 26, 2019 at 17:12
To: "" <>, Bill Owens <>
Subject: Re: [WG-IRR] Some Google observations

 

Google is not filtering routes at this time.  They have been saying they would start this in September, but based on emails I exchanged with them last week, this is behind schedule.  They are now saying they will not start filtering before October.

Their plan has been to publish what they will filter in their ISP portal before they implement the filtering, so issues can be identified.  I believe that is what they just started doing last week.

Bill, have you been able to find anywhere in their ISP portal where they show which AS-SET they have selected for your network?  I've been looking, but I haven't found that information any where in their portal.

Jeff

Bill Owens wrote on 8/26/19 11:07 AM:

As Jeff Bartig pointed out last week, Google is now flagging routes as 'irr-invalid' in their ISP portal. However, in our case every 'invalid' route is actually being accepted and carrying traffic, though I can't tell whether that's because they are simply flagging, or because the ISP portal report is out of sync with the real filters. I'm leaning towards the former, that they are only reporting errors without placing the filters on the actual BGP sessions, because we have one prefix that is intentionally not in the RADb or any other IRR and it is still accepted. 

For some of the errors it appears they simply aren't getting a complete view of the data, since the vast majority of the 'invalid' routes have RADb entries. In at least a couple of cases all of the routes for a particular origin AS are flagged invalid except those that have old Level3 IRR objects, but there's no pattern I can discern. They do not appear to be using ARIN WHOIS OriginAS. For those keeping score, we are advertising 132 routes, they are flagging 35, all but one of those have correct RADb objects.

I've been doing my testing by starting up a GCP instance and running traceroute from the CLI, absent any Google traceroute looking glass. That works fine except that the GCP instance doesn't appear to have any support for IPv6, so I can only test v4 routes.

We do have one case where a campus is originating their prefix to NYSERNet using their AS, and having their ISP (a cable company) originate it using the ISP's AS; Google seems to be somewhat confused by this and is actually using both paths. We're going to work on that. There are valid RADb objects for both origins, and yet Google is flagging the one that comes across our peering. Weird.

Bill.

 

--
Jeff Bartig
Interconnection Architect
Internet2  AS11164 / AS11537
+1-608-616-9908