BGP Communities: estándar, large y extended

¿Qué son las BGP communities?

Las BGP communities son etiquetas de 32 bits adjuntas a los anuncios de rutas. Transportan información de señalización entre ASes sin modificar la ruta en sí. Una community dice «trata este prefijo de forma diferente» -- reduce su preferencia, haz prepend en el path, descártalo por completo o anúncialo solo a peers específicos. Las communities son transitivas: se propagan a través de las sesiones BGP a menos que se eliminen explícitamente. Existen tres tipos: standard (RFC 1997), extended (RFC 4360) y large (RFC 8092).

Las communities resuelven un problema de coordinación. Sin ellas, cada decisión de política de enrutamiento requiere configuración bilateral en ambos lados de una sesión. Con communities, tu upstream o route server del IX lee tus etiquetas y aplica la política que solicitaste. Etiquetas una vez, la red actúa.

Si necesitas primero la configuración de una sesión BGP, consulta BIRD2 BGP Configuration on Linux o FRR BGP Configuration on Linux.

¿Cuáles son los tres tipos de BGP communities?

Difieren en tamaño, codificación y los problemas que resuelven. Las standard communities cubren la mayoría de los casos, pero fallan con ASNs de 4 bytes. Las large communities solucionan esa limitación. Las extended communities sirven para aplicaciones especializadas del plano de control.

Propiedad	Standard (RFC 1997)	Large (RFC 8092)	Extended (RFC 4360)
Tamaño	32 bits	96 bits (3 x 32 bits)	64 bits
Formato	ASN:value	ASN:value1:value2	type:subtype:value
Soporte de ASN	Solo 2 bytes	4 bytes nativo	2 bytes o 4 bytes (depende del tipo)
Atributo BGP	COMMUNITIES (8)	LARGE_COMMUNITIES (32)	EXTENDED COMMUNITIES (16)
Uso principal	Señalización upstream, ingeniería de tráfico	Igual que standard, compatible con ASN de 4 bytes	MPLS VPN, EVPN, route targets
Adopción	Universal	Generalizada desde ~2018	Específica de protocolo

Standard communities (RFC 1997)

Las standard communities son valores de 32 bits escritos como dos enteros de 16 bits separados por dos puntos: ASN:value. Los 16 bits de orden alto identifican el AS que define el significado de la community. Los 16 bits de orden bajo contienen la acción o información.

Ejemplo: 174:70 significa «Cogent: establecer local preference a 70». Solo Cogent define qué significa el valor 70 en el espacio de nombres 174. Cada proveedor publica sus propias definiciones de communities.

El campo ASN de 16 bits limita las standard communities a ASNs de 2 bytes (0-65535). Con más de 120 000 ASNs asignados a fecha de 2026, la mayoría de las nuevas asignaciones son números de 4 bytes. Las standard communities no pueden representarlos.

IANA reserva el rango 65535:0 a 65535:65535 para communities bien conocidas (well-known).

Large communities (RFC 8092)

Las large communities usan tres enteros de 32 bits: Global Administrator : Local Data 1 : Local Data 2. El global administrator es el ASN de la red que define la community. Ambos campos de datos locales son definidos por el operador.

Este formato resuelve el problema de los ASN de 4 bytes. Un AS con número 398465 puede definir 398465:100:0 como una large community válida. Las standard communities no pueden codificar esto.

La estructura de tres campos también permite semánticas más ricas. Un patrón habitual es ASN:función:parámetro -- por ejemplo, 35661:1010:174 podría significar «prepend una vez en Frankfurt hacia Cogent (AS174)».

El soporte de large communities está disponible en BIRD 1.6.3+, BIRD2, FRR 3.0+, OpenBGPD 6.1+, GoBGP, Cisco IOS-XR 6.2.1+ y Junos 17.3+. Si tu daemon BGP fue publicado después de 2018, casi con seguridad las soporta.

Extended communities (RFC 4360)

Las extended communities son valores de 64 bits con un campo de tipo, un campo de subtipo y un valor. A diferencia de las standard y large communities, las extended communities tienen semánticas estructuradas: el tipo y subtipo definen cómo debe interpretarse el valor.

Las extended communities se encuentran principalmente en:

• MPLS L3VPN: Los route targets (rt 65000:100) y los route distinguishers controlan la importación/exportación de VRFs
• EVPN: MAC mobility, ESI labels y tipos de ruta
• BGP Flowspec: Limitación de tasa de tráfico y acciones de redirección

Para ingeniería de tráfico entre ASes, las standard y large communities son las herramientas adecuadas. Las extended communities son relevantes cuando ejecutas servicios overlay. Este artículo se centra en las standard y large communities en las secciones restantes.

¿Cuáles son las BGP communities bien conocidas?

IANA define varios valores de communities bien conocidos (well-known) en el rango reservado 65535:*. Toda implementación BGP conforme debe entenderlos.

Community	Valor	Hex	Comportamiento	RFC
NO_EXPORT	65535:65281	0xFFFFFF01	No anunciar fuera de la confederación AS local	1997
NO_ADVERTISE	65535:65282	0xFFFFFF02	No anunciar a ningún peer BGP	1997
NO_EXPORT_SUBCONFED	65535:65283	0xFFFFFF03	No anunciar fuera del AS local	1997
NOPEER	65535:65284	0xFFFFFF04	No anunciar a peers bilaterales	3765
BLACKHOLE	65535:666	0xFFFF029A	Solicitar blackhole del prefijo etiquetado	7999
GRACEFUL_SHUTDOWN	65535:0	0xFFFF0000	Señalar apagado planificado de sesión, establecer local-pref a 0	8326

NO_EXPORT es la más utilizada. Etiqueta un prefijo con ella y tu peer no lo re-anunciará más allá de la frontera de su AS. Así es como se controlan las fugas de rutas (route leaks) hacia terceros.

BLACKHOLE y GRACEFUL_SHUTDOWN se cubren en detalle en las secciones de ingeniería de tráfico más adelante.

¿Cómo permiten las BGP communities la ingeniería de tráfico?

Las communities te permiten influir en las decisiones de enrutamiento en redes que no controlas. No puedes conectarte a los routers de tu upstream y cambiar su configuración. Pero puedes etiquetar tus anuncios con communities que ellos han aceptado honrar. Esto es ingeniería de tráfico BGP vía communities.

¿Cómo funciona la señalización de local preference con communities?

La mayoría de los proveedores de tránsito ofrecen communities que establecen el local preference de tu prefijo dentro de su red. Un local preference más alto significa «preferir esta ruta». Un valor más bajo significa «usar esto solo como respaldo».

Por ejemplo, un proveedor con AS 64500 podría definir:

Community	Efecto
64500:100	Preferencia normal (por defecto)
64500:90	Preferencia baja (ruta de respaldo)
64500:150	Preferencia alta (ruta preferida)

Al etiquetar tu anuncio con 64500:90 cuando lo envías a un upstream y dejar el valor por defecto en otro, sesgas el tráfico entrante hacia el upstream sin la community de respaldo. Esto funciona porque el local preference se evalúa antes de la longitud del AS-path en el proceso de decisión BGP.

Consulta la documentación de communities de tu proveedor. Los valores anteriores son ilustrativos. Cada proveedor define su propio esquema.

¿Cómo funciona el BGP prepending con communities?

El AS-path prepending infla artificialmente la longitud del path para hacer una ruta menos preferida por las redes remotas. En lugar de hacer prepending en tu propio router (lo que afecta a todos los peers por igual), las communities te permiten solicitar prepending de forma selectiva.

Un esquema típico de proveedor:

Community	Efecto
64500:1001	Prepend 1x hacia todos los peers
64500:1002	Prepend 2x hacia todos los peers
64500:1003	Prepend 3x hacia todos los peers

Con large communities, el objetivo puede ser más específico:

Large community	Efecto
64500:1:174	Prepend 1x hacia Cogent (AS174)
64500:2:174	Prepend 2x hacia Cogent (AS174)
64500:3:0	Prepend 3x hacia todos los peers

Esta granularidad es la razón por la que las large communities están reemplazando a las standard para ingeniería de tráfico. El tercer campo codifica el ASN de destino o el grupo de peers.

¿Cómo funciona el BGP blackholing con la community BLACKHOLE?

El blackholing indica a las redes upstream que descarten todo el tráfico destinado a un prefijo etiquetado. Es una herramienta de mitigación DDoS: cuando una IP está bajo ataque, la anuncias con la community BLACKHOLE y tus upstreams hacen null-route del tráfico antes de que llegue a tu red.

RFC 7999 estandariza la community bien conocida 65535:666 para este propósito.

Requisitos para que el blackholing funcione:

1. Especificidad del prefijo. Anuncia un /32 (IPv4) o /128 (IPv6) para la IP objetivo. Nunca hagas blackhole de un /24 completo.
2. Acuerdo bilateral. Tu upstream debe estar configurado para honrar la community BLACKHOLE. Esto no es automático. Verifica con tu proveedor.
3. Etiquetado NO_EXPORT. Siempre añade NO_EXPORT junto con BLACKHOLE para evitar que el blackhole se propague más allá de tu upstream inmediato.
4. Monitorización. El blackholing descarta todo el tráfico, legítimo y malicioso. Monitoriza y retira el anuncio en cuanto el ataque cese.

La mayoría de los route servers de IXP también soportan blackholing vía 65535:666. El route server establece el next-hop a una dirección de blackhole y añade NO_EXPORT antes de la redistribución.

¿Cómo se usan las communities para anuncio selectivo?

El anuncio selectivo te permite controlar qué peers o IXPs ven tu prefijo. Es el patrón «no anunciar a» o «anunciar solo a».

Las implementaciones habituales usan un modelo de denegación/permiso:

Community	Efecto
64500:0:0	No anunciar a nadie (denegación global)
64500:0:174	No anunciar a Cogent
64500:8:174	Anunciar solo a Cogent (anula la denegación)

Con Virtua (AS35661), esto usa el esquema de communities por ubicación descrito en la tabla de referencia más adelante.

¿Cómo funciona el graceful shutdown con la community GRACEFUL_SHUTDOWN?

RFC 8326 define la community GRACEFUL_SHUTDOWN (65535:0) para mantenimiento planificado. Cuando necesitas desactivar una sesión BGP, etiquetar tus rutas con esta community indica a los routers receptores que bajen el local preference a 0 y empiecen a preferir rutas alternativas antes de que desconectes.

La secuencia:

1. Añadir la community GRACEFUL_SHUTDOWN a todas las rutas enviadas al peer en mantenimiento
2. Esperar la convergencia (las rutas se desplazan a paths alternativos)
3. Apagar la sesión BGP
4. Realizar el mantenimiento
5. Restablecer la sesión
6. Eliminar la community

Sin graceful shutdown, desmontar una sesión causa la retirada inmediata de rutas. El tráfico se interrumpe hasta que BGP converge en la ruta alternativa. Con graceful shutdown, el tráfico se desplaza gradualmente antes de que la sesión se apague.

Esto se relaciona directamente con las estrategias de failover en multi-homing.

¿Cómo configuro las BGP communities en BIRD2?

BIRD2 usa atributos de community tipados en los objetos de ruta. Los tres atributos relevantes son:

Atributo	Tipo	Tipo de community
bgp_community	clist (lista de pares)	Standard
bgp_large_community	lclist (lista de tripletas)	Large
bgp_ext_community	eclist (lista extendida)	Extended

Añadir communities en BIRD2

Usa el método .add() en bloques de filtro:

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

Filtrar communities en BIRD2

Comprueba la pertenencia con el operador ~:

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

El operador ~ devuelve verdadero si el operando izquierdo es miembro del operando derecho. Para coincidencia con conjuntos, usa patrones de pares/tripletas con * como comodín.

Eliminar communities en BIRD2

Limpia las communities en la entrada para evitar señalización no autorizada:

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

Receptor de graceful shutdown en 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;
}

Aplica ebgp_inbound como filtro de importación en todas las sesiones EBGP. Cuando un peer envía la community GRACEFUL_SHUTDOWN, esto establece el local preference a 0, haciendo que tu router prefiera cualquier ruta alternativa.

Disparador de blackhole en 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;
}

¿Cómo configuro las BGP communities en FRR?

FRR usa definiciones community-list al estilo IOS y acciones route-map. Las communities se filtran con cláusulas match y se establecen con cláusulas set.

Definir community lists en 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 soporta tanto community lists numeradas (1-99 para standard, 100-500 para expanded) como con nombre. Las listas con nombre son más fáciles de mantener.

Establecer communities en route-maps de FRR

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

La palabra clave additive añade communities en lugar de reemplazar el conjunto existente. Sin ella, set community sobrescribe todas las communities existentes.

Filtrar communities en route-maps de FRR

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

Eliminar communities en 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:.*:.*

Esto elimina cualquier community en el espacio de nombres de tu ASN que un peer podría inyectar. Aplica este route-map como neighbor <peer> route-map SCRUB-INBOUND in.

Graceful shutdown en FRR

FRR proporciona un comando integrado:

router bgp 35661
 bgp graceful-shutdown

Esto añade automáticamente la community GRACEFUL_SHUTDOWN (65535:0) a todas las rutas enviadas a todos los peers EBGP. Úsalo antes de un mantenimiento planificado.

En el lado receptor, aplica un route-map que filtre la community y baje el local preference:

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

Comparación de configuración de communities entre BIRD2 y FRR

Operación	BIRD2	FRR
Añadir standard community	bgp_community.add((ASN, val))	set community ASN:val additive
Añadir large community	bgp_large_community.add((ASN, v1, v2))	set large-community ASN:v1:v2 additive
Filtrar standard community	if (ASN, val) ~ bgp_community	match community LIST_NAME
Filtrar large community	if (ASN, v1, v2) ~ bgp_large_community	match large-community LIST_NAME
Eliminar por patrón	bgp_community.delete([(ASN, *)])	set comm-list LIST_NAME delete
Coincidencia con comodín	[(ASN, *)] en expresión de conjunto	Community-list expanded con regex
Aplicar filtro	import filter name; en protocolo	neighbor X route-map NAME in

BIRD2 gestiona las operaciones de communities inline dentro de funciones de filtro. FRR separa la definición (community-list) de la acción (route-map). Ambos enfoques funcionan. La sintaxis inline de BIRD2 es más concisa para lógica con condicionales. El modelo separado de FRR es más legible para políticas simples de tipo match-and-set.

¿Cuáles son los valores de BGP communities de Virtua?

Virtua (AS35661) soporta tanto standard como large BGP communities. Las large communities siguen el formato 35661:ACCIÓN_UBICACIÓN:OBJETIVO. El esquema de communities tiene en cuenta la ubicación, permitiéndote controlar anuncios por POP, por tipo de peer o por ASN de peer específico.

Códigos de ubicación

Código	Ciudad	País	POP ID
000	París	Francia	PAR01FR
001	Lille	Francia	LIL01FR
010	Frankfurt	Alemania	FRA01DE
020	Ámsterdam	Países Bajos	AMS01NL
999	Todas las ubicaciones	--	ALL

Communities de acción

Acción	Formato large community	Efecto
Origen de ruta	35661:0[LOC]:TARGET	Informativo: identifica dónde se aprendió la ruta
Prepend 1x	35661:1[LOC]:TARGET	Prepend AS35661 una vez hacia el objetivo
Prepend 2x	35661:2[LOC]:TARGET	Prepend AS35661 dos veces hacia el objetivo
Prepend 3x	35661:3[LOC]:TARGET	Prepend AS35661 tres veces hacia el objetivo
Exportar solo	35661:8[LOC]:TARGET	Anula la denegación: anunciar solo al objetivo
No exportar	35661:9[LOC]:TARGET	No anunciar al objetivo

Selectores de objetivo

Valor del objetivo	Significado
0	Todos los peers en la ubicación especificada
1	Solo peers de tránsito
2	Solo peers de IX
ASN específico	Un solo peer (p. ej., 174 para Cogent)

Reglas de precedencia

Cuando varias communities entran en conflicto, Virtua las evalúa en este orden (mayor prioridad primero):

1. 35661:8[LOC]:ASN -- permiso explícito para un peer específico
2. 35661:9[LOC]:ASN -- denegación para un peer específico
3. 35661:9[LOC]:1 o 35661:9[LOC]:2 -- denegación para grupo de peers (tránsito o IX)
4. 35661:9[LOC]:0 -- denegación para todos los peers en una ubicación
5. 35661:9999:0 -- denegación global (no anunciar en ningún sitio)

Ejemplos con communities de Virtua

Anunciar en todas partes excepto a Cogent en Frankfurt:

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

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

Anunciar solo a peers IX en todas las ubicaciones:

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

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

Prepend 2x hacia todos los peers en París:

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

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

Para más información sobre la configuración BGP con Virtua, consulta BGP Bring Your Own IP on a VPS.

¿Cómo verifico las BGP communities en una ruta?

Verificar en BIRD2

birdc show route for 203.0.113.0/24 all

Busca los atributos BGP.community y BGP.large_community en la salida:

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

Verificar en FRR

vtysh -c "show ip bgp 203.0.113.0/24"

La salida incluye una línea Community::

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

Verificar con herramientas externas

No puedes ver las communities solo desde dentro de tu red. Usa looking glasses externos para verificar lo que ve el resto de internet:

• bgp.tools: Busca tu prefijo y revisa la pestaña «Communities». Muestra communities tal como las ven múltiples colectores en todo el mundo.
• RIPE Stat: El widget «BGP Looking Glass» muestra atributos de communities desde los colectores RIPE RIS.
• NLNOG Looking Glass: Consulta desde nodos NLNOG RING a través de múltiples ASes.

Verifica siempre desde fuera. Una community puede estar configurada correctamente en tu router pero ser eliminada por una red intermedia.

¿Cómo debo gestionar la seguridad de las communities?

Las communities son transitivas por defecto. Cualquier red en la ruta puede leerlas, añadirlas o eliminarlas. Esto genera riesgos de seguridad si no filtras correctamente.

Eliminar communities entrantes en tu espacio de nombres ASN

Si un peer te envía una ruta etiquetada con tus propias communities (p. ej., 35661:9999:0), y no la limpias, tus propios filtros de exportación podrían respetarla. Esto podría hacer que dejes de anunciar el prefijo por completo.

Limpia siempre tu propio espacio de nombres de communities en la importación:

# 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

Validar solicitudes de blackhole

Nunca honres 65535:666 de cualquier peer sin verificar. Un peer malicioso o mal configurado podría hacer blackhole de los prefijos de tus clientes.

Reglas para aceptar blackholes:

• Solo aceptar rutas con blackhole para prefijos que el peer está autorizado a originar
• Verificar la validez RPKI/ROA antes de honrar el blackhole (ver RPKI ROA Setup for BGP)
• Limitar la longitud de prefijo aceptada a /32 (IPv4) y /128 (IPv6) para blackholes
• Siempre añadir NO_EXPORT a las rutas de blackhole antes de redistribuir

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

Eliminar communities en la exportación cuando sea apropiado

Antes de anunciar rutas a peers, elimina las communities que no deberían ver o sobre las que no deberían actuar:

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

La seguridad de communities es parte de una estrategia más amplia de filtrado de rutas. Consulta BGP Route Filtering and Security para el panorama completo.

¿Algo salió mal?

Las communities no aparecen en looking glasses remotos. Tu upstream podría estar eliminándolas. Comprueba si la community está en un espacio de nombres que ellos honran. Algunos proveedores eliminan todas las communities de terceros por defecto.

El blackhole no funciona. Verifica la longitud del prefijo (se requiere /32 o /128). Confirma que tu upstream soporta RFC 7999. Comprueba si se está añadiendo NO_EXPORT -- sin él, el blackhole puede propagarse más de lo previsto y ser eliminado.

Las large communities no se propagan. Implementaciones BGP antiguas descartan silenciosamente atributos desconocidos. Si un AS intermedio ejecuta software anterior al soporte de RFC 8092, las large communities se perderán. Revisa el AS path e identifica la red que las descarta.

Errores de sintaxis en filtros BIRD2. Los pares de communities usan paréntesis, no dos puntos: (35661, 100) y no 35661:100. Las large communities son tripletas: (35661, 100, 200). La notación con dos puntos es solo para visualización y CLI.

La community-list de FRR no filtra. Las community lists con nombre deben referenciarse exactamente como fueron definidas. Busca erratas. Usa show bgp community-list para verificar el contenido de la lista.

Las communities se sobrescriben en lugar de añadirse en FRR. Falta la palabra clave additive en set community o set large-community. Sin ella, se reemplazan todas las communities existentes. Usa siempre additive a menos que quieras sobrescribir intencionalmente.

Revisa los logs para problemas de sesión BGP:

# BIRD2
journalctl -u bird -f

# FRR
journalctl -u frr -f

Copyright 2026 Virtua.Cloud. Todos los derechos reservados. Este contenido es una obra original del equipo de Virtua.Cloud. La reproducción, republicación o redistribución sin permiso escrito está prohibida.