Chuck,
I did a search on CCO and found a few links which state the
following..
http://www.cisco.com/univercd/cc/td/doc/product/software/ios121/121cgcr/ip_c
/ipcprt2/1cdigrp.htm
watch the line wrap.
Normally, routers that are connected to broadcast-type IP networks and that
use distance-vector routing protocols employ the split horizon mechanism to
reduce the possibility of routing loops. Split horizon blocks information
about routes from being advertised by a router out of any interface from
which that information originated. This behavior usually optimizes
communications among multiple routers, particularly when links are broken.
However, with nonbroadcast networks (such as Frame Relay and Switched
Multimegabit Data Service [SMDS]), situations can arise for which this
behavior is less than ideal. For these situations, you might want to disable
split horizon.
Split horizon for Frame Relay and SMDS encapsulation is disabled by default.
Split horizon is not disabled by default for interfaces using any of the
X.25 encapsulations. For all other encapsulations, split horizon is enabled
by default.
http://www.cisco.com/univercd/cc/td/doc/product/software/ios121/121cgcr/ip_c
/ipcprt2/1cdeigrp.htm
By default, split horizon is enabled on all interfaces.
So Chuck as you mentioned split-horizon is implemented IOS-wide by default
on all interfaces with some exceptions as noted above. It seems that with
the default implementation of split-horizon, once a DV-based
protocol/process (as you mentioned) is configured on the device, the
protocol and process adheres to the rules of the split-horizon mechanism
versus being invoked.
HTH
Nigel
----- Original Message -----
From: "Chuck"
To:
Sent: Saturday, June 08, 2002 2:37 AM
Subject: Split horizon behaviour - explain me this one! [7:46102]
> 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=46103&t=46102
--------------------------------------------------
FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html
Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
