CCC, TCC, and Ethernet Over MPLS Configuration

Translational cross-connect (TCC) allows you to forward traffic between a variety of Layer 2 protocols or circuits. It is similar to its predecessor, CCC. However, while CCC requires the same Layer 2 encapsulations on both sides of a router (such as Point-to-Point Protocol [PPP] or Frame Relay-to-Frame Relay), TCC lets you connect different types of Layer 2 protocols interchangeably. With TCC, combinations such as PPP-to-ATM and Ethernet-to-Frame Relay cross-connections are possible. Also, TCC can be used to create Layer 2.5 VPNs and Layer 2.5 circuits.

Consider a sample topology (Figure 1) in which you can configure a full-duplex Layer 2.5 translational cross-connect between Router A and Router C, using a Juniper Networks router, Router B, as the TCC interface. In this topology, Router B strips all PPP encapsulation data from frames arriving from Router A and adds ATM encapsulation data before the frames are sent to Router C. All Layer 2 negotiations are terminated at the interconnecting router (Router B).

Figure 1: Sample Translation Cross-Connect Topology

TCC functionality is different from standard Layer 2 switching. TCC only swaps Layer 2 headers. No other processing, such as header checksums, time-to-live (TTL) decrementing, or protocol handling, is performed. Currently, TCC is supported in IPv4, ISO, and MPLS.

Ethernet TCC is supported on interfaces that carry IPv4 traffic only. For 8-port, 12-port, and 48-port Fast Ethernet PICs, TCC and extended VLAN CCC are not supported. For 4-port Gigabit Ethernet PICs, extended VLAN CCC and extended VLAN TCC are not supported.

Circuit cross-connect (CCC) allows you to configure transparent connections between two circuits, where a circuit can be a Frame Relay data-link connection identifier (DLCI), an Asynchronous Transfer Mode (ATM) virtual circuit (VC), a Point-to-Point Protocol (PPP) interface, a Cisco High-Level Data Link Control (HDLC) interface, or an MPLS label-switched path (LSP). Using CCC, packets from the source circuit are delivered to the destination circuit with, at most, the Layer 2 address being changed. No other processing—such as header checksums, time-to-live (TTL) decrementing, or protocol processing—is done.

CCC circuits fall into two categories: logical interfaces, which include DLCIs, VCs, virtual local area network (VLAN) IDs, PPP and Cisco HDLC interfaces, and LSPs. The two circuit categories provide three types of cross-connect:

• Layer 2 switching—Cross-connects between logical interfaces provide what is essentially Layer 2 switching. The interfaces that you connect must be of the same type.

• MPLS tunneling—Cross-connects between interfaces and LSPs allow you to connect two distant interface circuits of the same type by creating MPLS tunnels that use LSPs as the conduit.

• LSP stitching—Cross-connects between LSPs provide a way to “stitch” together two label-switched paths, including paths that fall in two different traffic engineering database areas.

For Layer 2 switching and MPLS tunneling, the cross-connect is bidirectional, so packets received on the first interface are transmitted out the second interface, and those received on the second interface are transmitted out the first. For LSP stitching, the cross-connect is unidirectional.

The customer of a VPN service provider might be a service provider for the end customer. The following are the two main types of carrier-of-carriers VPNs (as described in RFC 4364:

• Internet Service Provider as the Customer—The VPN customer is an ISP that uses the VPN service provider’s network to connect its geographically disparate regional networks. The customer does not have to configure MPLS within its regional networks.

• VPN Service Provider as the Customer—The VPN customer is itself a VPN service provider offering VPN service to its customers. The carrier-of-carriers VPN service customer relies on the backbone VPN service provider for inter-site connectivity. The customer VPN service provider is required to run MPLS within its regional networks.

Figure 3 illustrates the network architecture used for a carrier-of-carriers VPN service.

Figure 3: Carrier-of-Carriers VPN Architecture

This topic covers the following:

• Internet Service Provider as the Customer
• VPN Service Provider as the Customer

All interprovider and carrier-of-carriers VPNs share the following characteristics:

• Each interprovider or carrier-of-carriers VPN customer must distinguish between internal and external customer routes.

• Internal customer routes must be maintained by the VPN service provider in its PE routers.

• External customer routes are carried only by the customer’s routing platforms, not by the VPN service provider’s routing platforms.

The key difference between interprovider and carrier-of-carriers VPNs is whether the customer sites belong to the same AS or to separate ASs:

• Interprovider VPNs—The customer sites belong to different ASs. You need to configure EBGP to exchange the customer’s external routes.

• Understanding Carrier-of-Carriers VPNs—The customer sites belong to the same AS. You need to configure IBGP to exchange the customer’s external routes.

In general, each service provider in a VPN hierarchy is required to maintain its own internal routes in its P routers, and the internal routes of its customers in its PE routers. By recursively applying this rule, it is possible to create a hierarchy of VPNs.

The following are definitions of the types of PE routers specific to interprovider and carrier-of-carriers VPNs:

• The AS border router is located at the AS border and handles traffic leaving and entering the AS.

• The end PE router is the PE router in the customer VPN; it is connected to the CE router at the end customer’s site.

You can configure BGP to gather traffic statistics for interprovider and carrier-of-carriers VPNs.

To configure BGP to gather traffic statistics for interprovider and carrier-of-carriers VPNs, include the traffic-statistics statement:

For a list of the hierarchy levels at which you can include this statement, see the summary section for this statement.

If you do not specify a filename, the statistics are not written to a file. However, if you have included the traffic-statistics statement in the BGP configuration, the statistics are still available and can be accessed by means of the show bgp group traffic-statistics group-name command.

To account for traffic from each customer separately, separate labels must be advertised for the same prefix to the peer routers in different groups. To enable separate traffic accounting, you need to include the per-group-label statement in the configuration for each BGP group. By including this statement, statistics are collected and displayed that account for traffic sent by the peers of the specified BGP group.

If you configure the statement at the [edit protocols bgp family inet] hierarchy level, rather than configuring it for a specific BGP group, then the traffic statistics are shared with all BGP groups configured with the traffic-statistics statement but not configured with the per-group-label statement.

To account for traffic from each customer separately, include the per-group-label statement in the configuration for each BGP group:

For a list of the hierarchy levels at which you can include this statement, see the summary section for this statement.

The following shows a sample of the output to the traffic statistics file:

The primary reason to configure vlan-ccc on the transport PS interface is interoperability with the existing access and aggregate devices in the network. Currently, Junos OS supports ethernet-ccc encapsulation on the transport PS interface. Typically, while establishing a pseudowire connection, the access device initiates a VLAN-based pseudowire (also known as VLAN-tagged mode), and a PE router signals the Ethernet mode VLAN back to the access device. For this type of pseudowire connection to be established, you can use the ignore-encapsulation-mismatch statement. However, the Junos OS device (access device) might not support the ignore-encapsulation-mismatch statement and, as a result, the pseudowire connection is not formed. When the ignore-encapsulation-mismatch statement is not supported on the access device, you can configure vlan-ccc between the nodes to form a pseudowire connection.

The forwarding data path is not changed with the new vlan-ccc encapsulation on the transport PS interface and the behavior similar to that when the ethernet-ccc encapsulation is configured on the transport PS interface. The transport PS interface either encapsulates or de-encapsulate the outer Layer 2 header and MPLS headers on the transmitted or received packets on the WAN port. Inner Ethernet or VLAN headers of the packet are handled on pseudowire client service logical interfaces. You must configure pseudowire client service logical interfaces with appropriate VLAN IDs or VLAN tags.

The following sections provides details, along with a sample configuration, about pseudowire configuration from both access and aggregation nodes.

• Pseudowire Configuration from Access Node
• Pseudowire Configuration from Aggregation Node

Pseudowire Configuration from Access Node

These pseudowires are set up using VLANs from the access node for customer devices attached to the Layer 2 circuit configured on access and PE routers with customer VLANs (C-VLANs). The ingress traffic (from the access node side) on the PE router is single VLAN tagged (inner Ethernet header), and thus the service logical interfaces must be configured with the same VLAN IDs corresponding to the C-VLAN IDs attached to the access node.

Figure 4 provides the details of a transport PS interface from an access node (access node).

Figure 4: Pseudowire Client Transport Logical Interface from Access Node

The following example shows the configuration of a pseudowire client logical interface configuration on a PE router from an access node:

Pseudowire Configuration from Aggregation Node

In this case, the aggregation node processes a stacked VLAN (also known as Q-in-Q). The pseudowire originates from aggregation node and terminates on a PE router. The aggregation node pushes the service VLAN (S-VLAN) tag, and the PE router is expected to operate on two VLAN tags—the outer VLAN tag corresponds to an S-VLAN and the inner VLAN tag corresponds to a C-VLAN. The VLAN ID configured on the transport PS interface at the PE router must match the VLAN tag of the S-VLAN. On the pseudowire client service logical interface, the outer VLAN tag must be configured to match the S-VLAN and the inner VLAN tag must be configured to match the C-VLAN.

Figure 5 provides the details of a transport PS interface from an aggregation node.

Figure 5: Pseudowire Client Transport Logical Interface from Aggregation Node

The following example shows the configuration of a pseudowire client logical interface configuration on a PE router from an aggregation node:

CCC protocol (and Layer 2 Circuit and Layer 2 VPN) configurations can transmit nonstandard bridge protocol data units (BPDUs) generated by other vendors’ equipment. This is the default behavior on all supported PICs and requires no additional configuration.

The following PICs are supported on M320 and T Series routers:

• 1-port Gigabit Ethernet PIC

• 2-port Gigabit Ethernet PIC

• 4-port Gigabit Ethernet PIC

• 10-port Gigabit Ethernet PIC

Translational cross-connect (TCC) is a switching concept that enables you to establish interconnections between a variety of Layer 2 protocols or circuits. It is similar to CCC. However, whereas CCC requires the same Layer 2 encapsulations on each side of a Juniper Networks router (such as PPP-to-PPP or Frame Relay-to-Frame Relay), TCC enables you to connect different types of Layer 2 protocols interchangeably. When you use TCC, combinations such as PPP-to-ATM (see Figure 6) and Ethernet-to-Frame Relay connections are possible.

Figure 6: TCC Example

The Layer 2 circuits and encapsulation types that can be interconnected by TCC are:

• Ethernet

• Extended VLANs

• PPP

• HDLC

• ATM

• Frame Relay

TCC works by removing the Layer 2 header when frames enter the router and adding a different Layer 2 header on the frames before they leave the router. In Figure 6, the PPP encapsulation is stripped from the frames arriving at Router B, and the ATM encapsulation is added before the frames are sent to Router C.

Note that all control traffic is terminated at the interconnecting router (Router B). Examples of traffic controllers include the Link Control Protocol (LCP) and the Network Control Protocol (NCP) for PPP, keepalives for HDLC, and Local Management Interface (LMI) for Frame Relay.

TCC functionality is different from standard Layer 2 switching. TCC only swaps Layer 2 headers. No other processing, such as header checksums, TTL decrementing, or protocol handling is performed. TCC is supported for IPv4 only.

Address Resolution Protocol (APR) packet policing on TCC Ethernet interfaces is effective for releases 10.4 and onwards.

You can configure TCC for interface switching and for Layer 2 VPNs. For more information about using TCC for virtual private networks (VPNs), see the Junos OS VPNs Library for Routing Devices.

Layer 2 switching cross-connects join logical interfaces to form what is essentially Layer 2 switching. The interfaces that you connect must be of the same type.

Figure 7 illustrates a Layer 2 switching cross-connect. In this topology, Router A and Router C have Frame Relay connections to Router B, which is a Juniper Networks router. Circuit cross-connect (CCC) allows you to configure Router B to act as a Frame Relay (Layer 2) switch.

To configure Router B to act as a Frame Relay switch, you configure a circuit from Router A to Router C that passes through Router B, effectively configuring Router B as a Frame Relay switch with respect to these routers. This configuration allows Router B to transparently switch packets (frames) between Router A and Router C without regard to the packets’ contents or the Layer 3 protocols. The only processing that Router B performs is to translate DLCI 600 to 750.

Figure 7: Layer 2 Switching Cross-Connect

If the Router A–to–Router B and Router B–to–Router C circuits were PPP, for example, the Link Control Protocol and Network Control Protocol exchanges occur between Router A and Router C. These messages are handled transparently by Router B, allowing Router A and Router C to use various PPP options (such as header or address compression and authentication) that Router B might not support. Similarly, Router A and Router C exchange keepalives, providing circuit-to-circuit connectivity status.

You can configure Layer 2 switching cross-connects on PPP, Cisco HDLC, Frame Relay, Ethernet, and ATM circuits. In a single cross-connect, only like interfaces can be connected.

To configure Layer 2 switching cross-connects, you must configure the following on the router that is acting as the switch (Router B in Figure 7):

• Configuring the CCC Encapsulation for Layer 2 Switching Cross-Connects
• Configuring the CCC Connection for Layer 2 Switching Cross-Connects
• Configuring MPLS for Layer 2 Switching Cross-Connects
• Example: Configuring a Layer 2 Switching Cross-Connect
• Configuring Layer 2 Switching Cross-Connect on ACX5440

Example: Configuring a Layer 2 Switching Cross-Connect

Configure a full-duplex Layer 2 switching cross-connect between Router A and Router C, using a Juniper Networks router, Router B, as the virtual switch. See the topology in Figure 8 and Figure 9.

Figure 8: Topology of a Frame Relay Layer 2 Switching Cross-Connect

Figure 9: Sample Topology of a VLAN Layer 2 Switching Cross-Connect

MPLS tunnel cross-connects between interfaces and LSPs allow you to connect two distant interface circuits of the same type by creating MPLS tunnels that use LSPs as the conduit. The topology in Figure 10 illustrates an MPLS LSP tunnel cross-connect. In this topology, two separate networks, in this case ATM access networks, are connected through an IP backbone. CCC allows you to establish an LSP tunnel between the two domains. With LSP tunneling, you tunnel the ATM traffic from one network across a SONET backbone to the second network by using an MPLS LSP.

Figure 10: MPLS Tunnel Cross-Connect

When traffic from Router A (VC 234) reaches Router B, it is encapsulated and placed into an LSP, which is sent through the backbone to Router C. At Router C, the label is removed, and the packets are placed onto the ATM permanent virtual circuit (PVC) (VC 591) and sent to Router D. Similarly, traffic from Router D (VC 591) is sent over an LSP to Router B, then placed on VC 234 to Router A.

You can configure LSP tunnel cross-connect on PPP, Cisco HDLC, Frame Relay, and ATM circuits. In a single cross-connect, only like interfaces can be connected.

When you use MPLS tunnel cross-connects to support IS-IS, you must ensure that the LSP’s maximum transmission unit (MTU) can, at a minimum, accommodate a 1492-octet IS-IS protocol data unit (PDU) in addition to the link-level overhead associated with the technology being connected.

For the tunnel cross-connects to work, the IS-IS frame size on the edge routers (Routers A and D in Figure 11) must be smaller than the LSP’s MTU.

To determine the LSP MTU required to support IS-IS, use the following calculation:

The framing overhead varies based on the encapsulation being used. The following lists the IS-IS encapsulation overhead values for various encapsulations:

• ATM

  • AAL5 multiplex—8 bytes (RFC 1483)

  • VC multiplex—0 bytes

• Frame Relay

  • Multiprotocol—2 bytes (RFCs 1490 and 2427)

  • VC multiplex—0 bytes

• HDLC—4 bytes

• PPP—4 bytes

• VLAN—21 bytes (802.3/LLC)

For IS-IS to work over VLAN-CCC, the LSP’s MTU must be at least 1513 bytes (or 1518 for 1497-byte PDUs). If you increase the size of a Fast Ethernet MTU above the default of 1500 bytes, you might need to explicitly configure jumbo frames on intervening equipment.

To modify the MTU, include the mtu statement when configuring the logical interface family at the [edit interfaces interface-name unit logical-unit-number encapsulation family] hierarchy level. For more information about setting the MTU, see the Junos OS Network Interfaces Library for Routing Devices.

To configure an LSP tunnel cross-connect, you must configure the following on the interdomain router (Router B in Figure 11):

• Configuring the CCC Encapsulation for LSP Tunnel Cross-Connects
• Configuring the CCC Connection for LSP Tunnel Cross-Connects
• Example: Configuring an LSP Tunnel Cross-Connect

Example: Configuring an LSP Tunnel Cross-Connect

Configure a full-duplex MPLS LSP tunnel cross-connect from Router A to Router D, passing through Router B and Router C. See the topology in Figure 11.

Figure 11: Example Topology of MPLS LSP Tunnel Cross-Connect

On Router B:

On Router C:

This section describes how to configure translational cross-connect (TCC).

To configure TCC, you must perform the following tasks on the router that is acting as the switch:

• Configuring the Encapsulation for Layer 2 Switching TCCs
• Configuring the Connection for Layer 2 Switching TCCs
• Configuring MPLS for Layer 2 Switching TCCs

CCC and TCC graceful restart allows Layer 2 connections between customer edge (CE) routers to restart gracefully. These Layer 2 connections are configured with the remote-interface-switch or lsp-switch statements. Because these CCC and TCC connections have an implicit dependency on RSVP LSPs, graceful restart for CCC and TCC uses the RSVP graceful restart capabilities.

RSVP graceful restart must be enabled on the PE routers and P routers to enable graceful restart for CCC and TCC. Also, because RSVP is used as the signaling protocol for signaling label information, the neighboring router must use helper mode to assist with the RSVP restart procedures.

Figure 12 illustrates how graceful restart might work on a CCC connection between two CE routers.

Figure 12: Remote Interface Switch Connecting Two CE Routers Using CCC

PE Router A is the ingress for the transmit LSP from PE Router A to PE Router B and the egress for the receive LSP from PE Router B to PE Router A. With RSVP graceful restart enabled on all the PE and P routers, the following occurs when PE router A restarts:

• PE Router A preserves the forwarding state associated with the CCC routes (those from CCC to MPLS and from MPLS to CCC).

• Traffic flows without disruption from CE router to CE router.

• After the restart, PE Router A preserves the label for the LSP for which PE Router A is the egress (the receive LSP, for example). The transmit LSP from PE Router A to PE Router B can derive new label mappings, but should not cause any traffic disruption.

To enable CCC and TCC graceful restart, include the graceful-restart statement:

You can include this statement at the following hierarchy levels:

• [edit routing-options]

• [edit logical-systems logical-system-name routing-options]

You can configure circuit cross-connect (CCC) between two circuits to switch traffic from interfaces to point-to-multipoint LSPs. This feature is useful for handling multicast or broadcast traffic (for example, a digital video stream).

To configure CCC switching for point-to-multipoint LSPs, you do the following:

• On the ingress provider edge (PE) router, you configure CCC to switch traffic from an incoming interface to a point-to-multipoint LSP.

• On the egress PE, you configure CCC to switch traffic from an incoming point-to-multipoint LSP to an outgoing interface.

The CCC connection for point-to-multipoint LSPs is unidirectional.

For more information about point-to-multipoint LSPs, see Point-to-Multipoint LSPs Overview.

To configure a CCC connection for a point-to-multipoint LSP, complete the steps in the following sections:

• Configuring the Point-to-Multipoint LSP Switch on Ingress PE Routers
• Configuring Local Receivers on a Point-to-Multipoint CCC LSP Switch on Ingress PE Routers
• Configuring the Point-to-Multipoint LSP Switch on Egress PE Routers