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:
vrouter> 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
vrouter> 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:
vrouter> 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¶
To enable RIP and to demonstrate the split-horizon feature, the above figure will be used.
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
..
..
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 Turbo 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 Turbo 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.
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.
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