I think the more appropriate observation is that split horizon is not protocol specific, but interface specific IF there are more than one DV's in operation on the interface.
If split horizon were protocol specific, then a route received via one DV protocol could still be advertised out the same interface by another DV protocol. Since OSPF is NOT a DV protocol, the learning of routes on a particular interface does NOT prohibit a DV from advertising that route out the same interface. I thought it an interesting little twist. It had never occurred to me before that split horizon was protocol independent. chalk up another one to experience. Chuck ""Jay"" wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... > 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=46176&t=46102 -------------------------------------------------- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
