02-18-2011 11:46 AM - edited 03-04-2019 11:28 AM
Hi everyone,
I have a rather complex question for you guys, but I'm sure someone else must have done this before. I am setting up a 1921 with two ethernet WAN ports going to two seperate ADSL ISP's (via bridged modems) and one connecting to the internal LAN. There is a single e-mail / web server behind the router.
I have been reading the following which is exactly what we want to do, but I have questions. Maybe failover would be better because Load Balancing seems a little too quirky without BGP.
Thank you for any help/pointers. I know you guys do this in your free time so I don't expect you to go out of your way - but any advice is much appreciated.
02-24-2011 05:46 AM
Sorry for this late reply.
Let me try to answer your questions :
1. the doc you pointed out describes the easy part, i.e. how to handle outbound connections with 2 ISPs. The tricky part is to handle inbound connections (using static NAT). You can look at the solution discussed in the thread below :
https://supportforums.cisco.com/message/3292490
2. We can typically track the DNS server of the related provider, this gives a good indication of the 'health' of the related ISP. Another way is to track any IP on the Internet and specify in the probe the source-interface. This forces the probe reply to come from tested ISP.
3. This potential issue is handled by solution provided in thread mentioned in point 1.
4. Well, the doc you pointed out doesn't use OER as far as I see. It uses IP SLA to track next-hop. As heads up, there is a concern with applications requiring NAT ALG processing (payload inspection) like FTP. You need to use PBR on inside interface to force such type of traffic through a single ISP interface.
5. Situation is simpler when using a failover scenario (not load sharing) but NAT handles a switchover in same way in both scenarios. When an ISP is down, the connections through that ISP are lost and need to be re-initiated by users. They then go through 2nd ISP, assuming the IP SLA has of course detected the failure. Same thing happens when ISP comes back up, i.e. sessions which falled back to 2nd ISP will be failing and need to get restarted to be forwarded and NATed via 1st ISP. Note that inbound connections are not impacted when ISP comes back up (only outbound connections are).
Thx,
Fabrice
02-24-2011 06:06 AM
Okay, that makes sense.
However few little questions:
1. If using PBR, to route specific traffic through one ISP. Let's say that is HTTPS and FTP, the most common tricky ones. If ISP 1 goes down and traffic is flowing outbound, does PBR then switch traffic to ISP 2. In theory then, PBR just favours one route until that becomes unavailable? However I am assuming this does no load sharing then? The problem with HTTPS is a lot of SaaS applications and websites don't like the fact the external public IP changes, understanably, and I know this type of configuration should be used really with a few leased lines with your own AS number. In which case load sharing is almost a bit pointless because ISP 1 for example would be taking most of the strain? I.E. There is no bandwidth sharing on ports defined by PBR.
2. Inbound Static NAT. This is the tricky but, you'd think it was easy but it's not so straightforward. Is the loopback interface absolutly required? I tend to avoid them where possible. I use VLAN 1 for internal LAN instead of defining an actual port, which I supose when using physical port is a little more secure but hey. Both ISP's currently just have a static IP assigned to the WAN port, say FE0 and FE0/1. So, I think the question is - is there anyway of doing reliable inbound NAT on both IP's with outbound PBR / Load Sharing without a loopback interface?
02-24-2011 02:37 PM
1. If using PBR, to route specific traffic through one ISP. Let's say that is HTTPS and FTP, the most common tricky ones. If ISP 1 goes down and traffic is flowing outbound, does PBR then switch traffic to ISP 2.
You can use PBR next-hop tracking with IP SLA to achieve this (set ip
next-hop verify-availability
In theory then, PBR just favours one route until that becomes unavailable? However I am assuming this does no load sharing then?
Indeed but up to you to be creative in the way you define your
route-map, for example can forward half of your internal users HTTPS
traffic through ISP-1 while 2nd half of users are directed through 2nd
ISP,etc...
The problem with HTTPS is a lot of SaaS applications and websites don't like the fact the external public IP changes, understanably, and I know this type of configuration should be used really with a few leased lines with your own AS number. In which case load sharing is almost a bit pointless because ISP 1 for example would be taking most of the strain? I.E. There is no bandwidth sharing on ports defined by PBR.
2. Inbound Static NAT. This is the tricky but, you'd think it was easy but it's not so straightforward. Is the loopback interface absolutly required? I tend to avoid them where possible. I use VLAN 1 for internal LAN instead of defining an actual port, which I supose when using physical port is a little more secure but hey. Both ISP's currently just have a static IP assigned to the WAN port, say FE0 and FE0/1. So, I think the question is - is there anyway of doing reliable inbound NAT on both IP's with outbound PBR / Load Sharing without a loopback interface?
If internal servers are directly connected to NAT routers, we need to do
the trick (i.e. having NAT before forwarding decision) within the NAT
router. If you have 2 spare interfaces on NAT router, you can do that
with an external cross cable instead of using loopback interface...
Thx,
Fabrice
02-24-2011 12:50 PM
Fail over Config for Cisco Router :
Go to above link, you will see fail over for wired and wireless internet ( Example 3 - clearing NAT using EEM ). I would ping to 4.2.2.2 or 8.8.8.8 or 8.8.4.4 which I trust most than any other IPs. I have set up the fail over config using above IP addresses for pinging.
Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: