Archive for the ‘Microsoft’ Category

Lack of Telnet Client in Windows Vista

March 23rd, 2009 1 comment

For the most part I will try to limit the number of “rants” on this Blog, but I have one I feel the need to share today (and I will even throw in a bit of helpful troublshooting advice).

Who in the world decided that removing the telnet *client* (not SERVER) from Windows Vista was a good idea?  As a network engineer I want to hunt that guy/gal down and give them a piece of my mind!  For crying out loud it is a 202KB executable file!

I could fully understand if we were talking about a *service* that had to load and run at boot that could represent a remote compromise opportunity, but no, we are talking about an extremely simple application that can simply open up a TCP connection to a remote host.

Windows Telnet Size

Windows Telnet Size

The worst part is that to install the Telnet client after the fact requires a number of clicks to drill down to wherever they hid the “Add/Remove Programs” control panel and then once you find and check the telnet client it takes like 20 minutes to install this 202KB file!

The reason this frustrates me so much is that if I am on a machine and I need to prove that I have TCP connectivity to something, the best way to do this is to simply type “telnet <ip or host> <port>” and hit enter.  I will immediately know if the remote host sent back a RST (connection denied), or if it connected (command terminal often will just be blank or the server could prompt something), or if it times out then the packets are getting lost somewhere.

Telnet Plunger Port 22

Telnet Plunger Port 22

Here you can see the result of the command above.  The connection opened successfully (as evidenced by the prompt clearing), and in this case SSH prompted the client with it’s version number.  You can press “ctrl-]” to drop to the telnet shell and enter “quit” to exit.

Telnet SSH Response

Telnet SSH Response

I use this extremely frequently when there is an access control list or firewall in the way that does not allow ICMP packets, or if I need to check if a port is open.  Also, I use this to prove “it’s not the network” when users complain of application issues and blame the network.  If I can open a TCP connection to their application server then that proves that round trip data flows between the devices are working.


Categories: Microsoft, Network Tags:

How To Configure Jumbo Frames

March 18th, 2009 17 comments

I have found there is a lot of confusion out there, as to how jumbo frames work, and in what circumstances they should be used.  Hopefully this post will be useful to others to avoid some of the pitfalls I have run into.

On your standard Ethernet network, the default frame size is 1500 bytes.  This can be notated in a number of different ways, however, since the actual amount of data sent is normally 1514 bytes which includes the source mac address (6 bytes), dest mac address (6 bytes), and protocol id (2 bytes), of the data in the frame (in most cases these days IP).  If you further include the 7 byte preamble, the 1 byte Start-of-Frame-Delimiter, and the 4 bytes of CRC32 at the end, you get 1526 (not to mention the 12 bytes of interframe-gap after transmission).  I have also seen it notated as 1518 bytes (1500 + 6 bytes src mac, 6 bytes dest mac, 2 bytes protocol id, and 4 bytes CRC 32).  When you run ifconfig on most operating systems it will show you 1500 bytes.  Within this “1500 byte frame” the usable space is further cut down to 1480 bytes by 20 bytes of IP header, and then if you are using TCP the data payload is cut down to 1460 bytes by another 20 bytes of TCP header.

Phew!  Was that enough numbers?  Now that we have that confusion out of the way, the question is why would you run something larger than 1500 bytes?  Well, back when the standard was set at 1500 byte frames we were not dealing with as large amounts of data as we are today.  Data transmission speeds were slower (i.e. 10 megabit) and the chances of encountering an error during the time it took to send a 1500 byte frame were much higher than sending a 1500 byte frame at gigabit speeds.  Keeping frames smaller meant you had to re-transmit less data when an error occurred.

As 100 megabit and then gigabit came out, the standards groups kept with the 1500 byte limit for backwards compatability.  This is great, except that when transferring large blocks of data (say during backups) this is less efficient than it could be since for every 1460 bytes of TCP payload data, you have 78 bytes worth of “time on the wire” that is used up.  You also force the computers at both ends of the connection to calculate a CRC-32 value for every 1460 bytes of data which is processor intensive (I am assuming you are not running a TOE), and also send ACK’s back etc…

So for certain applications you might want to consider running larger than 1500 byte mtu’s.  I recommend them only in the following circumstances:

  • You have an all gigabit network for the VLAN/network in question
  • All switches in your switching path can be configured to be “jumbo frame clean” up to the size frames you choose to use
  • You are sure all your host operating systems and NIC drivers will support Jumbo Frames at the size of frame you decide to use (this can vary a lot!) – note that I was once told that DataDomain boxes support jumbo frames, but they are not recommended because it causes a performance impact (this does not make sense to me, but it is what they said)
  • You have a real reason to need to run them (i.e. a backup VLAN or NFS VLAN)

Note that getting jumbo frames to work can be a real pain and in many cases is probably not worth it.  When you make the switch on a given subnet over to jumbo frames, you must simultaneously change *every* host on that network/VLAN or you will have weird problems where some hosts can talk to each other and others have difficulty for some types of connections.  TCP connections might work, but UDP connections fail intermittently (i.e. you can mount an nfs mount but when transferring files it fails).

As a side note, the reason that TCP will work on a MTU size mismatched network is that in the TCP 3 way handshake, a MSS (Maximum Segment Size) is specified by both ends of the connection and the smaller of the two is agreed upon.  Running different hosts on the same subnet with differing MTU sizes is *not* recommended.

So what size MTU should you choose?  Since there is no standard, different vendors have chosen to implement different maximum supported sizes.  I have seen drivers support all sorts of different mtu’s…  Some allow any mtu up to a max, while others support only several “canned” values (i.e. some Windows drivers).  From some research I have read, CRC-32 becomes ineffective above about 11,000 bytes.  I have found that every manufacturer I have used (that supports jumbo frames at all) will support 9000 byte MTU’s, therefore I highly recommend using 9000 byte MTU’s (this is also what is standardized on for Internet 2 traffic).

It is extremely important that your entire VLAN/network you are implementing this on be “Jumbo Frame Clean” for the size MTU you are using.  What I mean by this is that every switch in the path will allow at least 9000 byte mtu packets through.  Different switches have differing commands to make them pass jumbo frames.  In my Cisco 6500 series platforms I set the mtu on a per-port basis (depending on your Supervisor and OS version you might only have 9216 as an option which is fine as long as it is larger than your chosen mtu).  On my 3750’s (and similar stacking blade enclosure switches) I have to set it globally on the switch and reboot the switch to take effect.

Operating System Settings

To actually set jumbo frames in Windows you go to the device manager, select your NIC driver, go to the Advanced tab, and find the Jumbo frame setting.  You must either choose the correct MTU size from a drop-down list provided (in some drivers), or enter the correct frame size it into the box (if applicable).  You might need to verifiy with the manufacturer what number they are expecting here (does it include frame headers and footers?)

Here is an example of a NVIDIA NIC:

NVIDIA Jumbo Frame Settings in Windows

NVIDIA Jumbo Frame Settings in Windows

And here is an example of an Intel NIC.  Note that NVIDA lists it as 9000 bytes and Intel lists 9014, but my testing has shown these settings to be equivalent!  Also note that none of the other options align…  (except for 1500 bytes)

Intel Jumbo Frame Settings in Windows

Intel Jumbo Frame Settings in Windows

To set jumbo frames on Solaris, you must first figure out how to configure  your specific driver for jumbo frames, and then use ifconfig to set the interface to the specific frame size you decide on.


To test to make sure jumbo frames are working, you can use the following ping command from your Cisco switch (this is assuming that you have a layer 3 interface in the jumbo frame vlan and that L3 virtual interface is setup for your jumbo mtu size).

switch#show run int vlan 99               
Building configuration…

Current configuration : 190 bytes
interface Vlan99
 description backup
 mtu 9000
 ip address
 ip broadcast-address


switch#ping ip size 9000 df-bit

Type escape sequence to abort.
Sending 5, 9000-byte ICMP Echos to, timeout is 2 seconds:
Packet sent with the DF bit set
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/3/4 ms

You can also generate jumbo frames from Solaris boxes, but Solaris does not seem to support setting the “DF” (do not fragment) bit which is a shame since you might never know that the machine you are on fragmented the packet before it sent it, hence not actually testing jumbo frames…

bash-3.00# ping 9000 is alive

Windows boxes can send jumbo frame pings as well, but you must subtract out the 20 bytes of IP header and 8 bytes of ICMP header that it inserts in the size you specify.  They *do* support setting the DF bit.

C:\>ping -f -l 8972

Pinging with 8972 bytes of data:

Reply from bytes=8972 time=2ms TTL=255
Reply from bytes=8972 time=2ms TTL=255
Reply from bytes=8972 time=2ms TTL=255
Reply from bytes=8972 time=2ms TTL=255

Ping statistics for
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 2ms, Maximum = 2ms, Average = 2ms


There are a lot more details to everything we went through to implement jumbo frames on our backup networks, but this has hopefully given you the high level overview and a few key tips.


Categories: Cisco, Microsoft, Network Tags:

Getting DIG to work on Windows

March 14th, 2009 5 comments

As a network engineer, there are a number of tools that are absolutely critical to my job, that I use on a daily basis.  One of those tools named “dig”, is included as part of the BIND package from the Internet Systems Consortium (ISC).  For those not familiar with “dig”, it is a command line query tool used to troubleshoot DNS issues.

Due to my need to support a number of specialty applications, I run a Windows PC as my main work laptop.  This is unfortunate as Microsoft’s command line diagnostic tools (such as nslookup) are quite weak.  While I could SSH into a Linux/Solaris/whatever host each time I need to troubleshoot something, I often find myself on foreign networks with only my trusty laptop available.  A number of years ago I figured out how to get dig running on my Windows machines and have never looked back.

To run dig on a Windows box you could install the full windows version of BIND (which includes dig), but that is quite overkill if all you want is dig.  Instead, I recommend downloading the latest stable precompiled windows binaries of BIND, extracting the .zip, and then copying the files listed below into your c:\windows directory (really you could put them anywhere in your PATH but c:\windows is easy and I doubt the filenames will ever conflict).

  • dig.exe
  • libisc.dll
  • libdns.dll
  • libeay32.dll
  • libbind9.dll
  • libisccfg.dll
  • liblwres.dll

Voila!  You can now run dig from the command prompt!


; <<>> DiG 9.6.0-P1 <<>>
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 1886
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;                        IN      A

;; ANSWER SECTION:         14400   IN      A

;; Query time: 210 msec
;; WHEN: Sun Mar 15 00:05:54 2009
;; MSG SIZE  rcvd: 48


Categories: Microsoft, Network Tags:

How to view MTU size in Windows Vista

March 13th, 2009 No comments

It has always frustrated me that ipconfig /all in windows does not show me the currently active MTU size on a given adaptor (like it does in most OS’s).  Up until now I was not aware of any way to get this information (beyond maybe looking up the setting in the registry).

I just discovered the following command in Windows Vista (you have to be running command prompt as admin):

C:\Windows\system32>netsh interface ipv4 show subinterface

   MTU  MediaSenseState   Bytes In  Bytes Out  Interface
——  —————  ———  ———  ————-
4294967295                1          0      41533  Loopback Pseudo-Interface 1
  1300                1    7853050    1403618  Wireless Network Connection
  1300                5          0      23616  Local Area Connection
  1500                5          0          0  Bluetooth Network Connection

Note that my MTU sizes on my LAN and Wireless cards are 1300, because the Cisco VPN client is installed, and I believe it sets them low to avoid PMTU issues.

This command does not work in Windows XP or Windows Server 2003 as it complains that RRAS is not running (I suspect it would work if RRAS *was* running).


Categories: Microsoft, Network Tags: