@TheGoob wrote:
I see what we are changing, but not seeing how that change makes it work? Was going extended to standard really all there was to it??
I now have 2 hops. Thank you.
Then all's well now, correct?
No, changing the ACL to a standard ACL was actually inconsequential. I only did that to make it a bit clearer that only the source IP is being used by (this case instance of) PBR. (BTW, an extended ACL might still be used for other PBR matching purposes, such as port numbers or ToS tags, etc. It's just appears that it ignores the destination IP. I suspect, this goes back to some design reason; like possibly as "normal" routing uses destination IP, we [PBR] don't need to consider it.)
Anyway, what's the critical change is: not using the set next-hop, as was done previously, because that (again because destination IP was ignored) applied to traffic we wished to ignore. Adding the "default" keyword, limits the policy to only apply it if the traffic being redirected would need to use the default route, as used for sending non-local traffic to 10.0.0.1. If traffic sourced from 192.168.7.0/24 would use the default route, the new replacement policy, for just that particular traffic, uses a new default route, 10.0.2.1.
BTW, it's been multiple decades since I've played with PBR, and I vaguely recall not particularly liking it, because of its complexity dealing with failures. Like, right now, if your new second path goes down, logically, you would want to redirect VLAN 8 traffic back to the original default. Likewise, if the other default path fails, you might want its external traffic to use the new second path. What I've provided, doesn't deal with such situations, but I believe it's possible using its own tracking capabilities, but this is how PBR complexity rapidly develops
Also, BTW, I spent quite a few hours last night, working in CML, to resolve this. It was only when I noticed, "gee it seems to be ignoring the destination IPs in ACL ACEs" (also wondered, a bug?), and doing more specific Internet searches, that my browser's AI summary, noted it had references that mentioned PBR ignores destination IPs. (My Internet searching also found other "quirks" with PBR, most related to using "deny", either not working, or processed in software, very slowly. [Did I mention, my having vague memories of not liking PBR? Laugh.]) (Oh, there's also even a PBR caching feature, but I don't know whether it offers any major benefit since CEF was introduced.)
Lastly, in a case like yours, what I would generally do is route across both paths, and if certain traffic needed better service, I would use QoS. (Additionally, what could be done with Cisco's OER/PfR, if available, was, I thought, amazing!)
