n@work unterstützt seit vielen Jahren BGP Communities zur Steuerung des BGP Routings. Kunden die eigene Netze besitzen und diese mit dem Routing Protokoll BGP an unser AS9211 weitergeben, können diese BGP Communities nutzen. Generell gibt es zwei Arten von Communities: zum einen setzen wir Communities um den Kunden die Information zu geben woher wir diese Route empfangen haben. Zum anderen können Sie mit Ihren Routen Communities an n@work weitergeben, die route prepends auslösen oder verhindern, dass die Route an bestimmte Upstreams oder Peerings weitergegeben werden. Klingt kompliziert ist es aber nicht.
Eine BGP Community ist erst einmal eine 32 Bit Zahl, die üblicherweise als zwei 16 Bit Zahlen durch einen Doppelpunkt getrennt dargestellt wird. Branchenüblich ist, dass jeder Provider, der Communities nutzt in den ersten 16 Bits sein eigenen AS einsetzt und in den zweiten 16 Bit die entsprechende zusätzliche Routing Information. Bei n@work bedeutet die Community 9211:1100, dass wir diese Route am DE-CIX Frankfurt empfangen haben, 9211:1200 bedeutet, wir haben die Route am DE-CIX in Hamburg erhalten. Die von n@work unterstützten Communities sind in der RIPE Datenbank unter AS9211 hinterlegt.
Wozu man diese Information verwenden kann, möchte ich in einem kleinen Beispiel beschreiben: Nehmen wir an n@work hat einen Kunden der in Kassel sitzt und neben n@work einen weiteren Upstream Provider in Frankfurt hat. Sowohl n@work als auch der Frankfurter Provider peeren am DE-CIX Frankfurt und am DE-CIX Hamburg. Nun ist es für unseren Kunden in Kassel nicht optimal die Daten, die nach Hamburg gehen sollen über den Frankfurter Provider zu schicken. Anders herum möchte unser Kunde in Kassel den Verkehr nach Frankfurt auch nicht über Hamburg schicken. Über die BGP Communities kann der Kunde identifizieren, welche Routen von n@work aus Hamburg kommen und welche aus Frankfurt und diese mit metric oder local preference entsprechend manipulieren.
Die Community für die verschiedenen Exchanges sind vor allem deshalb notwendig, da es für den Kunden aus dem AS-Pfad nicht ersichtlich ist, über welchen Exchange diese Route gekommen ist. Bei den Upstream Providern ist das eindeutig aus dem AS-Pfad ablesbar, hier wäre eine BGP Community nur dann notwendig, wenn n@work Upstream von einem AS an unterschiedlichen Orten beziehen würde. N@work bezieht aber alle Upstreams in Hamburg.
Über die zweite Art von Communities, die Sie mit Ihren Routen mitgeben, können Sie verhindern, dass wir ihre Routen an andere Upstream Provider weitergeben, oder durch sogenannte Prepends den AS-Pfad künstlich verlängern. Wir halten nicht besonders viel von Pfad Verlängerungen, setzen dieses Instrument selbst kaum ein und würden eher empfehlen die komplette Unterdrückung der Route vorzunehmen. N@work hat derzeit vier Upstream Provider und wenn Sie aus welchen Gründen auch immer nicht möchten, dass Ihre Routen z.B. zu Cogent weitergeben werden, dann setzen Sie die Community 9211:4300 und haben immer noch ausreichend Redundanz aus den verbleibenden drei Upstream Providern.
An dieser Stelle sollte man hinzufügen, dass mit den Comminities nicht das Routing von n@work beeinflussbar ist. Alle Pakete, die wir zu Cogent schicken, werden auch weiterhin dorthin gehen, egal wie Sie Ihre Communities setzen. Sie können damit lediglich den Rückweg beeinflussen. Wenn man BGP spricht, hat man aber in der Regel mehr als einen Upstream Provider und natürlich haben Sie die Möglichkeit den Verkehr, den Sie nicht über einen bestimmten Upstream Provider von n@work routen möchten, über einen anderen Ihrer Upstreams zu routen in der Hoffnung dass dieser einen alternativen Weg bereitstellt.
Wenn Sie BGP Communities einsetzen möchten, unterstützen wir Sie gerne bei der Umsetzung, setzen Sie sich dazu mit unserem Support in Verbindung.