لطفا منتظر باشید ...
Layer 2 Local Switching
The local switching feature is another building block of the Cisco Unified VPN suite. Layer 2 local switching allows you to switch Layer 2 frames between two different attachment circuits on the same PE. The following permutations are supported, some of which do not require IW because the attachment circuit technologies are the same, whereas others do because they use different attachment circuit technologies:
Interfaces of the same type:
ATM-to-ATM
Frame Relay-to-Frame Relay
Ethernet-to-Ethernet/VLAN-to-VLAN
Interfaces of different types:
ATM-to-Ethernet/VLAN
ATM-to-Frame Relay
Frame Relay-to-Ethernet/VLAN
Local switching is not a pseudowire technology by the rigorous definition because a signaling protocol (such as LDP or L2TPv3) is not involved. However, local switching is a useful tool in the Layer 2 VPN solutions.
The main building block of the local switching configuration is the connect command, which allows you to create locally switched cross connections.
This section covers local switching between interfaces of the same type, and a later section details local switching between interfaces of different types. (See the section titled "Layer 2 local switching with interworking.") In this section, you learn the configuration and verification for the following local switching case studies:
Case Study 14-8: Frame Relay-to-Frame Relay Local Switching
Case Study 14-9: ATM-to-ATM Local Switching
Case Study 14-10: Ethernet-to-Ethernet Local Switching
Case Study 14-8: Frame Relay-to-Frame Relay Local Switching
Frame Relay-to-Frame Relay local switching is a feature that was introduced before the development of the complete Layer 2 VPN local switching suite and was welcomed as part of that. This Frame Relay-to-Frame Relay local switching case study uses the topology shown in Figure 14-13, introducing the SanJose node.
Figure 14-13. Frame Relay-to-Frame Relay Local Switching Topology
Example 14-35 shows the configuration for the SanFran PE.
Example 14-35. Frame Relay-to-Frame Relay Local Switching
!
hostname SanFran
!
frame-relay switching
!
interface Serial7/0
no ip address
encapsulation frame-relay
frame-relay interface-dlci 70 switched
frame-relay intf-type dce
!
interface Serial8/0
no ip address
encapsulation frame-relay
frame-relay intf-type dce
!
connect fr_local_sw Serial7/0 70 Serial8/0 80
!
!
From Example 14-35, you can see that the global configuration for frame-relay switching is a requirement. You can also see a switched Frame Relay interface DLCI configured in interface Serial 7/0 but not for interface Serial 8/0. Configuring the switched DLCI is an optional step. If the switched DLCI is not created in the interface, it is created with the connect command.
The heart of the configuration is in the connect command, by which you create the connection named fr_local_sw, which ties up DLCI 70 in Serial 7/0 to DLCI 80 in Serial 8/0. All the commands and tools that were covered in this and previous chapters regarding Frame Relay LMI, DLCI, maps, and connections are applicable to this case. For completeness, Example 14-36 includes the output of the command show connection.
Example 14-36. show connection Command in Local Switching
SanFran#show connection name fr_local_sw
3 fr_local_sw Se7/0 70 Se8/0 80 UP
SanFran#
With Frame Relay attachment circuits, you can use the debug command debug frame-relay pseudowire to troubleshoot problems.
Case Study 14-9: ATM-to-ATM Local Switching
The case of ATM-to-ATM local switching is quite similar to Frame Relay-to-Frame Relay local switching. However, specific considerations are necessary, the most important ones related to the PVC encapsulation. Only two types of PVC encapsulation are supported in ATM-to-ATM local switching:
AAL5 Using encapsulation aal5
SCR Single Cell Relay VC mode using encapsulation aal0
When you are using Single Cell Relay in some platforms, the virtual path identifier and virtual channel identifier (VPI/VCI) pair must match in both endpoints of the local switched connection.
When you are using AAL5, VPI/VCI values do not need to match in both endpoints. However, if you are transporting OAM cells over the local switched connection, the VPI/VCI must match because OAM cells are transported as cells, and you have the same limitation stated for single cell relay (SCR).
Besides the local switching of ATM PVCs, some platforms support the local switching of ATM permanent virtual paths (PVP) and packed cell relay (PCR) for local switching of ATM PVCs and ATM PVPs. In addition, local switching of ATM PVCs and ATM PVPs in the same port is supported. The configuration is analogous to this case study, using the same ATM interface for both connection endpoints.
Example 14-37 shows a sample configuration for PVC ATM-to-ATM local switching.
Example 14-37. ATM-to-ATM Local Switching Configuration
!
hostname SanFran
!
interface ATM1/0
pvc 0/100 l2transport
encapsulation aal5
!
interface ATM2/0
pvc 0/200 l2transport
encapsulation aal5
!
connect aal5_local_sw atm 1/0 0/100 atm 2/0 0/200
Notice that Example 14-37 shows cross-connecting PVCs with different VPI/VCI values, and the configuration uses encapsulation AAL5. Observe that the ATM PVCs are created using the l2transport keyword to identify the PVC as switched and not as terminated. The connection configuration is analogous to the Frame Relay-to-Frame Relay example, using VPI/VCI instead of DLCI.
Another similarity with Frame Relay-to-Frame Relay local switching is that you can enter the connect command without previously configuring the ATM PVCs, in which case the PVCs are created automatically in the respective interfaces that are specified (see Example 14-38).
Example 14-38. ATM-to-ATM Local Switching with Automatic PVCs
SanFran(config)#connect atm_local ATM 4/0 0/40 ATM 3/0 0/40
SanFran(config-connection)#
SanFran#show connection
ID Name Segment 1 Segment 2 State
===========================================================================
1 atm_local AT4/0 CELL 0/40 AT3/0 CELL 0/40 UP
SanFran#
SanFran#show connection id 1
Connection: 1 - atm_local
Current State: UP
Segment 1: ATM4/0 CELL 0/40 u
Segment 2: ATM3/0 CELL 0/40 up
SanFran#
You can see from Example 14-38 that only the connect command is entered, and it automatically creates the local switched connection. Note from the show connection output that the default encapsulation for automatically created l2transport PVCs is AAL0that is, VC Cell Relay mode. Example 14-39 shows how to check for automatically created l2transport PVCs and their default encapsulation.
Example 14-39. Displaying Automatic PVCs
SanFran#show atm vc | include 40| VC
VCD / Peak Avg/Min Burst
Interface Name VPI VCI Type Encaps Kbps Kbps Cells Sts
3/0 11 0 40 PVC-A AAL0 155000 N/A UP
4/0 19 0 40 PVC-A AAL0 149760 N/A UP
SanFran#
SanFram#show atm pvc 0/40 | begin ATM4/0
ATM4/0: VCD: 19, VPI: 0, VCI: 40
UBR, PeakRate: 149760
AAL0-Cell Relay, etype:0x10, Flags: 0x10000C2D, VCmode: 0x0
OAM Cell Emulation: not configured
Interworking Method: like to like
Remote Circuit Status = No Alarm, Alarm Type = None
InBytes: 208963575912, OutBytes: 1088149400
Cell-packing Disabled
OAM cells received: 1
F5 InEndloop: 0, F5 InSegloop: 0, F5 InAIS: 1, F5 InRDI: 0
OAM cells sent: 1
F5 OutEndloop: 0, F5 OutSegloop: 0, F5 OutAIS: 1, F5 OutRDI: 0
OAM cell drops: 0
Auto-created by Connection Manager
Status: UP
W2N-7.11-c7206VXR-A#m
Case Study 14-12: ATM Attachment Circuits and Local Switching."
With ATM PVC attachment circuits, you can use the debug command debug atm l2transport as a troubleshooting tool.
Case Study 14-10: Ethernet-to-Ethernet Local Switching
This case study shows Ethernet-to-Ethernet port mode local switching. The same configuration and verification presented here is analogous to Ethernet dot1Q VLAN-to-VLAN local switching using subinterfaces instead of the main interface. This topology is included in Figure 14-14.
Figure 14-14. Ethernet-to-Ethernet Local Switching
The actual configuration required is equivalent to the previous ones using the connect command (see Example 14-40).
Example 14-40. Ethernet-to-Ethernet Local Switching
!
hostname SanFran
!
connect eth-eth Ethernet3/0 Ethernet4/0
!
!
The configuration that is required at the PE is to activate the Ethernet interfaces with a no shutdown and issue the connect command. You can verify that the local switched connection is working (see Example 14-41).
Example 14-41. Ethernet-to-Ethernet Local Switching Verification
SanFran#show connection name eth-eth
Connection: 4 - eth-eth
Current State: UP
Segment 1: Ethernet3/0 up
Segment 2: Ethernet4/0 up
SanFran#
SanJose#ping 192.168.51.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.51.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 24/28/36 ms
SanJose#
For the sake of argument, you can use the local switching feature without configuring IP addresses in the PE device, because no signaling is involved. An interface or a router that does not have an IP address does not process IP packets; therefore, it cannot process signaling messages carried over IP, as is the case with LDP and L2TPv3. This idea emphasizes the point that no signaling protocol is implicated in local switching.
You can witness this fact when enabling the debug command debug acircuit event to debug events that occur on the attachment circuits (see Example 14-42).
Example 14-42. Debugging Attachment Circuit for a Local Switched Connection
SanFran(config)#do debug acircuit event
Attachment Circuit events debugging is on
SanFran(config)#interface Ethernet 3/0
SanFran(config-if)#no shutdown
SanFran(config-if)#
00:28:44: ACLIB [0.0.0.0, 0]: SW AC interface UP for Ethernet interface Et3/0
00:28:44: ACLIB: Added circuit to retry queue, type 6, id 5, idb Et3/0
00:28:44: ACLIB [0.0.0.0, 0]: pthru_intf_handle_circuit_up() calling acmgr_circuit_up
00:28:44: ACLIB [0.0.0.0, 0]: Setting new AC state to Ac-Connecting
00:28:44: ACLIB: Update switching plane with circuit UP status
00:28:44: ACLIB [0.0.0.0, 0]: SW AC interface UP for Ethernet interface Et3/0
00:28:44: ACLIB [0.0.0.0, 0]: pthru_intf_handle_circuit_up() ignoring up event.
Already connected or connecting.
00:28:44: ACLIB [0.0.0.0, 0]: pthru_intf_handle_circuit_up() ignoring up event.
Already connected or connecting.
00:28:44: Et3/0 ACMGR: Receive <Circuit Up> msg
00:28:44: Et3/0 ACMGR: circuit up event, SIP state chg fsp up to connected, action
is p2p up forwarded
00:28:44: ACLIB: pthru_intf_response hdl is 7F000012, response is 2
00:28:44: ACLIB [0.0.0.0, 0]: Setting new AC state to Ac-Connected
00:28:44: Et4/0 ACMGR: Receive <Remote Up Notification> msg
00:28:44: Et4/0 ACMGR: remote up event, FSP state chg fsp up to connected, action
is respond forwarded
00:28:44: ACLIB: pthru_intf_response hdl is 41000016, response is 2
00:28:44: ACLIB [0.0.0.0, 0]: Setting new AC state to Ac-Connected
00:28:46: %LINK-3-UPDOWN: Interface Ethernet3/0, changed state to up
00:28:47: %LINEPROTO-5-UPDOWN: Line protocol on Interface Ethernet3/0, changed
state to up
SanFran(config-if)#
You can see by inspecting [0.0.0.0, 0] that the IP address of the remote peer is displayed as 0.0.0.0, and the VC ID is shown as 0. This is because it is a local switching connection.
Note
A consequence of no pseudowire signaling protocol being involved in local switching cases is that MTU mismatches between the attachment circuits do not prevent the circuit from coming up. The downside is that a circuit not coming up might trigger you to revisit the MTU settings.
