This topic is to discuss the following lesson:
1 Like
Hi,
Is that purposely put in above under bandwidth listed as we are reading trouble shoot section?
10000Kbits (100Mbit) or my eyes playing tricks on:)
Hi Aaron,
What do you mean exactly? 
Rene
Hi Rene,
It’s says bandwidth is 10000Kits/sec 100Mbits but on sh int display it’s correct 10Mbits (half duplex)
while I’m here do you also divide delay by 10 on both serial and Ethernet? For example when doing redistribution.
Great site really helps me out a lot.
Thanks,
Aaron
Hi Aaron,
Glad to hear you like it!
I see it now, sorry for the confusion. In the example the FastEthernet was running in half-duplex / 10 Mbit. I just fixed this, it’s now showing the correct bandwidth and duplex.
When you configure delay you have to divide it by 10 yes:
R1(config)#interface GigabitEthernet 0/1
R1(config-if)#delay 1
R1#show interfaces GigabitEthernet 0/1 | include DLY
MTU 1500 bytes, BW 80000 Kbit/sec, DLY 10 usec
R1(config)#interface GigabitEthernet 0/1
R1(config-if)#delay 10
R1#show interfaces GigabitEthernet 0/1 | include DLY
MTU 1500 bytes, BW 80000 Kbit/sec, DLY 100 usec
Rene
Many thanks Rene!
A thankyou is less for this article . You are awesome !!
I was wondering if all “giants” are dropped on ingress if they are above the interface MTU? Or does the interface try to fragment the packet unless the DF bit is set? I’ve seen conflicting information on this on various sites. Some seem to state that they are dropped only if the FCS fails, some seem to provide proof that this is true.
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!
Laz
Hello Laz,
A few questions, what is the way to check if an interface is enabled for Jumbo frame? Is it a common practice to enable jumbo frame in a router? Does the application usually turn on DF bit? Would you give me a real life scenario where an application may turn on DF bit? Thank you so much.
Azm
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!
Laz
Hello Laz,
What happens to the IPSEC,DMVPN or MPLS packets?
Azm
In regards to MTU / fragmentation? If you allow fragmentation then these packets will get fragmented which is a bad thing.
For example, in MPLS if your router receives a labeled packet that it can’t forward out of an interface because of the MTU then it will:
* Strip the label(s)
* Fragment the IP packet (if the DF-bit is not set)
* Add the label(s) to all fragments.
* Forward all fragments.
Which is not very efficient 
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?
1 Like
Hello Brian,
From what I am reading what you want to do is possible, but not with the show interface command. I believe that what you need to do is turn on logging. I am attaching a Cisco forum post that might be helpful to you. I would like to try this in my GNS3 lab but I dont think I will be able to anytime soon. I hope this helps!
Thanks,
Scott Weller
1 Like
Hello Brian
There’s no counterpart command for Cisco that will tell you the last time an interface flapped. One solution is what Scott shared. Another is to make sure that logging is turned on and that you are logging at least severity level 3, because the LINK-3-UPDOWN syslog message you want to view is at severity level 3. Going through the syslogs and filtering for the specific interface in question, you will be able to see the events indicating the flapping of the interface.
I hope this has been helpful!
Laz
1 Like
I work for ISP so they probably have all the logging turned on. That is something that would be good addition to this website. using the show log command on cisco to find logs.
I know how to do it pretty decently on a Juniper just because I was shown in the last week and I have to use it a lot. We also have Cisco equipment but I have not worked as much with that yet as they start us out on the Juniper as its much easier to work with. I also hear Alcatel is easy but have not gotten to work with that much yet.
On side note I did login to ASR 9000 Series Cisco Router and it actually had the “last flap” Most of the other cisco though I have seen have been smaller devices and did not.
Hello Brian
Take a look at this search results page of lessons on the site:
https://networklessons.com/?s=syslog
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!
Laz
1 Like
Thanks will do.
This is first time I ever worked on configuration and trouble shooting from the ISP perspective so all knew I am like a baby but because its job and performance and stuff I am having to learn very fast.
I have always been biased towards Cisco I love cisco… I learn everything on cisco there is so much documentation out there on Cisco. I still love Cisco on smaller things but man I am really starting to love the Juniper MX Series like MX 950 as far as trouble shooting on devices that have a thousands of lines of configuration. Juniper has a “match” command and its on all the Juniper models. So when you use descriptions heavily you will be able to pull up anything you want as long as you label correct in first place. It seems much stronger than “include”
So just from search so far Juniper over all seems better at isolating what you are looking for. Cheaper Junipers can do this as well as top ends. I think Cisco its only big models like the asr9000 have similar power.
I will share more as I learn more as I said still a baby but this is how you learn by being thrown into the frying pan. all my cisco experience before this was just catalyst. I don’t even have all the names and models down as it was not important to me before but now models are starting to mean ability especially on the Cisco side. On Juniper their IOS is almost all same so that seems a plus. Take this with a grain of salt as I am just learning some things will change as I get better understanding.
Hello Brian
It’s great that you’re sharing your personal experience with us concerning Cisco and Juniper. It’s interesting to get a perspective on the types of similarities and differences that exist between the two vendors.
Keep up the awesome contributions and thanks once again!
Laz