I am trying to understand the "big picture" of MTU. Specifically, many discussions of MTU focus on a single hop (e.g. laptop to router), so the natural question is: how to determine MTU between cable modem and ISP, or more generally, for any given hop of a route.
Now, I can easily see the MTU between my laptop and its: wi-fi router using ifconfig on Mac OS X:
en0: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500
options=2b<RXCSUM,TXCSUM,VLAN_HWTAGGING,TSO4>
ether 58:b0:35:f0:14:75
media: autoselect (none)
status: inactive
en1: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500
ether 58:b0:35:72:64:fa
inet6 fe80::5ab0:35ff:fe72:64fa%en1 prefixlen 64 scopeid 0x5
inet 192.168.1.100 netmask 0xffffff00 broadcast 192.168.1.255
media: autoselect
status: active
1500 is the canonical value b/c of the limitation of the wi-fi frame (which I am guessing was designed to match the Ethernet frame; please correct me if that's wrong).
So, the question is: How to determine the MTU of arbitrary hops in my route?
Answer summary:
Per the below answer, best bet is "tcpdump", "traceroute --mtu" or "tracepath"
The thing you are looking for is Path MTU Discovery. You can see that in action with tcpdump(1) during TCP three way handshake by watching the MSS option values (you will need appropriate level of dump verbosity, afair -vv does it).
Original traceroute(8) is supposed to show you path MTU changes, but I never had luck with it. Linux tracepath(8) gives you hop MTU value right away.
Related
I have read RTP Packet maximum size? and What is the max rtsp(over tcp) packet size? but that didn't answer on my problem.
How can I find out what is the max size of rtp/rtsp? is that depend only on MTU ? there is no way that rtp/rtsp will be bigger than MTU ?
I have change the MTU with ifconfig eth1 mtu 1000 up but still I got RTSP packet with 1440 length
How can I find out what is the max size of rtp/rtsp? is that depend
only on MTU ? there is no way that rtp/rtsp will be bigger than MTU ?
In practice a RTP of 1400 bytes is a good size in 99.9% of time.
There is no real limit as you may use IP level fragmentation and/or Ethernet Jumbo-frame.
In summary, the max size of RTP is not dependent on MTU but on the codec/framing in use.
I have change the MTU with ifconfig eth1 mtu 1000 up but still I got
RTSP packet with 1440 length
ifconfig eth1 mtu 1000 set a 1000 MTU on the eth1 interface.
It is not possible to send larger datagrams than 1000,
but eth1 is still able to receive larger datagrams.
If you think about it interface-MTU is rather different of actual path-MTU between two hosts.
If you have such a specific need, you should be looking to implement MTU path discovery.
As we all perfectly know, UDP does not support retransmission along with some other things.
We also aware of such thing like MTU that works basically in the following way -- when one of the network devices on the path between source and destination points does not support packet of some size, it just drops it.
In case of TCP, it's not a problem -- it already knows MSS after handshake that is always less than MTU (am I right?), so there's no possibility to send a packet with the size greater than MTU.
However, I wonder how does it work in case of UDP? As I already said, there's no retransmission in this protocol and there's no such thing like MSS. So what happens when the packet is dropped due to exceeding MTU?
Or it just works because of the MTU nature (it actually belongs to the IP layer, not the transport layer protocols like UDP or TCP)? So the IP layer reconstruct the dropped packet in smaller units and send it again?
First of all, you must distinguish between the local MTU, which is just the MTU of the local link, and the path MTU (PMTU), which is the smallest MTU of the local link. Consider the following topology:
1500 1480 1500
A -------- B -------- C -------- D
then A's local MTU is 1500, but the PMTU is just 1480.
When router B receives a packet of size 1500 which it needs to forward, and the DF bit is set, it sends an ICMP packet back to the sender with the next hop's MTU, 1480 in this case. The sender can then reduce the packet size.
In TCP, this is done transparently by the network stack. In UDP, the application needs to deal with it. There are three ways to do that:
always send packets that are small enough; 1024 is always safe over IPv6, and 512 is usually (but not always) safe over IPv4;
use a connected UDP socket, and react to an EMSGSIZE error by reducing the packet size; or
use any kind of UDP socket, request the PMTU ancillary data, and use the data provided.
Technique (3) is the most efficient. For IPv6, it is described in Section 11.3 of RFC 3542.
I am checking the MTU size of a USB tethering connection, but I got different results with different commands...
By using "netsh interface ip show subinterfaces" I get the following results (Local Area Connection 8 is the tethering connection):
C:\Users\Chris>netsh interface ip show subinterfaces
MTU MediaSenseState Bytes In Bytes Out Interface
4294967295 1 0 1350760 Loopback Pseudo-Interface 1
1500 2 3756376356 10363121083 Wireless Network Connection
1500 5 0 0 Local Area Connection
1500 1 178477 238360 Local Area Connection 8
But by using "ping google.com -l 1472 -f" I got the following results:
C:\Users\Chris>ping google.com -l 1472 -f
Pinging google.com [216.58.220.142] with 1472 bytes of data:
Reply from 192.168.42.129: Packet needs to be fragmented but DF set.
Packet needs to be fragmented but DF set.
Packet needs to be fragmented but DF set.
Packet needs to be fragmented but DF set.
The tethering connection is the only working connection when I check. If the MTU size is 1500 the ping method should work... I am a little bit confused here. Could anyone tell me what's the difference between the 2 method?
netsh shows the MTU of the interface itself. But your ping command sends packets through your interface into the wider world of the Internet. Somewhere along the path between your interface and google.com there is a router with a smaller MTU than 1472 bytes. This is called Path MTU.
Hope I've came to the right place to ask this, if not I guess my question becomes where can I find people who know the answer as a week on google doesnt help!
I have NetEm setup and got it finally working but what I want to do is test using an IPv4 filter, i.e I want to have latency added to one IP without adding it to others to test the effect of a range of different latencies all commected to one server.
Im running NetEm through ubuntu, any advice pointing me to the right direction would help!
Thanks,
Dave
Please use the below set of commands to setup netem to do whatever you want for a particular ip address.
tc qdisc del dev eth0 root
(assuming eth0 is the interface)
tc qdisc add dev eth0 root handle 1: htb
tc class add dev eth0 parent 1: classid 1:1 htb rate 100mbit
(100mbit rate of tokens)
tc filter add dev eth0 parent 1: protocol ip prio 1 u32 flowid 1:1 match ip dst 192.168.2.219
(assuming you want to throttle bw for this dst ip address)
tc qdisc add dev eth0 parent 1:1 handle 10: netem delay 25ms
(assuming you want a 25ms delay)
Refer to my other answer for a better explaination
And this excellent thesis for a better understanding
I tried to understand mapping multicast IP address to layer 2 ethernet frame i.e IEEE 802.3 multicast frame but didn't understand the concept behind it. I'm will appreciate the answers with examples here, of which mapping of an IP address to Ethernet frame can be explained on the scale side by side.
This is very simple:
For ipv4 :
Mac adress has to start with 01:00:5E the 01 in binary gives 00000001 the the lowest bit of the hihgest byte give multicast or not. This is the first bit received by network card so then can quickly ignore or not multicast packet
So you have 01:00:5E:XX:YY:ZZ the range of available mac adresses goes from 01:00:5e:00:00:00 to 01:00:5e:7f:ff:ff
So you have 23 bits to complete with the 23 lowest bits of the ipv4 adresses
IPV4 adresses multicast go from 224.0.0.0 to 239.255.255.255
So for example OSPF (well know routing protocol) use these ipv4 adresses :
224.0.0.5 that give 01:00:5E:00:00:05
224.0.0.6 that give 01:00:5E:00:00:06
For ipv6 :
ipv6 adress are ff00::/8
You use mac prefix 33:33:XX:YY:ZZ (remark the lowest bit of the highest bytes is 1)
and you complete by the lowest bytes of ipv6 adress