User Tools

Site Tools


latex2wiki:user_manual:configuration_overview

Configuration Overview

Introduction

A XORP router must be configured to perform the desired operations. The configuration information can be provided in one of the two ways:

  • Use a configuration file when the 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).

  • Use the 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.

Network Interfaces

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

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).

Forwarding Engine Abstraction

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).

Protocols

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.

Static Routes

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
    }
    */
  }
}

Routing Information Protocol

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
        }
      }
    }
  }
}

Open Shortest Path First

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 {
          }
        }
      }
    }
  }
}

Border Gateway Protocol

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 */
    }
  }
}

Multicast Forwarding Engine Abstraction

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.

Internet Group Management Protocol/Multicast Listener Discovery

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.

Protocol Independent Multicast - Sparse Mode

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.

FIB2MRIB

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
  }
}
1) Currently (July 2008) XORP has only preliminary support to configure firewall rules.
2) See file ERRATA from the XORP distribution for additional information how to compile XORP on Linux with firewall support enabled.
3) Note that prior to XORP Release-1.1, the enable-unicast-forwarding4 and enable-unicast-forwarding6 flags were used instead to enable or disable the IPv4 and IPv6 forwarding.
4) Note that prior to XORP Release-1.1, the enable flag was used instead of disable to enable or disable each part of the configuration.
5) Starting with XORP Release-1.2 policy is used to export routes into RIP with the export statement. Prior to XORP Release 1.2 the export statement was used with a different syntax.
6) , 7) Note that prior to XORP Release-1.1, the enable flag was used instead of disable to enable or disable each part of the configuration.
8) Note that the version statement appeared after XORP Release-1.1.
9) , 15) Note that the enable-ip-router-alert-option-check statement appeared after XORP Release-1.1.
10) Note that the query-interval statement appeared after XORP Release-1.1.
11) Note that the query-last-member-interval statement appeared after XORP Release-1.1.
12) Note that the query-response-interval statement appeared after XORP Release-1.1.
13) Note that the robust-count statement appeared after XORP Release-1.1.
14) , 21) Note that prior to XORP Release-1.1, the enable flag was used instead of disable to enable or disable each part of the configuration.
16) Note that the hello-period statement appeared after XORP Release-1.1.
17) Note that the hello-triggered-delay statement appeared after XORP Release-1.1.
18) Note that the cand-bsr-by-vif-addr statement appeared after XORP Release-1.1.
19) Note that the cand-rp-by-vif-addr statement appeared after XORP Release-1.1.
20) Note that prior to XORP Release-1.3, the interval-sec statement was used instead of interval.
latex2wiki/user_manual/configuration_overview.txt · Last modified: 2011/03/11 21:42 by Pierre Lepropre