From: Jongsoo.Kim@Intelsat.com
Date: Sat Mar 05 2005 - 16:03:08 GMT-3
I agree. And I missed that
By the way,
In your config below, I am just wondering how you can get "no ip eigrp 90
split-horizon".
because I saw in ios command, "no ip split-horizon eigrp..."
> 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
Regards
Jongsoo
-----Original Message-----
From: Matt White [mailto:mwhite23@gmail.com]
Sent: Saturday, March 05, 2005 1:55 PM
To: Kim, Jongsoo
Cc: ccielab@groupstudy.com
Subject: Re: ip split-horizon on frame-relay; link state protocols
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.
> ############################################################
>
############################################################
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