cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
24326
Views
34
Helpful
20
Replies

Multihop in iBGP

chetanmahendroo
Level 1
Level 1

Experts,

This may sound a dumb question, but since i am not able to find it documented anywhere, can somebody provide any link/document regarding:

Why multihop is not required in iBGP session ?

Thanks

20 Replies 20

Peter Paluch
Cisco Employee
Cisco Employee

Hello,

Hey, it's absolutely not a dumb question :)

The fact that the iBGP does not require multihop is given intentionally by the BGP design. Within an autonomous system, you should not (and often cannot) require that all pairs of iBGP speakers are directly connected. Such requirement would pose very strict demands on the physical topology. Recall that the iBGP speakers must either be fully meshed or a route-reflector must be used. Note that if even iBGP peers were required to be directly connected, then for a full mesh of iBGP speakers, each two would have to be directly connected, ultimately leading to a linear topology of a single multiaccess segment (e.g. an Ethernet switch) with all BGP speakers connected to it. Also, it would effectively prevent you from using Loopback interfaces when peering BGP speakers, or from using route reflectors. Moreover, the BGP expects that the internal routing within an autonomous system is already solved by IGP protocols. In other words, the BGP is not responsible for routing inside the autonomous system, rather, it makes use of it when establishing the iBGP sessions.

So within an autonomous system, it is necessary that the iBGP does not require the multihop feature to run. It would not bring any advantages or additional positive features with it - on the contrary, it would be a useless burden. For iBGP, it simply does not make sense.

The eBGP is a different stuff. Routing between two different autonomous systems should be provided by eBGP alone. That is why the eBGP requires that the BGP speakers are directly connected. Of course, even this requirement is sometimes difficult to meet, therefore the ebgp-multihop feature is introduced. However, note that for ebgp-multihop to work, you have to somehow add the route to the distant eBGP peer on your router - you will probably do it manually - which breaks the original design intention that the routes into a different autonomous system must be discovered using the eBGP alone. Therefore, even with eBGP, the ebgp-multihop feature should be used only when absolutely necessary.

Best regards,

Peter

Giuseppe Larosa
Hall of Fame
Hall of Fame

Hello Chetan,

>> Why multihop is not required in iBGP session ?

because usually iBGP sessions use loopback ip addresses that are not directly connected and cannot be.

the BGP open message in the case of iBGP uses a TTL=255 and a TTL=1 for eBGP session.

Hope to help

Giuseppe

Mohamed Sobair
Level 7
Level 7

Hi,

The simple answer would be the following:

1- In EBGP: the manadatory attributes carried in each ebgp updates are:

a- As-path

b- next-hop

c- origin

2- In IBGP: the manadatory attributes carried in each IBGP updates are:

a- As-path

b- Local-prefrence

c- Origin

please refer to the bellow link for further information:

http://www.cisco.com/en/US/tech/tk365/technologies_tech_note09186a00800c95bb.shtml

HTH

Mohamed

Hello Mohamed,

I am sorry but I do not agree with your description here.

A mandatory attribute must be present on every BGP-advertised prefix without regards to eBGP or iBGP. The RFC 4271 is quite clear about this (a direct quotation from the Section 5 of the RFC 4271 follows):

The mandatory category refers to an attribute that MUST be present in both IBGP and EBGP exchanges if NLRI are contained in the UPDATE message. Attributes classified as optional for the purpose of the protocol extension mechanism may be purely discretionary, discretionary, required, or disallowed in certain contexts.

attribute/EBGP/IBGP

ORIGIN/mandatory/mandatory

AS_PATH/mandatory/mandatory

NEXT_HOP/mandatory/mandatory

MULTI_EXIT_DISC/discretionary/discretionary

LOCAL_PREF/see Section 5.1.5/required

ATOMIC_AGGREGATE/see Section 5.1.6 and 9.1.4

AGGREGATOR/discretionary/discretionary

As you can see, the local preference is not a mandatory attribute, rather, it is described only as a required attribute that SHALL but does not need to be included in the iBGP messages. On the other hand, the Origin, AS-Path and Next-Hop attributes must always be present.

Perhaps you wanted to say that the Next-Hop attribute is not modified when a route is advertised in iBGP but that would not answer the original question.

Best regards,

Peter

Experts,

As usual and as expected, perfect explanation and knowledge sharing, so rated accordingly.

Mr. Giuseppe as stated by you >>>> the BGP open message in the case of iBGP uses a TTL=255 and a TTL=1 for eBGP session.

I also have same understanding but not able to find this statement documented anywhere.

If anyone can refer a doc, where it is visible, will be of great help .

Thanks

Mohamed Sobair
Level 7
Level 7

Hi Peter,

I was mistaken, I refered to RFC 4271, and yes you are correct.

Thanks for the useful information,

Regards,

Mohamed

Chetan,

Here is a document confirming Giuslar's comment on TTLs with captures:

http://www.cciezone.com/?p=170

HTH

Reza

Hi,

Thanks for the link but Chetan has pointed out an interesting issue. We all take for granted that the eBGP sessions use TTL 1 by default. But I have crawled over the RFC 4271 where the current BGP version is described and it contains absolutely no discussion about the TTL. In other words, this behavior is not mandated by the RFC. I wonder now where the entire idea of TTL 1 comes from.

Best regards,

Peter

Hello Peter,

>> I wonder now where the entire idea of TTL 1 comes from

otherwise what would be the effect of ebgp-multihop x ?

what parameter allows to limit the travel of an IP packet to a single hop?

there is a BGP field that is called hop count ?

the simplest way is to implement this using ipv4 TTL on the header.

EDit:

sorry for the tone of this post that looks like aggressive, however using IPV4 header TTL is the simplest way to do this.

Hope to help

Giuseppe

Giuseppe,

Let me rephrase my question: The EBGP behaves in a special way - it sets the IP TTL value to 1. However, the RFC 4271 does not require it. As a matter of fact, the entire RFC 4271 does not mention the TTL at all. My question therefore is: Is this behavior a standardized behavior mandated by some document like RFC, or is this just an implementation issue that may vary from one vendor to another?

I understand completely that the IP TTL is the simplest and at the same time the only way to do this. But I am not asking how is it done, rather, I am asking what specification requires the BGP to behave that way. You surely understand that if this behavior is not mandated by the BGP-related RFCs, it is completely implementation-dependent and we might be talking here about Cisco-specific implementation and not about a universal BGP characteristic.

Best regards,

Peter

Hi Peter,

You bring up a very good point that this may be a Cisco-specific implementation and not based on RFC 4271, because for example on Juniper routers you do not configure the TTL at all. Looking at Juniper documentation the default for their boxes is actually 255 not 1. Here is the link to the documentation:

http://www.juniper.net/techpubs/software/junos/junos70/swconfig70-routing/html/bgp-config32.html

Thanks,

Reza

Hello Reza,

if you follow the link to multihop command reference

http://www.juniper.net/techpubs/software/junos/junos70/swconfig70-routing/html/bgp-summary30.html#1014703

it says:

If you omit this statement, all EBGP peers are assumed to be directly connected (that is, you are establishing a nonmultihop, or "regular", BGP session), and the default time-to-live (TTL) value is 1.

so also Juniper has a default TTL=1 for eBGP sessions

I think Peter has found a grey zone in BGP RFCs where actually this aspect is not specified and I agree on this both new RFC and old 1771 doesn't say in an explicit way how the directly connected in eBGP is implemented.

Hope to help

Giuseppe

Here you go Mr Peter, Where does this TTL idea in BGP come from ?

You have caught my thought.

Hello Chetan,

being BGP based on TCP there is also an IPv4 header carrying the TCP segment that contains the BGP message.

So BGP designers instead of introducing a router hop field in BGP messages to limit their reach they (designers)decided to rely on IPv4 header.

I agree that an explicit sentence telling this would be wellcome but RFCs don't contain the sentence.

They just say BGP is based on TCP port 179 and leave all the collateral effects unexpressed.

As you can see both Cisco and Juniper defaults to TTL=1 for eBGP sessions.

Hope to help

Giuseppe

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: