Definitive MPLS Network Designs [Electronic resources] نسخه متنی

Routing and Backbone Label-Forwarding Design

The backbone of the TK domestic network supports MPLS label switching of all Unicast traffic. The labels are assigned and distributed using Label Distribution Protocol (LDP) and RSVP-TE (Resource Reservation Protocol Traffic Engineering). TK chose not to deploy any LDP filters (unlike USCom in the previous chapter). Therefore, both Internet and Layer 3 MPLS VPN traffic is label-switched.

Because all Unicast traffic is label-switched, and because TK does not provide a native IP Multicast service, the IPv4 BGP address family is not required to be deployed on the P routers in the MPC. This facility allows TK to run an Internet-free core network, although MP-BGP is still required to distribute the VPNv4 routes created by the Layer 3 MPLS VPN service.

mVPN Service Application," that TK provides Multicast services to its Layer 3 MPLS VPN customers only. This is an additional service provided within the customer's VRF. It uses the mVPN technology that was reviewed in the "Multicast VPNs" section of Chapter 1, "Technology Primer: Layer 3 VPN, Multicast VPNs, IPv6 and Pseudowire."

When using this technology, as each Multicast packet is encapsulated using [GRE] with a source address of the ingress mPE router, the RPF checks performed on Multicast packets are always an mPE router loopback interface address rather than the original source address within the customer VPN. Because these mPE router loopback addresses are distributed by the IGP, no additional functionality is necessary to successfully perform the RPF checks.

On the other hand, if TK supported a global IP Multicast service, RPF vector functionality would be necessary (as you will see in Chapter 5, "Global Service Provider Design Study"). This functionality allows an RPF check to be performed on a route's BGP next hop rather than that route's originator.

Removing the BGP IPv4 address family from the core of the domestic network had several implications that needed to be addressed:

Service provisioning Many of the existing scripts that were currently used to provision the edge and core routers needed to be changed to remove any redundant BGP configuration such as IPv4 address family sessions at the P routers.

Fault detection A failure in the packet forwarding path needed to be detected and subsequently repaired. Unlabeled IP packets could no longer be forwarded within the core because of the removal of IPv4 routes from the P routers.

Security The tools used to identify attack threats, such as IP Source Tracker, no longer work within the network's core because the P routers forward only MPLS packets, not IP packets.

Troubleshooting The Network Operations staff needed to understand how to troubleshoot an MPLS core network as opposed to a pure IP environment.

However, an Internet-free core also has a number of advantages:

The amount of routing state stored locally on P routers is greatly reduced, thus decreasing the memory and processor usage.

The BGP IPv4 address family peering mesh can be substantially reduced because only the edge routers need to carry IPv4 BGP routes.

Stability of the core network is likely to be enhanced because it is no longer aware of external routes. For example, an external route flap can no longer affect a P router because this router does not carry external routes.

Market perception of increased security of an Internet-free private core can be taken advantage of even though it is possible to secure the core network without removing the IPv4 address family.

TK believed the benefits of an Internet-free core outweighed the migration's complications and addressed the implications pointed out previously in the following way: As part of the migration, all the existing provisioning scripts were modified to correctly configure both the edge mPE routers and the core P routers. Most of this exercise involved removing the BGP configuration on the P routers rather than additional commands and reconfiguring the mPE routers to peer with IPv4 address family route reflectors (RRs) located in the Level 1 POPs.

Clearly denial of service (DoS) attacks are a concern for any network operator. Before migrating the core network to MPLS switching, TK used the IP Source Tracker tool to identify the source of any suspected DoS attacks. When a specific destination was suspected of being under attack, TK enabled IP Source Tracker on its routers so that each line card could create a Forwarding Information Base (FIB) entry for the destination address and collect information about traffic flow to the tracked destination. This data was then observed periodically to identify the source of the attack.

With its transition to an Internet-free core, TK was forced to push this functionality to the mPE routers because these were the only devices in the network that used the FIB to forward IP packets (IP Source Tracker works in conjunction with the FIB). All MPLS packets are forwarded using the Label Forwarding Information Base (LFIB) rather than the FIB and therefore are not subject to tracking with the currently available IP Source Tracker feature.

When a DoS attack is suspected, either within a VPN or via the global Internet, TK enables IP Source Tracker on the egress mPE router through which the attack is suspected. Then TK examines the output to determine the source IP address of the attack. The company then can identify the ingress mPE router by examining the identified source address within the BGP table at the egress mPE router. Note that without MPLS forwarding in the core network, the mPE router has no way of identifying the entry point for the attack. Its next hop for the source may not actually be the router through which the packet entered the network.

With respect to forwarding fault detection and troubleshooting, LSP liveliness is determined through the use of LSP-ping (see [LSP-PING]). This functionality allows pings to be initiated using the Cisco Service Assurance Agent (SAA) to test that a particular LSP is functioning correctly. If a failure is detected, TK uses LSP Traceroute (also documented in [LSP-PING]) to identify the point of failure within the network and then takes corrective action. The SAA and LSP-ping functionality are initiated from the mPE routers.

In terms of control plane fault detection for LDP and MPLS Traffic Engineering, in case a traffic Engineering LSP or LDP LSP fails, TK uses the regular set of troubleshooting features available on the P routers. This allows for extensive detail on the TE/LDP LSP's operational state (CLI show and debug commands, SNMP traps related to TE/LDP, and IGP TE extensions).

IGP-LDP synchronization functionality (enabled using the global mpls ldp sync command) is also deployed. This allows the IGP to stay synchronized with the LDP protocol so that packets are not forwarded across a given link until both the IGP and LDP protocols have converged. Lack of coordination between the IGP and LDP may result in packet loss in two situations:

On link-up when the IGP adjacency starts, the router may begin forwarding traffic on the link before LDP label exchange between the link peers has finished. This causes traffic loss of the label-switched packets because no LSP is yet available along the preferred path (determined by the IGP).

If an LDP session is lost but the IGP adjacency is not, the router may continue forwarding traffic using the link associated with the LDP session in preference to alternative paths with fully synchronized LDP sessions. That would lead to the same undesirable effect as just mentioned.

Packet loss in these situations may be reduced by means of synchronizing the LDP protocol with the IGP. On a link-up event, if an LDP session is already operational, the IGP brings up an adjacency as normal. However, if an LDP session is not operational, the following occur:

If the LDP neighbor can be reached, the IGP delays sending hellos until either the LDP session is operational or a hold-down timer expires.

If the LDP neighbor cannot be reached, the IGP starts sending hellos.

When the IGP adjacency is up, and before the LDP session is fully operational, the router initially announces reachability to the link using IGP's maximum metric. This prevents any traffic from being forwarded along the corresponding link.

When the LDP session is successfully established, the router announces the link using the normal configured metric for the link, allowing traffic to use the link.

If at some point in the future the LDP session subsequently fails after the IGP advertises the configured link metric, the following actions occur:

The IGP again starts advertising its maximum metric for the link.

When the LDP session returns, the IGP resumes advertising the configured link metric.

Shared-Edge Internet and Layer 3 MPLS VPN Services

As mentioned, the edge of the TK domestic network consists of mPE routers that provide a variety of services, including Internet and Layer 3 MPLS VPN. The MPC's P routers are shared for transport of all services.

The implication of running shared services on the same edge routers was evaluated for the design. Clearly security of the P network and edge was of paramount importance, as was network scaling. The Chapter 5 section "Layer 3 MPLS VPN Security and Scalability" provides details of how these challenges can be met and overcome, so these design aspects are not covered in this chapter.

Internet Service: Route Reflection Deployment

A further positive implication of removing the BGP IPv4 address family from the P routers is that the Internet RRs may follow a design similar to the VPNv4 route reflection. This is because packets are no longer IP-forwarded in the core and need not follow the network's physical topology (as explained in the previous chapter). Hence, TK chose to deploy RRs for its Internet service using a centralized model but kept the IPv4 RRs separate from those used for VPNv4 routes. The main reason for separation was control-plane convergence; TK did not want contention between the two services during a failure.

As shown in Figure 4-6, each Level 1 POP has two RRs serving the IPv4 address family. Each mPE router within a Level 2 POP peers with the two RRs closest to it. Each mPE router within a Level 1 POP peers with the local RRs.