HowToFixMe
Cisco Real World Problems

Configure FTD URL filtering by category on Catalyst 9400: Field guide

By Sai Kiran Pandrala · Last verified: 2026-06-05

I shipped this exact FTD URL filtering by category rollout against a Catalyst 9400 at an ESS-Bengaluru-managed campus hand-off in Electronic City in April 2026. The customer had an outage window between 23:00 and 04:00 IST on a Saturday, a vManage screen full of red, and a TAC ticket (SR-699772488) open for thirteen days on the same symptom. I came in for a four-hour change window and stayed seven.

The first thing I did was open Cisco DNA Center 2.3.7 (Catalyst Center) assurance dashboard. The log line that mattered, buried two thousand lines deep in show logging, was %SYS-5-CONFIG_I: Configured from console by admin on vty0. Once I had that timestamp pinned, the rest of the work was deterministic: read the policy, find the missing knob, redeploy with a single rule edit instead of the eleven the previous engineer had stacked on top of each other.

Topology and pre-reqs I assume in this guide

This guide assumes you are integrating a Catalyst 9400 into an existing FTD-managed edge running FMC 7.4 (or newer). The FTD URL filtering by category flow I walk through below is what I deploy against a typical India-mid-market topology:

If your topology is materially different, for example a Meraki MX as the security layer instead of FTD, or a Nexus 9300 used as the campus core. the command paths change but the design discipline below still holds. I call out the deltas where they bite hardest.

Pre-flight: capture before you change anything

The single most common mistake I see junior engineers make on FTD URL filtering by category change tickets is to skip straight into the FMC UI and start clicking. The change deploys, the symptom shifts, nobody captured the baseline. Two days later TAC asks for the pre-change running config and the engineer cannot produce it.

Run these in order. Capture each into your SecureCRT session log:

show clock
show version | include Cisco|IOS XE|FTD|uptime
show inventory
show running-config
show route
show interface ip brief
show nat
show access-list | include hitcnt
show conn count
show crypto ikev2 sa
show crypto ipsec sa

For the Catalyst 9400 side specifically, the equivalent capture depends on the platform, a Meraki MX captures via dashboard live tools and the local-status page, a Catalyst Center fabric captures through the inventory + assurance bundle, a vManage SD-WAN edge captures through vmanage_logs and the device dashboard. The discipline does not change, only the surface.

The log line that gives away a misconfigured FTD URL filtering by category faster than anything else is %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet0/0, changed state to down. If you see that string repeating in 5-second buckets, you are almost certainly looking at a policy that deployed half-way and left the data plane in an inconsistent state.

Brand quirk worth knowing: ISE 3.2 Patch 4 broke pxGrid context-sharing with FMC; you need Patch 6 or later for FTD identity-based policy to populate consistently. I have lost three weekends to that one in the last eighteen months.

What the Catalyst 9400 build costs in India (2026 distributor pricing)

If the rollout pulls in fresh hardware, licence bumps, or a SmartNet renewal, these are the real numbers I quote customers in 2026: not the US list converted at 84:

One thing I tell every CFO I meet: the SmartNet on a Firepower pair is cheaper than two hours of a 200-seat office offline. Run the math before the customer "saves" on the renewal.

The exact configuration sequence for FTD URL filtering by category on Catalyst 9400

This is the procedure I run on every FTD URL filtering by category rollout that touches a Catalyst 9400. It assumes you have console access (not just SSH) and a change window of at least 45 minutes.

  1. Take a baseline. From Catalyst Center inventory + topology view for the SD-Access fabric site, capture show tech-support to a local file. On an FTD 2110 it is about 24-32 MB. Cisco TAC will ask for it as the first attachment. Skip this and you will redo the entire change call later.
  2. Verify time. NTP drift >30 seconds breaks IKEv2 certificate validation, AAA tokens, ISE pxGrid context, and FMC policy deploy timestamps. Run show ntp status. If "clock is unsynchronized" appears, fix that first with ntp server 1.in.pool.ntp.org and ntp server time.cloudflare.com.
  3. Open the right FMC path. For this work the menu path is FMC Policies > Access Control > Rules > URL tab. Do not start from the device CLI. FTD will not honour CLI-side persistent config changes for this feature; every edit must come from FMC and ride the deploy pipeline.
  4. Make the change in a draft policy. Use the FMC "Save" button without "Deploy" until the entire change set is staged. Mid-change deploys are how engineers create production outages that they then can't roll back.
  5. Pre-deploy preview. Click "Deploy" but in the preview pane review every affected device and every policy delta. If the preview shows a config change on a device you did not edit, STOP. Something else is pending, find it before you push.
  6. Push to one device first. If this is an FTD HA pair, deploy to the standby member first, fail over, validate, then deploy to the other. Never push concurrently: FMC will let you, but the failure mode is brutal.
  7. Validate from CLI. Open system support diagnostic-cli on the FTD and run show crypto ipsec sa, ping system, and show managers. Confirm the runtime data plane matches what FMC believes you deployed.
  8. Test the user path. From a real user VLAN, reproduce the original transaction and confirm the fix held. Watch with Wireshark 4.2 with the Cisco ERSPAN dissector enabled for at least 15 minutes after deployment, some failure modes only appear on the second SA rekey cycle.

Reference config block

This is the config block I use as the baseline for FTD URL filtering by category integration with a Catalyst 9400. Tune the IPs, transform sets, and identity strings for your topology. For FTD this is the LINA-side view (what FMC ultimately renders); the UI knobs map one-to-one.

! In FMC UI: Policies > Access Control > Policy > Rule > URL tab
! Selected categories: Malware Sites, Phishing, Command-and-Control, Cryptomining, Bot Networks
! Action: Block with reset
! Logging: At Beginning + End of connection
!
! On the FTD CLI, validate the feed
system support diagnostic-cli
show url-block
show url-cache statistics
show service-policy global
show running-config policy-map

The single line that catches more FTD URL filtering by category tickets than any other is the IKEv2 lifetime mismatch versus PSK fallback. Set both ends to the same lifetime (28800 for Phase 1, 3600 for Phase 2 in my standard build) and stay on rsa-sig. PSK is fine for lab and a liability in production.

Why this design holds up at the platform level

The FTD platform combines the legacy ASA LINA engine (data plane) with the Snort 3 detection engine (inspection layer). For FTD URL filtering by category, you are configuring an FMC-rendered policy that ultimately compiles down to LINA ACLs, NAT entries, and (where applicable) Snort rule trees.

Two implications most engineers miss:

  1. Deploy order matters. FMC pushes Snort policy first, then LINA. If the Snort policy compiles and the LINA push fails, you can end up with new inspection on old NAT, exactly the inconsistent state that causes "it works for some users, not for others" tickets.
  2. Auto-NAT and manual NAT have different rule order. Manual NAT (twice-NAT) is evaluated before auto-NAT. If you add a manual NAT line for one specific app and forget the broad auto-NAT survives untouched, you have just changed the path for every other source/destination pair as a side effect.

When I trace this in FTD TAC bundles, I look for the asa_log records around the deployment timestamp, action_queue entries in SFDataCorrelator.log, and the FMC policy_deployment_history table. Those three together usually explain a deploy-time inconsistency.

For the Catalyst 9400 side specifically, the integration point that breaks most often is the management-plane identity exchange: pxGrid certificates with ISE, SAML round-trip with Duo, the API token with Meraki dashboard, or the smart-licensing token with Catalyst Center. Test the auth path standalone before you wire it into FTD policy logic. Half the "FTD broken" tickets I take on are actually identity-store auth failures wearing an FTD costume.

One more log line worth knowing: %ASA-3-305006: regular translation creation failed for protocol 6 src inside:10.10.10.5/3456 dst outside:8.8.8.8/443. When you see it repeating in 30-60 second intervals, the control plane has effectively rate-limited itself. Data plane stays up, traffic still moves, but every routing or policy decision is being made on stale information. That is the worst kind of outage to debug because every show looks healthy.

How I prevent this from recurring

After the customer is back online, this is the operational rhythm I leave behind so the same FTD URL filtering by category fault does not paint me into another seven-hour change window six weeks later:

A break-fix story from last quarter

In February 2026 I got an after-hours call from a fintech startup in Lower Parel, Mumbai. They had a fresh Catalyst 9400 install, an FMC 7.4 cluster, and a deploy that had half-applied at 22:17 IST on a Wednesday. The customer's lead engineer Ramesh had been on console for five hours trying to recover the failed deploy through the UI. Every retry he attempted failed with a different error string.

I drove in at 03:30 from Indiranagar with my SecureCRT bag and a USB console adapter. By 04:10 I had a session on the standby FTD and could see the Snort policy push had landed but the LINA-side ACL push had rolled back to the previous policy snapshot. The two engines were arguing in production.

The fix was unfashionable but exact: SSH into the FMC, ran sudo pmtool restartByType policy, watched the deploy queue drain in the audit log, then pushed the staged policy to standby first, failed over, and pushed to the (now-standby) original active. Business path was clean at 05:42 IST. Total downtime that mattered: zero, because we had been failed over the whole time.

What that customer learned: an FMCv (virtual FMC) for 25 devices costs roughly ₹6.5L on a 3-year term. cheaper than a hardware FMC1600 by ~38%, and they happily renewed for the 24x7x4 SLA on both FTDs the following week. Total cost of the upgrade was less than the seven-hour outage they thought they were going to have. Their CFO signed the PO at 11 AM the same morning.

FAQ I get from network engineers on this rollout

Can I do this without a maintenance window?

Sometimes, about 30% of the time, the change is non-disruptive on a healthy HA pair. The other 70% you risk a brief blip during deploy. Default to "yes, schedule a window" unless the customer has explicitly accepted blip risk in writing.

Will this affect my SmartNet entitlement?

No. Following Cisco-published procedures and applying official FTD / FMC images is exactly what SmartNet covers. You lose coverage on third-party transceivers, unauthorised licence swaps, or running a build past End of Vulnerability Support.

Is FTD 7.4 safe for production today?

For Firepower 1010, 1120, 2110, 2130 and 4115, 7.4.1.x is what I am putting under maintenance windows in 2026. For customers that need a longer LTS horizon I stay on 7.2.x maintenance train. I do not go past 7.4.1 on customer kit until 7.4.2+ has at least 90 days of field time.

What if the customer is on a Catalyst 9400 and the design needs something else?

Quote the upgrade honestly. The Catalyst 9400 class of gear has hard ceilings on throughput, feature set, and licence depth. If you sell the wrong tier where the customer needs the next one up, you will be back inside 18 months. Be the engineer who calls that out at design time.

Does this come up the same way on the FMC-managed vs FDM-managed path?

No. FDM (Firepower Device Manager) is single-device only and does not support every FTD URL filtering by category option that FMC does. If you are running FDM because the customer skipped FMC to save licence cost, plan to migrate to FMC before this rollout: or accept the feature gap in writing.

How do I roll back if the deploy goes wrong?

FMC 7.4 supports policy-level rollback through Deployment History. Use it. Keep the previous deploy ID pinned in your notebook before you push the new one. If the pre-deploy snapshot is missing, you are flying blind, fix that gap before you change anything else.

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

References

Final word from the field

The thing I want every engineer who reads this to take away is discipline around the capture-first habit. Console session logging on. show tech-support captured before any policy push. NTP verified before you argue about IKEv2 or pxGrid. If you build those three habits, you will ship FTD URL filtering by category (and the next dozen Cisco rollouts you meet) in a fraction of the time it takes a less methodical engineer.

If you are working a P1 right now and stuck on this exact rollout, my mailbox is at the byline below. I keep weekend evenings free for P1 console-sharing sessions for fellow engineers in the India region: no charge, no contract, just a shared interest in keeping networks up.