интересно, на каком вендоре/вендорах у них сеть

не надо OOB???

Что за ЕРЕСЬ?!??!!

пускай страдают

ну он же не грит что манаджмент не надо

не надо OOB???

Как сделать ZTP без OOB?

@blademd тут щас LSVR будет

Консольками сразу в железки натыкать

@onemorepash поч на underlay отказались от bfd?

А нахуя? У тебя есть видимость физических линков. А все остальное — ну, false positive at scale страшнее сценариев отказа, где это может чем-то помочь. То есть вреда, имхо, больше, чем пользы

А нахуя? У тебя есть видимость физических линков. А все остальное — ну, false positive at scale страшнее сценариев отказа, где это может чем-то помочь. То есть вреда, имхо, больше, чем пользы

На физ линки есть OAM? Там про это ни слова

Нету, а зачем?

Нету, а зачем?

Как детектите проблемы на линке?

Нету, а зачем?

не перфекционисты вы нифига

у вас проблемы, а вы не видите :)

Как детектите проблемы на линке?

это же DC

а не SP

это же DC

и что блять, как будто патч не могут помять

там это редкая проблема имхо

будет у тебя 1 из 4 линков битый

Ну я все еще утверждаю, что оам или бфд — проблем будет больше чем пользы.

Ну я все еще утверждаю, что оам или бфд — проблем будет больше чем пользы.

Я понял, а как детектите всё же? Телеметрия?

Я не смотрел видео, только презу

Я понял, а как детектите всё же? Телеметрия?

пользователи грят - "чот тормозит"..

Challenge your vendor and PoC everything in advance Вот это прям понравилось

Телеметрия, да. Плюс дедовские методы, snmp там, вот это все. Но это другой вопрос. BFD тебе от этого не поможет. Если он у тебя упал, то ты об этом тоже как-то должен узнать.

И главное, что-то сделать

А это нетривиально

Телеметрия, да. Плюс дедовские методы, snmp там, вот это все. Но это другой вопрос. BFD тебе от этого не поможет. Если он у тебя упал, то ты об этом тоже как-то должен узнать.

BFD тебе просто быстрее сообщит это

можно и через телеметрию узнать

BFD тебе просто быстрее сообщит это

быстрее обнаружит

BFD сообщит о чем-то своем

быстрее обнаружит

но если bfd/oam протокол ляжет, то проблемы могут быть больше

Вот

@onemorepash ты это имел в виду?

Да, да

ну при директ линках смысла в BFD особо нет

вот если аренда или мультихоп

или какой нибудь DWDM старый

ну при директ линках смысла в BFD особо нет

Ну при директ OAM LFM

Ну при директ OAM LFM

EFM?

EFM?

LFM

То есть класть L3-связность через линк, когда там что-то не то, это довольно опасное решение. Не то чтоб я прям религиозно против, но это тот случай, когда мы для себя решили, что опасности от этого больше.

Ну типа риск потерять оба аплинка лифа, когда BDF что-тот там себе надумал

LFM

802.3ah 2004 Ethernet in the First Mile (EFM, «первая миля» Ethernet)

Ну при директ OAM LFM

жунипер аддикт

Ну типа риск потерять оба аплинка лифа, когда BDF что-тот там себе надумал

Ну а как вы всё же боритесь с проблемами на директ линках? Просто для себя интересно. Вы это отпускаете на телеметрию/мониторинг, но делаете сеть более надежной за счет уменьшения протоколов в сети, я правильно понял?

@onemorepash скажи, вы когда рынок исследовали, не было более менее рабочий EVPN/Whatever имплементаций?

802.3ah 2004 Ethernet in the First Mile (EFM, «первая миля» Ethernet)

EFM, насколько я помню, можно мониторить сервис, например pw/vpls, а LFM - это чисто direct

whatever - GENEVE/GRE и так далее

Через ооб обновлять по удобнее

Ну так я об этом и вещаю

BFD качество не определяет

для этого нужен 802.3ah

несите BER тогда уж

ну и что ты получишь с BFD? Флаппинг в худшем случае

тогда уж EFM, BER

ну и что ты получишь с BFD? Флаппинг в худшем случае

при наличии дампенинга не так страшно конечно

но всё равно, BFD это не тот механизм имхо чтобы такие линки определять

Вчера по оптимистичным оценкам Гугла почти все их американское вычислительное облако лежало четыре с половиной часа. По слухам: из-за ошибки в работе маршрутизатора разнесло большой кусок сети, все видели потерю пакетов. Не работала часть сервисов Гугла (включая Ютуб и Gmail), не работало много сервисов которые уехали в гугловское облако (например снапчат). Также судя по слухам, сломался внутренний инструмент, который сетевые инженеры Гугла используют для общения вокруг инцидентов, что и привело к такому длительному простою. Тяжелая история, пока чемпионом по стабильности среди облаков с огромным отрывом является Амазон. https://status.cloud.google.com/incident/compute/19003

В гугл взяли того чувака из яндекса

ну вот на моей памяти были случае когда EFM проблему такую плавающую видел, а BFD нет

не работало много сервисов которые уехали в гугловское облако (например снапчат)

Невелика потеря

EFM, насколько я помню, можно мониторить сервис, например pw/vpls, а LFM - это чисто direct

e2e это CFM, LFM/EFM это одно и тоже, оно p2p только

e2e это CFM, LFM/EFM это одно и тоже, оно p2p только

ок

облако превратилось в тучу

ну вот на моей памяти были случае когда EFM проблему такую плавающую видел, а BFD нет

погоди, EFM/LFM умеет детектить, что именно нет так, а BFD что что-то не так.

По этому я за EFM даже на direct link, но, можно не делать его агрессивным

И чисто срать в логи, например

По этому я за EFM даже на direct link, но, можно не делать его агрессивным

Да что не BER то сразу :)

я наелся с false positive и efm, когда у меня пол сегмента уехало из-за "особенностей" работы efm на huawei, и теперь я @onemorepash прекрасно понимаю

это для ситуации, когда механизмы работают, как запланировано)

@onemorepash хорошая преза, спасибо

у меня все линки легли, когда 802.3 ethernet некорректный пришёл)

БД)

оно там включено

эй, я уже пошутил эту шутку!