Charles,
I asked one of our Engineers to clarify on Large Packet Support On Linux
Routers and VLAN vs IPSEC.
Here is his response.
Vlan is level two information. A VLAN packet has a different type in
the Ethernet header, which is read by the card driver. So a VLAN aware
driver will allow a packet which physical size is 1518 bytes long (1500
bytes of payload + 2*6 of ethernet address + 2 bytes of type/len + 4
bytes VLAN extra info) instead of the normal 1514.
On the other hand, IPSec (more precisely ESP and AH) are IP protocols.
I.e. the ethernet drivers knows nothing about it. And an IPSec packet
can be transported in an ethernet packet, a vlan packet or over a ppp
connection. It is IP. Plus, the overhead of IPSec is a lot more than 4
bytes, more 40 bytes or so, but I don't remember the exact value.
So my recollection is as followed:
- the unpatched drivers on our Linux box were dumb and would simply
drop packets that where too big.
- the starOS has unpatched drivers but drops to 1496 the MTU of the
VLAN interface so that no extra large packet would be generated at the
ethernet interface. It works and is correct, but not the behavior we
were looking after, only if all devices agree to this behavior and it
doesn't mimic the capability of VLAN switches.
- the patched drivers (RapidDSL Router Code) and Mikrotik drivers, although
they display a MTU
of 1500, will accept larger packets to accommodate VLANs.
The fact that you cannot change the MTU in Mikrotik doesn't mean that I
doesn't pass properly the VLAN packets. Many VLANs are setup all over the
place over our Mikrotik routers and RapidDSL routers, and to the best of my
knowledge, it works properly.
But this has no bearing on IPSec. This is a different ball games. And
that's why I was asking the question: what is it for? To create tunnels
for you and they need to have 1500 MTU? Or to create tunnels for the
customers and it is then a non-issue: they'll have to deal with the
lower MTU size of the IPSec tunnel and most of the time it just works
(thanks to path MTU discovery).
To clarify. The MTU is only the size of the payload. It doesn't take
into account the Ethernet header. Of course, the IP header, TCP/UDP
header, etc. are considered payload for ethernet and indeed counted in
the ethernet payload.
There are two MTU to consider. The MTU of the underlying ethernet
interface and the MTU of the VLAN interface itself. The second MTU is
the "effective" MTU, the one seen by application, networks, using this
interface. The first MTU is the one of the hardware interface.
The trick used by StarOS is to reduced the "effective" MTU. Therefore,
gaining 4 bytes off the payload to expand the header into it, without
the underlying interface having to be aware of it. If it was possible,
leaving the effective MTU at the same value and increasing the
underlying interface MTU by 4 bytes would have the same effect.
The proper VLAN aware drivers show 1500 MTU for both the underlying
interface and the VLAN interface, but it treats VLAN packets with
caution, so as not to truncate or drop them because of their longer
size.
On some places on our network (Reston) I could only "ping -s 1470
IPaddres", because any higher ping wouldn;t work.
Actually, if 1470 works, so should 1471 and 1472. The size in the ping
command is the payload of the ping packet. So the actual size of the IP
packet is this size plus the icmp header (8 bytes) and the IP header
(20 bytes). 1472 + 20 + 8 = 1500. If you have a VLAN issue, it will cut
off at 1468, 1472 - 4 extra bytes of the VLAN tagging.
But at Dulles, I tried " ping -s 9600 IPaddres" and the pings
returned. There is no way the Ethernet devices would pass 9600 byte
packets would they?
ICMP traffic is IP traffic, and as such can go through IP fragmentation
(http://www.geocities.com/siliconvalley/vista/8672/network/
ipfrag.html). But some dumb device with a limited IP stack
implementation will not support IP reassembling, especially on ICMP
traffic. For example, at Dulles, pinging su-peter-knob with -s 1753
fails but pinging ap-wifi-peter-knob works. Note that the ap is Linux
based, and hence has a full network stack, and the su (Teletronics) is not.
I know the gigabit ports would, but not the Mikrotik 100mbps ports?
So I'm not even sure how to test :-)
You have to prevent or detect fragmentation to know what's going on.
With ping, the option '-M do' will set the DF flag (don't fragment).
The test is to see that without fragmentation, you can ping with '-s
1468' and not with '-s 1472'. This would indicate a VLAN MTU issue.
Sniffing with tcpdump, where appropriate, is also very informative. In
particular look at the flags: [DF] means that the don't fragment flag
is set, [+] means that the more fragment to come flag is set (i.e. the
message is fragmented). Examples:
# sudo tcpdump -i eth4 -l -n -v icmp
tcpdump: listening on eth4, link-type EN10MB (Ethernet), capture size
68 bytes
19:05:27.714176 IP (tos 0x0, ttl 64, id 12940, offset 0, flags [DF],
length: 1500) 10.0.162.1 > 10.0.162.3: icmp 1480: echo request seq 0
19:05:27.761057 IP (tos 0x0, ttl 32, id 56852, offset 0, flags [DF],
length: 1500) 10.0.162.3 > 10.0.162.1: icmp 1480: echo reply seq 0
19:05:43.667823 IP (tos 0x0, ttl 64, id 62485, offset 0, flags [+],
length: 1500) 10.0.162.1 > 10.0.162.3: icmp 1480: echo request seq 0
19:05:43.667834 IP (tos 0x0, ttl 64, id 62485, offset 1480, flags
[none], length: 21) 10.0.162.1 > 10.0.162.3: icmp
19:05:44.665582 IP (tos 0x0, ttl 64, id 52822, offset 0, flags [+],
length: 1500) 10.0.162.1 > 10.0.162.3: icmp 1480: echo request seq 256
19:05:44.665592 IP (tos 0x0, ttl 64, id 52822, offset 1480, flags
[none], length: 21) 10.0.162.1 > 10.0.162.3: icmp
19:09:11.485566 IP (tos 0x0, ttl 64, id 25938, offset 0, flags [+],
length: 1500) 10.0.162.1 > 10.0.162.4: icmp 1480: echo request seq 768
19:09:11.485576 IP (tos 0x0, ttl 64, id 25938, offset 1480, flags
[none], length: 21) 10.0.162.1 > 10.0.162.4: icmp
19:09:11.492506 IP (tos 0x0, ttl 64, id 18866, offset 0, flags [+],
length: 1500) 10.0.162.4 > 10.0.162.1: icmp 1480: echo reply seq 768
19:09:11.492811 IP (tos 0x0, ttl 64, id 18866, offset 1480, flags
[none], length: 21) 10.0.162.4 > 10.0.162.1: icmp
Tom DeReggi
RapidDSL & Wireless, Inc
IntAirNet- Fixed Wireless Broadband
--
WISPA Wireless List: wireless@wispa.org
Subscribe/Unsubscribe:
http://lists.wispa.org/mailman/listinfo/wireless
Archives: http://lists.wispa.org/pipermail/wireless/
