Да, конечно. 25-го тут, а в ближайшее время на патреоне.
  • avatar qelso
  • 0
Марат, Максим, и вся команда linkmeup, спасибо! Классная статья.

В шаге 6 про OSPF, на мой взгляд, ошибка. После обмена DBD (юникаст) никто не шлет LSAck, продолжается обмен DBD,LSR,LSU (все юникаст), в конце DR шлет LSU на 224.0.0.5, все остальные отвечают LSAck'ами: BDR на 224.0.0.5, DROther на 224.0.0.6 (однако, бывают юникастовые LSAck, что допускает состояние Exchange)

Хотел бы поделиться примерами и особенностями, с которыми столкнулся во время изучения OSPF. Вдруг кому-нибудь пригодится. На истинность не предентую.

1 В случае одновременного получения роутерами мультикастовых Hello (например, если одновременно стартовали ospf процессы на разных роутерах, что бывает редко), каждый роутер выполняет те шаги, которые должен выполнить при получении hello: они отвечают друг другу юникастовым hello (если совпали параметры), устанавливают отношение смежности и т.д. Подробнее в RFC 2328 раздел 10.5

2 Бывают случаи 2-х юникастовых hello: R1 (cisco) шлет hello на 224.0.0.5 (например clear ip ospf process), ему отвечает сосед R2 (cisco) юникастом, на который R1 тоже отвечает юникастом. Получается 2 юникастовых hello. Тут надо гуглить ospf immediate hello

3 Выбор DR происходит в конце 2-Way, после установления двусторонних связей (если двусторонних связей нет, т.е. роутер не получил ни от кого hello и не установил соседство, он решает что он один и объявляет себя DR'ом). Роутеры уже знают о своих соседях достаточно, чтобы начать выборы DR и BDR. Выбор BDR происходит раньше выбора DR (Наряду с другими мерами это предотвращает захват функций DR и BackupDR одним маршрутизатором). Механизм описан в RFC 2328 пункты 9.4, 7.3, 7.4
    3.1 Если расчеты привели к смене DR и BDR, то требуется обновить набор отношений смежности, связанных с данным интерфейсом.
    3.2 Новый маршрутизатор Backup DR не может быть назначен, пока прежний маршрутизатор не примет на себя функции DR (обеспечивается за счет введения гистерезиса (запаздывания)).

4 Если DR и BDR не запланированы (ip ospf network point-to-point), то для общения не будет использоваться 224.0.0.6, а будет 224.0.0.5 (hello, LSU, LSAck). Юникастовые пакеты на определенных стадиях все также будут (hello ответы, DBD, LSR, LSU). В конечном состоянии в таблице соседства у всех будет «FULL/-»
    4.1 Есть нюансы. В сетях point-to-point и виртуальных каналах значение Network Mask принятого пакета Hello игнорируется. Отправитель идентифицируется значением Router ID в заголовке OSPF пакета Hello, а не по IP-адресу отправителя. При получении пакета Hello из сети point-to-point (но не из виртуального канала) значение Neighbor IP устанавливается в соответствии с IP-адресом отправителя. И т.д. см RFC 2328

Broadcast multiaccess:

5 Все DROther между собой имеют статус 2way. FULL только до DR и BDR. Соответственно DR/BDR имеют FULL со всеми.

6 ip ospf priority 0 — запрещает роутеру быть DR или BDR, у такого роутера состояние 2way к другому DROther это нормально. Если в L2 домене нет DR или BDR, то DROther все равно будут в состоянии 2way друг с другом, маршруты пересылаться не будут.
    6.1 В тех случаях, когда роутер является единственным маршрутизатором, способным стать DR, он может назначить себя на роль DR, а BDR просто не будет выбран для сети. В hello пакетах BDR будет 0.0.0.0

7 Когда базы синхронизировались и топология не перестраивается (затишье), то все шлют hello на 224.0.0.5

8 Когда новый участник поднимает ospf и в L2 домене уже есть DR и BDR, то выборы новых DR и BDR не происходят. Даже если у нового участника выше приоритет

9 Если DR не сообщив никому отвалился (BDR в это время не выполняет роль DR), то по истечении dead interval все роутеры начинают слать LSU (кто-то раньше, кто-то позже, в зависимости у кого когда сработал dead interval, причем маршрутизатор, обнаруживший отсутствие DR до того, как это удалось сделать BDR, на некоторое время выберет BDR в качестве DR и BDR одновременно). DROther'ы шлют LSU на 224.0.0.6, BDR шлет LSU на 224.0.0.5 (причем может быть несколько, т.к. прияты LSU от DROther'ов и нужно отправить LSU с новыми данными).DROther'ы шлют LSAck на 224.0.0.6, BDR шлет LSAck на 224.0.0.5 Далее BDR становится DR (на короткий период у DROther'ов в поле DR и BDR может стоять BDR). Далее выбирается BDR среди DROther. (Новые выборы DR не происходять, т.к. он уже есть. Происходят только выборы BDR из DROther)

10 Если у DR (BDR) произошли изменения в LSDB (up/down интерфейса, add network в ospf, reboot роутера, рестарт ospf и т.п.). DR (BDR) отослает LSU на 224.0.0.5 В ответ BDR (DR) шлет LSAck на 224.0.0.5, а DROther шлют LSAck на 224.0.0.6.

11 Если у DROther произошли изменения в LSDB (up/down интерфейса, add network в ospf, reboot роутера, рестарт ospf и т.п.), он шлет LSU на 224.0.0.6
    11.1 Если DR и BDR живы. В ответ DR шлет LSU на 224.0.0.5 На которое отвечают BDR (LSAck на 224.0.0.5) и другие DROther'ы (LSAck на 224.0.0.6), кроме того DROther кто отправил изначальный LSU, т.к. номер LSA не изменился и отправивший проигнорирует LSU (в случае ребута, то он просто не получит LSU от DR).
    11.2 Если BDR в этот момент недоступен, то DR шлет LSU на 224.0.0.5 (как если бы BDR был доступен). На которое отвечают другие DROther (LSAck на 224.0.0.6)
    11.3 Если DR в этот момент недоступен, то через некоторое время (что за таймер выяснить не удалось, возможно, hello interval) BDR (видимо не получив LSU 224.0.0.5 от DR) отправит LSU юникастом на оставшиеся DROther и на DR (хоть он и не доступен). В ответ DROther шлют LSAck на 224.0.0.6

12 Старт DROther.
    12.1 Если DR и BDR живы. DROther шлет Hello на 224.0.0.5 В ответ все роутеры в L2 домене (DR, BDR, DROther) отвечают юникстовым hello стартовавшему DROther'у, в котором уже адреса DR и BDR, а также соседи. Стартовавший роутер видит себя в соседях в полученном hello. Далее стандартно EXSTART, Exchange, LOADING, FULL STATE
    12.2 Если BDR в этот момент недоступен и новый BDR еще не выбран. DROther, стартуя, шлет Hello на 224.0.0.5 В ответ только живые DR, DROther'ы шлют Hello юникстом, в котором адреса DR и BDR (который отвалился), а также адреса соседей. Далее обмен DBD юникастом между живыми роутерами, затем DR шлет LSU 224.0.0.5, а после hello с новым BDR. На LSU отвечают: DROther LSAck 224.0.0.6, BDR LSAck 224.0.0.5. Следом стандартно EXSTART, Exchange юникастом со стартовавшим DROther. А также LOADING: DR шлет LSU на 224.0.0.5, DROther'ы LSU на 224.0.0.6 На что отвечают DROther'ы LSAck'ами 224.0.0.6, BDR LSAck 224.0.0.5. FULL
    12.3 Если DR в этот момент недоступен (и новый DR еще не выбран). DROther стартует, шлет Hello на 224.0.0.5. В ответ только живые BDR, DROther'ы шлют Hello юникстом, в котором адреса DR (который отвалился) и BDR, а также адреса соседей. Далее стандартно EXSTART, Exchange юникастом между живыми роутерами, в том числе и на упавший DR. Далее DROther'ы шлют LSU на 224.0.0.6, BDR шлет LSU на 224.0.0.5 Потом DROther'ы шлют LSAck на 224.0.0.6, BDR шлет LSAck на 224.0.0.5 Далее BDR становится DR (на короткий период у DROther'ов в поле DR и BDR может стоять BDR). Далее выбирается BDR среди DROther. (Новые выборы DR не происходять, т.к. он уже есть. Происходят только выборы BDR из DROther). FULL
Скажите, а файл подкаста будет?
Автоматизируй это. И будет появляться время на развитие.
А ещё послушайте подкаст всё-таки. 25-го :)
  • avatar qelso
  • 0
При моделировании в GNS видно, что мультикастовый Hello был отправлен обоими роутерами без инфы о соседях.
Возможно первый hello не был обработан соседом, т.к. на нем еще не запустился ospf. Например R1 шлет hello на R2, на R2 еще не запущен ospf, соответственно принятый hello не обрабатывается. Далее запускается ospf на R2, R2 шлет hello, на который отвечает R1 юникастовым hello.
Почему только один юникаст? как они выбирают, кто этот юникаст будет посылать, оба ведь получают идентичные мультикасты друг от друга.
Попытался смоделировать такое в UnetLab. В случае одновременного получения роутерами мультикастовых Hello (например, clear ip ospf process одновременно на обоих), каждый роутер выполняет те шаги, которые должен выполнить при получении hello: они отвечают друг другу юникастовым hello (если совпали параметры), устанавливают отношение смежности и т.д. Можно почитать RFC 2328 раздел 10.5
Скажите, пжлст, речь про именно про сетевиков, которые больше ничем не занимаются или больше про инженеров ISP, которые кроме прочего занимаются околосетевыми делами. Вопрос возник потому, что я тут работаю без продыха, голову поднять не успеваю, всем что-то нужно, все платят, все ок, а тут оказывается не нужны инженеры =) По-моему, бред. Кто железо будет настраивать и решать ежедневные вопросы? Каждый день какие-то хитрые кейсы то от абонентов, то от руководства.
Ocen xoroshaya tema. Dovno xotel chto-to slushat ot tex kto uje imel rabotu s etimi WDM.
Naschet protokolov dlya ringa, eto nedavno bil samiy obsujdaemiy tema u nas na rabote. To est, reshili ispolzovat REP u cisco. Kajdom segmente 14-15 hostov i segmenti proxodit cerez ASRs, pricem 5 segment odnovremenno. Do six vso rabotaet ne ploxo.
Eshe let 5 nazad stolknulis s Allied Telesis'koy EPSR. No chisto texniceski i po nadojnosti, po moemu, REP luchshaya.
Дайте ссылку на чатик.
Помогите начинающему. Я только начал читать статью и сразу завис над настройкой роутера 2811. От роутера я вижу все вланы, но при попытке, например, пинговать сеть ФЕО с компьютера из сети ПТО ничего не получается.
!
hostname msk-arbat-gw1
!
!
!
!
!
!
!
!
ip cef
no ipv6 cef
!
!
!
!
!
!
!
!
!
!
!
!
spanning-tree mode pvst
!
!
!
!
!
!
interface FastEthernet0/0
no ip address
duplex auto
speed auto
!
interface FastEthernet0/0.2
description Management
encapsulation dot1Q 2
ip address 172.16.1.1 255.255.255.0
!
interface FastEthernet0/0.3
description Servers
encapsulation dot1Q 3
ip address 172.16.0.1 255.255.255.0
!
interface FastEthernet0/0.101
description PTO
encapsulation dot1Q 101
ip address 172.16.3.1 255.255.255.0
!
interface FastEthernet0/0.102
description FEO
encapsulation dot1Q 102
ip address 172.16.4.1 255.255.255.0
!
interface FastEthernet0/0.103
description Accounting
encapsulation dot1Q 103
ip address 172.16.5.1 255.255.255.0
!
interface FastEthernet0/0.104
description Others
encapsulation dot1Q 104
ip address 172.16.6.1 255.255.255.0
!
interface FastEthernet0/1
no ip address
duplex auto
speed auto
shutdown
!
interface Vlan1
no ip address
shutdown
!
router rip
!
ip classless
!
ip flow-export version 9
!
!
!
!
!
!
!
line con 0
!
line aux 0
!
line vty 0 4
login
!
!
!
end
  • avatar admin
  • 0
Да, жаль, что не правится. Но тут стоит выбор — или новую статью писать или старые доводить до идеала.
Рано или поздно я соберусь и приведу всё в порядок. Поэтому комментарии к статье помогли бы.

Проблем подключиться в гигабитные порты сотками быть не должно — просто согласуются на 100МБ/с. Не вижу противоречия. С точки зрения дизайна сети, да, нелепо, но мы же тут не про дизайн.
Спасибо за быстрый ответ, да вроде проверял, он не пингуется, хотя днс резолвит его… причем с двух провайдеров, все равно большое спасибо за яндекс линк!!! и за ваш труд.
По схеме 2950 предлагается подключать в гигабитные порты? Но там ведь нет гигабитных портов! Или я чего-то не понимаю.
Вообще опечаток хватает, жаль, что ничего не правится.
Рискну предположить, что у вас какие-то сложности именно с archive.org — у меня открывается.
Но вы можете скачать подкаст с яндекс-диска.
Ну ребят это уже не смешно… дайте пожалуйста послушать, а то чет ссылка на archive.org не работает…
Здесь больше имеется ввиду скорее изучение технологий. Но ваш вопрос тоже обсуждался на одной из CCIEлок. Все, кто сдавал лабораторную работу CCIE отмечают, что лучше знать все основные команды наизусть. У вас не хватит времени, если нажимать таб или набирать знак вопроса, ну и все команды лучше набирать в блокноте :)
Благодарю, за ссылку. Эмиль, подскажите, а к «не должны заглядывать в учебники ...» отностится доступ в консоль, или использование "?" и «tab» возможно?
Добрый день:) Расшарить эссе пока проблематично, нужно спрашивать разрешение у участников, согласятся ли они. А вот требования и описание вы можете прочитать по ссылке linkmeup.ru/blog/230.html Пишите, если будут вопросы.
Добрый день и спасибо за статью. Понадобилось почти пол года, много вина и коньяка, чтобы понять распределение меток))
Есть замечание:
Интересна судьба PE10, которая окажет своё влияние на жизни всех других PE.
Дело в том, что он не укладывается в блок 100-109 со своим VE ID 110. Его VBO будет 110=ЦЕЛОЕ(110/10)*10. А в качестве LB он выбрал 10000.
Когда PE10 пришлёт результаты своих калькуляций PE5, неравенство не выполнится: 110 ≤ 105 ≤ 119.
В этом случае запускается процесс выделения нового блока.
1. PE5 выбирает новый LB 5030, VBS уже выбран PE10 — 10.
2. Имея уже данные от PE10,
А. PE5 вычисляет исходящую метку к PE10: (PE10 LB + PE5 VE-ID — PE5 VBO) = (10000 + 105 — 100) = 10005. Обратите внимание, что отнимается локальный VBO.
Б. Вычисляет входящую метку от PE10: (PE5 New LB + PE10 VE-ID — PE10 VBO) = (5030 + 110 — 110) = 5030. Используется новый LB и VBO PE10.

3. PE5 высылает PE10 новый BGP Update, анонсируя уже два префикса: первый — старый, а второй — LB: 5030, VE ID: 105, VBS:10, VBO:110.
4. VE-ID PE10 в этот раз входит в новый диапазон 110-119,
А. поэтому он может вычислить исходящую метку: (PE5 LB + PE10 VE-ID — PE10 VBO) = (5030 + 110 — 110) = 5030. То есть PE10 при отправке кадра этого VSI на PE5 должен вставить VPN-метку 5030.
Б. Может он вычислить и входящую от PE5: (PE10 LB + PE5 VE-ID — PE5 VBO) = (10000 + 105- 100) = 10005. Здесь он использует тот VBO, в который входит PE5, а не PE10.
5. Каждый PE должен будет выделить по второму блоку меток, чтобы общаться с PE10. Вычисления продолжаются.

В пункте 2 PE5 не может взять в качестве исходящей метки к PE10 значение 10005, так как его VE-ID не удовлетворяет офсету 10-го роутера. Вместо этого PE5 будет ждать от PE10 новый блок меток, с офсетом 100, из которого он сможет взять себе метку. Для офсета же 110 подходящие VE-ID лежат в диапазоне 110-119. Таким образом офсет по сути — это первый VE-ID в выделяемом блоке. Теперь представим что у нас появился роутер PE15. Вот он то и возьмет себе метку (PE10 LB + PE15 VE-ID — PE15 VBO) = (10000 + 115 — 110)=10005

Другими словами по дефолту каждый роутер при включении создает блок меток размером VBS для соседей, ID которых находятся в диапазоне от VBO до VBO+VBS-1.
Это значит что в момент включения устройства PE1-PE9 будут готовы обмениваться трафиком с друг с другом а PE10 c PE10-PE19. После того как устройства обменяются NLRI, они обнаружат что есть VE-ID вне выделенных диапазонов и они должны будут выделить по новому, второму блоку: PE1-9 для 10-19 и наоборот.