I've been reading around in the forum trying to figure out what causes giants in an mpls enabled interface. We have a network running MPLS designed by Cisco and the recommendation regarding fragmentation is to set the mtu to 1550 to accomodate the extra labels. As I read through, most of the articles say that it should be mpls mtu. My questions regarding this are: 1.) Is setting the MTU to 1550 have the same to using the mpls mtu command to set some higher value to accomodate the labels? 2) Could this be the reason why we are seeing a lot of giants.
I'm posting the config of two neighbor routers and the equivalent show interface command. Hope you guys can enlighthen me. Thanks is advance. (I'm deleting some output which I think is not relevant)
Though just to follow up on the other question, regarding the giants, we have this on a lot of P-PE connections although there doesn't seem to be any input errors or drops. Some forum threads mention that it is normal in an mpls implementation. The only time i know giants can occur (other than hardware/software error) is when there are additional bytes in the header such as the case with trunks and mpls tags, but a lot of the documents say that giants are discarded by router. Do you think the mtu setting is causing this? Should we be concerned about this and try to eliminate it?
I remember we had a similar issue in our first MPLS implementations, after some mounths of deployment there were very high giants counters but no real issue for user traffic we explained this with the baby giants concept: packets are counted as giants but they are not discarded.
Our P and PE nodes were C7500 and C12000.
As you have written the baby giant concept is derived by additional overhead on trunk links and/or by MPLS overhead.
As far as user traffic is not affected by these counters you should be fine.
You can demonstrate it is not a real issue if you are able to send packets with IP size 1500 bytes within an MPLS VPN.
if an extended ping in VRF with 1500 bytes IP size packet is fine your network is working well.
There can be more overhead demanding scenarios for example carrying MPLS VPN packets inside a EoMPLS pseudowire or inside an MPLS TE tunnel so you may need to adapt the test to your specific environment.
We are pleased to announce availability of Beta software for 16.6.3.
16.6.3 will be the second rebuild on the 16.6 release train targeted
towards Catalyst 9500/9400/9300/3850/3650 switching platforms. We are
looking for early feedback from customers befor...
Introduction Featured Speakers Luis Espejel is the Telecommunications
Manager of IENova, an Oil & Gas company. Currently he works with Cisco
IOS® and Cisco IOS XE platforms, and NX to some extent. He has also
worked as a Senior Engineer with the Routing P...
In this session you can learn more about Layer 3 multicast and the best
practices to identify possible threats and take security measures. It
provides an overview of basic multicast, the best security practices for
use of this technology, and recommendati...