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

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

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

2»

Комментарии

  • Это что-то типа внутреннего функционала для надёжной доставки eigrp-пакетов внутри eigrp-домена (за счёт HelloAck). :) Это не отдельный протокол, насколько я понимаю.
  • Вопрос действительно стоит как Transport Layer то есть, 4-й уровень, где работает TCP/UDP
    Протокол RTP (real-time-protocol) (что указан в вопросе наравне с другими протоколами транспортного уровня TCP/UDP), как и RSVP работает поверх UDP и используется в связке с RTCP (real-time-control-protcol) для доставки голосового/видео трафика поверх IP сетей.

    Для EIGRP используется же протокол RTP 3-го уровня, в WireShark это видно, как написал Jay-T в заголовке IP-пакета идет protocol 88.
    И он, не работает на транспортном уровне (поверх UDP) а именно на сетевом.
    То есть, когда речь идет об rtp/rtcp и передачи Voice трафика, то в заголовках пакетов значение protocol стоит 17 (UDP) и уже в него инкаспулируется RTP/RTCP (работают в связки, один по четным портам, другой по нечетным).

    Ну а так, на скорую руку можно и ошибиться.
  • Packo написал:

    Тут вот не знаю ошибка или неоднозначность вопроса, или недостаточное понимание:
    Я знаю что у EIGRP ip.proto == 88 , но я также думал, что этот протокол 88 является транспортным и называется Reliable Transport Protocol, нет?
    Я по началу ответил RTP, но у них ответ e в приложении...

    Ошибка, правильный ответ RTP.
    Да, RTP (Reliable Transport Protocol) - часть EIGRP, но он всё же выделяется отдельно. Это такой себе упрощенный TCP со своими Sequence numbers.
  • отредактировано марта 2016
    dmfigol написал:

    Packo написал:

    Тут вот не знаю ошибка или неоднозначность вопроса, или недостаточное понимание:
    Я знаю что у EIGRP ip.proto == 88 , но я также думал, что этот протокол 88 является транспортным и называется Reliable Transport Protocol, нет?
    Я по началу ответил RTP, но у них ответ e в приложении...

    Ошибка, правильный ответ RTP.
    Да, RTP (Reliable Transport Protocol) - часть EIGRP, но он всё же выделяется отдельно. Это такой себе упрощенный TCP со своими Sequence numbers.
    Да, и при этом он работает отдельно от протоколов транспортного уровня и не инкаспулируется в tcp/udp протоколы. О чем, говорит в варианте E.
    А вот RTP (Real-time transport protocol) как раз таки инкапсулируется.
  • feo_sobolev написал:

    dmfigol написал:

    Packo написал:

    Тут вот не знаю ошибка или неоднозначность вопроса, или недостаточное понимание:
    Я знаю что у EIGRP ip.proto == 88 , но я также думал, что этот протокол 88 является транспортным и называется Reliable Transport Protocol, нет?
    Я по началу ответил RTP, но у них ответ e в приложении...

    Ошибка, правильный ответ RTP.
    Да, RTP (Reliable Transport Protocol) - часть EIGRP, но он всё же выделяется отдельно. Это такой себе упрощенный TCP со своими Sequence numbers.
    Да, и при этом он работает отдельно от протоколов транспортного уровня и не инкаспулируется в tcp/udp протоколы. О чем, говорит в варианте E.
    А вот RTP (Real-time transport protocol) как раз таки инкапсулируется.
    Ну не сказано там, что имеется в виду Real time Transfer Protocol, поэтому я бы выбрал RTP.
  • отредактировано марта 2016
    feo_sobolev написал:

    протокол RTP 3-го уровня

    а почему тогда он называется reliable Transport protocol :) Да я думаю это очередной косяк автора, а вообще не так уже и важно.

  • Packo написал:

    feo_sobolev написал:

    протокол RTP 3-го уровня

    а почему тогда он называется riliable Transport protocol :) Да я думаю это очередной косяк автора, а вообще не так уже и важно.
    Наверное потому, что это их реализация tcp протокола, и он действительно занимается транспортом.
    Но, при этом он не икапсулирует данные в хорошо знакомые и привычные нам протоколы транспортного уровня tcp/udp.
  • Рис. 1 - Заголовок EIGRP пакета.
    Рис. 2 - Вырезка из eigrp draft.
    Дак вот RTP как Reliable transport protocol - это набор правил позволяющих взаимодействовать с полями ACK и SEQ для надёжной доставки юникаст и мультикаст EIGRP-пакетов. Этот RTP нельзя применить ни к какому другому протоколу, т.к. он является частью EIGRP (ровно как и Finite State Machine). Заголовков дополнительных на пакет не вешается и EIGRP-пакеты не передаются на transport layer.
    В следствие этого и исходя из вопроса "Какой протокол транспортного уровня используется для обмена EIGRP пакетами." я отвечу "никакой". :) И ещё в добиваение, даже если я неправ (а я прав), Reliable Transport Protocol не является протоколом транспортного уровня, что уже исключает его из ответов. :)
  • Да он просто так называется, и, как точно сказано выше, является частью самого EIGRP. А так можно сказать что EIGRP работает поверх IP=88

  • Jay-T написал:

    Рис. 1 - Заголовок EIGRP пакета.
    Рис. 2 - Вырезка из eigrp draft.
    Дак вот RTP как Reliable transport protocol - это набор правил позволяющих взаимодействовать с полями ACK и SEQ для надёжной доставки юникаст и мультикаст EIGRP-пакетов. Этот RTP нельзя применить ни к какому другому протоколу, т.к. он является частью EIGRP (ровно как и Finite State Machine). Заголовков дополнительных на пакет не вешается и EIGRP-пакеты не передаются на transport layer.
    В следствие этого и исходя из вопроса "Какой протокол транспортного уровня используется для обмена EIGRP пакетами." я отвечу "никакой". :) И ещё в добиваение, даже если я неправ (а я прав), Reliable Transport Protocol не является протоколом транспортного уровня, что уже исключает его из ответов. :)

    У вас все верные аргументы, но я бы всё равно ответил RTP :)
  • отредактировано марта 2016
    Jay-T написал:

    Reliable Transport Protocol не является протоколом транспортного уровня

    Вот это самый спорный вопрос по моему :)
    Jay-T написал:

    для обмена EIGRP пакетами.

    там написано EIGRP messages, было бы слово про пакеты... :)
    Jay-T написал:

    Этот RTP нельзя применить ни к какому другому протоколу

    EIGRP for IPv6 и EIGRP for IPv4 используют RTP, и вроде как EIGRP и под другие протоколы сетевого уровня есть, еще круче того, вот такая схема есть в Cisco Exploration v5.0.2:

    или кто Вам мешает завтра разработать свой протокол на основе RTP из EIGRP's RFC...

    и кстати там сказано обратите внимание, что именно RTP позволяет протоколу EIGRP не использовать TCP/UDP
    Jay-T написал:

    Заголовков дополнительных на пакет не вешается и EIGRP-пакеты не передаются на transport layer.

    А наличие собственных заголовков это обязательный атрибут протокола? например NDP(Neighbor Discovery Protocol) пользуется заголовками ICMPv6

    П.С. Но это бессмысленный спор, OSI и TCP -всего лишь модели, просто автор книги задал неоднозначный вопрос.
    to forum.png 203.9K
  • Слово про пакеты в вашей картинке есть в первом предложении. :)
    По поводу NDP правильно сказали, что он работает в ICMPv6 (вы же не относите NDP к уровню приложения, например?). С RTP и EIGRP такая же схема - RTP работает в заголовках EIGRP, поэтому выше уровня работы EIGRP, а именно сетевого, я считаю, его нельзя ставить, т.к. отдельно он не работает больше ни с чем, кроме EIGRP (для IPv6 используется тот же EIGRP заголовок, что и для IPv4, только в таком случае в TLV передаются IPv6 префиксы).
    Ну вот против того, что изображено на картинке я бессилен - фигня какая-то. :) Судя по ней, я могу любые пакеты с заголовком IP передавать с использованием Reliable transport protocol, включая OSPF. :)
  • отредактировано марта 2016
    Jay-T написал:

    Слово про пакеты в вашей картинке есть в первом предложении. :)

    Где?
    Jay-T написал:


    С RTP и EIGRP такая же схема - RTP работает в заголовках EIGRP, поэтому выше уровня работы EIGRP, а именно сетевого, я считаю, его нельзя ставить, т.к. отдельно он не работает больше ни с чем, кроме EIGRP.

    Я не видел чтобы кто-то запрещал такое делать, OSI и TCP/IP это всего лишь референтная модель.
    И почему Вы решили что RTP поверх EIGRP работает? Это RTP обеспечивает работу EIGRP, а не наоборот, то что поля используемые им никто не выделяет в отдельный заголовок, не говорит, о том что это не транспортный протокол. Это необязательный атрибут для протокола - иметь свой собственный отдельный заголовок.
    Jay-T написал:


    Судя по ней, я могу любые пакеты с заголовком IP передавать с использованием
    Reliable transport protocol, включая OSPF.

    Можете, но это будет новая не стандратная реализация протокола OSPF, дальше можете стандартизировать её через IETF :) Я бы назвал это link-state EIGRP :))
    А с другой стороны, кто Вам разрешит DHCP через TCP передавать?:)) Модель TCP/IP хоть и вносит модульность, но не изменяет код реализации и текст стандартов.


  • Jay-T написал:

    поэтому выше уровня работы EIGRP, а именно сетевого,

    Эм?
  • Сетевой относительно модели OSI (межсетевой относительно TCP/IP, как вам удобнее).
    Я веду к тому, что RTP - это использование полей EIGRP заголовка Sequence и ACK. Вы не можете в нынешней реализации использовать RTP в OSPF, потому что там этих полей нет (RTP не работает отдельно от EIGRP по крайней мере пока). Почему TCP или UDP относят к транспортному уровню (а RTP я туда не отношу), потому что данные от приложения инкапсулируются в заголовки TCP или UDP, и им абсолютно неважно, что находится на сетевом (межсетевом) и ниже абстракционном уровне - эти сегменты могут передаваться как в IPv4, так и в IPv6 - всё равно, и они будут доставлены получателю в точно таком же виде, в котором отправлялись. RTP же работает только с EIGRP, может обрабатывать только поля в EIGRP заголовке, потому что там есть, что обрабатывать для надёжной доставки пакетов. Я не знаю, как вам ещё это донести. :)
    А про пакеты смотрите не эту картинку с вопросом, а скрин из Cisco Networking Academy, там первое предложение "EIGRP uses RTP for the delivery and reception of EIGRP packets".
  • Jay-T написал:

    Сетевой относительно модели OSI

    Я бы подискутировал на этот счёт, но это будет неинтересно :(
  • отредактировано марта 2016
    Jay-T написал:

    EIGRP uses RTP for the delivery and reception of

    Тамже написано EIGRP заменяет TCP на RTP...
    Jay-T написал:

    Я не знаю, как вам ещё это донести. :)

    Да я Вас понял отлично, я просто говорю, что все эти уровни сетевой модели и пр, это все - просто способ взглянуть на более сложную систему. Вопрос спорный и если такое попадется на экзамене, шанс ответить 50/50 т.к. ты не знаешь заранее с какой точки зрения подходил к вопросу автор.


  • Здесь же есть на форуме сертифицированный Cisco инструктор. Что он скажет по этому поводу? :)
  • отредактировано марта 2016
    Кстати, а никто не обращал внимания на то, что OSPF используя номер протокола 89, так-же при передачи данных шлет что-то вроде ACK пакетов?
    Можно, тогда назвать и OSPF транспортным протоколом.
    Я больше склонен к Jay-T и автору книги F.L.G., т.к. речь идет именно о передачи пакетов протокола, от роутера, к роутере, без дополнительной инкапсуляции, прямо на "сетевом" уровне.
    Ведь, как раз RIP, OSPF работают на сетевом уровне, как и ARP и не инкаспулируется в протоколы транспортного уровня tcp/udp, аналогично с ICMP.
    Вот и EIGRP используя свой RTP (ну, назвали так, свою реализацию, чтобы отказаться от "традиционных, хорошо известных" протоколов транспортного уровня и сделали реализацию ACK.
    Но, по факту, протокол же не инкапсулируется на уровни выше. О чем сказано, в варианте E:
    Что EIGRP работает прямо на сетевом уровне и не используется дополнительных транспортных протоколов.
    Под ними, как раз имеют ввиду TCP/UDP.
    Плюс там-же RSVP (протокол используемый для QoS) и RTP (вероятно, протокол используемый для VoIP, наравне с другими приведенными протоколами)
    Признаюсь что сам я, когда прочел главу, выбрал Е, позже, когда перечитывал вопросы, более быстро и менее вдумчиво выбрал D. :)
  • feo_sobolev написал:

    как и ARP

    Прошу прощения, ARP работает на канальном уровне :)
  • dmfigol написал:

    feo_sobolev написал:

    dmfigol написал:


    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.
    Ну вот, только что, снова наткнулся на данную ситуацию.
    Когда прилетает UPDATE от текущего Successor, метрика становится хуже, в итоге, получается что FD!=Calculated Distance of Successor.
    Однако, правило FC напрямую относится и к этому случаю, а именно почему не запускается или запуская алгоритм DUAL и маршрут уходит либо не уходит в Active.
    Выходит, если прилетает update от текущего Successor где он рапартует о том, что его метрика уменьшается, и его RD (с новой метрикой) при удовлетворении условия FC ( new_RD_from_current-Succsessor < FD) тогда получаем, что FD остается прежним, а Calculated Distance of Successor. становится больше. Получаем FD!=CDofS.
    Но, если новая метрика текущего Succsesor не удовлетворяет условия FC, тогда запускается алгоритм DUAL и FD меняется и становится равна FD=CDofS.
    Ниже 2 скрина, где путем добавления offest на роутере orginate ухудшаем метрику, чтобы она попадала под условие FC, а на втором скрине не попадала под условие FC.
    EIGRP-1.png 64.5K
    EIGRP-2.png 100.7K
  • feo_sobolev написал:


    dmfigol написал:

    feo_sobolev написал:

    dmfigol написал:


    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.
    Однако, правило FC напрямую относится и к этому случаю, а именно почему не запускается или запуская алгоритм DUAL и маршрут уходит либо не уходит в Active.
    Всё так, да :smile:
Войдите или Зарегистрируйтесь чтобы комментировать.