Routing Algorithm of Kawaii Networks

We use bgpq4 to generate as-sets and prefix lists. The databases we adopt include:

RPKI,AFRINIC,ARIN,APNIC,LACNIC,RIPE,RADB,ALTDB

Term Definitions:

• Accept: Accept the route, it will not participate in further filtering.
• Reject: Reject the route, it will not participate in further filtering.
• Match: Match the route, it continues to participate in filtering.

For every BGP session, we generate a corresponding receive filter and a send filter. Router configurations are generated via GitHub Actions daily at 10:00 and 22:00, and applied at 12:00 and 00:00. The specific algorithms are as follows:

Receiving Routes

IBGP

1. Accept all additionally allowed prefixes.
2. Accept all prefixes belonging to our own AS, accepting up to /32 (IPv4) and /128 (IPv6).
3. Reject all routes with prefix lengths between 0-7, 25-32 (IPv4), and 0-15, 49-128 (IPv6). Reject all routes whose as-path contains Bogon ASNs. Reject all Bogon IPv4 and Bogon IPv6 prefixes.
4. Reject all RPKI Invalid routes.

Route Attributes:

• Set local-preference to 90 for all accepted routes.

TIP

There is currently no settled conclusion regarding IBGP local-preference. It should relate to the send mode.

EBGP

Upstream

1. Reject all routes with prefix lengths between 0-7, 25-32 (IPv4), and 0-15, 49-128 (IPv6). Reject all routes whose as-path contains Bogon ASNs. Reject all Bogon IPv4 and Bogon IPv6 prefixes.
2. Reject all RPKI Invalid routes.

Route Attributes:

• Set local-preference to 100 for all accepted routes.

IX Route Server

If the IX has not set an IRR as-set on PeeringDB, it is treated as an Upstream. If the IX has set an IRR as-set on PeeringDB, it is treated as a Peer.

Route Attributes:

• Set local-preference to 130 for all accepted routes.

TIP

Currently, all IX Route Servers are treated as Upstreams.

Peer

1. For a network establishing a connection with us, we first look up its IRR as-set, IPv4 Prefixes, and IPv6 Prefixes using its ASN on PeeringDB. If the IRR as-set is empty, we use its ASN as the AS-SET (e.g., AS23333). If IPv4 Prefixes or IPv6 Prefixes is empty (0), we close the session.
2. Reject all routes with prefix lengths between 0-7, 25-32 (IPv4), and 0-15, 49-128 (IPv6). Reject all routes whose as-path contains Bogon ASNs. Reject all Bogon IPv4 and Bogon IPv6 prefixes.
3. Reject all RPKI Invalid routes.
4. Reject all routes whose as-path does not conform to the network's AS-SET. The as-path should resemble a pyramid, where adjacent ASes from left to right share a direct Upstream - Downstream relationship.
5. Reject all routes not in the prefix list.

Route Attributes:

• Set local-preference to 160 for all accepted routes.

TIP

Currently, we only reject routes whose as-path does not conform to: leftmost is Peer AS, rightmost is its Cone AS.

Currently, if the AS Cone is too large (causing the AS-SET and prefix list to be excessively large), we only reject routes whose as-path does not conform to the leftmost being the Peer AS, and we do not apply restrictions based on the prefix list.

Downstream

Treated as Peer.

Route Attributes:

• Set local-preference to 200 for all accepted routes.

Sending Routes

IBGP

TIP

There is currently no settled conclusion on how IBGP should send routes.

Mode 1

1. Accept all additionally allowed prefixes.
2. Accept all prefixes belonging to our own AS, accepting up to /32 (IPv4) and /128 (IPv6).

Mode 2

1. Match all static and connected route types.
2. Match all other routes.
3. Accept all additionally allowed prefixes.
4. Accept all prefixes belonging to our own AS, accepting up to /32 (IPv4) and /128 (IPv6).
5. Reject all routes with prefix lengths between 0-7, 25-32 (IPv4), and 0-15, 49-128 (IPv6). Reject all routes whose as-path contains Bogon ASNs. Reject all Bogon IPv4 and Bogon IPv6 prefixes.
6. Reject all RPKI Invalid routes.

EBGP

Upstream

1. Match all static and connected route types. Accept all prefixes belonging to our own AS, accepting up to /24 (IPv4) and /48 (IPv6).
2. Reject routes received from IBGP.
3. Accept all routes originating from Downstreams. (Thus only local Downstreams are sent to upstream providers)

IX Route Server

Treated as Upstream.

Peer

1. Match all static and connected route types.
2. Match all routes originating from our own AS. (e.g., obtained from IBGP)
3. Accept all prefixes belonging to our own AS, accepting up to /24 (IPv4) and /48 (IPv6).
4. Match and accept all routes originating from Downstreams.

Downstream

1. Match all static and connected route types.
2. Match all routes originating from our own AS. (e.g., obtained from IBGP)
3. Accept all prefixes belonging to our own AS, accepting up to /24 (IPv4) and /48 (IPv6).
4. Match and accept all routes originating from Downstreams.
5. Match and accept all routes originating from Peers.
6. Match and accept all routes originating from IX Route Servers.
7. Match and accept all routes originating from Upstreams.
8. Match and accept all routes originating from IBGP.