Comments 34
Отличная статья!
Ну load можно манипулировать, установив для удобства небольшой BW и пустив скачку образа с другого роутера в null0. Если совсем небольшой BW ставить, то и TCP 19 можно обойтись.
Reliability? Можно попробовать сделать duplex mismatch и погнать трафик так, чтобы ошибки начали появляться.
Но в любом случае никто не рекомендует использовать данные метрики, уж больно трафик штормить будет. Сомневаюсь, что и на лабе RS такое попросят делать.
Петля для EIGRP — это почти что нормальное состояние и при совпадающих K :)
Можно еще добавить кое-что:
BW можно использовать для манипуляции трафиком. Но очень нежелательно. Типичная ошибка — слишком маленький BW, а так как EIGRP для своего служебного трафика задействует максимум 50% от BW (если мне память не изменяет), это может вызвать серьезные проблемы со сходимостью в сетях с большим числом префиксов. А вот delay ни на что не влияет кроме собственно метрики.
И во многих топологиях с разношерстными каналами имеет смысл ставить заведомо неправильный (но достаточно высокий, чтобы не мешать обмену между соседями) BW на интерфейс с целью упрощения математики и задействования ECMP.
Я честно не смог точно понять, как ведут себя от хопа к хопу reliability и load, так как эмулировать их изменение мне не удалось.
Ну load можно манипулировать, установив для удобства небольшой BW и пустив скачку образа с другого роутера в null0. Если совсем небольшой BW ставить, то и TCP 19 можно обойтись.
Reliability? Можно попробовать сделать duplex mismatch и погнать трафик так, чтобы ошибки начали появляться.
Но в любом случае никто не рекомендует использовать данные метрики, уж больно трафик штормить будет. Сомневаюсь, что и на лабе RS такое попросят делать.
Иначе каждый маршрутизатор будет считать ее по своему, и не далеко до петли.
Петля для EIGRP — это почти что нормальное состояние и при совпадающих K :)
Можно еще добавить кое-что:
регулировать мы можем только один – delay, так как bandwidth всегда несет минимальное значение пропускной способности по трассе
BW можно использовать для манипуляции трафиком. Но очень нежелательно. Типичная ошибка — слишком маленький BW, а так как EIGRP для своего служебного трафика задействует максимум 50% от BW (если мне память не изменяет), это может вызвать серьезные проблемы со сходимостью в сетях с большим числом префиксов. А вот delay ни на что не влияет кроме собственно метрики.
И во многих топологиях с разношерстными каналами имеет смысл ставить заведомо неправильный (но достаточно высокий, чтобы не мешать обмену между соседями) BW на интерфейс с целью упрощения математики и задействования ECMP.
Петля для EIGRP — это почти что нормальное состояние и при совпадающих K :)
Ну, почему так строго? DUAL работает достаточно неплохо. Петля конечно легко может образоваться при неаккуратной редистрибуции, особенно если она идет и в RIP, и в OSPF, и последние два тоже редистрибутят друг в друга. Но в простом eigrp домене создать петлю крайне затруднительно, благодаря feasible distance. Имхо.
Но в простом eigrp домене создать петлю крайне затруднительно, благодаря feasible distance. Имхо.
Да как нефиг делать. Даже без редистрибуции. И даже не используя баги, и не допуская ошибок в конфигурации, с воспроизводимостью где-то 2/3 ;) Особенно забавно это траблшутить: собрать десятки/сотни килобайт дебагов с нескольких железок и попакетно сверять, что же там EIGRP творит, от кого и в каком порядке получает UPDATE, кому шлет QUERY и получает ли REPLY, и все это с точностью до миллисекунд, до полного понимания хронологии событий и до вывода «бага не было, все вели себя корректно, просто протокол такой».
Хотя и с багами бывает весело. Например, из-за бага в redistribute static четыре железки в кольце могут угодить в SIA, по часовой стрелке ожидая ответа от соседа. Проверено. Симптом забавный: погасил интерфейс, и через какое-то время где-то на другой стороне сети железка сбрасывает соседство, так как принадлежащий тому интерфейсу префикс взял и залип.
В общем, не верьте бреду вроде «благодаря feasiblity condition даже кратковременные лупы невозможны, в отличие от link-state протоколов». Зато долговременные появляются вплоть до срабатывания active таймера…
Да, действительно, вы правы, про проблему с SIA я как то и забыл. Мало все же eigrp встречается в практике. SIA и перегруженные процессоры в результате каскадных query в реальной жизни видел может раз или два. Конечно, считаю, что для больших топологий с массой маршрутной информации лучше использовать link state протоколы. Там и с метрикой нет таких заморочек :).
Ну, все же конечно stub-ы спасают от лавин query, хотя, конечно я вашу топологию не знаю :)
Для SIA даже перегруженные процессоры и большая латентность не нужны, и количество префиксов особой роли не играет. Важен порядок распространения сообщений. Я бы, вероятно, смог вогнать EIGRP в SIA в топологии из 4-х железок и одного префикса (не считая линки между железками).
Link state тоже не одинаково полезны. Я знаю контору, в который выбрали IS-IS в качестве глобального IGP, так как OSPF в их топологии работал хреново. Про EIGRP там и речи быть не могло, с тем зоопарком.
Link state тоже не одинаково полезны. Я знаю контору, в который выбрали IS-IS в качестве глобального IGP, так как OSPF в их топологии работал хреново. Про EIGRP там и речи быть не могло, с тем зоопарком.
А вот это интересно. Если вы поделитесь способом вогнать 4 роутера в SIA, это наверное помогло бы мне в учении. Конечно, если это не хитрый секрет :-) поделитесь?
А про eigrp, link state и т.д., все же согласитесь, все очень сильно зависит от дизайна сети. Конечно, может быть полно факторов, как от зоопарка железа, так до кривых реализаций протоколов. Но, все же каждый IGP надо держать под жестким контролем, иначе прощай секундная сходимость, отказоустойчиовость и масштабируемость. Какой бы не был идеальный алгоритм, границы и диаметр сети нужно ограничивать, как и распространение query/lsa и т.д.
А про eigrp, link state и т.д., все же согласитесь, все очень сильно зависит от дизайна сети. Конечно, может быть полно факторов, как от зоопарка железа, так до кривых реализаций протоколов. Но, все же каждый IGP надо держать под жестким контролем, иначе прощай секундная сходимость, отказоустойчиовость и масштабируемость. Какой бы не был идеальный алгоритм, границы и диаметр сети нужно ограничивать, как и распространение query/lsa и т.д.
Да почти ничем. В isis нет жесткой backbone зоны, через которую все обязательно должны проходить, ну и еще он независим от маршрутизируемого протокола, т.е. он может распространять маршрутную информацию как IPv4, так и IPv6, и т.д. По сути он работает на L2 поверх CLNS. По этому он немного непривычен в администрировании и обучении.
Не совсем конечно корректное сравнение, так как isis все же link state IGP. Но если совсем-совсем грубо, то да. Но преимущества в интеграции IPv6 сомнительны, с тем же успехом можно гонять dual stack с OSPFv3 или тем же EIGRP for IPv6. Кстати, что интересно, EIGRP изначально был разработан как протокол, который мог роутить что угодно, как IP, так и AppleTalk и IPX.
Помимо радикальных различий в устройстве бекбона, их эксперименты показали, что и в пределах области, когда сеть широкая и с кучей колец, OSPF может сильно тормозить. Глубже я не вдавался. Сам я знаю IS-IS в рамках полузабытого курса BSCI, то есть слабо знаю :)
Если коротко и сходу:
1. ISIS поддерживает MTR
2. ISIS поддерживает IPv6 (в случае с OSPF нужно поднимать отдельный протокол OSPFv3, а это дополнительная нагрузка на control plane телеком оборудования)
3. масштабируемость у ISIS выше (сравните ограничение LSP и LSA, которые упираются в MTU для OSPF)
4. ISIS использует CLNS пакеты, в то время, как OSPF IPшные. В глобальной сети Интернет, CLNS пакеты не маршрутизируются, а значит такая сеть более безопасна с точки зрения сетевой безопасности (вектор атаки снижается).
5. ISIS протокол открытый и для него фичи выходят раньше, чем для OSPF.
6. ISIS проще с точки зрения network design (не надо заморачиваться с типом area).
7. ISIS поддерживает приоритезацию префиксов :)
ну и т.д. и т.п.
PS: Проблема в том, что большинство людей не умеют его правильно траблшутить :-)
1. ISIS поддерживает MTR
2. ISIS поддерживает IPv6 (в случае с OSPF нужно поднимать отдельный протокол OSPFv3, а это дополнительная нагрузка на control plane телеком оборудования)
3. масштабируемость у ISIS выше (сравните ограничение LSP и LSA, которые упираются в MTU для OSPF)
4. ISIS использует CLNS пакеты, в то время, как OSPF IPшные. В глобальной сети Интернет, CLNS пакеты не маршрутизируются, а значит такая сеть более безопасна с точки зрения сетевой безопасности (вектор атаки снижается).
5. ISIS протокол открытый и для него фичи выходят раньше, чем для OSPF.
6. ISIS проще с точки зрения network design (не надо заморачиваться с типом area).
7. ISIS поддерживает приоритезацию префиксов :)
ну и т.д. и т.п.
PS: Проблема в том, что большинство людей не умеют его правильно траблшутить :-)
Добавлю:
к пункту 5:
ISIS использует TLV, а OSPF использует LSA. Из реальных примеров, Forwarding Adj для ISIS реализовали раньше, механизм сигнализации BGP Wait on Start и т.д. и т.п. MPLS TE Extensions.
В общем для операторов c IP/MPLS бекбоном самое то ;-)
к пункту 5:
ISIS использует TLV, а OSPF использует LSA. Из реальных примеров, Forwarding Adj для ISIS реализовали раньше, механизм сигнализации BGP Wait on Start и т.д. и т.п. MPLS TE Extensions.
В общем для операторов c IP/MPLS бекбоном самое то ;-)
Я правильно понимаю, можно определённый префикс отдать в определённый линк с меньшим костом, чем на этом линке для всех остальных?
Нет, приоритезация префиксов не для этого. Механизм приоритезации префиксов скорее имеет отношение к конвергенции сети. В реальности это фича становится крайне полезной в очень больших сетях с большим объемом маршрутной информации и при наличии критически важных префиксов, где задержка в несколько мс может быть критичной. Например — VoIP, Video Conference, HD Video, Телеметрия и т.д. и т.п.
В OSPF для этого придётся с разными областями заморачиваться.
Заморочиться можно разными способами. Например опять же с MTR :) Но это противоречит основному принципу keep it simple.
Кстати, если я правильно Вас понимаю, то у Вас там IP/MPLS сеть. Хотел бы Вас предупредить, что как только Вы побьетесь на area у Вас могут появиться пролемы с функциональностью MPLS TE. Проблемы возникнут из-за потери ERO. В общем, подумайте 10 раз ;-)
Вообще можете посоветовать книжку с адекватным описанием IS-IS?
Раз — www.amazon.com/Network-Design-Solutions-Networking-Technology/dp/1578702208
Два — www.cisco.com/go/isis
Нет, приоритезация префиксов не для этого. Механизм приоритезации префиксов скорее имеет отношение к конвергенции сети. В реальности это фича становится крайне полезной в очень больших сетях с большим объемом маршрутной информации и при наличии критически важных префиксов, где задержка в несколько мс может быть критичной. Например — VoIP, Video Conference, HD Video, Телеметрия и т.д. и т.п.
В OSPF для этого придётся с разными областями заморачиваться.
Заморочиться можно разными способами. Например опять же с MTR :) Но это противоречит основному принципу keep it simple.
Кстати, если я правильно Вас понимаю, то у Вас там IP/MPLS сеть. Хотел бы Вас предупредить, что как только Вы побьетесь на area у Вас могут появиться пролемы с функциональностью MPLS TE. Проблемы возникнут из-за потери ERO. В общем, подумайте 10 раз ;-)
Вообще можете посоветовать книжку с адекватным описанием IS-IS?
Раз — www.amazon.com/Network-Design-Solutions-Networking-Technology/dp/1578702208
Два — www.cisco.com/go/isis
Если мне не изменяет память, EIGRP передаёт векторную метрику при изменении BW или delay. При добавлении в расчёт reliability и load это поведение не меняется.
То есть EIGRP будет использовать те reliability и load, которые получил когда-то давно, они могут сто раз измениться где-то там в сети, но никто об этом не узнает и метрика не изменится.
То есть никаких «штормов» метрики не будет. Будет просто её расчёт исходя из ранее запомненных, неактуальных, уже не нужных никому значений.
То есть EIGRP будет использовать те reliability и load, которые получил когда-то давно, они могут сто раз измениться где-то там в сети, но никто об этом не узнает и метрика не изменится.
То есть никаких «штормов» метрики не будет. Будет просто её расчёт исходя из ранее запомненных, неактуальных, уже не нужных никому значений.
Да, но непонятно, будет взято худшее значение на маршруте, или оно как то будет суммироваться?
Reliability is the worst reliability for any interface in the path. Load is cumulative.
Что, в принципе, логично, поскольку 100% надёжность — уже 255, больше некуда суммировать. С загрузкой — наоборот.
Что, в принципе, логично, поскольку 100% надёжность — уже 255, больше некуда суммировать. С загрузкой — наоборот.
Ясно, загрузка по ходу суммируется покуда не упрется в 255.
Load берется максимальный на всем пути.
Суммировать было бы странно. Если у нас последовательно два 10G интерфейса, и через них идет поток в 5G, то что, выкинуть весь путь из path selection?
Суммировать было бы странно. Если у нас последовательно два 10G интерфейса, и через них идет поток в 5G, то что, выкинуть весь путь из path selection?
• Load (K2) – Cumulative load of all outgoing interfaces in the path, given as a fraction of 255
Источник: www.routeralley.com/ra/docs/eigrp.pdf
Почему выкинуть? Ведь максимума достигла не композитная метрика, а всего лишь одно из её слагаемых.
Источник: www.routeralley.com/ra/docs/eigrp.pdf
Почему выкинуть? Ведь максимума достигла не композитная метрика, а всего лишь одно из её слагаемых.
learningnetwork.cisco.com/docs/DOC-8176
Оба источника неофициальные. Оба автора могут ошибаться. Надо бы потестить, но лень…
Хотя тоже верно. Но все равно чистое сложение бессмысленно. Вот дробь с 255 — ближе.
If used, enter worst load between source and destination.
Оба источника неофициальные. Оба автора могут ошибаться. Надо бы потестить, но лень…
Ведь максимума достигла не композитная метрика, а всего лишь одно из её слагаемых.
Хотя тоже верно. Но все равно чистое сложение бессмысленно. Вот дробь с 255 — ближе.
Пепельняк в своей книге тоже говорит, что худший load выбирается…
Да всем лень тестить, и авторам в том числе. Зачем тестить то, что использоваться точно не будет? :)
Да всем лень тестить, и авторам в том числе. Зачем тестить то, что использоваться точно не будет? :)
Ну как бы автор книги (особенно если Cisco Press) должен говорить как есть и отвечать за свои слова :)
Но есть другой нюанс. В какой-то момент поведение Load могли и поменять…
В общем, черт с ним, этим действительно никто не будет пользоваться.
Но есть другой нюанс. В какой-то момент поведение Load могли и поменять…
В общем, черт с ним, этим действительно никто не будет пользоваться.
Там в каждой книге в начале сказано, что мы конечно хоть и Cisco Press, но вся инфа as is, и нам как бы все равно :-). Вообще в Cisco Press литературе очень много ошибок, практически в каждой книге. От синтаксиса, до базовых понятий, недавно читал в какой то книге по дизайну, что свет распространяется со скоростью несколько миль в секунду.
Sign up to leave a comment.
Композитная метрика EIGRP