BGP communities: la herramienta de ingeniería de tráfico que la mayoría de los ISPs en Latam no usa bien
BGP tiene una característica que muchos operadores conocen en teoría pero pocos aprovechan en su totalidad: las BGP communities. Son atributos opcionales que se adjuntan a los prefijos anunciados y permiten tomar decisiones de ruteo sofisticadas sin modificar la topología física de la red ni alterar métricas como el MED o el local-preference de forma manual en cada router.
En la práctica, lo que vemos en redes latinoamericanas es uno de tres escenarios: communities no implementadas, communities implementadas a medias sin documentación coherente, o communities que se propagan hacia peers y upstreams cuando no deberían. Los tres escenarios tienen consecuencias operativas reales.
Este artículo cubre qué son, para qué sirven, cómo diseñar un esquema coherente, y cómo configurarlas en Huawei VRP.
Qué son las BGP communities y por qué existen tres tipos
Una BGP community es un atributo de 32 bits que se transporta como parte de un anuncio BGP. No tiene efecto por sí solo: su valor solo importa cuando los routers que reciben el prefijo tienen políticas configuradas para actuar en función de ese valor.
Existen tres variantes:
Standard communities (RFC 1997): El formato clásico, representado como ASN:valor donde cada campo ocupa 16 bits. Por ejemplo, 65001:100. La limitación es que el campo ASN está restringido a 16 bits, lo que crea ambigüedad en redes con ASNs de 32 bits (4-byte AS). Siguen siendo el estándar más interoperable y el que prácticamente todos los routers entienden.
Extended communities (RFC 4360): 64 bits de largo, con un campo de tipo que define cómo interpretar los restantes bits. Se usan principalmente en contextos específicos como MPLS VPN (Route Targets y Route Distinguishers) y en algunas implementaciones de QoS. Para ingeniería de tráfico general entre ISPs, son menos comunes que las standard.
Large communities (RFC 8092): El formato moderno para redes con ASNs de 32 bits. Representadas como tres campos de 32 bits: ASN-global:función:parámetro. Por ejemplo, 65001:1:200 podría significar “ruta aprendida de upstream 200”. Son el formato recomendado para esquemas nuevos y están bien soportadas en el software actual (Huawei VRP, Juniper Junos, FRR, BIRD).
La elección entre standard y large communities depende principalmente del parque de equipos. Redes que usan equipos relativamente modernos pueden adoptar large communities desde el inicio. Redes con equipos legados o con peers que no soporten large communities suelen mantener las standard por compatibilidad.
El problema que resuelven: influencia de tráfico sin modificar la topología
Imaginá que tu red tiene dos upstreams: un transit provider A con buena conectividad hacia Brasil y un transit provider B con mejor cobertura hacia Europa. Sin communities, influir sobre qué tráfico sale por cada upstream requiere modificar el local-preference manualmente en los route-maps de cada router de borde, para cada prefijo o grupo de prefijos.
Con communities, el proceso se puede centralizar: cada prefijo recibido de cualquier fuente se marca con una community que indica su origen. Las políticas de local-preference (y por lo tanto de selección de ruta de salida) se aplican en función de esa marca. Cuando querés cambiar la política (por ejemplo, porque el transit provider B mejoró su cobertura hacia Brasil), modificás la policy en un lugar en lugar de reconfigurar router por router.
En la dirección inversa, las communities también sirven para influir sobre cómo los upstreams y peers te envían tráfico a vos. Muchos proveedores de tránsito aceptan communities bien conocidas que les instruyen a modificar el BGP local-preference o el AS-PATH prepending con el que propagan tus prefijos hacia el resto de internet. Esto te da control sobre el tráfico de entrada (inbound) sin cambiar nada en tu infraestructura física.
Casos de uso prácticos para ISPs
Traffic engineering: preferir rutas por upstream A vs B
El caso más común. Si tu AS es el 65001 y tenés dos upstreams (AS 1234 y AS 5678), podés definir un esquema de communities para indicar la preferencia de salida:
65001:200en un prefijo de cliente: salir preferentemente por upstream 123465001:201en un prefijo de cliente: salir preferentemente por upstream 567865001:100en un prefijo de cliente: rutas internas de alta prioridad (local-preference 200)
El route-map de entrada en cada upstream evalúa estas communities y asigna el local-preference correspondiente. El resultado es que podés ajustar el ruteo de salida para distintos bloques de clientes simplemente modificando qué community se adjunta al prefijo, sin tocar la topología.
También se puede hacer a la inversa: usar las communities que ofrecen tus upstreams para controlar cómo ellos propagan tus prefijos. Por ejemplo, muchos grandes transit providers aceptan X:0 para indicar que no deben propagar un prefijo a nivel global, o X:Y para limitar la propagación a una región específica. Documentar qué communities acepta cada uno de tus upstreams es parte del trabajo de ingeniería de tráfico que marca la diferencia entre una red reactiva y una red gestionada.
Blackholing remoto (RTBH) para mitigar DDoS
El Remote Triggered Blackhole (RTBH) es uno de los usos más valiosos de las communities para operadores bajo presión de un ataque DDoS. El mecanismo es conceptualmente simple: anunciás un prefijo específico (el IP o bloque atacado) con una community que instruye a tus upstreams y peers a descartar el tráfico destinado a ese prefijo en su infraestructura, antes de que llegue a la tuya.
La community estándar para RTBH está definida en el RFC 7999 — BLACKHOLE Community: 65535:666. Este RFC, publicado en octubre de 2016, estandarizó una práctica que ya existía informalmente entre operadores, estableciendo 65535:666 como la community well-known universal para señalizar blackhole. Antes del RFC 7999, cada transit provider y cada IXP definía su propia community para RTBH (por ejemplo, transit-asn:666), lo que generaba fragmentación y complejidad operativa. Con la estandarización, un solo anuncio con 65535:666 es reconocido por la mayoría de los grandes transit providers, IXPs y redes de contenido.
Al anunciar un /32 (o /128 en IPv6) con esta community adjunta, estás pidiendo a tus vecinos BGP que instalen una ruta hacia ese destino apuntando a Null0 o Discard. El tráfico se descarta en el borde del upstream, no en tu red. El RFC 7999 también recomienda que la ruta blackhole se anuncie con el atributo NO_EXPORT (65535:65281) para evitar que se propague más allá de lo necesario.
La secuencia operativa es:
- Detectar el destino bajo ataque (idealmente con NetFlow/sFlow o sistemas de detección de anomalías)
- Generar el anuncio BGP del prefijo atacado con
65535:666adjunto - Propagarlo hacia upstreams que soporten RTBH
- Monitorear la caída del volumen de ataque
El costo es que el IP o bloque atacado queda inalcanzable (el tráfico legítimo también se descarta). Pero en un ataque volumétrico serio, eso es mejor que perder toda la conectividad de la red. Muchos ISPs implementan esto de forma manual y tardía. Los que tienen el mecanismo automatizado pueden reaccionar en segundos.
La configuración del RTBH también puede hacerse internamente (iBGP blackhole) para descartar el tráfico en el borde de tu propia red, antes de que llegue al servicio atacado. Ambas variantes son complementarias.
Marcado de rutas por origen: customer, peer, upstream, internal
Esta es la base de una política de ruteo bien diseñada. Cada prefijo que entra a tu red debería llevar una marca que identifique su origen:
| Origen | Community ejemplo |
|---|---|
| Cliente (customer) | 65001:1000 |
| Peer (IXP o bilateral) | 65001:2000 |
| Upstream / transit | 65001:3000 |
| Ruta interna | 65001:4000 |
Con este esquema, las decisiones de exportación se vuelven políticas simples y auditables: “a mis upstreams, solo exporto prefijos con community 65001:1000 (clientes) y mis propios prefijos”. Ninguna ruta de peer o upstream debería propagarse a otro upstream. Eso evita route leaks (que describimos en detalle en nuestro artículo sobre errores de configuración BGP).
Políticas de no-export, no-advertise y blackhole
El RFC 1997 y el RFC 7999 definen well-known communities con semántica estandarizada que todos los routers BGP deben respetar:
NO_EXPORT(65535:65281): No propagués este prefijo fuera de la confederación o AS. Se usa para rutas que deben permanecer locales a tu red.NO_ADVERTISE(65535:65282): No propagués este prefijo a ningún vecino BGP. El prefijo se usa localmente para tomar decisiones de ruteo pero no se redistribuye.NO_EXPORT_SUBCONFED(65535:65283): Similar a NO_EXPORT pero aplica a nivel de sub-confederación.BLACKHOLE(65535:666): Definida por el RFC 7999, indica que el tráfico hacia este prefijo debe descartarse (blackhole). Es la community estándar para RTBH y es reconocida por la mayoría de los grandes transit providers y puntos de intercambio de tráfico (IXPs).
Las tres primeras son especialmente útiles para controlar la propagación de rutas de infraestructura interna (loopbacks de gestión, rangos de IPs de equipos de red) que no deberían ser visibles fuera de tu AS. La cuarta es la base del mecanismo de RTBH que se describe más arriba. El error común es no adjuntarlas y descubrir que esas rutas están siendo propagadas a peers o upstreams cuando no deberían.
Cómo documentar un esquema de communities coherente (RFC 8195)
El RFC 8195 (“Use of BGP Large Communities”) no solo define el formato técnico: también establece convenciones de documentación para que los esquemas de communities sean legibles y auditables. La estructura recomendada para large communities es:
<Global Administrator>:<Function>:<Parameter>
Donde:
- Global Administrator: Tu ASN (32 bits)
- Function: Un número que identifica el tipo de acción o información (definido por vos)
- Parameter: El valor específico dentro de esa función
Un ejemplo de esquema documentado para AS 65001:
| Community | Significado |
|---|---|
65001:1:1 |
Ruta aprendida de cliente directo |
65001:1:2 |
Ruta aprendida de peer IXP |
65001:1:3 |
Ruta aprendida de upstream transit |
65001:2:100 |
Ajustar local-preference a 100 |
65001:2:200 |
Ajustar local-preference a 200 |
65001:3:1 |
No exportar a upstreams |
65001:3:2 |
No exportar a peers |
65001:9:666 |
RTBH: descartar tráfico a este prefijo |
La clave es que este esquema viva en un documento versionado (Git es el lugar correcto), sea conocido por todo el equipo de NOC e ingeniería, y se actualice cuando cambia la política. Una community que nadie recuerda qué significa es peor que ninguna: genera falsa confianza.
Errores comunes: communities que se propagan cuando no deberían
El error más frecuente que encontramos al auditar redes ISP es la propagación no controlada de communities internas. Cuando tu red asigna communities propias a los prefijos (por ejemplo, para indicar origen o prioridad), esas communities deberían eliminarse antes de propagar el prefijo hacia peers y upstreams. Si no lo hacés, estás exponiendo tu política de ruteo interna a operadores externos, lo que en el mejor caso genera confusión y en el peor caso expone información operativa sensible.
El mecanismo para evitarlo es simple: en los route-maps de exportación hacia peers y upstreams, aplicar un strip de communities antes de anunciar el prefijo.
El segundo error común es no documentar qué communities acepta tu red de tus clientes. Si un cliente envía prefijos con communities adjuntas y no tenés una política explícita de qué hacer con ellas, el router las acepta y propaga. Esto puede resultar en que un cliente influya accidentalmente (o deliberadamente) sobre tu política de ruteo.
El tercer error es más sutil: no filtrar communities en sesiones de peering en IXPs. En un punto de intercambio de tráfico, recibís prefijos de docenas de ASes. Algunos pueden traer communities que tienen significado en tu red (por coincidencia de numeración). Sin filtros explícitos, esas communities pueden afectar tus decisiones de ruteo de formas no esperadas.
Ejemplo de configuración en Huawei VRP
El siguiente ejemplo muestra la configuración de un esquema básico de communities en Huawei VRP: marcado de rutas de clientes, asignación de local-preference, y strip de communities internas al exportar a un upstream.
# Definir community-filter para identificar rutas de cliente
ip community-filter basic CLIENTES permit 65001:1000
# Route-policy de entrada desde cliente: marcar con community de origen
route-policy CLIENTE-IN permit node 10
apply community 65001:1000 additive
# Route-policy de entrada desde upstream: marcar y ajustar local-pref
route-policy UPSTREAM-IN permit node 10
apply community 65001:3000 additive
apply local-preference 100
# Route-policy de salida hacia upstream: solo exportar clientes y propios
# y eliminar communities internas antes de exportar
route-policy UPSTREAM-OUT permit node 10
if-match community-filter CLIENTES
apply community none
route-policy UPSTREAM-OUT permit node 20
if-match ip-prefix MIS-PREFIJOS-PROPIOS
apply community none
# Sesión BGP con cliente
bgp 65001
peer 203.0.113.1 as-number 64500
peer 203.0.113.1 route-policy CLIENTE-IN import
peer 203.0.113.1 route-policy CLIENTE-OUT export
# Sesión BGP con upstream
peer 198.51.100.1 as-number 1234
peer 198.51.100.1 route-policy UPSTREAM-IN import
peer 198.51.100.1 route-policy UPSTREAM-OUT export
Para configurar RTBH en Huawei VRP, el prefijo atacado se anuncia con la community 65535:666 mediante una ruta estática hacia Null0 redistribuida por BGP:
# Ruta estática hacia Null0 para el IP bajo ataque
ip route-static 203.0.113.100 255.255.255.255 NULL0
# Route-policy para redistribuir rutas RTBH con la community correcta
route-policy RTBH-OUT permit node 10
if-match ip-prefix PREFIJOS-RTBH
apply community 65535:666 additive
# En el proceso BGP, importar las rutas estáticas con la policy RTBH
bgp 65001
import-route static route-policy RTBH-OUT
Este esquema básico puede extenderse para soportar RTBH automático integrado con sistemas de detección de anomalías.
Relación con RPKI y seguridad de ruteo
Las BGP communities y RPKI resuelven problemas distintos pero complementarios. RPKI valida que el AS origen de un anuncio BGP tiene autorización criptográfica para anunciar ese prefijo. Las communities influyen sobre cómo se propagan y priorizan los prefijos una vez que ingresan a la red.
Un prefijo puede ser válido desde el punto de vista de RPKI (el AS tiene autorización) pero aun así necesitar communities para que se ruteen correctamente dentro y hacia afuera de tu red. Y un esquema de communities bien diseñado complementa RPKI al facilitar el marcado de rutas y el control de propagación que previene route leaks.
Si todavía no tenés RPKI implementado en tu red, el artículo RPKI vs Ingeniería Social: Cómo proteger tu BGP cuando el firewall humano falla es una buena lectura complementaria. Ambas herramientas forman parte de una política de ruteo madura.
Nuestra experiencia en campo
En las redes ISP que auditamos en Latinoamérica, el patrón más frecuente es el siguiente: las communities están configuradas en algún punto histórico, pero el esquema original no se documentó, la persona que lo diseñó ya no está en la organización, y nadie sabe con certeza qué hace cada community que está activa. El equipo de NOC aprende a no tocarlas por miedo a romper algo.
Eso no es ingeniería de tráfico: es deuda técnica que se acumula silenciosamente.
Un esquema de communities bien diseñado debería poder explicarse en una sola tabla, estar documentado en el mismo repositorio que las configuraciones de los routers, y ser modificable por cualquier ingeniero del equipo sin necesidad de consultar al “experto” de turno.
Si tu red opera BGP con múltiples upstreams o peers y querés revisar cómo están configuradas tus communities (qué se propaga, qué se filtra, qué se documenta), podemos hacer esa revisión con vos.
¿Querés diseñar o auditar el esquema de BGP communities de tu red?
Trabajamos con ISPs y operadores en Latinoamérica en diseño de políticas de ruteo, implementación de ingeniería de tráfico, y auditoría de configuraciones BGP.
Ver nuestros servicios de ingeniería de redes →
¿Tenés preguntas sobre BGP communities o ingeniería de tráfico en tu red? Escribinos a [email protected]
Referencias
- RFC 1997 — BGP Communities Attribute — Define el formato original de standard communities (32 bits,
ASN:valor). - RFC 4360 — BGP Extended Communities Attribute — Extended communities de 64 bits, usadas principalmente en contextos MPLS VPN.
- RFC 7999 — BLACKHOLE Community — Estandariza la community well-known
65535:666para Remote Triggered Blackhole (RTBH), unificando una práctica que existía de forma fragmentada entre operadores. - RFC 8092 — BGP Large Communities Attribute — Define el formato de large communities (tres campos de 32 bits) para redes con ASNs de 4 bytes.
- RFC 8195 — Use of BGP Large Communities — Convenciones de uso y documentación para esquemas de large communities.