Split Horizon is a loop avoidance feature for distance vector routing protocols. OSPF, being a Link-State RP, has loop avoidance properties derived from it's nature, so the SH rule does not apply (look into how information is shared on a NBMA or BROADCAST network between DR/BDR/DROTHERs). If you redistribute a DVRP into a LSRP that runs over the same set of routers, you're likely going to create routing loops.
Jay Greenberg On Sat, 2002-06-08 at 02:37, Chuck wrote: > 179 days and counting. Going through my protocol by protocol review. > > 192.168.1.0/24 > ---------------------------------------------------------------------- > | | | > | > R1 R2 R3 R4 > > > R2 redistributes IGRP into RIP > > the purpose of the exercise is to review the purpose and function of the > default-metric command under RIP in a redistribution situation. > > Now consider that R2 learns certain routes from IGRP via the ethernet > interface, and is supposed to redistribute those routes into RIP, and > advertise those routes out the ethernet interface to R1. > > However, based on my observation, it would appear that split horizon is > preventing this. Observe: > > IGRP on R2 > > 01:48:12: RIP: build update entries > 01:48:12: network 192.168.1.0 metric 1 > 01:48:12: network 192.168.10.0 metric 2 > 01:48:12: network 192.168.30.0 metric 5 > 01:48:12: network 192.168.40.0 metric 5 > 01:48:39 > > Router_1#ir > > C 192.168.10.0/24 is directly connected, Loopback0 > R 192.168.20.0/24 [120/1] via 192.168.1.2, 00:00:16, Ethernet0 > C 192.168.1.0/24 is directly connected, Ethernet0 > > > Note that while R2 is creating the RIP routes, R1 does not receive them > > But if I disable split horizon on the ethernet interface, then observe: > > Router_1#ir > > R 192.168.30.0/24 [120/5] via 192.168.1.2, 00:00:12, Ethernet0 > C 192.168.10.0/24 is directly connected, Loopback0 > R 192.168.40.0/24 [120/5] via 192.168.1.2, 00:00:12, Ethernet0 > R 192.168.20.0/24 [120/1] via 192.168.1.2, 00:00:12, Ethernet0 > C 192.168.1.0/24 is directly connected, Ethernet0 > > Now before leaping to conclusions about the nature of split horizon, I did a > sanity check using OSPF. Interesting difference: > > Router_1#ir > > R 192.168.30.0/24 [120/5] via 192.168.1.2, 00:00:14, Ethernet0 > C 192.168.10.0/24 is directly connected, Loopback0 > R 192.168.40.0/24 [120/5] via 192.168.1.2, 00:00:14, Ethernet0 > R 192.168.20.0/24 [120/1] via 192.168.1.2, 00:00:14, Ethernet0 > C 192.168.1.0/24 is directly connected, Ethernet0 > > no problem here. so let's try the last sanity check, using EIGRP: > > Router_2# > 02:16:18: %SYS-5-CONFIG_I: Configured from console by console > 02:16:28: RIP: sending v1 update to 255.255.255.255 via Ethernet0 > (192.168.1.2) > 02:16:28: RIP: build update entries > 02:16:28: network 192.168.20.0 metric 1 > 02:16:28: RIP: sending v1 update to 255.255.255.255 via Loopback0 > (192.168.20.1) > > 02:16:28: RIP: build update entries > 02:16:28: network 192.168.1.0 metric 1 > 02:16:28: network 192.168.10.0 metric 2 > 02:16:28: network 192.168.30.0 metric 5 > 02:16:28: network 192.168.40.0 metric 5 > 02:16:28: RIP: received v1 update from 192.168.1.1 on Ethernet0 > > Router_1#ir > > C 192.168.10.0/24 is directly connected, Loopback0 > R 192.168.20.0/24 [120/1] via 192.168.1.2, 00:00:09, Ethernet0 > C 192.168.1.0/24 is directly connected, Ethernet0 > > aha! no routes from R2 > > but when I disable split horizon on R2 > > Router_2(config)#int e 0 > Router_2(config-if)#no ip split > Router_2(config-if)#^Z > Router_2# > > then I see routes on R1: > > Router_1#ir > > R 192.168.30.0/24 [120/5] via 192.168.1.2, 00:00:24, Ethernet0 > C 192.168.10.0/24 is directly connected, Loopback0 > R 192.168.40.0/24 [120/5] via 192.168.1.2, 00:00:24, Ethernet0 > R 192.168.20.0/24 [120/1] via 192.168.1.2, 00:00:24, Ethernet0 > C 192.168.1.0/24 is directly connected, Ethernet0 > Router_1# > > Conclusion: there is something else here, beyond the obvious. buried within > the IOS code I would surmise there is a "split horizon" process, and if a > routing protocol is one that honors split horizon, then split horizon is > invoked, no matter what the source and destination protocols. make sense? > > Chuck Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=46150&t=46102 -------------------------------------------------- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
