Static Route Removal

[theonewhoknocks]

Default route via ISP-A (primary) has not yet recovered, even though the monitored IP address (DNS server of ISP-A) is already rechable via the interface connected to ISP-A router. (tested via ping source x.x.x.x host y.y.y.y)

I have seen the logs from previous months that the firewall has detected path failure and was able to recover. So I assume the setup is correct?

Any other troubleshooting that I can do? Or any other things to double check on my setup?

[theonewhoknocks]

Update on this.

Current routing table is still via ISP-B.
Upon using traceroute source x.x.x.x host y.y.y.y, I saw that the DNS Server of ISP-A is being reached via ISP-B.

Do I need to put a specific static route pointing to DNS Server of ISP-A via ISP-A gateway?

[rmfalconer]

Do you have separate interfaces connected to ISP-A and B?

How are your static routes configured? Sounds like path monitoring. What are you using for source interfaces on each route?

What is the metric configuration on each route?

[Harshit]

if you are monitoring ISP A , then yes, the route for the tracking of that DNS(A) would have to be forced through ISP A only using the static routes.

~HTH 

[OtakarKlier]

Hello,

You can also specify the interface. Hopefully each ISP has their own?

Regards,

[theonewhoknocks]

Hi All,

Here's my setup.

ISPA (eth1/1) and LAN interfaces on one VR1

ISPB (eth1/2) on another VR2

VR1 Routes:

-Default route  (defaul admin distance, metric 10) w/ path monitoring (Monitored IP - DNS of ISP-A, source eth1/1, other settings default)

-Backup default route to next VR (default admin distance, metric 20)

-Specific /32 route of DNS of ISP-A to force it via ISP-A Gateway.

-Tunnel Routes

VR2 Routes:
-Defaul route pointing to ISPB gateway

-Return routes to LAN segments (via next VR1)

[theonewhoknocks]

I just added the specific /32 route going to DNS os ISP-A via the ISP-A Gateway.

ping source eth1/1 (ISP-A port) host DNS of ISPA, fails now. 

[theonewhoknocks]

Update:

Stand-alone test worked fine.
Can reach the internet and the DNS of ISPA (monitored IP in path monitoring of default route)

So I guess the problem is on the PA? Anything that I need to double check?
Checking from previous logs, firewall was able to detect path failure and was also able to recover.

[OtakarKlier]

Hello,

Do you have any dynamic routing between the VR's? Perhaps that is how it learned the routes? But sounds like you have it solved with the static /32 routes. I also use them to be super specific on certain destinations for monitring and dynamic routing.

Regards,

[theonewhoknocks]

Hi @OtakarKlier,

No Dynamic Routes between VR's.

Adding the specific /32 static route did not resolve the problem.

Path Monitoring status is stil down.

[OtakarKlier]

Hello,

Sorry I misread that. when you do the ping, do the traffic logs show anything useful or is the traffic allowed? Also is ISP A in an upstate? What about the routes in the Forwarding table, are they correct?

https://www.paloaltonetworks.com/documentation/80/pan-os/web-interface-help/network/network-virtual-...

There are two tables, the route table and forwarding table, the traffic will flow per the forwarding table.

Sorry if i missed something in an earlier post.

[theonewhoknocks]

@OtakarKlier no worries.

Port Connected to ISPA is in up state. No logs is generated as I am using the eth1/2 as the source of the ping to reach the ISP-A DNS Server.

Routes in the forwarding table:
Default Route is via next VR (ISPB VR)

ISP-A DNS Server via ISP-A Gateway

[OtakarKlier]

OK, I think I understand now. What happens if you ping ISP A DNS from port 1/1?

[theonewhoknocks]

@OtakarKlier

Port 1/1 - ISP B
Port 1/2 - ISP A

ping 'port 1/1 IP' host 'ISP-A DNS IP' --- success

ping 'port 1/2 IP' host 'ISP-A DNS IP' --- fail

[OtakarKlier]

Hello,

I would say double check the FIB table and traffic logs as this kinda makes sense to me, but I could be wrong. Meaning that since you have the /32 route to the DNS of ISP A, when you try to ping from the other ISP B interface, its trying to route internnally and out ISP A interface. In the VR or ISP B put in a /32 route to ISP A DNS and I bet it will reply.

Regards,