Peers list
Each BGP peer represents one neighbour the Service Gateway talks BGP to. For each peer you define:- Peer address — the neighbour’s IP.
- Peer ASN — autonomous system number on the neighbour side.
- Local ASN — the Service Gateway’s ASN.
- Auth (optional) — MD5 password if the neighbour requires it.
- Timers — keepalive and hold-down overrides, if the defaults don’t match.
- Route policies — which routes to advertise and accept.
When BGP helps
- Anycast or multi-site deployments where routes need to converge based on health.
- SD-WAN integrations (Viptela / Catalyst SD-WAN) where the fabric already relies on BGP.
- Venues with their own core network team that manages routing via BGP and doesn’t want static route bookkeeping.
When to stick with static routing
- Single-site, flat-guest-VLAN venues with no redundancy requirements.
- Meraki-only venues — you don’t have a Service Gateway, so BGP isn’t applicable.
- Small deployments where the operational cost of BGP outweighs its convergence benefit.
Setting up a peer
Coordinate ASNs and policies
Agree on ASNs and what routes each side will advertise. Write
this down — route policy misconfiguration is the most common
BGP-related incident.
Add the peer in Sign In
From the BGP tab, click Add Peer and enter the address, ASNs,
and any auth / timers.
Configure the router
Mirror the peer configuration on the Cisco side. BGP on Service
Gateway typically runs inside the IPsec tunnel to Netgraph.
Route policies
Be explicit about what the Service Gateway advertises. A permissive policy that advertises everything can black-hole traffic if the wider network expects only specific prefixes. Start narrow, expand as needed, and document every change.Related
IPsec
BGP typically runs inside the IPsec tunnel.
Gateways
Each Gateway can have BGP on or off independently.

