[c-nsp] 6500 Sup720 high CPU load - RP LES Fragmentation unsupported

[Sukumar Subburayan]

On Mon, 4 Dec 2006, Bernhard Schmidt wrote:

> Sukumar Subburayan wrote:
>
> Hi,
>
>>> The physical ports (6704-10GE and 6748-GE-TX) are configured to MTU 9216 
>>> as well, but the SVI is configured to 1500 Bytes. I guess the size is not 
>>> checked on incoming packets on SVI.
>> 
>> OK, this makes sense. When MTU is configured to 9216 on the ingress, we 
>> will check to see if the packet is less than that on the input interface 
>> (the 6748-GE-TX linecard) and when we try to L3-switch the packet, we see 
>> the SVI interface is 1500 bytes. We probably are punting the packet to the 
>> RP for fragmentation.
>> 
>> Can you check to see if you configure 'mtu 9216' on your SVI interface, 
>> that the CPU comes down?
>
> The high CPU load is on the other box (ingress 10GE routed 9216 bytes, egress 
> L3 SVI 1500 bytes, L2 10GE-Trunk 1500 bytes). The box where the packet enters 
> the network (ingress L2 GE 9216 bytes, ingress L3 SVI 1500 bytes, egress 10GE 
> routed 9216 bytes) does not have any CPU issues. I would have expected it to 
> just drop the packets, but I guess MTU != MRU on Cisco (as long as you don't

Yes, I was going to send another email. In this scenario, we would not 
drop the packet, as in the ingress we check only on the physical port. 
For egress, we actually check the egress interface MTU programed in the 
adjacency for forwarding and then drop/punt to RP depending on DF-bit 
configuration and then finally do an egress L2-MTU check.

so, that is why the first router din't have a problem.

> hit hardware limits of course). We are talking about 1512 bytes IP (1530 
> Bytes Ethernet frame with FCS).
>
> Filer ----- Router ----- Router ----- Host
> MTU  L2 9216     L2/L3 9216   L2/L3 1500
>     L3 1500                ^ CPU-Load
>
> The inconsistent MTU configuration on the first router is definitely an error 
> (I don't know why it was configured that way), but it is not causing us any 
> issues at the moment. The fragmentation is happening at the second box.

It is not causing any issues, because we are not checking L3-MTU on 
ingress. We check L2-MTU on ingress & L3 & L2 MTU on egress.

> If I 
> increased the L3 MTU on the SVI on the first router the large packet would 
> still pass and need to be fragmented.
>

Yes, that is right. I wasn't sure about your exact configuration. In this 
case, you either have to fix your application or change the config on the 
box having high cpu to have higher mtu on the L3-interfaces, as well, so 
that we can L3-switch the packets in HW.

The fix for the bug I mentioned will help by bringing down the CPU-load as 
it will support fast-forwarding of fragmentation in CEF-path. But, it is 
still a good idea to fix the app.

> To remove the fragmentation I would have to set the L2 and L3 egress ports on 
> the second box to something larger, but the infrastructure behind these ports 
> is not entirely Jumbo-frames compatible.
>
> We will see what NetApp has to say about this.
>
>>> The traffic I've seen was incoming on WS-X6748-GE-TX. Interestingly there 
>>> are no giants listed on the interface in "sh int", but the giant counter 
>>> on the other router (where ingress is 10GE routed) is increasing. 
>>> Different IOS though.
>> 
>> There are some differences in the way 'giant's are reported on the 
>> linecards and particularly if the ports are configured as trunk-port vs 
>> switchport.
>> 
>> For ports configured as trunk ports, we will not report giant packets for 
>> packets upto the size of 1548 bytes.
>
> The interface reporting the giants is 10GE "no switchport" on 12.2(33)SRA, 
> the one not reporting is GE "switchport mode access" on 12.2(18)SXD6.
>

Maybe, we are not reporting Giants for 'switchport mode access' as well 
for packets upto 1548 bytes. This should have been the case only for trunk 
ports.


However,  > Regards,
> Bernhard
>