Как правильно посчитать MTU для 6to4?
Цитата: RoxsAndy от 24/02/2019, 14:37Собственно вопрос возник из пары смежных тем по настройке 6to4.
На текущий момент при соединении с провом через PPPoE на WAN порту имеем MTU = 1492, соответственно на sit0 (6to4 от tb.ip4market.ru) с последними правками MTU = 1472
sfstudio
В общем глянул код и исходя из текущей реализации там вообще должно MTU на всех sit и LAN интерфейсах быть -20 от WAN используемого для туннеля (т.е. в случае с PPPOE при 1492 на нём будет 1472 на всех ифэйсах с ipv6 адресами) т.е. если правильно понял то:
- let "sitmtu=$wanmtu - 20"
- ipvmtu=$sitmtu
Feb 24 14:56:30 kernel: IPv6 over IPv4 tunneling driver Feb 24 14:56:30 ipv6: Tunel ipv6 to ipv4 configure and up at sit0 interface Feb 24 14:56:30 ipv6: Add adress 2a0d:8000:cde:5555:b06c:4455::1/16 to sit0 Feb 24 14:56:30 ipv6: MTU WAN: 1492 LAN: 1472 Feb 24 14:56:30 ipv6: Set mtu 1472 to sit0 Feb 24 14:56:30 ipv6: Add route to 2000::/3 via ::193.0.203.203 dev sit0 Feb 24 14:56:30 ipv6: Used tunneled ipv6 mode, disable forward from real wan interfaces (security reason), enable foe sit0. Feb 24 14:56:30 ipv6: Used tunneled ipv6 mode, not need ipv6 adress and route at wan ifaces - drop it (security reason). Feb 24 14:56:30 ipv6: Set 2a0d:8000:cde:5555:b06c:4455::2/64 to br0 Feb 24 14:56:30 ipv6: Configure and start radvd and dhcpv6 server Feb 24 14:56:30 ipv6: Use user manual configured DNS 2001:4860:4860::8888 2a02:6b8::feed:0ff Feb 24 14:56:30 ipv6: Use local DNS server as relay and local ipv6 hosts resolve 2a0d:8000:cde:5555:b06c:4455:0:2 Feb 24 14:56:30 ipv6: MTU WAN: 1492 LAN: 1472 Feb 24 14:56:30 ipv6: Configure radvd Feb 24 14:56:30 ipv6: Starting radvd Feb 24 14:56:30 radvd[3991]: version 2.17 started Feb 24 14:56:30 ipv6: Configure dhcp6s Feb 24 14:56:30 ipv6: Starting dhcp6sМаксимальный размер пинг-пакета через IPv6 равен 1424 байта.
>ping -6 -l 1424 ipv6.google.com Обмен пакетами с ipv6.l.google.com [2a00:1450:4011:80f::1001] с 1424 байтами данных: Ответ от 2a00:1450:4011:80f::1001: время=46мс Ответ от 2a00:1450:4011:80f::1001: время=45мс Ответ от 2a00:1450:4011:80f::1001: время=46мс Ответ от 2a00:1450:4011:80f::1001: время=45мс Статистика Ping для 2a00:1450:4011:80f::1001: Пакетов: отправлено = 4, получено = 4, потеряно = 0 (0% потерь) Приблизительное время приема-передачи в мс: Минимальное = 45мсек, Максимальное = 46 мсек, Среднее = 45 мсек >ping -6 -l 1425 ipv6.google.com Обмен пакетами с ipv6.l.google.com [2a00:1450:4011:80f::1001] с 1425 байтами данных: Control-C ^CПризываем на помощь математику:
1472 - 1424 = 48, если правильно разобрался, то это 40 байт IPv6 заголовок + 8 байт данных ICMPv6.
Снимал дампы wireshark-ом, максимальный payload для ICMPv6 показывает 1432 байта (что вроде бы правильно, если считать, что заголовок IPv6 еще 40 байт).
Вроде всё правильно, IPv6 пакеты бегают, сайты по этому протоколу открываются, но...
Поправьте меня, где я не прав? Или всё действительно так и MTU на ифейсах выставлены верно?
Собственно вопрос возник из пары смежных тем по настройке 6to4.
На текущий момент при соединении с провом через PPPoE на WAN порту имеем MTU = 1492, соответственно на sit0 (6to4 от tb.ip4market.ru) с последними правками MTU = 1472
sfstudio
В общем глянул код и исходя из текущей реализации там вообще должно MTU на всех sit и LAN интерфейсах быть -20 от WAN используемого для туннеля (т.е. в случае с PPPOE при 1492 на нём будет 1472 на всех ифэйсах с ipv6 адресами) т.е. если правильно понял то:
- let "sitmtu=$wanmtu - 20"
- ipvmtu=$sitmtu
Feb 24 14:56:30 kernel: IPv6 over IPv4 tunneling driver Feb 24 14:56:30 ipv6: Tunel ipv6 to ipv4 configure and up at sit0 interface Feb 24 14:56:30 ipv6: Add adress 2a0d:8000:cde:5555:b06c:4455::1/16 to sit0 Feb 24 14:56:30 ipv6: MTU WAN: 1492 LAN: 1472 Feb 24 14:56:30 ipv6: Set mtu 1472 to sit0 Feb 24 14:56:30 ipv6: Add route to 2000::/3 via ::193.0.203.203 dev sit0 Feb 24 14:56:30 ipv6: Used tunneled ipv6 mode, disable forward from real wan interfaces (security reason), enable foe sit0. Feb 24 14:56:30 ipv6: Used tunneled ipv6 mode, not need ipv6 adress and route at wan ifaces - drop it (security reason). Feb 24 14:56:30 ipv6: Set 2a0d:8000:cde:5555:b06c:4455::2/64 to br0 Feb 24 14:56:30 ipv6: Configure and start radvd and dhcpv6 server Feb 24 14:56:30 ipv6: Use user manual configured DNS 2001:4860:4860::8888 2a02:6b8::feed:0ff Feb 24 14:56:30 ipv6: Use local DNS server as relay and local ipv6 hosts resolve 2a0d:8000:cde:5555:b06c:4455:0:2 Feb 24 14:56:30 ipv6: MTU WAN: 1492 LAN: 1472 Feb 24 14:56:30 ipv6: Configure radvd Feb 24 14:56:30 ipv6: Starting radvd Feb 24 14:56:30 radvd[3991]: version 2.17 started Feb 24 14:56:30 ipv6: Configure dhcp6s Feb 24 14:56:30 ipv6: Starting dhcp6s
Максимальный размер пинг-пакета через IPv6 равен 1424 байта.
>ping -6 -l 1424 ipv6.google.com
Обмен пакетами с ipv6.l.google.com [2a00:1450:4011:80f::1001] с 1424 байтами данных:
Ответ от 2a00:1450:4011:80f::1001: время=46мс
Ответ от 2a00:1450:4011:80f::1001: время=45мс
Ответ от 2a00:1450:4011:80f::1001: время=46мс
Ответ от 2a00:1450:4011:80f::1001: время=45мс
Статистика Ping для 2a00:1450:4011:80f::1001:
Пакетов: отправлено = 4, получено = 4, потеряно = 0
(0% потерь)
Приблизительное время приема-передачи в мс:
Минимальное = 45мсек, Максимальное = 46 мсек, Среднее = 45 мсек
>ping -6 -l 1425 ipv6.google.com
Обмен пакетами с ipv6.l.google.com [2a00:1450:4011:80f::1001] с 1425 байтами данных:
Control-C
^C
Призываем на помощь математику:
1472 - 1424 = 48, если правильно разобрался, то это 40 байт IPv6 заголовок + 8 байт данных ICMPv6.
Снимал дампы wireshark-ом, максимальный payload для ICMPv6 показывает 1432 байта (что вроде бы правильно, если считать, что заголовок IPv6 еще 40 байт).
Вроде всё правильно, IPv6 пакеты бегают, сайты по этому протоколу открываются, но...
Поправьте меня, где я не прав? Или всё действительно так и MTU на ифейсах выставлены верно?
Цитата: sfstudio от 24/02/2019, 15:16Хосподи, ну грю же отложим чутка. Я сам там потерялся уже. И меня смущает неработающая фрагментация. Хотя кто что вещает аля то в sit вообще фрагментация работать и не должна.
Тогда эта логика становиться ещё более критичной и значение ipvmtu отдаваемое клиенту в RA и устанавливаемое на LAN_IF должно быть гарантированно таким что бы пакеты улетали в SIT без превышения ибо не могут быть фрагментированы.
Сейчас это гарантированно выполняется. Потеря в 40 байт не принципиальная от слова совсем. НО... Я не уверен что фрагментация работать и не должна с sit. Потому и грю отложим дальше вернёмся к теме когда будет время. Сейчас чесслово не до этого, да и проблемой сиё не является от слова совсем. Никаких проблем перестраховка (уж не помню почему её сделали и чётко помню что проверял на ТТК и именно на этом враианте остановился не зря, хотя уже не помню почему) в себе не несёт вообще.
Так что безопасно оставить в текущем виде и не заморачиваться. Дефолтовая схема вообще 1280 MTU для ipv6 подразумевает =)
Хосподи, ну грю же отложим чутка. Я сам там потерялся уже. И меня смущает неработающая фрагментация. Хотя кто что вещает аля то в sit вообще фрагментация работать и не должна.
Тогда эта логика становиться ещё более критичной и значение ipvmtu отдаваемое клиенту в RA и устанавливаемое на LAN_IF должно быть гарантированно таким что бы пакеты улетали в SIT без превышения ибо не могут быть фрагментированы.
Сейчас это гарантированно выполняется. Потеря в 40 байт не принципиальная от слова совсем. НО... Я не уверен что фрагментация работать и не должна с sit. Потому и грю отложим дальше вернёмся к теме когда будет время. Сейчас чесслово не до этого, да и проблемой сиё не является от слова совсем. Никаких проблем перестраховка (уж не помню почему её сделали и чётко помню что проверял на ТТК и именно на этом враианте остановился не зря, хотя уже не помню почему) в себе не несёт вообще.
Так что безопасно оставить в текущем виде и не заморачиваться. Дефолтовая схема вообще 1280 MTU для ipv6 подразумевает =)
