The peering policy for EdgeNXT IX Route Servers is outlined as follows:

Traffic Exchange

Traffic exchange within EdgeNXT IX participants occurs through two methods:

1. Route Servers: Participants can exchange IP traffic using BGP protocol through the route servers provided by EdgeNXT IX, facilitating simplified connectivity.
2. Bilateral BGP Sessions: EdgeNXT IX encourages participants to establish bilateral BGP sessions with CDN providers for enhanced traffic control and increased traffic flow from CDN networks.

Route Servers Peering Policies

Disabling first AS check

• The Route Servers do not have their AS first in the AS_PATH. As Router-server is transparent, due to which participant see each other as directly connected to each other.
• In some routers you might need to disable "first AS check" in your config.
• On Cisco routers please specify ‘no bgp enforce-first-as’ or ‘bgp enforce-first-as disable’ to disable the enforcement. On Huawei routers please specify ‘undo check-first-as’ to disable the enforcement.

Router-server Filter

Participants are required to announce only their own routes and the routes of their downstream customers towards the Route-server peering. Incorrect route advertisement will be filtered out.

The route servers will filter inbound routes advertisement, which means that using the route servers for peering is generally much safer than peering directly with other participants.

We are doing RPKI and IRRdb based filtering for all participants establishing BGP sessions with our route servers, to filter out incorrect route advertisement. And to allow connected members advertise only prefixes which they have registered publicly.

The route-server enforces route filtering policy based on the following rules and sequence:

1. IP prefixes with only below subnet-mask range, will be accepted.

IPv4: /8 <= and <= /24,  IPv6: /19 <= and <= /48.

2. Drop all well-known Martians and bogons.
3. Ensure that the peer AS is the same as the first AS in the AS path.
4. Drop any prefix where the next-hop IP address is not the same as the peer IP address. This prevents prefix hijacking.
5. Drop any prefix with a well-known transit network ASN in the AS path.
6. Ensure that your IRRDB AS-SET is updated with your origin AS object and also your all downstream ASN is added in your AS-set. Share "as-set" object with us.
7. If your prefix has a valid RPKI ROA, it will be accepted.
8. If the prefix is evaluated as RPKI invalid, drop.
9. If the prefix is evaluated as RPKI unknown (no ROA exists), fallback to standard IRRDB prefix filtering:

Participants must refrain from advertising their peering LAN IP-prefix, routes learned from Route-server to other transit networks. Additionally, participants are strictly prohibited from announcing private IP addresses to the route servers.

If you find any BGP route-leaks on Route-server peering, please report the case to EdgeNXT NOC at ixsupport@edgenxt.com

BGP Community

Operational BGP Communities can be used to control various functions of the route server, such as redistribution of advertised prefixes, based on ASN.

This allows you to precisely manage your BGP announcements and distribute them only to specific participants.