Как стать автором
Обновить

Комментарии 14

НЛО прилетело и опубликовало эту надпись здесь
Подозреваю, может быть актуально для решений IaaS — у клиента ставится маленькая коробочка-роутер с VPN-ом в облако и на этом всё заканчивается, дальше управление идёт из центра.
НЛО прилетело и опубликовало эту надпись здесь
Так уж, к слову, есть поддержка CDP на *nix системах и ограниченная поддержка HP Procurve
Ну как бы L2TP, AToM и любые другие инкапсулирующие L2 фреймы транспорты спокойно тащат на себе и CDP. Что, конечно, никак не отменяет факт полной бесполезности ODR.

По поводу «Подключать роутеры в сеть, вообще не делая никаких настроек» — не прокатит, если мы говорим о роутинге, ведь надо еще как-то назначать адреса внутренним интерфейсам (хотя возможны хитрые варианты с EEM в случае IPv4, а у IPv6 есть свои врожденные способы реализовать эту задачу).
Если надо я смогу как-то наверно сесть и дописать всетаки статью по OER/PFR которую у меня на CCIE R&S лабе попалась…
Только надо кармы будеть на циска-хаб залить
Я вот пытался с ним подружиться. Всерьез пытался. Лаба, несколько тестовых роутеров, генерация трафика, прозрачный сервер для контролируемого внесения задержек/дропов с целью сделать OOP. Несколько кейсов, пара новых багов. И я так до конца и не понял, как эта сволочь должна работать.

К счастью, из нового CCIE RS его убрали. И правильно. Нечего над людьми издеваться.
да, там на пробках все завязано ) если пробы висят то все нормально,
бажит конкретно иногда — а для генерации трафика и пинга хватает на лабе.
Как лабу перетяну свою на новый рак то напишу на хабре пост )
если пробы висят то все нормально

Active — возможно. Fast — иногда (далеко не всегда). Dual… Собственно, с ним главные проблемы. А без него — немереное количество конфигурации, когда речь идет о сотнях соседств. Красивая идея, крайне бажная реализация. То не переключает, то переключает, но обратно не возвращает…

Ну и собственно генерация трафика была бюджетной, telnet x.x.x.x 19 в несколько потоков (вроде по 30кб/с на поток) и маленькие bandwidth на интерфейсах. А главное — все-таки возможность нормально делать задержку-потери по мере надобности, а не плясать с бубном вокруг шейпера и random-detect.
Как я уже написал, больше академический интерес. Необычное решение, разбирал больше из спортивного любопытства, а не ради практического применения, так как оно, очевидно, маловероятно)
А дальше будет)
Напоминает поведение при accept_ra=2 у линуксов (ipv6) — по мультикасту слушать о доступных машрутах с маршрутизаторов и конфигурировать свои маршруты в соответствии с. При этом ещё и самим работать маршрутизатором.
Ipv6 Stateless Autoconfiguration в общем-то у всех одинаков, все же стандарт.
Что линукс, что циска.
Если на маршрутизаторе применить команду ipv6 address auto-config и не применять ipv6 unicast-routing (оставить его в режиме работы IPv6 узла), то он будет генерировать сообщения RS, и принимать сообщения RA.
А свои RA он рассылать будет? Вся прелесть accept_ra=2, что можно одновременно и принимать RA, и рассылать их.

Правда, это нифига не zero-configuration, т.к. надо анонсы самому настраивать.
Без ipv6 unicast-routing RA не отправляются)
Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации

Истории