BGP Communities uitgelegd: Standard, Large en Extended
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:
- Prefixspecificiteit. Kondig een /32 (IPv4) of /128 (IPv6) aan voor het doel-IP. Blackhole nooit een heel /24.
- Bilaterale overeenkomst. Je upstream moet geconfigureerd zijn om de BLACKHOLE-community te honoreren. Dit gaat niet automatisch. Verifieer bij je provider.
- NO_EXPORT-tagging. Voeg altijd
NO_EXPORTtoe naast BLACKHOLE om te voorkomen dat de blackhole zich verspreidt voorbij je directe upstream. - 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:
- Voeg de
GRACEFUL_SHUTDOWN-community toe aan alle routes die naar de peer in onderhoud worden gestuurd - Wacht op convergentie (routes verschuiven naar alternatieve paden)
- Sluit de BGP-sessie af
- Voer onderhoud uit
- Breng de sessie weer op
- 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):
35661:8[LOC]:ASN-- expliciete toelating voor een specifieke peer35661:9[LOC]:ASN-- deny voor een specifieke peer35661:9[LOC]:1of35661:9[LOC]:2-- deny voor peergroep (transit of IX)35661:9[LOC]:0-- deny voor alle peers op een locatie35661: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_EXPORTtoe 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