Hello,
When I receive the OID_SWITCH_NIC_CREATE oid, I save the mtu for the nic.
However, I can change the mtu with the netsh command:
“netsh interface ipv4 set subinterface <interface_name> mtu=<new_value>”
yet I receive no notification in NDIS about it (I expected a OID_GEN_MAXIMUM_TOTAL_SIZE or an OID_SWITCH_NIC_UPDATED to be sent).
It’s a hyper-v switch extension, if it matters to know.
Can anybody help? How can I get notified in the driver of the mtu change?
Thanks!</new_value></interface_name>
I don’t think you will be notified of any configuration change that applies
only to the TCPIP.SYS driver. Nothing has changed as far as the L2 stack.
This command just simply tells TCPIP.SYS to make believe the reported MTU is
something else.
TCPIP.SYS (nor any other protocol bound to a NIC) is obligated to say what
*it* thinks the logical MTU is on an adapter.
Why do you care what an upper protocol is going to use for MTU?
You need to support the characteristics of the link as reported by the NIC /
bridge-switch.
Good Luck,
Dave Cattley
Dave’s right. There is a concept of MTU at layer 2. Higher-level protocols like IPv4 or IPv6 may have their own concept of an MTU. The two are related only in that the layer-2 MTU is greater than or equal to the higher-level MTUs. (Which makes sense, if you think about it… IPv4 won’t have much luck sending packets if they get rejected by the local NIC.)
A higher-level MTU can be lower than the layer-2 MTU, if for example, an upstream router has a low MTU. For example:
[Your computer] -----1500MTU-----> [Router] ------1000MTU -----> [The internet]
In that example, you have a 1500 byte MTU at layer-2. But IPv4 and IPv6 will quickly discover that they need to constrain themselves to 1000 byte MTU if they want to actually do anything useful.
So the netsh command only configures IPv4 and IPv6 MTUs. The way to configure a layer-2 MTU is to look for a *JumboPacket keyword on the NIC. Set-NetAdapterAdvancedProperty.
Note that although our IP stack can change its layer-3 MTU on-the-fly, NDIS does *not* support changing the layer-2 MTU dynamically. So your NDIS filter driver will never need to worry about the MTU changing. Whatever MTU you get in NDIS_RESTART_GENERAL_ATTRIBUTES::MtuSize will stay the same.
Let’s see if I have this right:
The NIC tells my IM that MTU is 1500
The router can tell TCP/IP that MTU is 1000
nethsh cannot change MTU above 1000
Is this correct that my IM does not have to worry about MTU being above 1500?
Larry C
> The router can tell TCP/IP that MTU is 1000 nethsh cannot change MTU above 1000
I don’t know offhand if the admin is allowed to overrule the router’s MTU advertisement. There’s some extra logic in there, because our IP stack attempts to detect the MTU at runtime: if packets of length greater than N seem to be getting black-holed, then I think our IP stack will silently configure itself with N as the MTU.
Is this correct that my IM does not have to worry about MTU being above 1500?
Larry, you do have to worry a bit, because you’re making an IM driver. What if you add the first member NIC, it has an MTU of 1500, then the next member shows up with MTU 9000?
(In that scenario, I would just fail the addition of the second NIC and log an event saying “Dear administrator: we only support building MUXes over NICs with identical MTUs”.)
But beyond the multi-NIC thing, you don’t have to worry about NICs *changing* their layer-2 MTUs.
Customers buy our product which includes our requirements for HOW the network is setup, we have specific requirements for our nodes like no RSS, no jumbo packets and no offloads to the NIC. We are changing our rules as these “options” change. RSS did not seem to work before, XP, and now may work… it’s a question of testing which costs money but may improve performance. Damn bean counters!
One of the requirements that our NO enforces is that the NICs must be from the same vendor that we have qualified, thus the same MTU.
On the otherhand I remember, I’m not as close to the code as I use to be, we would change the attributes of the NIC being passed up for our own purposes… maybe not kosher or maybe effective, but we would also stop any offload on the way down. Belts & suspenders that may or may not work!
Sounds quite reasonable to me.
Thanks!
I was worrying that in a virtual environment the mtu could change (in a virtualized environment there should be no physical layer restrictions for mtu).
As for jumbo packets, if I enable jumbo frames, e.g. using powershell, then, Ipv4 / Ipv6 should change their mtu as well, so they can send bigger packets. Is there a way I can find out the jumbo frame setting / jumbo frame max size from within the kernel?
I am interested because, if I encapsulate a packet, I need to know whether the resulting size will be ok or not.
Thanks!
> Is there a way I can find out the jumbo frame setting / jumbo frame max size from within the kernel?
If you’re an NDIS driver bound to the NIC stack, you can look at NDIS_RESTART_GENERAL_ATTRIBUTES::MtuSize. Otherwise, if you’re not an NDIS driver, you can call GetIfEntry2 (or GetIfTable2Ex) and look at MIB_IF_ROW2::Mtu.