RIP Next Hop Feature and Split Horizon
This section covers the split horizon and next-hop features of RIPv2. These two features do not typically need to be considered at the same time, but in some cases they do. The example used in this section shows how the two features may be needed in the same design.
First, Cisco IOS controls the split horizon setting per interface, using the [no] ip split-horizon interface subcommand. Split horizon is on by default, except for cases in which Frame Relay is configured with the IP address on the physical interface.
The RIPv2 next-hop feature allows a RIP router to advertise a different next-hop router than the advertising router. To demonstrate the next-hop feature in Example 8-6, S2 will not run RIP at all, but rather will use OSPF to advertise routes to R2. R2 will in turn redistribute the OSPF routes into RIP, and advertise those routes to the other routers. When R2 advertises the OSPF-learned routes over the LAN, R1 learns these routes. However, because of the next-hop feature, R1 will point to S2 as the next-hop router. To cause that to happen, R2 advertises S2 as the next-hop router in R2's RIP updates.
Interestingly, for this example to work, the split horizon feature must be disabled on R2's fa0/0 interface. With split horizon enabled on fa0/0 (the default configuration), R1 would not normally advertise the redistributed routes out R2's fa0/0 interface, because R2's outgoing interface for those routes is also fa0/0. So, to force R2 to advertise those routes out fa0/0, thereby showing an example of RIP's advertisement of a different next-hop router, R2 must disable split horizon on fa0/0. Example 8-6 shows the details.
Example 8-6 RIP Next-Hop Feature ! R2 Config
! Note that split horizon is disabled on R2's fa0/0. interface FastEthernet0/0 ip address 172.31.11.2 255.255.255.0 no ip split-horizon
! Next, R2 has a basic OSPF configuration, with simple redistribution into RIP. router ospf 1
network 172.31.11.0 0.0.0.255 area 0
router rip version 2
redistribute ospf 1 metric 2 network 10.0.0.0 network 172.31.0.0
Example 8-6 RIP Next-Hop Feature (Continued)
! On R2, the three OSPF-learned routes are listed; these will be the routes that ! RIP redistributes to R1 and the rest of the routers. R2# show ip route ospf
172.31.0.0/16 is variably subnetted, 13 subnets, 2 masks O 172.31.223.0/24 [110/2] via 172.31.11.202, 02:01:40, FastEthernet0/0
O 172.31.222.0/24 [110/2] via 172.31.11.202, 02:01:40, FastEthernet0/0
O 172.31.221.0/24 [110/2] via 172.31.11.202, 02:01:40, FastEthernet0/0
! lines omitted for brevity
! Below, R2's first debug message mentions "172.31.11.2" as the update source of
! the next update. After that, the three messages, one per route, highlight the
! Next Hop field listing 172.31.11.202 (S2) as the next hop.
R2# debug ip rip
RIP protocol debugging is on
Jan 11 10:58:12.874: RIP: sending v2 update to 224.0.0.9 via FastEthernet0/0
(172.31.11.2) ! some lines omitted for brevity.
Jan 11 10:58:12.878: 172.31.221.0/24 via 172.31.11.202, metric 2, tag 0 Jan 11 10:58:12.878: 172.31.222.0/24 via 172.31.11.202, metric 2, tag 0 Jan 11 10:58:12.878: 172.31.223.0/24 via 172.31.11.202, metric 2, tag 0 ! Below, on R1, note the route to 172.31.221.0/24 points to next hop of S2. In a ! bit of a misnomer, the output lists the "last update from" information as if S2 ! (172.31.11.202) sent the last routing update, but S2 is not even running RIP. ! The second-to-last line lists the actual update's source ("from 172.31.11.2"). R1# show ip route 172.31.221.0 Routing entry for 172.31.221.0/24 Known via "rip", distance 120, metric 2 Redistributing via rip
Last update from 172.31.11.202 on FastEthernet0/0, 00:00:05 ago Routing Descriptor Blocks:
* 172.31.11.202, from 172.31.11.2, 00:00:05 ago, via FastEthernet0/0 Route metric is 2, traffic share count is 1
POINT
Post a comment