Re: How to achieve application reliability
On Sat, 04 December 1999, James Smith wrote:
Our only alternative is to eliminate every single-point failure with stuff like high availability clustering, redundant feeds, battery backups, nuclear reactors, physical separate sites on different planets, etc. :-) (Pardon me, it's 2:00am and I'm getting punching)
If you are using Microsoft products in your nuclear reactor, its not going to be very reliable. They aren't designed for that purpose. The tools exist to make very reliable network applications, but we can't force people to use them. So long as applications neglect to use the other information provided by the network, they are going to be vulnerable to single points of failure. Multiple A records exist for a reason. Even if you have high availability clustering, redundant feeds, battery backups, multi-homing, multi-sites; if you are depending on a single global network announcement there is nothing to prevent another ISP from announcing the same prefix with a shorter AS path length, and effectively blackholing your network. For people with ultra-high reliablility requirements, a /19 isn't the solution.
Sean, First, Unix is the only way to go. :) Second, what do you suggest instead of a /19? -- James Smith, CCNA Network/System Administrator DXSTORM.COM http://www.dxstorm.com/ DXSTORM Inc. 2140 Winston Park Drive, Suite 203 Oakville, ON, CA L6H 5V5 Tel: 905-829-3389 (email preferred) Fax: 905-829-5692 1-877-DXSTORM (1-877-397-8676) On 5 Dec 1999, Sean Donelan wrote:
On Sat, 04 December 1999, James Smith wrote:
Our only alternative is to eliminate every single-point failure with stuff like high availability clustering, redundant feeds, battery backups, nuclear reactors, physical separate sites on different planets, etc. :-) (Pardon me, it's 2:00am and I'm getting punching)
If you are using Microsoft products in your nuclear reactor, its not going to be very reliable. They aren't designed for that purpose.
The tools exist to make very reliable network applications, but we can't force people to use them. So long as applications neglect to use the other information provided by the network, they are going to be vulnerable to single points of failure.
Multiple A records exist for a reason. Even if you have high availability clustering, redundant feeds, battery backups, multi-homing, multi-sites; if you are depending on a single global network announcement there is nothing to prevent another ISP from announcing the same prefix with a shorter AS path length, and effectively blackholing your network. For people with ultra-high reliablility requirements, a /19 isn't the solution.
From: Sean Donelan, Sent: Sunday, December 05, 1999 8:37 AM
For people with ultra-high reliablility requirements, a /19 isn't the solution.
But, from the discussion, a /19 would be part of the requirement, along with some form of LBDNS, like Resonate. Yes, the Net can get blackholed, but isn't that an error condition anyway? One that must be fixed? Also, we haven't discussed the security implications much. Keeping the rest of this in mind, those of us using tcp_wrappers, SSH, and other IP-based filtering, would have our lives simplified greatly if we had a common IP block that covered the entire domain, regardless of which provider a host is located in. VPNs would also be much less expensive to maintain. Simpler security == tighter security. The issue is that there is no way that the cases I have before me should need more than a /24, even if /20 requirements can be met by host count. Most of the hosts would be in NAT'd space anyway, for security reasons I shouldn't need to go into here. In fact, I could architect both domains into a /25, or even a /26, if I had to, using NAT'd space (it would be a tight fit with no growth allowance). To review the cases, I have two instances where I have geographically separated sites that need a common IP-block, with multiple providers. I have an interim solution now, using an SSH VPN, but the maintenance is killing me. Not to mention the fact that I still haven't reduced the packet load on the primary site. On one of the sites, distribution of the packet load is ONE of many reasons for the geo-physical separation. Ergo, that dog doesn't scale here. In fact, it could DOUBLE traffic at the primary site and add encryption processing load as well. As an aside, IPSEC (as one person had suggested) would not be an improvement, wrt packet traffic, at the primary site (while the implementation is slightly different, the general effects are the same). The only apparent route left would be to burn /24s at each end, even though I don't need them. I got no problem with that, but I thought that the priority goal was conservation of IP space. BTW, I obviously have sympathy for a movement that would generate an RFC for CONSISTENT route filtering policies.
participants (3)
-
James Smith -
Roeland M.J. Meyer -
Sean Donelan