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 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 network destination prefix, along with an associated next hop (nextHop). The nextHop IP address must be an IP address of a VMI object. A prefix defines the destination network that is reachable via the next hop. A RouteTable lets you define a static route and next-hop pairing, which you can then associate with a RouteTable and a virtual network (VN). The following is an example of a RouteTable CR. Note that the namespace field is not required in this instance.

  Note that the field nextHopType must have the value ip-address. Any other value results in a user input error. The communityAttributes field allows you to set BGP communities on the route, which are advertised via BGP.

• InterfaceRouteTable: The InterfaceRouteTable configures static routing with the next hop of a virtual machine interface (VMI). An InterfaceRouteTable contains the destination prefix without the need for a statically-configured next hop entry. As with a RouteTable, the prefix defines the destination network. 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 namespace field is not required in this instance.

  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 virtual network (VN). A VN references a RouteTable in it's spec. As a result, when the RouteTable is associated with that VN, the static route is applied. The following is a VN object with an associated RouteTable:

Configure Static Routes for a VMI

Configure the interface-route-table annotation on a VMI in order to apply an InterfaceRouteTable to a VMI.

The following is an example kubectl describe vmi output:

Note the Interface Route Table References section. This section shows the association between the listed InterfaceRouteTables and VMIs.

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:

Note the securityContext fields. These fields are necessary because the pod must have permission to change it's routing table in order to utilize the configured route.

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

Dataplane Verification

• In the vRouter 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:

  • Access vRouter introspect at https://<vrouter_ip>:8085/Snh_VrfListReq

  • Verify that the VRF is associated with the VN.

  • 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 accurate and as desired. 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.

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.