BGP message length in of 2 bytes. So why can't the max bgp message size be 65535 ? why is it 4096 ?
2 Answers
BGP message length in of 2 bytes. So why can't the max bgp message size be 65535? why is it 4096?
Official Answer
Quoting Tony Li when he responded to this question on the IDR List:
1a) Having a fixed size is good because it makes the protocol implementations easy. There is no point to having complexity in an implementation if it provides no benefit. Large messages don't provide a wonderful benefit, as they need to be large enough to carry the path attributes and associated prefixes. For this purpose 4k is probably adequate to date.
1b) Historically, 4k was considered a bit wasteful. Of course, it was wonderfully simple compared to EGP which used fragmented packets. Care to parse a 16k jumbo-gram? Care to debug that? Trust me, it's not fun.
2) The 4k message size is completely independent of the TCP window size. An implementation is perfectly free to compose any number of messages, each of which is within the 4k limit. The implementation can then cram any number of messages into its TCP socket, up to the buffering limits of that TCP.
2a) Thus, the message size is NOT performance limiting, except when an implementation could actually overfill a message. Folks maintaining current implementations might chime in here as to whether or not they see this.
So, in summary, yes, a 4k message size limit is a fine situation for BGP, for the way that it behaves and the job that it does. This does NOT necessarily generalize to other protocols, (e.g. OSPF) where 4k exceeds the most common MTUs. In those cases, you'd end up with fragmentation, and that's bad.
Other thoughts
65536 / 4096 = 16
Do we really want BGP's transient RAM requirements to multiply by 16? Remember that under the covers, many BGP implementations are written in C, which means BGP could need to malloc
space for every message to the maximum message size.
Obligatory rhetorical questions...
- Why do we have any variable size limits in software?
- Why isn't every C integer a
long long
?
Let's assume we have 100,000 BGP prefixes with 15,000 unique attribute combinations; let's also assume our BGP implementation packs the prefixes into BGP UPDATE
messages with 100% efficiency. Therefore we need 15,000 BGP UPDATE
messages.
15000 messages * 4096 bytes/message = 58MB of aggregate BGP message buffering used
15000 messages * 65536 bytes/message = 937MB of aggregate BGP message buffering used

- 29,876
- 11
- 78
- 152
Because RFC4271 says so? The limit was present in BGP 3 as well. Given the small internet at the time when BGP was created on legendary napkin, I'd say it was choosen exactly the way number of bits in IPv4 was.

- 4,030
- 15
- 24