Disabling RIP on an Interface

Problem

You want to prevent an interface from participating in RIP.

Solution

You can prevent an interface from participating in RIP with the following set of commands:

Router1#configure terminal 
Enter configuration commands, one per line. End with CNTL/Z.
Router1(config)#access-list 12 deny any
Router1(config)#router rip 
Router1(config-router)#passive-interface FastEthernet0/1
Router1(config-router)#distribute-list 12 in FastEthernet0/1
Router1(config-router)#end
Router1#

 

Discussion

As we discussed in Recipe 6.1, you enable RIP on an interface with a network command. But because RIP expects any networks you specify this way to follow address class rules, it is quite easy to inadvertently enable RIP on an interface that you don't want to use this protocol.

There are two important reasons that might lead you to disable RIP on a particular interface. First, if you are already running another protocol on a particular interface, then the additional RIP traffic could consume important bandwidth resources. Second, there may be devices on a particular network segment that you do not trust. In this case you want to make sure that you don't let them distribute routing information into your network. This is particularly important because some Unix workstations run RIP by default, but the administrators rarely devote much attention to making sure that any local static routes have the correct metric values. It is possible for one misconfigured workstation to completely disrupt routing for an entire network.

This recipe does two things to disable RIP. First, the passive-interface command tells RIP not to send any routing information out through the specified interface. But this does not prevent the router from listening for incoming routes. So we have also applied an inbound distribute-list command to the interface to prevent RIP from learning any routes this way.

To demonstrate this, in the following example, we have applied the passive interface command, but not the distribute list:

Router1#show ip route rip
R 192.168.30.0/24 [120/1] via 172.25.2.2, 00:00:09, Serial0/0.2
 172.25.0.0/16 is variably subnetted, 6 subnets, 3 masks
R 172.25.25.2/32 [120/1] via 172.25.2.2, 00:00:09, Serial0/0.2
R 192.168.20.0/24 [120/1] via 172.22.1.4, 00:00:08, FastEthernet0/1
Router1#

As you can see, the router is still learning routes through the FastEthernet0/1 port. A debug trace proves that although the router doesn't send any routing information out through this interface, it does receive information this way:

Router1#debug ip rip
RIP protocol debugging is on
Aug 11 02:35:33.403: RIP: sending v1 flash update to 255.255.255.255 via FastEthernet0/0 
Aug 11 02:35:33.403: RIP: build flash update entries
Aug 11 02:35:33.403: subnet 0.0.0.0 metric 16
Aug 11 02:35:33.403: RIP: sending v1 flash update to 255.255.255.255 via Serial0/0.2
Aug 11 02:35:33.403: RIP: build flash update entries
Aug 11 02:35:33.403: subnet 0.0.0.0 metric 1
Aug 11 02:35:33.403: network 172.21.0.0 metric 1
Aug 11 02:35:39.012: RIP: received v1 update from 172.22.1.4 on FastEthernet0/1
Aug 11 02:35:39.012: 192.168.20.0 in 1 hops

Then, when we add the distribute-list command inbound on the FastEthernet0/1 interface, the unwanted route disappears from the routing table:

Router1#show ip route rip
R 192.168.30.0/24 [120/1] via 172.25.2.2, 00:00:04, Serial0/0.2
 172.25.0.0/16 is variably subnetted, 5 subnets, 2 masks
R 172.25.25.2/32 [120/1] via 172.25.2.2, 00:00:04, Serial0/0.2
Router1#

You can see the effects of both commands in the output of the show ip protocols command:

Router1#show ip protocols
Routing Protocol is "rip"
 Sending updates every 30 seconds, next due in 13 seconds
 Invalid after 180 seconds, hold down 180, flushed after 240
 Outgoing update filter list for all interfaces is not set
 Incoming update filter list for all interfaces is not set
 FastEthernet0/1 filtered by 12 (per-user), default is 12
 Redistributing: rip
 Default version control: send version 1, receive any version
 Interface Send Recv Triggered RIP Key-chain
 FastEthernet0/0.1 1 1 2 
 Serial0/0.2 1 1 2 
 Automatic network summarization is in effect
 Maximum path: 4
 Routing for Networks:
 172.22.0.0
 172.25.0.0
 Passive Interface(s):
 FastEthernet0/1
 Routing Information Sources:
 Gateway Distance Last Update
 172.25.1.7 120 00:00:08
 172.25.2.2 120 00:00:00
 Distance: (default is 120)

Router1#

Note that you could apply an inbound access list to an interface to prevent the router from receiving RIP updates from other devices. To do this, you would simply apply a filter to block UDP port 520. However, as we discuss in Chapter 19, you cannot use access control lists on an interface to filter outbound router packets. In any case, that method forces the router to look at every incoming packet. This can cause serious CPU problems on fast links. It is far more efficient to just let the RIP process do the filtering, as we have shown in this recipe.

Similarly, it is more efficient to use the passive interface command to prevent the router from sending routes out through an interface, rather than using an outbound distribute list that merely blocks all routes. This is because with the passive interface command, the router doesn't have to compare the routes it wants to send to an access list to decide whether to send them. Instead, it just knows not to send any routes.

See Also

Recipe 6.2

Router Configuration and File Management

Router Management

User Access and Privilege Levels

TACACS+

IP Routing

RIP

EIGRP

OSPF

BGP

Frame Relay

Handling Queuing and Congestion

Tunnels and VPNs

Dial Backup

NTP and Time

DLSw

Router Interfaces and Media

Simple Network Management Protocol

Logging

Access-Lists

DHCP

NAT

First Hop Redundancy Protocols

IP Multicast

IP Mobility

IPv6

MPLS

Security

Appendix 1. External Software Packages

Appendix 2. IP Precedence, TOS, and DSCP Classifications

Index



Cisco IOS Cookbook
Cisco IOS Cookbook (Cookbooks (OReilly))
ISBN: 0596527225
EAN: 2147483647
Year: 2004
Pages: 505

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