Что происходит с пакетом, когда он большего MTU чем на интерфейсе?

[c0re]

Есть PC, у него на интерфейсе стоит MTU в 1000. К нему приходит пакет с MTU 1400. Что произойдёт?
Я в tcpdump'e вижу полную пустоту. Пробую на ICMP пакетах.
Что должно происходить? rfc?

[storinger]

По идее должно просто тупо дропаться как ошибка на физике. То есть с точки зрения интерфейса этот сигнал вообще не должен распознаваться как ethernet-фрейм.

[slim]

дропнеца. в ответ может улететь icmp сообщение (типа, нужен дефрагмент), если фича pmtu включена в системе.

на счет ошибок физики - врятли. если crc фрейма не битая, ошибок не должно возникать..

[storinger]

Я вот чего-то забыл как конец фрейма определяется -- там длина в заголовке есть или маркер конца ?

[c0re]

Я вот чего-то забыл как конец фрейма определяется -- там длина в заголовке есть или маркер конца ?
http://upload.wikimedia.org/wikipedia/commons/thumb/1/13/Ethernet_Type_II_Frame_format.svg/700px-Ethernet_Type_II_Frame_format.svg.png

маркеры, вроде, в токен-ринге и в шине были

если фича pmtu включена в системе.
это остаётся проверить, в затупе я чо-то с траблой

[slim]

Я вот чего-то забыл как конец фрейма определяется -- там длина в заголовке есть или маркер конца ?

тут, как мне кажется, дело не с формате фрейма,
а в том, что ограничение в 1000 байт мту, выставленное на хосте, -
это инфа сетевого, но не канального уровня.

соотв. на канальном уровне все должно быть без проблем,
а вот коннективити сетевого уровня - роляет данное ограничение.


как-то так..

2коре,
а в чем, интересно затык?
и че вчера не приехал? :)

[c0re]

интересная ситуация


bge0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1100
options=9b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM>

не получает вообще пакет больше 1100 байт


а
xl0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1100
options=9<RXCSUM,VLAN_MTU>
rl0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1100
options=8<VLAN_MTU>

получают, не смотря на mtu.

у меня подняты gif интерфейсы (это просто ipinip) на этих машинках с mtu 1280. Через этот gif пролезает 1280. gif прикручен к реальному интерфейсу xl0 или rl0, то есть пакет с 1300 MTU максимум пролазиет в xl0 и rl0, не смотря на 1100 этих интерфейсов.

а с bge0 так не получается.

rl - realtek
xl - 3com
bge - broadcom

Предполагаю, что опции как-то могут влиять на это... и снять с bge опции. Или перевесить сервис, что ли, на тоннельный ип...

Всегда не любил проблемы с MTU :-E

[slim]

а покажи ifconfig -m

первое что приходит в голову - это попробовать отключить checksumm offloading на бге интерфейсе..

и не совсем понятно, почему на туннельном интерфейсе мту больше, чем на физическом?

пакеты в туннеле проходят до тех пор, пока df бит на них не выставлен, видимо..

[c0re]

а покажи ifconfig -m
# ifconfig -m
bge0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1100
options=9b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM>
capabilities=9b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM>
...........
IP,MAC
...........
media: Ethernet autoselect (100baseTX <full-duplex>)
status: active
supported media:
media autoselect
media 1000baseTX mediaopt full-duplex
media 1000baseTX
media 100baseTX mediaopt full-duplex
media 100baseTX
media 10baseT/UTP mediaopt full-duplex
media 10baseT/UTP
media none



первое что приходит в голову - это попробовать отключить checksumm offloading на бге интерфейсе..
да, тоже самое и мне приходило, но смогу только сегодня вечером попробовать, боевая машинка.


и не совсем понятно, почему на туннельном интерфейсе мту больше, чем на физическом?
на bge на одном из алиасов висит tcp демон, мту там меньше, чем тоннельный для того, чтобы при tcp-коннекте через тоннель к этому IP mss передавался заведомо меньший тоннельного, иначе с МТУ грабля.

работало на других серверах такая схема, а с броадкомом вот засада вышла.


пакеты в туннеле проходят до тех пор, пока df бит на них не выставлен, видимо..
df не выставлен в прилетающих пакетах, проверял tcpdump'ом до входа в тоннель на ифейсе с 1500мту.


есть 2 варианта решения, как мне кажется:
1) попробовать снять RXCSUM,TXCSUM с интерфейсов
2) повесить tcp-демона на тоннельный IP, что мне сейчас кажется более грамотным. И вернуть у физического интерфейса обратно 1500 МТУ.

[squirL]

Есть PC, у него на интерфейсе стоит MTU в 1000. К нему приходит пакет с MTU 1400. Что произойдёт?

примется пакет, если не установлен DF. например когда на удаленной стороне включен PMTU в чем проблема-то? :)

[c0re]

примется пакет, если не установлен DF. например когда на удаленной стороне включен PMTU в чем проблема-то?
да вот какая-то фигня творится.
bge0 - 1100 mtu
там же gif0 1280 mtu
прилетает пакет 1300 размером к bge0 (ipencap пакет gif'овский) и исчезает. Вернее, в tcpdump'е на bge0 его не видно. Максимум - суммарный 1100 пакет может прилететь на bge0. При том, что rl0 и xl0 на это положить. Предполагаем, что по RX/TX summ железяк отбой проходит где-то...

[slim]

а если сервис перевести на лупбек?

[c0re]

а если сервис перевести на лупбек?
ох ты ж ё-маё, как же я сам не допёр!
идеё :)

[c0re]

а если сервис перевести на лупбек?

перевёл на lo1, выставил там 1100 mtu
делаю telnet и слушаю tcpdump'ом.
что вы думали?

S 1009315563:1009315563(0) ack 223293962 win 65535 <mss 1460,sackOK,eol>

отвечает mss 1460 и срал он на мту!

засада :(

[slim]

а покажи-ка:
sh run int lo1
sh ip int lo1 | i MTU

mss=1460 - это правильное значение: 1500 - 20 (ip хедер) = 1480; 1480 - 20 (tcp хедер) = 1460

[c0re]

это freebsd :)


mss=1460 - это правильное значение: 1500 - 20 (ip хедер) = 1480; 1480 - 20 (tcp хедер) = 1460
да, я в курсе)
во фрибсд параметр mtu на loopback интерфейсах игнорируется вообще почему-то

[slim]

ну тогда хз.. %)