Home > Security Appliances > Networks and Routing > BGP

BGP

Overview

All MX security appliances support the ability to communicate AutoVPN route information using BGP. This guide introduces key concepts, how BGP is implemented on MX appliances, and how to configure BGP.

 

The feature discussed in this article is only available in beta. If you are interested in participating in this beta, please contact your Cisco Meraki sales rep or the Cisco Meraki Support team.

Key Concepts

Before deploying BGP, it is important to understand several key concepts.

Concentrator Mode

All MXs can be configured in either NAT or VPN concentrator mode. There are important considerations for both modes. For more detailed information on concentrator modes, click here.

One-Armed Concentrator

In this mode the MX is configured with a single Ethernet connection to the upstream network. All traffic will be sent and received on this interface. This is the recommended configuration for MX appliances serving as VPN termination points into the datacenter.

NAT Mode Concentrator

BGP configuration is not available for MXs operating as NAT mode VPN concentrators.

VPN Topology

There are several options available for the structure of the VPN deployment.

Hub and Spoke

In a hub and spoke configuration, the MX security appliances at the branches and remote offices connect directly to specific MX appliances and will not form tunnels to other MX or Z1 devices in the organization. Communication between branch sites or remote offices is available through the configured VPN hubs. This is the recommended VPN topology for most deployments.

VPN Mesh

In a mesh configuration, an MX appliance at the branch or remote office is configured to connect directly to any other MXs in the organization that are also in mesh mode, as well as any spoke MXs that are configured to use it as a hub.

Datacenter Redundancy (DC-DC Failover)

Deploying one or more MXs to act as VPN concentrators in additional datacenters provides greater redundancy for critical network services. In a dual- or multi-datacenter configuration, identical subnets can be advertised from each datacenter with a VPN concentrator mode MX. 

 

In a DC-DC failover design, a spoke site will form VPN tunnels to all VPN hubs that are configured for that site. For subnets that are unique to a particular hub, traffic will be routed directly to that hub so long as tunnels between the spoke and hub are established successfully. For subnets that are advertised from multiple hubs, spokes sites will send traffic to the highest priority hub that is reachable.

 

For information on configuring DC-DC Failover, please see this article.

Warm Spare (High Availability) for VPN concentrators

When configured for high availability (HA), one MX serves as the master unit and the other MX operates in a spare capacity. All traffic flows through the master MX, while the spare operates as an added layer of redundancy in the event of failure.

 

Failover between MXs in an HA configuration leverages VRRP heartbeat packets. These heartbeat packets are sent from the Primary MX to the Secondary MX out the singular uplink in order to indicate that the Primary is online and functioning properly. As long as the Secondary is receiving these heartbeat packets, it functions in the spare state. If the Secondary stops receiving these heartbeat packets, it will assume that the Primary is offline and will transition into the master state. In order to receive these heartbeats, both VPN concentrator MXs should have uplinks on the same subnet within the datacenter.

 

Only one MX license is required for the HA pair, as only a single device is in full operation at any given time.

BGP Terminology

Border Gateway Protocol (BGP) is a highly scalable dynamic routing protocol that is used to exchange routing information between and within autonomous systems (AS).

Autonomous System (AS)

An autonomous system is a network, or group of networks, under a common administration and with common routing policies.

AS Path

The different autonomous systems traffic passes through to arrive at a specific router is its AS path. The AS path is a property of each route.

IBGP

If BGP is used to exchange routes within an autonomous system, then the protocol is referred to as Interior BGP (IBGP).

EBGP

When BGP is used between different autonomous systems, then the protocol is referred to as External BGP (EBGP).

Implementation

MX appliances use IBGP to exchange route information over Meraki AutoVPN. MXs deployed as one-armed VPN concentrator use EBGP to exchange and learn routes within the datacenter. Learned routes are redistributed to AutoVPN spokes using IBGP.

IBGP

On the Security Appliance > Configure > Site-to-site VPN settings page, BGP configuration is available for one-armed VPN concentrator MXs. When BGP is toggled to enabled, the organization-wide VPN BGP AS can be set.

 

 

This AS number will be used for IBGP. Configuring this AS number will automatically set all other MXs in the organization to use the same AS number.

 

IBGP sessions are automatically established between MX appliances over their Meraki AutoVPN tunnels.

EBGP

On the Security Appliance > Configure > Site-to-site VPN settings page, BGP configuration is available for one-armed VPN concentrator MXs. When BGP is toggled to enabled, BGP neighbors can be configured.

 

To configure an EBGP neighbor, click "Add a BGP neighbor." Then, configure the Neighbor IP and Remote AS.

 

 

The BGP neighbor must be configured to peer with the one-armed VPN concentrator using its WAN1 IP and the organization-wide VPN BGP AS number.

 

If the one-armed VPN concentrator is deployed in a warm spare (high availability) configuration, the virtual IP (vIP) will be used instead of the WAN1 IP address.

Route Advertisement Behavior

Routes are advertised to EBGP and IBGP peers in the following conditions:

 

  • A VPN spoke will advertise all of it's VLANs or static routes that are allowed to participate in the VPN through IBGP to its configured hub.
  • A VPN spoke will learn routes advertised to it by other AutoVPN peers.
  • A one-armed VPN concentrator will learn routes advertised to it by other AutoVPN peers and re-advertise these IBGP learned routes to EBGP peers
  • A one-armed VPN concentrator will learn routes advertised to it by its EBGP peers and re-advertise these EBGP learned routes to other AutoVPN peers via IBGP
  • A one-armed VPN concentrator will advertise local networks configured on the site-to-site VPN settings page via IBGP

 

The following scenarios will illustrate how routes are learned and advertised through both Internal and External BGP.

Scenario 1: Single IBGP and EBGP Peers

Consider the following topology:

 

  • An MX configured as a one-armed VPN concentrator
  • Another datacenter router with an established EBGP session with the one-armed concentrator
  • A VPN spoke connected to the one-armed concentrator over AutoVPN. The two have an established IBGP session.
  • 10.255.0.0/24 is a subnet that exists in the datacenter and is advertised over EBGP
  • 172.17.7.0/24 is a subnet that exists in a remote branch and is advertised over IBGP

 

 

In this scenario:

  • The One-armed Concentrator MX will learn 172.17.7.0/24 via IBGP from the VPN Spoke MX
  • The One-armed Concentrator MX will learn 10.255.0.0/24 via EBGP from the BGP Peer
  • The VPN Spoke MX will learn of 10.255.0.0/24 via IBGP from the One-armed Concentrator MX
  • The BGP Peer will learn 172.17.7.0/24 via EBGP from the One-armed Concentrator MX

Scenario 2: Multiple EBGP Peers

Consider the following topology:

 

  • An MX configured as a one-armed VPN concentrator
  • Two datacenter routers, "BGP Peer A" and "BGP Peer B" with established EBGP sessions with the one-armed VPN concentrator.
  • A VPN spoke connected to the one-armed concentrator over AutoVPN. The two have an established IBGP session.
  • 10.255.0.0/24 is a subnet that exists in the datacenter and is advertised over EBGP through BGP peer A
  • 192.168.4.0/24 is a subnet that exists in the datacenter and is advertised over EBGP through BGP peer B
  • 172.17.7.0/24 is a subnet that exists in a remote branch and is advertised over IBGP

 

 

In this scenario:

  • The One-armed Concentrator MX will learn 172.17.7.0/24 via IBGP from the VPN Spoke MX
  • The One-armed Concentrator MX will learn 10.255.0.0/24 via EBGP from the BGP Peer A
  • The One-armed Concentrator MX will learn 192.168.4.0/24 via EBGP from BGP Peer B
  • The VPN Spoke MX will learn of 10.255.0.0/24 and 192.168.4.0/24 via IBGP from the One-armed Concentrator MX
  • Both BGP Peer A and BGP Peer B will learn 172.17.7.0/24 via EBGP from the One-armed Concentrator MX
  • BGP Peer A will also learn 192.168.4.0/24 from it's EBGP session with the One-armed Concentrator MX
  • BGP Peer B will also learn 10.255.0.0/24 from it's EBGP session with the One-armed Concentrator MX

Scenario 3: Datacenter Redundancy (DC-DC Failover)

Consider the following topology:

 

  • A VPN Spoke with a local subnet of 172.17.7.0/24
  • Two datacenters set up with a DC-DC Failover configuration:
    • The VPN Spoke MX establishes VPN to a one-armed VPN Concentrator in each datacenter  
    • The same subnet is advertised to the spoke through both datacenters
    • Communication to the datacenters is an active/passive failover configuration.
      • The active hub is defined based on it's configured hub priority. The one-armed concentrator in the primary datacenter has the highest priority in this scenario.
        • If the VPN Spoke MX were configured in a VPN mesh configuration, the organization-wide VPN concentrator priority would act as the hub priority in this case.
  • The primary datacenter has subnets of 10.0.0.0/8 and 192.168.80.0/24
  • The primary datacenter has an ASN of 1111
  • The one-armed VPN concentrator in the Primary datacenter has an active EBGP session with BGP Peer A
  • The secondary datacenter has subnets of 10.0.0/8 and 192.168.1.0/24
  • The secondary datacenter has an ASN of 2222
  • The one-armed VPN concentrator in the Secondary datacenter has an active EBGP session with BGP Peer B
  • The VPN Spoke MX is connected to the One-armed VPN Concentrator MXs in both datacenters. There are active IBGP sessions between the spoke MX and both concentrators.
  • The organization-wide AutoVPN ASN is 8888

 

 

In this scenario:

 

Primary DC

  • The One-armed Concentrator MX will learn 10.0.0.0/8 and 192.168.80.0/24 via EBGP from BGP Peer A.
  • The One-armed Concentrator MX will learn 172.17.7.0/24 via IBGP from the VPN Spoke MX.
  • BGP Peer A will learn 172.17.7.0/24 via EBGP from the One-armed Concentrator MX

 

Secondary DC

  • The One-armed Concentrator MX will learn 10.0.0.0/8 and 192.168.1.0/24 via EBGP from BGP Peer B.
  • The One-armed Concentrator MX will learn 172.17.7.0/24 via IBGP from the VPN Spoke MX.
    • Routes learned from the VPN Spoke MX by the One-armed Concentrator MX in the secondary DC will have an additional ASN (8888) pre-pended
  • BGP Peer B will learn 172.17.7.0/24 via EBGP from the One-armed Concentrator MX
    • Routes that are learned via IBGP by the One-armed VPN Concentrator in the secondary DC and re-advertised via EBGP will have an AS Path of 8888 8888

 

VPN Spoke

  • The VPN Spoke MX will learn 10.0.0.0/8 and 192.168.80.0/24 from the primary One-armed Concentrator MX
  • The VPN Spoke MX will learn 10.0.0.0/8 and 192.168.1.0/24 from the secondary One-armed Concentrator MX
  • The 10.0.0/8 route was learned from two different sources. Since the One-armed Concentrator MX in the secondary datacenter has a lower hub priority, the 10.0.0.0/8 route learned from the primary is preferred. 
    • Routes learned from the One-armed Concentrator MX will have an additional ASN (8888) pre-pended to it's AS Path to achieve this route prioritization.

 

You must to post a comment.
Last modified
15:45, 2 Mar 2017

Tags

This page has no custom tags.

Classifications

This page has no classifications.

Article ID

ID: 5666

Contact Support

Most questions can be answered by reviewing our documentation, but if you need more help, Cisco Meraki Support is ready to work with you.

Open a Case