Ah! You are the security engineer at a medium sized bank, and perhaps you want to expand your Internet access to include a 2nd ISP. You are already paying $$ for the 10Mbps and now you are going to cough up even more $$$ for the new 25 Mbps service. Your websites and email servers are well set, and they are using static translations on the first ISP public address. How can you bring the 2nd ISP online, load-balance traffic across both links but preserve what you have built thus far?
You configure a select set of static routes (with SLA tracking if necessary) and this forces some outbound traffic off to the new link:
route outside-new 128.0.0.0 255.0.0.0 x.x.x.x
Just select a few more of your favorite Internet targets. You can enable the SLA tracking feature to add an element of dynamism!
and so on...
But, you notice that connections for the outside are not completing. You setup "logging console notifications" and observe uRPF drops! Now that's easy to explain: traffic to your static translations will come in via the old circuit but new more specific routes break uRPF on the ASA. The solutions is to check and disable "ip verify reverse-path" and Voila! you are back in business!
You configure a select set of static routes (with SLA tracking if necessary) and this forces some outbound traffic off to the new link:
route outside-new 128.0.0.0 255.0.0.0 x.x.x.x
Just select a few more of your favorite Internet targets. You can enable the SLA tracking feature to add an element of dynamism!
and so on...
But, you notice that connections for the outside are not completing. You setup "logging console notifications" and observe uRPF drops! Now that's easy to explain: traffic to your static translations will come in via the old circuit but new more specific routes break uRPF on the ASA. The solutions is to check and disable "ip verify reverse-path" and Voila! you are back in business!
