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.
>> 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
The simple answer would be the following:
1- In EBGP: the manadatory attributes carried in each ebgp updates are:
2- In IBGP: the manadatory attributes carried in each IBGP updates are:
please refer to the bellow link for further information:
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.
LOCAL_PREF/see Section 5.1.5/required
ATOMIC_AGGREGATE/see Section 5.1.6 and 9.1.4
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.
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 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.
>> 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.
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
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.
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:
if you follow the link to multihop command reference
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
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
Also note that if the BGP authors actually defined a BGP field similar to a "hop count", it would require all routers on the route between any two BGP peers to be able to understand this field and decrement it. That would basically necessitate a Layer7 inspection on all routers. It would be quite impossible to maintain this requirement.
But anyway, we have reached an interesting point here - everybody takes for granted that by default, in EBGP, the TTL 1 is used. However, it is not mandated in any documents I have been able to find. Is this just a best implementor's practice? You have mentioned that I have probably found a grey part in the related BGP. Well, I must say I am not particularily happy about it :)
Thank you for your answer. I have seen the GTSM RFCs 3682 and 5082 but there are two issues here:
1.) The GTSM RFCs talk about setting TTL to 255, not to 1.
2.) The BGP RFCs do not mention using the GTSM at all, nor do they reference the GTSM RFCs.
So I am afraid the GTSM is not the answer here why the TTL in EBGP sessions is set to 1.
RFC 4274 (INFORMATIONAL)
BGP uses the IP TTL value to protect its External BGP (EBGP) sessions from any TCP- or IP-based CPU-intensive attacks. It is a simple mechanism that suggests the use of filtering BGP (TCP) segments, using the IP TTL value carried within the IP header of BGP (TCP) segments that are exchanged between the EBGP sessions. The BGP TTL mechanism is described in [RFC3682]. Usage of [RFC3682] impacts performance in a similar way as using any access control list (ACL) policies for BGP.
TTL=1 is ALWAYS processed by CPU (punted), which is important on hardware-forwarding platforms, and therefore will be decremented to 0, discarded and trigger ICMP Destination Unreachable. That eliminates the needs in additional ACLs required by GTSM.
Thank you for your response. Unfortunately, it seems that we are moving in circles here. The actual RFC where the current BGP is described is the RFC 4271. That RFC alone does not discuss or reference any of the GTSM RFC, nor it directly mentions any special handling of eBGP sessions.
The informational RFC 4274 you have pointed out here talks about using the GTSM. The GTSM is not about TTL=1, on the contrary, it mandates using the TTL=255. Moreover, the ACL that the GTSM RFC 3682 talks about, is only conceptual, and the updated RFC 5082 ceased completely from referencing any ACL.
I am well aware of the consequences of TTL=1. What I am saying here is that it using the TTL=1 in eBGP sessions seems to be supported only by some sort of tradition but not by relevant RFCs.