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=46102&t=46102
--------------------------------------------------
FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html
Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
