Table of Contents

Configuring Tag Switching

This chapter describes Tag Switching, and highlights Tag Switching on the
Catalyst 8540 MSR/CSR. It includes the following topics:

About Tag Switching

Tag Switching is a high-performance method for forwarding packets (frames) through a network. It enables routers at the edge of a network to apply labels to packets (frames). Switches or routers in the network core switch packets according to the labels with minimal lookup overhead.

In contrast to Tag Switching, conventional Layer 3 IP routing is based on the exchange of network reachability information. As a packet traverses the network, each router extracts all the information relevant to forwarding from the Layer 3 header. This information is then used as an index for a routing table lookup to determine the packet's next hop. This is repeated at each router across a network. At each hop in the network, the optimal forwarding of a packet must again be determined. The information in IP packets, such as information on IP Precedence and Virtual Private Network membership, is usually not considered when forwarding packets. Thus, to get maximum forwarding performance, typically only the destination address is considered. However, because other fields could be relevant, a complex header analysis must be done at each router that the packet meets.

By including a label on each packet, Tag Switching integrates the performance and traffic management capabilities of Data Link Layer 2 with the scalability and flexibility of Network Layer 3 routing. Packets or cells are assigned short, fixed length labels. Switching entities perform table lookups based on these simple labels to determine where data should be forwarded.

The label summarizes the following essential information about routing the packet:

With Tag Switching, a complete analysis of the Layer 3 header is performed only once at the edge label switch router (LSR), which is located at each network edge. At this location, the Layer 3 header is mapped into a fixed length label.

At each switch or router across the network, only the label need be examined in the incoming cell or packet in order to send the cell or packet on its way across the network. At the other end of the network, an edge LSR swaps out the label for the appropriate header data linked to that label.

A key result of this arrangement is that forwarding decisions based on some or all of these different sources of information are achieved by means of a single table lookup from a fixed-length label. For this reason, label switching makes it feasible for switches and routers to make forwarding decisions based upon multiple destination addresses.

Tag Switching Terminology

The following table lists the Tag Switching terminology used in this chapter:

Tag Switching Network Structure

A typical structure for Tag Switching networks is shown in Figure 13-1. The following elements are basic in a label switching network:

LERs are located at the boundaries of a network, performing value-added network layer services and applying labels to packets.

LSRs switch labeled packets or cells based on the labels. Label switches also support full
Layer 3 routing or Layer 2 switching in addition to label switching.

LDP is used in conjunction with standard network layer routing protocols to distribute label information between devices in a label switched network.

A Tag Switching network consists of LERs around a core of LSRs. Customer sites are connected to the provider Tag Switching network. Typically there are several hundred customer sites per LER. The Customer Premises Equipment (CPE) runs ordinary IP forwarding but usually does not run Tag Switching. If the CPE does run Tag Switching, it uses it independently of the provider. It is important to note that the LERs are part of the provider network and are controlled by the provider. The LERs are critical to network operation and are not intended to be CPE under any circumstances.

Figure 13-1 shows a typical network structure.

Tag Switching Operation on the Catalyst 8540 MSR/CSR

This section covers the Tag Switching implementation on the enhanced Gigabit Ethernet interfaces and the Packet over SONET interfaces on the Catalyst 8540 MSR/CSR Tag Switching forwarding operation.

The Catalyst 8540 MSR/CSR enabled with Tag Switching, uses the Forwarding information base (FIB) and Tag forwarding information base (TFIB) or Label forwarding information base (LFIB) to perform packet forwarding.

Figure 13-2 shows how the FIB is derived from the routing table and the TFIB is derived from the Tag information base (TIB). The label distribution protocol (LDP) and the TIB provide part of the control function for label switching by implementing label distribution and management. They implement protocols and procedures used to gather the information required to create the FIB and TFIB supporting the switching function.

The forwarding component in Tag Switching is based on Tag swapping. When a LSR receives a packet with a label, the label is used as an index in the TFIB. Each entry in the TFIB consists of an incoming label and one or more subentries such as outgoing label, outgoing interface, and outgoing link level information.

For each sub-entry, the label switch replaces the incoming label with the outgoing label and sends the packet on its way over the outgoing interface with the corresponding link-level information.

The Catalyst 8540 MSR/CSR enabled with Tag Switching, performs the following packet forwarding:

Tag Switching Operation in Virtual Private Networks

A Virtual Private Network (VPN) service is the infrastructure of a managed Intranet or Extranet service offered by a provider to many corporate customers. These are often massive IP networks. Tag Switching, in combination with the Border Gateway Protocol (BGP) or Open Shortest Path First (OSPF), allows one provider network to support several customer VPNs.

In a Tag Switching VPN, each site in a particular customer network is modeled as an autonomous system. The customer edge (CE) device(s) at a site use External BGP (or some other mechanism) to exchange routing information with the provider edge (PE) device(s) to which they are connected. The customer network interior routing algorithm runs independently at each site, and does not run in the provider network. Each VPN is an Internet with the backbone, and the provider network(s) connect the sites together.

Tag Switching-VPN enforces traffic separation among customers by assigning a unique VPN routing and forwarding (VRF) instance to each customer's VPN. PE switches or routers map IPv4 addresses from a particular customer network into corresponding addresses in a new VPN-IPv4 address family. A VPN-IPv4 address is a twelve-byte quantity. The first eight bytes are known as the route distinguisher (RD); the next four bytes are an IPv4 address. If two customer networks attach to the same provider network, and a given IP address is used in both customer networks, the PE switches or routers attached to the customer networks will translate the IPv4 address into two different VPN-IPv4 addresses (by using a different RD). Even when two customer networks use the same IPv4 address, the corresponding VPN-IPv4 addresses will be different. Within the provider network, routes to addresses that are within customer networks are maintained as routes to VPN-IPv4 addresses. Overlap between the address spaces of the two customer networks does not cause any ambiguity in the provider network. VPN-IPv4 routing information for a particular customer network is exchanged, using BGP, only by the PE routers that attach to that customer network. Provider routers that do not attach to a particular customer network do not receive the routing information for that network. The amount of routing information stored in a provider router is not proportional to the total number of VPNs supported by the provider network, It is only proportional to the number of VPNs to which that provider router is directly attached.

If a particular customer network is attached to a large number of PE switch routers, the need to have each one distribute routing information to all the others can cause a scalability problem. However, this problem can be addressed by means of well known techniques, such as the use of BGP route reflectors. That is, rather than having a PE distribute the routes directly to another PE, the two PEs can be clients of a common route reflector. A given route reflector need not handle routes from all VPNs; the set of VPNs using a particular backbone can be partitioned, and each set of VPNs can be assigned to a different route reflector. In no case is there ever any one system that needs to know all the routes. This fact makes it possible to scale the system virtually without limit.

Before a PE switch router distributes routing information (about other sites in the customer network) to a CE switch router, it translates the VPN-IPv4 addresses into IPv4 addresses by stripping off the first eight bytes. Thus the CE switch routers see only ordinary IPv4 addresses; the longer addressing form is used only in the provider network. The customer routers do not need to support the VPN-IPv4 address family.

Figure 13-4 shows a Tag Switching VPN Model

Tag Switching VPN Forwarding

An ingress PE switch router must maintain a separate forwarding table for each attached customer network. This forwarding table is populated with routing information that pertains only to the customer network. This information is gathered, by way of BGP, from other PE nodes that attach to the same customer network.

When a packet arrives from a directly attached customer network, its destination address is looked up in the corresponding forwarding table to determine its egress PE switch router.

The route a packet must traverse between its ingress and egress PE switch routers usually includes one or more intermediate provider switch routers. The intermediate provider switch routers do not maintain routing information for the VPNs, so they cannot forward the packet by looking up its IP destination address. Tag Switching achieves proper forwarding through the provider network.

Tag Switching is used to route the packet to the chosen egress PE switch router. The ingress PE switch router wraps the packet in a Tag Switching header, where the label corresponds to a route (through the provider network) to the egress PE switch router. Intermediate provider switch routers forward the packet based on the label, not based on the IP destination address. Therefore the intermediate provider switch routers do not need to know anything about customer network routing. Nor do they need to know anything about VPN-IPv4 addresses.

The ingress PE switch router applies two labels to the packet. When PE1 sends, by way of BGP, a VPN-IPv4 route to PE2, it also specifies a label for the route. If this route belongs to a particular customer network, PE2 enters this route into the forwarding table it uses for packets from that customer network. When PE2 receives a packet from a CE device in that network, it looks up the packet destination address in this forwarding table. As a result, it determines the packet BGP next hop (i.e., PE1), and the label assigned by that next hop. This label is pushed onto the packet label stack. Then PE2 looks up the address of PE1 in its "regular" forwarding table (i.e., in the forwarding table containing routes through the provider network). The provider switch router which is PE2's next hop to PE1 (call this P1) will have used LDP to bind a label to the PE1 route. This label is then pushed on the packet label stack, and the packet is sent to P1.

The topmost label, used for routing the packet through the provider network, corresponds to a route to the egress PE switch router. The bottom label is used by the egress PE switch router to determine the particular output port on which it should transmit the packet. Thus the egress PE switch router does not need to look up the packet destination address.

The Tag Switching VPN model allows a provider network to support any number of VPNs while maintaining a limit on the amount of routing information that needs to be stored in any one provider switch router. It prevents data from flowing between VPNs, since it maintains separate forwarding information for each VPN. It does not assume that VPNs use addresses that are unique.

Tag Switching SDM Control Operation

The control component of Tag Switching consists of IP routing protocols (typically OSPF or IS-IS) running in conjunction with Tag Switching label allocation and maintenance procedures. The control component sets up label forwarding paths along IP routes and distributes these label bindings to the label switches. The control component also maintains the accuracy for the topology changes in the path that might occur.

The label distribution protocol (LDP) is a major part of the control component. LDP establishes peer sessions between label switches and exchanges the labels needed by the forwarding function.

The OSPF or IS-IS routing protocol runs in the normal way, automatically creating forwarding tables in each Tag Switching label switch router. The Tag Switching label distribution protocol (LDP) is linked to the routing protocols and works in parallel with them. Based on the routing information provided by OSPF or IS-IS, LDP exchanges the labels needed by the forwarding function.

On the Catalyst 8540, The Tag Switching switching database manager (SDM) control layer resides on the route processor. It communicates between Cisco IOS Tag Switching (IP,VRF, and TFIB) subsystems and interface modules so that the IP FIB, VRF, TFIB, and tag-rewrite entries built in the route processor are also maintained in the interface module memory.

The Tag Switching SDM control layer maintains a shadow copy of the forwarding table (TFIB table) on the content addressable memory (CiscoCAM) and random access memory (SRAM) on the Gigabit Ethernet interfaces and POS interfaces. The Switching Database Manager (SDM) manages the IP, IPX, and IP Multicast switching applications in the CiscoCAM and SRAM. The SDM control infrastructure manages the VRF tables and tag rewrite entries in the Tag Switching switching database.

Configuring Tag Switching VPNs

This section provides configuration information for the Tag Switching operation on the Catalyst 8540 MSR/CSR.

To configure Tag Switching VPN, perform the following configuration tasks and use Figure 13-5 for reference:

Configuring BGP CE to PE Routing Sessions

To configure a BGP CE to PE routing session, perform the following steps on a CE device beginning in global configuration mode:

Example

The following example shows how to configure a BGP routing session between PE1 and CE1 in Figure 13-5:

Configuring VPNs in PE Devices

To configure VPN routing instances, perform the following steps on the PE switch router beginning in global configuration mode:

Example

The following example shows how to define a VPN by configuring interface Gigabit Ethernet 2/0/0 on PE1 to CE1 in Figure 13-5:

Configuring BGP PE Routing Sessions

To configure BGP PE routing sessions in a provider network, perform the following steps beginning in global configuration mode:

Example

The following example shows how to configure a BGP routing session in PE1 in Figure 13-5:

Configuring Tag Switching on PE and P Devices

To configure label switching between PE and P devices in the provider network, perform the following steps beginning in global configuration mode:

Example

The following example shows how to configure label switching on the PE1 device in the provider network in Figure 13-5:

Example

The following example shows how to configure label switching on the P1 device in the provider network in Figure 14-5.

Configuring IGP on PE Devices

To configure OSPF PE to P routing sessions in a provider network, perform the following steps beginning in global configuration mode:

Example

The following example shows how to configure OSPF routing session on PE1 in the provider network in Figure 13-5:

Configuring IGP on P Devices

To configure routing sessions between P devices in a provider network, perform the following steps beginning in global configuration mode:

Example

The following example shows how to configure an OSPF routing session on P1 in the provider network in Figure 13-5:

Configuring RIP Between PE and CE Devices

To configure RIP PE to CE routing sessions perform the following steps on the PE switch router from global configuration mode:

	Command	Purpose
Step 1	Router(config)# router rip	Enables RIP.
Step 2	Router(config-router)# address-family ipv4 [unicast] vrf vrf name	Defines RIP parameters for PE and CE routing sessions. Note    The default is Off for all auto-summary and synchronization in the VRF address-family submode.
Step 3	Router(config-router)# network prefix	Enables RIP on the PE to CE link.

Example

The following example shows how to configure a RIP routing session on PE1 in Figure 13-5:

Configuring Static Route PE to CE Routing Sessions

To configure static route PE to CE routing sessions perform the following steps on the PE switch router from global configuration mode:

Example

The following example shows how to configure a static route on PE1 in Figure 13-5:

Tag Switching VPN Configuration Examples

The configuration examples in this section show the Tag Switching VPN configurations described in Figure 13-6 and in the "Configuring Tag Switching VPNs" section.

Example

The following example shows the Tag Switching VPN configuration on the CE1 device referenced in Figure 13-6.

Example

Example

Verifying Tag Switching VPN Operation

To verify Tag Switching VPN operation, perform the following steps from the privilege EXEC mode:

Examples

The following examples show the output for the Tag Switching VPN operation:

To verify Tag Switching in the switching database manager (SDM), use the following commands from the privilege EXEC mode:

Examples

The following examples show the output for the Tag Switching SDM commands: