Skip to main content
Cisco Meraki Documentation

BGP routing over IPsec VPN

This article outlines how to configure BGP routing over IPsec VPN peers.

BGP Routing over IPsec VPN

BGP peering over IPsec VPN tunnels can be enabled on the Meraki Security Appliance. This unlocks new dynamic routing use cases for customers in addition to enabling resiliency and redundancy over IPsec VPN peers. 

Prerequisites

  • IKEv2 setting

  • MX 19.1.4 or newer release

  • MX platforms that support MX 19.1 firmware and above

  • BGP - TCP port 179 permitted on your VPN firewall

  • BGP enabled

Configuring eBGP over IPsec

When you add an IPsec VPN peer, under Routing you have - Static and Dynamic. With Dynamic selected, you see the following configuration options:

  1. Routing – Dynamic (BGP)
     

  2. Network – Select the name of the Meraki SD-WAN network you want to configure. This field replaces the availability tag for dynamically routed peers.
     

  3. IPsec subnet – This is a /30 IPsec subnet required and used for eBGP peering.

     

  4. BGP Source IP – This is the local BGP IP the Meraki SD-WAN device will use for BGP peering. This IP should fall within the /30 IPsec subnet configured above.
     

  5. BGP Neighbor IP – This is BGP IP of the remote peer. This IP should fall within the /30 IPsec subnet configured above.
     

  6. Remote AS – This is the ASN of the remote peer.
     

  7. Weight - BGP attribute 0-49. Weight is only local to the MX device to manipulate inbound route priority, a higher weight means more preferred path.
     

  8. Path Prepending - This is used to manipulate remote peer path decisions, a shorter AS path is preferred to a longer one. If a remote peer has two paths to your branch, AS path can be used to influence what path the remote site takes to reach your branch.
     

  9. Multi-Exit discriminator (MED) - This is used to manipulate remote peer path decisions, a lower MED is preferred to a higher one. If a remote peer has two paths to your branch, MED can be used to influence what path the remote site takes to reach your branch.

     

  10. Multi-hop - This is enabled by default and required for peering with next-hop that are not directly connected.

     

  11. Hold timer - By default, our hold-down timer is set to 240 sec, this timer is negotiated between BGP peers, and the lower of the two is used by both peers.

     

  12. BGP configuration should be used to configure the BGP neighbor peering with the MX Appliance.

Screenshot 2024-08-20 at 12.40.59 PM.png

BGP peer will show up grayed out on the Security & SD-WAN > Routing page, and can only be removed when the peer is deleted via the Site-to-Site VPN page.

Screenshot 2024-08-28 at 11.38.03 AM.png

Verifying Connectivity

An IPsec tunnel is formed before the eBGP peering relationship is formed. Hence, to verify BGP neighborship, First verify that the IPsec tunnel is up. We can verify by navigating to Security & SD-WAN > VPN Status – Non Meraki VPN tab.  

Here we can see the status of the IPsec tunnel.

VPN status indicator

Meaning

Green 

Phase 1 and phase 2 are up. 

Amber

Phase 1 is up but phase 2 is down 

Red

Phase 1 and phase 2 are both down. 

If we see a Green indicator, it means the IPsec tunnel is up. 
Next, we navigate to the Dynamic protocol status page to see if the eBGP peering relationship with our remote peer is up. An Established peer status indicates that the BGP neighbor relationship is established, and the “Routes” column indicates how many routes have been learned from the BGP neighbor. 

Screenshot 2024-08-29 at 9.43.54 AM.png

The exact routes learned can viewed on the Security & SD-WAN > Route table page

  • Was this article helpful?