Migration of the Backbone to a Frame-mode MPLS Solution
We will consider within this chapter a theoretical service provider backbone network?let's call it TransitNet?that currently provides Internet transit to several large customers. This Internet access is obtained through two separate external BGP peering points to upstream service providers. For the first part of the case study, we will consider a backbone made up purely of routers, without any ATM switch involvement. This router-based topology can be seen in Figure 6-1.
Although Figure 6-1 does not show all the physical network structure (this is not necessary within the scope of this discussion), it does provide an illustration of the BGP structure of the TransitNet backbone network.
Figure 6-1. TransitNet Backbone Network Topology
Each regional POP within the backbone has a requirement to carry BGP information that has been learned from the two external peering points located in the London and Portsmouth POPs. Furthermore, all TransitNet customer routes are carried within BGP, so there is also a requirement to run BGP in each POP so that customer routes can be propagated across the backbone network and be advertised to external BGP peers.
All external and customer routing information must be advertised throughout the topology so that all transit routers are capable of successfully routing traffic. Because of this requirement, a complex BGP structure that includes route reflection both within the POPs and also within the core of the network is necessary. Figure 6-1 shows each of the necessary iBGP sessions for one of the TransitNet POPs and highlights the complex hierarchical route reflection topology. This topology includes reflection within the POP from access-layer routers to the distribution-layer routers. Each distribution-layer router is a route reflector for clients within the POP (access-layer router) and is itself a client of the core route reflectors. Each core route reflector is fully meshed with every other core route reflector, and its role is to reflect routes from one POP to all other core routers and POPs.
Note
We will discuss route reflection and BGP design considerations further in Chapter 12, "Advanced MPLS/VPN Topics." If you need in-depth details of the Border Gateway Protocol, its functional elements such as route reflectors, or usage guidelines for BGP deployment on the Internet, turn to Internet Routing Architectures, Second Edition, by Bassam Halabi (Cisco Press).
The TransitNet service provider has decided to migrate its backbone toward an MPLS-based infrastructure because it does not want to carry external BGP information within the core of its network. The service provider also wants to remove the complexity of the routing protocol structure, which requires multiple BGP peering sessions and the deployment of multiple BGP route reflectors. In addition, the service provider wants to provide more advanced services, such as virtual private networks, to its customers at a later date, as well as the capability to distribute this traffic across its backbone using traffic engineering.
We have already seen that one of the consequences of a migration to the MPLS architecture is the capability to remove the requirement to carry BGP information within the core of the network. This was fully discussed in Chapter 2, "Frame-mode MPLS Operation." This is not always an obvious reason to migrate to an MPLS topology, but it certainly has major advantages and fits in very well with the objectives of the TransitNet service provider.
