[ollsanek]

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

в этом есть смысл? я сейчас не только микротик имею ввиду.

если железка с нормальным разделением control и data plane, то нет.

но микрот - софтроутер, поэтому data plane (пакеты) ждёт пока отработает control plane (OSPF) и тут могут помочь большие буфера, хотя они могут вызвать новый головняк.

[NiTr0]

data plane (пакеты) ждёт пока отработает control plane (OSPF)

Вообще-то должно быть наоборот. Приоритет ядерных процессов выше приоритета юзерспейса.

[Saab95]

Вообще-то должно быть наоборот. Приоритет ядерных процессов выше приоритета юзерспейса.

 

То есть на ваших любимых софтроутерах на серверах с линуксами это так и есть?

[ollsanek]

data plane (пакеты) ждёт пока отработает control plane (OSPF)

Вообще-то должно быть наоборот. Приоритет ядерных процессов выше приоритета юзерспейса.

ну да, должно,

но по факту, на роутерборде, если флапает порт, то транзитный трафик через другие порты запинается.

 

В любом случае, при поднятых буферах в полный рост встаёт bufferbloat.

[NiTr0]

То есть на ваших любимых софтроутерах на серверах с линуксами это так и есть?

Именно. Перестройка маршрутов никоим образом не влияет на проходящий трафик. Могу сколько угодно гасить-поднимать бгп пиры, никто из клиентов этого даже не заметит. А в микротике, видать, криворукие разработчики почему-то решили роутинг процессам дать реалтайм приоритет...

[Saab95]

но по факту, на роутерборде, если флапает порт, то транзитный трафик через другие порты запинается.

 

В любом случае, при поднятых буферах в полный рост встаёт bufferbloat.

 

Если правильно настроить OSPF проблем нет. Вспомните про BFD.

 

Именно. Перестройка маршрутов никоим образом не влияет на проходящий трафик. Могу сколько угодно гасить-поднимать бгп пиры, никто из клиентов этого даже не заметит. А в микротике, видать, криворукие разработчики почему-то решили роутинг процессам дать реалтайм приоритет...

 

На микротике тоже не влияет.

[NiTr0]

На микротике тоже не влияет.

Неужто?

но по факту, на роутерборде, если флапает порт, то транзитный трафик через другие порты запинается.

[Saab95]

но по факту, на роутерборде, если флапает порт, то транзитный трафик через другие порты запинается.

 

Это при работе в бридже что ли? Если роутинг, как может работа других портов влиять на него?

[zhenya`]

Бфд страшно при больших нагрузках.. Тем более оно на проце. Флапов из-за скачков нагрузки не будет?

[Saab95]

Бфд страшно при больших нагрузках.. Тем более оно на проце. Флапов из-за скачков нагрузки не будет?

 

Так нужно использовать каждый инструмент для правильных целей. Если каналы медленные и работают с перегрузами, BFD лучше не включать.

[s.lobanov]

Бфд страшно при больших нагрузках.. Тем более оно на проце. Флапов из-за скачков нагрузки не будет?

 

Так нужно использовать каждый инструмент для правильных целей. Если каналы медленные и работают с перегрузами, BFD лучше не включать.

 

как раз с медленными и перегруженными(а не арендованное L2) каналы понятно как быть - настроить приоритезацию сигнализации(в том числе bfd) и настанет счастье (если оно по дефолту не настроено).

 

даже с перегрузками CPU можно бороться, путём настройки приоритезации в сторону CPU (только это может быть не документировано явным образом, надо знать внутренние особенности и т.п.) и приоритезацию процессов(тут уже только вендор поможет ибо опенсорс оборудования по сути нет)

 

но на практике это всё очень сложно проверить и предусмотреть все случаи(например когда на CPU в ту же очередь, куда попадает bfd пойдёт что-то ещё жирное)

 

вообщем, с bfd нужно держать ухо в остро, штука прикольная, но аварий из-за неё может быть больше, чем пользы. в мухосранк-хоумнетах оно точно не нужно