# Routing Currently supported YANG models: | **YANG Model** | **Description** | |:--------------------------|:--------------------------------| | ietf-routing | Base model for all other models | | ietf-ipv4-unicast-routing | Static IPv4 unicast routing | | ietf-ipv6-unicast-routing | Static IPv6 unicast routing | | ietf-ospf | OSPF routing | | ietf-rip | RIP routing | | infix-routing | Infix deviations and extensions | The base model, ietf-routing, is where all the other models hook in. It is used to set configuration and read operational status (RIB tables) in the other models. > [!NOTE] > The standard IETF routing models allows multiple instances, but Infix > currently *only support one instance* per routing protocol! In the > examples presented here, the instance name `default` is used. ## IPv4 Static routes The standard IETF model for static routes reside under the `static` control plane protocol. For our examples we use the instance name `default`, you can use any name. The most common case when using a static IP setup is adding a default route (i.e., the default gateway): 
admin@example:/> configure
admin@example:/config/> edit routing control-plane-protocol static name default ipv4
admin@example:/config/routing/…/ipv4/> set route 0.0.0.0/0 next-hop next-hop-address 192.168.1.1
admin@example:/config/routing/…/ipv4/> leave
admin@example:/>
For a route with destination 192.168.200.0/24 via 192.168.1.1: 
admin@example:/> configure
admin@example:/config/> edit routing control-plane-protocol static name default ipv4
admin@example:/config/routing/…/ipv4/> set route 192.168.200.0/24 next-hop next-hop-address 192.168.1.1
admin@example:/config/routing/…/ipv4/> leave
admin@example:/>
For a "floating" static route with destination 10.0.0.0/16 via a backup router 192.168.1.1, using the highest possible distance: 
admin@example:/> configure
admin@example:/config/> edit routing control-plane-protocol static name default ipv4
admin@example:/config/routing/…/ipv4/> set route 10.0.0.0/16 next-hop next-hop-address 192.168.1.1 route-preference 254
admin@example:/config/routing/…/ipv4/> leave
admin@example:/>
> [!TIP] > Remember to enable [IPv4 forwarding](ip.md#ipv4-forwarding) for the > interfaces you want to route between. ## IPv6 Static routes Default route via an IPv6 gateway: 
admin@example:/> configure
admin@example:/config/> edit routing control-plane-protocol static name default ipv6
admin@example:/config/routing/…/ipv6/> set route ::/0 next-hop next-hop-address 2001:db8:3c4d:1::1
admin@example:/config/routing/…/ipv6/> leave
admin@example:/>
For a route with destination 2001:db8:3c4d:200::/64 via 2001:db8:3c4d:1::1: 
admin@example:/> configure
admin@example:/config/> edit routing control-plane-protocol static name default ipv6
admin@example:/config/routing/…/ipv6/> set route 2001:db8:3c4d:200::/64 next-hop next-hop-address 2001:db8:3c4d:1::1
admin@example:/config/routing/…/ipv6/> leave
admin@example:/>
## OSPFv2 Routing The system supports OSPF dynamic routing for IPv4, i.e., OSPFv2. To enable OSPF and set one active interface in area 0: 
admin@example:/config/> edit routing control-plane-protocol ospfv2 name default ospf
admin@example:/config/routing/…/ospf/> set area 0.0.0.0 interface e0 enabled
admin@example:/config/routing/…/ospf/> leave
admin@example:/>
> [!TIP] > Remember to enable [IPv4 forwarding](ip.md#ipv4-forwarding) for all the > interfaces you want to route between. ### OSPF area types In addition to *regular* OSPF areas, area types *NSSA* and *Stub* are also supported. To configure an NSSA area with summary routes: 
admin@example:/config/> edit routing control-plane-protocol ospfv2 name default ospf
admin@example:/config/routing/…/ospf/> set area 0.0.0.1 area-type nssa-area
admin@example:/config/routing/…/ospf/> set area 0.0.0.1 summary true
admin@example:/config/routing/…/ospf/> leave
admin@example:/>
### Bidirectional Forwarding Detection (BFD) It is possible to enable BFD per OSPF interface to speed up detection of link loss. 
admin@example:/config/> edit routing control-plane-protocol ospfv2 name default ospf
admin@example:/config/routing/…/ospf/> set area 0.0.0.0 interface e0 bfd enabled true
admin@example:/config/routing/…/ospf/> leave
admin@example:/>
### OSPF interface settings We have already seen how to enable OSPF per interface (*enabled true*) and BFD for OSPF per interface (*bfd enabled true*). These and other OSPF interface settings are done in context of an OSFP area, e.g., *area 0.0.0.0*. Available commands can be listed using the `?` mark. 
admin@example:/config/routing/…/> edit ospf area 0.0.0.0
admin@example:/config/routing/…/ospf/area/0.0.0.0/> edit interface e0
admin@example:/config/routing/…/ospf/area/0.0.0.0/interface/e0/> set ?
  bfd                  BFD interface configuration.
  cost                 Interface's cost.
  dead-interval        Interval after which a neighbor is declared down
  enabled              Enables/disables the OSPF protocol on the interface.
  hello-interval       Interval between Hello packets (seconds).  It must
  interface-type       Interface type.
  passive              Enables/disables a passive interface.  A passive
  retransmit-interval  Interval between retransmitting unacknowledged Link
  transmit-delay       Estimated time needed to transmit Link State Update
admin@example:/config/routing/…/ospf/area/0.0.0.0/interface/e0/> set
For example, setting the OSPF *interface type* to *point-to-point* for an Ethernet interface can be done as follows. 
admin@example:/config/routing/…/ospf/area/0.0.0.0/interface/e0/> set interface-type point-to-point
admin@example:/config/routing/…/ospf/area/0.0.0.0/interface/e0/>
### Point-to-Multipoint Point-to-Multipoint (P2MP) is used when multiple OSPF routers share a common network segment but should form individual adjacencies rather than electing a Designated Router (DR). This is common in NBMA-like environments, DMVPN, or hub-and-spoke topologies. Infix supports two P2MP variants via the `interface-type` setting: | **Interface Type** | **Behavior** | |:----------------------|:-----------------------------------------------| | `hybrid` | P2MP with multicast Hellos (broadcast-capable) | | `point-to-multipoint` | P2MP with unicast Hellos (non-broadcast) | #### Hybrid (broadcast-capable P2MP) Use `hybrid` when all neighbors on the segment can receive multicast. Hello packets are sent to the standard OSPF multicast address (224.0.0.5) and neighbors are discovered automatically — no manual neighbor configuration is needed. 
admin@example:/config/> edit routing control-plane-protocol ospfv2 name default ospf
admin@example:/config/routing/…/ospf/> set area 0.0.0.0 interface e0 interface-type hybrid
admin@example:/config/routing/…/ospf/> leave
admin@example:/>
#### Non-broadcast P2MP Use `point-to-multipoint` when the network does not support multicast. Hello packets are sent as unicast directly to each configured neighbor. Since neighbors cannot be discovered automatically, they must be configured explicitly using static neighbors (see below). 
admin@example:/config/> edit routing control-plane-protocol ospfv2 name default ospf
admin@example:/config/routing/…/ospf/> set area 0.0.0.0 interface e0 interface-type point-to-multipoint
admin@example:/config/routing/…/ospf/> leave
admin@example:/>
### Static Neighbors When using non-broadcast interface types (such as `point-to-multipoint`), OSPF cannot discover neighbors via multicast. Static neighbors must be configured so the router knows where to send unicast Hello packets. 
admin@example:/config/> edit routing control-plane-protocol ospfv2 name default ospf
admin@example:/config/routing/…/ospf/> set area 0.0.0.0 interface e0 static-neighbors neighbor 10.0.123.2
admin@example:/config/routing/…/ospf/> set area 0.0.0.0 interface e0 static-neighbors neighbor 10.0.123.3
admin@example:/config/routing/…/ospf/> leave
admin@example:/>
> [!NOTE] > Static neighbors are only needed for non-broadcast interface types. > With `hybrid` (or `broadcast`), neighbors are discovered automatically > via multicast. ### OSPF global settings In addition to *area* and *interface* specific settings, OSPF provides global settings for route redistribution and OSPF router identifier. 
admin@example:/config/> edit routing control-plane-protocol ospfv2 name default ospf
admin@example:/config/routing/…/ospf/> set ?
  area                     List of OSPF areas.
  default-route-advertise  Distribute default route to network
  explicit-router-id       Defined in RFC 2328.  A 32-bit number
  redistribute             Redistribute protocols into OSPF
admin@example:/config/routing/…/ospf/> set
- Explicit router ID: By default the router will pick an IP address from one of its OSPF interfaces as OSPF router ID. An explicit ID is used to get a deterministic behavior, e.g., `set explicit-router-id 1.1.1.1`. - Redistribution: `set redistribute static` and `set redistribute connected` can be used to include static or connected routes into the OSPF routing domain. These routes are redistributed as *external type-2* (E2) routes. - Advertising default route: An OSPF router can be made to distribute a default route into the OSPF domain by command `set default-route-advertise enabled`. This route is distributed as long as the router itself has an *active* default route in its routing table. By adding command `set default-route-advertise always` the router will distribute a default route even when it lacks a default route. The default route will be distributed as an *external type-2* (E2) route. ### Debug OSPFv2 Using NETCONF and the YANG model *ietf-routing* it is possible to read the OSPF routing table, neighbors and more, that may be useful for debugging the OSPFv2 setup. The CLI has various OSPF status commands such as `show ospf neighbor`, `show ospf interface` and `show ospf routes`. 
admin@example:/> show ospf neighbor
Neighbor ID     Pri State           Up Time         Dead Time Address         Interface                        RXmtL RqstL DBsmL
10.1.1.2          1 Full/-          3h46m59s          30.177s 10.1.1.2        e0:10.1.1.1                          0     0     0
10.1.1.3          1 Full/-          3h46m55s          34.665s 10.1.1.3        e1:10.1.1.1                          0     0     0
admin@example:/>
For more detailed troubleshooting, OSPF debug logging can be enabled to capture specific protocol events. Debug messages are written to the routing log file (`/var/log/routing`). > [!CAUTION] > Debug logging significantly increases log output and may impact > performance. Only enable debug categories needed for troubleshooting, > and disable them when done. To enable specific OSPF debug categories: 
admin@example:/> configure
admin@example:/config/> edit routing control-plane-protocol ospfv2 name default ospf debug
admin@example:/config/routing/…/ospf/debug/> set bfd true
admin@example:/config/routing/…/ospf/debug/> set nsm true
admin@example:/config/routing/…/ospf/debug/> leave
admin@example:/>
Available debug categories include: - `bfd`: BFD (Bidirectional Forwarding Detection) events - `packet`: Detailed packet debugging (all OSPF packets) - `ism`: Interface State Machine events - `nsm`: Neighbor State Machine events - `default-information`: Default route origination - `nssa`: Not-So-Stubby Area events All debug options are disabled by default. Refer to the `infix-routing` YANG model for the complete list of available debug options. To view current debug settings: 
admin@example:/> show running-config routing control-plane-protocol
To disable all debug logging, simply delete the debug settings or set all options back to `false`: 
admin@example:/> configure
admin@example:/config/> delete routing control-plane-protocol ospfv2 name default ospf debug
admin@example:/config/> leave
admin@example:/>
## RIP Routing The system supports RIP dynamic routing for IPv4, i.e., RIPv2. To enable RIP and set active interfaces: 
admin@example:/config/> edit routing control-plane-protocol ripv2 name default rip
admin@example:/config/routing/…/rip/> set interfaces interface e0
admin@example:/config/routing/…/rip/> set interfaces interface e1
admin@example:/config/routing/…/rip/> leave
admin@example:/>
> [!TIP] > Remember to enable [IPv4 forwarding](ip.md#ipv4-forwarding) for all the > interfaces you want to route between. ### RIP interface settings By default, interfaces send and receive RIPv2 packets. To control the RIP version per interface: 
admin@example:/config/routing/…/rip/> edit interfaces interface e0
admin@example:/config/routing/…/rip/interfaces/interface/e0/> set send-version 1
admin@example:/config/routing/…/rip/interfaces/interface/e0/> set receive-version 1-2
admin@example:/config/routing/…/rip/interfaces/interface/e0/> leave
admin@example:/>
Valid version values are `1`, `2`, or `1-2` (both versions). To configure a passive interface (advertise network but don't send/receive RIP updates): 
admin@example:/config/routing/…/rip/> edit interfaces interface e0
admin@example:/config/routing/…/rip/interfaces/interface/e0/> set passive
admin@example:/config/routing/…/rip/interfaces/interface/e0/> leave
admin@example:/>
### RIP global settings RIP supports redistribution of connected and static routes: 
admin@example:/config/routing/…/rip/> set redistribute connected
admin@example:/config/routing/…/rip/> set redistribute static
admin@example:/config/routing/…/rip/> leave
admin@example:/>
### Debug RIPv2 The CLI provides various RIP status commands: 
admin@example:/> show ip rip
Default version control: send version 2, receive version 2
  Interface        Send  Recv   Key-chain                    
  e0               2     2
  e1               2     2

Routing for Networks:
  e0
  e1

Routing Information Sources:
  Gateway          BadPackets BadRoutes  Distance Last Update
  10.0.1.2                  0         0       120    00:00:16
Distance: (default is 120)

admin@example:/> show ip rip neighbor
ADDRESS          BAD-PACKETS    BAD-ROUTES                   
10.0.1.2         0              0
admin@example:/>
For more detailed troubleshooting, RIP debug logging can be enabled to capture specific protocol events. Debug messages are written to the routing log file (`/var/log/routing`). > [!CAUTION] > Debug logging significantly increases log output and may impact > performance. Only enable debug categories needed for troubleshooting, > and disable them when done. To enable specific RIP debug categories: 
admin@example:/> configure
admin@example:/config/> edit routing control-plane-protocol ripv2 name default rip debug
admin@example:/config/routing/…/rip/debug/> set events true
admin@example:/config/routing/…/rip/debug/> set packet true
admin@example:/config/routing/…/rip/debug/> leave
admin@example:/>
Available debug categories include: - `events`: RIP events (sending/receiving packets, timers, interface changes) - `packet`: Detailed packet debugging (packet dumps with origin and port) - `kernel`: Kernel routing table updates (route add/delete, interface updates) All debug options are disabled by default. Refer to the `infix-routing` YANG model for the complete list of available debug options. To view current debug settings: 
admin@example:/> show running-config routing control-plane-protocol
To disable all debug logging, simply delete the debug settings or set all options back to `false`: 
admin@example:/> configure
admin@example:/config/> delete routing control-plane-protocol ripv2 name default rip debug
admin@example:/config/> leave
admin@example:/>
## View routing table The routing table can be inspected from the operational datastore, XPath `/routing/ribs`, using sysrepocfg, NETCONF/RESTCONF, or using the CLI. ### IPv4 routing table This CLI example shows the IPv4 routing table with a few connected routes and some routes learned from OSPF. See the next section for an explanation of route preferences (PREF). The `>` at the start of a line marks a selected route (in the IETF YANG model referred to as *active*), if there are more than one route with the same destination the `*` marks the next-hop used and installed in the kernel FIB (the YANG model refers to this as *installed*). 
admin@example:/> show ip route
   DESTINATION            PREF NEXT-HOP         PROTO     UPTIME
>* 0.0.0.0/0             110/2 10.0.23.1        ospfv2   4h2m43s
>* 10.0.0.1/32        110/4000 10.0.13.1        ospfv2   4h2m43s
   10.0.0.3/32           110/0 lo               ospfv2   4h2m57s
>* 10.0.0.3/32             0/0 lo               direct   4h2m58s
   10.0.13.0/30       110/2000 e5               ospfv2   4h2m57s
>* 10.0.13.0/30            0/0 e5               direct   4h2m58s
   10.0.23.0/30          110/1 e6               ospfv2   4h2m57s
>* 10.0.23.0/30            0/0 e6               direct   4h2m58s
   192.168.3.0/24        110/1 e2               ospfv2   4h2m57s
>* 192.168.3.0/24          0/0 e2               direct   4h2m58s
admin@example:/>
### IPv6 routing table This CLI example show the IPv6 routing table. 
admin@example:/> show ipv6 route
   DESTINATION                      PREF NEXT-HOP              PROTO     UPTIME
>* ::/0                              1/0 2001:db8:3c4d:50::1   static   0h1m20s
>* 2001:db8:3c4d:50::/64             0/0 e6                    direct   0h1m20s
>* 2001:db8:3c4d:200::1/128          0/0 lo                    direct   0h1m20s
 * fe80::/64                         0/0 e7                    direct   0h1m20s
 * fe80::/64                         0/0 e6                    direct   0h1m20s
 * fe80::/64                         0/0 e5                    direct   0h1m20s
 * fe80::/64                         0/0 e4                    direct   0h1m20s
 * fe80::/64                         0/0 e3                    direct   0h1m20s
 * fe80::/64                         0/0 e2                    direct   0h1m20s
>* fe80::/64                         0/0 e1                    direct   0h1m20s
admin@example:/>
### Route Preference The operating system leverages FRRouting ([Frr][0]) as routing engine for both static and dynamic routing. Even routes injected from a DHCP client, and IPv4 link-local (IPv4) routes, are injected into Frr to let it weigh all routes before installing them into the kernel routing table (sometimes referred to as FIB). Routes have different weights made up from a *distance* and a *metric*. The kernel routing table only talks about *metric*, which unfortunately is **not the same** -- this is one of the reasons why the term *route preference* is used instead. It is recommended to use the CLI, or any of the other previously mentioned YANG based front-ends, to inspect the routing table. Default distances used (lower numeric value wins): | **Distance** | **Protocol** | |--------------|-----------------------------------------| | 0 | Kernel routes, i.e., connected routes | | 1 | Static routes | | 5 | DHCP routes | | 110 | OSPF | | 254 | IPv4LL (ZeroConf) device routes | | 255 | Route will not be used or redistributed | Hence, a route learned from OSPF may be overridden by a static route set locally. By default, even a route to the same destination, but with a different next-hop, learned from a DHCP server wins over an OSPF route. The distance used for static routes and DHCP routes can be changed by setting a different *routing preference* value. > [!NOTE] > The kernel metric is an unsigned 32-bit value, which is read by Frr as > (upper) 8 bits distance and 24 bits metric. But it does not write it > back to the kernel FIB this way, only selected routes are candidates > to be installed in the FIB by Frr. ### Source protocol The source protocol describes the origin of the route. | **Protocol** | **Description** | |:-------------|:----------------------------------------------------| | kernel | Added when setting a subnet address on an interface | | static | User created, learned from DHCP, or IPv4LL | | ospfv2 | Routes learned from OSPFv2 | The YANG model *ietf-routing* support multiple ribs but only two are currently supported, namely `ipv4` and `ipv6`. [0]: https://frrouting.org/