Friday, February 17, 2012

MTU Vs MSS - Part One

 Have you ever seen the below configuration and wondered what these commands do? And why the MSS value always seems to be 40 bytes lower than the MTU?

interface Dialer1
 ip mtu 1440
 ip tcp adjust-mss 1400


 Well, over the course of my next couple of blog entries, I plan to tell you all about them.

From my countless number of Google searches, the best information I could find was:
  • TCP MSS operates at Layer 4. It is 40 bytes lower than the IP MTU as it does not take headers in to consideration (20 byte IP and 20 byte TCP).
  • IP MTU operates at Layer 3. It is the maximum size a packet can be before it needs to be fragmented (or dropped if the df-bit is set).
  • Ethernet MTU (Layer 2) - 1500 bytes, excluding the header and trailer.
This is good information, but it doesn't tell you why you need to set both the MSS and the MTU.

Using Wireshark, and speaking with the helpful people over at Whirlpool, I was able to get a deeper understanding of how these two come together.

As the syntax of the command suggests, the "ip tcp adjust-mss" command only works for TCP connections. When applied to a router's interface, the router will monitor this interface's incoming and outgoing traffic, looking for SYN packets (which is where hosts define their MSS). When it sees a SYN packet, it will automatically change the MSS field to the size that you specified using the command above. When the receiving host receives the SYN packet, it will see the new MSS that was set by the router, and will reply with an MSS equal to or less than the one specified by the initiating host.

(Just to reiterate, as the router inspects both incoming and outgoing traffic, it doesn't matter whether the connection is initiated by a local host or a remote one, the SYN packet will still be altered).

Note: If the  "ip tcp adjust-mss" command is also set on the remote end of the connection, the lower MSS will be used.

To put it simply, the "ip tcp adjust-mss" command is used to prevent "blackhole routing".

By using this command, you can ensure that your packets are not being fragmented in transit. Fragmentation is far from ideal as it can lead to things like delayed packet delivery and packet drops.

Speaking of fragmentation, this is where the IP MTU comes in to play. When applied to an interface, the IP MTU basically states that packets leaving this interface need to be equal to, or less than the specified size. If they are larger, they will be fragmented. This is why the "ip tcp adjust-mss" command is necessary. By setting the MSS to 40 bytes below the MTU, you ensure that all of the packets sent from your network will not be fragmented by your routers.

Unfortunately though, setting the IP MTU and the MSS does not guarantee your packets won't be fragmented or dropped on their way to their destination. This is because each router your data passes on its way to the destination will be configured differently, and may have different MTU sizes on their interfaces.

If you find your having connectivity issues, there are tools you can use like mturoute.exe that will tell you the MTU of each hop between you and the destination network.

Finally, the Ethernet MTU. This is the MTU that your Layer 2 traffic uses. Setting this to a higher value (e.g 9000 bytes for Jumbo Frames) allows you to send more data per frame, meaning that you've got less overhead per packet. This enables you to deliver much larger amounts of data in shorter periods of time.

And that's it for this entry :) In my next blog post I'll delve deeper in to MSS and include some packet captures to demonstrate how it works.

Update: MTU Vs MSS - Part Two has now been published.

As always, if you have any questions or have a topic that you would like me to discuss, please feel free to post a comment at the bottom of this blog entry, e-mail at myciscolabsblog@gmail.com, or drop me a message on Twitter (@OzNetNerd).

Note: This website is my personal blog. The opinions expressed in this blog are my own and not those of my employer.

Friday, February 10, 2012

GNS3 IOS Memory Errors - Solution


In a previous post I talked about GNS3 memory errors that produced the below log messages when certain IOS images were used and NATing was enabled:

R1(config)#int fa0/0
R1(config-if)#ip nat inside
% NBAR ERROR: parsing stopped
% NBAR Error : Activation failed due to insufficient dynamic memory
% NBAR Error: Stile could not add protocol node
%NAT: Error activating CNBAR on the interface FastEthernet0/0
*Mar  1 00:00:27.307: %SYS-2-MALLOCFAIL: Memory allocation of 10260 bytes failed from 0x62912920, alignment 0
Pool: Processor  Free: 13696  Cause: Memory fragmentation
Alternate Pool: None  Free: 0  Cause: No Alternate pool
 -Process= "Exec", ipl= 0, pid= 94,  -Traceback= 0x61488C44 0x60015E58 0x6001BDB8 0x6001C410 0x636726CC 0x62912928 0x628F12D8 0x628F6E7C 0x628F25B4 0x628F7104 0x628F25B4 0x628F257C 0x628F4F90 0x628F25B4 0x628F2778 0x62925C0
*Mar  1 00:00:27.311: %NBAR-2-NOMEMORY: No memory available for StILE lmalloc,  -Traceback= 0x61488C44 0x62912944 0x628F12D8 0x628F6E7C 0x628F25B4 0x628F7104 0x628F25B4 0x628F257C 0x628F4F90 0x628F25B4 0x628F2778 0x62925C08 0x6293066C 0x6291D81C 0x6293ABBC 0x6293AF3C
R1(config-if)#
*Mar  1 00:00:27.863: %LINEPROTO-5-UPDOWN: Line protocol on Interface NVI0, changed state to up
*Mar  1 00:00:30.263: %AAA-3-ACCT_LOW_MEM_UID_FAIL: AAA unable to create UID for incoming calls due to insufficient processor memory


% NBAR ERROR: symbol addition
% NBAR ERROR: symbol addition
% NBAR ERROR: symbol addition
% NBAR ERROR: symbol addition
% NBAR ERROR: symbol addition
% NBAR ERROR: symbol addition
% NBAR Error : Activation failed due to insufficient dynamic memory
% NBAR Error: Stile could not add protocol node
%NAT: Error activating CNBAR on the interface FastEthernet0/1



Then, the following message would be displayed in the GNS3 Console:



=> *** Warning: ghostsize is to small for device R1. Increase it with the ghostsize option.


Well, thanks to an anonymous commenter, we now have a fix to the issue. Here is what they wrote:


I had this same thing. Here's how I fixed it quickly. Instead of upping RAM manually on all device, edit the .net file for your project and set the 'ram' parameter on the model as follows:

-------------------
[127.0.0.1:7200]
workingdir = /tmp
udp = 10000
[[3745]]
image = /downloads/c3745-advipservicesk9-mz.124-15.T14.bin
ram = 256
idlepc = 0x60bc1748
ghostios = True
-------------------

now all devices you create from that model will have the same ram setting. seems to have cleared it up the issue for me anyway...



Looking at the other comments that were posted after the above one, it seems to be resolving the issues for others too.

Thanks to the anonymous commenter and to the others for letting us all know that it worked for you too! :)


As always, if you have any questions or have a topic that you would like me to discuss, please feel free to post a comment at the bottom of this blog entry, e-mail at myciscolabsblog@gmail.com, or drop me a message on Twitter (@OzNetNerd).

Note: This website is my personal blog. The opinions expressed in this blog are my own and not those of my employer.