f5-bigip-operations

name	f5-bigip-operations
description	Operational runbook for the F5 BIG-IP agent — safe procedures for draining pool members, HA-aware writes, certificate expiry checks, and diagnosing offline members.

F5 BIG-IP Operations Runbook

Use these procedures when managing the bigip F5 BIG-IP via the wrapper MCP tools. Always read state before writing, and confirm destructive operations.

Pre-flight for ANY write operation

1. Run failover_status. If the target device is standby, STOP and warn the user — writes should target the active device or be performed on the traffic group owner.
2. Run config_sync_status. If sync is out of sync, warn that changes may not propagate cleanly to the HA peer.
3. Confirm the partition (default Common) explicitly before any create/delete.

Gracefully draining a pool member (zero-impact maintenance)

Goal: take a member out of rotation without dropping live connections.

1. list_pool_members on the target pool to capture current state (save for rollback).
2. set_pool_member_state → disabled (NOT forced-offline). Disabled allows existing connections to finish; forced-offline kills them immediately.
3. Tell the user connections will drain as they close naturally. Only use forced-offline if they explicitly need an immediate cutoff and accept dropped connections.
4. To restore: set_pool_member_state → enabled.

Deleting a pool safely

1. list_virtual_servers and check each with get_virtual_server — refuse/​warn if any virtual server references the pool. Deleting an in-use pool breaks the VIP.
2. Summarize what will break, then ask for confirmation.
3. delete_pool only after confirmation.

Deleting a node safely

A node may back members in multiple pools. Before delete_node:

1. list_pools + list_pool_members to find every pool referencing the node's address.
2. List the affected pools to the user and confirm before deleting.

Certificate expiry audit

1. list_certificates, then get_certificate for expiration dates.
2. Flag anything expiring within 30 days as urgent, 90 days as a heads-up.
3. Present as a table sorted by soonest expiry.

Diagnosing an offline / red member

Status meanings:

• available + green → healthy, taking traffic
• offline + red → health monitor failing (most common real problem)
• disabled + blue → administratively disabled (someone drained it)
• forced-offline + red → user forced offline, dropping connections

Triage steps:

1. list_pool_members → confirm the actual state vs. expected.
2. list_monitors / list_http_monitors etc. → check which monitor is attached and its send/receive strings and interval.
3. If blue (disabled) → it was drained on purpose; ask before re-enabling.
4. If red (offline) → the backend is failing the monitor; check the backend service, not F5.

Error code cheat sheet

• 409 = already exists (idempotency — the object is likely already configured)
• 404 = not found (check partition and exact name)
• 422 = invalid configuration (bad parameters, e.g. malformed member address:port)

Member naming is always address:port (e.g. 10.0.1.50:80).