You want to exchange routing information with one device on a network, but not with any others.
You can configure RIP to send its updates to a neighboring router using unicast instead of broadcast or multicast packets. This is useful in two situations. First, on Nonbroadcast Multiple Access (NBMA) networks, you can't use the standard broadcast or multicast methods for distributing information because the media doesn't support it. Second, sometimes you need to exchange routing information with one or more specific devices on a segment, but you don't trust the rest to give you reliable information. This feature is rarely used, but it can be extremely valuable in these types of situations:
Router1#configure terminal Enter configuration commands, one per line. End with CNTL/Z. Router1(config)#router rip Router1(config-router)#passive-interface FastEthernet0/1 Router1(config-router)#neighbor 172.22.1.4 Router1(config-router)#end Router1#
This recipe uses the passive-interface command discussed in Recipes 6.6 and 6.7 to prevent the router from sending routing information to the interface in general. Note that it does not prevent the router from receiving routing information from other devices on the segment. We will discuss how to solve that problem in a moment.
A debug trace helps to show how the unicast update option works:
Router1#debug ip rip RIP protocol debugging is on Router1# Aug 11 02:41:13.632: RIP: sending v1 update to 255.255.255.255 via FastEthernet0/0.1 (172.25.1.5) Aug 11 02:41:13.636: RIP: sending v1 update to 255.255.255.255 via Serial0/0.2 (172.25.2.1) Aug 11 02:41:13.644: RIP: sending v1 update to 172.22.1.4 via FastEthernet0/1 (172.22.1.3)
Here you can see that this router sends its updates to the general broadcast address, 255.255.255.255, for all of the other interfaces, but for FastEthernet0/1, the update goes directly to 172.22.1.4. We note in passing that this is RIP Version 1. If it were Version 2, it would send updates using the multicast address 188.8.131.52, instead of the general segment broadcast address by default. However, the unicast option for Version 2 would work exactly the same as shown here.
The output of the show ip protocols command includes information about any unicast neighbors:
Router1#show ip protocols Routing Protocol is "rip" Sending updates every 30 seconds, next due in 21 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 Redistributing: rip Neighbor(s): 172.22.1.4 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:26 172.25.2.2 120 00:00:14 172.22.1.4 120 00:00:07 Distance: (default is 120) Router1#
As we noted in Recipe 6.6, just making an interface passive does not prevent it from listening for updates. But one of the most common reasons for using unicast neighbors with RIP is to ensure that the router accepts routing information only from specific devices on a segment. So we need to configure the router to reject incoming RIP information from all other devices. This is most easily accomplished by using an access list, as follows:
Router1#configure terminal Enter configuration commands, one per line. End with CNTL/Z. Router1(config)#access-list 101 permit udp host 172.22.1.4 any eq rip Router1(config)#access-list 101 deny udp any any eq rip Router1(config)#access-list 101 permit ip any any Router1(config)#interface FastEthernet0/1 Router1(config-if)#ip access-group 101 in Router1(config-if)#end Router1#
Recipe 6.6; Recipe 6.7
Router Configuration and File Management
User Access and Privilege Levels
Handling Queuing and Congestion
Tunnels and VPNs
NTP and Time
Router Interfaces and Media
Simple Network Management Protocol
First Hop Redundancy Protocols
Appendix 1. External Software Packages
Appendix 2. IP Precedence, TOS, and DSCP Classifications