Maximum Segment Size

Document created by cdnadmin on Jan 25, 2014
Version 1Show Document
  • View in full screen mode
This document was generated from CDN thread

Created by: Viktor S. Wold Eide on 22-05-2013 07:52:33 AM
Hi,

I just tested the CustomEncryption sample-app to send over some data (a small text file). The data is sent from one Linux computer to another, via two Cisco routers with an dpss_encdec OnePK application connected to each router. The TCP transfer stops almost immediately. It appears that some of the packets become to large, when sending non-interactive bulk data. When setting the Maximum Segment Size on the Linux computers to a lower value (e.g., 1300 bytes), TCP does not stop and the data is transferred completely. What is the recommended way for handling this?

Best regards
Viktor

Subject: Re: New Message from Viktor S. Wold Eide in onePK - Troubleshooting: Maximu
Replied by: Einar Nilsen-Nygaard on 22-05-2013 09:34:51 AM
Viktor,

At the moment the recommended way to handle it is to configure the way you have at the moment OR to ensure that the MTU on the path from the route sourcing the packets to where the dpss_mp is running is larger than the MTU of the interfaces the traffic you are diverting is passing through by about 200 bytes (to be safe). Just now the DPSS does not fragment packets, so packets larger than the MTU get dropped by the router. This will be addressed in subsequent releases, but the main initial deployment scenario for the DPSS is blade hosting (e.g. an SRE or UCS-E in an ISR-G2) where the MTU from the ISR to the blade can accommodate jumbo packets.

Cheers,

Einar

On May 22, 2013, at 1:52 PM, Cisco Developer Community Forums <cdicuser@developer.cisco.com<mailto:cdicuser@developer.cisco.com>> wrote:

Viktor S. Wold Eide has created a new message in the forum "Troubleshooting": -------------------------------------------------------------- Hi,

I just tested the CustomEncryption sample-app to send over some data (a small text file). The data is sent from one Linux computer to another, via two Cisco routers with an dpss_encdec OnePK application connected to each router. The TCP transfer stops almost immediately. It appears that some of the packets become to large, when sending non-interactive bulk data. When setting the Maximum Segment Size on the Linux computers to a lower value (e.g., 1300 bytes), TCP does not stop and the data is transferred completely. What is the recommended way for handling this?

Best regards
Viktor
--
To respond to this post, please click the following link: http://developer.cisco.com/web/onepk/community/-/message_boards/view_message/15483346 or simply reply to this email.

Subject: Re: New Message from Einar Nilsen-Nygaard in onePK - Troubleshooting: Re: N
Replied by: Viktor S. Wold Eide on 22-05-2013 10:52:27 AM
OK Einar,

Thanks for the quick reply. Maybe I missed something, but is the dropping
signaled / indicated to the application / user somehow?

By the way, regarding the dpss_encdec sample app, the TCP header length
might vary between systems. As I understand it, Linux by default adds TCP
header timestamps and the TCP header length is often not 20 bytes, but
rather 32.  Below is a one-liner patch, removing the hard-coded value.
For testing, header timestamps can be disabled in Linux by:
echo 0 > /proc/sys/net/ipv4/tcp_timestamps

Best regards
Viktor

diff -ur
/opt/cisco/onep/c32/sdk-c32-0.7.0.503g/c/sample-apps/CustomEncryption/src/dpss_encdec.c
./src/dpss_encdec.c
---
/opt/cisco/onep/c32/sdk-c32-0.7.0.503g/c/sample-apps/CustomEncryption/src/dpss_encdec.c
2013-04-02 08:05:47.000000000 +0200
+++ ./src/dpss_encdec.c 2013-05-22 17:04:54.318328577 +0200
@@ -173,7 +173,7 @@
     onep_dpss_pkt_get_payload_size(pak, &psize);

     rc = onep_dpss_pkt_get_l4_start(pak, &l4_start);
-    payload = l4_start + 20;
+    rc = onep_dpss_pkt_get_payload(pak, &payload);
     for(i = 0; i < psize; i++) {
             clr_c = *(payload + i);

Subject: Re: New Message from Viktor S. Wold Eide in onePK - Troubleshooting: Re: Ne
Replied by: Einar Nilsen-Nygaard on 22-05-2013 11:16:27 AM
Viktor,

Thanks for the info on TCP header.

I'm afraid the dropping is NOT signaled to the user today. This happens on the router as a function of the GRE packet sent by the platform DPSS code having the DF bit set and IOS dropping the packet.

Cheers,

Einar

On May 22, 2013, at 4:52 PM, Cisco Developer Community Forums <cdicuser@developer.cisco.com<mailto:cdicuser@developer.cisco.com>> wrote:

Viktor S. Wold Eide has created a new message in the forum "Troubleshooting": -------------------------------------------------------------- OK Einar,

Thanks for the quick reply. Maybe I missed something, but is the dropping
signaled / indicated to the application / user somehow?

By the way, regarding the dpss_encdec sample app, the TCP header length
might vary between systems. As I understand it, Linux by default adds TCP
header timestamps and the TCP header length is often not 20 bytes, but
rather 32. Below is a one-liner patch, removing the hard-coded value.
For testing, header timestamps can be disabled in Linux by:
echo 0 > /proc/sys/net/ipv4/tcp_timestamps

Best regards
Viktor

diff -ur
/opt/cisco/onep/c32/sdk-c32-0.7.0.503g/c/sample-apps/CustomEncryption/src/dpss_encdec.c
./src/dpss_encdec.c
---
/opt/cisco/onep/c32/sdk-c32-0.7.0.503g/c/sample-apps/CustomEncryption/src/dpss_encdec.c
2013-04-02 08:05:47.000000000 +0200
+++ ./src/dpss_encdec.c 2013-05-22 17:04:54.318328577 +0200
@@ -173,7 +173,7 @@
onep_dpss_pkt_get_payload_size(pak, &psize);

rc = onep_dpss_pkt_get_l4_start(pak, &l4_start);
- payload = l4_start + 20;
+ rc = onep_dpss_pkt_get_payload(pak, &payload);
for(i = 0; i < psize; i++) {
clr_c = *(payload + i);
--
To respond to this post, please click the following link: http://developer.cisco.com/web/onepk/community/-/message_boards/view_message/15492110 or simply reply to this email.

Subject: RE: Re: New Message from Einar Nilsen-Nygaard in onePK - Troubleshooting: R
Replied by: Joseph Clarke on 22-05-2013 01:48:27 PM
Viktor, thanks for the report.  When you were seeing drops, did you notice any error or drop counters incrementing on the GRE Tunnel interface on the router?

Subject: Re: New Message from Joseph Clarke in onePK - Troubleshooting: RE: Re: New
Replied by: Viktor S. Wold Eide on 23-05-2013 02:49:27 AM
Hi Joseph,

Yes, I could see that the drop counter on the GRE Tunnel interface on the
router was incrementing. I also could observe increase in errors and drop
from the following:

***************************
Before bulk transfer test:

OnePK-1#show cef dpss
VM Tport State                                                 Prt/Eth
Errors    SeqNum
1  GRE   up
   Local-addr:  10.0.226.11                                    0x8921
93        3643029
   Remote-addr: 10.0.226.21                                    0x8921
1         311
   Sticky errors: yes, Tunnel: Tunnel0, GRE handle: 0x115B998
   OCE: RAW midchain out of Tunnel0, addr 10.0.226.21 02520980
   Punt/Copy: 3639213/0, Reinject/Inject/Drop: 3604541/4366/124
   User ID: 2878
   Refcount: 3, Memory: 0x251F590

Errors: 2297
CFT FOs free/in use: 256/0, errors: 0
Reinject handles free/in use: 500/0, errors: 76
Encode/decode buffer size: 65665 bytes, memory: 0x1EF8BE8
OnePK-1#show ip cef switching statistics

       Reason                          Drop       Punt  Punt2Host
RP LES No route                         181          0        445
RP LES Packet destined for us             0      23266          0
RP LES TTL expired                        0          0      16488
RP LES Fragmentation failed, DF         326          0        386
RP LES Total                            507      23266      17319

All    Total                            507      23266      17319
OnePK-1#


*****************
After testing, TCP hangs without progress

OnePK-1#show cef dpss
VM Tport State                                                 Prt/Eth
Errors    SeqNum
1  GRE   up
   Local-addr:  10.0.226.11                                    0x8921
93        3643047
   Remote-addr: 10.0.226.21                                    0x8921
3         318
   Sticky errors: yes, Tunnel: Tunnel0, GRE handle: 0x115B998
   OCE: RAW midchain out of Tunnel0, addr 10.0.226.21 02520980
   Punt/Copy: 3639231/0, Reinject/Inject/Drop: 3604548/4366/124
   User ID: 2878
   Refcount: 3, Memory: 0x251F590

Errors: 2320
CFT FOs free/in use: 256/0, errors: 0
Reinject handles free/in use: 500/0, errors: 76
Encode/decode buffer size: 65665 bytes, memory: 0x1EF8BE8
OnePK-1#show ip cef switching statistics

       Reason                          Drop       Punt  Punt2Host
RP LES No route                         181          0        445
RP LES Packet destined for us             0      23305          0
RP LES TTL expired                        0          0      16493
RP LES Fragmentation failed, DF         335          0        389
RP LES Total                            516      23305      17327

All    Total                            516      23305      17327
OnePK-1#

Best regards
Viktor



2013/5/22 Cisco Developer Community Forums <cdicuser@developer.cisco.com>

> Joseph Clarke has created a new message in the forum "Troubleshooting":
> -------------------------------------------------------------- Viktor,
> thanks for the report.  When you were seeing drops, did you notice any
> error or drop counters incrementing on the GRE Tunnel interface on the
> router?
> --
> To respond to this post, please click the following link:
> http://developer.cisco.com/web/onepk/community/-/message_boards/view_message/15497165or simply reply to this email.

Subject: RE: Re: New Message from Einar Nilsen-Nygaard in onePK - Troubleshooting: R
Replied by: Joseph Clarke on 23-05-2013 10:49:28 AM
Thanks, Viktor.  Do you see any counters increment on the tunnel interface itself (i.e., "show int tunX")?  I am wondering if we can use an InterfaceStatistics listener to watch for this.

Subject: Re: New Message from Joseph Clarke in onePK - Troubleshooting: RE: Re: New
Replied by: Viktor S. Wold Eide on 24-05-2013 09:52:27 AM
Hi Joseph,

On the tunnel interface on the router I see the packets output and bytes
counters increment, but as far as I can see, not anything related to drop.
That is maybe not as expected?

Regards
Viktor

2013/5/23 Cisco Developer Community Forums <cdicuser@developer.cisco.com>

> Joseph Clarke has created a new message in the forum "Troubleshooting":
> -------------------------------------------------------------- Thanks,
> Viktor.  Do you see any counters increment on the tunnel interface itself
> (i.e., "show int tunX")?  I am wondering if we can use an
> InterfaceStatistics listener to watch for this.
> --
> To respond to this post, please click the following link:
> http://developer.cisco.com/web/onepk/community/-/message_boards/view_message/15539001or simply reply to this email.

Attachments

    Outcomes