Layer 2 Vpn Architectures [Electronic resources] نسخه متنی

Understanding Advanced Interworking and Local Switching

This final section covers two topics:

connect command You learn about the different behaviors of this command.

Encapsulation You learn detailed information about the encapsulations of IW and local switching.

connect Command

At this point, you know how to use the connect command in multiple contexts. You used it to create AToM and L2TPv3 pseudowire endpoints in Frame Relay DLCI attachment circuits to perform local switching and Frame Relay local switching. This section compares the different modes of this command using examples.

You have used the connect command in three different contexts and created different configuration modes. Example 14-45 shows the connect command that performs Frame Relay pseudowire switching.

Example 14-45. connect Command and Frame Relay Pseudowire Switching

SanFran(config)#connect fr-vlan Serial5/0 100 l2transport
SanFran(config-fr-pw-switching)#

When you use the connect command with the l2transport keyword, you are taken into config-fr-pw-switching configuration mode. Example 14-46 shows the connect command that performs local Frame Relay switching.

Example 14-46. connect Command and Frame Relay Switching

SanFran(config)#connect fr_local_sw serial 7/0 70 serial 8/0 80
SanFran(config-fr-switching)#

When you use the connect command to cross connect two local Frame Relay DLCIs, you are taken into config-fr-switching configuration mode. Example 14-47 shows the connect command that performs local cross connection between two attachment circuits.

Example 14-47. connect Command for Local Switching Connections

SanFran(config)#connect eth-eth ethernet 3/0 ethernet 4/0
SanFran(config-connection)#
SanFran(config)#connect eth-fr ethernet 3/0 serial 7/0 100 interworking ip
SanFran(config-connection)#
SanFran(config)#connect eth-eth ethernet 3/0.1 ethernet 4/0.1
SanFran(config-connection)#exit
SanFran(config)#connect atm_local ATM 4/0 0/40 ATM 3/0 0/40
SanFran(config-connection)#

Example 14-47 shows various cases used throughout this chapter. In the case of any-to-any (not like-to-like) attachment circuits, the IW option is presented. These different configuration submodes also present different commands that are applicable to the specific function that is being performed. (For example, the local switching submodes have no xconnect command.)

Encapsulation

This section introduces you to encapsulation details for some of the case studies presented in this chapter. To view the encapsulation details, use Subscriber Service Switch (SSS) exec commands. The connections are represented as attachment circuit session types to SSS. All the examples use the command show sss circuits, which provides the status, encapsulation length, and encapsulation hexadecimal dump for the circuits. The encapsulation that is presented as output of this command, also called rewrite, indicates data that is added to the packet.

This section's goal is that you obtain a better understanding of the underlying processes and protocols in the case studies. The following examples are presented:

Encapsulation 1: Ethernet-to-VLAN Local Switching Ethernet IW

Encapsulation 2: Frame Relay-to-VLAN IP IW Using AToM

Encapsulation 3: VLAN-to-Ethernet Bridged IW Using L2TPv3

Encapsulation 4: Frame Relay-to-PPP IP-IW Using L2TPv3

Encapsulation 1: Ethernet-to-VLAN Local Switching Ethernet IW

This scenario presents the local switching Case Study 14-10in the SanFran PE router between Ethernet 2/0 and VLAN 27 in Ethernet 3/0.1 (see Example 14-48).

Example 14-48. SSS Circuit Encapsulation for Ethernet-to-VLAN Local Switching Ethernet-IW

SanFran#show sss circuits
Current SSS Circuit Information: Total number of circuits 5
!Output omitted for brevity
Common Circuit ID 0             Serial Num 5          Switch ID 18796512
---------------------------------------------------------------------------
Status  Encapsulation 
UP flg  len dump      
Y  AES  0             
Y  AES  4   8100001B  
SanFran#

Focusing on the encapsulation, you know that in Ethernet IW, Ethernet frames are sent over the Layer 2 circuit. Therefore, the Ethernet endpoint has no specific encapsulation, as denoted in the encapsulation length of 0.

For the VLAN side, however, the encapsulation includes the 4-byte VLAN tag. In this example, the encapsulation is represented as 0x8100001B, from which you see the following:

The 802.1q VLAN Ethertype of 0x8100

The 802.1p CoS bits of 0 and CFI of 0

The VLAN ID of 0x1B or 27 as configured

Encapsulation 2: Frame Relay-to-VLAN IP IW Using AToM

This scenario presents the AToM IP IW Case Study 14-4 from both the SanFran and New York PE routers. The scenario starts from the SanFran PE router, in which the local cross-connection is Frame Relay-to-AToM (see Example 14-49).

Example 14-49. SSS Circuit Encapsulation for Frame Relay IP-IW Using AToM

SanFran#show sss circuits
Current SSS Circuit Information: Total number of circuits 5
!Output omitted for brevity
Common Circuit ID 0             Serial Num 3          Switch ID 18796912
---------------------------------------------------------------------------
Status  Encapsulation 
UP flg  len dump      
Y  AES  4   184103CC  
Y  AES  0             
SanFran#

The show sss circuits command in the SanFran PE shows the encapsulations that are local to this PE router; it does not show the remote VLAN encapsulation. In IP IW, only raw IP packets are sent over the pseudowire; therefore, the rewrite includes the complete Layer 2 encapsulation.

You can see that the encapsulation for the Frame Relay endpoint is 4 bytes in length, is equal to 0x184103CC, and is made out of the following:

The first 2 octets represent the Q.922 header:

The leftmost 6 bits of the first octet are equal to 000110 and form the high-order DLCI; the leftmost 4 bits of the second octet are equal to 0100 and make up the low-order DLCI. Therefore, the 10-bit DLCI is expressed in binary 0001100100 or 100 in decimal, which is the DLCI that is configured in Case Study 14-4.

The least significant bit of the second byte is set to 1, to indicate the lack of an extended address (EA).

The third octet in the encapsulation is the control of 0x03.

The last octet is the NLPID value of the IP Protocol that is equal to 0xCC.

Because IP is received over the pseudowire, after you append this 4-byte encapsulation and set the values of FECN, BECN, and DE, you send the packet over the Frame Relay attachment circuit. Toward the AToM side, the encapsulation is always shown as NULL.

The second part of this example presents the VLAN side of the AToM routed IW pseudowire from the New York PE, in which the local cross connection is VLAN to AToM (see Example 14-50).

Example 14-50. SSS Circuit Encapsulation for VLAN IP-IW Using AToM

New York#show sss circuits
Current SSS Circuit Information: Total number of circuits 4
[snip]
Common Circuit ID 0             Serial Num 3          Switch ID 18796912
---------------------------------------------------------------------------
Status  Encapsulation                                
UP flg  len dump                                     
Y  AES  18  FFFFFFFF FFFF000C CF552408 81000002 0800 
Y  AES  0                                            
!Output omitted for brevity
New York#

To reiterate, the show sss circuits command in the New York PE illustrates the encapsulations that are local to this PE router and does not show the remote Frame Relay encapsulation. In IP IW, only raw IP packets are transmitted over the pseudowire; therefore, the VLAN side should show a complete 18-byte VLAN rewrite.

When you compare the VLAN encapsulation for both bridged and routed IW, you see the following:

Bridged The encapsulation is only 4 bytes and includes the 802.1q header only. This is because an Ethernet frame is received over the pseudowire, and adding the 802.1q header creates a complete VLAN frame.

Routed The encapsulation is 18 bytes and includes the complete Layer 2 encapsulation, including Ethernet II and 802.1q headers. This is because an IP datagram is received over the pseudowire, so appending the 18-byte encapsulation creates a complete VLAN frame.

You can see that the encapsulation length is 18 bytes and is composed of the following:

The first 6 bytes are the destination MAC address where 0xFFFFFFFFFFFF is a broadcast Ethernet address, meaning that the PE has not yet learned the CE's MAC address. This MAC address is changed to the actual value after it is learned.

The next 6 bytes are the source MAC address.

The next 4 bytes are the VLAN tag, including the following:

VLAN etype of 0x8100

CoS and CFI of 0

VLAN ID of 2 as configured

The final two bytes are the IP Ethertype of 0x0800.

Prepending this encapsulation to an IP packet that is received over the pseudowire and setting CoS bits appropriately makes a valid frame to be sent out of the Ethernet 2/0.1 interface in the New York PE.

Figure 14-16 shows the encapsulation added in both SanFran and New York PEs for this scenario. The fields in gray represent the rewrite that has been described verbally.

Encapsulation 3: VLAN-to-Ethernet Bridged IW Using L2TPv3

This scenario presents the L2TPv3 Ethernet IW Case Study 14-2 from the VLAN attachment circuit in the New York PE router. The local cross-connection in the New York router is VLAN-to-L2TPv3 (see Example 14-51).

Example 14-51. SSS Circuit Encapsulation for VLAN Ethernet-IW Using L2TPv3

New York#show sss circuits
Current SSS Circuit Information: Total number of circuits 4
Common Circuit ID 0             Serial Num 2          Switch ID 18797112
---------------------------------------------------------------------------
Status  Encapsulation                                    
UP flg  len dump                                         
Y  AES  4   81000002                                     
Y  AES  28  45000000 00000000 FF73A5F7 0A0000CB 0A0000C9 
         000058FB 00000000                        
New York#

The local encapsulations to the New York PE router are VLAN toward the attachment circuit and L2TPv3 toward the PSN. The attachment circuit side is equivalent to previous encapsulation scenario 1. Because this is bridged IW and Ethernet frames are received over the pseudowire, no other encapsulation is needed.

However, the PSN side that uses L2TPv3 is new and shows an encapsulation length of 28 bytes, consisting of the following:

20 bytes of IPv4 header, including the following:

Version 4 Header length 5 32-bit words

Protocol 115 (0x73) for L2TPv3

Source address 10.0.0.203

Destination address 10.0.0.201

4 bytes of L2TPv3 Session Header (0x000058FB): 32-bit Session ID of 22779

4 bytes of L2-Specific Sublayer (sequencing was configured):

Sequence bit clear

Sequence number cleared

Note

You can also display the L2TPv3 encapsulation by using the show adjacency detail command in the pseudowire IP adjacency.

An Ethernet frame is encapsulated. After you complete the empty fields, such as DSCP in the IP Header and sequencing information in the L2-Specific Sublayer, you can send the L2TPv3 packet toward the PSN.

Encapsulation 4: Frame Relay-to-PPP IP-IW Using L2TPv3

Case Study 14-5 from the SanFran and New York PE routers. The discussion starts from the SanFran PE router, in which the local cross connection is Frame Relay to L2TPv3 (see Example 14-52).

Example 14-52. SSS Circuit Encapsulation for Frame Relay IP-IW Using L2TPv3

SanFran#show sss circuits
Current SSS Circuit Information: Total number of circuits 5
!Output omitted for brevity
Common Circuit ID 0             Serial Num 4          Switch ID 18796712
---------------------------------------------------------------------------
Status  Encapsulation                                    
UP flg  len dump                                         
Y  AES  4   0CC103CC                                     
Y  AES  24  45000000 00000000 FF73A5F7 0A0000C9 0A0000CB 
         0000269D                                 
SanFran#

The Frame Relay attachment circuit and L2TPv3 encapsulation in SanFran PE are similar to the previous examples, where you can see the following for the Frame Relay attachment circuit:

The first 2 octets represent the Q.922 header: DLCI = 111100b = 60.

The third octet in the encapsulation is the control of 0x03.

The last octet is the NLPID value of IP Protocol, equal to 0xCC.

The Frame Relay encapsulation is a full Frame Relay header that, when appended to the received raw IP datagram, creates a complete Frame Relay frame carrying IP.

The L2TPv3 side shows an encapsulation length of 24 bytes, because sequencing is not enabled and no L2-Specific Sublayer exists:

20 bytes of IPv4 header, including the following:

Version 4 Header Length 5 32-bit words

Protocol 115 (0x73) for L2TPv3

Source address 10.0.0.201

Destination address 10.0.0.203

4 bytes of L2TPv3 Session Header (0x0000269D):

32-bit Session ID of 9885

The second part of this scenario presents the PPP side of the L2TPv3 routed IW pseudowire from the New York PE, in which the local cross-connection is PPP-to-L2TPv3 (see Example 14-53).

Example 14-53. SSS Circuit Encapsulation for PPP IP-IW Using L2TPv3

New York#show sss circuits
Current SSS Circuit Information: Total number of circuits 4
!Output omitted for brevity
Common Circuit ID 0             Serial Num 4          Switch ID 18796712
---------------------------------------------------------------------------
Status  Encapsulation                                    
UP flg  len dump                                         
Y  AES  4   FF030021                                     
Y  AES  24  45000000 00000000 FF73A5F7 0A0000CB 0A0000C9 
         000058FA                                 
!Output omitted for brevity
New York#

You can see in the New York PE that the encapsulation length for the PPP side is 4 bytes, comprising a full PPP header, and contains the following:

Address of 0xFF

Control of 0x03

PPP DLL protocol number of 0x0021 for IPv4

Prepending this encapsulation to an IP packet that is received over the pseudowire creates a PPP frame to be sent out of the Serial 6/0 interface in the New York PE. The L2TPv3 side is equivalent to the analysis in the SanFran PE with mirror source and destination IP addresses and a different Session ID. The L2TPv3 encapsulation includes the following:

20 bytes of IPv4 header, including the following:

Version 4 Header Length 5, 32-bit words

Protocol 115 (0x73) for L2TPv3

Source address 10.0.0.203, destination address 10.0.0.201

4 bytes of L2TPv3 Session Header (0x000058FA): 32-bit Session ID of 22778

Figure 14-17 shows the encapsulations added in both the SanFran and New York PEs for this scenario in addition to the L2TPv3 encapsulation added to the carried PDU. The fields in gray represent the rewrite that has been described verbally.