Configuring RIP

Problem

You want network devices running RIP Version 2 to be able to communicate with the rest of your network.

Solution

You configure basic RIP functionality on your router:

	[edit protocols]
	aviva@RouterA# set 
rip group alpha-rip-group neighbor fe-0/0/0
	aviva@RouterA# show
	protocols {
	 rip {
	 group alpha-rip-group {
	 neighbor fe-0/0/0.0;
	 }
	 }
	}

 

Discussion

To have your RIP systems communicate with the rest of your network, you enable RIP on each interface that is directly connected to a RIP neighbor. You do this by defining a group in which you identify each RIP device by the name of the interface that is directly connected to the RIP device. In this example, the Fast Ethernet interface fe-0/0/0 is the connection to your RIP device.

For the connection to the RIP neighbor to work, you must configure an IPv4 address on the interface that is connected to the neighbor (see Recipe 7.5).

We said that we were configuring RIP Version 2, but nowhere in this configuration is there any mention of the RIP version. By default, the JUNOS software configures both versions of RIP when you enable RIP. Most modern devices support and run RIP Version 2, so this shouldn't be an issue.

Why does the JUNOS software force you to put your RIP neighbors in groups instead of just letting you just define them individually? There are a few reasons for this. First, if one of your customers has multiple links to their site or sites, groups let you keep all these links together. Second, if you need to set up different authentication passwords or routing policies, or if you need to control traffic flow differently across different parts of the RIP network by modifying metrics or route preferences, it can be easier for you to configure these changes for an entire group of RIP neighbors rather than for individual neighbors.

If you have a number of RIP devices, you configure each interface that is connected to a RIP neighbor:

	[edit protocols]
	aviva@RouterA# set rip group alpha-rip-group neighbor fe-0/0/1
	aviva@RouterA# set rip group alpha-rip-group neighbor se-0/0/3
	protocols {
	 rip {
	 group alpha-rip-group {
	 neighbor se-0/0/3.0;
	 neighbor fe-0/0/0.0;
	 neighbor fe-0/0/1.0;
	 }
	 }
	}

After you have configured RIP, you can see that the connections to the RIP neighbors are active:

	aviva@RouterA>  
show rip neighbor
	 Source 
Destination Send Receive In
	Neighbor State Address Address Mode Mode Met
	-------- ----- ------- ----------- ---- ------- ---
	fe-0/0/1.0 Up 10.0.15.2 224.0.0.9 mcast both 1
	fe-0/0/0.0 Up 10.0.16.1 224.0.0.9 mcast both 1
	se-0/0/3.0 Up 10.0.21.1 224.0.0.9 mcast both 1

You see the three RIP neighbors that you configured. The first column shows the interface that is directly connected to the RIP neighbor. The second column shows that the interface to the neighbor is operational, or Up, and is listening to RIP traffic. The source address is the IPv4 address of the interface, and the destination address is the address of the neighbor's RIP interface. Here, the destination address is the well-known multicast group assigned to RIP Version 2, which is 224.0.0.9.

The Send Mode column tells how the router's RIP update packets are sent and received. The JUNOS implementation of RIP can multicast or broadcast both Version 1 and Version 2 packets (multicast is the default) or can broadcast only Version 1 packets. You should always use the default multicast mode to reduce the amount of RIP protocol update packets traveling on your network. The Receive Mode column indicates which type of RIP update packets the router can receive: Version 1, Version 2, or both (the default).

The last column shows the inbound metric, which is how many hops away the neighbor is. Here, each neighbor is directly connected and is one hop away, so the inbound metrics are 1. The metric value is included in the RIP route to the neighbor that is placed in the routing table.

If the interface to the RIP neighbor is not operational, the Source Address and Destination Address columns would show Dn (down):

	aviva@RouterA> show rip neighbor
	 Source Destination Send Receive In
	Neighbor State Address Address Mode Mode Met
	-------- ----- ------- ----------- ---- ------- ---
	fe-0/0/1.0 Up 10.0.15.2 224.0.0.9 mcast both 1
	fe-0/0/0.0 Up 10.0.16.1 224.0.0.9 mcast both 1
	se-0/0/3.0 Dn (null) (null) mcast both 1

To find out what the problem is, first check whether the interface to the neighbor is running:

	[edit interfaces]
	aviva@RouterE# run ping 10.0.15.1 count 5
	PING 10.0.15.1 (10.0.15.1): 56 data bytes
	ping: sendto: No route to host

The ping command here shows that no IPv4 address is configured on the interface. If the interface is configured properly on the local router, log in to the neighboring router and make sure that RIP is enabled and configured properly.

After RIP is running on the local router, you can check whether it is learning routes from its neighbors:

	[edit]
	aviva@RouterA#  
run show rip statistics
	 
RIPv2 info: port 520; update interval 30s; holddown 180s; timeout 120s.
	 rts learned rts held down rqsts dropped resps dropped
	 6 0 0 0
	fe-0/0/1.0: 4 routes learned; 0 routes advertised
	Counter Total Last 5 min Last minute
	------- ----------- ----------- -----------
	Updates Sent 0 0 0
	Triggered Updates Sent 0 0 0
	Responses Sent 0 0 0
	Bad Messages 0 0 0
	RIPv1 Updates Received 0 0 0
	RIPv1 Bad Route Entries 0 0 0
	RIPv1 Updates Ignored 0 0 0
	RIPv2 Updates Received 14 11 2
	RIPv2 Bad Route Entries 0 0 0
	RIPv2 Updates Ignored 0 0 0
	Authentication Failures 0 0 0
	RIP Requests Received 0 0 0
	RIP Requests Ignored 0 0 0

From this output, you see that RIP has learned six routes and that the fe-0/0/1 interface has learned four routes. The other two routes have been learned by one or both of the other two interfaces, but we have abridged the command output to save space.

One thing to notice from this output is that RIP has not sent any protocol update messages. The values in the Updates Sent line are all 0. This is the default JUNOS RIP behavior. With the basic RIP configuration of this recipe, RIP only listens to updates but does not send any.

You can find out which routes RIP learned by looking in the unicast routing table:

	aviva@RouterA> show route table inet.0
	inet.0: 13 destinations, 14 routes (14 active, 0 holddown, 0 hidden)
	+ = Active Route, - = Last Active, * = Both
	0.0.0.0/0 *[Static/5] 2w4d 23:08:21
	 > to 172.19.121.1 via fe-0/0/0.0
	10.0.0.0/24 *[Direct/0] 2w4d 23:05:23
	 > via fe-0/0/1.0
	10.0.0.2/32 *[Local/0] 2w4d 23:05:23
	 Local via fe-0/0/1.0
	10.0.1.0/24 *[ 
RIP/100] 00:04:40, metric 2, tag 0
	 > to 10.0.2.1 via fe-0/0/0.0
	 to 10.0.0.1 via fe-0/0/1.0
	10.0.2.0/24 *[Direct/0] 2w4d 23:05:23
	 > via fe-0/0/1.0
	10.0.2.2/32 *[Local/0] 2w4d 23:05:23
	 Local via fe-0/0/1.0
	10.0.8.0/24 *[Direct/0] 2w4d 23:08:59
	 > via fe-0/0/0.0
	10.0.8.1/32 *[Local/0] 2w4d 23:08:59
	 Local via fe-0/0/0.0
	10.0.16.0/24 *[ 
RIP/100] 00:02:48, metric 2, tag 0
	 > to 10.0.0.1 via fe-0/0/1.0
	10.0.24.0/24 *[RIP/100] 00:04:40, metric 2, tag 0
	 > to 10.0.2.1 via fe-0/0/0.0
	192.168.0.1/32 *[RIP/100] 00:02:48, metric 2, tag 0
	 > to 10.0.0.1 via fe-0/0/1.0
	192.168.2.1/32 *[RIP/100] 00:04:40, metric 2, tag 0
	 > to 10.0.2.1 via fe-0/0/0.0
	192.168.5.1/32 *[Direct/0] 2w4d 19:43:23
	 > via lo0.0
	224.0.0.9/32 *[RIP/100] 02:02:08, metric 1
	 MultiRecv

The route entries starting with [RIP/100] are those learned from RIP. The router has learned six routes from RIP:

• 10.0.1.0/24, 10.0.16.0/24, and 10.0.24.0/24, which are subnetworks
• 192.168.0.1/32 and 192.168.2.1./32, which are router loopback addresses
• The RIP Version 2 multicast address

The value of 100 in the brackets is the JUNOS default value for the RIP administrative distance, also called the preference, which is used to select which route is installed in the forwarding table when several protocols calculate routes to the same destination. You can change the preference value by configuring the preference statement for the RIP group. The numbers following the brackets show how long the routing table has known about the route. The metric value (either 1 or 2) indicates the distance (number of hops) to this address. Understanding the routing table is discussed in more detail in Recipe 8.1.

You might find it strange that a multicast address, 224.0.0.9/32, is present in the inet.0 routing table, which is the unicast routing table. This is simply a result of a JUNOS design decision. Instead of establishing a separate routing table for the few multicast routes used by routing protocols, which are well-known addresses, the JUNOS software places these routes in the unicast routing table.

See Also

Recipes 7.5 and 8.1