that's the thing, those guys will only provide one single routable IP address.

and yes, we will setup VPN L2L tunnels from our main office to this 10.10.10.0 office, so we will need to configure VPN on both routers.

Any work-around to this?

perhaps HRSP only with 1 IP???? :) I know is not possible to use one IP in HSRP, but in situations like this, what are the work arounds?

What about just making one of the routers act as an stand-by router? so this way, when one of the routers fails, the other ones becomes active?

what about IP SLAs on the inside? can we use some sort of logic on the inside interfaces of the routers so that we can make one router active and monitor its outside interface so when this fails, to re-route the traffic towards the other interface..??? but again, this looks very doable and the problem still persists on the outside... how do we get around on the outside interfaces of the routers??

Can we stick or associate that single routable IP to a "NATed" private IP (or perhaps to a fake private IP), and use this IP in the middle of the 2 routers? (virtually speaking that is...) so this way, we can configure the outside interfaces of the routers with private IP addresses that will be on the same subnet as that IP that we associated with the routable public IP address?

"how do we get around on the outside interfaces of the routers"

I believe your statement sums it up. You have one point of failure. The only other suggestion I would have is get another ISP to bring a circuit in if your provider will only assign one address. You might also look into a cellular backup in case this link were to go down, but when you only have one pipe coming in, you only have the one pipe going out. =)

Actually, I'm not sure where you're located in the world, but AT&T provides a cellular backup device called Anira (or something like that). It can run VRRP with your existing router, and when the provider goes down, you'd be able to route all of your traffic through the Anira appliance out a cell connection. You pay a hefty cost per month for the amount of bandwidth that you're allocated, but it may be worth it to you.

HTH,

John

If you add another device in front of the 871s you still have a single point of failure. As j.blakley points out, you have a bigger problem if you have only a single WAN circuit. I think it's more likely that you'll experience a failed circuit than a failed router.

I forgot to tell you, although it should be overunderstood, that the single IP that the "DATA CENTER" gave us already has all the redundancy and SLAs required. This is not just another regular T1/T3 circuit where you put your router behind it and pray the circuit, or your single router, will never go down.

A 3rd router will indeed solve our problem but again, like you pointed out, will give us a single point of failure.

I tried NATing, but no goal. A shorter path was faking the MACs. If the routers both have the “same mac address”, then the ISP router/switch will not care. So I decided to try this and issued a single command to Router-1 on the outside interface: “mac-address xxxx.xxxx.xxxx” where xxxx.xxxx.xxxx is the mac-address of the outside interface of Router-2. With this, the ISP router/firewall/switch does not know that traffic is coming from both routers; as far as that guy is concerned, traffic is coming from single IP address 65.65.65.49 when in reality, it is coming from the 2 routers.

During testing, I took down the outside interface of router-1 and traffic was still going out to the internet via router-2.

The real trick was on having the config on both routers identical to each other. Here is where I spent more time testing. All my testing with outbound traffic (initiated by internal hosts towards the internet) worked great, but I needed to test traffic that initiated from the outside towards the inside. So I allowed tcp port 5900 on router-1 to go to an internal machine, 10.10.10.20. It worked, but sometimes it didn't; so I had to configure the same stuff on router-2. This is because when you come from the outside, your packet hits the ISP first, and this guy says “I got a packet destined to 65.65.65.49, so I need to send it to him and his ARP address says it is at port 0/4 on my number3 switch” So router-1 is connected to port 0/4, so it will grab the packet and also because router-1 had the 5900 port open to 10.10.10.20.

But when trying to access this internal host from the outside didn't work, I knew it was because the packet was trying to reach the internal host via router-2. So far I knew this so I went to router-2 and configured the same statetement I had done on router-1 and it worked.

Once again, it works, but what I don't understand is the way or how the packets get redirected, when coming from the outside. If router-1 is connected to port 0/4 on the ISP switch, then the ISP routers will look at the arp table on the switch where 65.65.65.49 is connected and will see that its mac-address is said to be at that port. But what about this same mac-address, associated with the same IP, being at the other port, switch port 0/5, of the ISP? Here is where I've stopped as this has blown my brain cells for today.

I didn't have any problems with established connections from an outside computer to an internal host (connection, was initiated on the outside). The connection never disconnected. In fact, when I took down one of the routers, the established connection remained, making it seem I had a perfect ASA stateful failover. The problem I do have is when I have a connection, for example a telnet connection, initiated from the outside to the one of the outside interfaces of one of the 2 routers. I would telnet to the single Public IP, one of the routers will obviuosly respond because I was prompted for credentials, and I would get in. So I would really successfully connect to one of the routers via a telnet session, but after 45 seconds or so, the session would dropped. I did this same test many times and all the times it dropped.

Any help?

GLBP load balances outbound traffic to both 871s. The switch gets a frame through f0/4 with a MAC address from Router-1, it updates its CAM table, then a short time later it gets another frame with the same MAC address via f0/5, Router-2. It updates its CAM table with the new entry. The switch has to keep changing that MAC entry in the CAM table back and forth between the two switchports.

While I applaud your ingenuity, I think you already realize that this setup will be hard to manage. If you're not sure how it works under normal circumstances, how do you troubleshoot problems with it?

Did you try using HSRP instead of GLBP on the inside?

I have only deployed one single host on the LAN and all tests where done on this. Meaning that I was able to access this host from the outside and the connection remained when any of the 2 routers was taken down.

These will be what I can call normal circumstances. The unexpected ones have been so far the telnet connections to the routers. I think your logic should apply since it makes sense that the ISP switch will be going crazy on its CAM table.

On this same token, however, (I'll be 90% sure about this comment) I think the ISP switch will have 2 entries on its table. Both of these entries will have the same mac-address but each of them will be pointing to the different ports where the routers are connected. Thus, it is a matter of the routers, or perhaps how the routers will be responding to these request rather than the ISP switch going crazy updating its table. Doesnt the switch asks first for who to send the packet destined to the one single IP? rather than knowing exactly who of the 2 mac-addresses at the 2 different ports the packet is destined for?

I was discussing this with a colleague and we were looking at this on the fact that because this is some sort of an illegal thing, the behaviors are indeed strange even under normal circumstances. Based on this discussion is also the fact that I am mentioning that it could be more of a "who responds faster to the requests".

At any given point of time, the ISP switch will put the request but if, for example, router-1 happens to be busy at this particular time, then it will not be able to respond and this will make the router-2 grab this packet because, let';s say for the sake of this argument, this guy happened to be free at this particular time.

That is my take which again, I think I am only 90% sure.

But the stuff I still dont get, but it works good so far, is when the connection is placed to the internal host. The connections being dropped are the ones placed to the outside interfaces of the routers (telnet)... why is it that I dont have any dropped connections when I establish a connection to the internal host?

My take on this is that because the outside connectioon already has an "established" connection to the internal host, the return traffic somehow already knows how and where to go... but I am not too sure because say that this connection came thru router-1 to host 10.10.10.30 but what about if when this happened, host .30 had router-2 as its default gateway (GLBP)??? will the return traffic go back to router-1 or will the return traffic go back via router-2 because this is the current default gateway of the host?

slmansfield, this is what I call sexy information. This is why I wasn't 100% and thank you very much for clarifying it.

This mess was actually inhereted. I am the guy who just puts fires out and by no means I am a cisco intermediate (i'm still a novice) but I can work with people like you to get this done.

I am also stubborn and like to find solutions for stuff like this. So I went further and I found a real fix without any hidden stuff (meaning overhead, hard to manage, unsupported, etc.) At least in theory. I have found the real solution to this problem and I am couple hours away from testing it. There is a feature called EEM (Embedded Event Manager). With this, a script can be run to keep the outside interface of router-2 in a shutdown state and make it go UP when some thresolds are hit. Think of these things as If-Then-Else statements in programming language. I am still reading about it but so far this is it. The only requirement is that I need to have my IOS versions to 12.4 minimum which is no obstacle for my 871s.

I also did have the time to tell management that this redundancy is almost impossible with one IP and that we needed at least 3 ( I also gave them the option that introducing a 3rd router will fix the issue but this in itself will introduce a single point of failure). So they understood and more than likely they'll purchase the 2 additional IPs, but I am just still working on this with one single IP because of stubbornness.

I also need to put a second or third host on the inside to test this mac-faking patch further. And if it works (again, it works so far as expected with one Host), then the mac-address faking work-around would have done the trick with the only exception of telneting to the outside interfaces of the routers.

Btw, I did try HSRP on the inside, at least in theory as I whiteboarded it with my cisco colleagues and was a no go mainly because the outside interface of the stand-by router will be up and will update the CAM table on the switch.

With this said, and although I liked the paragraph you got from the book, I still think that the routers, because they have the same mac-addresses, will at "some" point, respond to the request in a perhaps "ramdom" order. My logic again is that if the CAM table of the ISP switch has mac-address xxx pointing to fa0/5, it will of course send the packet request towards this port, however, and once again as I had stated before, what if router-1 (which is connected to fa0/5) is very busy at the time the ISP switch placed the request, then I think (this I still need to dig on the books) the next thing it will happen is that the switch will "broadcast" it to all its ports and this is when router-2, who is connected on port fa0/8, will more than likely grab it.

What do you think?

I was thinking somewhat along the same lines. The switchport to the secondary router could be disabled normally. Something could be set up so that when the primary router goes down the switchport connecting the secondary is enabled. If you don't have control over the switch perhaps EEM will work. The concern I have is that it may still require layer 3 communication between the two 871s. If you could move control to the switch you'd be managing the common element to both routers.

The CAM description was from CCO. The information from the book relates to the MAC spoofing and continuous CAM table updates. There was pretty much the same exact scenario as what you have set up. From a security standpoint, a similar configuration could escalate into a DoS attack against the switch.

With respect to the CAM table updates, what I think happens is that the switch updates the MAC entries based on traffic coming into the switch via the port associated with the MAC address. If the switch receives a frame with the destination of an unknown MAC it will broadcast that frame through all its ports except the one that sent the frame. Once it gets a response it will update its CAM table with the port through which it received the response.

In this case, Router-1 sends a frame to the switch. The switch creates an entry in its CAM table, associating the source MAC address with the port of Router-1.

The switch receives another frame through the port associated with Router-2 that has the same source MAC address. It updates its CAM table with the new port.

This change flips back and forth between the two ports, which I think is the cause of your lost connectivity to your telnet session.

Thanks for the rating! This type of dialog is what NetPro is all about.

Just FYI, here's a nice basic description of how switches work. HTH

http://www.cisco.com/en/US/tech/tk389/tk689/technologies_tech_note09186a00800a7af3.shtml

hi slmansfield,

i was revisiting this thread as this case came up but just as a memory between the customer who I did this for. alhough I never got to deploy eem, they were really impressed with the work-around of the mac-address faking. so that is why i remembered you and wanted to thank you for the insights... your input was just great.. thank you very much.

question though, have you deployed eem? if so, what do you think about it?