PBR verify availability track object on FMC 7.4

[tato386]

I am setting up PBR under device management on FMC 7.4.  (in the past I had done this with FlexConfig but it seems that starting with 7.1 that **nctionality has been disabled from FlexConfig and moved to device management).  Under dev mgmnt/PBR/verify availability there is an option to enter a track but it's not clear if this should be an existing track object or the PBR screen will create a new object.  I started by just entering a random number with the thinking it will create the track but it appears it does not?  When I connect to the LINA and issue a "show track" command I only see the track objects that I added previously using SLA monitor in the object management screen.  Is it possible that this new track object lives somewhere else and I need to use a different command to see its status?  Or am I overthinking this and I need to create a track object separately and reference this object in my PBR config?   See attached example were PBR created track is 222 but does not appear in LINA config.  Track 3 and 4 were created using object management screen.

!
route-map FMC_GENERATED_PBR_1715304385871 permit 5
match ip **bleep** acl_PBR
set ip next-hop verify-availability 1.1.1.1 1 track 222
!
sla monitor 3
type echo protocol ipIcmpEcho 8.8.4.4 interface interface3
timeout 6000
sla monitor schedule 2 life forever start-time now
sla monitor 4
type echo protocol ipIcmpEcho 8.8.8.8 interface interface4
timeout 6000
sla monitor schedule 1 life forever start-time now

!
track 3 rtr 3 reachability
track 4 rtr 4 reachability

[tato386]

update: I was not able to get PBR with verify-availability working using only the PBR config screen in dev management. Two issues I had were that it would add two "set ip next-hop" lines in the PBR and that it does not create an SLA tracking object.  I used FlexConfig to remove the extra line and create the SLA and this seems to work as I need.  Below is summary:

** device management generated PBR **
route-map FMC_GENERATED_PBR_1715304385885 permit 5
match ip **bleep** acl_PBR-ISP1
set ip next-hop verify-availability ISP1_gatewayIP 1 track 3
set ip next-hop ISP1_gatewayIP

** "fixup" FlexConfig fpr dev mgmt generated PBR **
route-map FMC_GENERATED_PBR_1715304385885 permit 5
no set ip next-hop ISP1_gatewayIP

no sla monitor 30
sla monitor 30
type echo protocol ipIcmpEcho 8.8.4.4 interface inf_ISP1
timeout 6000
sla monitor schedule 30 life forever start-time now

track 3 rtr 30 reachability

[Rob Ingram]

@tato386 you could use the interface priority instead of using Flexconfig

"Interface Priority—The traffic is forwarded based on the priority of the interfaces. Traffic is routed to the interface with the least priority value first. When the interface is not available, the traffic is then forwarded to the interface with the next lowest priority value."

https://www.cisco.com/c/en/us/td/docs/security/secure-firewall/management-center/device-config/710/management-center-device-config-71/routing-policy-based.html

[tato386]

yes, but what is the definition of "interface not available"?  The FTD interfaces are connected to the ISP's on-prem router so as long as there is power the FTD interface will show as up even if no path to internet.  I guess path monitoring might help here?  If path  shows down does that create an interface not available event?

[Rob Ingram]

@tato386 yes use path monitoring. Here is a better guide:- https://secure.cisco.com/secure-firewall/docs/policy-based-routing-with-path-monitoring

[tato386]

looks pretty good.  I'll give that a shot and post back.

[tato386]

@Rob Ingram I tried to use path monitoring and the device management PBR config but was not able to achieve the desired results.  When both interfaces are in a normal state the PBR functions as expected.  However, I then tried to simulate a failed circuit by using a bogus IP address in the IPv4 peer target of the primary interface path monitoring config.  I can see from the health monitor that the MOS for that circuit dropped to 0 and the packet loss jumped to 100% but yet the FTD continued to router traffic out that "failed" interface.   Maybe there is some other step I need to take?

Thanks   

[tato386]

pbr: policy based route lookup called for 10.0.0.11/62195 to 18.64.243.21/443 proto 17 sub_proto 0 received on interface inf_inside,
pbr: First matching rule from ACL(3)
pbr: route map FMC_GENERATED_PBR_1715304385898, sequence 5, permit; proceed with policy routing
pbr: policy based routing applied; egress_ifc = inf_ISP2 : next_hop = gw_ISP2
pbr: policy based route lookup called for 10.0.0.11/56704 to 3.211.227.81/443 proto 6 sub_proto 0 received on interface inf_inside,
pbr: First matching rule from ACL(3)
pbr: route map FMC_GENERATED_PBR_1715304385898, sequence 5, permit; proceed with policy routing
pbr: policy based routing applied; egress_ifc = inf_IPS2 : next_hop = gw_ISP2

fpr# show path-monitoring
Interface: inf_ISP2 (Ethernet1/1)
Remote peer: 33.44.55.66
Version: 7546
Remote peer reachable: No
RTT average: N/A
Jitter: N/A
Packet loss: 100%
MOS: 0.0
Last updated: 7 second(s) ago

Interface: inf_IPS1 (Ethernet1/3)
Remote peer: 8.8.8.8
Version: 7546
Remote peer reachable: Yes
RTT average: 5029 microsecond(s)
Jitter: 751 microsecond(s)
Packet loss: 0%
MOS: 4.40
Last updated: 7 second(s) ago

MOS: 4.40
Last updated: 7 second(s) ago

[tato386]

Team,

After experimenting a bit on my own and discussing it with the TAC team, it seems PBR (w/o FlexConfig) will not be able to do what I need. What I am looking to do is to send low priority traffic (defined by ACL) out of a low performance interface as long as that interface has working L3/IP connectivity to a peer on the Internet.

In my case I would need PBR to recognize the "Remote peer reachable" path monitoring metric which it does not. None of the other metrics work for me because priority and order only fail over when L2 is down. MOS, jitter, RTT and packet loss are better on higher performance interfaces so those won't work either.

The TAC guys are still mulling it over but most likely I'll have to wait/hope the developers add this capability in the future.  I will have to stick with FlexConfig for now.

Below is sample output from path monitoring which shows the PM metrics for ISP2 in up state and no L3/IP state.

> show path-monitoring
Interface: inf_ISP1 (Ethernet1/1)
Remote peer: 8.8.8.8
Version: 10600
Remote peer reachable: Yes
RTT average: 3454 microsecond(s)
Jitter: 92 microsecond(s)
Packet loss: 0%
MOS: 4.40
Last updated: 0 second(s) ago

Interface: inf_ISP2 (Ethernet1/3)
Remote peer: 8.8.4.4
Version: 10600
Remote peer reachable: Yes
RTT average: 5079 microsecond(s)
Jitter: 829 microsecond(s)
Packet loss: 0%
MOS: 4.40
Last updated: 0 second(s) ago

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

> show path-monitoring
Interface: inf_ISP1 (Ethernet1/1)
Remote peer: 8.8.8.8
Version: 10762
Remote peer reachable: Yes
RTT average: 3283 microsecond(s)
Jitter: 89 microsecond(s)
Packet loss: 0%
MOS: 4.40
Last updated: 5 second(s) ago

Interface: inf_ISP2 (Ethernet1/3)
Remote peer: 33.44.55.66
Version: 10762
Remote peer reachable: No
RTT average: N/A
Jitter: N/A
Packet loss: 100%
MOS: 0.0
Last updated: 5 second(s) ago

[MHM Cisco World]

From your previous output I notice peer reachability is NO and hence I think pbr not work' 

We use usually in IOS use something solve this issue' by 

Add new next-hop like 8.8.4.4 

Add static route for this next-hop via same egress interface we use in set of pbr

That solve issue make next-hop UP and path work.

Try it 

""Remote peer reachable: No""

MHM

[tato386]

@MHM Cisco World peer reachability in my example is there by design.  I purposely used a bogus IP (33.44.55.66) in the path monitoring of the interface in order to simulate a L3/IP loss to the Internet.  That's how I tested and confirmed PBR on FMC (w/o FlexConfig) currently has no option for my use case.

[MHM Cisco World]

You use next-hop 8.8.8.8/8.8.4.4 or direct connect IP?

Use direct connect IP not far multihops IP

MHM

[tato386]

@MHM Cisco World Thanks for the tip but I am not looking to fix the Remote Peer Reachable issue.  It will work fine if I use a valid IP.  I only did this to try to test if the PBR will recognize this and failover but unfortunately it does not recognize when remote peer reachable is no.

[MHM Cisco World]

But without next-hop reachability and using verify then pbr not work.

Pbr is divide into

Match acl or app 

Set 

The part of set is not correct or next-hop not reachable then all pbr will not work.

Anyway' wait TAC answer and then compare them answer with my note.

Goodluck in your task 

MHM