From: Jongsoo.Kim@Intelsat.com
Date: Sat Mar 05 2005 - 12:38:04 GMT-3
Matt
http://www.cisco.com/en/US/partner/tech/tk365/technologies_q_and_a_item09186
a008012dac4.shtml#ten
I saw this url from another email. I think this has good job to explain
this.
This a copy from cisco
Q. Why are routes received from one neighbor on a point-to-multipoint
interface running EIGRP not propagated to another neighbor on the same
point-to-multipoint interface?
A. The split horizon rule prohibits a router from advertising a route
through an interface that the router itself is using to reach the
destination. To disable the split horizon behavior, use the no ip
split-horizon eigrp as-number interface command. Some important points to
remember about EIGRP split horizon are:
Split horizon behavior is turned on by default.
Changing the EIGRP split horizon setting on an interface resets all
adjacencies with EIGRP neighbors reachable over that interface.
Split horizon should only be disabled on a hub site in a hub-and-spoke
network.
Disabling split horizon on the spokes radically increases EIGRP memory
consumption on the hub router, as well as the amount of traffic generated on
the spoke routers.
EIGRP's split horizon behavior is not controlled or influenced by the ip
split-horizon command.
For more details on split horizon and poison reverse, refer to Split Horizon
and Poison Reverse. For more information on commands, refer to EIGRP
Commands.
The command is "ip split-horizon eigrp as-number"
Regards
Jongsoo
-----Original Message-----
From: Kim, Jongsoo
Sent: Saturday, March 05, 2005 9:54 AM
To: 'Matt White'
Cc: ccielab@groupstudy.com
Subject: RE: ip split-horizon on frame-relay; link state protocols
Matt
You also need to put no ip split-horison on eigrp hub, otherwise it looks ok
to me.
Basically no split-horizon on rip and eigrp hub.
However, when you disable ip split-horizon, you have to be very careful
because spoke can learn its own route from Hub with high metric. So when you
do "clear ip route * " only on spoke not on hub to repopulate route table,
it can screw routing tablbe temperarily. But if you don't pay attnetion on
this, it can really get you in lab.
In most LAB, spoke has "directly connected rip route" so that even if it
learns its own routes from Hub, they can affect spoke's routing table as
direct connect will beat all the rip route. But in real life, ip
split-horizon is really good to be on even though nobody would ever use rip.
But good news( I ma not sure if it is good or bad news ^^) is in most CCIE
lab environment, the chance of Rip or EIGRP hub-and-spoke topology will be
very low. So the trick of ip split-h a lab writer is more toward physical
frame-relay interface using "poing-to-point" topology.
Regards
Jongsoo
-----Original Message-----
From: Matt White [mailto:mwhite23@gmail.com]
Sent: Friday, March 04, 2005 8:39 PM
To: Kim, Jongsoo
Cc: ccielab@groupstudy.com
Subject: Re: ip split-horizon on frame-relay; link state protocols
So... You're saying that for ALL frame-relay physical interfaces other
than a hub RIP router, you should enter "ip split-horizon"?
Would this configuration example look appropriate for this explaination?
!
Interface s0
Description EIGRP HUB
ip address 1.1.1.1 255.255.255.248
ip split-horizon
no ip eigrp 90 split-horizon
encapsulation frame-relay
!
Interface s1
Description RIP HUB
ip address 2.2.2.2 255.255.255.248
encapsulation frame-relay
!
Interface s2
Description EIGRP SPOKE
ip address 3.3.3.3 255.255.255.248
ip split-horizon
encapsulation frame-relay
!
Interface s3
Description RIP SPOKE
ip address 4.4.4.4 255.255.255.248
ip split-horizon
encapsulation frame-relay
!
Interface s4
Description OSPF (or ISIS), any type
ip address 5.5.5.5 255.255.255.248
ip split-horizon
encapsulation frame-relay
router eigrp 90
no auto-summary
network 1.1.1.1 0.0.0.0
network 3.3.3.3 0.0.0.0
router rip
version 2
no auto-summary
passive-interface default
no passive-interface Serial1
no passive-interface Serial3
network 2.0.0.0
network 4.0.0.0
router ospf 1
network 5.5.5.5 0.0.0.0 area 0
This question, as far as being "right or wrong" is driving me crazy.
Thank you for any additional assistance.
MW
On Fri, 4 Mar 2005 16:32:09 -0500, Jongsoo.Kim@intelsat.com
<Jongsoo.Kim@intelsat.com> wrote:
> You are correct and this was one painful and stupid mistake I always did
in
> IGP.
>
> I am not sure what you mean by a stub rip, but it should be on all active
> rip interfaces except Hub interface in hub and spoke topology.
> Same for eigrp. But as you said, I will also turn on for OSPF or ISIS
> protocols.
>
> In my opinion, rip is very hard topic in igp because it has a lot of
tricks
> a lab writer love to use such as split-horizon, v1 and v2,
> multicast,broadcast,and unicast, auto-summary, passive interface, the fact
> that it doesn't require neighbor adjacency, and so on.
>
> Regards
>
> Jongsoo
>
>
> -----Original Message-----
> From: Matt White [mailto:mwhite23@gmail.com]
> Sent: Friday, 04 March, 2005 3:41 PM
> To: Group Study
> Subject: ip split-horizon on frame-relay; link state protocols
>
> Let's say I have encapsulation frame-relay on a physical serial
> interface, ip split-horizon becomes automatically disabled. If I
> assign an IP address and apply this to an OSPF process, would it be
> considered best practice to re-enable split-horizon?
>
> I understand the split-horizon has nothing to do with a link state
> protocol like OSPF, but would this hurt/help in any specific
> situations?
>
> I believe it IS considered best-practice to do this on a stub RIP
> frame-relay physical interface, correct?
>
> Thanks for you help guys.
>
> _______________________________________________________________________
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html
>
> ############################################################
>
> Building on 40 Years of Leadership - As a global communications leader
with 40 years of experience, Intelsat helps service providers,
> broadcasters, corporations and governments deliver information and
entertainment anywhere in the world, instantly, securely and reliably.
>
> ############################################################
> This email message is for the sole use of the intended
> recipient(s) and may contain confidential and privileged
> information. Any unauthorized review, use, disclosure or
> distribution is prohibited. If you are not the intended
> recipient, please contact the sender by reply email and
> destroy all copies of the original message. Any views
> expressed in this message are those of the individual
> sender, except where the sender specifically states them
> to be the views of Intelsat, Ltd. and its subsidiaries.
> ############################################################
>
############################################################
Building on 40 Years of Leadership - As a global communications leader with 40 years of experience, Intelsat helps service providers,
broadcasters, corporations and governments deliver information and entertainment anywhere in the world, instantly, securely and reliably.
############################################################
This email message is for the sole use of the intended
recipient(s) and may contain confidential and privileged
information. Any unauthorized review, use, disclosure or
distribution is prohibited. If you are not the intended
recipient, please contact the sender by reply email and
destroy all copies of the original message. Any views
expressed in this message are those of the individual
sender, except where the sender specifically states them
to be the views of Intelsat, Ltd. and its subsidiaries.
############################################################
This archive was generated by hypermail 2.1.4 : Sun Apr 03 2005 - 17:56:41 GMT-3