8.2 RIP

RIP is one of the oldest IGP protocols used today. RIP has its roots in the U.S. Department of Defense ARPANET in 1969. There are also components in RIP from early Xerox Network Systems (XNS) and Free BSD (Berkeley Software Design, Inc.) UNIX routing applications. (More history on RIP can be found at www.ietf.org/rfc.html RFC 1058.)

There are two RIP versions that are still supported by most routers today: version 1 (RIPv1) and version 2 (RIPv2). RIPv2 has been standardized by the IETF in RFC 2453. RIPv1 was never completely standardized, and although it is still used in some cases, its use is not recommended owing to its lack of flexibility. However, RIPv1 will be covered here because it is still supported by Juniper Networks routers.

8.2.1 Theory of Operation

RIP is simpleit is the quick and easy routing protocol. Its simplicity and low processing requirements are two reasons the implementation of RIP networks persists. RIP uses the Bellman-Ford algorithm (distance vector) to determine the path to a destination network. When a RIP router learns routes from neighboring routers, it adds these routes to its routing table and forwards a copy of all of the routes out of RIP-enabled interfaces every 30 seconds. An entry is made up of the destination network and the number of hops to get there. If there are 500 network route entries in the routing table, all 500 entries will be sent out of RIP interfaces every 30 seconds. This can use considerable network bandwidth as the size of the network grows.

The RIP update consists of the destination prefix and the metric for each known network. When a RIPv1 router has not had a network route updated from another for 180 seconds, it marks that router's networks as unreachable by setting the metric to 16. If another 60 seconds pass, and it still has not received a network update for that network, it will remove the network from the routing table.

RIPv1 has two very important limitations. It can only be used in classful route advertisements and has a high metric limit of 15. The classful route advertisement limitation is significant because it prevents RIPv1 from using CIDR and VLSMs, which were created to drastically increase network address flexibility. The RIPv1 metric limit of 15 means that this routing protocol can only be used in smaller networks. If the metric for a RIPv1 network is set to 16, the network is considered unreachable by the router. A metric of 16 is also known as count-to-infinity because it is beyond what RIP considers reachable .

8.2.2 RIP Metrics

RIP only uses one metrichop count. A network segment is considered to be the link between two routers. In Figure 8-5, router A has two different paths that it can use to forward packets toward network 10.10.10.0/24 . When router B advertises 10.10.10.0/24 to router A, it advertises a metric of 1. Adding the directly connected link between router A and router B, router A sees 10.10.10.0/24 as two hops away, through router B. Router B also advertises 10.10.10.0/24 to router C as one hop away. Router C adds a hop and advertises 10.10.10.0/24 as two hops away. Router A then adds a hop for the directly connected interface and sees 10.10.10.0/24 as three hops away through router C. Router A compares the two potential paths to the destination network. The route through router B is entered into the routing table because it has the lowest metric.

Figure 8-5. RIP Metrics

8.2.3 Loop Avoidance

The nature of distance vector can cause routing loops . In Figure 8-6, you can see a routing loop form. Network 10.10.1.0 is attached to router A. Router A advertises network 10.10.1.0 to router B. Router B then advertises it to router C. Router C then advertises it to router D. Finally, Router D advertises the network back to router A.

Figure 8-6. Routing Loops

If network 10.10.1.0 has a malfunction, router A will send the update to router B and so on. Before those updates can finish propagating through the network, router D could be telling router A that it knows how to get to network 10.10.1.0 . Router A may then start sending traffic bound for 10.10.1.0 to router D, thinking router D still has a viable route to 10.10.1.0 .

There are three features that RIP uses to assist in preventing routing loops and keeping routing information correct: split horizon, split horizon with poison reverse, and triggered updates. Split horizon states that no network advertisement will be sent out of the same interface through which it was received. This does help in preventing loops, but it is slow to timeout the routes that might cause loops.

Poison reverse is another RIP feature that is implemented with split horizon. With split horizon only, potentially loop- causing routes must timeout before being withdrawn. Split horizon with poison reverse allows that route to always be advertised out of the incoming interface, but with an assigned metric of 16, which is considered unreachable. Split horizon has advantages with and without poison reverse. A disadvantage of not using poison reverse is long convergence times after a network change. When new routes are added that have a lower metric, or a lower metric route fails, the routes must be timed out before they can be removed from the routing tables. An advantage of not using poison reverse is that the routing updates are smaller because they only have to include the best routes. What happens when adding poison reverse to split horizon? The advantages and disadvantages are reversed . Network changes can be propagated quickly through the network because routes will not be removed from the updates, just labeled unreachable, but all of the unusable routes in the update waste bandwidth when updates are sent. This keeps RIP from being used efficiently in all but the smallest networks.

Triggered updates assist these other two features in propagating changes as soon as they happen. Triggered updates allow a router to send an update almost immediately after a metric change. The advantage for triggered updates is the rapid convergence time of the network. The disadvantage is the very large amount of excess network traffic that can be generated in a large RIP network with frequent changes.

8.2.4 RIPv1 Versus RIPv2

The main difference between RIPv1 and RIPv2 is classless routing. RIPv2 incorporates the addition of the network mask in the update to allow classless routing advertisements. This is extremely important for the flexibility needed to efficiently utilize the network assignments for an ever-shrinking pool of IP addresses.

There are other differences between RIPv1 and RIPv2. In RIPv2, the destination address for the updates is multicast, instead of broadcast, as in RIPv1. This reduces the burden on network devices that do not need to listen to RIP updates. With broadcast, every device in the broadcast domain must at least open the IP packet and process the initial information to determine relevance. With multicast addressing, if a device needs that information, it will listen to that specific address. If it does not need the RIP information, it does not have to process the multicast address. The multicast address RIPv2 sends to is 224.0.0.9 .

Another addition to RIPv2 is authentication. Authentication is used to ensure that routes being distributed throughout the network are coming from authorized sources.

8.2.5 RIP Design Principles

If you are designing a network, only use RIP if you must. All Juniper Networks routers have enough processing power to handle more robust and efficient routing protocols, such as OSPF or IS-IS. RIP may sometimes be used in cases where Juniper Networks routers are being installed in a network already running RIP, for instance, before migrating to OSPF or IS-IS.

If you decide to use RIP, the next decision is which version to use. RIPv2 should be used if possible. Classless routing, multicast updates, and authentication are advantages of RIPv2 over RIPv1. Since RIPv1 and RIPv2 can both reside on an interface of a Juniper Networks router, a Juniper Networks router can be used as a gateway between version types or for upgrading from RIP to OSPF.

Either RIP version should be monitored closely to ensure the paths the router is choosing for forwarding are the most desirable. It is easy for a situation to occur in which RIP is sending data to destinations over very small bandwidth links because its only metric is hop count.

Figure 8-7 illustrates a network running RIP. Because the number of hops to reach 10.10.1.0/24 from router A is through the T1 link to router B, router A will ignore the faster T3 links between routers A and C and routers C and B. Manual configuration of metrics on the direct link between routers A and B would be required to ensure that RIP saw that path as having a higher hop count and, therefore, as less desirable.

Figure 8-7. RIP Path Evaluations

Since RIP sends the entire routing table out every 30 seconds, as the network grows so does the entire routing table and all of the updates with it. RIP should be monitored to ensure that network congestion is not ensuing. Even using RIPv2 with multicast updates, the updates will still take up valuable bandwidth.

8.2.6 Basic RIP Configuration

RIP is configured in two easy steps:

1. Create a policy that will export routes from the routing table that RIP can advertise.

2. Add an interface to the RIP process so the interface may be allowed to advertise RIP routes.

In Figure 8-8, two routers will advertise their directly connected networks to each other using RIP.

Figure 8-8. RIP Configurations

The first step in configuring RIP is to create a policy that will export routes from the routing table that RIP can advertise. (Importing and exporting routing policy is discussed in detail in Chapter 11.) You create a policy in the [edit policy-options] hierarchy level. We want RIP to advertise all directly connected networks, so in this example, we will create a policy named rip1 on each of the three routers that export the directly connected routes. Below, the configuration steps are followed by explanations of what the commands accomplish:

 [edit]  lab@Chicago# edit policy-options 

This enters the policy-options hierarchy.

 [edit policy-options]  lab@Chicago# edit policy-statement rip1 

This creates a policy-statement named rip1 .

 [edit policy-options policy-statement rip1]  lab@Chicago# set from protocol direct 

This determines a match condition for directly connected routes.

 [edit policy-options policy-statement rip1]  lab@Chicago# set then accept 

This accepts the routes that meet the match condition.

 [edit policy-options policy-statement rip1]  lab@Chicago# up [edit policy-options] lab@Chicago# show <----- shows all configured policy-options policy-statement rip1 { from protocol direct; then accept; } [edit policy-options] lab@Chicago# 

The second step is to configure a RIP group that will represent all RIP neighbors that can be advertised to in the same manner. Under the named group , the export policy statement is configured, and the interface through which RIP will export that policy statement is selected.

 [edit]  lab@Chicago# edit protocols rip [edit protocols rip] lab@Chicago# edit group boston 

This creates group called boston .

 [edit protocols rip group boston]  lab@Chicago# set export rip1 

This applies the policy-statement to generate advertisements.

 [edit protocols rip group boston]  lab@Chicago# set neighbor fe-0/0/1 

This tells RIP which interface will send those advertisements.

 [edit protocols rip group boston]  lab@Chicago# up [edit protocols rip] lab@Chicago# show group boston { export rip1; neighbor fe-0/0/1; } [edit protocols rip] lab@Chicago# commit commit complete [edit protocols rip] lab@Chicago# 

RIP has now been configured on both Chicago and Boston. When showing the routing table of Chicago, we see the routes learned from RIP. Chicago has network 30.30.30.0/24 via interface fe-0/0/1 . The next-hop is the interface on Boston. Chicago has learned this because of the advertisement for this network from Boston that was received on Chicago's fe-0/0/1.0 interface. In addition, there is a multicast address of 224.0.0.9/32 that has been added to the routing table. These addresses are highlighted below. This is the multicast address that RIPv2 uses to send updates to. This address is added when RIPv2 is implemented.

 lab@Chicago> show route  inet.0: 8 destinations, 8 routes (8 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 10.0.0.0/24        *[Direct/0] 07:26:38         via fe-0/0/2.0 10.0.0.1/32        *[Local/0] 07:26:39                      Local  30.30.30.0/24      *[RIP/100] 00:02:59, metric 2  51.0.0.0/24        *[Direct/0] 07:26:38         via fe-0/0/1.0 51.0.0.1/32        *[Local/0] 07:26:39                      Local  224.0.0.9/32       *[RIP/100] 00:03:22, metric 1  lab@Chicago> 

On Boston, 10.0.0.0/24 is learned from Chicago, so Boston has added the entry into its routing table.

 lab@Boston> show route  inet.0: 8 destinations, 8 routes (7 active, 0 holddown, 1 hidden) + = Active Route, - = Last Active, * = Both  10.0.0.0/24        *[RIP/100] 00:03:38, metric 2  30.30.30.0/24      *[Direct/0] 07:23:51        via fe-0/0/1.0 30.30.30.2/32      *[Local/0] 07:23:51                      Local 51.0.0.0/24        *[Direct/0] 07:23:51        via fe-0/0/0.0 51.0.0.2/32        *[Local/0] 07:23:51                      Local 224.0.0.9/32       *[RIP/100] 00:12:27, metric 1 lab@Boston> 

RIPv1 and RIPv2 can be run simultaneously . You can use this feature to migrate an existing RIPv1 network to one running RIPv2. In addition, this allows a Juniper Networks router to communicate and interact with older routers that might not have the ability to run RIPv2. Configuring the router to send and receive specific versions of RIP can be done in one of two places:

1. Under the main RIP heading

2. Individually under the group

This allows the grouping of RIPv1 and RIPv2 neighbors. Juniper Networks routers receive both RIPv1 and RIPv2 and send RIPv2 as a default. Below, RIP sending remains RIPv2 by default while RIP receiving has been set for RIPv2 only:

 [edit protocols rip]  lab@Chicago# set receive ? Possible completions:   both                 Accept both RIPv1 and RIPv2 packets   none                 Do not receive RIP packets   version-1            Accept RIPv1 packets only   version-2            Accept only RIPv2 packets [edit protocols rip] lab@Chicago# [edit protocols rip] lab@Chicago# set receive version-2 [edit protocols rip] lab@Chicago# show send version-2; receive version-2; group boston { export rip1; neighbor fe-0/0/1.0; } 

8.2.7 RIP Authentication

As stated earlier in this section, RIPv2 allows for authentication. You can use authentication to ensure that routers or hosts do not inject any routes not configured by the authorized administrators. This assists an administrator in having the most control over which routers can communicate with each other and what networks they can advertise.

Juniper Networks routers can use simple text passwords or MD5 authentication. Plain-text passwords are passed through the network in simple, readable form, although when the password is typed in plain text in the CLI, it will appear scrambled when shown in CLI output. MD5, or message digest version 5, passes encrypted keys so passwords cannot be readily "snooped" on the network. A shared key authenticating the reader, in this case a router, on the other end is the only way to view the contents of the message.

In the following example, an authentication-type of simple and a password of juniper01 are configured. Following the configuration code, sample CLI output is also shown, demonstrating that the password juniper01 has been encrypted by the router.

 [edit protocols rip]  lab@Chicago#  set authentication-type simple  [edit protocols rip] lab@Chicago#  set authentication-key juniper01  [edit protocols rip] lab@Chicago# show send multicast; receive version-2;  authentication-type simple;   authentication-key " 
 [edit protocols rip] lab@Chicago#  set authentication-type simple  [edit protocols rip] lab@Chicago#  set authentication-key juniper01  [edit protocols rip] lab@Chicago# show send multicast; receive version-2;  authentication-type simple;   authentication-key "$9$0Eus1EyM87s2alK2aZU.mO1RErevWL"; # SECRET-DATA  group chicago { export rip1; neighbor fe-0/0/1.0; } [edit protocols rip] lab@Chicago# 
 Eus1EyM87s2alK2aZU.mO1RErevWL"; # SECRET-DATA  group chicago { export rip1; neighbor fe-0/0/1.0; } [edit protocols rip] lab@Chicago# 

8.2.8 RIP Parameters

RIP has several parameters that can be adjusted to fine tune network configuration: metrics, message-size , and reserved-field validation for RFC compliance. Metrics are the most important. Administratively manipulating metrics allows the administrator to pick the path the data will take through the RIP network. Juniper Networks routers can change the number of routes the update contains to make the updates more efficient. This number can range from 25 (default) to 255.

The command message-size is used either in the global RIP configuration or can be specified by neighbor under the group, as shown next:

 [edit protocols rip group chicago]  lab@Boston# set neighbor fe-0/0/0 message-size ? Possible completions: <message-size>       Number of route entries per update message (25..255) [edit protocols rip group chicago] lab@Boston# set neighbor fe-0/0/0 message-size 

You should set the reserved fields of RIP updates to zero. By default, updates that do not comply with this standard are dropped. If interoperability requires these updates to be received and acted on, then the no-check-zero parameter can be used, as shown in the help context below.

 [edit protocols rip group boston]  lab@Chicago# set neighbor fe-0/0/1 ? Possible completions:   <[Enter]>            Execute this command   advertise-default    Generate advertisements for 0/0 with given metric (1..15) apply-groups         Groups from which to inherit configuration data authentication-key   Authentication key (password) authentication-type  Authentication type  check-zero           Check reserved fields on incoming RIPv1 packets  import               Import policy message-size         Number of route entries per update message (25..255) metric-in            Metric value to add to incoming routes (1..15)  no-check-zero        Don't check reserved fields on incoming RIPv1 packets  receive              Configure RIP receive options send                 Configure RIP send options                     Pipe through a command [edit protocols rip group boston] lab@Chicago# set neighbor fe-0/0/1 

8.2.8.1 Manipulating RIP Metrics

There are two ways to manipulate RIP metrics: incoming to the router and outgoing from the router. If a metric-in is manipulated, it affects the advertisement as it enters the router, before it goes to the routing table. If the metric-out is adjusted, then it changes the hop count to that which was advertised from the originating router.

Metric-in is used globally in RIP. This means it is configured directly in the [edit protocol rip] area and affects all groups at the same time. Metric-out , on the other hand, can be specified by group. This allows an administrator to advertise routes differently depending on group.

In Figure 8-9, Chicago has network 192.168.254.0/24 , and will advertise it to Boston and Washington D.C. If Boston and Washington D.C. were in two different groups, Chicago could set the metric-out differently to affect which way they send traffic. If Chicago keeps the default metrics, Boston and Washington D.C. will use their directly connected links to forward to 192.168.254.0/24 .

Figure 8-9. RIP Metric Configuration

Looking at Boston's routing table, you will notice that the route for the network 192.168.254.0/24 is forwarded out of interface fe-0/0/0 , which is directly connected to Chicago with the address in that network of 192.168.254.1 . When Chicago's metric-out to group Boston is manipulated to add three hops, Boston will now forward packets bound for 192.168.254.0/24 to Chicago through Washington D.C.

 lab@Boston> show route  inet.0: 8 destinations, 8 routes (7 active, 0 holddown, 1 hidden) + = Active Route, - = Last Active, * = Both  10.0.0.0/24        *[RIP/100] 00:00:12, metric 2  30.30.30.0/24      *[Direct/0] 1d 00:23:18                     > via fe-0/0/1.0 30.30.30.2/32      *[Local/0] 1d 00:23:18                      Local 51.0.0.0/24        *[Direct/0] 1d 00:23:18      via fe-0/0/0.0 51.0.0.2/32        *[Local/0] 1d 00:23:18                      Local  192.168.254.0/24   *[RIP/100] 00:00:12, metric 2  224.0.0.9/32       *[RIP/100] 00:00:14, metric 1 lab@Boston> 

Chicago has a metric-out added to the Boston group, changing the metric on the received routes from Chicago by adding three hop counts to each route.

 [edit protocols rip]  lab@Chicago# edit group boston [edit protocols rip group boston] lab@Chicago# set metric-out 3 [edit protocols rip group boston] lab@Chicago# show  metric-out 3;  export rip1; neighbor fe-0/0/1.0; [edit protocols rip group boston] lab@Chicago# 

Looking at the Boston routing table, the route for 192.168.254.0/24 from Chicago now has a higher metric than the route from Washington D.C. Boston enters the new lowest metric path through Washington D.C. out fe-0/0/1 into the routing table.

 lab@Boston> show route  inet.0: 8 destinations, 8 routes (7 active, 0 holddown, 1 hidden) + = Active Route, - = Last Active, * = Both  10.0.0.0/24        *[RIP/100] 00:00:06, metric 2   > to 30.30.30.1 via fe-0/0/1.0  30.30.30.0/24      *[Direct/0] 1d 00:33:42                    >via fe-0/0/1.0 30.30.30.2/32      *[Local/0] 1d 00:33:42                      Local via fe-0/0/1.0 51.0.0.0/24        *[Direct/0] 1d 00:33:42                     > via fe-0/0/0.0 [RIP/100] 00:00:06, metric 3                     > to 30.30.30.1 via fe-0/0/1.0 51.0.0.2/32        *[Local/0] 1d 00:33:42                      Local  192.168.254.0/24   *[RIP/100] 00:00:06, metric 3   > to 30.30.30.1 via fe-0/0/1.0  224.0.0.9/32       *[RIP/100] 00:10:38, metric 1 lab@Boston> 

This has been a quick explanation of manipulating RIP metrics in a Juniper Networks router. Be advised that this is something to be done with care. Doing this incorrectly can cause loops or, at least, suboptimal routing.