Configuring route-server BGP

Configure sessions from your assigned peering addresses to all CNX route servers. The route-server side is passive, so your router must initiate TCP/179.

Configure all three route servers. CNX operates the route servers as a redundant service, not as individually guaranteed endpoints. CNX may remove one server from service for routine rolling maintenance without customer notification. Configure and monitor both address families on all three servers so peering continues while an individual server is unavailable. A configuration using fewer than all three is not fully redundant.

1. Create explicit export filters

Build separate IPv4 and IPv6 prefix lists containing only routes you intend to announce. An aggregate must exist in the local routing table before most platforms will originate it with a BGP network statement.

Example policy intent:

permit 203.0.113.0/24 exact
permit 2001:db8:100::/48 exact
reject everything else

Replace these documentation prefixes with your registered resources. Match the actual announced prefix length, IRR objects, and ROA maxLength.

2. Create route-server peer groups

Use AS132213 as the remote ASN. Activate the appropriate address family for each neighbor and apply the same export policy to every route server.

CNX route servers preserve the originating member's AS_PATH; they do not insert AS132213. Disable first-AS enforcement on platforms that otherwise require the remote ASN to be the first ASN in every received path.

Do not set next-hop-self on received CNX routes. The route's next hop is the member router that forwards the traffic and must remain reachable on the peering LAN.

3. Apply inbound policy

Set maximum-prefix limits on your side as protection against an unexpected route volume. CNX recommends preferring accepted CNX routes over paid transit by assigning them a higher local preference. Keep ROV, bogon, leak, and other normal safety filters in front of that preference; free traffic is not unfiltered traffic.

For IOS XE, merge this intent into the existing inbound policy for both address families:

! Keep normal safety filters: free traffic is not unfiltered traffic.
route-map bgp-cnx-rs4-in deny 10
 match rpki invalid
! Prefer accepted CNX routes over paid transit: there is no transit charge.
route-map bgp-cnx-rs4-in permit 100
 set local-preference 300

router bgp <YOUR_ASN>
 no bgp enforce-first-as
 ! Compare MED consistently across routes received through the route servers.
 bgp always-compare-med

Apply the same preference to the IPv6 CNX import policy. Choose a value that is higher than paid transit but still fits your network's existing local- preference hierarchy.

Avoid filtering only on AS132213 in the received AS_PATH; the transparent route server does not add it. Use the session identity and the original path attributes instead.

4. Activate both address families

Establish IPv4 and IPv6 independently. A working IPv4 session does not prove that IPv6 addressing, neighbour discovery, filters, or advertisements are correct.

See Platform configuration patterns for IOS-XE, Junos, and Huawei VRP examples.

Minimal route-server neighbor patterns are:

Cisco IOS XE: neighbor 103.7.144.1 remote-as 132213
Junos OS:     set protocols bgp group CNX-RS neighbor 103.7.144.1 peer-as 132213
Huawei VRP:   peer 103.7.144.1 as-number 132213

Create equivalent sessions for all three IPv4 and all three IPv6 endpoints, bind the correct local address, disable first-AS enforcement only for these route-server sessions, and attach strict inbound and outbound policy. The complete platform pages include those surrounding controls.

5. Verify before changing preference

Complete Verifying peering before increasing local preference or moving production traffic. Confirm received next hops, accepted prefixes, exported prefixes, ROV status, and forwarding in both directions.