RIP configuration options

Several options are available to tune the default RIP configuration.

Enabling ECMP

  • Configure RIP to allow equal cost multipath:

vrf main
 routing rip
   allow-ecmp true
   ..
 ..

Specifying the RIP version

By default, RIP is configured to handle both incoming v1 and v2 requests. However, it is possible to globally configure the default RIP version. Below configuration example illustrates how to disable v1.

vrf main
  routing rip
    version
      receive 2
      send 2
      ..
    ..
  ..

It is also possible to disable some rip versioning handling per interface. Below example illustrates how to handle both reception and emission with RIP v1 only:

vrf main
  routing interface eth1_0
    ip rip version send 1
    ip rip version receive 1
    ..
  ..
..

Above configuration can be checked by using following show command:

vsr> show rip status
[...]
Routing Protocol is "rip"
Sending updates every 30 seconds with +/-50%, next due in 18 seconds
Timeout after 180 seconds, garbage collect after 120 seconds
Outgoing update filter list for all interface is not set
Incoming update filter list for all interface is not set
Default redistribution metric is 1
Redistributing: connected
Default version control: send version 1, receive version 1
  Interface       Send  Recv  Key-chain
  eth1_0          1     1
[...]

Note

These commands can be useful to interconnect some old RIP v1 networks to a new RIP v2 network, or during a migration period.

Passive interface

A passive RIP interface can receive and process the RIP packets, however it does not send any RIP information (except to the neighbor listed by the neighbor command).

  • Make an interface passive:

vrf main
  routing rip
    passive-interface eth1_0
    network 10.1.1.0/28
    ..
  ..

This appears on the configuration as

vsr> show config vrf main routing
routint rip
  network 10.1.1.0/28
  passive-interface eth1_0
  ..
..

In this example, routing updates will not be advertised out the interface eth1_0.

Unicast announces

Although RIP v1 is a broadcast protocol and RIP v2 is a multicast protocol, the RIP routing updates can be unicasted too. Consequently, the IPv4 address of the unicast neighbors can be defined in order for RIP to send the routing updates to a set of specific RIP nodes.

To add the address of the neighbors, use the following command :

vrf main
  routing rip
    neighbor 10.125.0.2
    ..
  ..

Note

  • This command is not required to enable RIP on point-to-point interfaces or tunnels, the network command is enough to activate RIP on these interfaces.

  • This command does NOT prevent RIP multicast packet to be sent on an interface. To suppress any RIP multicast packets, this command must be used jointly with the passive-interface command

Modifying timers

The routing protocols are based on many timers that control the stability of your network and the time convergence of the algorithms. RIP is based on three timers:

The update-interval default value is 30 seconds. This is the time between each update message emission.

The holddown interval default value is 180 seconds.

The flush interval default value is 120 seconds.

It is possible to change the timers values by using following command:

vrf main
  routing rip
    timers update-interval 30 holddown-interval 180 flush-interval 120
    ..
  ..

It is possible to check the timers values by using following show command:

vsr> show rip status
Routing Protocol is "rip"
  Sending updates every 30 seconds with +/-50%, next due in 9 seconds
  Timeout after 180 seconds, garbage collect after 120 seconds
  [...]

Note

Do not change any default value if you are deploying a RIP network over a LAN. They should only be changed over some very low bandwidth links (about 32 Kbit/s or less) or over cost expensive links.

Split horizon

When split-horizon is used, the learnt prefixes are not announced on the interface from which they come from. It has been designed to decrease traffic load and to avoid routing loops. To decrease the traffic load when the routing table is advertised, split-horizon is activated by default on each interface.

  • Disable split-horizon:

vrf main
  routing interface eth0_0
    ip rip split-horizon disabled
    ..
  ..
..

  • Enable split-horizon:

vrf main
  routing interface eth0_0
    ip rip split-horizon simple
    ..
  ..
..

Note

  • Split-horizon is enabled or disabled on a per interface basis, and the corresponding commands are executed at the interface level.

  • Disable split-horizon when many interfaces on a broadcast area do not share the same connected prefix. In this case, it is enough to disable split-horizon on the routers that have the common connected prefixes because it will act as a gateway for the different connected prefixes.

Split horizon Example

../../../../_images/ripv2-split-horizon.svg

RIP v2 split-horizon

To enable RIP and to demonstrate the split-horizon feature, the above figure will be used.

  1. Announce the different networks:

The announcing of networks is configured like below on rt1:

vrf main
  routing interface eth1_0
    ip rip split-horizon simple
    ..
  ..
  routing rip
    network 10.1.1.0/28
    interface eth0_0
    ..
  ..

  1. Show routing information:

    Now RIP is running and RIP does not announce the learnt prefixes on the interfaces from which they were learnt. This is the default behavior of Virtual Service Router.

Example

For example, rt1’s RIP RIB is:

rt1> show rip

Codes: R - RIP, C - connected, S - Static, O - OSPF, B - BGP
Sub-codes:
      (n) - normal, (s) - static, (d) - default, (r) - redistribute,
      (i) - interface

      Network         Next Hop  Metric  From      Tag  Time
C(i)  10.1.1.0/28     0.0.0.0        1  self        0
C(i)  192.168.1.0/24  0.0.0.0        1  self        0
R(n)  192.168.2.0/24  10.1.1.2       2  10.1.1.2    0  02:40
R(n)  192.168.3.0/24  10.1.1.3       2  10.1.1.3    0  02:53

By default, with this previous configuration, rt1 does not announce 192.168.2.0/24, neither 192.168.3.0/24 on the eth1_0 interface due to the split-horizon feature. When split-horizon is disabled, they are announced.

Split horizon with poisoned reverse

The goal of poisoning the reverse path is to increase the convergence of the RIP algorithm to quickly kill the RIP routing loops. When split-horizon with poisoned reverse path is enabled, the prefixes which are learned via an interface, are announced back each 30 seconds with a metric of 16 (i.e. infinite).

To increase the time convergence of the RIP algorithm, the originator routes may be poisoned. It means that the routes will be announced with an infinite metric (16) via the interface that should be used for the shortest path. However it increases the traffic load. By default Virtual Service Router does not activate the split-horizon with poisoned reverse path on each interface.

  • Enable split-horizon with poisoned reverse path:

vrf main
  routing interface eth0_0
    ip rip split-horizon poisoned-reverse
    ..
  ..

  • Disable the poisoned-reverse option:

vrf main
  routing interface eth0_0
    ip rip split-horizon simple
    ..
  ..

This will disable the poisoned-reverse option in the RIP configuration. It will fall back to the default split-horizon option.

The split horizon with poisoned reverse policy is configured on a per interface basis.

Next-hop option

When sending a RIP message, the router will if necessary add a next-hop option to the routes it advertises. This option indicates the gateway via which the router can reach the advertised destinations. It enables the routers that receive the RIP message to create local shortcuts.

If the next-hop option is not set, then the router that originated the RIP packet is used as the next-hop.

Default route advertisement

It is possible to force the next-hop value by using the default-information originate keyword.

Allow RIP to advertise the default route ` 0.0.0.0/0`:

vrf main
  routing rip
    default-information-originate true
    ..
  ..

  • Do not advertise the default route:

vrf main
 routing rip
   default-information-originate false
   ..
 ..

Note

  • When a router is advertising a default route, it is advised that it is itself configured with its own default IPv4 route to avoid that it becomes a blackhole:

vrf main
  routing static ipv4-route 0.0.0.0/0 next-hop 10.1.1.2
  ..

It is also possible to use the command redistribute static under routing rip mode, when a static route is defined.

Using route-map to change next-hop

It is possible to configure a route-map with a a set clause. More information on route-map is given in route map. Below example illustrates a RIP configuration, where nexthop is forced to be a hard set value.

vrf main
  routing rip
    interface eth1_0
    route-map eth1_0 out route-map-name rmap_name
    ..
  ..
..
routing
  route-map rmap_name seq 11
    policy permit
    set ip next-hop 10.1.0.101
    ..
  ..

Example

Example

For example, if rt3 has a static route to the network 172.16.1.0/24 via a gateway - 10.1.1.4 - on the eth1_0 interface, rt2 and rt1 know that they can directly reach this gateway without sending packets to rt3, so they conclude that there is a shorter route to network 172.16.1.0/24 via the 10.1.1.4 gateway.

../../../../_images/rip-nexthop.svg

Next-hop feature

Assuming the following configuration:

rt1

vrf main
  routing rip
    network 10.1.1.0/28
    network 192.168.1.0/24
    ..
  ..

rt2

vrf main
  routing rip
    network 10.1.1.0/28
    network 192.168.2.0/24
    ..
  ..

rt3

vrf main
  routing rip
    network 10.1.1.0/28
    network 192.168.3.0/24
    ..
  ..

It leads to the following IPv4 FIB:

rt3> show rip
Codes: R - RIP, C - connected, S - Static, O - OSPF, B - BGP
Sub-codes:
(n) - normal, (s) - static, (d) - default, (r) - redistribute,
(i) - interface

     Network          Next Hop  Metric  From    Tag  Time
C(i) 10.1.1.0/28      0.0.0.0        1  self      0
S(r) 172.16.1.0/24    10.1.1.4       1  self      0
R(n) 192.168.1.0/24   10.1.1.1       2  10.1.1.1  0  02:39
R(n) 192.168.2.0/24   10.1.1.2       2  10.1.1.2  0  02:20
C(i) 192.168.3.0/24   0.0.0.0        1  self      0

While on rt2 we have:

rt2> show rip
Codes: R - RIP, C - connected, S - Static, O - OSPF, B - BGP
Sub-codes:
(n) - normal, (s) - static, (d) - default, (r) - redistribute,
(i) - interface

     Network         Next Hop  Metric  From    Tag  Time
C(i) 10.1.1.0/28     0.0.0.0        1  self      0
R(n) 172.16.1.0/24   10.1.1.4       2  10.1.1.3  0  02:45
R(n) 192.168.1.0/24  10.1.1.1       2  10.1.1.1  0  02:46
C(i) 192.168.2.0/24  0.0.0.0        1  self      0
R(n) 192.168.3.0/24 10.1.1.3        2  10.1.1.3  0  02:45

rt1 and rt2 are using the same next-hop to join the network 172.16.1.0/24 without sending the data to rt3 that originates the route.

Note

When the next-hop is not reachable, the router should use the originator of the RIP packet as the gateway. Then, if this originator is not reachable too, the RIP entry should be ignored. Another router could announce better information.

Static RIP route

The RIP process can announce a route that has no origin. It means that it has not been introduced into the RIP RIB by the redistribute command.

  • Add a route into the RIP RIB:

vrf main
  routing rip
    static-route 1.2.2.0/24
    ..
  ..

Note

Configuring a static RIP route is very useful for testing purpose.

Redistribute other IGPs, static routes or connected routes

The RIP signaling process can learn the network prefixes either from another routing protocol such as BGP or OSPF from the connected network prefixes that have been set on the interfaces, or from the static routes that have been set.

  • Redistribute prefixes:

vrf main
  routing rip
    redistribute connected
    redistribute static
    redistribute bgp
    redistribute ospf
    ..
  ..

The redistribution of static routes applies to the default route too. It is a good practice to announce the default route from a CPE that provides a NAT service for the traffic through the public interface.

Note

The prefixes, which are announced with the redistribute command, are named Connected-redistribute (C(r)).

Redistributed connected routes appear with the sub-code C(r) in the show rip output.

Default route appears with the (d) sub-code, while a connected interface (announced in the router rip context with the network {A.B.C.D/M|IFNAME} command) appears with the (i) sub-code.

Note

If the same prefix is learnt via different means (redistribution, interface, or default) the route learnt via redistribution is the less preferred.

FIB’s RIP administrative distance

When many IGPs and EGPs are provisioning a same active route into the IPv4 FIB, the one from the preferred routing protocols is selected; for example the static routes are preferred to the OSPF v2 routes that are preferred to the RIP routes that are preferred to the eBGP routes.

The default RIP distance is 120. It is however possible to override that behaviour by using the following command:

vrf main
  routing rip
    administrative-distance default 123
    ..
  ..

More information about administrative distance of other routing protocols can be found on following reference Administrative Distance

Manage the redistributed metrics

Since the routing protocols are not the same (BGP, static, connected), the associated metrics cannot be compared, and hence cannot be kept within the RIP advertisements. An arbitrary distance, which is assimilated to a hop count, can be set with the redistribute SOURCE metric N command into the RIP context.

vrf main
  routing rip
    redistribute static metric 3
    redistribute connected metric 2
    redistribute bgp metric 9
    redistribute ospf metric 4
    ..
  ..

Note

Due to the maximum RIP metric (16), these commands decrease the size of your network.

The default redistribution metric into RIP is 1.

Note

When redistributing a routing protocol into RIP, special care must be taken for the metric control, because not all routing protocols have the same metric. Remember that RIP uses the hop count as metric.

RIP options example

In this example we will configure 4 routers rt1, rt2, rt3 and rt4 to support the RIP options.

../../../../_images/example-illustrating-rip.svg

RIP options

Required features

rt1

RIP static route option

rt2

Delete split-horizon, poison-reverse and administrative distance options

rt3

Redistribute connected + metric option

rt4

Modify timers option

rt1

vrf main
  interface
    physical eth0_0
      ipv4 address 192.168.1.1/24
      ..
    physical eth1_0
      ipv4 address 10.1.1.1/28
      ..
    ..
  routing rip
    network 10.1.1.0/28
    network 192.168.1.0/24
    static-route 192.168.4.0/24
    ..
  ..
  routing static ipv4-route 192.168.4.0/24 next-hop 192.168.1.25

rt2

vrf main
  interface
    physical eth0_0
      ipv4 address 10.1.1.18/28
      ..
    physical eth1_0
      ipv4 address 10.1.1.2/28
      ..
    physical eth2_0
      ipv4 address 192.168.2.2/24
      ..
    ..
  routing
    interface eth0_0
      ip rip split-horizon poisoned-reverse
      ..
    interface eth1_0
      ip rip split-horizon disabled
      ..
    rip
      network 10.1.1.0/27
      network 192.168.2.0/24
      ..
    ..

rt3

vrf main
  interface
    physical eth0_0
      ipv4 address 192.168.3.3/24
      ..
    physical eth1_0
      ipv4 address 10.1.1.19/28
      ..
    ..
  routing rip
    network 10.1.1.16/28
    redistribute connected metric 4

rt4

vrf main
  interface
    physical eth0_0
      ipv4 address 172.16.1.4/24
      ..
    physical eth1_0
      ipv4 address 10.1.1.20/28
      ..
    ..
  routing rip
    network 10.1.1.16/28
    network eth0_0
    timers update-interval 30 holddown-interval 180 flush-interval 120
    ..
  ..

Here is what rt1 RIP RIB and FIB look like:

rt1> show rip
Codes: R - RIP, C - connected, S - Static, O - OSPF, B - BGP
Sub-codes:
(n) - normal, (s) - static, (d) - default, (r) - redistribute,
(i) - interface

      Network          Next Hop   Metric  From      Tag   Time
C(i)  10.1.1.0/28      0.0.0.0         1  self        0
R(n)  10.1.1.16/28     10.1.1.2        2  10.1.1.2    0   02:53
R(n)  172.16.1.0/24    10.1.1.2        3  10.1.1.2    0   02:53
C(i)  192.168.1.0/24   0.0.0.0         1  self        0
R(n)  192.168.2.0/24   10.1.1.2        2  10.1.1.2    0   02:53
R(n)  192.168.3.0/24   10.1.1.2        6  10.1.1.2    0   02:53
R(s)  192.168.4.0/24   0.0.0.0         1  self        0

The 10.1.1.0/28 and 192.168.1.0/24 routes are routes to directly connected interfaces (C(i) flag), their next hop is consequently rt1 itself and the metric is 1. The 192.168.4.0/24 route is redistributed from a static route (R(s) flag), its next hop is consequently rt1 itself and the metric is 1.

The 10.1.1.16/28, 172.16.1.0/24, and 192.168.2.0/24 routes were acquired via the RIP protocol (R(n) flag), their next hop is rt2 and their metrics correspond to the number of hops up to the destination. The 192.168.3.0/24 route’s metric is 6 instead of 2, due to rt3 configuration, which increased the metric by 4.

rt1> show ipv4-routes
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,
       > - selected route, * - FIB route

 C>* 10.1.1.0/28 is directly connected, eth1_0
 R>* 10.1.1.16/28 [120/2] via 10.1.1.2, eth1_0, 00:00:16
 C>* 127.0.0.0/8 is directly connected, lo0
 R>* 172.16.1.0/24 [120/3] via 10.1.1.2, eth1_0, 00:00:16
 C>* 192.168.1.0/24 is directly connected, eth0_0
 R>* 192.168.2.0/24 [120/2] via 10.1.1.2, eth1_0, 00:00:16
 R>* 192.168.3.0/24 [120/6] via 10.1.1.2, eth1_0, 00:00:16
 S>* 192.168.4.0/24 [1/0] via 192.168.1.25, eth0_0