Policy Based Routing/Default Route Catalyst 9600 Sup-2

[griffijo]

For several years I've been using some simple policy routing to set a default route for specific traffic.  I have 2 Internet circuits (2 different ISPs) that both terminate on a Catalyst 9600.  They are both full rate 10-Gbps circuits that connect to 2 Firepower 4215 appliances.  I make one of the circuits look better by tweaking the delay on a redistributed route from one of the Firepower.  The bulk of our traffic uses the preferred route. I then use PBR to set the default route for the 2nd circuit (data center, admin users, etc.)

!
Extended IP access list Data-Center
10 permit ip 192.168.200.0 0.0.0.255 any
20 permit ip 192.168.2.0 0.0.0.255 any
30 permit ip 192.168.101.0 0.0.0.255 any
40 deny ip any any
!
route-map PBR-DEFAULT-ROUTE permit 10
match ip address Data-Center
set ip default next-hop 192.168.207.2
!
Interface Fo1/0/1
ip address 10.1.1.1 255.255.255.252
ip pim sparse-mode
ip policy route-map PBR-DEFAULT-ROUTE
!

This all worked well for several years.  We recently upgraded the Supervisor from a Sup-1 to a Sup-2 and the policy routing no longer works.  It appears to send all traffic to the Firepower, as if we were doing a "set ip next-hop" instead of a "set ip default next-hop".  I can see this in the connection table on the Firepower, where the source and destination IP address are both in the local routing tables.  I've tried 3 different versions of code and the behavior remains the same.  I was wondering if anyone had seen similar behavior.  Yes, I do have TAC case open.  The first assigned engineer has not been helpful as they've told me the behavior was expected.  We briefly put back the Sup-1, and everything works fine. 

Thank you.

[MHM Cisco World]

Defualt meaning the pbr check rib first, 

Are you sure the defualt route is available in rib?

MHM

[griffijo]

Yes, absolutely. 

EIGRP-IPv4 VR(eps-eigrp) Topology Entry for AS(100)/ID(172.31.94.3) for 0.0.0.0/0
State is Passive, Query origin flag is 1, 1 Successor(s), FD is 786432, RIB is 6144
Descriptor Blocks:
192.168.206.2 (FiftyGigE5/0/47), from 192.168.206.2, Send flag is 0x0
Composite metric is (786432/720896), route is External
Vector metric:
Minimum bandwidth is 10000000 Kbit
Total delay is 11000000 picoseconds
Reliability is 255/255
Load is 1/255
Minimum MTU is 1500
Hop count is 1
External data:
Originating router is 192.168.206.2
AS number of route is 0
External protocol is Static, external metric is 0
Administrator tag is 0 (0x00000000)
192.168.207.2 (FiftyGigE5/0/48), from 192.168.207.2, Send flag is 0x0
Composite metric is (1441792/1376256), route is External
Vector metric:
Minimum bandwidth is 10000000 Kbit
Total delay is 21000000 picoseconds
Reliability is 255/255
Load is 1/255
Minimum MTU is 1500
Hop count is 1
External data:
Originating router is 192.168.207.2
AS number of route is 0
External protocol is Static, external metric is 0
Administrator tag is 0 (0x00000000)

[MHM Cisco World]

Friend this eigrp topolgy not rib'

The pbr check prefix in rib.

MHM

[griffijo]

You are right in that the prefix is not in the rib.  I wonder if it does not meet the feasibility condition.

[vishalbhandari]

@griffijo It sounds like your issue is related to a change in how the Supervisor 2 processes policy-based routing (PBR) compared to Supervisor 1. Specifically, the set ip default next-hop command seems to be behaving like set ip next-hop, sending all traffic to the Firepower regardless of matching the local routing table. Since it worked perfectly with Supervisor 1, it suggests a possible software or hardware processing difference in Supervisor 2.

Here are a few suggestions while you await TAC resolution:

1. Verify if there are any known bugs in the versions you've tested by checking the Cisco Bug Search Tool.
2. Test using set ip next-hop verify-availability or explore alternative PBR configurations that might address this.
3. If possible, try a more recent or recommended IOS XE version specifically for the Catalyst 9600 with Sup-2, as the issue could be code-related.

Reverting to Supervisor 1 temporarily, as you already tested, confirms this isn’t a configuration issue. Keep escalating your TAC case for clarification and potential fixes.

[paul driver]

Hello
Please note:

set ip next-hop =  will ALWAYS PBR first irrelative of any route populated in route table
v
set ip default next-hop =  will ONLY PBR if route table does NOT have definitive/default route in route table

Additionally  the below will PBR first
set ip next hop recursive
set ip interface 


Additionally  the below will route via route table first before PBR
set default interface 

[griffijo]

Yes, this is the behavior I am expecting.  I am using the set ip default next-hop, expecting it will PBR if the destination is NOT in the route table.