|
ru.unix.bsd
- RU.UNIX.BSD ------------------------------------------------------------------
From : Yuri Selivanov 2:5020/400 29 Jan 2007 12:22:26
To : Alex Mogilnikov
Subject : Re: Jumbo frames and fxp
--------------------------------------------------------------------------------
Alex Mogilnikov <Alex.Mogilnikov@f70.n5054.z2.fidonet.org> wrote:
[snip]
> AB> Вот именно. И мы, как получатель, не можем принять фрейм
> AB> размером больше MTU.
> Почему это? Кто сказал, что у всех получателей в сети способности
> одинаковые?
Стоп. L2-сегмент обязан иметь *консистентный* mtu, равный наименьшему
поддерживаемому среди хостов. В противном случае можно поиметь
труднодиагностируемый black-hole.
> AM>> Его назначение - не передавать фреймы, которые получатель не
> AM>> сможет принять. Я
>
> AB> Вот пусть и не передают фреймы, которые мы принять не можем.
>
> Вот и я об этом - проверка должна выполняться на стороне отправителя.
Это принцип ietf -- be liberal in what you accept and conservative
in what you send, но вот только это не надо растягивать его на все случаи,
в конечном итоге, прием фрейма, размер которого превышает значение mtu
на входящем интерфейсе свидетельствует о том, что в l2-сегменте есть
mtu *mismatch*. Btw, вот что говорит man ti по поводу поддержки больших
фреймов:
[snip]
Support for jumbo frames is provided via the interface MTU setting.
Selecting an MTU larger than 1500 bytes with the ifconfig(8) utility con-
figures the adapter to receive and transmit jumbo frames. Using jumbo
^^^^^^^^^^^^^^^^^^^^
frames can greatly improve performance for certain tasks, such as file
transfers and data streaming.
[snip]
> Во-вторых, я бы еще понял, если бы такое отбрасывание производилось
> драйвером физического устройства (конкретного сетевого адаптера), который,
> действительно, отвечает за складывание принимаемых байтов в буфер
> ограниченного
Hа коммутаторах|раутерах именно так и происходит, что собственно,
изначально Вас так и удивило...
> размера (эту проверку, кстати, и так делают современные контроллеры). Hо вот
> для них как раз эта проверка не выполняется, зато она выполняется например для
> всяких vlan, которые сами никаким реальным приемом и складыванием байтов в
> буфер не занимаются, а получают уже принятый и сложенный в буфер фрейм от
> ассоциированного с ним физического интерфейса. Где же логика?
Уважаемый, Вы -- мыслите с точки зрения обработки фрейма *конечной*
станцией, в то время как спецификации и процедуры на MAC-sublayer не
дифференцируют понятия dte/dce.
P.S. Вообще, этот диалог мне кажется немного бессмысленным. Если
вы расположены считать происходящее с mtu одной большой ошибкой,
то разубеждать в этом я не собираюсь -- все остаются при своих
мнениях|интересах.
> Всего наилучшего, [Team PCAD 2000]
> Алексей М.
> ... Программисты и программистки! Выше флаг промежуточного переноса!
--
Best Regards,
Yuri Selivanov [URI2-RIPE]
--- ifmail v.2.15dev5.3
* Origin: A poorly-installed InterNetNews site (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
