NetScreen Admin MTU Setting and RST, Retransmissions & ICMP Type 3, Code 4 messages

May 18th at 12:00am

Last time I posted something it had to do with troubleshooting MTU mis-match issues using Wireshark. Today I'd like to post some clarity for administrators who have Juniper NetScreen devices somewhere in their network back-bone.

I spent a lot of time poring through books, blog posts and 'kb' documents to understand what the NetScreens in my environment were doing. The end result was that we were able to alter the configuration of one of the devices to resolve the MTU mis-match issue (ICMP Type 3, Code 4 and tcp retransmissions / RST packets captured via WireShark).

Reference

The single best resource available today for understanding NetScreen and ScreenOS is the O'Reilly book ScreenOS Cookbook. This is not a paid endorsement or 'referral' link- I just think this is one damn fine book that helped me IMMENSELY in my journey to understand all things NetScreen. If you are stuck supporting one (or more!) of these old devices, it makes a lot of sense to take a look.

MTU Configuration Fix for SSG-5, SSG-20 and SSG-320M

Something that was not clear to me when reading about these SSG NetScreen devices was how to change the MTU on an interface. I feel like the guy on this juniper forums thread (MTU Dilemma) [forums.juniper.net] as he describes his journey to understand this functionality. Every other online resource I found skipped over the command to set MTU and instead focused on commands to set the TCP MSS (which seems a bit indirect to me- I've got UDP packets, too...)

In a nutshell: The 'Admin MTU' setting that is visible [and editable] via Web UI and CLI controls the MTU of the physical interface. It has to be set in the range of 1280 to 1500 if you are going to customize it. By default it is set to '0' (which must mean the default of 1500).

During my deep-dive into our NetScreen configurations I found that the vast majority of interfaces had their 'Admin MTU' set to 0. In a few cases someone or some wizard or creation process had set the Admin MTU to 1500. For a long time I dismissed this as being a potential source of problems since, after all, it was set to the expected setting of '1500'.

It was one of my co-workers that cracked this final nut and let us put the MTU mis-match issue to bed (after I painted a landing strip and a map to the problem area, of course. :P ). He reset the Admin MTU back to 0 and we noticed our MTU mis-match issues went away for good.

(Obviously this doesn't make a ton of sense, but if you have reason to suspect MTU mis-match is an issue in your environment it would make sense to check your interfaces and sub-interfaces and ensure that Admin MTU is set to 0 [At least for a test!])

Additional Details on Changing Interface MTU

Something else I should note about Admin MTU: When you change this setting, the 'operating mtu' setting (visible via CLI) will change to match.

To change the MTU of an interface via CLI, use the command: set interface eth0/0 mtu <size_of_mtu>
(Be sure to change eth0/0 to a real interface on your device and <size_of_mtu> to something specific!)

So, here is what it looks like out of the box:

SSG-MyScreen-> get int eth0/0
Interface ethernet0/0:
description ethernet0/0
number 0, if_info 0, if_index 0, mode route
link down, phy-link down, admin status up
status change:0
vsys Root, zone Untrust, vr trust-vr
dhcp client disabled
PPPoE disabled
admin mtu 0, operating mtu 1500, default mtu 1500

And here is what it looks like after you set a specific MTU (in my case 1280):

Our configuration that DID NOT WORK:

admin mtu 1500, operating mtu 1500, default mtu 1500 **Note this does not work!