Pull to refresh

Comments 36

А почему не использовать такой замечательный параметр, как variance? Специально для таких случаев существует, чтобы не возиться с интерфейсами.
Я писал, что вариантов решения вопроса с балансировкой может быть несколько. Вы упоминаете variance, если честно, я его не стал использовать, так как у меня не заработало все должным образом, поэтому и решил попробовать вариант с delay, а вообще с variance все проще по идее. Задаете множитель variance, на который будет умножаться FD текущего лучшего маршрута для определения feasible маршрутов.
А что именно не заработало? Маршруты в таблицу не добавлялись, или трафик не ходил? Чудес-то не бывает.
[telepathy]
Скорее всего, проблема была в том, что не устанавливались feaseable successors.
[/telepathy]
ага очень походит на правду
К сожалению, сейчас точно сказать не могу, трафик не ходил, точно. Но тогда я был очень неопытным в плане оборудования CISCO, можно будет как-нибудь попробовать с variance =)
А вообще, это общепринятая практика использование bandwidth и delay. Играясь с этими параметрами можно разные эффекты получать. Например, когда у нас есть несколько каналов с разной стоимостью трафика. или каналы с разной надежностью, например, есть радио-релейный канал, на котором много ретрансмиттов и канал по оптике и нам нужно, чтоб по умолчанию работала «оптика» а когда она рвется (не приведи господи) использовался радио-релейный. Благодаря variance мы можем сделать так, что маршрута через релейный канал не будет, пока не упал «оптический» интерфейс. Вообще, когда цыска подключена эзернетами к различным модемам, с разной пропускной способностью, и топология сети сложная, нам в любом случае приходится придется прописать bandwidth на интерфейсах в соответствии с реальной пропускной способностью модемов. Так меньше вероятность наступить на грабли с load balancing-ом.
Действительно, если задуматься, то полезных применений комбинирования bandwith и delay можно найти очень много. У нас кстати на одном из объектов используется радио-релейный канал, мягко говоря это — жесть… Туман выпал и увсё :-D
А меня больше заинтересовали ваши линки в сеть ID с per-packet load balancing. На нескольких каналах (возможно, еще и разной толщины) порядок пакетов почти гарантированно будет нарушаться. Пробовали пускать туда голос/видео? Как они себя чувствуют?
Цель данной сети: передача телеметрической информации по телемеханическим протоколам МЭК 60870-5-104, да и ширина каждого канала всего 1 тайм-слот, т.е 56 кбит/c… Соответственно ни о аудио и тем более о видео мечтать не приходится. Протокол МЭК инкапсулируется в TCP и работает вроде без нареканий.
Цель данной сети: передача телеметрической информации по телемеханическим протоколам МЭК 60870-5-104, да и ширина каждого канала всего 1 тайм-слот, т.е 56 кбит/c… Соответственно ни о аудио и тем более о видео мечтать не приходится. Протокол МЭК инкапсулируется в TCP и работает вроде без нареканий.
Хотел спросить совета у более опытных хабровцев. Итак:
20 февраля я написал статью, 21 опубликовал её в песочнице под названием «Балансировка нагрузки между двумя каналами в динамической маршрутизации EIGRP». 3 марта один замечательный человек прислал мне инвайт и рекомендовал отредактировать и дополнить статью, статья попала в черновики. Сегодня у меня дошли руки, я добвил небольшую теоретическую часть, непосредственно, расчет задержки для моего примера и вставил пару изображений из мониторинга нагрузки интерфейсов.
Сегодня один пользователь написал мне в личку, что видел подобный топик в песочнице и на стороннем ресурсе; в песочнице понятно была моя статья, до получения мною инвайта, но вот на стороннем блоге, я сам увидел и офигел...21 февраля, когда моя первая редакция статьи попала в песочницу её увели :'(
Первая статья и такое начало, если честно, не ожидал…
Хочу спросить совета, что делать в дальнейшем, чтобы обезопасить себя от кражи и подозрения в плагиате? Ставить копирайты по типы водяных знаков на изображения?
P.S. Написал тоже в саппорт…
Спасибо за статью, есть несколько косметических вопросв и рекомендаций, если вы не против:
— зачем на схеме сети присутствует ID, если она никак не участвует далее?;
— из генерируемого выводы хорошо бы убрать всё ненужное, заменив его на «вывод пропущен» или что-нибудь подобное — сильно увеличит читабельность;
— проверьте как просто работает variance и добавьте в статью, потому что это базовое средство load balancing между каналами с разной метрикой, иначе эта статья про то как высчитать правильное число;
— по умолчанию значение maximum-paths у EIGRP равно 4 для каналов с одинаковой метрикой, так что можно и забыть изменить;
— я так понял маршрутизаторы в IE находятся под вашим административным контролем? Что если маршрутизаторы в IE, после каких-либо манипуляций, начнут говорить иной AD? Снова будете считать? Логичнее будет использовать именно variance, либо, раз уж совсем не выходит ввести одну команду (variance 2), настроить именно маршрутизаторы офиса IE на отдачу необходимых для балансировки AD. Тем более «Route is External», а значит можно указать правильные BW & DLY уже при редистрибуции.

В-любом случае, спасибо за статью, всегда с интересом читаю статью про Cisco :)
1) Я изначально хотел добавить статью по статической маршрутизации тоже, но потом уже когда нарисовал схему, решил, что это совсем элементарно и не нужно здесь…
2) Постараюсь убрать лишнее, когда появится время.
3) variance 2, пробовал первоначально, но ничего не работало, попробую при наличии времен и при успехе добавлю в статью.
4) Про значение по умолчанию maximum-paths не знал, спасибо, приму к сведению
5) Да маршутизаторы в IE и в «нашей сети» по моим контролем.

Спасибо за интерес к статье, не могли бы Вы дать рекомендации по variance, изначально пробовал и не получалось, попробую снова в воскресенье =)
Русскоязычная информация, достаточная для ваших изысканий на тему балансировки нагрузки через пути с разной метрикой: xgu.ru/wiki/EIGRP
Статья о том, что автор не знает, что можно использовать variance?
Настраивать что-то на портах ниразу не очевидно, да и если вы вдруг решите что-то добавить еще один канал — снова будете задержку настраивать?
Статья не о том, что автор не знает, что можно настраивать variance, а о одном из возможных вариантов настройки балансировки трафика по ДВУМ каналам. Можно говорить много если, статья есть и она описывает возможность настройки EIRGP варьируя таким параметром, как задержка и рассматривается пример настройки данного параметра для реальной системы. Третий канал не появится, а если и что-то произойдет, то это уже не ваш вопрос…
Да конечно — это не мой вопрос.

Прошу прощения, если я грубовато выразился, но я думаю, что статья скорее вредная, чем полезная, т.к. вы показываете дурной пример. По крайней мере вам следовало бы добавить в статью информацию о том, как ПРАВИЛЬНО решить проблему, а не создавать подпорку, которая потом может чем-то аукнуться.
вариант с variance обсуждается в рамках курса CCNA, тогда как вариация delay и bandwith на более продвинутых уровнях, и статья будет полезной, так как расширяет кругозор. Многим людям она понравилась, и её добавили в избранное, я опираюсь на мнение большинства, а не на ваше частное мнение.
P.S. И вообще почитал ваши комменты и сделал для себя выводы, успехов
А можно мне для расширения кругозора уточнить — а на каких более продвинутых уровнях это обсуждается? Просто всегда хотел получить систематизированные и глубокие знания о сетях, но как то не удалось.
И кстати по поводу CCNA — а насколько глубоко там изучают EIGRP?
Я сам проходил только курсы ICND1 и ICND2 в рамках общего курса CCNA, EIGRP изучается в ICND2 в разделе маршрутизация также, как и RIP, OSPF. Хотя, на мой взгляд EIGRP уделяется большее внимание, так как это детище CISCO. При сдаче экзамена на CCNA в практике точно не понадобиться варьировать delay и bandwith, там как раз рассматривается вариант с variance, который у меня когда-то не заработал, поэтому и пришлось идти на хитрость ;)
Со слов более опытного приятеля подобные вещи с delay и bandwith рассматриваются в более продвинутых треках CCNP и возможно в CCNE, более подробную информацию о ступенях сертификации и топкиах, рассматриваемых в конкретных треках вы можете ознакомиться на официальном сайте cisco
А можно нескромный вопрос — почему вы выбрали именно EIGRP?
Можно, я не выбирал, я уже пришел, когда система работала и некоторые вещи не совсем так, как надо, а вносить изменения в работающую систему крайне сложно, так как это связано с согласованием со многими службами, потому что система работает в СПД промышленных объектов, которых ни один и ни два…
Как человек сдавший CCNP:ROUTE могу сказать, что вопрос манипуляций с EIGRP-метрикой довольно подробно рассматривается в свете редистрибуции маршрутов.
Несколько раз сталкивался в лабах с задачей именно уровнять метрики, чтобы EIGRP считал, что это equal-paths load-balancing, несмотря на то что имелся FS и можно было всего лишь изменить значение variance.
Чтобы понять когда игра с метриками полезна достаточно представить, что в вашей топологии 3 канала, один широкий(Ш) и два одинаковых узких(У), при этом трафик должен балансироваться между 1Ш и 1У, а второй У, является FS и ждет своей очереди. В этом случае изменение variance приведет к балансировке между всеми доступными путями, что нарушит условия, в отличие от варианта с игрой метрик.
О как все интересно, не порекомендуете литературу, где все это описывается с разбором практических задач =)
Конечно, мне очень понравилась книга Ivan Pepelnjak «EIGRP Network Design Solutions» как и его чудесный блог blog.ioshints.info/
Спасибо =) Обязательно посмторю
Вариант с variance будет добавлен, когда доберусь до работы и оттестирую =)
И вообще читайте внимательно, я писал что это ОДИН из нескольких вариантов решения проблемы и она не самое элегантное и логичное, так как может затруднить траблшутинг.
Подскажите, в какой программе графики загрузки интерфейсов сделаны?
WhatsUp Gold =) Отличная программа, но дорогая и лицензируется в зависимости от количества девайсов, которые мониторятся. Насколько я знаю есть аналогичные бесплатные вещи, знающие могу подсказать здесь =)
WhatsUp Gold это совсем не отличная программа :)
Фичей в неё понапихали уйму, но реализация их…
У variance и ручного допиливания метрики на самом деле разные цели.
Variance решает какие линки из существующих (тех кто прошёл feasibility condition) будут участвовать в балансировке.
Игра с метрикой решает какой процент траффика пойдёт через каждый из линков.
Игра с метрикой на соседях влияет на то, кто пройдёт feasibility condition, а кто нет.

Это так, чтоб мухи отдельно, котлеты отдельно :)
Sign up to leave a comment.

Articles