Showing results for 
Search instead for 
Did you mean: 
Join Customer Connection to register!

Dual-homed without BGP

Hello all,

Due to our companies size and current public IP needs, it doesn't seem as though we can justify a BGP implementation.  However, we have public facing services that require as much redundancy as possible.  With that in mind, I'm trying to come up with a solution that would get us as close as possible to a proper BGP design in a dual-homed environment.  I would appreciate any and all feedback or suggestions you can offer.

The attached diagram is what I've come up with so far, but I'm not sure this design is really feasible.  It contains 2 edge routers serving the independent providers IP space (/27).  I hoping I can run GLBP on these two routers to provide outbound load-balancing between the providers and use a low DNS TTL and DNS round-robin for inbound traffic "load-balancing".  I initially thought I could use L2 switches between the edge routers and ASAs, but after further review it seems as though I will need a L3 switch in order to use policy based routing to send any inbound traffic out the path it originated from.

Some questions I've come up with are:

-Will I need to double NAT?  (Edge Router -> ASA - > DMZ)

     -if not, where is the ideal place to run NAT? 

-Should I be looking at running EIGRP between the edge routers and ASA?

What am I missing here?  Again, I would appreciate any/all feedback!



Gautam Renjen
Cisco Employee

1. How will you avoid black holing of traffic without using a routing protocol easily? I would suggest running a routing protocol with the provider, even if it's not


    1.1 if the link on the inside of the edge router on the top left breaks, how will the isp attached  to it know of it?

    As per your statement, you're advertising a /27 network, which i'm assuming both providers are forwarding, so how would one know when it's down?

    1.2 How would the Layer-3 switch (if it's being used for routing) or the ASA know if the edge link from router to ISP1 is broken and not send traffic that way?

2. ASA would be better kept in active / standby mode, as you don't want to be dealing with PBR for routing and determination of symmetric paths. 

3. Use the edge routers for just isp link termination and traffic passthrough, with just an infrastructure ACL, and QoS if need be. Let it be a simple config.

4. NAT should be done on the firewall. Double natting not needed. Also, as only one asa will be active at any given time, you'll not need to use pbr, or anything else

to maintain symmetry

5. I dont know how you've configured your switches, but you can keep them for layer 2 as much as you can unless you need to create SVIs for some reason.

6. Run OSPF or EIGRP between the ASAs / Routers with a reduced timer for faster convergence.

7. Load-balancing:

    7.1 : If you go with my suggestion of using ASA in Active/standby (much more stable and standard config , from experience), you won't be able to load-balance ,

    using GLBP. GLBP load-balancing is achieved by replying to ARP requests with different mac entries. In you case, if you use glbp, the ASA would have a default

    route pointing to the virtual IP (GLBP) and will cache the mac it gets from it's first ARP request, and will keep it for 4 hours. So for that duration, the traffic

    will be forwarded to only one router and so only one isp link.

    7.2 : Even if you don't go with my suggestion and keep ASAs in Active/Active, i have seen cases where some other device might arp for the virtual IP, and the 2nd ASA

    might actually get the 1st router's response again when it arps. This will again result in the same scenario as above, and the problem will be that due to unpredictability,

    troubleshooting any issue in that area might become difficult for you and TAC.

    7.3 : However, if you configured OSPF / EIGRP For example, the ASA would get two equal cost routes, and load-balance between them per flow.

    7.4 : How are you trying to load-balance the inbound path?

Thanks a million for the thorough reply Gautam!  I'll try to touch on all of your points.

1.  We have seperate IP space from each provider.  So no, each provider will not be forwarding the others' space, only their own. 

     1.1 This is a great point and now an area of concern.  If we are not running a routing protocol between the providers (which I am assuming isn't an option, due to the lack of PI address space).  I'm wondering if this might be resolved by running EIGRP between the edge routers and the ASA as you suggest.

     1.2   I was anticipating using IP SLA tracking to handle this, but after your response I believe it would be better handled via EIGRP.

2.  My apologies - I neglected to depict the ASA's cross-over connection in my drawing.  It was my intention that they would be run in an Active/Standby configuration.

3.  After reading you're response, I can see why this is the better option.

4.  My concern with the double-nat is the 2 separate IP spaces.  I thought it might be possible to map 1-to-1 each public ip to the ASA's corresponding outside IP.  Is this not necessary (or possible)?

5.  I don't know of a reason to use SVIs in this scenario.  I thought I would need a L3 gateway for the ASA to point at that would allow IP SLA tracking of the upstream providers internet state.  It seems this would be uncessary when using EIGRP, correct?

6.  This seems to be the ideal solution.

7.  As above, I intended to use the ASAs in active/standby, so thanks for explaining how GLBP would not have worked in this design.  I'll more than likely move forward using EIGRP as you suggested.

     7.4  Hoping to achieve some level of load-balancing using 3rd party DNS round-robin of the two sets of public IP addresses, ideally set to a low TTL.  There is also some level of host detection available via the DNS service.  If one or all of the IPs are down it will be removed from the DNS pool.   

Thanks again for your response.  I need to work to understand how to handle NAT in this design, but you've helped me get a much better understanding overall.     

For internet peering, if you can run routing like i said earlier, you should go for it.

I don't see how provider address space or provider independent address space should make a differce.

If your concern of /27 and you loosing addressing blocks is the concern, then there are other ways to work that out.

Also tell me if your interent facing links are configured with private IPs or public?

If public, then is it part of the same /27 subnetted or full /27 mask. If not part of /27,then what is it ? /30?

Anyways, if you can't run a protocol with your providers, then you can run ip sla with tracking to flap your default route when

connectivity is lost with the isp. You can either choose to track upto gateway or even beyond to some known server.

Redistribute this default route into eigrp which you run between routers and ASA, and ASA will know if your uplink is up or down.

ip route track 1

track 1 rtr 1

ip sla 1

icmp-echo source-interface FastEthernet0/0

frequency 10

router eigrp 1

no auto-summary


redistribute static


Load balancing in current scenario may not work because of different ip pools from providers,

Now i see why you were saying dual natting, cause you want to nat the internet

traffic inbound going to ASA so that the ASA cna identify which router to send back

the traffic to, else the providers would drop it if they got each others addresses

in the source IP on the way out.

However, there are a few issues here:

1. Routers don't support doing a reverse nat outside --> for this scenario.

It just isn't supported, even though an outside to inside nat is configurable,

what matters is which part of the IP is getting changed, and how routing will affect

this as well, as there are different rules for natting in routers when it comes

to nat order of operation.

2. Internet IP table is huge. Even if you don't get huge amounts of traffic, expect

some 10s of thousands of NAT entries just for internet traffic which can

cause resource utilization to go high and overload .

3. ASAs have a trick with which you can do reverse nat, but trust me, you won't get support

from TAC on this. I think they'll deny that it can even be done, even though i know it can

and has been done before in only exception cases. Even if you find someone who can do it for you,

anytime that there is an issue and you need to go to TAC or a consultant for support,

you'll be refused as it's agaist all design guides and best practices. There would be unpredictable behavior.

You'll be left hanging in the middle in such a scenario.

4. Because of this, you'll have to re-think your design, maybe when it comes to ASAs.

In this case, NATTING will  have to be done on the routers. ASA can be free of any NAT config in your case.

You might be thinking that you can NAT everything on the ASA and then just NAT the ASA IP on the router.

It doesn't make much difference unless you have a specific purpose to nat on the asa. It's more or less the same thing.

Other than that, NATTING everyting on the routers also gives you one advantage. You can configure netflow

on the routers and get a good insight into the traffic flows, specially during malicious activities or if there is a DOS attack,

or if a user is hogging a lot of your bandwidth, intentionally (torrents) or unintentionally. You can also fine tune QoS based on inside IP address groups

on the router for internet bandwidth, which would be tougher if you just had one ASA NAT IP arriving on the router (deep packet inspection = more cpu).

i agree since there is one outside interface then ECMP can work

You can define up to three equal cost routes to the same destination per interface. ECMP is not supported across multiple interfaces. With ECMP, the traffic is not necessarily divided evenly between the routes; traffic is distributed among the specified gateways based on an algorithm that hashes the source and destination IP addresses.

The following example shows static routes that are equal cost routes that direct traffic to three different gateways on the outside interface. The adaptive security appliance distributes the traffic among the specified gateways.

hostname(config)# route outside

hostname(config)# route outside

hostname(config)# route outside

also the below link is go exampe for other type of topology

also you could use the ASAs not in redundant mode and have them in transparent mode and use the 
default gateway as the routers VIPs address 

but this depends if you need VPN for example them the above is not an option 

hope this help


To answer your question, our internet facing links are public IPs, subnetted as /30, and are outside of our /27 block.

I'm afraid I'm a bit more confused regarding the NAT configuration.  You say configuring NAT in this way on the routers is not supported, but because of the limitations of the ASA - it will have to done on the routers?   

Regarding the number of NAT entries on the edge routers - we were hoping to use 2921s with the default RAM of 512MB.  Would you suggest maxing them out at 2.5GB?

My thought in using 2 routers was to provide hardware redundancy.  Would this design be simplified by using 1 router for both ISPs?  Or is there another configuration you might suggest?

Thanks, I appreciate your insight.

Hey Adam,

I thought some more on this, and realized that even if we configured NAT on the routers, the ASA would stilll have no way to know what the incoming path of the traffic was, to be able to forward the outbound traffic to the correct router.

So, here are a few suggestions regarding this:

1. As we have to do "source based routing", for this to work, let ASA send the packets to either router (by hsrp virtual ip as the next hop, or if you run a routing protocol between the asa and routers, then dynamic route).

2. The routers will have a PBR configured and applied to the inside interface to send all traffic with a source IP not supported by it's ISP, to the other router's inside interface IP. So a packet that comes from the ASA to lets say Router1, but actually has a NAT IP of the ISP2's pool, will hit pbr, and take a U-turn, and be sent to Router2. Here it won't match it's pbr as it is meant to be forwarded out Router2, and will be sent out.