NAT DIA tracker and two default route

[dijix1990]

 I bumped into interested problem (don't know is it normal or not)

1. I have two isp with two default route
2. I have nat dia (Direct Traffic from Service VPN like ip nat route vrf 16 0.0.0.0 0.0.0.0 global) with track to google (8.8.8.8)
   and today one of my isp did preventive maintenance. 

Sla reachability for this isp was timeout but DIA tried to sent traffic via problem providers because def gw was reachable

I thought that if sla has problem traffic not sent to problem link.

[dijix1990]

we don't have track for default route in sdwan (for transport)

when we have arp for default gateway default route doesn't dissapear. despite endpoint-tracker to 8.8.8.8 or cisco.com and doen't work for problem isp. I don't know why with endpoint tracker nat need to sent traffic via working isp

S*    0.0.0.0/0 [1/0] via 100.100.100.1
                [1/0] via 200.200.200.1

endpoint-tracker google
 endpoint-ip 8.8.8.8
 interval 20
 multiplier 2
 tracker-type interface
 
interface GigabitEthernet0/0/1.936
 ip nat outside
 endpoint-tracker google 
 
interface GigabitEthernet0/0/1.937 
 ip nat outside
 endpoint-tracker google

sh endpoint-tracker
Interface                        Record Name            Status          Address Family   RTT in msecs    Probe ID   Next Hop
GigabitEthernet0/0/1.936         google                 Up              IPv4              -               -          -
GigabitEthernet0/0/1.937         google                 Down            IPv4              -               -          -

by netflow I can see that nat traffic try to sent via GigabitEthernet0/0/1.937

after I disable GigabitEthernet0/0/1.937 internet via nat started to work. Before it I tried to reload router because thought it's bug 

isr4331 Version 17.12.5a

[MHM Cisco World]

MHM

[dijix1990]

Do you think I don't know how configure nat dia with tracker? 

[MHM Cisco World]

Why you talk with me like this ?

I try help here.

Anyway goodluck 

MHM

[dijix1990]

the problem is probably due to the fact that the provider has a stub at the time of work and all traffic on http tests looks successful periodically, which makes the device not understand that the channel is not working, as I understand it, there is no icmp verification mechanism for isr4331 to somehow circumvent such problems. It's only exist for device from Release 17.13.1a