IRR & RPKI Policy

Introduction

Filtering on our edge is generated from routing registry data and validated against RPKI. Nothing is accepted simply because it looks plausible. This page sets out what we expect from customers and peers, and what our routers do with announcements that do not match. Filters rebuild automatically on a schedule, so registering a prefix correctly is normally all that is needed for it to be accepted.

IRR Policy

Customers and peers must maintain up-to-date objects in a recognized IRR database (RIPE, RADB, ARIN, etc.). Our filters are generated automatically from IRR data and applied across our edge routers.

• All prefixes must be properly registered in the IRR.
• Customers should maintain an as-set object (e.g., AS216265:AS-ARISTONET).
• Route objects must include the correct origin ASN (AS216265 or customer ASN).

RPKI Policy

Aristo Networks fully supports RPKI route origin validation. All customer and peer announcements must have valid Route Origin Authorizations (ROAs). Invalids will be dropped, while unknowns are accepted but monitored.

• All customer prefixes must be RPKI signed.
• Invalid ROAs will result in prefix rejection.
• RPKI validation is enforced across all BGP sessions with AS216265.

Peering & Compliance

Compliance with these IRR and RPKI requirements is mandatory for all customers and peers. Non-compliant routes may be filtered automatically.

• ASN: 216265
• IRR as-set: AS216265:AS-ARISTONET
• RPKI: All prefixes signed and validated
• Peering Policy: Open peering at major IXPs