|
|
Advanced ATM Transport over L2TPv3The previous section covered PMTUD that applies to the transport of all Layer 2 protocols over L2TPv3. This section covers the transport and tunneling of ATM over L2TPv3. First you learn about ATM OAM local emulation mode for AAL5 CPCS-SDU Transport. Then you learn about ATM cell packing for cell relay (CR) over L2TPv3. Case Study 13-2: ATM OAM EmulationTwo operational modes exist for managing OAM cells in an AAL5 L2TPv3 pseudowire:
You can see a graphic representation of these two operational modes for OAM flows in Figure 13-5. Figure 13-5. Operational Modes for OAM Flows in L2TPv3
You might wonder when you would use ATM OAM local emulation. You can use OAM emulation to locally terminate or loop the OAM cells in two realistic scenarios:
In this case study, you will learn OAM emulation in L2TPv3 using the topology shown in Figure 13-6. Note that the VPI/VCI pair is different in both endpoints of the pseudowire. Figure 13-6. L2TPv3 OAM Emulation Topology
In AAL5 SDU L2TPv3 sessions, the VPI/VCI pair that makes up the attachment circuits for the PVCs can be different at both endpoints, as in Figure 13-6. However, such a scenario has a limitation: The VPI/VCI cannot be rewritten for cells that are transported over the AAL5 pseudowire. This limitation exists only for ATM cells that are transported over the AAL5 SDU pseudowire; it does not pose a problem for AAL5 SDUs that are transported over it. For successful transport of raw ATM cells (such as F5 OAM cells) over an AAL5 SDU pseudowire, the VPI/VCI pair needs to match at both ends. The only way of supporting OAM management of CE PVCs with different VPI/VCIs is by enabling OAM local emulation. With OAM local emulation, OAM cells are looped back or terminated and acted upon in the PE's attachment circuit. They are not transported over the pseudowire. Note When an L2TPv3 PE that is configured for OAM emulation receives an OAM cell indicating an alarm condition such as OAM AIS, a Set-Link-Info (SLI) message is triggered to notify the remote PE of the defect instead of tearing down the L2TPv3 session. This in turn triggers the generation of OAM alarm signals in the remote end of the L2TPv3 session and toward the remote CE. This achieves end-to-end alarm indication, maintaining the session as UP but alarmed. Example 13-29 shows the L2TPv3 sessions used in both the SanFran and NewYork PE devices. Example 13-29. OAM Emulation SessionsSanFran#show l2tun session circuit vcid 27 | begin Loc LocID TunID Peer-address Type Stat Username, Intf/ Vcid, Circuit 10314 22650 10.0.0.203 ATM UP 27, AT5/0:0/100 SanFran# NewYork#show l2tun session circuit vcid 27 | begin Loc LocID TunID Peer-address Type Stat Username, Intf/ Vcid, Circuit 38764 45445 10.0.0.201 ATM UP 27, AT5/0:0/101 NewYork# Now enable OAM PVC management in the Oakland and Albany PVCs with the command oam-pvc manage. Example 13-30 shows the configuration for the Oakland endpoint. Example 13-30. OAM PVC Management Configuration in the CEs
!
hostname Oakland
!
interface ATM6/0.1 point-to-point
ip address 192.168.103.1 255.255.255.252
pvc 0/100
oam-pvc manage
encapsulation aal5snap
!
The CE PVCs go into a DOWN state when OAM cells that are looped back are not received (see Example 13-31). Example 13-31. CE PVCs Go DOWN Without OAM-AC EmulationOakland#show atm pvc interface ATM 6/0.1 VCD / Peak Avg/Min Burst Interface Name VPI VCI Type Encaps Kbps Kbps Cells Sts 6/0.1 1 0 100 PVC SNAP 149760 N/A DOWN You can use the command show atm vc to display the OAM state and counters (see Example 13-32). Example 13-32. CE PVCs DOWN and OAM CountersOakland#show atm vc interface ATM 6/0.1 detail ATM6/0.1: VCD: 1, VPI: 0, VCI: 100 UBR, PeakRate: 149760 AAL5-LLC/SNAP, etype:0x0, Flags: 0xC20, VCmode: 0x0 OAM frequency: 10 second(s) InARP frequency: 15 minutes(s) Transmit priority 4 InPkts: 0, OutPkts: 0, InBytes: 0, OutBytes: 0 InPRoc: 0, OutPRoc: 0 InFast: 0, OutFast: 0, InAS: 0, OutAS: 0 InPktDrops: 0, OutPktDrops: 0 CrcErrors: 0, SarTimeOuts: 0, OverSizedSDUs: 0 Out CLP=1 Pkts: 0 OAM cells received: 0 OAM cells sent: 16 Status: DOWN The command show atm pvc presents enhanced statistics and counters, including the fact that the ATM PVC state is managed by OAM events (see Example 13-33). Example 13-33. CE PVCs DOWN and Enhanced OAM CountersOakland#show atm pvc 0/100 ATM6/0.1: VCD: 1, VPI: 0, VCI: 100 UBR, PeakRate: 149760 AAL5-LLC/SNAP, etype:0x0, Flags: 0xC20, VCmode: 0x0 OAM frequency: 10 second(s), OAM retry frequency: 1 second(s) OAM up retry count: 3, OAM down retry count: 5 OAM Loopback status: OAM Sent OAM VC state: Not Verified ILMI VC state: Not Managed VC is managed by OAM. InARP frequency: 15 minutes(s) Transmit priority 4 InPkts: 0, OutPkts: 0, InBytes: 0, OutBytes: 0 InPRoc: 0, OutPRoc: 0 InFast: 0, OutFast: 0, InAS: 0, OutAS: 0 InPktDrops: 0, OutPktDrops: 0 CrcErrors: 0, SarTimeOuts: 0, OverSizedSDUs: 0 Out CLP=1 Pkts: 0 OAM cells received: 0 F5 InEndloop: 0, F5 InSegloop: 0, F5 InAIS: 0, F5 InRDI: 0 OAM cells sent: 16 F5 OutEndloop: 16, F5 OutSegloop: 0, F5 OutAIS: 0, F5 OutRDI: 0 OAM cell drops: 0 Status: DOWN, State: NOT_VERIFIED Oakland# By comparing Example 13-32 and Example 13-33, you can see the difference in output between the old show atm vc command and the new show atm pvc command. The latter contains much more detailed information than the former. For OAM emulation to work effectively, you must enable it in both ends simultaneously. The L2TPv3 extensions for ATM pseudowires define the new OAM Emulation Required Attribute-Value Pair (AVP) to be used in AAL5 CPCS-SDU mode to signal OAM Emulation. OAM Emulation AVP is a boolean AVP that has no attribute value. Its mere presence or absence indicates a TRUE or FALSE value, respectively. If OAM cell emulation is configured or detected on one side, the other LCCE also must support it, which is the purpose of the OAM Emulation Required AVP signaling method. If the other LCCE cannot support the OAM cell emulation, you must tear down the associated L2TP session via a Call-Disconnect-Notify (CDN) message. Example 13-34 shows the command to enable OAM emulation in the SanFran PE. Example 13-34. Enabling OAM Emulation in the SanFran PE
interface ATM5/0
pvc 0/100 l2transport
oam-ac emulation-enable 2
encapsulation aal5
xconnect 10.0.0.203 27 pw-class pw-l2tpv3-atm
!
The rate in seconds at which OAM alarm indication signal (AIS) cells are sent follows the command oam-ac emulation-enable. Note After you enable OAM emulation with the oam-ac emulation-enable command, you can make the usual OAM Management commands such as oam-pvc manage available in the Layer 2 transport PVC. A Layer 2 transport PVC (attachment circuit) that has been configured for OAM emulation can periodically send OAM loopback cells toward the CE router and manage the Layer 2 transport PVC status based on the reply to those OAM loopback cells. At this point, you have enabled OAM emulation only at one endin the SanFran PE. As you have learned already in this section, this tears down the session with a CDN message because the OAM emulation value does not match at both ends. Examples 13-33 through 13-35 show the L2X debugs in the SanFran and NewYork PEs. The debugs that are enabled are debug vpdn l2x-errors, debug vpdn l2x-events, and debug vpdn l2x-packets. L2X means that the command is applicable to both Layer 2 Forwarding (L2F) and Layer 2 Tunnel Protocol (L2TP) protocols. Example 13-35 shows an Incoming-Call-Request (ICRQ) message that the SanFran PE receives. It has a pseudowire Type 2 for AAL5 SDU and a VC ID (end identifier) of 27. Example 13-35. Mismatch OAM-AC Emulation ConfigurationICRQSanFran#debug vpdn l2x-errors L2X protocol errors debugging is on SanFran#debug vpdn l2x-events L2X protocol events debugging is on SanFran#debug vpdn l2x-packets L2X control packets debugging is on SanFran# SanFran#show debugging VPN: L2X protocol events debugging is on L2X control packets debugging is on L2X protocol errors debugging is on SanFran# *Jul 6 18:27:26.792: Tnl56204 L2TP: Parse AVP 0, len 8, flag 0x8000 (M) *Jul 6 18:27:26.792: Tnl56204 L2TP: Parse ICRQ !Output omitted for brevity *Jul 6 18:27:26.792: Tnl56204 L2TP: Parse Cisco AVP 7, len 8, flag 0x8000 (M) *Jul 6 18:27:26.792: Tnl56204 L2TP: Pseudo Wire Type 2 *Jul 6 18:27:26.792: Tnl56204 L2TP: Parse Cisco AVP 6, len 8, flag 0x0 *Jul 6 18:27:26.792: Tnl56204 L2TP: End Identifier 27 !Output omitted for brevity *Jul 6 18:27:26.792: Tnl56204 L2TP: Parse AVP 47, len 10, flag 0x0 *Jul 6 18:27:26.792: Tnl56204 L2TP: L2 Specific Sublayer 2 The ICRQ message also includes the Layer 2-Specific Sublayer AVP specifying the ATMSpecific Sublayer with a value of 2. No OAM Emulation Required AVP is available because it has not been configured in the NewYork PE. Example 13-36 shows the Incoming-Call-Reply (ICRP) message in reply as received by the NewYork PE. Example 13-36. Mismatch OAM-AC Emulation ConfigurationICRPNewYork#debug vpdn l2x-errors L2X protocol errors debugging is on NewYork#debug vpdn l2x-events L2X protocol events debugging is on NewYork#debug vpdn l2x-packets L2X control packets debugging is on NewYork# NewYork# *Jul 12 06:19:12.309: Tnl65533 L2TP: Parse ICRP *Jul 12 06:19:12.309: Tnl65533 L2TP: Parse Cisco AVP 3, len 10, flag 0x8000 (M) *Jul 12 06:19:12.313: Tnl65533 L2TP: Local Session ID 12575 *Jul 12 06:19:12.313: Tnl65533 L2TP: Parse Cisco AVP 4, len 10, flag 0x8000 (M) *Jul 12 06:19:12.313: Tnl65533 L2TP: Remote Session ID 38123 *Jul 12 06:19:12.313: Tnl65533 L2TP: Parse Cisco AVP 7, len 8, flag 0x8000 (M) *Jul 12 06:19:12.313: Tnl65533 L2TP: Pseudo Wire Type 2 *Jul 12 06:19:12.313: Tnl65533 L2TP: Parse Cisco AVP 108, len 6, flag 0x0 *Jul 12 06:19:12.313: Tnl65533 L2TP: OAM Emulation Required *Jul 12 06:19:12.313: Tnl65533 L2TP: Parse AVP 47, len 10, flag 0x0 *Jul 12 06:19:12.313: Tnl65533 L2TP: L2 Specific Sublayer 2 *Jul 12 06:19:12.313: Tnl65533 L2TP: No missing AVPs in ICRP *Jul 12 06:19:12.313: Tnl/Sn65533/38123 L2TP: OAM Emulation Required AVP in ICRP contradicts with local config. Tearing down the session. From Example 13-36, you can see that the ICRP as received from NewYork contains a pseudowire Type 2 for AAL5 and the Layer 2-Specific Sublayer with a value of 2 for ATM. In addition, the ICRP contains the OAM Emulation Required AVP because it has been configured in the SanFran PE. The OAM Emulation Required AVP uses Cisco AVP 108 waiting for IANA assignment. Example 13-36 shows the mismatch of OAM emulation configuration detected in the NewYork PE. The NetYork PE tears down the session by sending a CDN message (see Example 13-37). Example 13-37. Mismatch OAM-AC Emulation ConfigurationCDNSanFran# *Jul 6 18:27:26.812: Tnl56204 L2TP: Parse CDN *Jul 6 18:27:26.812: Tnl56204 L2TP: Parse AVP 1, len 10, flag 0x8000 (M) *Jul 6 18:27:26.816: L2X: Result code(4): 4: Call failed, not enough resources (temporary) *Jul 6 18:27:26.816: Error code(0): No error *Jul 6 18:27:26.816: Tnl56204 L2TP: Parse Cisco AVP 3, len 10, flag 0x8000 (M) *Jul 6 18:27:26.816: Tnl56204 L2TP: Local Session ID 38123 *Jul 6 18:27:26.816: Tnl56204 L2TP: Parse Cisco AVP 4, len 10, flag 0x8000 (M) *Jul 6 18:27:26.816: Tnl56204 L2TP: Remote Session ID 12575 *Jul 6 18:27:26.816: Tnl56204 L2TP: No missing AVPs in CDN *Jul 6 18:27:26.816: Tnl/Sn56204/12575 L2TP: I CDN from NewYork tnl 65533, cl 38123 *Jul 6 18:27:26.816: Tnl/Sn56204/12575 L2TP: Destroying session *Jul 6 18:27:26.816: Tnl/Sn56204/12575 L2TP: Session state change from wait-connect to idle From Example 13-37, you can see that the SanFran PE receives the CDN that destroys the session. The CDN message contains the Result Code AVP (IETF AVP 1) as defined in RFC 2661, "Layer Two Tunneling Protocol 'L2TP.'" The result code of 4 indicates that the call failed because appropriate facilities were not available (temporary condition). Error code 0 specifies no general error. Because the L2TPv3 pseudowire is down, ATM OAM AIS cells are sent out of the attachment circuits toward the CEs. The CEs in turn reply with remote defect indication (RDI) OAM cells that the PE receives (see Example 13-38). Example 13-38. OAM AIS and RDI CellsSanFran#show atm pvc 0/100 ATM5/0: VCD: 3, VPI: 0, VCI: 100 UBR, PeakRate: 149760 AAL5 L2transport, etype:0xF, Flags: 0x30000C2E, VCmode: 0x0 OAM Cell Emulation: enabled, F5 End2end AIS Xmit frequency: 2 second(s) Interworking Method: like to like Remote Circuit Status = Undefined, Alarm Type = Undefined OAM frequency: 0 second(s), OAM retry frequency: 1 second(s) OAM up retry count: 3, OAM down retry count: 5 OAM Loopback status: OAM Disabled OAM VC state: Not Managed - AIS Xmitted ILMI VC state: Not Managed InPkts: 21, OutPkts: 0, InBytes: 1680, OutBytes: 0 InPRoc: 0, OutPRoc: 0 InFast: 0, OutFast: 0, InAS: 0, OutAS: 0 InPktDrops: 0, OutPktDrops: 0 CrcErrors: 0, SarTimeOuts: 0, OverSizedSDUs: 0 Out CLP=1 Pkts: 0 OAM cells received: 73 F5 InEndloop: 21, F5 InSegloop: 0, F5 InAIS: 0, F5 InRDI: 52 OAM cells sent: 52 F5 OutEndloop: 0, F5 OutSegloop: 0, F5 OutAIS: 52, F5 OutRDI: 0 OAM cell drops: 0 Status: UP SanFran# Oakland#show atm pvc 0/100 ATM6/0.1: VCD: 1, VPI: 0, VCI: 100 UBR, PeakRate: 149760 AAL5-LLC/SNAP, etype:0x0, Flags: 0xC20, VCmode: 0x0 OAM frequency: 10 second(s), OAM retry frequency: 1 second(s) OAM up retry count: 3, OAM down retry count: 5 OAM Loopback status: OAM Sent OAM VC state: AIS/RDI ILMI VC state: Not Managed VC is managed by OAM. InARP frequency: 15 minutes(s) Transmit priority 4 InPkts: 0, OutPkts: 0, InBytes: 0, OutBytes: 0 InPRoc: 0, OutPRoc: 0 InFast: 0, OutFast: 0, InAS: 0, OutAS: 0 InPktDrops: 0, OutPktDrops: 0 CrcErrors: 0, SarTimeOuts: 0, OverSizedSDUs: 0 Out CLP=1 Pkts: 0 OAM cells received: 52 F5 InEndloop: 0, F5 InSegloop: 0, F5 InAIS: 52, F5 InRDI: 0 OAM cells sent: 73 F5 OutEndloop: 21, F5 OutSegloop: 0, F5 OutAIS: 0, F5 OutRDI: 52 OAM cell drops: 0 Status: DOWN, State: NOT_VERIFIED Oakland# Example 13-38 shows that OAM emulation is enabled for the AAL5 Layer 2 transport pseudowire in SanFran. The SanFran attachment circuit has sent 52 AIS cells (F5 OutAIS) toward the Oakland CE because the L2TPv3 session is down, and it has received 52 RDI cells (F5 InRDI) from the Oakland CE. OAM AIS cells are equivalent to a blue alarm, and OAM RDI cells are equivalent to a yellow alarm. Consistently, the Oakland CE's PVC shows the receipt of 52 OAM AIS cells (F5 InAIS) from the SanFran PE, which resulted in 52 RDI cells (F5 OutRDI) generated toward the SanFran PE. The Oakland OAM PVC status is now DOWN because of AIS/RDI. To conclude the OAM emulation configuration, enable OAM emulation in the NewYork PE and verify that the L2TPv3 session comes up. The Oakland PVC receives end-to-end loopback cells and comes up (see Example 13-39). Example 13-39. Oakland CE PVC UPOakland#show atm pvc interface ATM 6/0.1 VCD / Peak Avg/Min Burst Interface Name VPI VCI Type Encaps Kbps Kbps Cells Sts 6/0.1 1 0 100 PVC SNAP 149760 N/A UP Oakland# Oakland#show atm pvc 0/100 ATM6/0.1: VCD: 1, VPI: 0, VCI: 100 UBR, PeakRate: 149760 AAL5-LLC/SNAP, etype:0x0, Flags: 0xC20, VCmode: 0x0 OAM frequency: 10 second(s), OAM retry frequency: 1 second(s) OAM up retry count: 3, OAM down retry count: 5 OAM Loopback status: OAM Received OAM VC state: Verified ILMI VC state: Not Managed VC is managed by OAM. InARP frequency: 15 minutes(s) Transmit priority 4 InPkts: 0, OutPkts: 0, InBytes: 0, OutBytes: 0 InPRoc: 0, OutPRoc: 0 InFast: 0, OutFast: 0, InAS: 0, OutAS: 0 InPktDrops: 0, OutPktDrops: 0 CrcErrors: 0, SarTimeOuts: 0, OverSizedSDUs: 0 Out CLP=1 Pkts: 0 OAM cells received: 162 F5 InEndloop: 9, F5 InSegloop: 0, F5 InAIS: 153, F5 InRDI: 0 OAM cells sent: 183 F5 OutEndloop: 30, F5 OutSegloop: 0, F5 OutAIS: 0, F5 OutRDI: 153 OAM cell drops: 0 Status: UP Oakland# Case Study 13-3: ATM Cell PackingThe second ATM advanced topic pertains to the cell transport over L2TPv3 (CRoL2TPv3). The cell packing feature, also called ATM cell concatenation, consists of packing or concatenating multiple ATM cells into a single L2TPv3 packet from a minimum of one cell (that is, no cell packing performed) to the maximum allowed by the MTU. Refer to Chapter 12 if you need a refresher about cell relay over L2TPv3. In contrast to OAM emulation, you can configure the cell packing feature independently in each endpoint using different values. You will learn to configure and verify cell packing using the topology shown in Figure 13-7. Figure 13-7. L2TPv3 ATM Cell Packing Topology
To configure cell packing, you must configure the maximum cell packing timeout (MCPT) timers in the main ATM interface. You have three different timers to pick from when configuring cell packing in the ATM port or all PVCs or PVPs within the physical interface. To configure these three timers, shut down the main interface (see Example 13-40). Example 13-40. Configuring MCPT TimersSanFran#conf t Enter configuration commands, one per line. End with CNTL/Z. SanFran(config)#interface ATM 5/0 SanFran(config-if)#shutdown SanFran(config-if)#atm mcpt-timers 100 1000 4095 SanFran(config-if)#no shutdown With the MCPT timers preconfigured in Example 13-40, you can enable cell packing in both the SanFran and NewYork PEs. The one mandatory argument is the maximum number of cells that can be packed (see Example 13-41). Example 13-41. Configuring Cell Packing! hostname SanFran ! interface ATM5/0 atm mcpt-timers 100 1000 4095 pvc 0/200 l2transport encapsulation aal0 cell-packing 14 mcpt-timer 3 xconnect 10.0.0.203 28 pw-class pw-l2tpv3-atm ! In Example 13-41, you have enabled cell packing for the pseudowire with attachment circuit, with VPI/VCI 0/200 in the SanFran PE specifying a maximum number of cells to be packed equal to 14 cells, and using the third preconfigured timer. Although you can configure a different value in the remote PE, you can also configure a maximum number of cells packed (MNCP) of 14 cells in the NewYork PE. The value of MNCP is signaled in the ATM Maximum Concatenated Cells AVP. MNCP indicates how many concatenated cells (maximum value) the LCCE node can process as a disposition capability. The values that are advertised in both directions do not need to match. Furthermore, the absence of this AVP indicates no cell packing. This AVP and cell packing in general apply only to ATM Cell Relay pseudowire types (see Example 13-42). Example 13-42. ATM Maximum Concatenated Cells AVP
SanFran#
*Jul 1 10:45:09.119: Tnl22650 L2TP: Parse AVP 0, len 8, flag 0x8000 (M)
*Jul 1 10:45:09.119: Tnl22650 L2TP: Parse ICRQ
!Output omitted for brevity
*Jul 1 10:45:09.123: Tnl22650 L2TP: Parse Cisco AVP 7, len 8, flag 0x8000 (M)
*Jul 1 10:45:09.123: Tnl22650 L2TP: Pseudo Wire Type 9
!Output omitted for brevity
*Jul 1 10:45:09.123: Tnl22650 L2TP: Parse Cisco AVP 11, len 8, flag 0x0
*Jul 1 10:45:09.123: Tnl22650 L2TP: ATM Maximum Number of cells that can be packed 14
*Jul 1 10:45:09.123: Tnl22650 L2TP: No missing AVPs in ICRQ
Example 13-42 shows the ATM Maximum Concatenated Cells AVP included in the ICRQ and using Cisco AVP 11. You can verify the configuration of ATM cell packing from the SanFran PE. See Example 13-43, which shows the local and remote MNCP values of 14 cells. Example 13-43. ATM Cell-Packing VerificationSanFran#show atm cell-packing average average circuit local nbr of cells peer nbr of cells MCPT type MNCP rcvd in one pkt MNCP sent in one pkt (us) ATM5/0 vc 0/200 14 0 14 0 4095 SanFran# As you know, each ATM cell carries 48 bytes of payload. When you concatenate 14 cells, you can carry an SDU of 48 bytes/cell * 14 cells = 672 bytes. You configured the Oakland and Albany CE's PVCs with AAL5-LLC/SNAP encapsulation, which means that an IP packet would have 16 bytes of encapsulation overhead as follows: 8 bytes of CPCS-PDU trailer plus 8 bytes of LLC/SNAP header. Therefore, the largest IP packet that you can fit into a single L2TPv3 Cell Relay packet that is concatenating 14 cells is 672 bytes 16 bytes = 656 bytes. To verify these calculations, send 100 656-bytes packets from the Oakland CE to the Albany CE. Then display the average number of cells sent and received per packet (see Example 13-44). Example 13-44. Optimal Cell-Packing UtilizationOakland#ping Protocol [ip]: Target IP address: 192.168.104.2 Repeat count [5]: 100 Datagram size [100]: 656 Timeout in seconds [2]: Extended commands [n]: Sweep range of sizes [n]: Type escape sequence to abort. Sending 100, 656-byte ICMP Echos to 192.168.104.2, timeout is 2 seconds: !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!! Success rate is 100 percent (100/100), round-trip min/avg/max = 96/98/108 ms Oakland# SanFran#show atm cell-packing average average circuit local nbr of cells peer nbr of cells MCPT type MNCP rcvd in one pkt MNCP sent in one pkt (us) ATM5/0 vc 0/200 14 14 14 14 4095 SanFran# You can see from Example 13-44 that the average number of cells sent and received in one packet equals 14 cells, which is the optimal usage for the pseudowire overhead. Consider what would happen if you used a slightly larger IP packet. See Example 13-45, which uses 657-byte packets. Example 13-45. Suboptimal Cell-Packing UtilizationOakland#ping Protocol [ip]: Target IP address: 192.168.104.2 Repeat count [5]: 100 Datagram size [100]: 657 Timeout in seconds [2]: Extended commands [n]: Sweep range of sizes [n]: Type escape sequence to abort. Sending 100, 657-byte ICMP Echos to 192.168.104.2, timeout is 2 seconds: !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!! Success rate is 100 percent (100/100), round-trip min/avg/max = 108/108/112 ms Oakland# SanFran#show atm cell-packing average average circuit local nbr of cells peer nbr of cells MCPT type MNCP rcvd in one pkt MNCP sent in one pkt (us) ATM5/0 vc 0/200 14 7 14 7 4095 SanFran# You can see in Example 13-45 that the average number of cells sent and received per L2TPv3 packet drastically dropped to 7 bytes. Each IP packet now needs 15 ATM cells; thus, it uses a first L2TPv3 packet with 14 cells and a second L2TPv3 packet with just 1 cell. The average equates to 7 cells per l2TPv3 packet. |
|
|
