iBGP update TTL

[manish.gautam]

how does ibgp peer know that a received update from a ibgp peer is not to be forwarded to another ibgp peer? is there any role of TTL, is so please explain?

[Giuseppe Larosa]

Hello Manish,

this is the iBGP split horizon rule:

doesn't forward to an iBGP peer what you have learned from another iBGP peer.

There is no TTL here.

The reasons are that AS path attribute is not updated within a single AS anatomy and so there is no way to detect loops and other possible problems.

From this comes the full mesh requirement for iBGP.

Scalability solutions include:

BGP route reflector servers

and/or

BGP confederations

the first adds two attribute:

Originator-ID BGP router-id of iBGP peer that injected the advertisement

Cluster-list : history of iBGP reflections

BGP confedrations uses an additional AS path attribute where the mini-AS numbers are recorded in order to prevent loops.

Main AS attribute is left unchanged so that it can be sent to true eBGP peers with the only addition of the public BGP AS number

in this way with this additional info iBGP updates can be propagated safely inside an AS.

Hope to help

Giuseppe

[manish.gautam]

Hi

thanks for your reply, i know the ibgp rule but would like to understand what field in the update packet makes a bgp speaking router know that it should not forward this update to another ibgp peer

[Richard Burts]

Manish

The router looks at the address of the neighbor who sent the BGP advertisement and from the address of the neighbor it knows the AS number of the neighbor. If the AS number of the neighbor is the same as the AS number of the router receiving the update then it is IBGP and the router should not forward the update.

While the update packet does have a TTL, the decision about whether to forward or not does not consider the TTL.

HTH

Rick

[Giuseppe Larosa]

Hello Manish,

a router keeps track of what advertisements are received by each of its peer.

That is the input RIB.

In building the updates for another iBGP peer all advertisements learned from another iBGP peer are filtered, unless there is a scenario with BGP route reflectors as explained in my first post.

There is no single field in the update message by itself that tells this: in the open message the two devices agree on building an iBGP session because the AS number is the same.

So peers are classified as iBGP peers or eBGP peers when the session is established.

It is built in in the logic of iBGP not an attribute in the update for the possible lack of information that could lead to routing loops (without the additional attributes used by BGP route reflectors or by BGP confederations)

Hope to help

Giuseppe