7

BGP message length in of 2 bytes. So why can't the max bgp message size be 65535 ? why is it 4096 ?

1
  • Did any answer help you? if so, you should accept the answer so that the question doesn't keep popping up forever, looking for an answer. Alternatively, you could post and accept your own answer.
    – Ron Maupin
    Jan 3 at 21:51
14

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

0

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.