cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
2898
Views
0
Helpful
14
Replies

857 & 877 / NAT STATIC: MTU BUG ? (836 & 878 ok)

osgpcqosg
Level 1
Level 1

Hi,

With the same 877 modem plugged in the same line.
  PVC configured with VC/MUX and PPPoA.
  We chose the PPPoA because we have 1500 Bytes MTU. (The PPPoE have a 1500-2-6=1492 MTU).
  IOS: Version 12.4(15)T10, RELEASE


If we put an "overload nat" we haven't any problem to ping without fragmentation:
   " echo 1 > /proc/sys/net/ipv4/ip_no_pmtu_disc;ping -M do -c 2 -s 1472 xxx.xxx.xxx.xxx"

But if we choose a "static nat", the mtu low to 1492 ! ???

   Nat change some ip mac port in the packet, allright,  but never will change the mtu size isn't it ?

Someone have the same issue ?

Someone as a idea the correct this ?

Best regards

PS: We have the problem with model:

  -857 "IOS: Version 12.4(15)T9" and "Version 12.4(15)T12 "

  -877 "Version 12.4(15)T10" modem

This ones are ok:

  -836 "IOS: Version 12.4(25c)"

  -878 "IOS Version 12.4(24)T4"

2 Accepted Solutions

Accepted Solutions

paolo bevilacqua
Hall of Fame
Hall of Fame

You should only make comparisons using the same exact IOS.

For example, load 12.4(24)T4 on the 877 and check again.

View solution in original post

One should always disable virtual-reassembly.

It's a buggy and practically useless feature that Cisco made default for heaven knows which reason.

View solution in original post

14 Replies 14

paolo bevilacqua
Hall of Fame
Hall of Fame

You should only make comparisons using the same exact IOS.

For example, load 12.4(24)T4 on the 877 and check again.

You're right, but in the other hand with the same version same router, a got a working and a not working configuration.

The change is only the way to do the nat.

Anyway I'll do the test with the same ios in the 877 between today or tomorrow.

So the 877 "IOS Version 12.4(24)T4"  work perfectly ! (edit the 20110118: Well the ping yes but the Wget still fail)

Now still have the problem with the 857 with the last IOS 124-15.T14

The hardware seems to be still supported, I'll open a ticket.

Thanks to https://supportforums.cisco.com/people/danicastro who help me with the IOS change to track down the problem.

Nikita Singh
Cisco Employee
Cisco Employee

When a device running NAT receives a packet from an internal client,  it replaces the packet header and translates the client's port number  and internal IP address to its own port number and external IP address. It does not change the MTU.


do u have to change the MTU on the interface to 1492 to make static nat to work ?

Is dynamic NAT for the same working fine.(Is it some application for which you are using this static NAT ?)

To test the configuration I do a ping directly in the router with a size of 1472 (1500 - 8 of icmp header).

For now to have a working configuration i use a mtu 1472 and a ip tcp adjust mss 1452.

I have the static nat already configured to "many" client router with a lot of unknow working applications.

Could try to change this but will take a lot of time...

I just change of old configuration from PPPoE to PPPoA, and I deleted the mtu and mss stuff for all the no VPN router (will try to clear this ones more later), and just found this strange lost of 8 bytes in the static nat so I put once again the mtu i mss stuff for this ones, waiting to find a another way to do with.

Hi,

Cisco call me about this problem.

The ios seems have problem with the ip virtual-reassembly tracker, and to solve the problem for now, we can desactivate it, like that:

interface vlan1
no ip virtual-reassembly
interface dialer 0
no ip virtual-reassembly

I'm waiting URLs for the full explaination.
And waiting too to know if a new ios release for this model will be under dev or not.
Regards.

One should always disable virtual-reassembly.

It's a buggy and practically useless feature that Cisco made default for heaven knows which reason.

Once again you're right !

The "ping -s 1472 -M do" was successful with the 878 BUT with a simple wget to download a kernel we have the same problem.

And yes the "no ip virtual-reassembly" works once again.

Thanks again

We have done some new test and the result here:

So without bug (with the test we have done ping and wget ones)

-836 "IOS: Version 12.4(25c)"

-877 "IOS: c870-advipservicesk9-mz.124-15.T13"

BUG list update:

-878 "IOS: c870-advsecurityk9-mz.124-24.T5"                    ping ok but wget fail

-878 "IOS: c870-advsecurityk9-mz.124-24.T4"                    ping ok but wget fail

-877 "IOS: c870-advsecurityk9-mz.124-24.T4"                    ping ok but wget fail

-877 "IOS: Version 12.4(15)T10"                                        ping fail

-857 "IOS: Version 12.4(15)T9" and "Version 12.4(15)T12 "  ping fail

Anyway for all version the "no ip virtual-reassembly" done the job and all work fine after.

Best regards.

Vince.

Some new about this problem, seems we have a MTU problem between us and the provider. I mean we have a upload 1500 Bytes MTU and a more download lower than 1500 Bytes MTU.

Anyway the problem is present in the ip virtual reassembly for a paquet more than 1472 Bytes so this is not the cause of the problem.

I use the so usefull way to capture the traffic on a router port, the IP Traffic export feature

http://www.cisco.com/en/US/docs/ios/12_3t/12_3t4/feature/guide/gt_rawip.html

And between the no ip virtual and the ip virtual case I found a little difference.

Between the WAN and the LAN, with the ip virtual case the data in the packet are changed in bytes 25 and 26.

WAN:

0020  48 54 54 50 2f 31 2e 31  20 32 30 30 20 4f 4b 0d   HTTP/1.1  200 OK.

0030  0a 44 61 74 65 3a 20 46  72 69 2c 20 30 38 20 4a   .Date: F ri, 08 J

0040  75 6c 20 32 30 31 31 20  31 33 3a 32 33 3a 35 31   ul 2011  13:23:51

0050  20 47 4d 54 0d 0a 53 65  72 76 65 72 3a 20 41 70    GMT..Se rver: Ap

0060  61 63 68 65 2f 32 2e 32  2e 31 36 20 28 44 65 62   ache/2.2 .16 (Deb

LAN:

0020  48 54 54 50 2f 31 2e 31  20 32 30 30 20 4f 4b 0d   HTTP/1.1  200 OK.

0030  0a 44 61 74 65 3a 20 46  ba c1 2c 20 30 38 20 4a   .Date: F .., 08 J

0040  75 6c 20 32 30 31 31 20  31 33 3a 32 33 3a 35 31   ul 2011  13:23:51

0050  20 47 4d 54 0d 0a 53 65  72 76 65 72 3a 20 41 70    GMT..Se rver: Ap

0060  61 63 68 65 2f 32 2e 32  2e 31 36 20 28 44 65 62   ache/2.2 .16 (Deb

Still have a ticket openend to cisco, wait and see...

Hi,

Cisco point me the problem:

With : "ip nat inside source static 10.0.0.2 xx.xx.xx.xx"  it's working.

But with: "ip nat inside source static 10.0.0.2 xx.xx.xx.xx  no-payload" we have the problem.

So nat static, with no "pay-load", with "ip virtual-reassembly" with packet > 1472, we have the problem.

Now i'am waiting for the correction .

Best regards.

I already test un new custom IOS witch solve this problem, but witch in the same time add some problem for example for DNS.

Have a new ticket for the new bug.

I will update.

Best regards

Hi,

Now I need to wait the new version to test it

Cisco answer:

"The bug CSCtt99073 now has a fix and the fix would be present in the IOS

versions 12.4(24)T7 and 15.2(1)T2. The IOS version 12.4(24)T7 would be

released on CCO on 03/16/2012 and 15.2(1)T2 on 02/17/2012."

Cisco Symptom:

"The checksum recalculation for the packet after NAT fixup is causing the corruption of data in the TCP or UDP packet."

Best regards.

Just check the IOS version 12.4(24)T7 and it's working fine.

paolo bevilacqua
Hall of Fame
Hall of Fame

Thanks for the nice rating, and good luck!

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community:

Review Cisco Networking products for a $25 gift card