Configuring redundancy using floating static

Question

I wanted to post my network layout, but I dont have the required reputation. So I have made up a network diagram below:

       ISP
       / \
      /   \
     /     \
    HQ------Branch
    |         |
  HQ-PC      B-PC

What I am trying to do is to use the WAN Link between HQ and Branch as the back-up link and it must not carry any data unless the link between HQ to ISP or Branch to ISP is down. Meaning it must strictly be only used as a back-up link.

What I have done is using floating static to configure the redundancy. However, it is not quite working out as what I have expected it to be. What I have done are:

1) a default route at the HQ and Branch to the ISP (0.0.0.0 0.0.0.0 NEXT-HOP-IP)

2) static route at ISP to HQ and Branch (HQ/BRANCH-NETWORK-ADDRESS SUBNET-MASK NEXT-HOP-IP)

3) a static(prefered) route at HQ (BRANCH-NETWORK-ADDRESS SUBNET-MASK NEXT-HOP-IP-TO-ISP)

4) a static(prefered) route at Branch (HQ-NETWORK-ADDRESS SUBNET-MASK NEXT-HOP-IP-TO-ISP)

5) a floating static(back-up) route at HQ (BRANCH-NETWORK-ADDRESS SUBNET-MASK NEXT-HOP-IP-TO-HQ-THROUGH-BACKUP-LINK)

6) a floating static(back-up) route at Branch (HQ-NETWORK-ADDRESS SUBNET-MASK NEXT-HOP-IP-TO-BRANCH-THROUGH-BACKUP-LINK)

However, there is a problem. For example, if the link between ISP and HQ is down, when I want to ping from HQ-PC to B-PC, the packet will be successfully sent from HQ-PC to B-PC, but the returning packet from B-PC will be sent to the ISP and not through the back-up link.

So sorry for such a lengthy post, but is there anyone who can help me? If my explanation is unclear, please feel free to query. Thanks in advance

EDIT: Sorry for the confusion, there should not be any routing protocols running with the ISP

Are you doing BGP to the ISP? if so, this gets easier, if not, well... there are ways but it won't be as fun. — Olipro, Jun 30 '13 at 10:55
The requirement is that they do not want to run any routing protocols with the ISP — bob, Jun 30 '13 at 11:08
@bob, please tell me your company is encrypting the inter-office traffic they are sending over the internet — Mike Pennington, Jun 30 '13 at 11:38
Did any answer help you? if so, you should accept the answer so that the question doesn't keep popping up forever, looking for an answer. Alternatively, you could post and accept your own answer. — Ron Maupin, Jan 03 '21 at 21:51

Mike Pennington · Answer 1 · 2013-06-30T11:48:36.413

As you mentioned, your static routes break, because there is no existing way to force failover to the WAN link at both sites when one site looses the uplink to the internet.

The best solution to this problem is to set up some form of routed tunnel (sourced from the ISP-link addresses on R1 and R2 in the diagram) through the internet, run a dynamic routing protocol (OSPF / EIGRP) through your tunnel and backup WAN, and set the routing metrics for the WAN link to be much higher.

HQ-Backup tunnel

Since you source the tunnel from the internet links on both sides, if either side looses internet connectivity the tunnel breaks (and the IGP recoverges to your WAN link). If you do this, be sure that PMTUD works through the tunnel so the tunnel overhead is accounted for. This kind of inter-office encrypted VPN is quite common, so it's a familiar topology for anyone who has to support this network in the future.

The issue you face with your existing design is that all your inter-office traffic traffic seems to be unencrypted (at least if I read your question at face-value). If you are not already doing so, I would strongly recommend that you encrypt all traffic between your corporate sites, if it's going through the internet.

@bob, what model of networking equipment do you have at each site? if cisco eqpt, please include what ios feature set you have — Mike Pennington, Jun 30 '13 at 14:31

ytti · Answer 2 · 2013-07-01T06:26:08.447

5

(Original all-BGP answer changed, as-per OP's request of no dynamic routing to ISP)

As @Mike suggested, tunnel+dynamic routing, especially in the INET facing is solid solution. But if for some reason you don't want tunnel (no HW support, don't want to lose MTU, dynamic routing not acceptable even internally) your other option is 'IP SLA' tracked routes.

I'll explain how it helps in the exact problem you describe, where branch continues to return traffic to INET, while it should use the direct link.

In branch you'd have:

ip route HQNet HQMask InetIF InetNH track 1 50
ip route HQNet HQMask DirectIF DirectNH 100
ip route HQStableTestIP 255.255.255.255 InetIF InetNH
!
track 1 ip sla 1
!
ip sla 1
 icmp-echo <HQStableTestIP> source-interface InetIF
ip sla schedule 1 start-time now

Now if HQ is not reachable via INET, tracking should fail, and INET more-specific route should be invalidated and you should fallback to next best route pointing to the direct link.

edited Jul 01 '13 at 06:26

answered Jun 30 '13 at 11:07

ytti

9,776
42
53

really sorry for the trouble, it was my mistake for not stating that there shouldnt be any routing protocols running with the isp :( – bob Jun 30 '13 at 11:18
Then best you can do is to use 'IP SLA' to track the static routes. To be robust against tracking related issues you'd need three routes 1) pointing to primary, tracked 2) pointing to secondary tracked 3) pointing to primary, untracked (3rd is needed so if all tracking fails, you'll still attempt to use the primary connection, instead of giving up). Other questions in this site have IP SLA examples. – ytti Jun 30 '13 at 11:36
Original answer changed to reflect the new requirement – ytti Jul 01 '13 at 06:26
1

The OP really needs to encrypt his traffic through the internet... after reviewing the question several times, I am increasingly convinced that he currently is sending his internal traffic as clear-text. – Mike Pennington Jul 01 '13 at 09:13
Need for encryption is debatable. Less than 1% of our clients encrypt site-to-site traffic traveling over our network. It's L3MPLS VPN but it's really no easier/harder to sniff than pure INET. Most are just concerned what PCI requires them to do, and do that, not more. Some might argue virtually no companies have any secret worth giving that you can't buy with a pint in a bar. And history has shown that worst information leakage to a company has 0 effect on their stock price. (Protecting from disaster should cost less than damage from disaster). – ytti Jul 01 '13 at 09:15
If you need to encrypt, make sure it works, if you trust every key, you don't have security. I'm saddened that you find this pedantic, it's clearly my failure in explaining ssh security model. Maybe ask in openssh mailing list, someone there is better than I am at explaining why security model is completely lost if key is not verified. The diagram OP has shows they connect to single ISP twice, for our network this would have 100% same security has MPLS-VPN, as they'd run 100% in same infrastructure. I'm certainly not saying 'dont encrypt', I'm saying not everyone must. – ytti Jul 01 '13 at 09:35
1

The obligatory drama around pedantry is noted. Trusting every key on scripts is an acceptable solution as long as other people manually ssh to the same devices with key-checking enabled... when you spend your life automating CLI sessions there are certain choices you would never make as a human to keep your work from spiraling into ratholes of low-probability solutions. The OP's diagram may or may not reflect homing to the same ISP... that could simply be an artifact of not wanting to complicate an ascii-art diagram with what he considers unnecessary details – Mike Pennington Jul 01 '13 at 09:43

Configuring redundancy using floating static

2 Answers2