Route Server Filtering

Incoming prefixes filtering

Basically, Following checks will be applied at route servers incoming announcement and will reject those non compliant prefixes

• Bogons and Martians (Reference : TEAM CYMRU BONONS List)
• Prefix length
• IPV4 subnet mask during /8 and /24, inclusively.
• IPV6 subnet mask during /19 and /48, inclusively.
• Private ASN : Prefix containing private ASN in its AS_PATH
• Default route
• IXP Prefix
• BGP Next Hop verification : bgp next hop attribute must same as the source of bgp peer address.
• BGP AS verification : The leftmost AS of AS_PATH must be the same ASN as the bgp peer ASN.

From March 2019, BKNIX introduces 4 filtering mode for receiving prefixes from route servers. BKNIX members can easily change the policy in the IXP-Manager

• IRRDB and RPKI Filtering (Default)
By selecting this mode, the route servers will apply both IRRDB based and RPKI based filtering. The prefixes announcement are valid in both filtering. This is a default option for all route server clients.


• IRRDB Filtering
By selecting this mode, the route servers will apply IRRDB based filtering. if prefixes appear in Member’s pre-defined AS/AS-SET, Route server will announce this prefixes to other clients.


• RPKI Filtering
By selecting this mode, the route servers will apply RPKI based filtering - Performing Route Origin Validation (ROV) using RPKI. If ROV status is INVALID^*, Route servers will not announce that prefix to other clients.


• No filtering (not recommend, for special purpose only)
The route servers will announce all prefixes learnt from other members and then tag with bgp standard community and large community based on matching matching criteria.
To use this mode, member needs to send the request showing the need and purpose by e-mail to noc@bknix.co.th.

IRRDB based Filtering

Each member has to define the AS-SET object (or AUT-NUM) using as the key for doing the recursive search to generate list of the ROUTE objects expected to see from member. BGPQ3 will be using for generating list from specific IRR source namely, APNIC, AFRINIC, ARIN, ALTDB, LACNIC, LEVEL3, RADB, RIPE, RGNET etc.
If the route is in the generated list from AS-SET/AS-NUM, It’s called ‘IRRDB found’ and propagated to other route server clients.

RPKI based Filtering

BKNIX has the local validated cache implemented by RPKI Relying Party (RP) software called rcynic which is the part of RPKI toolkit 'rpki.net' In order to feed the ROA records to route servers for BGP Origin Validation.
If the ROV status is VALID^* or UNKNOWN^*, the route is tagged with the communities "63529:65010, 63529:1000:1" or "63529:65011, 63529:1000:2" respectively and propagated to other route server clients.
On the other hand, If the ROV status is INVALID^* , the route is tagged with the communities "63529:65014, 63529:1000:4" and will be rejected by BKNIX Route server.

*please refer the definition of VALID, UNKNOWN and INVALID regarding RFC6483

---