From: tan (tan@dia.janis.or.jp)
Date: Mon Feb 24 2003 - 22:25:49 GMT-3
While when unwrapping a packet and sending upwards, first signs of an ospf
update come a whole layer ahead of first signs of rip, and still another
layer ahead of bgp, which one could then say ospf is layer x and bgp is
layer y. But trying to pigeon-hole split horizon based on this categorizes
the SplitH concept mistakenly I feel. Split horizon comes under interface
configuration and should be understood on a protocol by protocol basis.
Eigrp has its own command because I guess Cisco wanted eigrp to behave
independently of igrp and rip. IGRP and RIP share the same command because
IOS was programmed that way, not because both are DV protocols and share
some similar processing flowchart at egress. On the contrary, what routes
"no split horizon" command will allow to be sent on rip and igrp can
actually differ, (but where I have seen this was an extremely manipulated
scenario, with unresolvable route entries generated on purpose), the point
being the on/off switch for split horizon shares the same command, but the
processing is protocol specific.
For BGP, I recall an old post that JUNOS will send a bgp packet backwards
toward where it came and rely on as_path rule on other side to stop it at
ingress, whereas IOS simply does not send it at all. This behaivor is the
source of original poster's question I think, no? Sounds like a coding issue
and can you turn it off? I doubt it. Maybe Howard knows.
> -----Original Message-----
> From: nobody@groupstudy.com [mailto:nobody@groupstudy.com]On Behalf Of
> Jerry Haverkos
> Sent: Tuesday, February 25, 2003 7:21 AM
> To: Howard C. Berkowitz; ccielab@groupstudy.com
> Subject: RE: split-horizon & BGP
>
>
> Howard
>
> I do not believe that the is a command to turn split-horizon on or off
> available for BGP, especially not one that works at layer 3.
> My point is
> that BGP does not run at the layer 2 or layer 3 or even layer
> 4 part of the
> stack. It is an application that exchanges data via an
> established BGP TCP
> session. It is an application to application (BGP peer to
> peer) decision not
> to send routes back to a peer that it received the routes from.)
>
> I do not believe that it has anything to do with the
> traditional idea that
> split horizon does not allow updates, received over an
> interface, to be sent
> back over that interface. ;)
>
> -----Original Message-----
> From: nobody@groupstudy.com [mailto:nobody@groupstudy.com]On Behalf Of
> Howard C. Berkowitz
> Sent: Monday, February 24, 2003 3:13 PM
> To: ccielab@groupstudy.com
> Subject: RE: split-horizon & BGP
>
>
> At 12:30 PM -0500 2/24/03, OhioHondo wrote:
> >Since BGP runs as a higher layer protocol (on top of TCP)
> split horizon
> does
> >not apply.
>
> Why do you think TCP would make a difference in loop detection?
>
> BGP is not strictly a DV protocol. Its primary loop detection method
> is examining incoming AS paths (i.e., path vectors) and rejecting
> those that contain the local AS number.
>
> There are additional methods, for iBGP using confederations and RR's,
> to reduce/eliminate transient internal loops/oscillation, but these
> are probably outside the CCIE scope.
>
> It isn't completely clean, as BGP/PV is provably loop-free only when
> additional policies are NOT used.
>
> >
> >-----Original Message-----
> >From: nobody@groupstudy.com [mailto:nobody@groupstudy.com]On
> Behalf Of
> >Pedro Eira
> >Sent: Monday, February 24, 2003 10:36 AM
> >To: ccielab@groupstudy.com
> >Subject: split-horizon & BGP
> >
> >
> >Hello, Would split-horizon have any effect on BGP?Should I follow the
> >same rules for BGP as I do for other DV routing protocols when
> >split-horizon is involved?
This archive was generated by hypermail 2.1.4 : Sat Mar 01 2003 - 11:06:34 GMT-3