Route Server

Kay edited this page Apr 11, 2018 · 15 revisions

DEPRECATED IN V4: please use the new framework for this - see here

Normally on a peering exchange, all connected parties will establish bilateral peering relationships with each other member port connected to the exchange. As the number of connected parties increases, it becomes increasingly more difficult to manage peering relationships with members of the exchange.

However, by using a route servers for all peering relationships, the number of BGP sessions per router stays at two: one for each route server (assuming a resilient set up). Clearly this is a more sustainable way of maintaining IXP peering relationships with a large number of participants.

At INEX we have two route servers (diversely located) with one running the Euro-IX Quagga branch and the other running Bird.

This page will explain how to automatically generate secure route server configurations.

The route server testing page also shows some practical examples.

The features of the route server configurations that we generate include:

  • full prefix filtering based on IRRDB entries (can be disabled on a per member basis if required) [see IRRDB filtering];
  • full origin ASN filtering based on IRRDB entries (can be disabled on a per member basis if required) [see IRRDB filtering];
  • in all cases, prefix filtering for IPv4 and v6 based on the IANA special purpose registries;
  • ensuring next hop is the neighbor address to ensure no next hop hijacking;
  • max prefix limits;
  • multiple VLAN interfaces for a single member also supported.

Configuration Options

Typically, you would run a Quagga / Bird instance for each peering LAN and protocol (so, if you have two peering LANs with IPv4 and IPv6 both enabled, you would have four Quagga / Bird instances).

Each instance takes its configuration from a Smarty configuration file. We have included a sample file which can be seen here.

This is fully commented and, as you can see, takes some key information such as the route server address, the route server ASN (which should be different to that of your IXPs own ASN) and other relevant parameters.

Writing / Altering Configuration Templates

Remember - use skinning to make changes to the bundled examples or add your own. For example, if you set target above to bird and had you skin configured as myixpskin, then the configuration would be generated from application/views/_skins/myixpskin/router-cli/server/bird/....

Contribute back - if you write a config generator for another router, please open a pull request and contribute it back to the project.

The follow variables are available for each member's IPv4 / IPv6 VLAN interface in the $int array:

 * `cid` - customer ID;
 * `cname` - full customer name;
 * `cshortname` - customer shortname;
 * `autsys` - customer AS number;
 * `peeringmacro` - customer's appropriate peering macro (if V6 interface then the V6 macro if defined, else the v4 macro. If no macro, it will be `AS65500` where 65500 is their AS number);
 * `vliid` - VLAN interface ID
 * `fvliid` - formatted VLAN interface ID using `sprintf( "%04d" )`;
 * `address` - IPv4/6 address
 * `bgpmd5secret` - their configured BGP MD5 secret (or false if not defined)
 * `maxprefixes` - the configured maximum prefix setting;
 * `location_name` - full location name;
 * `location_shortname` - location shortname;
 * `location_tag` - location tag.

As mentioned above, there are complete examples for Bird and Quagga provided in application/views/router-cli/server/{quagga,bird} which should give you all the details you need.

The three key files that are required in each target directory are:

  • header.cfg - optional - if present, will be printed once at the start. Can be used to set standard configuration options such as logging, non-customer specific access lists, vty configs, etc. Also, for Quagga, which we expect to be piped to an active Quagga instance in the demo files, it sends the conf t command.
  • neighbor.cfg - required - parsed and printed for each member. This is the heart of you per-member configuration.
  • footer.cfg - optional - if present, will be printed once at the end. For Quagga, which we expect to be piped to an active Quagga instance in the demo files, it sends the exit; wr mem commands.

Strict Prefix Filtering

At INEX, we use strict inbound prefix filtering to ensure no route server client can insert bad or dangerous route prefixes. The prefixes are taken from the database via [the IRRDB prefix mechanism](IRRDB Prefixes). Ensure either set this up, use a different template or uncheck the Apply IRRDB Filtering field in every VLAN interface.

Generating the Configuration via the CLI

Once you have set up a configuration file, all you need is the database ID of the VLAN you wish to generate the configuration for. You'll get this by hovering over any of the actions in the VLAN section of IXP Manager and examining the URL.

Then, by executing the following, all active VLAN interfaces marked as Route Server Client will have a BGP configuration generated for them via:

${APPLICATION_PATH}/bin/ixptool.php -a router-cli.gen-server-conf -p vlanid=X,target=bird,proto=6 --config=/full/path/to/config.conf

The available additional options are:

  • vlan=X - the VLAN database ID to generate the configuration for;
  • proto=[4|6] - generate configuration for the given protocol;
  • target=bird - the target directory (in router-cli/server/) from which to load theneighbor.cfg` template file.

You can also generate the snippet for a single member (excluding the header and footer templates) by specifying the parameter:

  • cust=$shortname - shortname of the customer to generate the snippet for.
  • wrappers=0|1 - (default 1) If 0, do not include the header and footer files in the output.
  • testmode=0|1 - (default 0) If 1, tweak the configuration for test mode.

Generating the Configuration via the API

You can generate a route server configuration via the API by using a URL such as:             

An example of the scripts and crontab that we at INEX use to rebuild our Bird route servers regularly can be found at:

Syncing the Configuration with the Router

Note that the provided Quagga example does not generate a complete router configuration - rather it just generates the necessary BGP clauses (and a few other bits). This is because, unfortunately, Quagga does not have a reload method for it's BGP daemon - updating a complete configuration would require a daemon restart which is unacceptable.

Instead, we start with a base Quagga configuration and then use RANCID to push the generated changes to it.

For example, if /tmp/rs-vlanX-ipvY.conf is the generated configuration, we push that via:

/path/to/clogin -x /tmp/rs-vlanX-ipvY.conf 

The other daemon we have bundled configurations for, Bird, does have a reload function and, for this, we generate a complete configuration.

Please note - due to the way these changes are pushed to Quagga, you will need to manually remove sessions for departed members until we develop a way of automating that.

You can’t perform that action at this time.
You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session.
Press h to open a hovercard with more details.