Коллеги, есть условно банальный вопрос:

Какие могут быть причины для того, чтоб по каналу не могли пролезть пакеты размером больше, чем 1472 байта? Т.е. пакеты до 1472 включительно пролазят с и без опции don't fragment, а большего размера (без df) уже не лезут.

Транспорт l2, максимум двойной тег может быть. L2 mtu - 9k везде. L3 - 1500. Оборудование с l3 - juniper. L2 сегмент на джунах, нексусах и хрен знает чём ещё. Какие есть варианты кроме mtu?

Покидайте варианты плиз...

какое кли, какие еще параметры по кли наблюдать одновремменно?
2020 год на дворе

По Кумулусу рассылки  уже идут от Nividia

только сейчас обратил внимание

ага, перенесли)

Да был бы на АТС и хрен с ним - посчитать что вбить чтобы при конверсии правильный адрес нарисовало. Единственное что есть немножечко чисел, которые не получится сконвертировать т.к. при переводе ведущий ноль на единицу поменяется, но это не ваш случай

Стандартный размер MTU, без jumbo frame. Всё.

ага - залез удалённо, махнул адрес и - гудбай...

а что с 1472 не так ?

это же как раз 1500 мту

.загадка на 5 баллов из 100: как сильно сказывается фрагментайия пакетов на производительности роутеров (хуй там - свичей) :
допустим в s6330, при IP форвардинге, с одной стороны 1600, а с другой 1200, что-то задумался

Вообще я не очень понял как связаны статический адрес и dhcp провайдера. Тут либо трусы надеть, либо носки снять нужно

Очень плохо

Оно в процессор уходит и софтово режется

))))

Через один конкретный линк поставщика не пролазят большие пакеты -даже без df-!

я подключаюсь к провайдеру, провайдерский dhcp сервер моему роутеру выдаёт статический адрес, оговоренный договором между юрлицами