Route Server Testing

Barry O'Donovan edited this page Oct 3, 2013 · 7 revisions

IXP Manager includes the ability to create example working member-side Quagga configurations allowing IXPs to set up near-equivalent to live environments for testing route server configurations.

There are also scripts for starting multiple Quagga instances and adding IP addresses to your local loopback interface for this purpose.

@barryo: A base level of knowledge and experience of route servers and Linux networking commands is expected in the below. Please feel free to contribute improved documentation.

What follows is a worked example of creating a test route server environment with the following assumptions:

  • using Ubuntu 13.04 (any recent version of Debian / Ubuntu Linux should be fine);
  • a working IXP Manager installation (of at least v3.5.3 at time of writing);
  • stock Quagga from Ubuntu repositories;
  • you have some knowledge of route servers, IXP Manager and Linux networking;
  • working via the bash shell (others may also be fine, but this example was worked via bash).

This worked example should be easy to extend to FreeBSD and / or Bird. I'll also document how this can be done as we go.

Environment Setup

From the [route server](Route Server) documentation page you'll know that we created dedicated route servers per peering (V)LAN and protocol. We'll define some shell variables here so that you can easily alter these and then copy and paste the commands below without altering them.

# The protocol to create a route server for; either 4 or 6:
proto=6
# The VLAN ID - this is not the VLAN tag but the database ID of the VLAN:
vlanid=2
# The route server implementation to use. Right now, only 'quagga' is defined
# for the member side router configurations. Later we may add 'bird' also.
target="quagga"
# The operating system on which we are running. Right now, only 'linux' is defined.
# Later we may add 'freebsd' also.
os="linux"
# The root directory of your IXP Manager installation
ixpdir="/path/to/ixpmanager"
# We also need a directory to store the client configurations and other files
workdir="/var/tmp/rstest"

Now create and setup the working directory:

mkdir -p $workdir
cd $workdir
mkdir -p ${workdir}/quagga
mkdir -p ${workdir}/confs
chown -R quagga:quaggavty ${workdir}/quagga
chmod -R ug+rwX ${workdir}/quagga/

While you should use your real route server IP address and your real route server ASN in the test platform, we will define two examples here using the example / private prefixes and ASNs. For an IPv4 test environment with subnet 192.0.2.0/25:

rstest_num=1
rstest_ip="192.0.2.8"
rstest_id="192.0.2.8"
rstest_as="65500"
rstest_masklen=25

And for a IPv6 environment with subnet 2001:db8:1:2::/64:

rstest_num=1
rstest_ip="2001:db8:1:2::8"
rstest_id="192.0.2.8"
rstest_as="65500"
rstest_masklen=25

Most IXPs run multiple route servers. The rstest_num above can be incremented for each route server you want to spin up.

Generate Your Test Route Server Configuration

It is assumed that you've read the section on [route servers](Route Server) before proceeding here.

We need to create a configuration for the route server itself. Some details of this are slightly different to the production configuration. For example, for Quagga, we stream the configuration via RANCID to the Quagga VTY and, thus, need to issue commands such as configure terminal. These are not required (and would in fact throw an error) in the test environment so we pass a special testmode=1 parameter below. You can see how this is used in the templates.

We also need a configuration file for the route server. A template version can be seen here which includes all possible variables. Here is an example we use:

cat >$workdir/rs${rstest_num}-vlanid${vlanid}-ipv${proto}.conf <<END_CONF
rsconfHostname       = "rs${rstest_num}-test-vlanid${vlanid}-ipv${proto}"
rsconfPassword       = "supersecret"
rsconfEnablePassword = "supersecret"
rsconfLogfile        = "${workdir}/quagga/bgpd-rs-vlanid${vlanid}-ipv${proto}.log"

rsconfASN            = "${rstest_as}"
rsconfRouterID       = "${rstest_id}"

rsconfListenAddr     = "${rstest_ip}"
END_CONF

We can now generate the route server configuration via:

$ixpdir/bin/ixptool.php -a router-cli.gen-server-conf                      \
    -p vlanid=${vlanid},target=${target},proto=${proto},testmode=1         \
    --config=$workdir/rs${rstest_num}-vlanid${vlanid}-ipv${proto}.conf       \
        >$workdir/confs/rs${rstest_num}-vlanid${vlanid}-ipv${proto}.conf

And we can start it up via:

/sbin/ip addr add ${rstest_ip}/${rstest_masklen} dev lo

/usr/lib/quagga/bgpd --daemon -u quagga -g quaggavty                       \
    -f $workdir/confs/rs${rstest_num}-vlanid${vlanid}-ipv${proto}.conf     \
    -i $workdir/quagga/rs${rstest_num}-vlanid${vlanid}-ipv${proto}.pid     \
    -z $workdir/quagga/rs${rstest_num}-vlanid${vlanid}-ipv${proto}.sock    \
    -l ${rstest_ip} -A ${rstest_ip} -n

You can log into this now via:

telnet ${rstest_ip} 2605

using the login and enable password of supersecret as defined in the config file above.

Generate Configurations for Member Clients

Now we need to create router configurations for the members of the IXP to connect to the route server. It is important that IRRDB prefixes are available so that the appropriate network statements can be configured for these member configurations.

A configuration file is also required for the client side configurations. Here is an example:

cat >$workdir/rs${rstest_num}-vlanid${vlanid}-ipv${proto}-clients.conf <<END_CONF
rsclientconfPassword       = "qwerty"
rsclientconfEnablePassword = "qwerty"

rsconfASN            = "${rstest_as}"

rsconfListenAddr1     = "${rstest_ip}"
# rsconfListenAddr2     = "192.0.2.9"
# ...
# rsconfListenAddr5     = "192.0.2.12"
END_CONF

This configuration is used to configure the member test routers which will connect to your test route server. You can specify up to five route server addresses (as shown above) and, for each one you specify, a BGP neighbor configuration will be created in the client configuration.

You can generate all the configurations for your members via:

${ixpdir}/bin/ixptool.php -a router-cli.gen-server-test-confs                    \
    -p vlanid=${vlanid},target=${target},proto=${proto},dir=${workdir}           \
    --config=${workdir}/rs${rstest_num}-vlanid${vlanid}-ipv${proto}-clients.conf

You can also generate the configuration for a single member by specifying the parameter cust=$shortname.

Configurations can be found in the ${workdir}/confs directory named as ${shortname}-vlanid${vlanid}-proto${proto}.conf.

As mentioned above, only Quagga is currently supported for client side configurations. To add support for Bird, just copy this file, name it bird.cfg in the same directory and set target="bird". And open a pull request!

Starting Up Member Clients

There is also a mechanism for automatically generating all the appropriate commands to start up the client routers. You can see those commands by executing:

${ixpdir}/bin/ixptool.php -a router-cli.gen-server-test-setup                    \
    -p vlanid=${vlanid},target=${target},os=${os},proto=${proto},dir=${workdir}  \
    --config=${workdir}/rs${rstest_num}-vlanid${vlanid}-ipv${proto}-clients.conf

You can pick off various individual clients to start, pipe it to a script or pipe it directly to bash:

${ixpdir}/bin/ixptool.php -a router-cli.gen-server-test-setup                    \
    -p vlanid=${vlanid},target=${target},os=${os},proto=${proto},dir=${workdir}  \
    --config=${workdir}/rs${rstest_num}-vlanid${vlanid}-ipv${proto}-clients.conf | bash

A variation of this command will create the necessary commands to stop the clients and remove the added IP addresses:

${ixpdir}/bin/ixptool.php -a router-cli.gen-server-test-setup                    \
    -p vlanid=${vlanid},target=${target},os=${os},proto=${proto},down=1,dir=${workdir}  \
    --config=${workdir}/rs${rstest_num}-vlanid${vlanid}-ipv${proto}-clients.conf

Note that you need to tear down the route server itself (and it's IP address yourself).

As mentioned above, only Quagga and Linux is currently supported for generating setup / teardown commands. To add support for, say, Bird and FreeBSD, just copy these files:

and rename them as bird-freebsd-setup-up.cfg and bird-freebsd-setup-down.cfg respectivily, and set target="bird" and os="freebsd". And open a pull request!

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.