Static Routes

Understanding Static Routes

You can use static routes when a network doesn't require the complexity of a dynamic routing protocol. Routes that are permanent fixtures in routing and forwarding tables are often configured as static routes. The internal traffic from stub networks benefits from static routes.

The route consists of a destination prefix and a next-hop forwarding address. The static route is activated in the routing table and inserted into the forwarding table when the next-hop address is reachable. Traffic that matches the static route is forwarded to the specified next-hop address.

Static Routes in CN2

CN2 implements static routes through the following two custom resources (CRs):

• RouteTable: Contains a user-defined next hop destination (nextHop), along with a destination prefix to identify next hop traffic. The nextHop IP address must be an IP address of another VMI object. A prefix defines the destination network which acts as the next hop for matching traffic. A RouteTable lets you define a static route. You can associate a RouteTable with a virtual network (VN). The following is an example of a RouteTable CR:

  Note that the field nextHopType must have the value ip-address. Any other value results in a user input error. The communityAttributes field enables you to control route learning via BGP.

• InterfaceRouteTable: The InterfaceRouteTable configures static routing for a virtual machine interface (VMI). An InterfaceRouteTable contains the destination prefix without the need for a next hop entry. As with a RouteTable, the prefix defines the destination network, or next hop. Unlike a RouteTable, you do not need to define a nextHop IP address because when you associate an InterfaceRouteTable with a VMI, the associated VMI acts as the next hop for this prefix.

  The following is an example of an InterfaceRouteTable CR:

  Note that the field nextHopType must have the value ip-address. Any other value results in a user input error.

These CRs are scoped to their respective namespaces and enable you to configure required attributes for static routes.

Configure Static Routes for a Virtual Network

Configure the RouteTable CR to apply static routes to a VN. A VN references a RouteTable in it's spec. As a result, the RouteTable is associated with that VN and the static route is configured. The following is a VN object with an associated RouteTable:

Configure Static Routes for a VMI

Configure an InterfaceRouteTable to apply static routes to a VMI. A VMI references an InterfaceRouteTable in it's InterfaceRouteTableReference section. The following is a VMI object with a reference to an InterfaceRouteTable:

Configure Static Routes on Pod Interfaces

You can use the annotation section of a pod's manifest to configure static routes for a pod's default or secondary interface. The pod reconciler processes the annotation section to create a VMI object with an associated InterfaceRouteTable. The reconciler looks for the string key: "core.juniper.net/interface-route-table" in the annotation section. The pod's VMI uses that string as a metadata label to associate with an InterfaceRouteTable.

The following is an example of a pod manifest with an InterfaceRouteTable defined for the default interface:

The following is an example of a pod manifest with an InterfaceRouteTable defined for the secondary interface:Note that the name for the primary interface InterfaceRouteTable is vmi-rt and that the name for the secondary interface is vn-route. Defining two InterfaceRouteTables with different names in the same namespace automatically creates an InterfaceRouteTable for the primary and secondary interface of that pod.

Configure Static Routes for a Virtual Network with a NAD

You can also specify static route properties in a network attachment definition (NAD) object. After the NAD is reconciled or applied, a RouteTable is created and the resulting VN object references that RouteTable. The following is an example of a NAD with static route information defined:

Multiple Static Routes on Pod Interfaces

Using InterfaceRouteTable, you can associate multiple static routes to a single pod interface (VMI). This means that that VMI object has multiple default next hop destinations, depending on the IP prefix. You can specify multiple InterfaceRouteTable references using cluster service version (CSV) syntax or JSON syntax annotations.

Note:

You must reference an InterfaceRouteTable in a "namespace/name" format. In the following example, static-route is the namespace and to-right and to-zone-1 are the InterfaceRouteTable objects, or next hop destination for the left-vn VMI.

The following example is a Deployment with multiple InterfaceRouteTable references:

The following example is a pod manifest with multiple InterfaceRouteTable references using JSON syntax:

Note:

You must use backward slashes in JSON syntax. Backward slashes are required to encode a JSON string inside another JSON string.

Troubleshooting RouteTable and InterfaceRouteTable

The following sections contain useful commands when troubleshooting various RouteTable and InterfaceRouteTable issues.

Config Plane Verification

• Verify the state of the RouteTable and InterfaceRouteTable objects.

  • Check the status of the reconciler for the InterfaceRouteTable object.

  • Check the status of the reconciler for the RouteTable object.

• Verify the RouteTable reference in the associated VN. Verify the InterfaceRouteTable reference in the associated VMI.

  • Check the status of the reconciler for the VMI. You should see the InterfaceRouteTable in the VMI with an associated universally unique identifier (UUID) the Contrail FQ (meta info such as apiversion, kind, namespace, name) name.

Dataplane Verification

• In the introspect, verify that the VRF of the VN shows a row with a matching static route prefix specified in the RT using the following steps:

  • Verify that the VRF is associated with the VN.

    https://%3Cvroute_ip%3E:8085/Snh_VrfListReq

  • Navigate to the ucindex column in the VRF unicast RouteTable.

  • Verify that the table contains a row with the correct static route prefix.

• In the introspect, verify that the next hop properties of the VN are valid. In the introspect, the next hop column for the prefix should contain the following:

  • The next hop interface name must be a valid tap interface.

  • The label must be a positive integer.

  • The resolved value must be true.

  • The route-type: value must be InterfaceStaticRoute.