Alex Bakhtin wrote:
любителям OSPF посвящается ....
> >>>>> "BB" == Boris Bliznukov writes:
>
> 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. Или я не прав? И есть все-же какие-то
> другие способы?
Дело в том что в EIGRP это не такая большая проблема как в OSPF.
В OSPF все направлено на уменьшение routing updateов прежде всего изза того что
ЛЮБОЙ routing update вызывает LS алгоритм и пересчитывает всю(!!!) database т.е.
если в области 50 routerов -- это примерно 200 entries в LS databasе (2 линка на
router + 2 entry на линк)*50 routerов. LS алгоритм довольно сложный и
логорифмически зависит от числа роутеров ... в EIGRP НЕТУ(!) этой проблемы. EGRP
получил update сравнил с routing table и если нужно отправил соседям (я конечно
утрирую но идея такая, vector based protocols vs. state based) ...
> >> Слишком во многих местах потребуется перекопать в случае небольшой смены
> >> топологии. А фактически - это будет попытка поделить сеть на
> >> области. Смысл это делать через eigrp? IMHO намного разумнее правильно
> >> задезайнить OSPF и не мучаться;-))
>
> BB> да уж ... проблема в OSPF то что он заточен под одну топологию backbone
> BB> в центре и
> BB> лепестки с края. Если ваша топология такая то все в порядке ... если
> BB> нет то тут начинаются боольшие проблемы ... к примеру когда появляется
>
> И какие "большие"? Virtual-link сделать - большие проблемы? Да,
> кстати, с этим есть, конечно, небольшие заморочки. Леша Зинин уже писал
> драфт по этому поводу.
Нормально не получится ... или делать все в одной area и желательно 0 :) или
начинается ... пакеты вместо того чтобы ехать на прямую едет к ближайшему backbone
router а потом уже едет куда нужно ... см пример ниже
потом если делать то делать нужно как минимум 2 virtual linkа что бы роутер не
отрывался от backbonа когда проблемы с сетью начинаются ...
а как там virtual linkи через 2 арии поживают ??? :)
> BB> прямой линк между двумя OSPF area....для того чтобы это победить всякие
> BB> вещи изобретают virtual links and etc ... и тому подобные проблемы
> BB> ... к примеру LS database общая для всех роутеров в одной области и
> BB> если на одном что то глюкнуло то проблемы на всех роутерах ... изза
>
> Вот про это подробнее, пожалуйста. Про глюкнуло и проблемы...
если по какой то причине на одном из routerов повреждена LS database оно
расползается по всей арии и лечится перезапуском OSPF ... вы видимо еще не имели
удовольствия попробовать сравнивать LS db руками на 3х 4х десятках роутерах ...
> BB> общей LS database нет возможности ограничить routings updates внутри
> BB> области, а только на границе областей... соответственно нагрузка на
>
> А это нужно? В смысле - ограничивать? Надо правильно разбивать на
> области.
Пример из жизни ... 2 здания, оба имеют линк до backbone (2M leased line) ...
каждое здание в своей area ... нет проблем с дизайном ?
теперь у них появилось волокно между зданиями .... как быть ?
надо этот линк делать в area 0 и строить virtual linkи ... а теперь они 3е здание
еще подключили опять VL ?? может проще все загнать в area 0 с самого начала?
т.е. если нет ярко выраженного backbone -- OSPF это геморой ...
или другой пример ...
Frame Relay 2M в него воткнуко 200 роутеров ... multipoint interface. как бы вы
делали это в ОСПФ ?? одна ареа ну или 2 арии ... Что происходит когда один из 200
роутеров отваливается ? ВСЕ 199 роутеров РЕЗКО напрягаются на общет LS update
который они получили ....т.к. в ОСПФ НЕТ! возможности ограничить LS update внутрии
арии
как это делается в ЕИГРП ...
router eigrp 1
distribute-list 1 out inte se0.1
access-list 1 permit 0.0.0.0 0.0.0.0
и ВСЕ :) роутер упал никто не очем не беспокоится ...
только не надо в меня stup & nssa тыкать :) ... в этом случае оно ведет себя точно
также
> BB> роутер довольно высокая Cisco не рекомендует делать более 50 роутеров в
> BB> одной области ...
> Ну, циска она много что рекомендует/не рекомендует;) Вы хотите
> сказать, что с EIGRP будет лучше?
однозначно ... ОСПФ дает очень большую нагрузку на процессор
> BB> EIGRP работает на каждом роутере независимо ... можно фильтровать
> Так так, а OSPF значит работает "зависимо"? В чем это
> заключается. Да и, про EIGRP, как это оно независимо работает-то?
прочитайте пожалуйста как устроено ОСПФ в конце концов ... Что таке LS databse и
пр ...
в ЕИГРП роутер знает только своих соседей в ОСПФ роутер знает ВСЕ роутеры в своей
арии.
> BB> routings updates
> В смысле - не отдавать частям сети роутинговую информацию о
> каких-то сетках? Это да, в OSPF с этим туго;) Btw, кто бы объяснил - в
> каком случае это необходимо?
смотри выше ... hub & spoke классический пример
> BB> ... auto summary работает опять же :)
> По классам-то? Чур меня;)
сегментируйте сеть правильно :)
> Да, уж про EIGRP over NBMA я молчу.
а что вас не устраивает, конкретно пожалуйста ... с примерами ... multicata нет ?
да и бог с ним ... зато есть bandwidth control для роутинг протокола ... Чтобы в
сильно oversubscribed hub & spoke роутинг протокол не клал линк при каждом update
:) ... network type multipoint это изобретение Cisco ... если бы не это в
классическом ОСПФ (не Ciscoвском исполнении) вы так натрахаетесь с выставлением
приоритетов на интерфейсах с DR и BDR что вам Рипом только после этого и захочется
пользоватся всю оставшуюся жизнь ...
я ничего не имею против ОСПФ и даже готов его терпеть за те features которых нет в
ЕИГРП разные таблицы маршрутизации для разных ТОС и пр ...
но по доброй воле делать ОСПФ с больше чем одной арией ... чур меня (ну может 3
... нет 3 это уже много)
мне лишняя головная боль не нужна ...
> --
> 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
