A XORP router must be configured to perform the desired operations. The configuration information can be provided in one of the two ways:
xorp_rtrmgr is started. By default, the xorp_rtrmgr will load the configuration from file “config.boot” in the XORP installation directory. This file can be specified by the “-b <filename>” command line option: xorp_rtrmgr -b my_config.boot
See “rtrmgr/config/*.boot” for a set of sample configuration files (note that those files MUST be modified before using them).
xorpsh command line interface after the xorp_rtrmgr is started. It should be noted that command line completion in the xorpsh does greatly simplify configuration.
A mixture of both methods is permissible. For example, a configuration file can also be loaded from within the xorpsh.
At very minimum, a router’s interfaces must be configured (see Network Interfaces). Typically, the FEA needs to be configured (e.g., to enable unicast forwarding); the FEA configuration is described in Forwarding Engine Abstraction. All protocol configuration is described in Protocols.
A XORP router will only use interfaces that it has been explicitly configured to use. Even for protocols such as BGP that are agnostic to interfaces, if the next-hop router for a routing entry is not through a configured interface the route will not be installed. For protocols that are explicitly aware of interfaces only configured interfaces will be used. Every physical network device in the system is considered to be an “interface”. Every interface can contain a number of virtual interfaces (“vif”s). In the majority of cases the interface name and vif name will be identical and will map to the name given to the interface by the operating system. A virtual interface is configured with the address or addresses that should be used. At each level in the configuration hierarchy (interface, vif and address) it is necessary to enable this part of the configuration.
interfaces {
restore-original-config-on-shutdown: false
interface dc0 {
description: "data interface"
disable: false
/* default-system-config */
vif dc0 {
disable: false
address 10.10.10.10 {
prefix-length: 24
broadcast: 10.10.10.255
disable: false
}
/*
address 2001:DB8:10:10:10:10:10:10 {
prefix-length: 64
disable: false
}
*/
}
}
}
We recommend that you select the interfaces that you want to use on your system and configure them as above. If you are configuring an interface that is currently being used by the the system make sure that there is no mismatch in the address, prefix-length and broadcast arguments. If the default-system-config statement is used, it instructs the FEA that the interface should be configured by using the existing interface information from the underlying system. In that case, the vif and address sections must not be configured.
Firewall rules are configured by using numbered entries1):
firewall {
rule4 100 {
action: "drop"
protocol: 6 /* TCP */
source {
interface: "fxp0"
vif: "fxp0"
network: 0.0.0.0/0
port-begin: 0
port-end: 65535
}
destination {
network: 10.10.0.0/24
port-begin: 0
port-end: 1024
}
}
}
Rules with smaller numbers are applied earlier. The rules allow matching based on protocol number, incoming interface and vif, source and destination network prefixes, and source and destination port ranges (for TCP and UDP only). The action can be one of the following:
| Action | Description |
|---|---|
| none | No action. Continue the evaluation with the next rule. |
| pass | Pass matching packets. |
| drop | Drop matching packets. |
| reject | Reject matching packets. |
Currently (July 2008), firewall configuration is supported only for *BSD and Linux 2).
It is a requirement to explicitly enable forwarding for each protocol family.
fea {
unicast-forwarding4 {
disable: false
}
/*
unicast-forwarding6 {
disable: false
}
*/
}
If IPv4 forwarding is required you will require the configuration above. If the system supports IPv6 and IPv6 forwarding is required, then the unicast-forwarding6 statement must be used to enable it 3).
A unicast router typically will be configured with one or more of the following protocols: Static Routes, RIP or BGP.
A multicast router must have the MFEA configured. Typically, a multicast router should have IGMP/MLD configured. Currently, PIM-SM is the only multicast routing protocol implemented. If some multicast-specific static routes need to be installed in the MRIB (for computing the reverse-path forwarding information), those can be specified in the Static Routes configuration. If there are no unicast routing protocols configured, the FIB2MRIB module may need to be configured as well.
This is the simplest routing protocol in XORP. It allows the installation of unicast or multicast static routes (either IPv4 or IPv6). Note that in case of multicast the routes are installed only in the user-level Multicast Routing Information Base and are used for multicast-specific reverse-path forwarding information by multicast routing protocols such as PIM-SM.
protocols {
static {
route 10.20.0.0/16 {
nexthop: 10.10.10.20
metric: 1
}
mrib-route 10.20.0.0/16 {
nexthop: 10.10.10.30
metric: 1
}
/*
route 2001:DB8:AAAA:20::/64 {
nexthop: 2001:DB8:10:10:10:10:10:20
metric: 1
}
mrib-route 2001:DB8:AAAA:20::/64 {
nexthop: 2001:DB8:10:10:10:10:10:30
metric: 1
}
*/
}
}
In order to run RIP it is sufficient to specify the set of interfaces, vifs and addresses (interface, vif and address) on which RIP is enabled4).
If you wish to announce routes then it is necessary to the routes that are to be announced. For example,
connected and static5).
policy {
/* Describe connected routes for redistribution */
policy-statement connected {
term export {
from {
protocol: "connected"
}
}
}
}
policy {
/* Describe static routes for redistribution */
policy-statement static {
term export {
from {
protocol: "static"
}
}
}
}
protocols {
rip {
/* Redistribute routes for connected interfaces */
/*
export: "connected"
*/
/* Redistribute static routes */
/*
export: "static"
*/
/* Redistribute connected and static routes */
/*
export: "connected,static"
*/
/* Run on specified network interface addresses */
interface dc0 {
vif dc0 {
address 10.10.10.10 {
disable: false
}
}
}
}
}
In order to run OSPF Version 2 the router-id must be specified, the numerically smallest IP address of
an interface belonging to the router is a good choice.
OSPF splits networks into areas so an area must be configured.
Configure one or more of the routers configured interface/vif/address in this area.
The 4 in ospf4 refers to the IPv4 address family.
protocols {
ospf4 {
router-id: 10.10.10.10
area 0.0.0.0 {
interface dc0 {
vif dc0 {
address 10.10.10.10 {
}
}
}
}
}
}
In order to run BGP the bgp-id (BGP Identifier) and local-as (Autonomous System number) must be
specified.
The peer statement specifies a peering. The argument to the peer statement is the IP address of the peer.
The local-ip is the IP address that TCP should use. The as is the Autonomous System Number of the
peer.
protocols {
bgp {
bgp-id: 10.10.10.10
local-as: 65002
peer 10.30.30.30 {
local-ip: 10.10.10.10
as: 65000
next-hop: 10.10.10.20
/*
local-port: 179
peer-port: 179
*/
/* holdtime: 120 */
/* disable: false */
/* IPv4 unicast is enabled by default */
/* ipv4-unicast: true */
/* Optionally enable other AFI/SAFI combinations */
/* ipv4-multicast: true */
/* ipv6-unicast: true */
/* ipv6-multicast: true */
}
}
}
The MFEA must be configured if the XORP router is to be used for multicast routing. The MFEA for IPv4
and IPv6 are configured separately.
In the configuration we must explicitly configure the entity itself, and each vif. The traceoptions
section is used to explicitly enable log information that can be used for debugging purpose6).
plumbing {
mfea4 {
disable: false
interface dc0 {
vif dc0 {
disable: false
}
}
interface register vif {
vif register vif {
/* Note: this vif should be always enabled */
disable: true
}
}
traceoptions {
flag all {
disable: true
}
}
}
}
plumbing {
mfea6 {
disable: true
interface dc0 {
vif dc0 {
disable: true
}
}
interface register vif {
vif register vif {
/* Note: this vif should be always enabled */
disable: true
}
}
traceoptions {
flag all {
disable: true
}
}
}
}
Note that the interface/vif named register_vif is special. If PIM-SM is configured, then register_vif must be enabled in the MFEA.
IGMP/MLD should be configured if the XORP router is to be used for multicast routing and if we want to track multicast group membership for directly connected subnets. Typically this is the case for a multicast router, therefore it should be enabled. IGMP and MLD are configured separately: IGMP is used for tracking IPv4 multicast members; MLD is used for tracking IPv6 multicast members.
In the configuration we must explicitly configure each entity and each vif. The traceoptions section
is used to explicitly enable log information that can be used for debugging purpose7).
protocols {
igmp {
disable: false
interface dc0 {
vif dc0 {
disable: false
/* version: 2 */
/* enable-ip-router-alert-option-check: false */
/* query-interval: 125 */
/* query-last-member-interval: 1 */
/* query-response-interval: 10 */
/* robust-count: 2 */
}
}
traceoptions {
flag all {
disable: false
}
}
}
}
protocols {
mld {
disable: false
interface dc0 {
vif dc0 {
disable: false
/* version: 1 */
/* enable-ip-router-alert-option-check: false */
/* query-interval: 125 */
/* query-last-member-interval: 1 */
/* query-response-interval: 10 */
/* robust-count: 2 */
}
}
traceoptions {
flag all {
disable: false
}
}
}
}
A number of parameters have default values, therefore they don’t have to be configured (those parameters are commented-out in the above sample configuration).
The version parameter is used to configure the MLD/IGMP protocol version per virtual interface8).
The enable-ip-router-alert-option-check parameter is used to enable the IP Router Alert
option check per virtual interface9).
The query-interval parameter is used to configure (per virtual interface) the interval (in seconds)
between general queries sent by the querier10).
The query-last-member-interval parameter is used to configure (per virtual interface) the maximum response time (in seconds) inserted into group-specific queries sent in response to leave group messages. It is also the interval between group-specific query messages11).
The query-response-interval parameter is used to configure (per virtual interface) the maximum
response time (in seconds) inserted into the periodic general queries12).
The robust-count parameter is used to configure the robustness variable count that allows tuning for
the expected packet loss on a subnet13).
Note that in case of IGMP each enabled interface must have a valid IPv4 address. In case of MLD each enabled interface must have a valid link-local IPv6 address.
PIM-SM should be configured if the XORP router is to be used for multicast routing in PIM-SM domain. PIM-SM for IPv4 and IPv6 are configured separately. At minimum, the entity itself and the virtual interfaces should be enabled, and the mechanism for obtaining the Candidate-RP set (either the Bootstrap mechanism, or a static-RP set)14).
protocols {
pimsm4 {
disable: false
interface dc0 {
vif dc0 {
disable: false
/* enable-ip-router-alert-option-check: false */
/* dr-priority: 1 */
/* hello-period: 30 */
/* hello-triggered-delay: 5 */
/* alternative-subnet 10.40.0.0/16 */
}
}
interface register vif {
vif register vif {
/* Note: this vif should be always enabled */
disable: false
}
}
static-rps {
rp 10.60.0.1 {
group-prefix 224.0.0.0/4 {
/* rp-priority: 192 */
/* hash-mask-len: 30 */
}
}
}
bootstrap {
disable: false
cand-bsr {
scope-zone 224.0.0.0/4 {
/* is-scope-zone: false */
cand-bsr-by-vif-name: "dc0"
/* cand-bsr-by-vif-addr: 10.10.10.10 */
/* bsr-priority: 1 */
/* hash-mask-len: 30 */
}
}
cand-rp {
group-prefix 224.0.0.0/4 {
/* is-scope-zone: false */
cand-rp-by-vif-name: "dc0"
/* cand-rp-by-vif-addr: 10.10.10.10 */
/* rp-priority: 192 */
/* rp-holdtime: 150 */
}
}
}
switch-to-spt-threshold {
/* approx. 1K bytes/s (10Kbps) threshold */
disable: false
interval: 100
bytes: 102400
}
traceoptions {
flag all {
disable: false
}
}
}
}
protocols {
pimsm6 {
disable: false
interface dc0 {
vif dc0 {
disable: false
/* enable-ip-router-alert-option-check: false */
/* dr-priority: 1 */
/* hello-period: 30 */
/* hello-triggered-delay: 5 */
/* alternative-subnet 2001:DB8:40:40::/64 */
}
}
interface register vif {
vif register vif {
/* Note: this vif should be always enabled */
disable: false
}
}
static-rps {
rp 2001:DB8:50:50:50:50:50:50 {
group-prefix ff00::/8 {
/* rp-priority: 192 */
/* hash-mask-len: 126 */
}
}
}
bootstrap {
disable: false
cand-bsr {
scope-zone ff00::/8 {
/* is-scope-zone: false */
cand-bsr-by-vif-name: "dc0"
/* cand-bsr-by-vif-addr: 2001:DB8:10:10:10:10:10:10 */
/* bsr-priority: 1 */
/* hash-mask-len: 126 */
}
}
cand-rp {
group-prefix ff00::/8 {
/* is-scope-zone: false */
cand-rp-by-vif-name: "dc0"
/* cand-rp-by-vif-addr: 2001:DB8:10:10:10:10:10:10 */
/* rp-priority: 192 */
/* rp-holdtime: 150 */
}
}
}
switch-to-spt-threshold {
/* approx. 1K bytes/s (10Kbps) threshold */
disable: false
interval: 100
bytes: 102400
}
traceoptions {
flag all {
disable: false
}
}
}
}
A number of parameters have default values, therefore they don’t have to be configured (those parameters
are commented-out in the above sample configuration).
Note that the interface/vif named register_vif is special. If PIM-SM is configured, then register_vif
must be enabled.
The enable-ip-router-alert-option-check parameter is used to enable the IP Router Alert
option check per virtual interface15).
The dr-priority parameter is used to configure the Designated Router priority per virtual interface (note
that in case of register vif it is not used).
The hello-period parameter is used to configure the PIM Hello messages period (in seconds) per virtual
interface16). It must be an integer between 1 and 18724.
The hello-triggered-delay parameter is used to configure the randomized triggered delay of the
PIM Hello messages (in seconds) per virtual interface17). It must be an integer between 1 and 255.
The alternative-subnet statement is used to associate additional subnets with a network interface.
For example, if you want to make incoming traffic with a non-local source address appear as it is coming
from a local subnet, then alternative-subnet can be used. Typically, this is needed as a workaround solution when we use uni-directional interfaces for receiving traffic (e.g., satellite links). Note: use
alternative-subnet with extreme care, only if you know what you are really doing!
If PIM-SM uses static RPs, those can be configured within the static-rps section. For each RP, an rp section is needed, and each section should contain the multicast prefix address the static RP is configured with. The RP priority can be modified with the rp-priority parameter.
If PIM-SM uses the Bootstrap mechanism to obtain the Candidate-RP set, this can be configured in the bootstrap section. If the XORP router is to be used as a Candidate-BSR, this should be specified in the cand-bsr section. For a router to be a Candidate-BSR it must advertise for each zone (scoped or non-scoped) the associated multicast prefix address. The cand-bsr section should contain scope-zone statements for each multicast prefix address. The vif name with the address that is to be used as the Candidate-BSR is specified by the cand-bsr-by-vif-name statement. The particular vif’s address can be specified by the cand-bsr-by-vif-addr statement. If the cand-bsr-by-vif-addr statement is omitted, a domain-wide address (if exists) that belongs to that interface is chosen by the router itself 18). The Candidate-BSR priority can be modified with the bsr-priority parameter.
If the XORP router is to be a Candidate-RP, this should be specified in the cand-rp section. For a
router to be a Candidate-RP it must advertise for each zone (scoped or non-scoped) the associated multicast prefix address. The cand-rp section should contain group-prefix statements for each multicast prefix address. The vif name with the address that is to be used as the Candidate-RP is specified by the cand-rp-by-vif-name statement. The particular vif’s address can be specified by the
cand-rp-by-vif-addr statement. If the cand-rp-by-vif-addr statement is omitted, a domain-wide address (if exists) that belongs to that interface is chosen by the router itself19). The Candidate-RP
priority can be modified with the rp-priority parameter; the Candidate-RP holdtime can be modified
with the rp-holdtime parameter.
The is-scope-zone parameter is used to specify whether a Candidate-BSR scope-zone or a Candidate-RP group-prefix is scoped. Currently, scoped zones are not well tested, hence it is recommended
scope-zone is always set to false. Note that typically the hash-mask-len should not be modified;
if you don’t know what hash-mask-len is used for, don’t modify it!
The switch-to-spt-threshold section can be used to specify the multicast data bandwidth threshold
used by the last-hop PIM-SM routers and the RPs to initiate shortest-path switch toward the multicast source.
Parameter interval is used to specify the periodic measurement interval20); parameter bytes is used
to specify the threshold in number of bytes within the measurement interval. It is recommended that the
measurement interval is not too small, and should be on the order of tens of seconds.
The traceoptions section is used to explicitly enable log information that can be used for debugging
purpose.
Note that in case of PIM-SM for IPv4 each enabled interface must have a valid IPv4 address. In case of PIM-SM for IPv6 each enabled interface must have a valid link-local and a valid domain-wide IPv6 addresses.
The FIB2MRIB module is used to obtain the Forwarding Information Base information from the underlying system (via the FEA), and to propagate it to the MRIB, so it can be used by multicast routing protocols such as PIM-SM. Typically, it is needed only if the unicast routing protocols (if any) on that router do not inject routes into the MRIB21).
protocols {
fib2mrib {
disable: false
}
}
version statement appeared after XORP Release-1.1.enable-ip-router-alert-option-check statement appeared after XORP Release-1.1.query-interval statement appeared after XORP Release-1.1.query-last-member-interval statement appeared after XORP Release-1.1.query-response-interval statement appeared after XORP Release-1.1.robust-count statement appeared after XORP Release-1.1.enable flag was used instead of disable to enable or disable each part of the configuration.hello-period statement appeared after XORP Release-1.1.hello-triggered-delay statement appeared after XORP Release-1.1.cand-bsr-by-vif-addr statement appeared after XORP Release-1.1.cand-rp-by-vif-addr statement appeared after XORP Release-1.1.