>>>>> "BB" == Boris Bliznukov writes:
BB> Alex Bakhtin wrote: любителям OSPF посвящается ....
К сожалению, не было времени написать ответ сразу:-(((
IB> какие есть предпочтения OSPF перед EIGRP, если в сети нет, и не
IB> предвидеться железок отличных от cisco ???
>> >> >>
>> >> >> Иерархическая модель. Вообще, вопрос это достаточно интересный -
>> >> >> по-видимому, тема для долгого обсуждения;) На данный момент, я
>> >> >> лично не готов аргументировано сравнить эти два протокола...
IB> означает ли это, что OSPF и EIGRP в случае достаточно большой сети
IB> равнозначны ???
>> >>
>> >> Нет, отнюдь. Насколько я знаю, в EIGRP нет нормальной возможности
>> >> ограничить область распространения routing updates.
>>
BB> скорее в OSPF ... router eigrp/ distribute-list ...
>>
>> Пардон, маленькое недопонимание. Distribute-list это не то. См. ниже.
>>
>> >> Да, можно писать на каждом интерфейсе ip summary-address - но это
>> >> чревато.
>>
BB> summary addres не предназначена для ограничения routing updates .... а
BB> только для уменьшения их количества ... RTFM
>>
>> Я имею в виду, что в случае EIGRP информация о том, что где-то там
>> далеко упал канал разойдется по всему EIGRP домену, если мы во всех
>> нужных местах не проставим summary-address. Или я не прав? И есть все-же
>> какие-то другие способы?
BB> Дело в том что в EIGRP это не такая большая проблема как в OSPF. В
BB> OSPF все направлено на уменьшение routing updateов прежде всего изза
BB> того что ЛЮБОЙ routing update вызывает LS алгоритм и пересчитывает
BB> всю(!!!) database т.е. если в области 50 routerов -- это примерно 200
BB> entries в LS databasе (2 линка на router + 2 entry на линк)*50
BB> routerов. LS алгоритм довольно сложный и логорифмически зависит от
BB> числа роутеров ... в EIGRP НЕТУ(!) этой проблемы. EGRP получил update
BB> сравнил с routing table и если нужно отправил соседям (я конечно
BB> утрирую но идея такая, vector based protocols vs. state based) ...
Я в курсе про то, что процессор требуется хороший;) Так же в курсе
про vector based и state based.
>> >> Слишком во многих местах потребуется перекопать в случае небольшой
>> >> смены топологии. А фактически - это будет попытка поделить сеть на
>> >> области. Смысл это делать через eigrp? IMHO намного разумнее
>> >> правильно задезайнить OSPF и не мучаться;-))
>>
BB> да уж ... проблема в OSPF то что он заточен под одну топологию backbone
BB> в центре и лепестки с края. Если ваша топология такая то все в порядке
BB> ... если нет то тут начинаются боольшие проблемы ... к примеру когда
BB> появляется
>>
>> И какие "большие"? Virtual-link сделать - большие проблемы? Да, кстати,
>> с этим есть, конечно, небольшие заморочки. Леша Зинин уже писал драфт по
>> этому поводу.
BB> Нормально не получится ... или делать все в одной area и желательно 0
BB> :) или начинается ... пакеты вместо того чтобы ехать на прямую едет к
BB> ближайшему backbone router а потом уже едет куда нужно ... см пример
BB> ниже
BB> потом если делать то делать нужно как минимум 2 virtual linkа что бы
BB> роутер не отрывался от backbonа когда проблемы с сетью начинаются ...
Да. Есть такая буква. С чем это связано - см. ниже.
BB> а как там virtual linkи через 2 арии поживают ??? :)
Зачем???
BB> прямой линк между двумя OSPF area....для того чтобы это победить всякие
BB> вещи изобретают virtual links and etc ... и тому подобные проблемы
BB> ... к примеру LS database общая для всех роутеров в одной области и
BB> если на одном что то глюкнуло то проблемы на всех роутерах ... изза
>>
>> Вот про это подробнее, пожалуйста. Про глюкнуло и проблемы...
BB> если по какой то причине на одном из routerов повреждена LS database
BB> оно расползается по всей арии и лечится перезапуском OSPF ... вы видимо
BB> еще не имели удовольствия попробовать сравнивать LS db руками на 3х 4х
BB> десятках роутерах ...
Пример, пожалуйста. Сравнительно с EIGRP - если на одном из
роутеров повреждена routing table, она расползается по всему домену...
BB> общей LS database нет возможности ограничить routings updates внутри
BB> области, а только на границе областей... соответственно нагрузка на
>>
>> А это нужно? В смысле - ограничивать? Надо правильно разбивать на
>> области.
BB> Пример из жизни ... 2 здания, оба имеют линк до backbone (2M leased
BB> line) ... каждое здание в своей area ... нет проблем с дизайном ?
BB> теперь у них появилось волокно между зданиями .... как быть ? надо
BB> этот линк делать в area 0 и строить virtual linkи ... а теперь они 3е
Либо все-же сделать redesign и включить нужные линки в backbone...
BB> здание еще подключили опять VL ?? может проще все загнать в area 0 с
BB> самого начала?
BB> т.е. если нет ярко выраженного backbone -- OSPF это геморой ...
BB> или другой пример ... Frame Relay 2M в него воткнуко 200 роутеров
BB> ... multipoint interface. как бы вы делали это в ОСПФ ?? одна ареа ну
BB> или 2 арии ... Что происходит когда один из 200 роутеров отваливается ?
BB> ВСЕ 199 роутеров РЕЗКО напрягаются на общет LS update который они
BB> получили ....т.к. в ОСПФ НЕТ! возможности ограничить LS update внутрии
BB> арии как это делается в ЕИГРП ... router eigrp 1 distribute-list 1 out
BB> inte se0.1 access-list 1 permit 0.0.0.0 0.0.0.0 и ВСЕ :) роутер упал
BB> никто не очем не беспокоится ... только не надо в меня stup & nssa
Можно вот про это подробнее? Что будет в случае EIGRP. Мне честно,
интересно.
BB> тыкать :) ... в этом случае оно ведет себя точно также
BB> роутер довольно высокая Cisco не рекомендует делать более 50 роутеров в
BB> одной области ...
>> Ну, циска она много что рекомендует/не рекомендует;) Вы хотите сказать,
>> что с EIGRP будет лучше?
BB> однозначно ... ОСПФ дает очень большую нагрузку на процессор
Кратковременную. При нормальном дезайне некритично.
BB> EIGRP работает на каждом роутере независимо ... можно фильтровать
>> Так так, а OSPF значит работает "зависимо"? В чем это заключается. Да и,
>> про EIGRP, как это оно независимо работает-то?
BB> прочитайте пожалуйста как устроено ОСПФ в конце концов ... Что таке LS
Вы можете рассказать что-то большее, чем написано в rfc2328? Тогда
расскажите, пожалуйста, я с удовольствием узнаю для себя что-нибудь новое.
BB> databse и пр ... в ЕИГРП роутер знает только своих соседей в ОСПФ
BB> роутер знает ВСЕ роутеры в своей арии.
EIGRP знает все маршруты в домене. Это значит, что они независимы?
BB> routings updates
>> В смысле - не отдавать частям сети роутинговую информацию о каких-то
>> сетках? Это да, в OSPF с этим туго;) Btw, кто бы объяснил - в каком
>> случае это необходимо?
BB> смотри выше ... hub & spoke классический пример
BB> ... auto summary работает опять же :)
>> По классам-то? Чур меня;)
BB> сегментируйте сеть правильно :)
>> Да, уж про EIGRP over NBMA я молчу.
BB> а что вас не устраивает, конкретно пожалуйста ... с примерами
BB> ... multicata нет ? да и бог с ним ... зато есть bandwidth control для
BB> роутинг протокола ... Чтобы в сильно oversubscribed hub & spoke роутинг
BB> протокол не клал линк при каждом update :) ... network type multipoint
BB> это изобретение Cisco ... если бы не это в классическом ОСПФ (не
BB> Ciscoвском исполнении) вы так натрахаетесь с выставлением приоритетов
BB> на интерфейсах с DR и BDR что вам Рипом только после этого и захочется
BB> пользоватся всю оставшуюся жизнь ...
Вы наверное не в курсе, но тип сети point-to-multipoint есть в
стандарте ospf v2.
BB> я ничего не имею против ОСПФ и даже готов его терпеть за те features
BB> которых нет в ЕИГРП разные таблицы маршрутизации для разных ТОС и пр
BB> ... но по доброй воле делать ОСПФ с больше чем одной арией ... чур
BB> меня (ну может 3 ... нет 3 это уже много) мне лишняя головная боль не
BB> нужна ...
В OSPF есть одна основная проблема. Это то, что они сделали
маршрутизацию между областями по DV алгоритму. Если бы между областями
работал link state, не было бы необходимости распространять маршрутную
информацию через бекбон.
--
Best regards, -- Alex Bakhtin.
AMT Group, Cisco Systems Gold Partner,
=============================================================================
"inet-admins" Internet access mailing list. Maintained by East Connection ISP.
Mail "unsubscribe inet-admins" to Majordomo@info.east.ru if you want to quit.
Archive is accessible on
