ISP Health and OSPF default advertisement

[#1]

Hi All, I come from Cisco background and trying to implement something similar to IP SLA and infleunce the outcome of the same to stop propagation of default route to the core switches. Here is the set up. We have an existing Juniper SSG140 firewall, that runs OSPF with two L3 switches, so each switch learns the default route from the firewall. We have two ISPs on the firewall with IP Tracking ( similar to Cisci IP SLA) running. Now we want to add a new firewall, so that we have some hardware redundancy as well as ISP circuits redundancy as well. This new firewall will be Fortigate 400A or similar and will terminate a new ISP connection. So each of the firewall will be running ospf thru the LAN side interface and advertise the default route to the two Core L3 switches, with Juniper being having a higher matric / cost, so that switches will prefer the default route coming in from new Fortigate and thus normally internet bound traffic will be routed thru Fortigate. I noticed there is a feature under interface, to specify a server IP address that can be on the internet ( something like openDNS, or Google DNS) and if that stops pinging, firewall will shut down that interface. can I implement the same feature on port 1 (LAN, trusted side) so that when ISP circuit is down, port 1 will get isolated (unless the address I specify has to be reachable thru the port 1), and thus core switches will stop receiving the ospf route thru fortigate and switchover the traffic to Juniper? Or is there another way to achieve this failover? Also I was looking for Cisco DNS Doctoring type of feature and looks like dnstranslation is it. But I am a bit confused as to what should be exact code to achieve? Assume inside webserver is 192.168.10.25 and mapped address on public side is 64.128.32.25. The public FQDN is webserver.test.com and windows FQDN is webserver.test.local. Because of windows domain name to be test.local, I can not simply add a local Host (A) record in internal domain controller/DNS and hence name resolution for webserver.test.com goes out and comes back as 64.128.32.25. That will make all traffic to always be looped thru firewall. Appreciate in advance for your support.

[#2]

I do find that Fortigate supports VRRP, and so does the Juniper SSG. I can then use VRRP between the two firewalls, making Fortigate the active gateway, so hardware failure on Fortigate can be mitigated by automatic switchover to Juniper via VRRP. Juniper has a feature to Track IP address thru an interface to trigger VRRP failover. Looks like I can do the same with Fortigate also. Under Fortigate High Availability Handbook, VRRP Chapter, Optional Configuration settings on page 265, there is an option, Monitor the route to a destination IP address using the vrdst option. But I am not sure if this will work, since we will have a static default route in firewall pointing to ISP router, so the router to any destination IP address will still get covered by the static default route, which will thus not go down. Please help.

[#3]

Can someone please clarify this option please? Monitor the route to a destination IP address using the vrdst option Thanks

[MisterAG]

I have a similar setup to what you are thinking of. Fortigate has a link to ISP1, and links to our two core routers. It advertises default information originate with the default metric. Backup Fortigate has a link to ISP2, and links to our two core routers. It advertises default information originate with a high metric (so that its route does NOT get installed into the route table on the core routers) Both Fortigates are configured with ping testing on their WAN (ISP facing) interfaces to ping the next hop router. If the next hop router stops responding to pings, the Fortigate will stop advertising default information originate, and the core routers will reroute traffic to the backup link. Once pings to the next hop router start replying again, the Fortigate will re-advertise default information originate, and traffic will flow through the main link again.

[MisterAG]

I personally don' t think that VRRP and OSPF mesh well for what you are planning on doing. Let OSPF decide when there is a hardware failure. The last thing that you need is for one router to be the VRRP master, and the other one have the default route installed on it. By either using physical links or tuned OSPF timers, you can detect link failure in a matter of seconds. I personally use the default timers and intermediate switches because I prefer operational flexibility, and don' t mind if the Internet is down for a minute before rerouting traffic.

[#6]

Thanks so much. I did set up ospf between Juniper SSG and Fortigate 400-A last Friday using OSPF. All is working fine since then. I was exploring using either of VRRP or OSPF and not both. Fortinet L3 support confirmed that VRRP implementation is buggy and will only be fixed in upcoming MR3. So I instead was able to set up OSPF only.

[MisterAG]

make sure to test your ping check on the Fortigate. I ping the next hop on my Fortigates, so as it stands I can' t detect upstream issues right on the FGT device. When I have upstream issues I currently either trust the provider' s BGP to figure it out quickly or stop default information originate manually. If you get the ping check to work properly by pinging something on the Internet (8.8.8.8 maybe?) let me know.

[#8]

Yes, I am doing 4.2.2.2 for ping check and I have tested, it works flawless. Had the ISP remove the static route on their POP router that points our Public subnet, to their CPE router at our site, for a minute. So we are good for actual issues beyond the next hop. Thanks again.