BGP sobre IPsec en Meraki
Contenido complementario
Este tema no está en las notas de mis cursos; está armado con la documentación oficial de Meraki (consultada en octubre de 2026) y mis notas de BGP. Valores de IP y AS de ejemplo. 🔎 Verificar = no confirmado en documentación.
Pendiente: validar en el lab
Este contenido no salió de mis clases. Probar estos pasos en el Dashboard antes de usarlos en un trabajo real, y corregir lo que difiera en mi versión.
Resumen
El MX puede establecer una sesión eBGP dentro de un túnel IPsec con un peer no-Meraki, de modo que las rutas se aprenden y anuncian dinámicamente en vez de listar subredes a mano. Es el diseño que mejor escala: agregar una subred deja de exigir cambios en ambos extremos. Además es la forma de lograr que los spokes de Auto VPN alcancen al peer no-Meraki. Se apoya en lo que ya sabes de BGP (ver 01 - BGP Overview y 01 - Configuracion eBGP & Multihop); lo nuevo es que la sesión corre por un túnel route-based y que la configuración vive en el Dashboard.
Requisitos previos
- IKEv2 y MX ≥ 19.1.4
- Peer route-based (en Palo Alto: Tunnel Interface, ver BGP sobre IPsec PA a Meraki)
- Una subred /30 para el túnel: una IP para el MX y otra para el peer
- TCP 179 permitido en las reglas de firewall site-to-site de salida si tienes reglas deny
- Red sin plantilla: BGP no está soportado en redes de plantilla
- AS privados distintos en cada lado (eBGP)
Conceptos clave
graph LR LANM["LAN Meraki<br/>10.1.0.0/24"] --- MX["MX<br/>AS 65001<br/>10.255.0.2/30"] MX == "IPsec IKEv2 + eBGP" === PA["Palo Alto<br/>AS 65002<br/>tunnel.1 10.255.0.1/30"] PA --- LANP["LAN PA<br/>10.10.0.0/24"]
| Atributo | Efecto | Se aplica sobre |
|---|---|---|
| Weight (0–49) | Preferencia local de rutas aprendidas (mayor = preferida). Solo afecta al MX | Entrada |
| AS path prepending | Influye en la ruta que elige el peer (camino más corto gana) | Salida |
| MED | Influye en la ruta que elige el peer (menor gana) | Salida |
| Hold timer | 240 s por defecto; se negocia y ambos usan el menor | Sesión |
Compáralo con tus notas de BGP: Meraki simplifica a weight (equivale a weight/local-preference de Cisco), prepend y MED.
Qué se anuncia
- El MX anuncia las subredes con VPN mode = Enabled (y las que aprendió por Auto VPN, lo que da tránsito entre Auto VPN y el peer).
- Las rutas estáticas definidas en un MX en modo Passthrough no se exportan al peer eBGP.
- El peer aparece en gris en Security & SD-WAN → Configure → Routing y solo se puede quitar desde la página Site-to-site VPN donde se creó.
Lo que NO se combina con BGP
- Túneles primario/secundario: no están soportados en peers con BGP sobre IPsec (documentación de Meraki). La redundancia se diseña con BGP y varios peers/uplinks. 🔎 Verificar.
- Health checks de capa 7: solo en túneles estáticos, no en rutas dinámicas BGP.
- Redes con plantilla: BGP no soportado.
Multihop
En firmware 19.1 el vecino necesita multihop (en el MX viene habilitado por defecto); desde 19.2 ya no hace falta. En el Palo Alto, si tu MX es 19.1, configura
Multi Hopen el peer BGP (ver BGP sobre IPsec PA a Meraki).
Configuración (Ejemplo)
1. Peer IPsec con routing dinámico
En el peer (Non-Meraki VPN peers). 🔎 Verificar los nombres exactos.
- IKE version = IKEv2, política y PSK como en Non-Meraki VPN Peers (IPsec).
- Routing = Dynamic (BGP).
- IPsec subnet = el /30 (por ejemplo
10.255.0.0/30). - BGP source IP (MX) y BGP neighbor IP (peer): ambas dentro del /30.
- Remote AS (AS del Palo Alto).
- Opciones por peer: weight, AS path prepending, MED, hold timer.
- Network: la red SD-WAN que participa (reemplaza la tag de Availability en los peers dinámicos).
2. Configuración del otro extremo
El Dashboard muestra un apartado Configuration for remote peer con lo que debe configurar el otro lado para el vecino BGP. Úsalo como referencia para el Palo Alto.
3. Los mismos campos por API
El endpoint de peers no-Meraki (thirdPartyVPNPeers) expone isRouteBased y un objeto ebgpNeighbor con neighborIp, sourceIp, remoteAsNumber, ebgpHoldTimer, ebgpMultihop, weight, pathPrepend y multiExitDiscriminator. Según la referencia de la API: isRouteBased requiere MX 19.1 o superior, ebgpHoldTimer va de 12 a 240 s, ebgpMultihop de 1 a 255 y pathPrepend admite hasta 10 ASN. Úsalo para auditar o comparar peers (ver Troubleshooting VPN Meraki).
Verificación
| Comando o lugar | Qué debes ver | Si no lo ves |
|---|---|---|
| VPN status | El túnel IPsec en verde (BGP no forma sin el túnel arriba) | Primero arregla el túnel: Troubleshooting VPN Meraki |
| Dynamic Protocol Status | Vecino establecido y cantidad de rutas | Ver Errores comunes |
| Monitor → Route table | Las subredes del Palo Alto | El PA no las anuncia |
| Lado PA | Ver BGP sobre IPsec PA a Meraki | — |
Errores comunes
El túnel está arriba pero BGP no establece
- Causa: falta TCP 179 en las reglas site-to-site, /30 mal puesto, AS remoto incorrecto, o falta multihop con 19.1.
- Solución: corrige el dato y espera a que el vecino se establezca.
Las rutas llegan pero no hay tráfico
- Causa: falta política de seguridad o NAT exemption en el Palo Alto.
- Solución: revisa Troubleshooting IPsec PA a Meraki.
Un spoke de Auto VPN no ve al Palo Alto
- Causa: el MX no re-anuncia los prefijos de los spokes, o el PA no los acepta.
- Solución: confirma que el peer anuncia las rutas de los spokes y que el PA las tiene.
Quiero BGP en una red con plantilla
- Causa: no está soportado.
- Solución: usa una red sin plantilla para el MX que hace BGP.