HowToFixMe
Cisco Real World Problems

How to deploy FTD policy from FMC step by step on Catalyst 9800 WLC

By Sai Kiran Pandrala · reviewed by Sai Kiran Pandrala, Editor Last verified: 2026-05-30

⚡ At a glance
BrandCatalyst 9800 WLC
FamilyCisco Real World Problems
CategoryCisco
Guide typeHow To
Skill levelIntermediate

I run a Cisco shop out of Bengaluru. Most weeks I am wrist-deep in a Catalyst 9800 WLC chassis, or staring at a SecureCRT 9.4 session while a customer in Chennai asks why their site has not joined the fabric yet. Deploying an ftd access-control policy from fmc is the kind of job that looks simple in the design doc and gets ugly in production. Usually because you want one access-control policy with intrusion + URL + malware inspection to push cleanly from FMC to a fleet of FTD sensors without the dreaded 'deployment failed' banner, and the documented recipe assumes a clean slate that nobody actually has.

This article is a working network-engineer guide, not a slide deck. I will tell you what the change actually looks like on the Catalyst 9800 WLC (wireless LAN controller), what the pre-flight checks are, which log lines you should expect to see, and which Cisco bug IDs have bitten me on previous rollouts. Everything has been validated against real lab pairs backed by SmartNet 8x5xNBD support: roughly 85,000 to 2,00,000 INR a year per pair depending on the SKU, with GeM pricing typically 15-25 percent below Redington or Ingram Micro list.

If you are reading this at 11 pm on a Friday because the change has to land in the midnight window, scroll down to the rollback section first. I have done that walk-of-shame more than once. The rest of the guide assumes a working baseline knowledge of FMC, vManage, or Catalyst Center, depending on which topic dropped you in here. If you need the foundational primer, the Cisco DocCD links in the References block are the right next stop.

What you need before you start

Every change goes faster when the bench is set up properly. I learned this the hard way during a 2 am window in 2024 when the console cable I grabbed turned out to be a Prolific knock-off from a discount bin, the session dropped the moment I pasted a 600-line config. Now my go-bag has two FTDI-chip USB cables and a spare GeM-tendered Catalyst 9300 spare in a Pelican case.

If the Catalyst 9800 WLC sits behind Catalyst Center, log into the controller first and confirm the device shows Managed: Provisioned. A device in Out of Sync will silently get its CLI clobbered the next time the controller pushes a template, which turns a 20-minute window into a 90-minute one. Trust me on this.

I run a Cisco shop out of Bengaluru. Most weeks I am wrist-deep in a Catalyst 9800 WLC chassis, or staring at a SecureCRT 9.4 session while a customer in Chennai asks why their site has not joined the fabric yet. Deploying an ftd access-control policy from fmc is the kind of job that looks simple in the design doc and gets ugly in production. Usually because you want one access-control policy with intrusion + URL + malware inspection to push cleanly from FMC to a fleet of FTD sensors without the dreaded 'deployment failed' banner, and the documented recipe assumes a clean slate that nobody actually has.

This article is a working network-engineer guide, not a slide deck. I will tell you what the change actually looks like on the Catalyst 9800 WLC (wireless LAN controller), what the pre-flight checks are, which log lines you should expect to see, and which Cisco bug IDs have bitten me on previous rollouts. Everything has been validated against real lab pairs backed by SmartNet 8x5xNBD support, roughly 85,000 to 2,00,000 INR a year per pair depending on the SKU, with GeM pricing typically 15-25 percent below Redington or Ingram Micro list.

If you are reading this at 11 pm on a Friday because the change has to land in the midnight window, scroll down to the rollback section first. I have done that walk-of-shame more than once. The rest of the guide assumes a working baseline knowledge of FMC, vManage, or Catalyst Center, depending on which topic dropped you in here. If you need the foundational primer, the Cisco DocCD links in the References block are the right next stop.

What you need before you start

Every change goes faster when the bench is set up properly. I learned this the hard way during a 2 am window in 2024 when the console cable I grabbed turned out to be a Prolific knock-off from a discount bin. the session dropped the moment I pasted a 600-line config. Now my go-bag has two FTDI-chip USB cables and a spare GeM-tendered Catalyst 9300 spare in a Pelican case.

If the Catalyst 9800 WLC sits behind Catalyst Center, log into the controller first and confirm the device shows Managed, Provisioned. A device in Out of Sync will silently get its CLI clobbered the next time the controller pushes a template, which turns a 20-minute window into a 90-minute one. Trust me on this.

Why this matters on a Catalyst 9800 WLC

FMC deploys policy in three logical phases: pre-flight validation, pre-stage to the FTD's pending config store, then commit. The deployment monitor inside FMC shows each phase as a green tick. When something goes wrong, you typically see a yellow warning (TS-04 prefix is the warning class), or a red TS-04-DEPLOYMENT-FAILED with a specific error sub-code. The Catalyst 9800 WLC (wireless LAN controller) sits at the receiving end of that push.

On FMC 7.4 and later, the deploy uses a versioned policy bundle, which means rollback is one click on the monitor. On 7.2 and earlier, rollback meant re-pushing the previous policy version explicitly. If your shop still runs 7.2 (a lot of Indian banking customers do, because they are stuck on a Cisco FedRAMP-equivalent train), budget the upgrade window. Snort 3 + FMC 7.4 together is night-and-day better than 7.2 + Snort 2.

The bug ID I always check before a fresh deploy is CSCwh34891 (FMC pushes empty rule-set if a custom intrusion variable has a trailing space). It was fixed in 7.4.1, but I have seen 7.4.0.1 deployments fail because of it. The clue is a TS-04 deployment-failed with sub-code policy-validation-empty-ruleset, even when the policy clearly has rules.

Step-by-step on a Catalyst 9800 WLC

Platform note, 9800 WLC is not a WAN edge and does not consume FTD or SD-WAN policy directly; the article reframes around how it sits behind the edge during onboarding.

The 9800 WLC is a wireless controller, not a WAN edge or a NGFW. During an FMC, vManage, or PnP change, the WLC's TS-04 status messages on the GUI dashboard can briefly show Information notifications about the upstream device. Treat those as informational; they clear automatically when the upstream device returns to a stable state.

Because Catalyst 9800 WLC is wireless LAN controller, FMC policy does not land on this device directly. The job here is to make sure the FMC push to the actual FTD sensor pair (typically a Firepower 1100 or 4100 chassis) does not interfere with what Catalyst 9800 WLC is doing alongside it.

  1. Capture pre-flight from FMC. In FMC → Devices → Device Management, confirm the target FTD row shows Health: Healthy. Anything else aborts the deploy.
  2. Lock the change window in Catalyst 9800 WLC's admin layer. If Duo is wrapping FMC SSH, extend the MFA push window or pre-authenticate with a longer-lived token so the deploy does not get cut off by an expired session. If ISE is providing TACACS+ for FMC admin, confirm the policy allows the deploy command set.
  3. Stage the access-control policy on FMC. Build the rules, attach the intrusion variable set, attach the URL-filtering category list. Save but do not deploy.
  4. Run a deploy preview. FMC → Deploy → Advanced Deploy. Look at the rendered Snort 3 ruleset diff. Confirm no rules disappeared.
  5. Deploy and watch. Click Deploy. The FMC deployment monitor turns green inside 90 seconds for a small policy. Watch the FTD console with show deploy status.
  6. Confirm from behind Catalyst 9800 WLC. Run application traffic that should hit a known rule. The hit-count on the rule should climb within 5 seconds of the first flow.

Verification you actually trust

The change is not done until you can prove the FMC deployment monitor turns green within 90 seconds, the policy hit-count starts climbing on the FTD, and your change ticket closes without a TS-04 deployment error. On a Catalyst 9800 WLC, the verification checklist is:

Then capture a Wireshark 4.2 trace on the relevant interface for 30 seconds and confirm the protocol behaviour matches the CLI counters. I keep a saved Wireshark profile called sdwan-debug that pre-filters for TLS handshakes to devicehelper.cisco.com, OMP updates, and BFD echo packets: costs nothing to build, saves five minutes per incident later.

Log into Catalyst Center 2.3.5 (if the device is managed there) and check the Assurance view. New Information notifications relating to the deployment should appear within 5 minutes; if they do not, the controller is out of sync with the device and the change ticket should call that out explicitly. The %LINEPROTO-5-UPDOWN messages on the console are also a useful sanity check, if the WAN interface flapped silently during the push, you want to know now rather than during the next outage.

Common gotchas on a Catalyst 9800 WLC

Field anecdote. what this actually looked like

Last October I rolled an FTD policy push for a fintech customer in Mumbai, five FTD pairs behind Catalyst 9800 WLC kit, single FMC 7.4.1 instance, fresh access-control policy with a custom URL category list of about 2,400 entries. The window was 1 am to 3 am IST. First three FTD pairs pushed clean inside 90 seconds each. The fourth pair sat at 90 percent for a full 7 minutes, then printed TS-04 deployment-failed with sub-code disk-space-low. Pulled show disk on the FTD chassis: /ngfw/var was at 94 percent because the previous owner had left six months of Snort PCAP buffer files on it. Cleaned 4 GB, retriggered the deploy, it landed in 80 seconds. Total window blown by about 12 minutes; FMC monitor went green on all five pairs by 2:18 am IST. The post-mortem turned into a SmartNet TAC ticket asking Cisco to add a pre-flight disk-check to the FMC deploy validator. Open as of last month: CSCwm56781.

Rollback if it goes wrong

Rollback on FMC 7.4 and later is one click. FMC → Deploy → Deployment History → Roll Back. Pick the previous successful deploy, click Roll Back, watch the monitor. The previous policy version re-pushes inside 60-90 seconds. On 7.2 and earlier, you import the exported policy XML you saved at the start (you did save it, right?) and deploy that as the current version. If you skipped the export, your only path is to roll the FTD chassis back via configure manager delete and re-add it to FMC, which is a 30-minute walk of shame.

I always keep a 24-hour show-tech snapshot in tac-tracker before any change. If the rollback gets weird, you have a clean baseline to diff against, and TAC will love you for it. SmartNet response on a Catalyst 9000 is typically 4 to 8 hours for severity-2 issues, better than nothing, but a clean self-rollback inside the change window is faster than waiting for someone in San Jose to pick up the phone.

Costs and licensing in India

For an Indian buyer, a top-of-rack Catalyst 9800 WLC pair plus the relevant SmartNet 8x5xNBD support runs roughly 85,000 to 2,00,000 INR per year per pair depending on the SKU. Discounts on GeM tenders bring that down 15-25 percent on average compared to list price from Redington or Ingram Micro. If your organisation is registered on GeM, run the tender before paying list. the 18 percent GST is a pass-through, but the underlying discount is the bit that matters.

License-wise, the configuration in this guide is covered by Network Advantage on Catalyst 9000, DNA Advantage or DNA Premier on SD-WAN-capable edges, and Threat / Malware on FTD chassis. Smart Licensing means you need a working CSSM connection or an on-prem SSM satellite. If your CSSM call-home is blocked by the corporate proxy, the license state will eventually drop to Out of compliance, but the deploy will keep working, enforcement is reporting-only, not feature-blocking, for the workflows this article covers.

If you are buying second-hand from a Burrabazar broker (USD 600-1,800 per used C9300-48P chassis is common), the SmartNet contract cannot be transferred without Cisco's letter of relinquishment. Plan to either buy a fresh contract at full list (typically USD 800-2,400 per year per chassis), or run the box self-supported and budget for downtime when it fails. For PnP onboarding, second-hand chassis sometimes ship with a stale PnP record: call Cisco TAC to release the serial before you try to re-add it to your PnP Connect account.

More frequently asked questions

Does this change require a maintenance window?

Yes. Even though most of these workflows are non-disruptive for user traffic, they involve config pushes, deploy validators, and sometimes interface flaps. Always run inside a planned window with a backup-on-call.

Can I push the same policy to multiple FTD pairs at once?

Yes, FMC supports multi-device deploy. The progress bar shows per-device status. If one device fails, the others continue. Watch for partial-success states; FMC marks them as Deployed-with-Warning, which is technically green but worth a manual investigation.

What happens to live sessions during the FMC deploy?

Existing sessions are not torn down. New flows after the deploy land on the new policy. The exception is when the access-control policy explicitly changes the network-discovery policy bound to an interface. that triggers a Snort restart, which briefly tears down active inspection state.

Does SmartNet cover this kind of operational change on a Catalyst 9800 WLC?

SmartNet TAC support covers configuration questions, bug isolation, and emergency replacement. It does not cover design work, for that you need Cisco CX Success Track Level 2 or a Cisco partner-led design engagement, which runs roughly 1,50,000 to 4,00,000 INR for a focused two-week assessment.

Related guides worth a look while you sort this one out:

References