From the configuration guide:
Frames sizes that can be received by the switch CPU are limited to 1998 bytes, no matter what value was entered with the system mtu or system mtu jumbo commands. Although frames that are forwarded or routed are typically not received by the CPU, in some cases packets are sent to the CPU, such as traffic sent to control traffic, SNMP, Telnet, or routing protocols.
But if it's received over a trunk it shouldn't be routed in the first place and even if it was the jumbo MTU should still apply.
Routed packets are subjected to MTU checks on the output ports. The MTU value used for routed ports is derived from the applied system mtu value (not the system mtu jumbo value). That is, the routed MTU is never greater than the system MTU for any VLAN. The routing protocols use the system MTU value when negotiating adjacencies and the MTU of the link. For example, the Open Shortest Path First (OSPF) protocol uses this MTU value before setting up an adjacency with a peer router. To view the MTU value for routed packets for a specific VLAN, use the show platform port-asic mvid privileged EXEC command.
Can you try this command:
show platform port-asic mvid
So it seems 1998 is max on SVI.
Am I right in saying that an Ethernet frame MTU is 1526 while the MTU
at the IP layer is 1500?
The Ethernet MTU is 1500 bytes, meaning the largest IP packet (or some other payload) an Ethernet frame can contain is 1500 bytes. Adding 26 bytes for the Ethernet header results in a maximum frame (not the same as MTU) of 1526 bytes.
Does the MTU change at each phase of encapsulation, or is the term
"MTU" only meant to define the maximum size of a packet at layer 3?
The MTU is often considered a property of a network link, and will generally refer to the layer 2 MTU. The limits at layer 3 are far higher (see below) and cause no issues.
The length of an IP packet (layer 3) is limited by the maximum value of the 16 bit Total Length field in the IP header. For IPv4, this results in a maximum payload size of 65515 (= 2^16 - 1 - 20 bytes header). Because IPv6 has a 40 byte header, it allows for payloads up to 65495. And IIRC using the Jumbo Payload header extension, IPv6 could allow packets up to 4 GB...
When setting up a TCP connection, a Maximum Segment Size (MSS) is agreed upon. This could be considered an MTU at layer 4, but it is not fixed. It is often set to the largest payload that can be sent in a TCP segment without causing fragmentation, thus reflecting the lowest layer 2 MTU on the path. With an ethernet MTU of 1500, this MSS would be 1460 after subtracting 20 bytes for the IPv4 and TCP header.
Best Answer
Regarding jumbo frame support on the Cat6k, IIRC the default system MTU size is 9216, but there are some modules where a maximum ingress frame size of only 8092 bytes is supported vs 9216 bytes (they'll drop frames larger than 8092 bytes at ingress). Double check the documentation to find out which modules exactly have this limitation.
Regarding the port-channels, if both ports in the port-channel are already set to the same MTU of 9216, it shouldn't make a difference if you configure the port-channel interface to have a 9216 MTU, but it wouldn't hurt for completeness'/clarity's sake in your configuration. You actually can't have two ports in an EtherChannel that have different MTU sizes.
Regarding the SVI's, there's really not much of a difference between routing jumbo frames across a routed L3 interface or an SVI (they're essentially the same thing) - just realize that if fragmentation is required across an L3 interface (ie a jumbo frame is routed from one L3 interface to another with a smaller MTU), the frame is punted to the CPU for fragmentation in software, and this can lead to problems. The rule of thumb here is to keep your jumbo frame traffic localized to other destinations/networks that also support jumbo frames.
While changing the MTU on the VLANs themselves shouldn't really be necessary, make sure that the interface MTU is the same across all the interfaces in the VLAN before setting the VLAN MTU to that same value. And similar to the port-channels, if you already have 9216 as the interface MTU's and the VLAN MTU for those interfaces, it shouldn't actually cause problems to set the MTU of the SVI for those VLANs to 9216.