Border firewalls and routing -- static vs dynamic routing

Solution 1:

Put external routers into HSRP/VRRP pair. Get an AS. Start doing BGP with your ISPs.

Then, everywhere inside your environment, the paths will be static. You just need to have failover, and that's what's achieved with VRRP/HSRP and firewalls in A/A or A/S configuration.

Alternatives are messier and/or less robust:

• Dynamic throughout is an unnecessary hassle.
• Static outbound on the firewalls would make it difficult/inflexible/impossible to use both uplinks simultaneously.
• Inbound redundancy will be a world of pain without kludges like PePLink/Ecessa/EdgeXOS.

Solution 2:

Note: all of the below assume you have a single site, with two ISP circuits. Please let me know if that's not the case.

For routing between your enterprise core and your DMZ, it sounds like static routing is perfectly appropriate; default route pointing to the firewalls, a route for your internal subnets (10.0.0.0/8, from the sounds of it), back to your core routers. (Although there is a school of thought that says the internet should not be routeable from your core network; more on that in an addendum at the end.) That said, if you summarise neatly, there would not be much overhead in running OSPF, EIGRP or even EBGP between your core and your DMZ. It's often down to the personal preference of the engineer.

Regarding routing between your DMZ and your providers, there are two aspects:

1. How your ISPs route to you
2. How you route to the internet via your ISPs

Regarding (1): do you have provider independent address space, allowing your VPN server and web server to be presented by both ISPs? Assuming this is the case, I would suggest that running EBGP to your providers is not a bad idea - it allows you to influence which ISP is preferred for your incoming traffic, through the use of various BGP attributes. If your servers are on provider specific address space, then there is no benefit to dynamically advertising routes to your ISPs; they may as well statically route to you.

Regarding (2): a default static route to an HSRP/VRRP address on your edge routers will work; you can use object tracking (on Cisco platforms) to determine the 'health' of the locally attached ISP circuit on each router, perhaps by pinging a well known IP. If the tracked object goes down, the router can be configured to decrease its HSRP/VRRP priority, failing traffic over to the other link.

That said, using a default is very course grained, and does not allow you to make use of any direct peerings your ISP may have with big content providers (e.g. akamai, BBC, etc). If this might be of use, EBGP peering will allow you to get more visibility into your ISPs connectivity. Many offer standard communities that allow you to accept 'customer' routes, meaning you have specific routes for any directly connected customers of your ISP, but do not need to maintain a copy of the full internet BGP table.

An aside: looking at your description, it seems that one piece of infrastructure that might be missing is an internet proxy. There is a lot to be said for not allowing your internal hosts to route directly to the internet; if the majority of outbound traffic is only web browsing, by installing one (or two, for failover) proxy in your DMZ, you could remove the need for your internal network to have a default route to the DMZ. Simply route to the DMZ subnets (where the proxy resides), and have internet reachability limited to your DMZ. A couple of benefits:

1. Centralised policy control; it allows you to restrict access to sites that your management/security people view as either inappropriate or high risk.
2. It limits the ability of any malware that makes it on to user workstations to 'phone home'. Anything that attempts to route directly to internet addresses will not be able to connect; anything that attempts to use the proxy will have to use only permitted ports (80/443), and if you subscribe to a good blacklist provider, your proxy can reduce your exposure even further.

Great question. :)