Welcome! To the enterprise architecture model, focusing on modular, resilient design.
Cisco’s Architectures for the Enterprise are a set of frameworks for the best practices for designing of complex networks that need to provide the business with the services it requires to obtain its objectives.
They outline 2 main forces behind network design decisions:
- Business forces
- Technology forces
The types of things that would be considered as business forces would be a return on investments objective. If the business just purchased a slew of new state of the art servers and storage but the network isn’t in a condition to fully utilize their potential, then the business will encounter a slower ROI. The need to increase that can be a driving force for network design decisions.
Your business may also be in a regulated industry, like the
financial or medical industries. These and many other industries and situations call for heavy regulations with how your business stores, transmits, and accesses data. This can be a very strong force when making design decisions and will often dictate heavily some pieces of your design.
The business may also be looking to enhance their competitiveness. This could be anything from supplying some new high bandwidth low latency application to its customers to gain an edge in the industry, to upgrades to allow faster product development.
As you can tell, business forces are driven by business goals; this differs slightly with technological forces that impact design decisions. These don’t have a clear business goal but are rather further demands of the technology in place which we as the designers must take into account when creating our design.
The technology forces that drive design decisions are:
- Removal of borders. With an increasingly mobile workforce; between people working when on the road, teleworkers, and the demand to have access to many corporate resources from many devices in many locations, this is an increasingly important design factor.
- Virtualization. This can be server virtualization or network virtualization. Perhaps you have the need to keep your financial data complete separate from any other data and need to use VRFs, that’s virtual routing and forwarding instances, to separate the routing tables. This would be an example of network device virtualization.
- Growth of applications. We all know developers like to make applications increasingly heavier. Adding another new feature every now and then. This may not be the only type of growth we’re talking about though. Perhaps you have a little used real-time transactional application that’s now gotten traction and is being used by 10x as many people. This type of growth may require some network redesign to allow the network infrastructure to adequately handle the traffic.
So, the Cisco Enterprise Architecture really feels like the
centerpiece of Cisco’s design recommendations. Don’t get me wrong, Cisco has hundreds, if not thousands of design whitepapers with best practices and in depth considerations for nearly every scenario that they’ve encountered across thousands of their clients. But the Enterprise Architecture is really the backbone for how an enterprise network should be structured.
The first thing I want you to notice here is that it’s extremely modular. There’s 4 main functional areas, each having several submodules. This is not only great for organization and ease of understanding, but it’s also excellent at controlling your fault domains, and scaling. Whoa whoa whoa, you say, but Ben, what’s a fault domain?
A fault domain is the portion of your network that would be
impacted by a failure. So each piece of the network has its own fault domain, which we try to minimize or eliminate. Say for example I have a single router connecting the WAN to a branch office. If that router goes down, that branch office is cut off from the rest of the campus, potentially unable to access line of business applications or make calls depending on their setup. This is a somewhat large fault domain, which is why we’d want to have 2 routers there in a redundant fashion running HSRP or VRRP to allow the impact of one of those routers failing to be minimized and therefore minimizing the fault domain.
This actually, while we’re on the subject, is really closely
related to fate sharing. So fate sharing is when multiple devices or pieces of the network are impacted by the same fault. Where this is most commonly referenced is in ISP or WAN connections, and also VPN connections but I’ll get to that in a moment. You may be all up on redundancy and insisting to your company that you absolutely need 2 internet connections because it costs the business over $80k/hr to be without internet, and so they go for it. Say you have ISP1 here and ISP2 here, great. You even go all out and get a fiber line as your backup because they want their backup to be just as fast as their primary. However, you may not have checked what path the ISPs take and turns out both of those fiber lines come in on the same utility pole. Next thing you know, construction’s going on and a backhoe *schwoop* takes out that pole and now you’re dead in the water with both of your lines down. So that would be an example of fate sharing.
As far as a VPN connection goes; this would be like if your
guy sets up 2 VPN tunnels to be ‘redundant’ right, but only has a single ISP. He says if one of them goes down then the other will work with a floating static route and all, but if that ISP goes down, then both of those tunnels go down. Also fate sharing. As a network designer it’s important to consider the whole scope of redundancy to ensure you actually have the amount of resiliency in your design as you think.
Right? So, 4 functional areas. Enterprise Campus, this is where your main building or group of buildings reside and typically where most of your staff reside as well. You’ve got your 3 layer campus infrastructure along with your on-prem server farm here.