Multihop in iBGP

[chetanmahendroo]

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

[chetanmahendroo]

Thank you Mr. Giuseppe,

You have made concept more clear.

[Peter Paluch]

Giuseppe,

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 :)

Best regards,

Peter

[bilousand]

It is a "security" feature described in RFC 5082 (most recent).

http://www.rfc-editor.org/rfc/rfc5082.txt

[Peter Paluch]

Hello,

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.

Best regards,

Peter

[bilousand]

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.

[Peter Paluch]

Hi Andriy,

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.

Best regards,

Peter