BGP Communities erklärt: Standard, Large und Extended

Was sind BGP Communities?

BGP Communities sind 32-Bit-Tags, die an Routen-Ankündigungen angehängt werden. Sie transportieren Signalisierungsinformationen zwischen autonomen Systemen, ohne die Route selbst zu verändern. Eine Community sagt: "Behandle dieses Präfix anders" -- senke die Präferenz, verlängere den AS-Pfad per Prepending, verwirf es vollständig, oder kündige es nur bestimmten Peers an. Communities sind transitiv: Sie werden über BGP-Sessions weitergegeben, sofern sie nicht explizit entfernt werden. Drei Typen existieren: Standard (RFC 1997), Extended (RFC 4360) und Large (RFC 8092).

Communities lösen ein Koordinationsproblem. Ohne sie erfordert jede Routing-Policy-Entscheidung bilaterale Konfiguration auf beiden Seiten einer Session. Mit Communities liest Ihr Upstream oder IX Route Server Ihre Tags und wendet die von Ihnen gewünschte Policy an. Sie taggen einmal, das Netzwerk handelt.

Falls Sie zuerst eine BGP-Session aufsetzen müssen, lesen Sie BIRD2 BGP Configuration on Linux oder FRR BGP Configuration on Linux.

Welche drei Typen von BGP Communities gibt es?

Sie unterscheiden sich in Größe, Kodierung und den Problemen, die sie lösen. Standard Communities decken die meisten Anwendungsfälle ab, versagen aber bei 4-Byte-ASNs. Large Communities beheben diese Einschränkung. Extended Communities dienen spezialisierten Control-Plane-Anwendungen.

Eigenschaft	Standard (RFC 1997)	Large (RFC 8092)	Extended (RFC 4360)
Größe	32 Bit	96 Bit (3 x 32 Bit)	64 Bit
Format	ASN:value	ASN:value1:value2	type:subtype:value
ASN-Unterstützung	Nur 2-Byte	Nativ 4-Byte	2-Byte oder 4-Byte (typabhängig)
BGP-Attribut	COMMUNITIES (8)	LARGE_COMMUNITIES (32)	EXTENDED COMMUNITIES (16)
Hauptverwendung	Upstream-Signalisierung, Traffic Engineering	Wie Standard, aber 4-Byte-ASN-sicher	MPLS VPN, EVPN, Route Targets
Verbreitung	Universell	Weit verbreitet seit ~2018	Protokollspezifisch

Standard Communities (RFC 1997)

Standard Communities sind 32-Bit-Werte, geschrieben als zwei 16-Bit-Ganzzahlen, getrennt durch einen Doppelpunkt: ASN:value. Die oberen 16 Bit identifizieren das AS, das die Bedeutung der Community definiert. Die unteren 16 Bit tragen die Aktion oder Information.

Beispiel: 174:70 bedeutet "Cogent: Setze Local Preference auf 70". Nur Cogent definiert, was der Wert 70 im Namensraum 174 bedeutet. Jeder Provider veröffentlicht eigene Community-Definitionen.

Das 16-Bit-ASN-Feld beschränkt Standard Communities auf 2-Byte-ASNs (0-65535). Mit über 120.000 vergebenen ASNs im Jahr 2026 sind die meisten neuen Zuweisungen 4-Byte-Nummern. Standard Communities können diese nicht abbilden.

IANA reserviert den Bereich 65535:0 bis 65535:65535 für Well-Known Communities.

Large Communities (RFC 8092)

Large Communities verwenden drei 32-Bit-Ganzzahlen: Global Administrator : Local Data 1 : Local Data 2. Der Global Administrator ist die ASN des Netzwerks, das die Community definiert. Beide Local-Data-Felder sind frei durch den Betreiber definierbar.

Dieses Format löst das 4-Byte-ASN-Problem. Ein AS mit der Nummer 398465 kann 398465:100:0 als gültige Large Community definieren. Standard Communities können das nicht kodieren.

Die Drei-Feld-Struktur ermöglicht auch reichere Semantik. Ein gängiges Muster ist ASN:Funktion:Parameter -- zum Beispiel könnte 35661:1010:174 bedeuten: "Einmal prependen in Frankfurt Richtung Cogent (AS174)".

Large Community Support ist verfügbar in BIRD 1.6.3+, BIRD2, FRR 3.0+, OpenBGPD 6.1+, GoBGP, Cisco IOS-XR 6.2.1+ und Junos 17.3+. Wenn Ihr BGP-Daemon nach 2018 veröffentlicht wurde, unterstützt er sie mit hoher Wahrscheinlichkeit.

Extended Communities (RFC 4360)

Extended Communities sind 64-Bit-Werte mit einem Type-Feld, Subtype-Feld und Value. Anders als Standard und Large Communities haben Extended Communities strukturierte Semantik: Type und Subtype definieren, wie der Value interpretiert wird.

Sie begegnen Extended Communities hauptsächlich bei:

• MPLS L3VPN: Route Targets (rt 65000:100) und Route Distinguisher steuern VRF-Import/Export
• EVPN: MAC Mobility, ESI Labels und Route Types
• BGP Flowspec: Traffic Rate Limiting und Redirect Actions

Für Traffic Engineering zwischen ASes sind Standard und Large Communities die richtigen Werkzeuge. Extended Communities sind relevant, wenn Sie Overlay-Services betreiben. Dieser Artikel konzentriert sich in den folgenden Abschnitten auf Standard und Large Communities.

Was sind Well-Known BGP Communities?

IANA definiert mehrere Well-Known Community-Werte im reservierten Bereich 65535:*. Jede konforme BGP-Implementierung muss diese verstehen.

Community	Wert	Hex	Verhalten	RFC
NO_EXPORT	65535:65281	0xFFFFFF01	Nicht außerhalb der lokalen AS-Konföderation ankündigen	1997
NO_ADVERTISE	65535:65282	0xFFFFFF02	An keinen BGP-Peer ankündigen	1997
NO_EXPORT_SUBCONFED	65535:65283	0xFFFFFF03	Nicht außerhalb des lokalen AS ankündigen	1997
NOPEER	65535:65284	0xFFFFFF04	Nicht an bilaterale Peers ankündigen	3765
BLACKHOLE	65535:666	0xFFFF029A	Blackholing des getaggten Präfixes anfordern	7999
GRACEFUL_SHUTDOWN	65535:0	0xFFFF0000	Geplante Session-Abschaltung signalisieren, Local-Pref auf 0 setzen	8326

NO_EXPORT wird am häufigsten verwendet. Taggen Sie ein Präfix damit und Ihr Peer wird es nicht über seine AS-Grenze hinaus weiterankündigen. So kontrollieren Sie Route Leaks zu Dritten.

BLACKHOLE und GRACEFUL_SHUTDOWN werden in den Traffic-Engineering-Abschnitten weiter unten im Detail behandelt.

Wie ermöglichen BGP Communities Traffic Engineering?

Communities erlauben es Ihnen, Routing-Entscheidungen in Netzwerken zu beeinflussen, die Sie nicht kontrollieren. Sie können sich nicht auf den Routern Ihres Upstreams einloggen und deren Konfiguration ändern. Aber Sie können Ihre Ankündigungen mit Communities taggen, die der Upstream zu honorieren vereinbart hat. Das ist BGP Traffic Engineering via Communities.

Wie funktioniert Local Preference Signaling mit Communities?

Die meisten Transit-Provider bieten Communities an, die die Local Preference Ihres Präfixes innerhalb ihres Netzwerks setzen. Eine höhere Local Preference bedeutet "bevorzuge diesen Pfad". Ein niedrigerer Wert bedeutet "nutze diesen nur als Backup".

Ein Provider mit AS 64500 könnte zum Beispiel definieren:

Community	Wirkung
64500:100	Normale Präferenz (Standard)
64500:90	Niedrigere Präferenz (Backup-Pfad)
64500:150	Höhere Präferenz (bevorzugter Pfad)

Wenn Sie Ihre Ankündigung mit 64500:90 taggen, die an einen Upstream gesendet wird, und beim anderen den Standard belassen, lenken Sie eingehenden Traffic zum Upstream ohne die Backup-Community. Das funktioniert, weil Local Preference im BGP-Entscheidungsprozess vor der AS-Path-Länge ausgewertet wird.

Prüfen Sie die Community-Dokumentation Ihres Providers. Die obigen Werte sind beispielhaft. Jeder Provider definiert sein eigenes Schema.

Wie funktioniert BGP Prepending mit Communities?

AS-Path Prepending verlängert künstlich die Pfadlänge, um eine Route für entfernte Netzwerke weniger attraktiv zu machen. Statt auf Ihrem eigenen Router zu prependen (was alle Peers gleichermaßen betrifft), können Sie per Community selektives Prepending anfordern.

Ein typisches Provider-Schema:

Community	Wirkung
64500:1001	1x prependen Richtung aller Peers
64500:1002	2x prependen Richtung aller Peers
64500:1003	3x prependen Richtung aller Peers

Mit Large Communities kann das Ziel spezifischer sein:

Large Community	Wirkung
64500:1:174	1x prependen Richtung Cogent (AS174)
64500:2:174	2x prependen Richtung Cogent (AS174)
64500:3:0	3x prependen Richtung aller Peers

Diese Granularität ist der Grund, warum Large Communities Standard Communities beim Traffic Engineering ablösen. Das dritte Feld kodiert die Ziel-ASN oder Peer-Gruppe.

Wie funktioniert BGP Blackholing mit der BLACKHOLE Community?

Blackholing weist Upstream-Netzwerke an, sämtlichen Traffic zu einem getaggten Präfix zu verwerfen. Es ist ein DDoS-Abwehrwerkzeug: Wenn eine IP angegriffen wird, kündigen Sie sie mit der BLACKHOLE Community an und Ihre Upstreams null-routen den Traffic, bevor er Ihr Netzwerk erreicht.

RFC 7999 standardisiert die Well-Known Community 65535:666 für diesen Zweck.

Voraussetzungen, damit Blackholing funktioniert:

1. Präfix-Spezifität. Kündigen Sie ein /32 (IPv4) oder /128 (IPv6) für die Ziel-IP an. Blackholen Sie niemals ein ganzes /24.
2. Bilaterale Vereinbarung. Ihr Upstream muss konfiguriert sein, die BLACKHOLE Community zu honorieren. Das geschieht nicht automatisch. Klären Sie das mit Ihrem Provider.
3. NO_EXPORT-Tagging. Fügen Sie immer NO_EXPORT neben BLACKHOLE hinzu, um zu verhindern, dass das Blackhole über Ihren direkten Upstream hinaus propagiert.
4. Monitoring. Blackholing verwirft sämtlichen Traffic, legitimen wie bösartigen. Überwachen Sie und ziehen Sie die Ankündigung zurück, sobald der Angriff endet.

Die meisten IXP Route Server unterstützen Blackholing ebenfalls via 65535:666. Der Route Server setzt den Next-Hop auf eine Blackhole-Adresse und fügt NO_EXPORT vor der Weiterverteilung hinzu.

Wie nutzt man Communities für selektive Ankündigungen?

Selektive Ankündigungen (Selective Announcement) erlauben Ihnen zu kontrollieren, welche Peers oder IXPs Ihr Präfix sehen. Das ist das "nicht ankündigen an" oder "nur ankündigen an"-Muster.

Gängige Implementierungen nutzen ein Deny/Allow-Modell:

Community	Wirkung
64500:0:0	An niemanden ankündigen (globales Deny)
64500:0:174	Nicht an Cogent ankündigen
64500:8:174	Nur an Cogent ankündigen (überschreibt Deny)

Bei Virtua (AS35661) nutzt dies das standortbezogene Community-Schema, das in der Referenztabelle weiter unten beschrieben wird.

Wie funktioniert Graceful Shutdown mit der GRACEFUL_SHUTDOWN Community?

RFC 8326 definiert die GRACEFUL_SHUTDOWN Community (65535:0) für geplante Wartungsarbeiten. Wenn Sie eine BGP-Session herunterfahren müssen, teilt das Taggen Ihrer Routen mit dieser Community den empfangenden Routern mit, die Local Preference auf 0 zu senken und alternative Pfade zu bevorzugen, bevor Sie die Verbindung trennen.

Der Ablauf:

1. GRACEFUL_SHUTDOWN Community zu allen Routen hinzufügen, die an den Peer gesendet werden, der gewartet wird
2. Auf Konvergenz warten (Routen wechseln auf alternative Pfade)
3. BGP-Session herunterfahren
4. Wartung durchführen
5. Session wieder hochfahren
6. Community entfernen

Ohne Graceful Shutdown verursacht das Herunterfahren einer Session sofortigen Route Withdrawal. Traffic fällt aus, bis BGP auf den alternativen Pfad konvergiert. Mit Graceful Shutdown verlagert sich der Traffic schrittweise, bevor die Session ausgeht.

Dies hängt direkt mit Multi-Homing-Failover-Strategien zusammen.

Wie konfiguriere ich BGP Communities in BIRD2?

BIRD2 verwendet typisierte Community-Attribute auf Route-Objekten. Die drei relevanten Attribute sind:

Attribut	Typ	Community-Typ
bgp_community	clist (Pair-Liste)	Standard
bgp_large_community	lclist (Triplet-Liste)	Large
bgp_ext_community	eclist (Extended-Liste)	Extended

Communities in BIRD2 hinzufügen

Verwenden Sie die .add()-Methode in Filter-Blöcken:

filter export_to_upstream {
  # Add standard community
  bgp_community.add((65535, 666));

  # Add large community
  bgp_large_community.add((35661, 1010, 174));

  # Add multiple communities
  bgp_community.add((65535, 65281));  # NO_EXPORT

  accept;
}

Communities in BIRD2 abgleichen

Testen Sie die Zugehörigkeit mit dem ~-Operator:

filter import_from_peer {
  # Match a specific standard community
  if (65535, 666) ~ bgp_community then {
    dest = RTD_BLACKHOLE;
    accept;
  }

  # Match a specific large community
  if (35661, 9999, 0) ~ bgp_large_community then {
    reject;
  }

  # Match with wildcards using sets
  # Any community in the 64500:* range
  if bgp_community ~ [(64500, *)] then {
    bgp_local_pref = 50;
  }

  accept;
}

Der ~-Operator gibt true zurück, wenn der linke Operand ein Element des rechten Operanden ist. Für Set-Matching verwenden Sie Pair-/Triplet-Muster mit * als Wildcard.

Communities in BIRD2 löschen

Entfernen Sie Communities beim Eingang, um unerlaubte Signalisierung zu verhindern:

filter scrub_inbound {
  # Remove all communities in our ASN namespace
  bgp_community.delete([(35661, *)]);
  bgp_large_community.delete([(35661, *, *)]);

  # Remove specific well-known community
  bgp_community.delete((65535, 666));

  accept;
}

Graceful Shutdown Empfänger in BIRD2

function honor_graceful_shutdown() {
  if (65535, 0) ~ bgp_community then {
    bgp_local_pref = 0;
  }
}

filter ebgp_inbound {
  honor_graceful_shutdown();
  # ... other import filters
  accept;
}

Wenden Sie ebgp_inbound als Import-Filter auf allen EBGP-Sessions an. Wenn ein Peer die GRACEFUL_SHUTDOWN Community sendet, setzt dieser Filter die Local Preference auf 0. Ihr Router bevorzugt dann jeden alternativen Pfad.

Blackhole Trigger in BIRD2

protocol static blackhole_triggers {
  ipv4 {
    table master4;
  };
  # Announce 203.0.113.5/32 with BLACKHOLE + NO_EXPORT
  route 203.0.113.5/32 blackhole;
}

filter export_blackhole {
  if dest = RTD_BLACKHOLE then {
    bgp_community.add((65535, 666));    # BLACKHOLE
    bgp_community.add((65535, 65281));  # NO_EXPORT
    # Accept only /32 for blackholes
    if net.len = 32 then accept;
  }
  reject;
}

Wie konfiguriere ich BGP Communities in FRR?

FRR verwendet community-list-Definitionen im IOS-Stil und route-map-Aktionen. Communities werden mit match-Klauseln abgeglichen und mit set-Klauseln gesetzt.

Community-Listen in FRR definieren

! Standard community list - match specific community
bgp community-list standard BLACKHOLE permit 65535:666
bgp community-list standard GRACEFUL_SHUTDOWN permit 65535:0
bgp community-list standard NO_EXPORT permit no-export

! Large community list
bgp large-community-list standard PREPEND_1X permit 35661:1:0
bgp large-community-list standard NO_ANNOUNCE permit 35661:9:0

FRR unterstützt sowohl nummerierte (1-99 für Standard, 100-500 für Expanded) als auch benannte Community-Listen. Benannte Listen sind einfacher zu pflegen.

Communities in FRR Route-Maps setzen

route-map EXPORT-TO-UPSTREAM permit 10
 set community 65535:666 no-export additive
!
route-map EXPORT-TO-UPSTREAM permit 20
 set large-community 35661:1010:174 additive

Das Schlüsselwort additive fügt Communities hinzu, statt den bestehenden Satz zu ersetzen. Ohne additive überschreibt set community alle vorhandenen Communities.

Communities in FRR Route-Maps abgleichen

route-map IMPORT-FROM-PEER permit 10
 match community BLACKHOLE
 set ip next-hop 192.0.2.1
!
route-map IMPORT-FROM-PEER permit 20
 match community GRACEFUL_SHUTDOWN
 set local-preference 0
!
route-map IMPORT-FROM-PEER permit 30
 ! Default: accept everything else

Communities in FRR entfernen

route-map SCRUB-INBOUND permit 10
 set comm-list OUR_COMMUNITIES delete
 set large-comm-list OUR_LARGE_COMMUNITIES delete
!
bgp community-list expanded OUR_COMMUNITIES permit 35661:.*
bgp large-community-list expanded OUR_LARGE_COMMUNITIES permit 35661:.*:.*

Dies entfernt alle Communities in Ihrem ASN-Namensraum, die ein Peer möglicherweise injiziert. Wenden Sie diese Route-Map als neighbor <peer> route-map SCRUB-INBOUND in an.

Graceful Shutdown in FRR

FRR bietet einen eingebauten Befehl:

router bgp 35661
 bgp graceful-shutdown

Dieser fügt automatisch die GRACEFUL_SHUTDOWN Community (65535:0) zu allen Routen hinzu, die an EBGP-Peers gesendet werden. Verwenden Sie ihn vor geplanten Wartungsarbeiten.

Auf der Empfängerseite wenden Sie eine Route-Map an, die die Community abgleicht und die Local Preference senkt:

route-map HONOR-GSHUT permit 10
 match community GRACEFUL_SHUTDOWN
 set local-preference 0
!
route-map HONOR-GSHUT permit 20
 ! Accept everything else at normal preference

BIRD2 vs. FRR Community-Konfiguration im Vergleich

Operation	BIRD2	FRR
Standard Community hinzufügen	bgp_community.add((ASN, val))	set community ASN:val additive
Large Community hinzufügen	bgp_large_community.add((ASN, v1, v2))	set large-community ASN:v1:v2 additive
Standard Community abgleichen	if (ASN, val) ~ bgp_community	match community LIST_NAME
Large Community abgleichen	if (ASN, v1, v2) ~ bgp_large_community	match large-community LIST_NAME
Nach Muster löschen	bgp_community.delete([(ASN, *)])	set comm-list LIST_NAME delete
Wildcard-Abgleich	[(ASN, *)] in Set-Ausdruck	Expanded Community-List mit Regex
Filter anwenden	import filter name; im Protocol	neighbor X route-map NAME in

BIRD2 verarbeitet Community-Operationen inline innerhalb von Filter-Funktionen. FRR trennt die Definition (Community-List) von der Aktion (Route-Map). Beide Ansätze funktionieren. Die Inline-Syntax von BIRD2 ist kompakter für komplexe Logik mit Bedingungen. Das geteilte Modell von FRR ist besser lesbar für einfache Match-and-Set-Policies.

Welche BGP-Community-Werte hat Virtua?

Virtua (AS35661) unterstützt sowohl Standard als auch Large BGP Communities. Large Communities folgen dem Format 35661:AKTION_STANDORT:ZIEL. Das Community-Schema ist standortbezogen und erlaubt Ihnen, Ankündigungen pro POP, pro Peer-Typ oder pro spezifischer Peer-ASN zu steuern.

Standortcodes

Code	Stadt	Land	POP-ID
000	Paris	Frankreich	PAR01FR
001	Lille	Frankreich	LIL01FR
010	Frankfurt	Deutschland	FRA01DE
020	Amsterdam	Niederlande	AMS01NL
999	Alle Standorte	--	ALL

Action Communities

Aktion	Large-Community-Format	Wirkung
Route Origin	35661:0[LOC]:TARGET	Informativ: identifiziert, wo die Route gelernt wurde
1x Prepend	35661:1[LOC]:TARGET	AS35661 einmal prependen Richtung Ziel
2x Prepend	35661:2[LOC]:TARGET	AS35661 zweimal prependen Richtung Ziel
3x Prepend	35661:3[LOC]:TARGET	AS35661 dreimal prependen Richtung Ziel
Export Only	35661:8[LOC]:TARGET	Deny überschreiben: nur an Ziel ankündigen
No Export	35661:9[LOC]:TARGET	Nicht an Ziel ankündigen

Ziel-Selektoren (Target Selectors)

Zielwert	Bedeutung
0	Alle Peers am angegebenen Standort
1	Nur Transit-Peers
2	Nur IX-Peers
Spezifische ASN	Ein einzelner Peer (z.B. 174 für Cogent)

Vorrangregeln (Precedence Rules)

Wenn mehrere Communities in Konflikt stehen, wertet Virtua sie in dieser Reihenfolge aus (höchste Priorität zuerst):

1. 35661:8[LOC]:ASN -- explizites Allow für einen spezifischen Peer
2. 35661:9[LOC]:ASN -- Deny für einen spezifischen Peer
3. 35661:9[LOC]:1 oder 35661:9[LOC]:2 -- Deny für Peer-Gruppe (Transit oder IX)
4. 35661:9[LOC]:0 -- Deny für alle Peers an einem Standort
5. 35661:9999:0 -- Globales Deny (nirgends ankündigen)

Beispiele mit Virtua Communities

Überall ankündigen außer an Cogent in Frankfurt:

# BIRD2
bgp_large_community.add((35661, 9010, 174));

! FRR
route-map EXPORT permit 10
 set large-community 35661:9010:174 additive

Nur an IX-Peers an allen Standorten ankündigen:

# BIRD2
bgp_large_community.add((35661, 9999, 1));  # deny all transit

! FRR
route-map EXPORT permit 10
 set large-community 35661:9999:1 additive

2x prependen Richtung aller Peers in Paris:

# BIRD2
bgp_large_community.add((35661, 2000, 0));

! FRR
route-map EXPORT permit 10
 set large-community 35661:2000:0 additive

Weitere Informationen zur BGP-Einrichtung mit Virtua finden Sie unter BGP Bring Your Own IP on a VPS.

Wie überprüfe ich BGP Communities auf einer Route?

Überprüfung in BIRD2

birdc show route for 203.0.113.0/24 all

Suchen Sie nach den Attributen BGP.community und BGP.large_community in der Ausgabe:

203.0.113.0/24   unicast [upstream1 2026-03-19] * (100) [AS64500i]
    via 198.51.100.1 on eth0
    Type: BGP univ
    BGP.community: (65535,666) (65535,65281)
    BGP.large_community: (35661,0010,174)
    BGP.as_path: 64500

Überprüfung in FRR

vtysh -c "show ip bgp 203.0.113.0/24"

Die Ausgabe enthält eine Community:-Zeile:

BGP routing table entry for 203.0.113.0/24
  65535:666 no-export
  Large Community: 35661:0010:174

Überprüfung mit externen Tools

Sie können Communities nicht allein aus Ihrem Netzwerk heraus sehen. Verwenden Sie externe Looking Glasses, um zu verifizieren, was der Rest des Internets sieht:

• bgp.tools: Suchen Sie Ihr Präfix und prüfen Sie den Tab "Communities". Zeigt Communities aus der Sicht mehrerer Kollektoren weltweit.
• RIPE Stat: Das Widget "BGP Looking Glass" zeigt Community-Attribute von RIPE-RIS-Kollektoren.
• NLNOG Looking Glass: Abfrage von NLNOG-RING-Knoten über mehrere ASes hinweg.

Verifizieren Sie immer von außen. Eine Community kann auf Ihrem Router korrekt gesetzt sein, aber von einem zwischengeschalteten Netzwerk entfernt werden.

Wie handhabe ich Community-Sicherheit?

Communities sind standardmäßig transitiv. Jedes Netzwerk im Pfad kann sie lesen, ergänzen oder entfernen. Das birgt Sicherheitsrisiken, wenn Sie nicht korrekt filtern.

Eingehende Communities im eigenen ASN-Namensraum entfernen

Wenn ein Peer Ihnen eine Route mit Ihren eigenen Communities sendet (z.B. 35661:9999:0) und Sie diese nicht entfernen, könnten Ihre eigenen Export-Filter sie honorieren. Das könnte dazu führen, dass Sie das Präfix gar nicht mehr ankündigen.

Bereinigen Sie immer Ihren eigenen Community-Namensraum beim Import:

# BIRD2 - apply on every EBGP import filter
bgp_community.delete([(35661, *)]);
bgp_large_community.delete([(35661, *, *)]);

! FRR - apply as inbound route-map on every EBGP neighbor
bgp community-list expanded OUR_COMMS permit 35661:.*
bgp large-community-list expanded OUR_LARGE_COMMS permit 35661:.*:.*

route-map SCRUB-IN permit 10
 set comm-list OUR_COMMS delete
 set large-comm-list OUR_LARGE_COMMS delete

Blackhole-Anfragen validieren

Honorieren Sie 65535:666 niemals blind von einem beliebigen Peer. Ein böswilliger oder fehlkonfigurierter Peer könnte Ihre Kundenpräfixe blackholen.

Regeln für die Blackhole-Akzeptanz:

• Akzeptieren Sie Blackhole-getaggte Routen nur für Präfixe, die der Peer berechtigt ist anzukündigen
• Überprüfen Sie RPKI/ROA-Validität, bevor Sie das Blackhole honorieren (siehe RPKI ROA Setup for BGP)
• Beschränken Sie die akzeptierte Präfixlänge für Blackholes auf /32 (IPv4) und /128 (IPv6)
• Fügen Sie immer NO_EXPORT zu Blackhole-Routen hinzu, bevor Sie sie weiterverteilen

# BIRD2 - safe blackhole acceptance
filter import_with_blackhole {
  if (65535, 666) ~ bgp_community then {
    # Only accept /32 for blackhole
    if net.len != 32 then reject;
    dest = RTD_BLACKHOLE;
    bgp_community.add((65535, 65281));  # NO_EXPORT
    accept;
  }
  # ... normal import policy
  accept;
}

Communities beim Export entfernen, wenn angebracht

Bevor Sie Routen an Peers ankündigen, entfernen Sie Communities, die diese nicht sehen oder auf die sie nicht reagieren sollen:

# BIRD2 - clean export to IX route server
filter export_to_ix {
  # Keep well-known communities, remove internal ones
  bgp_community.delete([(35661, *)]);
  bgp_large_community.delete([(35661, 0, *)]);  # Remove informational
  # Keep action communities the IX needs to see
  accept;
}

Community-Sicherheit ist Teil einer breiteren Route-Filtering-Strategie. Lesen Sie BGP Route Filtering and Security für das vollständige Bild.

Etwas funktioniert nicht?

Communities erscheinen nicht auf externen Looking Glasses. Ihr Upstream entfernt sie möglicherweise. Prüfen Sie, ob die Community in einem Namensraum liegt, den der Upstream honoriert. Manche Provider entfernen standardmäßig alle Drittanbieter-Communities.

Blackholing funktioniert nicht. Überprüfen Sie die Präfixlänge (/32 oder /128 erforderlich). Bestätigen Sie, dass Ihr Upstream RFC 7999 unterstützt. Prüfen Sie, ob NO_EXPORT hinzugefügt wird -- ohne es könnte das Blackhole weiter als beabsichtigt propagieren und entfernt werden.

Large Communities werden nicht weitergegeben. Ältere BGP-Implementierungen verwerfen stillschweigend unbekannte Attribute. Wenn ein zwischengeschaltetes AS Software betreibt, die vor RFC 8092 Support liegt, gehen Large Communities verloren. Prüfen Sie den AS-Pfad und identifizieren Sie das Netzwerk, das sie verwirft.

BIRD2 Filter-Syntaxfehler. Community-Paare verwenden Klammern, keine Doppelpunkte: (35661, 100) nicht 35661:100. Large Communities sind Triplets: (35661, 100, 200). Die Doppelpunkt-Notation ist nur für Anzeige und CLI.

FRR Community-List greift nicht. Benannte Community-Listen müssen exakt wie definiert referenziert werden. Prüfen Sie auf Tippfehler. Verwenden Sie show bgp community-list, um den Listeninhalt zu überprüfen.

Communities werden in FRR überschrieben statt angehängt. Das Schlüsselwort additive fehlt bei set community oder set large-community. Ohne es werden alle vorhandenen Communities ersetzt. Verwenden Sie immer additive, es sei denn, Sie wollen absichtlich überschreiben.

Prüfen Sie die Logs bei BGP-Session-Problemen:

# BIRD2
journalctl -u bird -f

# FRR
journalctl -u frr -f

Copyright 2026 Virtua.Cloud. Alle Rechte vorbehalten. Dieser Inhalt ist ein Originalwerk des Virtua.Cloud-Teams. Vervielfältigung, Wiederveröffentlichung oder Weiterverbreitung ohne schriftliche Genehmigung ist untersagt.