MPLS Interaction with the Border Gateway Protocol
In the section "Label Binding and Distribution," earlier in this chapter, you saw that a label is assigned to every IP prefix in the IP routing table of a router acting as LSR, the only exception being routes learned through the Border Gateway Protocol (BGP). No labels are assigned to these routes and the ingress Edge-LSR uses the label assigned to the BGP next hop to label the packets forwarded toward BGP destinations.
To illustrate this phenomenon, assume that the MAE-East router in the SuperNet network receives a route for network 192.168.3.0 from a router in Autonomous System 4635. The route is propagated throughout the SuperNet network with the MAE-East router from AS4635 being the BGP next-hop. When looking in the BGP table on the San Jose router and in the corresponding FIB table entries, you can see that the same label (28) is used to label the packets for the BGP destination and for the BGP next-hop (see Example 2-21).
Example 2-21 BGP and FIB Entries on the San Jose Router
SanJose#show ip bgp 192.168.3.0 BGP routing table entry for 192.168.3.0/24, version 2 Paths: (1 available, best #1, table Default-IP-Routing-Table) 4635 192.168.100.2 (metric 21) from 172.16.4.1 (172.16.4.1) Origin IGP, metric 0, localpref 100, valid, internal, best SanJose#show ip cef 192.168.3.0 192.168.3.0/24, version 52, cached adjacency 172.16.1.4 0 packets, 0 bytes tag information from 172.16.1.4/32, shared local tag: 39 fast tag rewrite with Se1/0/1, 172.16.1.4, tags imposed: {28} via 192.168.100.2, 0 dependencies, recursive next hop 172.16.1.4, Serial1/0/1 via 172.16.1.4/32 valid cached adjacency tag rewrite with Se1/0/1, 172.16.1.4, tags imposed: {28} SanJose#show ip cef 192.168.100.2 192.168.100.2/32, version 26, cached adjacency 172.16.1.4 0 packets, 0 bytes tag information set, shared local tag: 39 fast tag rewrite with Se1/0/1, 172.16.1.4, tags imposed: {28} via 192.168.100.2, 0 dependencies, recursive next hop 172.16.1.4, Serial1/0/1 via 172.16.1.4/32 valid cached adjacency tag rewrite with Se1/0/1, 172.16.1.4, tags imposed: {28}
The interaction between MPLS, IGP, and BGP gives a network designer a completely new approach to network design. Traditionally, BGP had to be run on every router in the core of a service provider network to enable proper packet forwarding. For example, BGP information from MAE-East had to be propagated to every core router in the SuperNet network (Washington, Denver, and San Francisco). If that were not the case, the core routers could not route the packets toward the BGP destination, as illustrated in Figure 2-10.
Figure 2-10. Connectivity Loss in Network with No BGP on Core Routers
If, however, the SuperNet network runs MPLS, the San Jose router propagates the packet toward a BGP destination as a labeled packet with the label associated with the BGP next hop. Because the BGP next-hop should always be announced in the IGP the network is running, all intermediate routers must have an incoming-to-outgoing label mapping for that destination in their LFIB already and must propagate the labeled packet toward the egress LSR (MAE-East) but need not run BGP. Figure 2-11 displays the whole process.
Figure 2-11. Packet Propagation Toward BGP Destination in MPLS-enabled Network
The removal of the BGP process from the core routers in a service provider network has a number of benefits:
The routing tables in the core routers become much more stable because the core routers do not process route flaps in the Internet.
Memory requirements for the core routers are reduced because they do not have to store the Internet routes (around 70,000 to 80,000 routes, consuming between 20 to 40 MB of memory in the router).
The route processor CPU utilization on the core routers is reduced greatly because they do not have to process BGP updates.
MPLS deployment, even in a pure router-based service provider IP backbone, is therefore highly recommended. Chapter 13, "Guidelines for the Deployment of MPLS/VPN," looks further at the removal of BGP within the core of a service provider network and the advantages this brings, especially in a VPN environment.
