Skip to main content
The Gateways tab under Service Gateway lists the Cisco routers registered to serve this Sign-In Context. Each entry identifies one physical (or virtual) router, along with the identifiers the platform uses to recognise its traffic and tunnel.

​
The Gateways list

Each row shows:
  • Router ID — the identifier the router uses when contacting Netgraph. Also used internally in logs and audit.
  • IP Address — the router’s public-facing address.
  • IPsec Remote Peer — the peer this router pairs with on the Netgraph side.
  • BGP Enabled — whether this router participates in BGP peering.
Use the search box to find a specific router in large deployments.

​
Add a Service Gateway

1

Click Add Service Gateway

On the Gateways tab, use the + Add Service Gateway button.
2

Supply Router ID and IP

These come from the router’s provisioning — coordinate with whoever owns the routing configuration.
3

Pick an IPsec Remote Peer

The router terminates its IPsec tunnel on one of the configured IPsec peers.
4

(Optional) enable BGP

If the venue uses dynamic routing, enable BGP and configure the peer under BGP.
5

Save and verify

The router should come online once the tunnel establishes. The Dashboard’s Service Status card updates to reflect whether DHCP, DNS, IPsec, and BGP are all healthy.
Click a row to open the per-gateway detail view — useful for inspecting state, seeing attached scopes, and editing the gateway’s IOS configuration template.

​
The per-gateway detail view

Each Service Gateway carries its own IOS configuration — rendered from a Framework Template that you control. The template uses ${placeholder} substitutions that are filled in at deploy time. Variables come from two sources: Reserved Variables (platform-supplied, read-only) and Custom Variables (admin- supplied, per-gateway). The detail view stacks the following cards on one page:
  • Framework Configuration — a Select Framework dropdown that picks which platform-provided template this gateway uses. The cards below appear once a framework is selected.
  • Reserved Variables — the set of names Netgraph populates for you. Read-only.
  • Framework Template — the IOS config snippet with ${VAR} placeholders. Editable, with a Restore from template button that reverts local changes to the framework’s default.
  • Custom Variables — per-gateway ${VAR} substitutions. Each row is editable; when a value differs from the framework default, a Restore link appears beside it.

​
Reserved Variables

A fixed set of names the platform fills in automatically. You can reference any of them in the Framework Template without defining them as Custom Variables.
NameMeaning
applicationIpPlatform IP the gateway talks to.
dcIdPlatform datacenter ID the Context runs in.
domainNamePlatform domain name.
contextIdThis Sign-In Context’s ID.
routerIdThis gateway’s Router ID.
bgpLocalAsThis gateway’s BGP Local AS, if BGP is enabled.
bgpRemoteAsThe configured BGP Remote AS.
ikev2PreSharedKeyThe IKEv2 pre-shared key for this gateway’s IPsec tunnel.
tunnelIntIpThis gateway’s tunnel-interface IP.
The table is read-only: you can copy the names into the template but you can’t edit the values or add more entries.

​
Framework Template

The Framework Template holds the IOS configuration as text, with ${VAR}-style placeholders wherever a value differs between gateways. Typical uses:
  • A multi-gateway deployment with per-venue interface IPs and DHCP relays substituted from Custom Variables.
  • Shared boilerplate (IPsec proposals, DPD timers, ACLs) defined once in the template and reused verbatim across every gateway.
  • Per-environment tweaks plugged in with reserved names like ${applicationIp} or ${contextId}.
Two callouts appear above the template to catch typos:
  • An “Unused Reserved Variables” callout lists reserved names the template doesn’t reference. Most of the time this is fine (you don’t need every reserved name in every template), but it signals copy-paste mismatches worth a glance.
  • An “Unused Custom Variables” callout lists Custom Variables you’ve defined but not referenced. Usually a sign of a stale variable left over from a previous revision — remove it or reference it.
A separate “Template modified” callout appears when the template has been edited from the framework’s default; use Restore from template to revert.
Editing the template is a full-text edit of the IOS config. Save to push the change; the Service Gateway picks it up on its next sync.

​
Custom Variables

Admin-editable ${VAR} → value mappings. One row per variable, with columns for Variable, Description, Value, and a delete action. Typical entries:
  • ${lanInterface} → GigabitEthernet0/0/1 on a venue whose LAN handoff differs from the default.
  • ${dhcpRelayIp} → an upstream DHCP server for a relay-only scope.
  • ${vlanId} for a VLAN the template references in multiple places.
Reserved and Custom share the same ${…} namespace — don’t re-use a Reserved name as a Custom variable.

​
Common Settings

The Service Gateway page’s Common Settings sub-tab (alongside Gateways) holds platform-level connection details:
  • Service Gateway IOS-XE — Interface description used on platform-generated configuration.
  • Service Gateway Viptela SDWAN — vManage Host, IPsec-Id, API Username, and API Password, used when the Gateways run on a Viptela / Catalyst SD-WAN fabric.

​
Remove a Service Gateway

Remove a router from the Gateways list when it’s decommissioned. Make sure no DHCP scopes, DNS entries, or BGP peers reference the router — the Context admin surfaces warnings where references would dangle.

​
Multiple routers in one Context

A Context can run many Gateways for:
  • High availability — a pair of routers at one venue, active/standby or active/active.
  • Multi-venue deployments — one Gateway per site, sharing one Sign In Context.
  • Geo distribution — Gateways in different regions serving different guest populations.
Every Gateway in the same Context shares the Context’s modules and policies; only the network-layer services (DHCP scopes, IPsec peers, BGP peers, DNS entries) can differ per Gateway.

DHCP

Scopes served by the registered Gateways.

IPsec

Tunnels each Gateway uses to reach Netgraph.