From: rick.jones2@hp.com
Moe Trin wrote:
> On Wed, 12 Jun 2013, in the Usenet newsgroup comp.protocols.tcp-ip, in
article
> , Rick Jones wrote:
> >The starting point is this, in pseudo IEEEspeak (which I've probably
> >botched) with a smattering of IETF style:
> > All stations in the same broadcast domain MUST have the same MTU.
> Wrong
Are we arguing about my conflating MTU and frame size together?
> >Ethernet has no way to communicate frame size between peers. If a
> >frame larger than the station is prepared to receive arrives, that
> >frame will be dropped.
> Nope - if you want to transmit packets no larger than 500 octets in a
> link where everyone else is doing 1500, that's your business. See
> RFC1122 and read about fragmentation and reassembly. Then look at
> my reply to Barry - specifically the output of 'ifconfig' and the
> tcpdump. One system with MTU 1280, one with 1500 and no problems.
> >However, if the interface on which it was going to receive the
> >datagram has an MTU/framesize smaller than the size of the datagram
> >sent, the datagram won't be "received" by the IP layer so it cannot be
> >resent, so the Path MTU logic cannot trigger.
> >Thus the reason why all stations (hosts, systems, what you will) in
> >the broadcast domain (everything joined at layer 2 eg ethernet) MUST
> >have the same MTU.
> Rick, what are you smoking? Can I get some? ;-)
JumboFrames I suspect.
Starting point - two systems, back-to-back cable 1500 byte MTU at both
ends:
raj@raj-8510w:~$ ifconfig eth0
eth0 Link encap:Ethernet HWaddr 00:1f:29:7a:d1:32
inet addr:192.168.1.3 Bcast:192.168.1.255 Mask:255.255.255.0
inet6 addr: fe80::21f:29ff:fe7a:d132/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:16256551 errors:0 dropped:5683 overruns:0 frame:0
TX packets:16251404 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:1155190603 (1.1 GB) TX bytes:1154104068 (1.1 GB)
Interrupt:22 Memory:e8000000-e8020000
raj@tardy:~$ ifconfig eth1
eth1 Link encap:Ethernet HWaddr 00:1c:c4:47:d3:f9
inet addr:192.168.1.4 Bcast:192.168.1.255 Mask:255.255.255.0
inet6 addr: fe80::21c:c4ff:fe47:d3f9/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:35423059 errors:0 dropped:0 overruns:0 frame:0
TX packets:35449304 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:2518538585 (2.5 GB) TX bytes:2522670698 (2.5 GB)
Interrupt:38 Memory:f4000000-f4020000
Perform your 8000 byte ping test:
raj@tardy:~$ ping -c 2 -s 8000 192.168.1.3
PING 192.168.1.3 (192.168.1.3) 8000(8028) bytes of data.
8008 bytes from 192.168.1.3: icmp_req=1 ttl=64 time=0.279 ms
8008 bytes from 192.168.1.3: icmp_req=2 ttl=64 time=0.236 ms
--- 192.168.1.3 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1000ms
rtt min/avg/max/mdev = 0.236/0.257/0.279/0.026 ms
And the tcpdump taken on the sender:
raj@tardy:~$ sudo tcpdump -i eth1 ip
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth1, link-type EN10MB (Ethernet), capture size 65535 bytes
15:47:27.120359 IP tardy.local > the-laptop: ICMP echo request, id 10123, seq
1, length 1480
15:47:27.120370 IP tardy.local > the-laptop: icmp
15:47:27.120373 IP tardy.local > the-laptop: icmp
15:47:27.120374 IP tardy.local > the-laptop: icmp
15:47:27.120376 IP tardy.local > the-laptop: icmp
15:47:27.120377 IP tardy.local > the-laptop: icmp
15:47:27.120595 IP the-laptop > tardy.local: ICMP echo reply, id 10123, seq 1,
length 1480
15:47:27.120605 IP the-laptop > tardy.local: icmp
15:47:27.120607 IP the-laptop > tardy.local: icmp
15:47:27.120610 IP the-laptop > tardy.local: icmp
15:47:27.120612 IP the-laptop > tardy.local: icmp
15:47:27.120614 IP the-laptop > tardy.local: icmp
15:47:28.120505 IP tardy.local > the-laptop: ICMP echo request, id 10123, seq
2, length 1480
15:47:28.120519 IP tardy.local > the-laptop: icmp
15:47:28.120521 IP tardy.local > the-laptop: icmp
15:47:28.120523 IP tardy.local > the-laptop: icmp
15:47:28.120525 IP tardy.local > the-laptop: icmp
15:47:28.120526 IP tardy.local > the-laptop: icmp
15:47:28.120687 IP the-laptop > tardy.local: ICMP echo reply, id 10123, seq 2,
length 1480
15:47:28.120699 IP the-laptop > tardy.local: icmp
15:47:28.120701 IP the-laptop > tardy.local: icmp
15:47:28.120712 IP the-laptop > tardy.local: icmp
15:47:28.120714 IP the-laptop > tardy.local: icmp
15:47:28.120716 IP the-laptop > tardy.local: icmp
^C
24 packets captured
24 packets received by filter
Now up the MTU on the sender to 9000 bytes:
[sudo] password for raj:
raj@tardy:~$ ifconfig eth1
eth1 Link encap:Ethernet HWaddr 00:1c:c4:47:d3:f9
inet6 addr: fe80::21c:c4ff:fe47:d3f9/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:9000 Metric:1
RX packets:35423102 errors:0 dropped:0 overruns:0 frame:0
TX packets:35449362 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:2518588525 (2.5 GB) TX bytes:2522723299 (2.5 GB)
Interrupt:38 Memory:f4000000-f4020000
Run the ping again (yes, I reapplied the IP address to eth1 :-)
raj@tardy:~$ ping -c 2 -s 8000 192.168.1.3
PING 192.168.1.3 (192.168.1.3) 8000(8028) bytes of data.
--- 192.168.1.3 ping statistics ---
2 packets transmitted, 0 received, 100% packet loss, time 1006ms
And the tcpdump trace, again from the sender:
raj@tardy:~$ sudo tcpdump -i eth1 ip
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth1, link-type EN10MB (Ethernet), capture size 65535 bytes
15:50:25.675807 IP tardy.local > the-laptop: ICMP echo request, id 10163, seq
1, length 8008
15:50:26.682668 IP tardy.local > the-laptop: ICMP echo request, id 10163, seq
2, length 8008
As it happens, ethtool -S eth0 on the destination shows
"rx_long_length_errors: 2" and that incremented to 4 when I ran the
ping test again.
Now, perhaps in your situation when you shrank the MTU to < 1500
bytes, the ethernet controller and NIC were still willing to take-in a
frame larger and IP accept it. In my setup, I have reset my sender to
a 1500 byte MTU, and then set the MTU to 1280 on my receiver. In that
case the 8000 byte ping still worked, but I am not sure it would be
good to rely on that. I could see, and have some vague recollections
about, systems whereon if one dropped the MTU/frame size below 1500
bytes, it would not accept packets above the new MTU and still below
1500.
rick
--
[continued in next message]
--- SoupGate-Win32 v1.05
* Origin: you cannot sedate... all the things you hate (1:229/2)
|
