[c-nsp] Re: 7200 MPLS MTU Issues

[mikus]

We ended up having to use "mtu <number>" under the interfaces - per
Cisco, it was the only way to get the asic's to increase mtu per bugs
associated to this across multiple platforms.  These were on the 6724
and 6748 sfp blades without DFC's currently.

You're right, if you globally set mtu's, you really don't need to use
"mpls mtu" commands, but this now affects routing protocols that
utilize mtu checks as part of their neighbor adjacency negotiations,
and might cause problems in multi-access ethernet segments where it
affects adjacencies with multiple devices simultaneously.  Some
interfaces don't allow universal interface mtu changes as well.  Plus,
there might be reasons you specifically do not want to allow gt 1500
mtu, and only wish to fix mpls traffic because of label stacking.  The
mpls mtu command is much more optimal for reconciling mtu issues
associated with mpls.

Now if only Cisco DE's would make it work properly on all platforms
and Q/A their software before unleashing it upon the world...  Typical
Cisco these days - take nothing at face value.

/me shrugs.

-mb


On Thu, 24 Mar 2005 00:06:46 -0800 (PST), Annu Roopa
<annu_roopa at yahoo.com> wrote:
> Hi Mikus, 
>   
> When u say "We saw issues with 67xx gige blades where it would ignore "mpls
> mtu", and were forced to change mtu on the interface to work around a bug." 
>   
> What cmd did u use on the interface then - "ip mtu". Does this take care of
> mpls labels in such a buggy situation. If it does then the Q is why do we
> need MPLS MTU ? Which cards were these 67 ??. 
>   
> Thanks,
> Annu. 
>   
>  
> 
>  ________________________________
> Do you Yahoo!?
>  Yahoo! Small Business - Try our new resources site! 
> 
>