filter route and AS (possible feature request)

[m0yellow]

Hello, I'm searching for a solution to filter the routes an AS sends me, and if they are originate from the right AS.

Principle: when peering with 64500, it sends me its own routes, plus the routes of their customers. Due to frequent configuration error, 64500 sends me route of Customer 64510 as their own.

This leads to potential routing problems, but also extended troubleshooting on my side, as this route is obviously filtered in some places.

Is there a possibility to output further filters, when querying for an as-set, to have the routes group by orgin AS? This would immediately filter those wrong announcements.

From my current point of view (as I'm using JunOS), this could be easily accomplished with a configuration block a this:

# show | compare 
[edit policy-options]
+   policy-statement PERMIT-AS64500-IN {
+       term AS64500-ROUTES {
+           from {
+               as-path AS64500;
+               route-filter 192.0.2.0/24 exact;
+           }
+       }
+       term AS64500_AS64510-ROUTES {
+           from {
+               as-path AS64500_AS64510;
+               route-filter 10.0.0.0/23 upto /24;
+           }
+       }
+   }
[edit policy-options]
+   as-path AS64500 64500+;
+   as-path AS64500_64510 "64500+ 64510+";

When included as import filter, this allows both networks to prepend their path as needed, but disallows an origin not documented in the RADB.

I have multiple use cases for this filters, and I hope I'm not alone with this, as I would have to script it externally (due to lack of skills in C).

[snar]

On Tue, Apr 14, 2020 at 08:23:41AM -0700, Matthias Šubik wrote:

Hello, I'm searching for a solution to filter the routes an AS sends me, and if they are originate from the right AS.

Have you considered running RPKI validation for your customers ? Looks like a perfect match for your case...

Principle: when peering with 64500, it sends me its own routes, plus the routes of their customers. Due to frequent configuration error, 64500 sends me route of Customer 64510 as their own.

This leads to potential routing problems, but also extended troubleshooting on my side, as this route is obviously filtered in some places.

Is there a possibility to output further filters, when querying for an as-set, to have the routes group by orgin AS? This would immediately filter those wrong announcements.

From my current point of view (as I'm using JunOS), this could be easily accomplished with a configuration block a this:

show | compare

[edit policy-options]

• policy-statement PERMIT-AS64500-IN {
• term AS64500-ROUTES {
• from {
• as-path AS64500;
• route-filter 192.0.2.0/24 exact;
• }
• }
• term AS64500_AS64510-ROUTES {
• from {
• as-path AS64500_AS64510;
• route-filter 10.0.0.0/23 upto /24;
• }
• }
• } [edit policy-options]
• as-path AS64500 64500+;
• as-path AS64500_64510 "64500+ 64510+";

When included as import filter, this allows both networks to prepend their path as needed, but disallows an origin not documented in the RADB.

I have multiple use cases for this filters, and I hope I'm not alone, with this, as I would have to script it externally (due to lack of skills in C).

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or unsubscribe.*

[m0yellow]

Thanks for your fast reply. We already do RPKI validation, but this is for the legacy customers, which miss out on RPKI. Some of them get default route from us, but still announce more than one AS. Since we hoped RPKI closes that window, but we have to defer full validation for a bit more.

So the idea came up, just make the filters tighter. We already list all routes manually on legacy customers, but they still manage to limit their/their customers reachability by sending wrong origin. Since we transport this routes to some big IXes, we want to have them clean.

I haven't looked in your source, how you represent the downloaded data from the RADB in RAM, but I assume since you validate all route origins by route object, you already know which AS emit which routes. This would allow dumping them in batches per AS. The example I provided was created on an MX, to test the applicability of such a filter. I haven't looked into all customers AS-sets, but I'm sure that would work. Do you think such a feature could be useful for other AS that have legacy customers (academic networks bandwidth buying bodys maybe?)