Notable Replies

  1. Hello James!

    If you have an MTU of 1500 set on a port, then any frame that attempts to ingress on this port that is larger than 1500 bytes will be dropped. If the port is set up to accept larger frames, then it will accept them. As for the FCS, if a frame is smaller than the MTU size that has been configured (either jumbo or not) it will be dropped if the FCS fails regardless of size.

    Note that the DF bit is on the Network Layer, that is, in the IP header. This bit tells the SENDER weather or not the IP packet can be fragmented during encapsulation. Let’s say a PC is encapsulating part of an email being sent. Say the IP packet is 1700 bytes and it is being encapsulated from layer 3 to layer 2 and the DF bit is set to 0 (allowed to be fragmented). The MTU of the NIC of the PC is set to 1500 bytes. The PC will split the IP packet into two, put one portion in one frame of less than 1500 bytes and the other portion in the next frame of less than 1500 bytes. Notice that the DF bit only plays a role at the SENDER. When this frame reaches the port of a switch, it will blindly check the size, and if it is too big, it will drop it. This is why it’s important that MTU be the same on both ends of a link. (I’ve had to learn this the hard way troubleshooting strange behaviour between two sites for almost two days, where some data goes through and some does not, seemingly at random!!)

    Now if the DF bit was set to 1, then the encapsulation would not occur at all at the PC, and the sending would fail. This once again shows how the DF bit has to do with encapsulation at the SENDER.

    I hope this has been helpful!


  2. Hello Azm

    This depends on the platform. On the 3750 for example, the MTU cannot be changed on an individual interface, but is implemented globally. On the higher end catalyst switches (4500, 6800 etc) and always depending on the supervisor and IOS used, you can configure it on a per interface basis. In either case, you can verify the MTU on aper interface basis by using the show interfaces command. For example:

    7609#show interfaces gigabitEthernet 1/1 
    GigabitEthernet1/1 is up, line protocol is up (connected) 
      Hardware is C6k 1000Mb 802.3, address is 0007.0d0e.640a (bia 0007.0d0e.640a) 
      MTU 9216 bytes, BW 1000000 Kbit, DLY 10 usec, 
      reliability 255/255, txload 1/255, rxload 1/255

    Notice the MTU size is well above the normal 1500 bytes, so this port is configured to allow for jumbo frames.

    Another useful command is the following:

    Switch# show system mtu
    System MTU size is 1546 bytes
    System Jumbo MTU size is 9000 bytes

    Here you can see that the jumbo MTU size has been configured to 9000 bytes. This essentially means that all ports have been configured to accommodate jumbo frames. More information on jumbo frames can be found here.

    There are situations where you require the increase in MTU size. One situation where I have come across it is on a metropolitan area fibre optic network. This network interconnects multiple organisations and connects them to a common connection to the Internet. Because QinQ is being used (which uses additional bits in the frame and increases its size beyond 1500 bytes to add a second VLAN tag) in order to send multiple client VLANs over single MAN VLANs, the MTU is raised up to well above the 1500 mark to accommodate all sizes of frames as well as to provide for more efficient transmission and the elimination of any possible fragmentation.

    Whether or not you have jumbo frames does not directly affect the DF bit. If jumbo frames are accommodated, then even if the DF bit is set, it is unlikely that any fragmentation will occur, because it is not necessary. Whether or not the DF bit is set depends strictly on the application being used. Situations where the DF bit is used is in Path MTU discovery as well as in situations where overhead must be avoided. Fragmentation generally adds CPU resource overhead as well as data overhead (in the form of additional headers needed for each fragment).

    I hope this has been helpful!


  3. How do you tell the last time a Cisco Interface flapped?

    Working at ISP I would say a majority is Juniper on a Juniper it actually has “Last Flapped” gives date and time. This is very useful because customer often ask for RFO (reason for outage) You can check interfaces to see last time it flapped. Then you can drill down into logs for the actual reason.

    I was surprised not to find something like this for Cisco?

  4. Hello Brian

    Take a look at this search results page of lessons on the site:

    It gives a list of several topics concerning syslog for both IOS devices as well as ASA firewalls. You might find some additional helpful information there.

    Thanks for sharing the last flap command on the ASR 9000 series devices, it’s good to know.

    As you get more familiar with Cisco, please share with us your thoughts concerning how Cisco compares with Juniper, Alcatel and other vendor devices as far as ease of configuration and use goes, it would be interesting to hear your experience…

    I hope this has been as helpful for you as it has been for us!


  5. Thanks Rene. The 8-bit value explanation makes sense.

Continue the discussion

17 more replies!