Привет, незнакомец!

Похоже, вы здесь новенький. Чтобы принять участие, нажмите одну из кнопок ниже!

Смысловые ошибки в Официальных гайдах по сертификации (рапространение LSA внутри зоны)

отредактировано апреля 2016 Раздел: Динамическая маршрутизация
Читаю гайд по циске от Кэвина Валласа по экзамену CCNP ROUTE 300-101,
Вижу:
такая топология:

Что пишет видно да? И еще что это типо Loop prevention механизм для LSA... Думаю, "чет не так... я думал DBD только в начале при установлении Adjacency используют, даже если так тогда, что DBD пакеты останавливает от зацикливания..."
Проверяю (добавляю нового соседа - R5 в топологию):

в топологии:


Точно что то не так. Но похоже не у меня:)

Вопрос - Кто дурак? В гайде ошибки?
1. LSA останавливаются за счет sequence - номеров и LSID от зацикливания?
2. При добавлении соседа через p-t-p линк, роутер (в моем случае R4, у Кэвина Валласа R2) не собирается никакие DBD/LSR отправлять в другие сети, только LSU + придут ему LSAck?
Тэги темы:
«1

Комментарии

  • отредактировано марта 2016
    Вроде верно, у Кевина R2 в BMA сети, значит, об обновлениях он сообщит DRу, а DR распространит. На твоей схеме кто DR? не R4? если да, то поэтому нет в дампе DBD сообщений, а вот подтверждения на 224.0.0.6 (all DR) есть.

    по номерам sequence маршрутизатор определяет свежесть обновления:
    если больше, то свежее и можно изучить и передать другим;
    если то же, то ничего не делать;
    если меньше, то значит у отправителя старая база, надо ему ответить обновлением.
    как то так, примерно.

    если вру - поправьте))
  • DR - R6 в моей топологии.
    R4 был BDR, но я попробывал сейчас как DROTHER его поставить - результат абсолютно тот же, никаких DbD в сети 10.100.1.0/24 нету, только что R4 так шлет LSU на 224.0.0.6 теперь (вместо 224.0.0.5, как он делал, когда он был BDR...).

    Вопрос был в том как вообще DbD в другую подсеть и LSR должны попасть? я думал они только для установления соседства используются (по крайней мере DD). А Кэвин пишет, что типо DBD и LSR и в другой сети (с установленными adjacency) должны оказаться, и еще, что они таким образом и предотвращают петли. Но как я Вижу в своей симуляции - то Кэвин неправ.
    aleksei_boroda написал:

    если меньше, то значит у отправителя старая база, надо ему ответить обновлением.

    - этого я не знал, спасибо, проверить правда сложновато наверно.
    aleksei_boroda написал:


    если больше, то свежее и можно изучить и передать другим;
    если то же, то ничего не делать;

    Ну и чем это не разрыв петли LSA-ев ?
  • отредактировано марта 2016
    Packo написал:

    Читаю гайд по циске от Кэвина Валласа по экзамену CCNP ROUTE 300-101,

    Точно что то не так. Но похоже не у меня:)

    Вопрос - Кто дурак? В гайде ошибки?
    1. LSA останавливаются за счет sequence - номеров и LSID от зацикливания?
    2. При добавлении соседа через p-t-p линк, роутер (в моем случае R4, у Кэвина Валласа R2) не собирается никакие DBD/LSR отправлять в другие сети, только LSU + придут ему LSAck?

    1. Нет у нас зацикливания, потому что мы можем определить какой LSA более новый. Если мы потом этот же LSA получаем снова, то мы можем определить, что это дупликат, поэтому ничего с ним не делаем (отбрасываем). Алгоритм сравнения LSA:
    1) Compare the sequence numbers. The LSA with the highest sequence number is more recent.
    2) If the sequence numbers are equal, then compare the checksums. The LSA with the highest unsigned checksum is the more recent.
    3) If the checksums are equal, then compare the age. If only one of the LSAs has an age of MaxAge (3600 seconds), it is considered the more recent.
    4) If the ages of the LSAs differ by more than 15 minutes (known as MaxAgeDiff), the LSA with the lower age is more recent.
    5) If none of the preceding conditions are met, the two LSAs are considered identical.

    2. Всё так, DBD важны только при установлении adjacency. Другим соседям мы отправляем LSU+LSack (Flooding). И это нормально, что в гайде ошибки. Я вам скажу больше, в CCIE Official Certification Guide их тоже хватает :)
  • отредактировано марта 2016
    dmfigol написал:


    И это нормально, что в гайде ошибки. Я вам скажу больше, в CCIE Official Certification Guide их тоже хватает :)

    Специально делают?:)
    dmfigol написал:


    Алгоритм сравнения LSA:

    Чуть сложнее чем я думал :) для CCIE все эти детали важны да? может проще написать свою реализацию OSPF :))
    UPD. Хотя в целом всё логично, я только про контрольную сумму не знал.
  • отредактировано марта 2016
    Packo написал:

    dmfigol написал:


    И это нормально, что в гайде ошибки. Я вам скажу больше, в CCIE Official Certification Guide их тоже хватает :)

    Специально делают?:)
    Я думаю, что авторы просто не помнят всех деталей - их там слишком много, и это нормально :) Единственная проблема - ты можешь выучить вначале неправильно, а потом думаешь, что всё понимаешь, пока более знающий коллега не поправит. Оказывается, что понимал неправильно :)
    Очень показательный пример - EIGRP Feasible Distance :)
    Packo написал:

    dmfigol написал:


    Алгоритм сравнения LSA:

    Чуть сложнее чем я думал :) для CCIE все эти детали важны да? может проще написать свою реализацию OSPF :))
    UPD. Хотя в целом всё логично, я только про контрольную сумму не знал.
    Для written - может быть, для лабы - всё равно.
  • отредактировано марта 2016
    dmfigol написал:


    Очень показательный пример - EIGRP Feasible Distance :)

    Спасибо, теперь у меня проблемы и с FD :)

    Может имеют ввиду DUAL не запускается, когда Successor отвалился? (хотя я этого не знаю)
  • отредактировано марта 2016
    Packo написал:

    dmfigol написал:


    Очень показательный пример - EIGRP Feasible Distance :)

    Спасибо, теперь у меня проблемы и с FD :)

    Может имеют ввиду DUAL не запускается, когда Successor отвалился?
    Welcome to an amazing world of CCIE preparation :)
    Нет, имеют в виду то, что написано :) Может придти UPDATE, который увеличит текущую лучшую метрику. Маршрут в Active не уйдет, но FD не поменяется и будет меньше, чем метрика лучшего маршрута в topology table.
  • Из последнего,что заметил. Посмотрите вопрос и ответы на него.
    Ответ "a" - понятно. Но "e"? По факту сурсом становится юникаст адрес helper интерфейса. Может, я что-то упускаю из виду?
    q.PNG 50.4K
    a.PNG 8K
  • k4route написал:

    Из последнего,что заметил. Посмотрите вопрос и ответы на него.
    Ответ "a" - понятно. Но "e"? По факту сурсом становится юникаст адрес helper интерфейса. Может, я что-то упускаю из виду?

    Как вариант автор писал на бумаге, потом переносил в электронный формат, e и c очень похожи... :)
  • отредактировано марта 2016
    dmfigol написал:

    Packo написал:

    dmfigol написал:


    Очень показательный пример - EIGRP Feasible Distance :)

    Спасибо, теперь у меня проблемы и с FD :)

    Может имеют ввиду DUAL не запускается, когда Successor отвалился?
    Welcome to an amazing world of CCIE preparation :)
    Нет, имеют в виду то, что написано :) Может придти UPDATE, который увеличит текущую лучшую метрику. Маршрут в Active не уйдет, но FD не поменяется и будет меньше, чем метрика лучшего маршрута в topology table.
    А разве этот update не будет попадать в Feasible Coundition? Таким образом, если его (роутера что послал update) Reported (Advertise) Distance будет меньше чем RD (AD) текущего Successor (чье RD-AD превращается в FD путем добавления метрики на текущем маршрутизаторе)
    Он должен стать либо Condidate Succsessor или сменить Successor-а.
    Могу заблуждаться и слегка плаваю в этой теме :) Буду рад пояснениям.
  • feo_sobolev написал:

    dmfigol написал:

    Packo написал:

    dmfigol написал:


    Очень показательный пример - EIGRP Feasible Distance :)

    Спасибо, теперь у меня проблемы и с FD :)

    Может имеют ввиду DUAL не запускается, когда Successor отвалился?
    Welcome to an amazing world of CCIE preparation :)
    Нет, имеют в виду то, что написано :) Может придти UPDATE, который увеличит текущую лучшую метрику. Маршрут в Active не уйдет, но FD не поменяется и будет меньше, чем метрика лучшего маршрута в topology table.
    А разве этот update не будет попадать в Feasible Coundition? Таким образом, если его (роутера что послал update) Reported (Advertise) Distance будет меньше чем RD (AD) текущего Successor (чье RD-AD превращается в FD путем добавления метрики на текущем маршрутизаторе)
    Он должен стать либо Condidate Succsessor или сменить Successor-а.
    Могу заблуждаться и слегка плаваю в этой теме :) Буду рад пояснениям.
    FC относится только к выбору FS, а я говорю о Successor. Метрика Successor может увеличиться, префикс в Active не уйдёт, а FD останется неизменным. В итоге FD != Calculated Distance of Successor. Раньше я думал, что это баг, так как иногда встречал такое в лабе, теперь понимаю, что просто не хватало знаний :)
    Я буду подробно рассказывать про FC/FD/метрику и тд в вебинаре по EIGRP.
  • Про EIGRP могу подкинуть на вентилятор пищи для размышления. Допустим, у роутера R1 есть три некстхопа до сети назначения. Один - successor, второй - feasible succesor, а третий не попадает под условия FC, НО! CD (computed distance) от R1 до сети назначения через этот третий некстхоп меньше, чем через feasible successor (да, такое возможно). Дак вот в тот момент, когда successor отпадет, R1 переведет маршрут до сети назначения в Active, повысит FD до сети до infinite значения и будет выбирать маршрут до сети (запустит local computation "локальное вычисление"). Хотя казалось бы при живом FS, зачем ему это делать? Дак вот, как оказалось для меня новостью когда-то, что по сути своей feasibility condition гарантирует отсутствие петель, но не гарантирует кратчайший маршрут до сети назначения.
    Поэтому после перехода маршрута в состояние passive sucessor'ом станет третий маршрутизатор.
    PS: Сеть назначения - 192.168.0.0/24 доступна через три маршрутизатора с адресами 10.2.2.2, 10.3.3.2 и 10.4.4.2.

    Нам такого ни на каком CCNP не рассказывали, вычитал только в книге. :)
  • Jay-T написал:

    CD (computed distance) от R1 до сети назначения через этот третий некстхоп меньше, чем через feasible successor (да, такое возможно).

    А почему это она меньше?
  • Выставив все k-value в 0, кроме k3, который множится на delay, можно выставить этот самый delay на интерфейсах, как указано на картинке.
  • Jay-T написал:

    Понял, CD маршрута#3 меньше CD для FS, но RD маршрута#3 больше FD
    И почему это он не использует FS, я думал условие для запуска процесса поиска маршрутов через Query - отсутствие любых маршрутов (S/FS) в Topology table EIGRP ?
  • отредактировано марта 2016
    If the link between R1 and R2 fails, the common belief is that R1 would first check
    whether it has a Feasible Successor available—and it does indeed; it is R3—so it would
    be promoted to the Successor role and R1 would install a route to the LAN through R3.
    This would not be correct, however. If R1 was simply satisfied with R3, it would be using
    a workable but not necessarily the shortest available path, and would never explore the
    possibility of using a shorter path. What really happens in EIGRP is the following:
    1) Whenever EIGRP detects a topology change, it first records the change into the
    topology table and updates the RD and CD of the neighbor that advertised the
    change (in case of a received EIGRP message) or was influenced by it (in case of a
    link metric change).
    2) From among all neighbors that advertise the network, EIGRP identifies the one that
    provides the least CD, taking into account the updated CDs. Note that the FC is not
    invoked at this step.
    3) Only after identifying the neighbor offering the least CD, EIGRP verifies whether
    this neighbor meets the FC and is therefore a Feasible Successor. If it is, EIGRP will
    promote it to the Successor and start using it right away. If, however, that neighbor
    does not meet the FC, EIGRP will put the route into the Active state and send out
    Queries, asking its neighbors to assist in locating the best route.

    In other words, EIGRP—just like any other routing protocol—always tries to choose the
    shortest path toward a destination, but before using it, EIGRP verifies whether it meets
    the FC to be loop-free. If it does, EIGRP will use it. If it does not, EIGRP puts the desti-
    nation into the Active state.

    (с) CCIE R&S v5.0 Official Guide Volume 1, p393. Narbik K.
    Плюс ещё вырезка из draft-savage-eigrp. https://tools.ietf.org/html/draft-savage-eigrp-00 (стр.9)
  • отредактировано марта 2016
    Jay-T, спасибо. Познавательно. Я знал, что он выберет R3, но думал, что это будет исключительно благодаря UPDATE (без перехода в Active). Оказалось нет, если у нас этот лучший маршрут (но не FS) есть уже в Topology Table или пришел Update с лучшей метрикой, то префикс перейдёт в Active, как и вы написали.
    Кстати, вы наверняка не использовали delay 3 на R3 e0/0, да? Если нет, то советую попробовать и повторить тест снова :)
  • отредактировано марта 2016
    Вот еще из тойже книги:

    пробую:

    пробую с summary-address, вроде первые несколько секунд работает, а потом...:


    Опять ошибка автора? или эксперимент недостаточно чист?:)

  • отредактировано марта 2016
    Packo написал:

    Вот еще из тойже книги:

    пробую:

    пробую с summary-address, вроде первые несколько секунд работает, а потом...:


    Опять ошибка автора? или эксперимент недостаточно чист?:)

    Хмм, странно, для того, чтобы в нужную Area анонсировать дефолт ее треубется перевести в Totally Stub, или в Totally NSSA (если в той Area будет иметь место ASBR).
    А команда area-range используется для суммирования маршрутов, но не создания дефолта (Как я понял из F.L.G)
    например для того чтобы несколько маршрутов /24 анонсировать как 192.168.0.0/21
  • отредактировано марта 2016
    Packo написал:

    Вот еще из тойже книги:


    Опять ошибка автора
    ? или эксперимент недостаточно чист?:)

    Нельзя в OSPF анонсировать Default с помощью area range или summary address.

    http://www.cisco.com/c/en/us/td/docs/ios-xml/ios/iproute_ospf/command/iro-cr-book/ospf-s1.html#wp4241563273
    Если быть более точным, то команда работает и автоматически добавляет not-advertise.
    Для area range нужной строки в документации не нашёл, но сообщение в логах говорит само за себя :)
  • отредактировано марта 2016
    dmfigol написал:


    OSPF does not support summary-address 0.0.0.0 0.0.0.0.

    Блин, а еще такие деньги просят за книгу... они не могут проверять то, что пишут?:) Надеюсь в CCIE R&S от Narbik не такое количество ошибок :)
  • Packo написал:

    dmfigol написал:


    OSPF does not support summary-address 0.0.0.0 0.0.0.0.

    Блин, а еще такие деньги просят за книгу... они не могут проверять то, что пишут?:) Надеюсь в CCIE R&S от Narbik не такое количество ошибок :)
    Ты будешь неприятно удивлён. :D
  • Jay-T написал:


    Ты будешь неприятно удивлён. :D

    А, что читать, чтобы быть приятно удивленным?:) нету в сети чего-нибудь типа CCNA Exploration , только для CCNP ? :)

  • Packo написал:

    Jay-T написал:


    Ты будешь неприятно удивлён. :D

    А, что читать, чтобы быть приятно удивленным?:) нету в сети чего-нибудь типа CCNA Exploration , только для CCNP ? :)

    Routing TCP/IP Volume 1. Не помню, чтобы там были ошибки. Хотя тоже наверняка можно найти :)
  • отредактировано марта 2016
    Плюсую Routing TCP/IP! :) Вообще я бы книгу Нарбика не отметал. Из неё можно начать черпать всё по-немногу. Текст вполне понятный, плюс все эти протоколы в версии IPv6 рассмотрены. По крайней мере можно начать с этой книги, а после нее брать по конкретным темам, будь то Multicast Deployment или IPv6 Fundamentals и прочие MPLS. По крайней мере я так планировал. Я не могу сказать, что CCIE RS OCG от Нарбика плохая книга. Она нормальная, но с учётом допущенных там ошибок приходится всё время думать и собирать лабы для проверки. :)
  • Попробовал с указанием на R3 eth0/0 delay 3. И может я что-то упускаю, но различий со стороны R1 я не увидел. Да и их не должно быть, насколько мне известно, ведь delay считается с исходящих интерфейсов на пути к сети назначения. Можно подумать, что трафик от R3 до сетей R1-R2 и R1-R4 будет ходить через R1 после уменьшения delay на eth0/0, но оно так и ходило, потому что на shared сегменте соседство у меня не устанавливается. :)
  • Jay-T написал:

    Попробовал с указанием на R3 eth0/0 delay 3. И может я что-то упускаю, но различий со стороны R1 я не увидел. Да и их не должно быть, насколько мне известно, ведь delay считается с исходящих интерфейсов на пути к сети назначения. Можно подумать, что трафик от R3 до сетей R1-R2 и R1-R4 будет ходить через R1 после уменьшения delay на eth0/0, но оно так и ходило, потому что на shared сегменте соседство у меня не устанавливается. :)

    Понятно, у меня просто на месте свитча - роутер с лупбеком и, конечно, там соседство везде есть.
    Когда R3 ходит к shared сегменту через R1, то из-за split-horizon R3 не отправит апдейт в сторону R1, а значит R1 не установит маршрут через R3 в topology table. Поэтому когда мы отключим линк R1-R2, то R1 будет использовать R4 как Successor в течение небольшого времени, отправит Update к R3, получит новый Update от R3 и маршрут уйдет в Active.
    Когда маршрут через R3 уже в topology table, то R1 сразу поменяет статус маршрута на Active.
  • отредактировано марта 2016
    Тут вот не знаю ошибка или неоднозначность вопроса, или недостаточное понимание:

    Я знаю что у EIGRP ip.proto == 88 , но я также думал, что этот протокол 88 является транспортным и называется Reliable Transport Protocol, нет?
    Я по началу ответил RTP, но у них ответ e в приложении...
  • отредактировано марта 2016
    RTP тут скорее всего, как Real-time transport protocol рассматривается. На самом деле EIGRP, как ты и написал, работает на ip. В книжке тоже пишут не путать real-time transport protocol и reliable transport protocol.
    Легко можно увидеть в том же wireshark, что EIGRP выше, чем в IP заголовки не оборачивается ни во что.
  • отредактировано марта 2016
    Jay-T написал:

    RTP тут скорее всего, как Real-time protocol

    :)) если бы написали полностью то да, а тут в ответе пишут "does not use additional transport protocol" - тогда, что такое "Reliable Transport Protocol"...
Войдите или Зарегистрируйтесь чтобы комментировать.