New Undocumented 12.4(20)T Feature
There is a nice new feature in 12.4(20)T that I do not believe is listed in the New Feature Documentation for that code. In IOS, by default the interface MTU on all ISR’s with onboard GE/FE interfaces is set to 1518 bytes prior to 12.4(20)T. This would allow you to carry a maximum Layer 3 payload of 1500 bytes with an additional overhead of 18 bytes to accommodate for the Layer 2 Ethernet encapsulation. There are some instances however where the default maximum interface MTU gets extended automatically to accommodate the additional overhead appended due to enabling of extra services on the interfaces. For instance when enabling 802.1q trunking the interface MTU size gets extended to 1522 bytes to transfer the additional 4 byte VLAN tag along with the frame size 1518 bytes.
Some of you may be aware of the differences, but for those you who are not let’s examine the differences between two different yet sometimes assumed to be the same command. The command “ip mtu” under interface configuration mode is used to configure the Layer 3 IP payload of the Ethernet frame up to 1500 bytes. The IP payload cannot exceed 1500 bytes though you are allowed to reduce the size based on the services enabled on the interface.
The purpose of the “mtu” command under interface configuration mode is used to configure the interface MTU which includes both layer 3 and layer 2 payloads . Now although the “mtu” command is available under the FE interfaces in IOS prior to 12.4(20)T, you are not allowed to modify the range. In fact the IOS would/will prompt you with an error when you attempt to modify the value. Let’s take a look at what happens when you attempt to modify the MTU on the FE interface of an 1841 running 12.4(15)T5 IOS:
CCIE6200-1841#sh ver
…
Cisco IOS Software, 1841 Software (C1841-ADVIPSERVICESK9-M), Version 12.4(15)T5, RELEASE SOFTWARE (fc4)
…
ROM: System Bootstrap, Version 12.3(8r)T9, RELEASE SOFTWARE (fc1)
CCIE6200-1841 uptime is 14 minutes
System returned to ROM by reload at 07:40:32 CDT Fri Jul 25 2008
System image file is “flash:c1841-advipservicesk9-mz.124-15.T5.bin”
…
Cisco 1841 (revision 6.0) with 354304K/38912K bytes of memory.
Processor board ID ********
2 FastEthernet interfaces
1 Virtual Private Network (VPN) Module
1 802.11 Radio
DRAM configuration is 64 bits wide with parity disabled.
191K bytes of NVRAM.
125440K bytes of ATA CompactFlash (Read/Write)
…
!
!
!
CCIE6200-1841# config t
Enter configuration commands, one per line. End with CNTL/Z.
CCIE6200-1841(config)#int fast0/1
CCIE6200-1841(config-if)#mtu ?
<64-17940> MTU size in bytes
CCIE6200-1841(config-if)#mtu 1584
% Interface FastEthernet0/1 does not support user settable mtu.
CCIE6200-1841(config-if)#
!
Ok so you can’t change the MTU, what’s the big deal with modifying it anyway or why would you want to change it in the first place? Well that’s a great question. As you look to enable Layer 2 types of VPN’s, for instance EoMPLS, without being able to modify the MTU of the interface it is not possible to transfer a maximum Layer 3 payload of 1500 bytes along with the additional feature specific overheads enabled and you are forced to lower the IP MTU to a value that will accommodate the IP Payload + Layer 2 Overhead + MPLS Labels + Control Word + Additional Layer 2 Overhead Again by the PE. You see fragmentation of IP payload is not permissible in an EoMPLS scenario so you have to basically pre-determine the maximum IP payload accommodating the additional overheads noted above and configure “ip mtu’ on the router accordingly. Let look at this in more detail…
So if we have a basic EoMPLS network with the following devices CE-R1 –>PE-R2–>PE-R3–>CE-R4, now imagine a packet flow from CE-R1 to CE-R4 in order to accommodate all the overheads added to the packet as it moves across these devices, in essence what you are having to do is back down the IP Payload (IP MTU) at the CE-R1 router so that all that additional overhead can be added at PE-R2 and still not exceed the MTU value at the PE-R2.
So in order to overcome the constraint of not being able to carry the maximum IP payload of 1500 bytes with features such as EoMPLS enabled, with 12.4(20)T you are now permitted to adjust the interface MTU to the maximum of 1600 bytes to accommodate the additional headers appended on the core facing interface of the PE routers (like PE-R2 in our example) using the “mtu” command in the interface configuration mode. Let’s take a look at what happens now when you attempt to modify the MTU on the FE interface of the same 1841 now running 12.4(20)T IOS:
CCIE6200-1841#sh ver
…
Cisco IOS Software, 1841 Software (C1841-ADVIPSERVICESK9-M), Version 12.4(20)T, RELEASE SOFTWARE (fc3)
…
ROM: System Bootstrap, Version 12.3(8r)T9, RELEASE SOFTWARE (fc1)
CCIE6200-1841 uptime is 2 minutes
System returned to ROM by reload at 07:48:55 CDT Fri Jul 25 2008
System image file is “flash:c1841-advipservicesk9-mz.124-20.T.bin”
…
Cisco 1841 (revision 6.0) with 355328K/37888K bytes of memory.
Processor board ID ********
2 FastEthernet interfaces
1 Virtual Private Network (VPN) Module
1 802.11 Radio
DRAM configuration is 64 bits wide with parity disabled.
191K bytes of NVRAM.
125440K bytes of ATA CompactFlash (Read/Write)
…
!
!
!
CCIE6200-1841#config t
Enter configuration commands, one per line. End with CNTL/Z.
CCIE6200-1841(config)#int fast0/1
CCIE6200-1841(config-if)#mtu ?
<64-1600> MTU size in bytes
CCIE6200-1841(config-if)#mtu 1584
CCIE6200-1841(config-if)#do sh run | sec in interface FastEthernet0/1
interface FastEthernet0/1
description **** Internal DMZ ****
mtu 1584
duplex auto
speed auto
no mop enabled
CCIE6200-1841(config-if)#

Comment by Nikolay Shopik on 25 July 2008:
Pretty interested findings. I wounder about jumbo frames (never used it still though). Its only supported on Gigabit links with routers?
Comment by test on 9 August 2008:
fyi
working for Gi intrefaces:
C3845 Mother board 1GE(TX,SFP),1GE(TX) and
NM-1GE Port adapter;
Unfortunately, it is not working for
NM-2FE2W_V2 Port adapter.
12.4(20+)T
Comment by Joe Harris on 10 August 2008:
That’s the correct behavior, this is only available for the onboard built-in interfaces, not for the NM or WIC based interfaces.