Overview
The Route Servers are available to all participants. Peering with the Route Servers is optional. Some participants may prefer to establish directing BGP peering relationships.
- Router Server ASN: 64234
- Route Server 1 (RS1):
- IPv4 206.41.104.253
- IPv6 2001:504:39::253
- Route Server 2 (RS2):
- IPv4 206.41.104.254
- IPv6 2001:504:39::254
- IPv4 maximum prefixes: 200,000
- IPv6 maximum prefixes: 100,000
BGP sessions are pre-configured for all VANIX participants on the VANIX route servers. Sessions are configured to be passive.
The route servers do not add the VANIX AS into the AS path. Participants using Cisco routers might need to add “no bgp enforce-first-as” to their BGP neighbor configuration, or the router will discard all VANIX routes as the AS paths do not begin with the VANIX AS.
VANIX’s route servers are based on the ARouteServer project.
BGP Communities
VANIX supports a comprehensive set of BGP communities for configuration of your routing policy.
VANIX supports new large communities in addition to standard communities. Not all router implementations support large communities, so if you are unsure which type to use, go with standard communities.
| Feature | Standard Community | Large Community |
|---|---|---|
| Prepend AS once to specific participant | 1:peer_as | 64234:101:peer_as |
| Prepend AS twice to specific participant | 2:peer_as | 64234:102:peer_as |
| Prepend AS three times to specific participant | 3:peer_as | 64234:103:peer_as |
| Don’t advertise to specific participant | 0:peer_as | 64234:0:peer_as |
| Do not advertise to any participants | 64234:65535 | 64234:0:0 |
| Announce to specific participant | 64234:peer_as | 64234:1:peer_as |
| Prepend AS once to all participants | 64234:65501 | 64234:2:1 |
| Prepend AS twice to all participants | 64234:65502 | 64234:2:2 |
| Prepend AS three times to all participants | 64234:65503 | 64234:2:3 |
Route Validation
Prefixes are validated in the following sequence:
- RPKI ROA – Prefixes with a valid ROA are accepted. Prefixes with an invalid ROA are discarded. Prefixes without a ROA are passed to the next step.
- Route Object – Prefixes with a corresponding route object in a public Internet Routing Registry (IRR) are accepted. VANIX uses the AS Set specified in the PeeringDB “IRR Record” field.
- Origin AS – Prefixes that match a WHOIS record and the Origin AS AS number, are accepted.
- Everything else is discarded.
You should register any prefixes that you send to the route servers in a public Internet Routing Registry (IRR) database. For most VANIX participants, this means using the ARIN IRR or RADB. Even if VANIX accepts your prefixes based on a RPKI or OriginAS match, validation of prefixes by IRR is widespread on the Internet.
VANIX supports RADB, BELL, CANARIE, ARIN, ALTDB, NTTCOM, LEVEL3, ROGERS, SAVVIS, and RIPE IRRs.
IRR Explorer is a useful tool to check to how your current prefixes in BGP compare to route objects from your AS Set.
Bidirectional Forwarding Detection (BFD) Support
The Need for BFD
On an Internet Exchange (IX), where routers are not directly connected, BGP is relied upon to detect peering failures. It accomplishes this by tearing down a session after it stops receiving updates or keepalives from a peer for the duration of the configured BGP hold time. BGP typically uses a high hold time—often 90 seconds or more. This long duration is intentional; on busy routers handling a full BGP tables, the processing of many BGP updates can delay the sending of keepalives. Traffic will be dropped until the BGP session fails and finds the next best path to the destination. BGP runs on the control plane, which is a premium router resource that all protocols are competing for. Simply reducing the BGP hold timer can lead to instability and false positives, causing sessions to flap unnecessarily.
What is BFD?
BFD is a protocol designed specifically to detect forwarding path failures between routers. It runs as a separate lightweight process, allowing its keepalive timers to be set much more aggressively—typically within a few seconds, and tuneable for sub-second failure detection. Many routers can offload BFD processing to the routing hardware, separating it from the control plane load and increasing its reliability for very fast detection.
By using BFD, your router can detect a failed route server session almost instantly, preventing your users from suffering a multi-minute outage while BGP waits for its hold timer to expire. BFD use is encouraged when BGP peering with other networks over indirect links, that is the case with VANIX.
VANIX’s BFD Configuration
At VANIX, we have enabled BFD on our route servers (206.41.104.253 and 206.41.104.254) for all peers to give participants an easy way to reduce outage times.
BFD is enabled in passive mode on the route servers for all participants. To take advantage of this feature, you simply need to configure BFD on your router’s BGP sessions with the route servers, and you’re all set.
These BFD sessions are only applicable to your peering with the VANIX route servers. If you have direct peering sessions with other networks, you will need to coordinate with them directly to enable BFD.