This week's tip is going to focus on the concept of routing policy in an enterprise network. This doesn't necessarily mean routing policies, which may or may not be used, but rather the effect of having an overarching routing architecture to support a tiered approach to your network.
How it helps to define the hierarchy
I'm sure everyone who is reading this has heard of or read about the tiered approach to networking as it applies to the core, distribution and access layers. What's really important about this concept of these "layers" is not how nice your network looks on a diagram, but the actual roles and functions of the devices within these layers. Functions such as policy routing (again, not routing policy), quality of service (QoS) and Access Control (ACLs) are examples of what makes a device fit into these different layers within a network.
Unlike the provider space, an enterprise network does not always have a clear demarcation, from a routing perspective, between a core and access device. This point assumes that routing is being performed from core to edge, which may or may not be the case in your environment but serves as the focal point for this article. Implementing strategies for things like protocol re-distribution, route-filtering and default-routing help lay the framework necessary for a routing architecture. Each of these types of functions, when applied to a device can create your hierarchy. An example could be if you defined an access routing device as one which can accept only a default route from its distribution neighbor and nothing else, then each subset of devices having this characteristic would by definition also be access devices.
The mixing bowl
One sometimes overlooked idea surrounding the enterprise routing environment is the idea that enterprise inherently means that the routing domain is contained and doesn't cross any administrative boundaries like it would in say the service provider networks. This of course is not entirely accurate. Take a large company for example, say Cisco – chances are that the company itself is not a single entity, but rather a bunch of smaller companies thrown together to create a bigger and more powerful organization. What happens when you take a network which has its own hierarchy and routing schemes and policies and merge it with another that has a completely separate and different routing model?
The answer of course depends on how you've defined your device functions and created your templates around your routing hierarchy and applied them to your layered model. Inevitably what this creates is a tiered model, repeated over and over again from network to network – the mixing bowl effect. This common event is specifically why you must plan and define ahead of time, a routing policy that can scale to meet the requirements of a growing enterprise network. One company's access device is another's core!
Ok so now you know that it's important to have a routing policy in your enterprise. But how do you go about doing it? There are protocols out there that can help, just by turning them on, create the layered model for you. In the next article I'll take you through some examples of implementations which may be useful in your quest to redefine your network.
Doug Downer (CCIE #9848) is a Sr. Consultant with Callisma, INC, a wholly owned subsidiary of SBC Communications. Doug has over 7 years in the industry and currently provides high level business and technology consulting for various federal clients in the Washington D.C. area. He can be reached at ddowner@callisma.com.
