Cisco Support Community
Showing results for 
Search instead for 
Did you mean: 

Welcome to Cisco Support Community. We would love to have your feedback.

For an introduction to the new site, click here. And see here for current known issues.

New Member

Why we need BGP Split Horizon Rule?

Dear All,

I have read this statement "When a BGP speaker receives an UPDATE message from an internal  peer, the receiving BGP speaker shall not re-distribute the routing  information contained in that UPDATE message to other internal peers. This is split horizon rule use within AS to prevent loops" about bgp in lots of books and articles but didn't find any explanation of it.

With all default settings if we did not use Split horizon rule, how it will cause loops?

Everyone's tags (3)
Hall of Fame Super Silver

Re: Why we need BGP Split Horizon Rule?

Hello Behzad,

the issue is originated by the fact that in iBGP sessions the AS path attribute is not modified when propagating an advertisement to another iBGP peer. Actually only when sending the advertisement to an eBGP peer the AS number of the BGP speaker is added to the AS path attribute (in first position).

This behaviour has the potential for loops in the propagation of the advertisement that can travel among several iBGP peers and could be sent back to the original node that injected the route in the AS.

The real problem arises if the originator node withdraws the BGP advertisement, in absence of control mechanisms the node could be fooled by a copy of advertisement received by another node and re-advertise the just withdrawed IP prefix.

As a result in the AS there would still be present an advertisement for a prefix that is not existing anymore.

For this reason an iBGP speaker cannot propagate advertisements received by an iBGP peer RX to any other iBGP peer.

This mechanism is built  in BGP and cannot be disabled for the reasons explained above.

The most important consequence is the requirement for a full mesh of iBGP sessions that leads to scalability problems, because given N iBGP nodes N*(N-1)/2

iBGP sessions would be required.

In order to avoid the full mesh scalability problems two different methods (that might be combined) have been developed.

Both methods allow for relaxing iBGP split horizon rule by adding other BGP attributes to keep track of history of advertisement within the AS.

BGP Route Reflectors:  these special nodes act as route servers by reflecting advertisements received by client nodes (as defined on RR side only).

Reflection is safe because the RR adds two attributes to the advertisement :

- BGP originator-id contains the 4 byte BGP router-id of the node that has injected the prefix into the AS

- BGP cluster-list contains an ordered list of route reflection, The list is formed by RR BGP router-ids and/or by cluster-ids. (a cluster-id is a sort of identifier to be used when two or more RRS serve the same set of client nodes).

These two new attributes allow for safe propagation of routes within the AS:

all RRS need to be in full mesh between themselves, but most of nodes in the AS don't need anymore a direct session. This solves the scalability issue.

When an advertisement is received the two attributes are checked:

BGP originator-id allows to the node that has the BGP router-id = BGP originator-id to ignore the advertisement

BGP cluster list allows to a RRS to ignore an advertisement if the cluster list already contains its own cluster-id (that might be equal to its own BGP router-id if a cluster id is not set explicitly in RRS BGP configuration)

The second method to overcome scalability issues is the use of BGP confederations:

in this case the AS is divided in several mini AS each with its own private AS number.

These private AS numbers of mini AS are used to build  the Confed AS path attribute that allows to use EBGP rules for loop avoidance. This attribute is separate from main AS path attribute and when a node has a true eBGP session with a router in outer world the following happens:

the Confed AS attribute is removed

the main AS attribute is modified adding the ufficial AS number in front (leftmost /first position) before sending to true eBGP peers.

Within each mini AS Route reflection  could be use combining the two methods.

This second method requires configuration changes in all nodes in the AS. RR requires changes only on devices acting as RR servers.

So in most cases the first method is deployed.

Hope to help


Cisco Employee

Why we need BGP Split Horizon Rule?


You beat me to it!

Best regards,


Cisco Employee

Why we need BGP Split Horizon Rule?


Between autonomous systems, BGP uses the AS_PATH attribute to avoid routing loops - a route will not be accepted if the AS_PATH contains the AS number of the router that receives it.

However, within an autonomous system, the AS_PATH attribute is not changed - it is not prepended to, so a router may not be sure whether it is processing a new route advertisement or whether this route advertisement already traversed it and just got advertised back. Accepting such a route would create a routing loop, as you would be trusting an information that you previously advertised yourself and that traces back to you.

In default settings, a routing loop is somewhat hard to concoct but think of a slightly modified scenario. Think three routers, A, B and C. Router A will learn about a route X from an external peer and advertise it to B but not to router C (perhaps because of some output filtering towards router C). Now, without BGP split horizon rule, this route can get advertised from B to C and from C to A. If router A is otherwise configured to prefer routes from router C, it would change the next hop towards X from the external peer to router C, and thereby form a routing loop, as C points back to B, B points back to A and A points back to C.

Best regards,


CreatePlease login to create content