I agree - it would be really odd to see an F5 and a Netscaler paired in an HA configuration in our experience and to do so would seem like a recipe for disaster. By network device we mean core and border routers, distribution and access switches, etc - the explanation is laid out much more clearly within the rule. The lowest rate of network failures and total calculated contribution to non-availability within our companies happened when the non-load balancing and non-fire-walling network devices were homogeneous. The companies we examined are mostly "hyper growth" and pushing the limits of scale with their size and speed of growth. It's entirely possible that if a company is in a low to no-growth situation such problems would never happen. After all, if one pushes the same level and type of traffic everyday it seems likely that the probability of a new problem happening without some other change is low. Speaking of Firewalls - we address them in an entirely different rule:)
Hi folks - I'm one of the authors. All good answers in here and all correct. One throat to choke is a great response with which we agree. The point in our book though is along the lines of the "it should work, but it doesn't" statement already given. Most vendors implement proprietary protocols that they claim to be consistent with RFCs 792, 1058, 4271, 5340 (ICMP, RIP, BGP, OSPF for IPV6) and others . These RFCs are loose enough to allow for differences in implementation. This in turn can cause a bit of a "stacked dependency" problem where 2 or more providers' gear works correctly IAW the RFCs, but not always with each other. Based on our analysis of many companies (n>200) and our personal experiences at both large and small companies the best solution is just to stick with one provider. Specifically, we often see device communication errors between providers as one of the top 5 reasons for down times across our client companies where they have heterogeneous networks. The most common fix is to replace with homogeneity - take your pick of provider.
The problem is exacerbated in that device providers don't test each other's equipment communication as well as they check their own. So more problems are bound to occur. It's really not that much different than the browser problem where your site may work with 3 browsers but get jacked up with another 2.
If you haven't had problems, it may not be worth fixing. If you are designing from scratch, our view is that it's best to stay homogeneous. Thanks for the review and the perspective!
Slashdot Mirror
I agree - it would be really odd to see an F5 and a Netscaler paired in an HA configuration in our experience and to do so would seem like a recipe for disaster. By network device we mean core and border routers, distribution and access switches, etc - the explanation is laid out much more clearly within the rule. The lowest rate of network failures and total calculated contribution to non-availability within our companies happened when the non-load balancing and non-fire-walling network devices were homogeneous. The companies we examined are mostly "hyper growth" and pushing the limits of scale with their size and speed of growth. It's entirely possible that if a company is in a low to no-growth situation such problems would never happen. After all, if one pushes the same level and type of traffic everyday it seems likely that the probability of a new problem happening without some other change is low. Speaking of Firewalls - we address them in an entirely different rule :)
Good point Gr8Apes - we point out in the book that we typically exclude Firewalls from the homogeneity rule.
Hi folks - I'm one of the authors. All good answers in here and all correct. One throat to choke is a great response with which we agree. The point in our book though is along the lines of the "it should work, but it doesn't" statement already given. Most vendors implement proprietary protocols that they claim to be consistent with RFCs 792, 1058, 4271, 5340 (ICMP, RIP, BGP, OSPF for IPV6) and others . These RFCs are loose enough to allow for differences in implementation. This in turn can cause a bit of a "stacked dependency" problem where 2 or more providers' gear works correctly IAW the RFCs, but not always with each other. Based on our analysis of many companies (n>200) and our personal experiences at both large and small companies the best solution is just to stick with one provider. Specifically, we often see device communication errors between providers as one of the top 5 reasons for down times across our client companies where they have heterogeneous networks. The most common fix is to replace with homogeneity - take your pick of provider. The problem is exacerbated in that device providers don't test each other's equipment communication as well as they check their own. So more problems are bound to occur. It's really not that much different than the browser problem where your site may work with 3 browsers but get jacked up with another 2. If you haven't had problems, it may not be worth fixing. If you are designing from scratch, our view is that it's best to stay homogeneous. Thanks for the review and the perspective!