From: Matt White (mwhite23@gmail.com)
Date: Sat Mar 05 2005 - 15:55:02 GMT-3
Wouldn't "no ip split-horizon" on the eigrp hub be turned on by
default anyway and therefore not show up in the config? IGRP/RIP and
EIGRP split-horizons are different things altogether to my knowledge.
It still remains a frame-realy physical interface...
Thank you again.
On Sat, 5 Mar 2005 09:53:45 -0500, Jongsoo.Kim@intelsat.com
<Jongsoo.Kim@intelsat.com> wrote:
> 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