RIP configuration options

Several options are available to tune the default RIP configuration.

Enabling ECMP

  • Configure RIP to select several next-hop best candidates as long as they have the same cost:

    router{conf:myconfig-rtg-rip}rip equal-cost N
    
    1 <= N <= 255

    Maximum number of equal cost paths. By default this is set to 1 (No ECMP).

Specifying the RIP version

  • Change the default RIP version:

    router{conf:myconfig-rtg-rip}version {1|2}
    
  • Only send the RIP version 1 packets on the eth0_0 interface:

    router{conf:myconfig-rtg}interface eth0_0
    router{conf:myconfig-rtg-interface}ip rip send version 1
    router{conf:myconfig-rtg-interface}exit
    

With the same method, we can configure an interface to receive RIP v1 or RIP v2.

  • Allow the router to receive only the RIP v1 packets on the eth0_0 interface:

    router{conf:myconfig-rtg}interface eth0_0
    router{conf:myconfig-rtg-interface}ip rip receive version 1
    router{conf:myconfig-rtg-interface}exit
    
  • Check the configuration:

    router{conf:myconfig}exit
    [...]
    router{}show routing ip 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  Pri  RIPv1BorderGW  RIPv1IngrSumy  Key-chain
      eth0_0          1     1     7    Enable         Enable
    [...]
    

    From this output, we can notice that version 1 is the default one and that interface eth0_0 is configured to receive only RIP version 1 packets.

Note

These commands can be useful to interconnect some old RIP v1 networks to a new RIP v2 network, or during a migration period. Beware that many old routers are still using RIP v1 as the default RIP version.

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:

    router{conf:myconfig-rtg-rip}passive-interface eth1_0
    router{conf:myconfig-rtg-rip}network 10.1.1.0/28
    router{conf:myconfig-rtg-rip}network 192.168.2.0/24
    

    This appears on the configuration as

      router{conf:myconfig-rtg-rip}exit
      router{conf:myconfig-rtg}display
      [...]
      router rip
      network 10.1.1.0/28
      network 192.168.2.0/24
      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.

  • Add the address of the neighbors:

    router{conf:myconfig-rtg-rip}neighbor A.B.C.D
    

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

  1. The routing table update in seconds: default 30 s.
  2. The routing information timeout in seconds: default 180 s.
  3. The garbage collection in seconds: default 120 s.
  • Change the default timers:

    router{conf:myconfig-rtg-rip}timers basic 30 180 120
    
  • Check the timers values:

    router{conf:myconfig-rtg-rip}exit
    [...]
    router{conf:myconfig}exit
    router{}show routing ip 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 management

To decrease the traffic load when the routing table is advertised, the Turbo IPsec activates the split-horizon RIP policy by default on each interface.

  • Disable split-horizon:

    router{conf:myconfig-rtg}interface eth0_0
    router{conf:myconfig-rtg-interface}delete ip rip split-horizon
    router{conf:myconfig-rtg-interface}exit
    
  • Enable split-horizon:

    router{conf:myconfig-rtg}interface eth0_0
    router{conf:myconfig-rtg-interface}ip rip split-horizon
    router{conf:myconfig-rtg-interface}exit
    

Note

  • Split-horizon is enabled or disabled on a per interface basis, and that 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 with poisoned reverse

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 Turbo IPsec does not activate the split-horizon with poisoned reverse path on each interface.

  • Enable split-horizon with poisoned reverse path:

    router{conf:myconfig-rtg}interface eth0_0
    router{conf:myconfig-rtg-interface}ip rip split-horizon poisoned-reverse
    router{conf:myconfig-rtg-interface}exit
    

    Once your configuration is loaded, exit configuration mode and verify operation:

    router{conf:myconfig-rtg}display
    interface eth0_0
    ip rip split-horizon poisoned-reverse
    router{conf:myconfig-rtg}
    
  • Disable the poisoned-reverse option:

    router{conf:myconfig-rtg}interface eth0_0
    router{conf:myconfig-rtg-interface}delete ip rip split-horizon
    poisoned-reverse
    router{conf:myconfig-rtg-interface}exit
    

    This will disable the poisoned-reverse option in the RIP configuration and remain in the split-horizon RIP policy.

    router{conf:myconfig-rtg}display
    router{conf:myconfig-rtg}
    

Since the default RIP configuration is to enable split-horizon, nothing will be displayed here. It means that the RIP is running with split-horizon policy.

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

Default route advertisement

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

    router{conf:myconfig-rtg-rip}default-information originate
    
  • Check the result:

    router{conf:myconfig-rtg-rip}exit
    router{conf:myconfig-rtg}display
    [...]
    router rip
    default-information originate
    network 10.1.1.0/28
    network 192.168.1.0/24
    [...]
    
  • Do not advertise the default route:

    router{conf:myconfig-rtg-rip}delete default-information originate
    

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:

    router{conf:myconfig-rtg}route default-ipv4 212.234.238.114
    
  • When only one static route is defined, the command redistribute static can be used instead of this command.

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:

    router{conf:myconfig-rtg-rip}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:

    router{conf:myconfig-rtg-rip}redistribute connected
    router{conf:myconfig-rtg-rip}redistribute static
    router{conf:myconfig-rtg-rip}redistribute bgp
    router{conf:myconfig-rtg-rip}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 routing ip 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.

  • Change the default RIP distance:

    router{conf:myconfig-rtg-rip}distance 123
    

We give here a reminder of the common routing protocols administrative distance:

Routing protocol Administrative distance
Connected prefixes (routes) 0
Static routes 1
DEP 10
BGP 20
OSPF v2 and OSPF v3 110
RIP and RIPng 120

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.

router{conf:myconfig-rtg-rip}redistribute static metric 3
router{conf:myconfig-rtg-rip}redistribute connected metric 2
router{conf:myconfig-rtg-rip}redistribute bgp metric 9
router{conf:myconfig-rtg-rip}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-options.png

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

# Reminder: Addresses Configuration
interface eth0_0
  ipaddress 192.168.1.1/24
interface eth1_0
  ipaddress 10.1.1.1/28
[...]
router rip
  network 10.1.1.0/28
  network 192.168.1.0/24
  route 192.168.4.0/24
[...]
route 192.168.4.0/24 192.168.1.25
[...]

rt2

# Reminder : Addresses Configuration
interface eth0_0
  ipaddress 10.1.1.18/28
interface eth1_0
  ipaddress 10.1.1.2/28
interface eth2_0
  ipaddress 192.168.2.2/24
[...]
interface eth0_0
  ip rip split-horizon poisoned-reverse
interface eth1_0
  delete ip rip split-horizon simple
[...]
router rip
  network 10.1.1.0/27
  network 192.168.2.0/24
[...]

rt3

# Reminder : Addresses Configuration
interface eth0_0
  ipaddress 192.168.3.3/24
interface eth1_0
  ipaddress 10.1.1.19/28
[...]
router rip
  network 10.1.1.16/28
redistribute connected metric 4
[...]

rt4

# Reminder : Addresses Configuration
interface eth0_0
  ipaddress 172.16.1.4/24
interface eth1_0
  ipaddress 10.1.1.20/28
[...]
router rip
  network 10.1.1.16/28
  network eth0_0
  timers basic 30 180 120
[...]

Here is what rt1 RIP RIB and FIB look like:

rt1{}show routing ip rip
Codes: R - RIP, C - connected, S - Static, O - OSPF, B - BGP
       D - DEP
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 routing ip route
Codes: K - kernel route, C - connected, S - static, R - RIP, O - OSPF,
       B - BGP, D - DEP, > - 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