может привести к "калапсу"

но не приводит, потому что достаточно просто ребутнуть глюкнувший маршрутизатор, чтобы все его пиры сбросили все полученные от него маршруты

а если bgp на нем работает НАСТОЛЬКО неправильно, то вряд ли у кого-то будет желание держать его включенным

Было уже

И что ? Все спокойно спят ?  Тоесть RPKI и всякие там штуки для защиты от ошибок конфигурации и роутликов мы думаем, а то что “мертвые души” в bgp DB есть

возможно, что какие-то единичные залипшие маршруты и существуют (в предположении, что есть какие-то отдельные очень долго работающие роутеры, bgp на которых глючит, но этого никто не замечает), но это явно не самая массовая пролема в мире

механизм native vlan - это в первоисточнике превращение нетегированного трафика в определённый тег.

на картинке порт в гибриде: не тегированный трафик превратить в 569, при этом если придёт тегом 569 - то тоже нормуль...

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

Вы что хотите получить на этом линке на картинке? что передавать и как получать от себя в клиента и наоборот?

Также вы можете наступить на вендорские грабли (особенно в гибридном режиме) - вендор может вообще по своему понимать native...

#define "спокойно спят"

Сетевики и не только лишь они, а вот такой вопрос,
А есть ли у кого в загашнике прям документ по проведению тестирования сетевого оборудования (роутеры\свитчи) как синтетическими тестами (некая методология) так и вот эти все, обновил софт, пофлапал портом, нагенерил битых пакетов, нагрузил трафиком, накидал маков, задрючил протокол на схождение и прочее прочее. У меня все это в голове, особенно после Элтекса, а вот перенос на бумагу это прям труд и большие временные затраты.

Поделитесь пожалуйста документом, если таковой существует!)
Спасибо)
За вводные цифры спасибо Илье Сомову @somovis )


!!! Не путать только с железом, которое приехало идет просто проверка того что нужно настроить перед в продом.

swithport trunk native vlan 569
switchport trunk allowed vlan .. 569

лично я читаю это как: принять untag и переписать в tag 569, принять tag 569 и пропустить не меняя. А что делать в обратную сторону? снимать тег со всех пакетов 569 или просто передать их тегом? согласно первой строке - тег снять, а согласно второй - передать в теге 569.

Посмотрите что на самом деле делает коробка и вам станет ясно почему не ходят маки.

это настройки клиента

я понял что клиента, я к тому, что пока с двух сторон не настроите правильно - связь не поднимется -)

с нашей стороны вендор huawei, порт в гибриде, метка native на 569 (отдаем), а забираем у клиента в trunk 569

клиент видит от вас трафик влана 569 в untag виде?

запрошу

Rkpi и другие проверки в данном случае не при чем. Когда маршрут анонсировали, он был валидным. Но при снятии анонса такое бывает, что маршрут где то залипает и не уходит. Обычно просто пишем туда, где залипло. Они уже разбираются. Чаще всего достаточно обновить информацию от пира, даже без разрыва сессии

скорее всего клиенту надо оставить native настройку и удалить 569 из allowed trunk, но это лечение по фотографии... что там за вендор у клиента, как он (вендор) понял тему native...

Вы с его стороны получаете трафик с 569 вланом? если да - то ему надо починить этот момент и всё поедет.

native с обоих сторон могут быть разные - это один из методов vlan mapping по одному тегу.

точнее если с обоих сторон native одинаковые - то делать так (снимать тег и потом вешать тот же самый) незачем