Cisco Catalyst 9300 HQoS and Static BFD: Configuration Order and Verification

For a bandwidth-limited Catalyst 9300 hub-and-branch link, review where traffic is classified and queued, and which static routes depend on BFD. A configured policy and an Up neighbor do not establish the complete forwarding result. These independent configuration examples use Cisco's IOS XE 17.18.x documentation; they are not completed lab results. Check the exact SKU, maintenance release, interface type, licenses, and existing policies. Another model's working configuration does not establish compatibility.

1. Start with the documented attachment restrictions

The 17.18.x QoS guide supports a two-level hierarchy: a port shaper in the parent and queues in the child. SVI policies are limited to marking, and egress queuing excludes ACL-based match access-group. Attach EtherChannel queuing to supported member ports rather than the logical channel. Review these restrictions before command order. See reference 1.

Function	Example location	Review question
Application identification and DSCP marking	LAN ingress physical port, or supported SVI marking policy	Does this point see the packets before the WAN queue?
Voice priority and CTI scheduling	Child of the WAN egress policy	Do the arriving DSCP values match the queue classes?
Aggregate rate control	Parent on the WAN egress physical port	Does the rate match this direction's service bottleneck?
Static-route reachability	BFD neighbor plus matching interface and next-hop in static routes	Which routes should disappear when this peer becomes unavailable?

SVI acceptance of service-policy input does not establish policing, shaping, or queuing support. Cisco confirms marking support, and a physical-port input marking policy can take precedence over an SVI policy. See reference 4 and reference 1.

2. Use a dependency order, then activate in stages

Recommended engineering order; IOS XE does not impose this as a universal installation sequence:

1. Capture the existing interfaces, routes and attached policies. Confirm a management path and prepare rollback commands.
2. Create classification ACLs, then the ingress class maps that reference them.
3. Create ingress marking policies and DSCP-based egress class maps.
4. Create the egress child policy, then the parent that references it.
5. Attach ingress marking and verify the marks; attach the parent to one egress target and verify hardware installation.
6. Configure BFD timers and peer registration on both endpoints, then associate the intended static routes.
7. Verify routing and traffic under normal load, congestion, failure and recovery. Save only after acceptance checks.

New unattached objects stage the design. Editing an object used by a live policy can already affect traffic, and policy attachment changes treatment. BFD association or route replacement can alter reachability immediately; saving is not the activation step.

3. Separate application ACLs from egress queue matching

The examples use hub network 198.51.100.0/24 and branch network 203.0.113.0/24, with voice hosts at .10 and CTI at .20. UDP ports 16384-32767 and TCP 8443 are arbitrary lab selectors. Confirm real application flows before using production classifiers.

ip access-list extended LAB-VOICE
 permit udp host 203.0.113.10 host 198.51.100.10 range 16384 32767
 permit udp host 198.51.100.10 host 203.0.113.10 range 16384 32767
 exit
ip access-list extended LAB-CTI
 permit tcp host 203.0.113.20 host 198.51.100.20 eq 8443
 permit tcp host 198.51.100.20 eq 8443 host 203.0.113.20
 exit
class-map match-any CM-IN-VOICE
 match access-group name LAB-VOICE
 exit
class-map match-any CM-IN-CTI
 match access-group name LAB-CTI
 exit
policy-map PM-LAN-MARK
 class CM-IN-VOICE
  set dscp ef
  exit
 class CM-IN-CTI
  set dscp af21
  exit
 exit
class-map match-any CM-OUT-VOICE
 match dscp ef
 exit
class-map match-any CM-OUT-CTI
 match dscp af21
 exit

These ACLs classify QoS traffic and are not attached as security ACLs. Include voice when classification or remarking is needed at this boundary; assess any approved EF mark already present. Verify packet markings against the intended classes. MQC syntax is documented in reference 2.

4. Build the child before the parent

policy-map PM-WAN-CHILD
 class CM-OUT-VOICE
  priority level 1
  police 10000000 conform-action transmit exceed-action drop
   exit
  exit
 class CM-OUT-CTI
  bandwidth remaining percent 20
  exit
 class class-default
  bandwidth remaining percent 80
  exit
 exit
policy-map PM-WAN-100M
 class class-default
  shape average 100000000
  service-policy PM-WAN-CHILD
  exit
 exit

The parent example shapes to 100,000,000 bits per second and limits voice to 10 Mb/s with excess traffic dropped. CTI and default classes receive weights from bandwidth remaining after priority treatment. 20 does not guarantee 20 Mb/s for CTI. Choose values from measured traffic and service needs. Scheduler semantics are described for 17.12.x; 17.18.x documents priority and parent-child syntax. See reference 5 and reference 2.

interface GigabitEthernet1/0/1
 service-policy input PM-LAN-MARK
 exit
interface GigabitEthernet1/0/48
 service-policy output PM-WAN-100M
 exit

The attachment assumes Gi1/0/1 is physical LAN ingress and Gi1/0/48 is physical WAN egress; it does not create or convert interfaces. For VLAN-based marking, assess the SVI and any competing physical-port input policy separately. Check LAN ingress marking and WAN egress scheduling at the sending site in each direction. A branch upload policy cannot control earlier upstream download drops. A single hub parent shaper caps shared egress; policy names alone do not create separate shaping per branch.

5. Associate static routes with the correct BFD peer

For the separate routing example, the WAN ports already use routed network 192.0.2.0/30, with hub .1 and branch .2. Local LAN networks also exist. Cisco requires directly connected BFD neighbors and participation at both ends. See reference 3.

Hub: new lab configuration

interface GigabitEthernet1/0/48
 bfd interval 500 min_rx 500 multiplier 5
 exit
ip route static bfd GigabitEthernet1/0/48 192.0.2.2
ip route 203.0.113.0 255.255.255.0 GigabitEthernet1/0/48 192.0.2.2

Branch: new lab configuration

interface GigabitEthernet1/0/48
 bfd interval 500 min_rx 500 multiplier 5
 exit
ip route static bfd GigabitEthernet1/0/48 192.0.2.1
ip route 198.51.100.0 255.255.255.0 GigabitEthernet1/0/48 192.0.2.1

Inspect negotiated timers; the example values do not promise convergence. Matching interface/next-hop pairs share a BFD session, while a next-hop-only route's association must be checked separately. Cisco documents an SVI timer disable/re-enable sequence after static registration. Schedule that reset as a change affecting dependent routes; port-channel restrictions are separate. See reference 6.

6. Convert existing routes without leaving an untracked path

For existing production routes, use a migration plan rather than applying the new-lab fragment:

1. Inventory every route using the peer, including VRF, administrative distance, tags, tracking and backup routes. Retain those attributes in the proposed replacements.
2. Confirm connected next-hop resolution and the return path. Check both endpoint configurations before associating a working route with BFD.
3. Rehearse the route replacement and BFD activation order on the target release. If pre-establishing a session with the documented unassociate option, verify that it has not yet enabled static-route tracking.
4. Convert one agreed prefix during the change window. Check the static database, RIB, CEF and application traffic after each step.
5. Remove any superseded next-hop-only route after verifying the replacement. During failure testing, check that it cannot continue forwarding around the intended BFD dependency.

Delete-and-add is not guaranteed hitless. Validate route coexistence and the transition to associated BFD on the target release. Prepare rollback to restore original attributes, remove the new association where needed, and verify forwarding. For only the simple hub lab example, remove the association with:

no ip route static bfd GigabitEthernet1/0/48 192.0.2.2

This command changes the association for all matching interface/peer routes. It does not cover production groups, VRFs, or other rollback dependencies.

7. Verify four layers of evidence

These are read-only checks. Confirm hardware command syntax for the platform, stack member, and release.

show version
show policy-map interface GigabitEthernet1/0/1
show policy-map interface GigabitEthernet1/0/48
show bfd neighbors details
show ip static route
show ip static route bfd
show ip route 203.0.113.0
show ip cef 203.0.113.0 255.255.255.0
show platform software fed switch active qos policy target status
show platform hardware fed switch active qos queue stats interface GigabitEthernet1/0/48

Evidence	Acceptance check
Configuration	Correct input/output targets, parent-child reference, peer and fully specified route
Hardware	Policy installed successfully; expected egress queues and drop behavior
Routing	BFD Up, intended static dependency, correct RIB and CEF next-hop
Traffic	Expected DSCP, usable voice and CTI, appropriate shaping, failure and recovery behavior

Check hardware installation as well as configured policies, and inspect per-queue drops. Capture counter deltas over a controlled traffic interval; interface averages can miss bursts. See reference 7 and reference 8.

If the WAN physical port instead shows growing CRC/FCS errors, runts or late collisions, check the negotiated speed and duplex at both ends before tuning the policy. For an example of a working link with mismatched duplex, see Cisco CDP Duplex Mismatch: FastEthernet Full, GigabitEthernet Half.

Pure queuing policies may lack counters available in marking/policing policies. A zero class count alone does not prove classification failure. Correlate packet marks, queues, and traffic. BFD may use class-default and suffer oversubscription loss, so test it under congestion instead of assuming voice priority protects it. See reference 1 and reference 3.

In a controlled failure test, record the BFD transition, tracked-route withdrawal, resulting CEF path, and application recovery. Verify any required alternative path explicitly. BFD detects the peer; it creates no backup route and does not establish the health of a server beyond that peer. No such test results are claimed here.

Before a release migration

Check management access separately from forwarding features. For an example of the SSH compatibility checks that can accompany an IOS XE migration, see Cisco Catalyst SSH Fails After IOS XE 17.18 Upgrade: No Matching KEX Algorithm.

For management-access preparation, Cisco Catalyst 9200L Local AAA Migration: Planning and Verification on IOS XE 17.18.4 provides a separate Catalyst 9200L example of preserving recovery access and validating fresh logins before saving. Use it as a change-planning reference; confirm authentication commands against the documentation for the actual target platform.

Related BFD troubleshooting case

If BFD Control packets are exchanged but the session still flaps, check Echo behavior separately. See Cisco Catalyst 9300 BFD Echo Failure: Troubleshooting Session Flaps and Restoring Stability for a case where Echo TX increased while Echo RX remained zero and disabling Echo restored session stability.

Official references

Documentation reviewed October 8, 2026. Check maintenance-release caveats and validate the exact SKU in addition to release-family guidance.

1. Cisco Catalyst 9300 Quality of Service Configuration Guide, IOS XE 17.18.x: restrictions, SVI marking, egress classification and hierarchical policies.
2. Cisco Catalyst 9300 QoS Command Reference, IOS XE 17.18.x: MQC, priority and policy-map commands.
3. Cisco Catalyst 9300: Configuring Bidirectional Forwarding Detection, IOS XE 17.18.x: static routing, directly connected neighbors and verification.
4. Cisco Catalyst 9300 Release Notes, IOS XE 17.18.x: hardware/software restrictions.
5. Cisco Catalyst 9300: Configuring QoS, IOS XE 17.12.x: scheduler semantics for comparison; not proof of an exact 17.12.5 deployment.
6. Cisco Catalyst 9300 IP Routing Command Reference, IOS XE 17.18.x: static BFD association, unassociate, SVI sequence and interface restrictions.
7. Cisco: Understand QoS Hardware Resources on Catalyst 9000 Switches: policy installation checks; adapt member/platform syntax.
8. Cisco: Troubleshoot Output Drops on Catalyst 9000 Switches: egress queue statistics and congestion investigation.