RIP

The Routing Information Protocol (RIP) is the oldest routing protocol that is still widely used. It has a large support base and a simple configuration. However, it also has a major drawback: poor route determination. RIP is a distance-vector protocol that looks only at the number of route hops (i.e., the number of routers crossed in traveling from one network to another) in computing the best route. For example, let's say that there are two routes to a destination. The first route crosses two separate 56K links, for a metric of 2; the second route crosses three T1 links, for a metric of 3. RIP always selects the first (two-hop) route, even though it is obvious that the second route is better under almost all circumstances. It's possible to use offset lists to force RIP to choose the better route, but that's merely adapting to the problem, not fixing it.

Another problem with RIP is that it can't scale to large networks. There are two scaling issues. First, routers using RIP periodically broadcast the entire routing table to the network. These broadcasts can eat precious bandwidth on lines that often can't afford it. Second, RIP considers any route past 15 hops unreachable. In addition, RIP does not support Variable-Length Subnet Masks (VLSM), an important technique for conserving IP-address space. Nor does it have any mechanism for authenticating other routers; it isn't difficult to trick RIP into believing bogus routing information. And it isn't particularly quick at settling on a new set of routes after the network is disrupted.

RIPv2 tried to solve some of RIP's shortcomings by introducing support for VLSM, bandwidth calculations (a more sophisticated metric for determining the best route), and route authentication. However, it is still limited by the basic scaling problem of its predecessor, the 15-hop limit. Any route that exceeds 15 hops is still considered unreachable.

With all of RIP's drawbacks, which are only partially addressed in Version 2, why would you consider RIP at all? You might find that RIP suits your needs if you have a small network and would like a routing protocol that is easy to manage. It's also supported by just about every piece of network hardware in existence, so you may be forced to use RIP if you have a large installed base that you can't afford to replace. In short, while RIP works well in small environments with only a handful of routers, most networks today require a more sophisticated and scalable routing protocol. Still, despite its drawbacks, RIP will be with us for the foreseeable future.

9.1.1. Basic RIP Configuration

Figure 9-1 shows a network configuration in which we want to enable RIP on Router 1, Router 2, and Router 3.

Figure 9-1. A simple network

To enable RIP on the routers, we use the router rip command followed by the network command, which lists the networks that are directly connected to each router and that are participating in RIP. We don't have to list networks that aren't directly connectedRIP's job is to find out about these. Likewise, we don't need to list networks that aren't running RIP; if there are any (and there aren't in this example), we'll have to handle them through route redistribution.

For Router 1, the configuration looks like this:

interface Ethernet0
 ip address 172.16.1.1 255.255.255.0
!
interface Serial0
 ip address 192.168.3.1 255.255.255.0
!
interface Serial1
 ip address 192.168.1.1 255.255.255.0
!
router rip
 version 2
 network 172.16.0.0
 network 192.168.1.0
 network 192.168.3.0

Here's the configuration for Router 2:

interface Ethernet0
 ip address 172.17.1.1 255.255.255.0
!
interface Serial0
 ip address 192.168.1.2 255.255.255.0
!
interface Serial1
 ip address 192.168.2.1 255.255.255.0
!
router rip
 version 2
 network 172.17.0.0
 network 192.168.1.0
 network 192.168.2.0

For Router 3, the configuration is:

interface Ethernet0
 ip address 172.18.1.1 255.255.255.0
!
interface Serial0
 ip address 192.168.2.2 255.255.255.0
!
interface Serial1
 ip address 192.168.3.2 255.255.255.0
!
router rip
 version 2
 network 172.18.0.0
 network 192.168.2.0
 network 192.168.3.0

Remember that RIP (as well as IGRP and EIGRP) is a classful routing protocol. Therefore, we need to be careful about our network statements. For example, on Router 1 we specify 172.16.0.0 (the classful address), not 172.16.1.0.

After the routers are configured, show ip route shows that everything is working nicely:

Router1#show ip route
Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP
 D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
 N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
 E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
 i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, * - candidate default
 U - per-user static route, o - ODR

Gateway of last resort is not set

R 172.17.0.0/16 [120/1] via 192.168.1.2, 00:00:09, Serial1
 172.16.0.0/24 is subnetted, 1 subnets
C 172.16.1.0 is directly connected, Ethernet0
R 172.18.0.0/16 [120/1] via 192.168.3.2, 00:00:03, Serial0
C 192.168.1.0/24 is directly connected, Serial1
R 192.168.2.0/24 [120/1] via 192.168.3.2, 00:00:03, Serial0
 [120/1] via 192.168.1.2, 00:00:10, Serial1
C 192.168.3.0/24 is directly connected, Serial0

From this output, we can see that Router 1 knows how to get to the 172.17.0.0/16 network through Serial1. Note that RIP has summarized 172.17.1.0/24 into a classful network boundary. It has done the same for 172.16.0.0/16 and 172.18.0.0/16. Automatic summarization is enabled by default in most protocols. To disable this behavior, use the no auto-summary command. In our little network, summarization works. (If we had subnetted differently, summarization could have been a big problem. See "EIGRP" later in this chapter for a complete example of how auto-summarization can affect a network.) The output from show ip route also shows that Router 1 knows two paths to the 192.168.2.0/24 network.

Now, let's ping to make sure that our network is functional. From Router 1, ping Router 2's Ethernet interface:

Router1#ping 172.17.1.1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.17.1.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 28/29/32 ms

Now ping Router 3's Ethernet interface:

Router1#ping 172.18.1.1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.18.1.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 28/30/32 ms

While the pings were successful, this isn't a true test of our routing configurationit only tests connectivity to the router. Still, ping is an extremely useful tool for showing that your hosts are on the network and reachable.

9.1.2. Enabling RIPv2 on the Network

By default, a Cisco router automatically listens to both Versions 1 and 2 of RIP. However, it sends only Version 1 packets. If you want to use RIPv2, you must enable it by using the version 2 command, as we did in the previous example. To get finer control over which version of RIP you're using, you can use the ip rip command to enable or disable Version 2 at the interface level. This command allows the router to talk Version 2 out one interface and Version 1 out another. See the ip rip command in Chapter 17 for more information.

9.1.3. Redistributing Other Routing Protocols into RIP

Many networks use two or more routing protocols; often, a second protocol is needed at the interface between one network and another. Less often, two protocols will be used within one network, possibly to accommodate older equipment. This raises a problem with metrics: one protocol's route metric might not translate to the metric used by another protocol. We use the default-metric command to assign a default metric value to routes received from other protocols. In the following example, we need to redistribute routes learned from EIGRP into RIP. However, these protocols have incompatible metrics. To solve this problem, we assign a default metric of 10, which is given to all routes that don't otherwise have a metrici.e., routes learned from other protocols (in this case, all routes learned from EIGRP):

router rip
 network 10.0.0.0
 default-metric 10
 redistribute eigrp 100

In this case, the EIGRP process number is 100. Depending on the routing protocol being redistributed, a process number may or may not be required.

9.1.4. RIPv2 Authentication

RIPv2 authentication provides some basic security to the routing updates. Since RIP automatically listens to anyone on the network who is also using RIP, a malicious user could easily intercept and corrupt the routing tables by injecting false information. RIPv2's authentication provides a password-like mechanism called a key to authenticate the routes from other machines.

The default authentication method is text, which means the passwords are exchanged in clear text. The keys will appear in every RIPv2 packet, so clear text is not secure. Anyone with a packet-sniffing program (such as ethereal or snoop) can discover what the passwords are by scanning all the RIP packets on a network. However, the authentication mode can easily be changed to use the MD5 message-digest algorithm , as in the following example. While MD5 is not true encryption, the passwords are no longer exchanged in clear text.

In this example, we configure the key chain and the authentication mode. The key chain is a series of passwords we are willing to accept. The final step is to enable RIPv2 authentication for an interface, which in this case is ethernet1. (For more information on key configuration, see Chapter 15.)

interface ethernet1
 ip rip authentication key-chain group1
 ip rip authentication mode md5
!
key chain group1
 key 1
 key-string authme1
 key 2
 key-string authme2
!
router rip
 version 2
 network 10.0.0.0

In this configuration, all RIP updates going in and out of ethernet1 are subject to RIPv2 authentication, which requires the key authme1 or authme2.





Cisco IOS in a Nutshell
Cisco IOS in a Nutshell (In a Nutshell (OReilly))
ISBN: 0596008694
EAN: 2147483647
Year: 2006
Pages: 1031
Authors: James Boney
Simiral book on Amazon

Flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net