Re: Split Horizon

Hi Ivan,

I like picky! And I like your example too. There's an illustrated
example (using OSPF redistribution into RIP vs. static) of split-
horizon and next-hop IP in the second edition of the R&S Cert Guide
(the graphic is found on page 213, the discussion begins on page
219). Since RIP was de-emphasized in v3.0 of the Cert Guide (and
thus presumably the written itself), this gets only a passing mention
in the latest version of the book and won't be of much value for the
purposes of this thread.

I got to thinking about your post after reading it on a recent flight
and perhaps the issue here, in the case of RIP anyway, is v1 vs. v2.
There wasn't any concept of advertising next-hop in the former; it was
introduced in the latter. So I suppose the old explanation of not
advertising back out a receiving interface has its roots in v1 and
seems to have been accurate enough in its day. The logic of RIP split-
horizon needed to be updated with the advent of next-hop support,
though, and so now your explanation is the far more precise one. I'd
put together a lab topology to explore/illustrate the nuance but I'm
working a billable project today instead. ;~)

Interestingly, I stumbled across yet another use of the term "split-
horizon" today while doing some research for a client (you may well be
right about this being the most overused term in networking
Anthony!). It relates to a VPLS full mesh of pseudowires in an SP
core and avoiding the need for a spanning-tree instance. Here's the
quote, followed by the link for anyone interested:

"To reduce the complexity of the VPLS architecture, [lasserre]
describes a flat architecture whereby all VSIs that are associated
with a single multipoint L2VPN are interconnected using a full mesh of
MPLS VCs as shown in Figure 4. As all VSIs are interconnected in a
full mesh, [lasserre] avoided implementing a spanning tree by using a
technique known as split horizon forwarding. Split horizon forwarding
is a frame forwarding technique that prevents packets looping by
simply not transmitting a frame back out of the interface the frame
was received upon. In the case of [lasserre] if a frame is received on
a PW, the frame cannot be forwarded on any other PW associated with a
particular VSI as shown in Figure 5. The concept of split horizon
forwarding is well-known with routing protocols such as RIP and IGRP,
and is important to understand with respect to VPLS as it is reused
within other drafts, including [VPLS-LDP]."

http://www.cisco.com/en/US/tech/tk436/tk891/technologies_white_paper09186a00801f6084.shtml

Cheers all,

Scott

On Apr 23, 2009, at 5:23 , Ivan Walker wrote:

> Being a little picky I believe that the concept found in most
> discussions
> is that a routing update received in an interface is not advertised
> back
> out that same interface.
>
> The implementation as far as I understand does not keep track of what
> interface an update comes in. Rather the next-hop is used - the
> update is
> not sent out an interface used to reach the next hop. Try
> redistributing
> a static route with a next hop out a rip enabled interface into rip-
> the
> redistributed static route won't be advertised out the interface
> used to
> reach the next hop even though technically the route was not
> received in
> that interface.
>
> Ivan
>
>> R.B,
>>
>> I would just clean that up a little and replace "packet" with
>> "destination" or something along that line.
>>
>> People sometimes (recently) use this in iBGP discussions, which I
>> believe to be a slightly improper application of the term. The full
>> mesh/synchronization requirement has as much if not more to do with
>> serving as an anti-blackholing mechanism vs. preventing loops from
>> forming. And even to the extent that it does prevent loops, it does
>> so slightly differently as contrasted to, say, RIP split-horizon, so
>> this is not a term that I personally use in the context of BGP.
>> Others do, though, and so this is probably one context worth making
>> note of.
>>
>> The term has also been borrowed for split-horizon DNS and so forth.
>> But it generally infers a behavior where otherwise flooded
>> information
>> is not reflected back towards its point of origin relative to any
>> given point in a topology.
>>
>> What was the catalyst for your question?
>>
>> Regards,
>>
>> Scott
>>
>>
>>
>> On Apr 23, 2009, at 7:03 , Robin Betterley wrote:
>>
>>> Hi GS,
>>>
>>> The basic principle is simple: Information about the routing for a
>>> particular packet is never sent back in the direction from which it
>>> was received.
>>>
>>> Is there any other known principle of split horizon?
>>>
>>> Cheers,
>>> R.B
>>>
>>>
>>> Blogs and organic groups at http://www.ccie.net
>>>
>>> _______________________________________________________________________
>>> Subscription information may be found at:
>>> http://www.groupstudy.com/list/CCIELab.html
>>
>>
>> Blogs and organic groups at http://www.ccie.net
>>
>> _______________________________________________________________________
>> Subscription information may be found at:
>> http://www.groupstudy.com/list/CCIELab.html
>
>
> Blogs and organic groups at http://www.ccie.net
>
> _______________________________________________________________________
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html

Blogs and organic groups at http://www.ccie.net
Received on Sat May 02 2009 - 12:45:08 ART