You have the ability to define static neighbor in RIP which can be used for configuring neighbors across NBMA links or just hardening the communication where RIP communicates using unicast. This lab will discuss and demonstrate the configuration and verification of static RIP Neighbors.
There is however another advantage to configuring RIP with static neighbor relationships which is added security but there is one catch!!! By default RIPv2 will send multicast updates out all interfaces specified within the range of the network command. If you configure a static neighbor; not only will that router send updates via unicast to that neighbor out the respected link. It will also send multicast updates out the same link as well. To prevent this from happening, you must utilize a feature called “Passive Interface”.
A RIP Passive Interface in a nut shell prevents the RIP routing process from sending multicast/broadcast updates out a specified interface. A RIP Passive interface however does not block unicast updates. Keep in mind a Passive Interface DOES NOT block multicast/broadcast updates therefore the router would still process received RIP updates.
So with that in mind, it’s quite common in secure networks the passive interface feature will be utilized on all interfaces and the neighbors will statically be configured to prevent RIP route snooping via Wireshark.
This lab will continue to build upon the same logical topology used previously in Lab 7-5 as shown below;
In this lab you will configure a static neighbor relationship between R1 and R2 via the Point-to-Point T1 link and verify that the neighbor relationship is indeed operating in a unicast fashion using debug ip rip events
Familiarize yourself with the following new command(s);
|neighbor x.x.x.x||This command is configured in the RIP routing process to specify a static neighbor relationship and use unicast communication with that node.|
|passive-interface name#/#||This command is executed in RIP configuration mode to specify a specific interface as passive which prevents the advertisement of multicast/broadcast updates.|
Objective 1. – Remove the previous RIP v2-broadcast configuration from R1’s point-to-point towards R2 and configure a R2’s Point-to-Point T1 interface IP address as a static neighbor.
R1#configure terminal Enter configuration commands, one per line. End with CNTL/Z. R1(config)#interface Serial0/1 R1(config-subif)#no ip rip v2-broadcast R1(config-subif)#router rip R1(config-router)#neighbor 10.70.21.2 R1(config-router)#end R1#
Objective 2. – On R2, Configure R1’s Point-to-Point T1 interface IP as a static neighbor.
R2>enable R2#configure terminal Enter configuration commands, one per line. End with CNTL/Z. R2(config)#router rip R2(config-router)#neighbor 10.70.21.1 R2(config-router)#end R2#
Objective 3. – Configure both R1 and R2 to not send Multicast/Broadcast updates out the Point-to-Point T1 link.
R1#configure terminal R1(config)#router rip R1(config-router)#passive-interface serial0/1 R1(config-router)#end R1#
R2#configure terminal R2(config)#router rip R2(config-router)#passive-interface serial0/1 R2(config-router)#end R2#
Objective 4. – Verify that RIP updates are being sent between R1 and R2 via Unicast using the debug ip rip events command.
R1#debug ip rip events RIP: sending v2 update to 10.70.21.2 via Serial0/1 (10.70.21.1) RIP: Update contains 3 routes RIP: Update queued RIP: Update sent via Serial0/1 RIP: received v2 update from 10.70.21.2 on Serial0/1 RIP: Update contains 5 routes R1#u all All possible debugging has been turned off R1#
As shown by the debug output above you can see that R1 sends a RIPv2 update to 10.70.21.2 via Serial0/1 and receives RIPv2 updates from 10.70.21.2. This shows that RIP unicast control traffic is operating as configured.