For the Intel Pro 1000 FreeBSD driver, this issue is listed:
"There are known performance issues with this driver when running UDP traffic with Jumbo Frames."
I wonder what impact his may have...
My gigabit switch supports jumbo frames. (one of those SMC units).
My m0n0wall box has one Intel 1000, and one fast ethernet card.
The Intel 1000 card is my "LAN" connection with an address of 192.168.10.1
The Fast ethernet card is my "OPT1" with an address of 192.168.20.1
Neither are bridged. I have a rule for OPT1 that is ANY (for everything) and a rule for LAN that's
ANY for everything. So nothing should be blocked by the router's firewall.
The Intel 1000 card in the router is connected to my gigabit switch. The Intel 1000 card has an
/sbin/ifconfig em0 mtu 9000 in the config settings. Switches the MTU to 9000 instead of 1500. OPT1
is still 1500.
Now traffic seems to flow fine minus one thing: RADIUS messages (UDP). I have an access point
functioning as a radius client on OPT1 and a radius server on LAN.
Most of the time the request doesn't even get sent and the access point complains that the server
doesn't respond. In this case there is no record in the Radius event viewer either. It's like it's
being dropped somewhere. Sometimes, the radius message gets passed but the Radius server says it's
not a valid message authenticator request and denies access. The access point then also complains
that the server doesn't respond.
How do I know this works in a different situation? Because if I switch all my gigabit cards to MTUs
of 1500 along with the router and stick the AP on the LAN network, then switch the IP of the AP as a
radius client on the radius server (the only change from 192.168.20.2 to 192.168.10.15), it works
Is what I'm doing a bad idea? I like the thought of jumbo frames as it lead to some higher
throughput and much lower CPU utilization, but not the radius thing. I think it's not just related
to radius but UDP in general.
Andy Choi Infinite
Labs - Owner
andy dash choi at infinitelabs dot net