Static routes¶

Standard routing¶

Once the IP addresses have been configured, communication is possible between the nodes (hosts or routers) directly connected to the same IP sub-network. It is a one hop communication. To communicate with other nodes that are connected to a different sub-network, a dedicated node, the router, requires routes. For example, you can define static IP routes to link sub-networks.

Static routes do not scale and are not error-free. They should be used only when dynamic routing protocols cannot be deployed, or in case of very simple topologies.

You can implement static routing by directly manipulating the equipment routing table. It may be used with any dynamic routing protocol. When both static and dynamic routes are set, the static ones are preferred because their administrative distance is 1.

To add a static route, do:

vsr running config# vrf main
vsr running vrf main# routing static
vsr running static# ipv4-route 10.200.0.0/24 next-hop 10.125.0.2
vsr running static# commit
Configuration applied.

To display the static routes state:

vsr running config# show state vrf main routing static
static
    ipv4-route 10.200.0.0/24
        next-hop 10.125.0.2
        ..
    ..

To check the route is present in the system Routing Information Base:

vsr running config# show state vrf main routing rib
rib
    ipv4-route 10.200.0.0/24
        next-hop 10.125.0.2
            selected true
            distance 1
            protocol static
            uptime 00:11:55
            interface ntfp2
            active true
            fib true
            ..
            [...]
        ..
    ..

To show the state in a human readable way:

vsr running config# show ipv4-routes vrf main
 Codes: K - kernel route, C - connected, S - static, R - RIP,
        O - OSPF, I - IS-IS, B - BGP, E - EIGRP, N - NHRP,
        T - Table, v - VNC, V - VNC-Direct, A - Babel, D - SHARP,
        F - PBR, f - OpenFabric,
        > - selected route, * - FIB route, q - queued route, r - rejected route

K>* 0.0.0.0/0 [0/0] via 10.0.2.2, mgmt0, 00:02:00
C>* 10.0.2.0/24 is directly connected, mgmt0, 00:02:00
C>* 10.100.0.0/24 is directly connected, ntfp1, 00:02:00
C>* 10.125.0.0/24 is directly connected, ntfp2, 00:02:00
C>* 10.175.0.0/24 is directly connected, ntfp3, 00:02:00
S>* 10.200.0.0/24 [1/0] via 10.125.0.2, ntfp2, 00:02:00

The same configuration can be made using this NETCONF XML configuration:

vsr running config# show config xml absolute vrf main routing static
<config xmlns="urn:6wind:vrouter">
  <vrf>
    <name>main</name>
    <routing xmlns="urn:6wind:vrouter/routing">
      <static>
        <ipv4-route>
          <destination>10.200.0.0/24</destination>
          <next-hop>
            <next-hop>10.125.0.2</next-hop>
          </next-hop>
        </ipv4-route>
      </static>
    </routing>
  </vrf>
</config>

Policy-Based Routing¶

Virtual Service Router supports multiple routing tables. By default, routes are set in the main table as explained above. For PBR, it is possible to specify the table to use using an identifier. See the Policy-Based Routing section for details.

To add a static route in a specific table, do:

vsr running static# table 100 ipv4-route 10.200.0.0/24 next-hop 10.175.0.2
vsr running static# commit
Configuration applied.

To show the state for a specific table:

vsr running config# show config xml absolute vrf main routing static
vsr running config# show ipv4-routes vrf main table 100
 Codes: K - kernel route, C - connected, S - static, R - RIP,
        O - OSPF, I - IS-IS, B - BGP, E - EIGRP, N - NHRP,
        T - Table, v - VNC, V - VNC-Direct, A - Babel, D - SHARP,
        F - PBR, f - OpenFabric,
        > - selected route, * - FIB route, q - queued route, r - rejected route

S>* 10.200.0.0/24 [1/0] via 10.175.0.2, ntfp3, 00:02:00

The matching NETCONF XML is as follows:

vsr running config# show config xml absolute vrf main routing static
<config xmlns="urn:6wind:vrouter">
  <vrf>
    <name>main</name>
    <routing xmlns="urn:6wind:vrouter/routing">
      <static>
        <table>
            <table-id>100</table-id>
            <ipv4-route>
              <destination>10.200.0.0/24</destination>
              <next-hop>
                <next-hop>10.175.0.2</next-hop>
              </next-hop>
            </ipv4-route>
        </table>
      </static>
    </routing>
  </vrf>
</config>

BFD With Static Routes¶

It is possible to enable a failover mechanism that relies on nexthops configured in static routes. By monitoring with BFD that nexthop, the route will be either validated or invalidated, according to BFD status. This mechanism enforces the reachability. To get more information on BFD, please see BFD.

Below example illustrates how a BFD peer session context is created, associated to next-hop 10.125.0.2.

vrf customer1
   routing static ipv4-route 10.200.0.0/24 next-hop 10.125.0.2 track bfd

Then you can continue the configuration as usual. For timer settings, the default emission and reception settings are set to 300000 microseconds, which may not be what is wished. In that case, it is possible to override default timers, by configuring general timer settings. More information is given in Configuring general BFD settings.

BFD Configuration And Monitoring In Static Routing Using Trackers¶

It’s also possible to configure a BFD or ICMP tracker manually. This enables using the same tracker in different services. An example is available in the BGP configuration and monitoring using trackers documentation.

More information about tracker can be found in Tracker guide.