In Part 1, I touched on some of the deciding factors organizations use to identify MPLS technology as a move toward the future, as well as some common configurations. As your network begins to change and requirements continue to drive complexity, it is important to understand whether or not the technology you purchased and the provider that manages it for you can adapt to new environments. In this article, I outline the typical MPLS site and explain more about common features that can be deployed in various environments.
Site types
Several factors drive site classification within an organization. MPLS can be used in both MAN and enterprise environments, but the focus here will be on remote sites that must use the WAN for communication to a central location. Some factors include:
- Number of users
- Importance of users (the bosses)
- Local applications (databases, voice, etc.)
- Central site dependability
Some businesses use one or all of those factors to help determine purchasing requirements for things such as hardware and bandwidth. Putting all of these together, a well-planned IT organization should create a blueprint for typical sites. Generally, this means small, medium and large. When examining these from an MPLS perspective, requirement blueprints for small, medium and large sites could be modified as follows:
- Large: Redundant customer edge (CE) routers with dual connectivity to the MPLS backbone. 2 CE routers
- Medium: A large site with smaller bandwidth, or singly attached MPLS circuits and a backup. (IPsec VPN, ATM, frame) 1 or 2 CE routers
- Small: Singly attached MPLS connection. 1 CE router
The features
Once a site has been deemed a "large" site, all of those questions for providers we asked in my previous article now come into play to help us evaluate and design or redesign the network. Common questions include:
- Do you support BGP communities? If so, which ones -- and what do you do with them?
- Is there a deterministic method of route selection on your backbone?
- Do you support Inbound Load Balancing with BGP?
Knowing how these features work is really the first step in designing your site to accept a new MPLS circuit. Take the first question: "Do you support BGP communities?" Why is this important? BGP communities allow networks the ability to provide end-to-end decision-making support without having to deploy overly complex networks. Certain providers can act on BGP communities as an included service. A community, 100:1, if advertised via BGP to the provider router, might tell the router to increase the local preference value, for example. This would, in turn, affect inbound traffic to that site. If providers simply allow for community values to pass through their network, other remote sites may be able to develop similar routing policies without having to create individual and complex filters and lists.
The topology
A common practice with large sites that use BGP for CE-to-provider edge (PE) communication is route redistribution from BGP into the IGP at the CE. Generally, filters are used to minimize the number of prefixes. At this point, the next step is to extend the features of BGP and the provider to the LAN infrastructure. That includes a physically redundant topology (e.g., crisscross). The figure illustrates a typical large site topology:
Figure 1 - Large site topology
Although feature sets and topology drive the architecture of the large site, it remains important to think about other factors when designing for these features.
- Knowledge gap
It is very beneficial to take advantage of embedded features in already used protocols and technologies, but consideration must be given to the expertise of the operations engineers for support.
- Hardware/software upgrades
Feature sets sometimes come at a high price in terms of preparation. Money is a big driver, but don't forget the possible downtime and performance hits you may take to "upgrade in preparation for the upgrade."
In the next tip, I will outline the other typical site types and talk about some good backup possibilities for the new MPLS connection.
About the author:
Doug Downer (CCIE #9848 and JNCIS #881) is a senior consultant with Callisma Inc., a wholly owned subsidiary of SBC Communications. Doug has more than seven years of experience in the industry and currently provides high-level business and technology consulting for various federal clients in the Washington, D.C., area.
