BGP Communities uitgelegd: Standard, Large en Extended

15 min leestijd·Matthieu·routingblackholefrrbird2traffic-engineeringbgp-communitiesbgp|

Hoe BGP standard, large en extended communities in de praktijk werken. Behandelt traffic engineering, blackholing, selectieve aankondigingen en graceful shutdown met configuratievoorbeelden in BIRD2 en FRR.

BGP Communities uitgelegd: Standard, Large en Extended

Wat zijn BGP communities?

BGP communities zijn 32-bit tags die aan route-aankondigingen worden gehecht. Ze dragen signaleringsinformatie tussen AS'en zonder de route zelf te wijzigen. Een community zegt "behandel dit prefix anders" -- verlaag de voorkeur, verleng het pad, laat het volledig vallen, of kondig het alleen aan bij specifieke peers. Communities zijn transitief: ze propageren over BGP-sessies tenzij ze expliciet worden verwijderd. Er bestaan drie types: standard (RFC 1997), extended (RFC 4360) en large (RFC 8092).

Communities lossen een coördinatieprobleem op. Zonder communities vereist elke routingbeleidsbeslissing bilaterale configuratie aan beide kanten van een sessie. Met communities leest je upstream of IX-routeserver je tags en past het gevraagde beleid toe. Je tagt één keer, het netwerk handelt.

Als je eerst BGP-sessieopzet nodig hebt, zie BIRD2 BGP Configuration on Linux of FRR BGP Configuration on Linux.

Wat zijn de drie typen BGP communities?

Ze verschillen in grootte, codering en de problemen die ze oplossen. Standard communities dekken de meeste toepassingen maar falen bij 4-byte ASN's. Large communities verhelpen die beperking. Extended communities dienen gespecialiseerde control-plane-toepassingen.

Eigenschap Standard (RFC 1997) Large (RFC 8092) Extended (RFC 4360)
Grootte 32 bits 96 bits (3 x 32 bits) 64 bits
Formaat ASN:value ASN:value1:value2 type:subtype:value
ASN-ondersteuning Alleen 2-byte 4-byte native 2-byte of 4-byte (afhankelijk van type)
BGP-attribuut COMMUNITIES (8) LARGE_COMMUNITIES (32) EXTENDED COMMUNITIES (16)
Primair gebruik Upstream-signalering, traffic engineering Zelfde als standard, 4-byte ASN-veilig MPLS VPN, EVPN, route targets
Adoptie Universeel Wijdverbreid sinds ~2018 Protocolspecifiek

Standard communities (RFC 1997)

Standard communities zijn 32-bit waarden, geschreven als twee 16-bit integers gescheiden door een dubbele punt: ASN:value. De hoge 16 bits identificeren het AS dat de betekenis van de community definieert. De lage 16 bits dragen de actie of informatie.

Voorbeeld: 174:70 betekent "Cogent: stel local preference in op 70". Alleen Cogent bepaalt wat waarde 70 betekent in de 174-namespace. Elke provider publiceert zijn eigen communitydefinities.

Het 16-bit ASN-veld beperkt standard communities tot 2-byte ASN's (0-65535). Met meer dan 120.000 toegewezen ASN's in 2026 zijn de meeste nieuwe toewijzingen 4-byte nummers. Standard communities kunnen deze niet representeren.

IANA reserveert het bereik 65535:0 tot en met 65535:65535 voor well-known communities.

Large communities (RFC 8092)

Large communities gebruiken drie 32-bit integers: Global Administrator : Local Data 1 : Local Data 2. De global administrator is het ASN van het netwerk dat de community definieert. Beide lokale datavelden worden door de operator bepaald.

Dit formaat lost het 4-byte ASN-probleem op. Een AS met nummer 398465 kan 398465:100:0 als geldige large community definiëren. Standard communities kunnen dit niet coderen.

De drieveldige structuur maakt ook rijkere semantiek mogelijk. Een veelvoorkomend patroon is ASN:functie:parameter. Bijvoorbeeld, 35661:1010:174 kan betekenen "prepend eenmaal bij Frankfurt richting Cogent (AS174)".

Large community-ondersteuning is beschikbaar in BIRD 1.6.3+, BIRD2, FRR 3.0+, OpenBGPD 6.1+, GoBGP, Cisco IOS-XR 6.2.1+ en Junos 17.3+. Als je BGP-daemon na 2018 is uitgebracht, ondersteunt deze ze vrijwel zeker.

Extended communities (RFC 4360)

Extended communities zijn 64-bit waarden met een typeveld, subtypeveld en waarde. Anders dan standard en large communities hebben extended communities gestructureerde semantiek: het type en subtype bepalen hoe de waarde geïnterpreteerd moet worden.

Je komt extended communities voornamelijk tegen bij:

  • MPLS L3VPN: Route targets (rt 65000:100) en route distinguishers regelen VRF import/export
  • EVPN: MAC-mobiliteit, ESI-labels en routetypen
  • BGP Flowspec: Traffic rate limiting en redirect-acties

Voor traffic engineering tussen AS'en zijn standard en large communities de juiste tools. Extended communities zijn relevant wanneer je overlay-diensten draait. Dit artikel richt zich voor de overige secties op standard en large communities.

Wat zijn well-known BGP communities?

IANA definieert meerdere well-known communitywaarden in het gereserveerde bereik 65535:*. Elke conforme BGP-implementatie moet deze begrijpen.

Community Waarde Hex Gedrag RFC
NO_EXPORT 65535:65281 0xFFFFFF01 Niet adverteren buiten de lokale AS-confederatie 1997
NO_ADVERTISE 65535:65282 0xFFFFFF02 Niet adverteren naar enige BGP-peer 1997
NO_EXPORT_SUBCONFED 65535:65283 0xFFFFFF03 Niet adverteren buiten het lokale AS 1997
NOPEER 65535:65284 0xFFFFFF04 Niet adverteren naar bilaterale peers 3765
BLACKHOLE 65535:666 0xFFFF029A Verzoek tot blackhole van het getagde prefix 7999
GRACEFUL_SHUTDOWN 65535:0 0xFFFF0000 Signaleer geplande sessie-shutdown, stel local-pref in op 0 8326

NO_EXPORT wordt het meest gebruikt. Tag een prefix hiermee en je peer zal het niet opnieuw adverteren voorbij zijn AS-grens. Zo beheer je route leaks naar derden.

BLACKHOLE en GRACEFUL_SHUTDOWN worden gedetailleerd behandeld in de traffic engineering-secties hieronder.

Hoe maken BGP communities traffic engineering mogelijk?

Communities laten je routingbeslissingen beïnvloeden in netwerken die je niet beheert. Je kunt niet inloggen op de routers van je upstream en hun configuratie wijzigen. Maar je kunt je aankondigingen taggen met communities die ze hebben afgesproken te honoreren. Dit is BGP traffic engineering via communities.

Hoe werkt local preference-signalering met communities?

De meeste transitproviders bieden communities aan die de local preference van je prefix in hun netwerk instellen. Een hogere local preference betekent "geef voorkeur aan dit pad". Een lagere waarde betekent "gebruik dit alleen als backup".

Een provider met AS 64500 zou bijvoorbeeld het volgende kunnen definiëren:

Community Effect
64500:100 Normale voorkeur (standaard)
64500:90 Lagere voorkeur (backup-pad)
64500:150 Hogere voorkeur (voorkeurspad)

Door je aankondiging te taggen met 64500:90 bij de ene upstream en de standaardwaarde te laten bij de andere, stuur je inkomend verkeer richting de upstream zonder de backup-community. Dit werkt omdat local preference vóór AS-path-lengte wordt geëvalueerd in het BGP-beslissingsproces.

Raadpleeg de communitydocumentatie van je provider. De waarden hierboven zijn illustratief. Elke provider definieert zijn eigen schema.

Hoe werkt BGP-prepending met communities?

AS-path prepending vergroot kunstmatig de padlengte om een route minder gewenst te maken voor externe netwerken. In plaats van te prependen op je eigen router (wat alle peers gelijk treft), laten communities je selectief prepending aanvragen.

Een typisch providerschema:

Community Effect
64500:1001 1x prependen richting alle peers
64500:1002 2x prependen richting alle peers
64500:1003 3x prependen richting alle peers

Met large communities kan het doel specifieker zijn:

Large community Effect
64500:1:174 1x prependen richting Cogent (AS174)
64500:2:174 2x prependen richting Cogent (AS174)
64500:3:0 3x prependen richting alle peers

Deze granulariteit is waarom large communities standard communities vervangen voor traffic engineering. Het derde veld codeert het doel-ASN of de peergroep.

Hoe werkt BGP-blackholing met de BLACKHOLE-community?

Blackholing vertelt upstream-netwerken al het verkeer naar een getagd prefix te droppen. Het is een DDoS-mitigatietool: wanneer een IP wordt aangevallen, kondig je het aan met de BLACKHOLE-community en je upstreams null-routen het verkeer voordat het je netwerk bereikt.

RFC 7999 standaardiseert de well-known community 65535:666 voor dit doel.

Vereisten voor werkende blackholing:

  1. Prefixspecificiteit. Kondig een /32 (IPv4) of /128 (IPv6) aan voor het doel-IP. Blackhole nooit een heel /24.
  2. Bilaterale overeenkomst. Je upstream moet geconfigureerd zijn om de BLACKHOLE-community te honoreren. Dit gaat niet automatisch. Verifieer bij je provider.
  3. NO_EXPORT-tagging. Voeg altijd NO_EXPORT toe naast BLACKHOLE om te voorkomen dat de blackhole zich verspreidt voorbij je directe upstream.
  4. Monitoring. Blackholing dropt al het verkeer, zowel legitiem als kwaadaardig. Monitor en trek de aankondiging in zodra de aanval stopt.

De meeste IXP-routeservers ondersteunen ook blackholing via 65535:666. De routeserver stelt de next-hop in op een blackhole-adres en voegt NO_EXPORT toe vóór herdistributie.

Hoe gebruik je communities voor selectieve aankondigingen?

Selectieve aankondiging laat je bepalen welke peers of IXP's je prefix zien. Dit is het patroon "niet aankondigen bij" of "alleen aankondigen bij".

Veelvoorkomende implementaties gebruiken een deny/allow-model:

Community Effect
64500:0:0 Aan niemand aankondigen (globale deny)
64500:0:174 Niet aankondigen bij Cogent
64500:8:174 Alleen aankondigen bij Cogent (override deny)

Bij Virtua (AS35661) maakt dit gebruik van het locatiebewuste communityschema dat in de referentietabel hieronder wordt beschreven.

Hoe werkt graceful shutdown met de GRACEFUL_SHUTDOWN-community?

RFC 8326 definieert de GRACEFUL_SHUTDOWN-community (65535:0) voor gepland onderhoud. Wanneer je een BGP-sessie moet beëindigen, vertelt het taggen van je routes met deze community ontvangende routers om de local preference te verlagen naar 0 en alternatieve paden te prefereren voordat je de verbinding verbreekt.

De volgorde:

  1. Voeg de GRACEFUL_SHUTDOWN-community toe aan alle routes die naar de peer in onderhoud worden gestuurd
  2. Wacht op convergentie (routes verschuiven naar alternatieve paden)
  3. Sluit de BGP-sessie af
  4. Voer onderhoud uit
  5. Breng de sessie weer op
  6. Verwijder de community

Zonder graceful shutdown veroorzaakt het beëindigen van een sessie onmiddellijke route withdrawal. Verkeer valt weg totdat BGP convergeert op het alternatieve pad. Met graceful shutdown verschuift verkeer geleidelijk voordat de sessie wordt beëindigd.

Dit sluit direct aan bij multi-homing failover-strategieën.

Hoe configureer ik BGP communities in BIRD2?

BIRD2 gebruikt getypeerde community-attributen op route-objecten. De drie relevante attributen zijn:

Attribuut Type Communitytype
bgp_community clist (pair list) Standard
bgp_large_community lclist (triplet list) Large
bgp_ext_community eclist (extended list) Extended

Communities toevoegen in BIRD2

Gebruik de .add()-methode in filterblokken:

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 matchen in BIRD2

Test lidmaatschap met de ~-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;
}

De ~-operator geeft true terug als de linker operand lid is van de rechter operand. Voor setmatching gebruik je pair/triplet-patronen met * als wildcard.

Communities verwijderen in BIRD2

Verwijder communities bij inkomend verkeer om ongeautoriseerde signalering te voorkomen:

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-ontvanger 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;
}

Pas ebgp_inbound toe als importfilter op alle EBGP-sessies. Wanneer een peer de GRACEFUL_SHUTDOWN-community stuurt, stelt dit de local preference in op 0, waardoor je router elk alternatief pad prefereert.

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;
}

Hoe configureer ik BGP communities in FRR?

FRR gebruikt IOS-stijl community-list-definities en route-map-acties. Communities worden gematcht met match-clausules en ingesteld met set-clausules.

Community-lijsten definiëren in FRR

! 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 ondersteunt zowel genummerde (1-99 voor standard, 100-500 voor expanded) als benoemde community-lijsten. Benoemde lijsten zijn makkelijker te onderhouden.

Communities instellen in FRR route-maps

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

Het sleutelwoord additive voegt communities toe in plaats van de bestaande set te vervangen. Zonder additive overschrijft set community alle bestaande communities.

Communities matchen in FRR route-maps

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 verwijderen in FRR

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:.*:.*

Dit verwijdert alle communities in je ASN-namespace die een peer mogelijk injecteert. Pas deze route-map toe als neighbor <peer> route-map SCRUB-INBOUND in.

Graceful shutdown in FRR

FRR biedt een ingebouwd commando:

router bgp 35661
 bgp graceful-shutdown

Dit voegt automatisch de GRACEFUL_SHUTDOWN-community (65535:0) toe aan alle routes die naar alle EBGP-peers worden gestuurd. Gebruik het vóór gepland onderhoud.

Aan de ontvangende kant pas je een route-map toe die de community matcht en de local preference verlaagt:

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-configuratievergelijking

Bewerking BIRD2 FRR
Standard community toevoegen bgp_community.add((ASN, val)) set community ASN:val additive
Large community toevoegen bgp_large_community.add((ASN, v1, v2)) set large-community ASN:v1:v2 additive
Standard community matchen if (ASN, val) ~ bgp_community match community LIST_NAME
Large community matchen if (ASN, v1, v2) ~ bgp_large_community match large-community LIST_NAME
Verwijderen op patroon bgp_community.delete([(ASN, *)]) set comm-list LIST_NAME delete
Wildcard-match [(ASN, *)] in setexpressie Expanded community-list met regex
Filter toepassen import filter name; in protocol neighbor X route-map NAME in

BIRD2 verwerkt community-operaties inline binnen filterfuncties. FRR scheidt de definitie (community-list) van de actie (route-map). Beide benaderingen werken. De inline syntax van BIRD2 is bondiger voor complexe logica met condities. Het gesplitste model van FRR is leesbaarder voor eenvoudige match-and-set-beleidsregels.

Wat zijn de BGP-communitywaarden van Virtua?

Virtua (AS35661) ondersteunt zowel standard als large BGP communities. Large communities volgen het formaat 35661:ACTIE_LOCATIE:DOEL. Het communityschema is locatiebewust, waardoor je aankondigingen per POP, per peertype of per specifiek peer-ASN kunt beheren.

Locatiecodes

Code Stad Land POP ID
000 Parijs Frankrijk PAR01FR
001 Rijsel Frankrijk LIL01FR
010 Frankfurt Duitsland FRA01DE
020 Amsterdam Nederland AMS01NL
999 Alle locaties -- ALL

Actie-communities

Actie Large community-formaat Effect
Route-oorsprong 35661:0[LOC]:TARGET Informatief: identificeert waar de route geleerd is
1x prependen 35661:1[LOC]:TARGET AS35661 eenmaal prependen richting doel
2x prependen 35661:2[LOC]:TARGET AS35661 tweemaal prependen richting doel
3x prependen 35661:3[LOC]:TARGET AS35661 driemaal prependen richting doel
Alleen exporteren 35661:8[LOC]:TARGET Override deny: alleen aankondigen bij doel
Niet exporteren 35661:9[LOC]:TARGET Niet aankondigen bij doel

Doelselectoren

Doelwaarde Betekenis
0 Alle peers op de opgegeven locatie
1 Alleen transitpeers
2 Alleen IX-peers
Specifiek ASN Een enkele peer (bijv. 174 voor Cogent)

Voorrangsregels

Wanneer meerdere communities conflicteren, evalueert Virtua ze in deze volgorde (hoogste prioriteit eerst):

  1. 35661:8[LOC]:ASN -- expliciete toelating voor een specifieke peer
  2. 35661:9[LOC]:ASN -- deny voor een specifieke peer
  3. 35661:9[LOC]:1 of 35661:9[LOC]:2 -- deny voor peergroep (transit of IX)
  4. 35661:9[LOC]:0 -- deny voor alle peers op een locatie
  5. 35661:9999:0 -- globale deny (nergens aankondigen)

Voorbeelden met Virtua-communities

Overal aankondigen behalve bij Cogent in Frankfurt:

# BIRD2
bgp_large_community.add((35661, 9010, 174));
! FRR
route-map EXPORT permit 10
 set large-community 35661:9010:174 additive

Alleen aankondigen bij IX-peers op alle locaties:

# 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 richting alle peers in Parijs:

# BIRD2
bgp_large_community.add((35661, 2000, 0));
! FRR
route-map EXPORT permit 10
 set large-community 35661:2000:0 additive

Zie BGP Bring Your Own IP on a VPS voor meer over BGP-opzet met Virtua.

Hoe verifieer ik BGP communities op een route?

Verifiëren in BIRD2

birdc show route for 203.0.113.0/24 all

Zoek naar de BGP.community- en BGP.large_community-attributen in de uitvoer:

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

Verifiëren in FRR

vtysh -c "show ip bgp 203.0.113.0/24"

De uitvoer bevat een Community:-regel:

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

Verifiëren met externe tools

Je kunt communities niet alleen vanuit je eigen netwerk bekijken. Gebruik externe looking glasses om te controleren wat de rest van het internet ziet:

  • bgp.tools: Zoek je prefix op en bekijk het tabblad "Communities". Toont communities zoals gezien door meerdere collectors wereldwijd.
  • RIPE Stat: De "BGP Looking Glass"-widget toont community-attributen van RIPE RIS-collectors.
  • NLNOG Looking Glass: Query vanuit NLNOG RING-nodes over meerdere AS'en.

Verifieer altijd van buitenaf. Een community kan correct ingesteld zijn op je router maar verwijderd worden door een tussenliggend netwerk.

Hoe ga ik om met community-beveiliging?

Communities zijn standaard transitief. Elk netwerk in het pad kan ze lezen, toevoegen of verwijderen. Dit levert beveiligingsrisico's op als je niet goed filtert.

Verwijder inkomende communities in je ASN-namespace

Als een peer je een route stuurt getagd met je eigen communities (bijv. 35661:9999:0) en je verwijdert deze niet, kunnen je eigen exportfilters ze honoreren. Dit kan ertoe leiden dat je stopt met het aankondigen van het prefix.

Schoon je eigen community-namespace altijd op bij 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

Valideer blackhole-verzoeken

Honoreer 65535:666 nooit blindelings van elke peer. Een kwaadwillende of fout geconfigureerde peer zou je klantprefixen kunnen blackholen.

Regels voor blackhole-acceptatie:

  • Accepteer alleen routes met blackhole-tag voor prefixen die de peer gemachtigd is te origineren
  • Verifieer RPKI/ROA-validiteit voordat je de blackhole honoreert (zie RPKI ROA Setup for BGP)
  • Beperk de geaccepteerde prefixlengte tot /32 (IPv4) en /128 (IPv6) voor blackholes
  • Voeg altijd NO_EXPORT toe aan blackhole-routes vóór herdistributie
# 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;
}

Verwijder communities bij export indien nodig

Verwijder vóór het aankondigen van routes naar peers communities die zij niet zouden moeten zien of waarnaar ze niet zouden moeten handelen:

# 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-beveiliging maakt deel uit van een bredere routefilteringsstrategie. Zie BGP Route Filtering and Security voor het volledige beeld.

Iets gaat niet goed?

Communities verschijnen niet op externe looking glasses. Je upstream verwijdert ze mogelijk. Controleer of de community in een namespace staat die zij honoreren. Sommige providers verwijderen standaard alle communities van derden.

Blackhole werkt niet. Controleer de prefixlengte (/32 of /128 vereist). Bevestig dat je upstream RFC 7999 ondersteunt. Controleer of NO_EXPORT wordt toegevoegd -- zonder dit kan de blackhole zich verder verspreiden dan bedoeld en worden verwijderd.

Large communities propageren niet. Oudere BGP-implementaties laten onbekende attributen stilzwijgend vallen. Als een tussenliggend AS software draait die RFC 8092-ondersteuning mist, gaan large communities verloren. Controleer het AS-pad en identificeer het netwerk dat ze dropt.

BIRD2-filtersyntaxfouten. Community-paren gebruiken haakjes, geen dubbele punten: (35661, 100) niet 35661:100. Large communities zijn triplets: (35661, 100, 200). De dubbelepuntnotatie is alleen voor weergave en CLI.

FRR community-list matcht niet. Benoemde community-lijsten moeten exact worden gerefereerd zoals gedefinieerd. Controleer op typefouten. Gebruik show bgp community-list om de lijstinhoud te verifiëren.

Communities worden overschreven in plaats van toegevoegd in FRR. Het sleutelwoord additive ontbreekt bij set community of set large-community. Dit vervangt alle bestaande communities. Gebruik altijd additive tenzij je bewust wilt overschrijven.

Controleer logs voor BGP-sessieproblemen:

# BIRD2
journalctl -u bird -f

# FRR
journalctl -u frr -f

Copyright 2026 Virtua.Cloud. Alle rechten voorbehouden. Deze inhoud is een origineel werk van het Virtua.Cloud-team. Reproductie, herpublicatie of herdistributie zonder schriftelijke toestemming is verboden.

Klaar om het zelf te proberen?

Deploy uw eigen server in seconden. Linux, Windows of FreeBSD.

Bekijk VPS-aanbod