Meraki Network Infrastructure¶
Overview¶
Cisco Meraki is the third operational domain of GPUS IT infrastructure, alongside the WDC on-premises Linux estate (SKY, RAIN, SUN, WIND) and the GCP cloud estate (OAK, MAPLE, CEDAR). Meraki provides the network fabric — security appliances (MX), switches (MS), and wireless access points (MR) — that connects the on-premises domain to the internet, to GCP via site-to-site VPN, and to end users across all Greenpeace USA physical sites.
This document is the canonical reference for the Meraki environment. Operational changes, incident response, and disaster recovery procedures that involve Meraki devices reference this document for current state, architecture, and ownership.
| Attribute | Value |
|---|---|
| Organization name | Greenpeace USA |
| Organization ID | 395909 |
| Cloud region | North America (Meraki Dashboard n120) |
| License model | Co-termination |
| License expiration | 2027-11-28 |
| Total managed devices | 32 (29 in production networks, 3 unassigned) |
| Total networks | 5 |
| Primary admin | rajesh.chhetry@greenpeace.org |
| Authentication | Local email-based (SAML cutover planned — see SSO runbook) |
| Dashboard URL | https://n120.dashboard.meraki.com/ |
Networks¶
The Meraki organization is segmented into five networks, each scoped to a distinct physical site or function. The two right-most columns indicate operational criticality and whether the network carries sensitive data.
| Network | Network ID | Site | Timezone | Product Types | Criticality | Sensitive Data |
|---|---|---|---|---|---|---|
| WDC-Eye Street | L_630503947831890190 |
Washington DC HQ | America/New_York | MX, MS, MR | Critical | Yes (staff workstations, finance, donor data paths) |
| MDEC | L_630503947831873852 |
Mid-Atlantic Direct Engagement Center | America/New_York | MX, MS, MR | High | Limited |
| OAKEC | L_630503947831873855 |
Oakland Engagement Center | America/Los_Angeles | MX, MS, MR | High | Limited |
| DC Apartments | N_630503947831910695 |
Residential staff housing | US/Eastern | MR only | Low | No |
| Major Gifts | N_630503947831998386 |
Systems Manager (MDM) | US/Eastern | SM only — no hardware | Medium | Yes (donor records on managed endpoints) |
Tags in use: East, West, GPUSalldevices. Tags are used in
Meraki Dashboard for bulk operations and in API-driven automation.
Tagging conventions are documented in the operational runbooks.
WDC-Eye Street (HQ)¶
The Washington DC headquarters is the most operationally critical network in the organization. It is the only site with a high-availability (HA) firewall pair and is the site that terminates the GCP site-to-site VPN.
Topology:
Internet
│
┌────────────┴────────────┐
│ │
Cogent (WAN1) Zayo (WAN2)
38.140.146.66/67 208.185.151.114/116
VRRP VIP .68 (GCP (failover path)
VPN peer)
│ │
└─────────┬───────────────┘
│
┌─────────┴─────────┐
│ MX95 HA pair │
│ wdc-fw-primary + │
│ wdc-fw-secondary │
└─────────┬─────────┘
│
├── wdc-edge-1 / wdc-edge-2 (MS120-8, edge switches)
│
└── WDC-STACK-0 through WDC-STACK-6
(7-switch MS225 stack —
4× MS225-48 + 3× MS225-48FP PoE)
│
├── wdc-wap-1 through wdc-wap-5
│ (5× MR57 access points)
│
└── End-user workstations / printers / IoT
Uplinks:
- WAN1 (Cogent) — primary, IPs
38.140.146.66and38.140.146.67with VRRP VIP38.140.146.68. The VIP is the GCP Classic VPN peer IP; failover between the two MX95 chassis happens via VRRP without changing the public-facing peer address. - WAN2 (Zayo) — secondary uplink, IPs
208.185.151.114and208.185.151.116. Used for failover when Cogent is degraded. Note: the GCP VPN tunnel is not currently configured to fail over to Zayo; see Phase 3 in the Meraki phased roadmap.
GCP VPN integration:
- Tunnel peer:
38.140.146.68(WDC VRRP VIP) ↔130.211.194.72(GCP) - VPN type: GCP Classic VPN (single tunnel, IKEv2)
- localTrafficSelector includes
10.8.0.0/28(the gpus-vpc-connector subnet) — this is non-obvious but required, otherwise Cloud Run egress traffic never enters the VPN tunnel. - Status: ESTABLISHED (operational since 2026-03 per VPN ops doc).
- Migration to GCP HA VPN is Phase 3 of the Meraki roadmap.
MDEC (Mid-Atlantic Direct Engagement Center)¶
A field office network with a single MX64 firewall, one access switch, and three access points. No HA, single uplink. Operationally important for field staff but not critical for organization-wide services.
Devices:
- 1× MX64 (MDEC MX) — firewall
- 1× MS210-24P (MDEC-access-2) — PoE access switch
- 1× MR52 (First Floor AP) — claimed 2025-11-26
- 1× MR52 (Garage AP) — claimed 2025-11-26
- 1× MR52 (Second Floor AP) — claimed 2025-11-26
Unassigned MDEC devices (see Audit Findings):
- Q2JD-29US-5JXK "mdec garage" (MR32) — end-of-support 2024-07-31
- Q2JD-2MFW-39AG "mdec 1st floor work room" (MR32) — end-of-support 2024-07-31
- Q2PD-L4QQ-9G54 "mdec 2nd floor by the bunk room" (MR33) — near EoS
These three devices have networkId: null in the org inventory — they
are claimed to the org but not assigned to any network. The two MR32
units are past end-of-support and must be either re-claimed and
decommissioned (preferred) or removed from the org entirely. The MR33
should be re-assigned to the MDEC network or decommissioned.
OAKEC (Oakland Engagement Center)¶
West Coast field office. Same design pattern as MDEC: single MX64, single access switch, two MR52 APs. No HA.
Devices:
- 1× MX64 (oakec-fw-primary) — firewall (formerly named "Justin-Bieber"
before 2026-04-23 hygiene rename)
- 1× MS210-24P (Oakland Warehouse Switch1)
- 2× MR52 (OAKEC-AP1, OAKEC-AP2)
DC Apartments¶
A residential network providing wireless-only service to staff housing units. Wireless-only deployment — no firewall, no switches in this network (uplink is presumably handled by a building-provided ISP service that is out of GPUS-IT scope). Lower criticality.
Devices:
- 4× APs across units (APT 707, APT 709, APT 611, APT211) —
mix of MR52 and MR33 hardware
All four DC Apartments APs are approaching end-of-support 2026-07-21 — see Lifecycle and EOL Tracking.
Major Gifts¶
A Systems Manager (Meraki MDM) network. No physical Meraki hardware in
this network. Provides MDM enrollment for endpoints belonging to the
Major Gifts team — endpoints enrolled via the enrollment string
greenpeaceusa. Licensed for 7 SM seats.
This network is in scope for Meraki documentation but operationally is managed alongside the broader endpoint management strategy, not alongside network infrastructure.
Device Inventory Summary¶
The full device-level inventory is maintained in
meraki-hostregistry.csv.
This section summarizes by device class.
Security Appliances (MX) — 4 devices¶
| Hostname | Model | Site | Network | EOL Status | Notes |
|---|---|---|---|---|---|
| wdc-fw-primary | MX95 | WDC HQ | WDC-Eye Street | Current | HA primary, VRRP master |
| wdc-fw-secondary | MX95 | WDC HQ | WDC-Eye Street | Current | HA secondary |
| MDEC MX | MX64 | MDEC | MDEC | EoS 2027-07-26 | Single uplink |
| oakec-fw-primary | MX64 | OAKEC | OAKEC | EoS 2027-07-26 | Single uplink |
Switches (MS) — 11 devices¶
| Hostname | Model | Site | Quantity | EOL Status |
|---|---|---|---|---|
| WDC-STACK-0 through WDC-STACK-3 | MS225-48 | WDC HQ | 4 | EoSale 2026-04-30 |
| WDC-STACK-4 through WDC-STACK-6 | MS225-48FP (PoE) | WDC HQ | 3 | EoSale 2026-04-30 |
| wdc-edge-1, wdc-edge-2 | MS120-8 | WDC HQ | 2 | EoSale 2025-03-28, EoS 2030-03-28 |
| MDEC-access-2 | MS210-24P | MDEC | 1 | EoSale 2026-04-30 |
| Oakland Warehouse Switch1 | MS210-24P | OAKEC | 1 | EoSale 2026-04-30 |
The seven WDC-STACK switches form a single physical stack via Meraki stack cables. The stack acts as a single logical switch from a configuration perspective.
Wireless Access Points (MR) — 17 devices¶
| Model | Quantity | Sites | EOL Status |
|---|---|---|---|
| MR57 | 5 | WDC HQ (wdc-wap-1 through wdc-wap-5) | Current |
| MR52 | 8 | MDEC (3), OAKEC (2), DC Apartments (3) | EoS 2026-07-21 ⚠ |
| MR33 | 4 | DC Apartments (3), MDEC unassigned (1) | EoS 2026-07-21 ⚠ |
| MR32 | 2 | MDEC unassigned (both) | PAST EOS — 2024-07-31 ⚠⚠ |
Systems Manager (SM) — Licensed 7 seats¶
No hardware. Endpoints enrolled to Major Gifts network via
greenpeaceusa enrollment string.
Lifecycle and EOL Tracking¶
Meraki publishes End-of-Sale (EoSale) and End-of-Support (EoS) dates per SKU. EoSale means no new units of that SKU can be ordered after the date — existing units continue to function. EoS means no further firmware updates, no security patches, and no Cisco TAC support — these devices are operating without vendor support.
| Status | Severity | Devices Affected | Action Required |
|---|---|---|---|
| Past End-of-Support | 🔴 Critical | 2× MR32 (unassigned MDEC) | Decommission immediately |
| Near End-of-Support (2026-07-21) | 🟠 High | 8× MR52 + 4× MR33 = 12 APs | Replacement plan by 2026-06-15 |
| End-of-Sale 2026-04-30 (3 days from publish date) | 🟡 Medium | 11 MS225 + 2 MS210 = 13 switches | Procurement window closes — order spares now if needed |
| Current (no EOL date set) | 🟢 OK | 2× MX95, 5× MR57 | Annual review |
| Long-term (EoS > 5 years) | 🟢 OK | 2× MX64 (EoS 2027-07-26), 2× MS120-8 (EoS 2030-03-28) | Annual review |
The 2026-07-21 cliff is the most operationally significant lifecycle event in the next twelve months. Twelve access points across three sites (MDEC, OAKEC, DC Apartments) hit end-of-support simultaneously. Replacement planning is tracked in the priorities document under T2-Meraki.
Administrative Access (Current State)¶
Local email-based authentication, four admin accounts:
| Admin | Org Access | Last Active | Status | |
|---|---|---|---|---|
| Rajesh Chhetry | rajesh.chhetry@greenpeace.org | full | 2026-04-27 | Active |
| Tanu Garg | tanu.garg@greenpeace.org | full | 2026-03-30 | Active |
| Jack Sundius | jack.sundius@greenpeace.org | read-only | 2026-03-04 | Active |
| Mike Sedita | msedita@greenpeace.org | full | 2025-11-25 | To be removed (no operational need) |
SAML SSO is not currently enabled. Migration to Okta SAML SSO is
documented in meraki-sso-runbook.md
and is the active sub-task of T2 in the priorities tracker. Target
post-cutover state: zero local admins (with one named break-glass for
30-day cutover stability), all access via Okta SAML.
Compliance Mappings¶
This section maps the current Meraki infrastructure to the compliance frameworks tracked across the GPUS IT MkDocs portal. Status reflects current state as of 2026-04-27, not target state. Gaps are remediation items.
MITRE ATT&CK — Relevant Techniques¶
Meraki devices are targets for adversary techniques in these tactics.
Detection coverage for each is tracked in blue-team-drills.md and
mitre-attack.md.
| Tactic | Technique ID | Technique | Meraki Relevance | Detection |
|---|---|---|---|---|
| Initial Access | T1133 | External Remote Services | Meraki Dashboard exposed to internet; admin credentials | Wazuh on Dashboard syslog (Phase 2) |
| Initial Access | T1078 | Valid Accounts | Compromised admin account | Okta + Meraki audit log correlation |
| Persistence | T1556 | Modify Authentication Process | SAML config tampering | Wazuh rule on Meraki SAML config change |
| Privilege Escalation | T1548 | Abuse Elevation Control Mechanism | Admin role elevation via Dashboard | Audit log review |
| Defense Evasion | T1562.004 | Disable or Modify System Firewall | MX firewall rule modification | Wazuh rule on MX config change |
| Credential Access | T1110 | Brute Force | Dashboard login brute-force | Meraki built-in + Okta logs |
| Discovery | T1046 | Network Service Discovery | Internal scanning detected by MX IDS | Snort signatures on MX |
| Lateral Movement | T1021 | Remote Services | Pivoting through compromised AP/switch | Network segmentation enforcement |
| Command and Control | T1071 | Application Layer Protocol | C2 over HTTPS through MX | MX threat protection + DNS logs |
| Exfiltration | T1041 | Exfiltration Over C2 Channel | Data egress through MX | NetFlow + threat protection |
| Impact | T1565 | Data Manipulation | Config changes to enable persistence | AIDE-equivalent — Meraki config snapshot diff |
PCI-DSS v4.0¶
GPUS USA does not currently process payment card data through any path that traverses the Meraki infrastructure (donations are processed via third-party payment processors that handle the cardholder data environment outside our network). The Meraki environment is therefore out of scope for PCI-DSS as a cardholder data environment but contributes to relevant requirements as connected systems.
| Requirement | Title | Meraki Contribution | Status |
|---|---|---|---|
| Req 1 | Install and maintain network security controls | MX firewall rules, segmentation | ✅ Implemented |
| Req 2 | Apply secure configurations | Default deny-all, no default credentials | ✅ Implemented |
| Req 4 | Protect cardholder data with strong cryptography during transmission | TLS for Dashboard, IPsec for VPN | ✅ Implemented (no CHD traverses) |
| Req 7 | Restrict access to system components | Admin role-based access | ⚠ Gap: read-only role under-utilized; SAML migration pending |
| Req 8 | Identify users and authenticate access | Per-admin accounts, no shared logins | ✅ Implemented; MFA via Okta post-SAML |
| Req 10 | Log and monitor all access | Meraki audit logs available; not yet centralized | ⚠ Gap: syslog → CEDAR is Phase 2 |
| Req 11 | Test security regularly | OpenVAS scans cover external WAN IPs | ✅ Implemented |
NIST CSF 2.0¶
| Function | Category | Meraki Implementation | Status |
|---|---|---|---|
| Identify | ID.AM-1 (Hardware inventory) | meraki-hostregistry.csv |
✅ Maintained |
| Identify | ID.AM-2 (Software/firmware inventory) | Meraki Dashboard reports | ✅ Maintained |
| Identify | ID.RA-1 (Asset vulnerabilities identified) | EOL tracking in this document | ✅ Maintained |
| Protect | PR.AC-1 (Identities and credentials managed) | Local admin → Okta SAML migration | ⚠ In progress |
| Protect | PR.AC-4 (Access permissions managed, least privilege) | RBAC two-tier (admin + read-only) post-SAML | ⚠ In progress |
| Protect | PR.AC-5 (Network integrity protected) | MX firewall, segmentation, IPsec VPN | ✅ Implemented |
| Protect | PR.PT-3 (Least functionality) | Default-deny on MX | ✅ Implemented |
| Detect | DE.AE-3 (Event data aggregated) | Syslog → CEDAR | ⚠ Phase 2 — not yet implemented |
| Detect | DE.CM-1 (Network monitoring) | Meraki Insight + MX threat protection | ✅ Implemented |
| Respond | RS.RP-1 (Response plan executed) | rb-006-meraki-failure.md, rb-007-meraki-compromise.md |
⚠ Drafts pending |
| Recover | RC.RP-1 (Recovery plan executed) | DR section in drp.md |
⚠ Pending |
NIST 800-53 Rev. 5 (Selected Controls)¶
| Control | Title | Status |
|---|---|---|
| AC-2 | Account Management | ⚠ Gap: Mike Sedita stale full access — remediation in flight |
| AC-6 | Least Privilege | ⚠ Gap: 3 of 4 admins have full access; Tanu Garg should likely be read-only or scoped — review |
| AC-7 | Unsuccessful Logon Attempts | ✅ Meraki built-in |
| AU-2 | Event Logging | ✅ Local; ⚠ centralized aggregation pending Phase 2 |
| AU-6 | Audit Record Review | ⚠ Gap: no formal review cadence — quarterly recommended |
| CM-3 | Configuration Change Control | ⚠ Gap: no formal change control process for Meraki — informal |
| IA-2 | Identification and Authentication | ⚠ Gap: no MFA on local admin accounts; resolved by Okta SAML |
| IA-2(1) | Multi-factor Authentication for Privileged Accounts | ⚠ Gap; resolved by Okta SAML |
| SC-7 | Boundary Protection | ✅ MX firewall enforces |
| SC-12 | Cryptographic Key Establishment | ✅ TLS, IPsec |
| SI-4 | System Monitoring | ⚠ Phase 2 — Wazuh integration pending |
ISO 27001:2022 Annex A¶
| Control | Title | Status |
|---|---|---|
| A.5.15 | Access Control | ⚠ Gap pending SAML cutover |
| A.5.18 | Access Rights | ⚠ Sedita removal + role review pending |
| A.8.1 | User Endpoint Devices | ✅ Major Gifts SM enrollment |
| A.8.9 | Configuration Management | ⚠ Gap: no formal config baseline |
| A.8.15 | Logging | ✅ Local; Phase 2 for centralization |
| A.8.16 | Monitoring Activities | ⚠ Phase 2 |
| A.8.20 | Network Security | ✅ MX, segmentation |
| A.8.21 | Security of Network Services | ✅ IPsec VPN |
| A.8.22 | Segregation of Networks | ⚠ VLAN review needed at WDC; document current segmentation |
| A.8.23 | Web Filtering | ✅ MX content filtering |
CIS Controls v8¶
| Control | Title | Status |
|---|---|---|
| 1 | Inventory and Control of Enterprise Assets | ✅ meraki-hostregistry.csv |
| 4 | Secure Configuration of Enterprise Assets and Software | ⚠ Gap: no documented baseline config per device class |
| 5 | Account Management | ⚠ Sedita removal in flight |
| 6 | Access Control Management | ⚠ SAML cutover in flight |
| 8 | Audit Log Management | ⚠ Phase 2 centralization |
| 12 | Network Infrastructure Management | ✅ Cloud-managed |
| 13 | Network Monitoring and Defense | ⚠ Phase 2 |
Audit Findings¶
The following findings emerged from the 2026-04-23 / 2026-04-27 discovery
sessions. Each is tracked through the priorities document and the
admin-review-meraki-2026-04.md audit document.
| ID | Finding | Severity | Owner | Target |
|---|---|---|---|---|
| MERAKI-2026-04-001 | Mike Sedita has full org admin access, last active 2025-11-25, no current operational need | High | Rajesh | 2026-05-02 |
| MERAKI-2026-04-002 | No SAML SSO; all admin auth is local email-based, no MFA enforcement at the platform | High | Rajesh | 2026-05-15 |
| MERAKI-2026-04-003 | 2× MR32 APs operating past end-of-support (2024-07-31), no security patches | Critical | Rajesh | 2026-05-09 |
| MERAKI-2026-04-004 | 12× APs (MR52/MR33) approaching end-of-support 2026-07-21 — 12-week replacement runway | High | Rajesh + Procurement | 2026-06-15 |
| MERAKI-2026-04-005 | 13× switches (MS225/MS210) hit end-of-sale 2026-04-30 — procurement window closing | Medium | Rajesh + Procurement | 2026-04-30 |
| MERAKI-2026-04-006 | 3 devices unassigned to any network (networkId: null) |
Medium | Rajesh | 2026-05-09 |
| MERAKI-2026-04-007 | No syslog forwarding to CEDAR (SIEM blind to Meraki events) | High | Rajesh | Phase 2 — 2026-Q3 |
| MERAKI-2026-04-008 | "DC Apartments" network name has trailing whitespace (cosmetic) | Low | Rajesh | Next maintenance window |
| MERAKI-2026-04-009 | No documented change-control process for Meraki Dashboard changes | Medium | Rajesh | 2026-Q3 |
| MERAKI-2026-04-010 | Meraki audit logs not retained beyond Dashboard default retention | Medium | Rajesh | Phase 2 — 2026-Q3 |
Phased Roadmap¶
Meraki integration with the broader GPUS-IT environment is sequenced in four phases. Phase 1 documentation is the deliverable of the current session.
Phase 1 — Documentation and Admin Hygiene (T2 in priorities doc)¶
Status: in progress (2026-04-27)
Documentation foundation, admin cleanup, SAML cutover. Goal: bring Meraki documentation parity with the WDC and GCP domains.
- [x] Discovery (org/inventory/networks API pulls)
- [x] API key rotation (old key was disclosed in chat)
- [x] OAKEC firewall renamed (Justin-Bieber → oakec-fw-primary)
- [ ]
meraki-infrastructure.md(this document) — Wave 1 - [ ]
meraki-hostregistry.csv— Wave 1 - [ ]
iar.mdMeraki section — Wave 1 - [ ]
gpus-it-architecture.htmlupdated — Wave 1 - [ ]
admin-review-meraki-2026-04.md— Wave 2 - [ ]
meraki-sso-runbook.md— Wave 2 - [ ] Mike Sedita admin removal — execution
- [ ] SAML SSO cutover (Okta + Meraki) — execution
- [ ] EOL MR32 decommission (2 units)
- [ ] Unassigned device cleanup (3 devices)
- [ ] DC Apartments name trim (cosmetic)
- [ ]
rb-006-meraki-failure.md,rb-007-meraki-compromise.md— Wave 3 - [ ] DRP / IRP / tabletop / blue-team-drill updates — Wave 3
- [ ] Status site, SOC site, infra portal Meraki tiles — Wave 4
- [ ] Priorities tracker T2 update via Cowork — Wave 5
Phase 2 — Telemetry Integration¶
Forward Meraki events into the existing GCP-hosted observability stack.
- Syslog from MX/MS/MR → CEDAR (Logstash on port 5140, Elasticsearch
index
meraki-*) - SNMP polling from MAPLE Prometheus
- Wazuh decoder + rules for Meraki event types (admin login, config change, IDS/IPS alert, VPN state change, AP outage)
- Grafana dashboard for Meraki ops on MAPLE
- Custom Wazuh rules in
/var/ossec/etc/rules/gpus-meraki-rules.xmlnumbered 100020+ (continuing from existing 100010-100015 LOLBin rules)
Estimated: 2026-Q3.
Phase 3 — Network Edge Modernization¶
- 12-AP refresh (MR52/MR33 → MR46/MR56 or current-gen equivalent) before 2026-07-21 EoS cliff
- WDC firewall rule audit (current ruleset has not been formally reviewed since deployment)
- GCP Classic VPN → HA VPN migration (GCP-side change; Meraki side reconfigures the tunnel peer)
- WAN2 (Zayo) failover for VPN tunnel — currently VPN only fails over to a DOWN state if Cogent fails
Estimated: 2026-Q3 to 2026-Q4.
Phase 4 — Surface Integration¶
- Status site Meraki tile (uplink status, device count, alerts)
- SOC site Meraki tile (admin activity, IDS alerts, config changes)
- Infra portal Meraki tile (link to Dashboard, current network state)
Estimated: 2026-Q4.
Operational Context¶
Naming Conventions¶
Devices follow the pattern <site>-<role>-<index>:
wdc-fw-primary,wdc-fw-secondary(HA pair)wdc-edge-1,wdc-edge-2wdc-wap-1throughwdc-wap-5WDC-STACK-0throughWDC-STACK-6(legacy uppercase, retain)oakec-fw-primaryOAKEC-AP1,OAKEC-AP2
Several legacy devices have descriptive but non-standard names
(First Floor AP, Garage AP, APT 707, mdec garage). These are
acceptable for residential / field-office contexts where physical
location is the primary identifier.
Tag Conventions¶
East— physically located in Eastern timezone (WDC, MDEC, DC Apt)West— physically located in Pacific timezone (OAKEC)GPUSalldevices— applied to all production devices for organization-wide bulk operationsrecently-added— Meraki-default, indicates recent claiming activity
Configuration Change Process (Current)¶
Currently informal. All Meraki Dashboard changes are made by Rajesh Chhetry directly. There is no peer review, no change ticket, no documented rollback plan. This is a CIS Control 4 / NIST 800-53 CM-3 gap. Formalization is tracked under finding MERAKI-2026-04-009.
Future state (target): all production changes go through change request in HappyFox, peer review by Tanu Garg or designated alternate, documented rollback, post-change verification.
Backup of Configuration¶
Meraki configuration is held centrally by Cisco Meraki (cloud-managed) and is not backed up to GPUS-controlled infrastructure. Configuration recovery in a Meraki-side outage scenario depends on Cisco's recovery SLAs. Local config snapshots via API are tracked under finding MERAKI-2026-04-009 as part of the change-control improvement.
Support Contacts¶
- Cisco TAC (Meraki): via Dashboard support portal — entitled through active license through 2027-11-28
- ISP escalation (Cogent): account on file with WDC office manager
- ISP escalation (Zayo): account on file with WDC office manager
Cross-References¶
| Document | Location | Relevance |
|---|---|---|
| Device-level inventory | meraki-hostregistry.csv |
Per-device data for the 32 devices |
| Information Asset Registry | iar.md |
Meraki classification, owner, criticality |
| WDC Linux infrastructure | wdc-infrastructure-architecture-overview.md (not yet in MkDocs — see Wave 5 cleanup) |
Servers Meraki connects |
| GCP cloud infrastructure | gcp-cloud-infrastructure.md |
VPN endpoint at GCP side |
| Architecture overview | gpus-it-architecture.html (Wave 1 update pending — not yet in MkDocs) |
Visual placement of Meraki domain |
| Admin review | admin-review-meraki-2026-04.md |
Admin access findings + actions |
| SSO migration | meraki-sso-runbook.md |
Okta SAML cutover procedure |
| Failure runbook | rb-006-meraki-failure.md |
Hardware/uplink/Dashboard outage response |
| Compromise runbook | rb-007-meraki-compromise.md |
Admin breach / config tampering response |
| Disaster recovery | drp.md |
Meraki domain DR procedures |
| Incident response | irp.md |
Meraki incident pathways |
| Tabletop scenarios | tabletop-playbooks.md |
Meraki Dashboard breach scenario |
| Blue team drills | blue-team-drills.md |
Meraki detection drills |
| MITRE coverage | mitre-attack.md |
Meraki technique coverage |
| Priorities tracker | gpus-it-priorities.md |
T2 Meraki status |
| VPN operations | vpn-operations.md |
GCP ↔ WDC tunnel ops |
Document History¶
| Version | Date | Author | Change |
|---|---|---|---|
| 1.0 | 2026-04-27 | Rajesh Chhetry | Initial document. Discovery output, device inventory, compliance mappings, audit findings, phased roadmap. |