Комментарии 14
НЛО прилетело и опубликовало эту надпись здесь
Подозреваю, может быть актуально для решений IaaS — у клиента ставится маленькая коробочка-роутер с VPN-ом в облако и на этом всё заканчивается, дальше управление идёт из центра.
0
НЛО прилетело и опубликовало эту надпись здесь
Так уж, к слову, есть поддержка CDP на *nix системах и ограниченная поддержка HP Procurve
0
Ну как бы L2TP, AToM и любые другие инкапсулирующие L2 фреймы транспорты спокойно тащат на себе и CDP. Что, конечно, никак не отменяет факт полной бесполезности ODR.
По поводу «Подключать роутеры в сеть, вообще не делая никаких настроек» — не прокатит, если мы говорим о роутинге, ведь надо еще как-то назначать адреса внутренним интерфейсам (хотя возможны хитрые варианты с EEM в случае IPv4, а у IPv6 есть свои врожденные способы реализовать эту задачу).
По поводу «Подключать роутеры в сеть, вообще не делая никаких настроек» — не прокатит, если мы говорим о роутинге, ведь надо еще как-то назначать адреса внутренним интерфейсам (хотя возможны хитрые варианты с EEM в случае IPv4, а у IPv6 есть свои врожденные способы реализовать эту задачу).
+1
Если надо я смогу как-то наверно сесть и дописать всетаки статью по OER/PFR которую у меня на CCIE R&S лабе попалась…
Только надо кармы будеть на циска-хаб залить
Только надо кармы будеть на циска-хаб залить
+1
Я вот пытался с ним подружиться. Всерьез пытался. Лаба, несколько тестовых роутеров, генерация трафика, прозрачный сервер для контролируемого внесения задержек/дропов с целью сделать OOP. Несколько кейсов, пара новых багов. И я так до конца и не понял, как эта сволочь должна работать.
К счастью, из нового CCIE RS его убрали. И правильно. Нечего над людьми издеваться.
К счастью, из нового CCIE RS его убрали. И правильно. Нечего над людьми издеваться.
0
да, там на пробках все завязано ) если пробы висят то все нормально,
бажит конкретно иногда — а для генерации трафика и пинга хватает на лабе.
Как лабу перетяну свою на новый рак то напишу на хабре пост )
бажит конкретно иногда — а для генерации трафика и пинга хватает на лабе.
Как лабу перетяну свою на новый рак то напишу на хабре пост )
0
если пробы висят то все нормально
Active — возможно. Fast — иногда (далеко не всегда). Dual… Собственно, с ним главные проблемы. А без него — немереное количество конфигурации, когда речь идет о сотнях соседств. Красивая идея, крайне бажная реализация. То не переключает, то переключает, но обратно не возвращает…
Ну и собственно генерация трафика была бюджетной, telnet x.x.x.x 19 в несколько потоков (вроде по 30кб/с на поток) и маленькие bandwidth на интерфейсах. А главное — все-таки возможность нормально делать задержку-потери по мере надобности, а не плясать с бубном вокруг шейпера и random-detect.
0
Как я уже написал, больше академический интерес. Необычное решение, разбирал больше из спортивного любопытства, а не ради практического применения, так как оно, очевидно, маловероятно)
А дальше будет)
А дальше будет)
0
Напоминает поведение при accept_ra=2 у линуксов (ipv6) — по мультикасту слушать о доступных машрутах с маршрутизаторов и конфигурировать свои маршруты в соответствии с. При этом ещё и самим работать маршрутизатором.
0
Ipv6 Stateless Autoconfiguration в общем-то у всех одинаков, все же стандарт.
Что линукс, что циска.
Если на маршрутизаторе применить команду ipv6 address auto-config и не применять ipv6 unicast-routing (оставить его в режиме работы IPv6 узла), то он будет генерировать сообщения RS, и принимать сообщения RA.
Что линукс, что циска.
Если на маршрутизаторе применить команду ipv6 address auto-config и не применять ipv6 unicast-routing (оставить его в режиме работы IPv6 узла), то он будет генерировать сообщения RS, и принимать сообщения RA.
0
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
ODR – On-Demand Routing