Warum wird die maximale BGP-Nachrichtengröße als 4096 ausgewählt? warum nicht 2 ^ 16?

BGP-Nachrichtenlänge in 2 Bytes. Warum kann die maximale BGP-Nachrichtengröße nicht 65535 betragen? warum ist es 4096?

BGP-Nachrichtenlänge in 2 Bytes. Warum kann die maximale BGP-Nachrichtengröße nicht 65535 betragen? warum ist es 4096?

Offizielle Antwort

Zitat von Tony Li, als er auf diese Frage in der IDR-Liste antwortete :

1a) Eine feste Größe ist gut, da dies die Protokollimplementierung erleichtert. Es macht keinen Sinn, eine Implementierung komplex zu gestalten, wenn sie keinen Nutzen bringt. Große Nachrichten bieten keinen wunderbaren Vorteil, da sie groß genug sein müssen, um die Pfadattribute und die zugehörigen Präfixe zu tragen. Zu diesem Zweck ist 4k bisher wahrscheinlich ausreichend.

1b) Historisch gesehen wurde 4k als etwas verschwenderisch angesehen. Natürlich war es im Vergleich zu EGP, das fragmentierte Pakete verwendete, wunderbar einfach. Möchten Sie ein 16k-Jumbo-Gramm analysieren? Möchtest du das debuggen? Vertrau mir, es macht keinen Spaß.

2) Die 4k-Nachrichtengröße ist völlig unabhängig von der TCP-Fenstergröße. Eine Implementierung ist völlig frei, um eine beliebige Anzahl von Nachrichten zu verfassen, von denen jede innerhalb der 4k-Grenze liegt. Die Implementierung kann dann eine beliebige Anzahl von Nachrichten in ihren TCP-Socket bis zu den Puffergrenzen dieses TCP packen.

2a) Somit ist die Nachrichtengröße NICHT leistungsbegrenzend, außer wenn eine Implementierung eine Nachricht tatsächlich überfüllen könnte. Leute, die aktuelle Implementierungen beibehalten, können sich hier melden, ob sie dies sehen oder nicht.

Zusammenfassend lässt sich sagen, dass eine Beschränkung der Nachrichtengröße auf 4 KB eine gute Situation für BGP ist , was das Verhalten und die Aufgabe betrifft. Dies verallgemeinert sich NICHT unbedingt auf andere Protokolle (z. B. OSPF), bei denen 4k die gängigsten MTUs überschreitet. In diesen Fällen würde es zu einer Fragmentierung kommen, und das ist schlecht.

Andere Gedanken

65536/4096 = 16

Wollen wir wirklich, dass sich die transienten RAM-Anforderungen von BGP mit 16 multiplizieren? Denken Sie daran, dass unter dem Deckmantel viele BGP-Implementierungen in C geschrieben sind, was bedeutet, dass BGP möglicherweise mallocPlatz für jede Nachricht bis zur maximalen Nachrichtengröße benötigt.

Obligatorische rhetorische Fragen ...

• Warum gibt es in der Software variable Größenbeschränkungen?
• Warum ist nicht jede C-Ganzzahl a long long?

Nehmen wir an, wir haben 100.000 BGP-Präfixe mit 15.000 eindeutigen Attributkombinationen. Nehmen wir auch an, dass unsere BGP-Implementierung die Präfixe BGP UPDATEmit 100% Effizienz in Nachrichten packt . Deshalb brauchen wir 15.000 BGP UPDATENachrichten.

15000 Nachrichten * 4096 Bytes / Nachricht = 58 MB verwendete aggregierte BGP-Nachrichtenpufferung

15000 Nachrichten * 65536 Bytes / Nachricht = 937 MB verwendete aggregierte BGP-Nachrichtenpufferung

Weil RFC4271 das sagt? Die Grenze war auch in BGP 3 vorhanden . Angesichts des kleinen Internets zu der Zeit, als BGP auf einer legendären Serviette erstellt wurde, würde ich sagen, dass es genau so gewählt wurde, wie die Anzahl der Bits in IPv4 war.