?

http://eve-ng.net/

а в EVE на образах IOSv (VIRL) порты так же 10 мбит/с ?

eve/virl/gns/unl - nichego s obrazami ne delaet

kak ih predostavlyaut vendors tak i est

kak ih predostavlyaut vendors tak i est

я аросто запустил в GNS, а там порты на гигабите.. удивился, привык, что везде 10 мбит/с для коммутаторов

nu da, vse po raznomu predostavlyaut

nu da, vse po raznomu predostavlyaut

спасибо за ответы =)

ne za chto :)

коммутаторы соединяются через хаб, это half duplex, а в этом режиме RSTP/MST переходят в режим стандартного STP, приходится принудительно на портах выставлять spanning-tree port type point-to-point. Но коммутаторы долго отрабатывают и часто идут потери покетов

код для обработки фулл дуплекса был введен в iol l2 в более поздних версиях, чем можно найти в интернете

код для обработки фулл дуплекса был введен в iol l2 в более поздних версиях, чем можно найти в интернете

понятно, спасибо

код для обработки фулл дуплекса был введен в iol l2 в более поздних версиях, чем можно найти в интернете

а в VIRL есть full duplex?

не в курсе

Нужна помощь, расставить точки над "i" с EIGRP Stub & Query. Перечитал все доступные книжки по EIGRP (CCIE RSv5 OCG, EIGRP Network Design Solutions, EIRGP For IP Basiс Operation and Configuration), презентации с CiscoLive (BRKRST-2336, BRKRST-2444), RFC7868, кучу блогов\whitepaper\technotes, последний Network Collective podcast c Russ White & Nico Russo, где как раз обсуждали EIGRP и только в одном источнике, а именно в OCG v5 от Нарбика акцентируется, что "все неправы, Hub отправляет Query к Stub'у, для полученных от него сетей", в OCG v4 этого не было. Какие только топологии ни собирал, никак не могу добиться что бы Hub отправил Query по маршруту полученного от Stub'а (при любых условиях в отношении Stub-маршрутизатора - ECMP, UCMP, вообще не кандидат). Помнится @dmfigol в своем "вебинаре" тоже сосласлся на OCG v5 и назвал "bullshit" утверждение о том что стабу не отправляются query (правда никак это не подтвердил). Кто-то может подтвердить или опровергнуть (и продемонстрировать) утверждение о том, Hub отправляет Stub-маршрутизаторы Query по маршрутам от него полученным?

Нужна помощь, расставить точки над "i" с EIGRP Stub & Query. Перечитал все доступные книжки по EIGRP (CCIE RSv5 OCG, EIGRP Network Design Solutions, EIRGP For IP Basiс Operation and Configuration), презентации с CiscoLive (BRKRST-2336, BRKRST-2444), RFC7868, кучу блогов\whitepaper\technotes, последний Network Collective podcast c Russ White & Nico Russo, где как раз обсуждали EIGRP и только в одном источнике, а именно в OCG v5 от Нарбика акцентируется, что "все неправы, Hub отправляет Query к Stub'у, для полученных от него сетей", в OCG v4 этого не было. Какие только топологии ни собирал, никак не могу добиться что бы Hub отправил Query по маршруту полученного от Stub'а (при любых условиях в отношении Stub-маршрутизатора - ECMP, UCMP, вообще не кандидат). Помнится @dmfigol в своем "вебинаре" тоже сосласлся на OCG v5 и назвал "bullshit" утверждение о том что стабу не отправляются query (правда никак это не подтвердил). Кто-то может подтвердить или опровергнуть (и продемонстрировать) утверждение о том, Hub отправляет Stub-маршрутизаторы Query по маршрутам от него полученным?

насколько мне известно, HUB не отправляет ничего... это было в курс INE

Нужна помощь, расставить точки над "i" с EIGRP Stub & Query. Перечитал все доступные книжки по EIGRP (CCIE RSv5 OCG, EIGRP Network Design Solutions, EIRGP For IP Basiс Operation and Configuration), презентации с CiscoLive (BRKRST-2336, BRKRST-2444), RFC7868, кучу блогов\whitepaper\technotes, последний Network Collective podcast c Russ White & Nico Russo, где как раз обсуждали EIGRP и только в одном источнике, а именно в OCG v5 от Нарбика акцентируется, что "все неправы, Hub отправляет Query к Stub'у, для полученных от него сетей", в OCG v4 этого не было. Какие только топологии ни собирал, никак не могу добиться что бы Hub отправил Query по маршруту полученного от Stub'а (при любых условиях в отношении Stub-маршрутизатора - ECMP, UCMP, вообще не кандидат). Помнится @dmfigol в своем "вебинаре" тоже сосласлся на OCG v5 и назвал "bullshit" утверждение о том что стабу не отправляются query (правда никак это не подтвердил). Кто-то может подтвердить или опровергнуть (и продемонстрировать) утверждение о том, Hub отправляет Stub-маршрутизаторы Query по маршрутам от него полученным?

я поищу дома, там разбирается этот вопрс

а нет, не у INE... сейчас на ютубе скину лекцию

Нужна помощь, расставить точки над "i" с EIGRP Stub & Query. Перечитал все доступные книжки по EIGRP (CCIE RSv5 OCG, EIGRP Network Design Solutions, EIRGP For IP Basiс Operation and Configuration), презентации с CiscoLive (BRKRST-2336, BRKRST-2444), RFC7868, кучу блогов\whitepaper\technotes, последний Network Collective podcast c Russ White & Nico Russo, где как раз обсуждали EIGRP и только в одном источнике, а именно в OCG v5 от Нарбика акцентируется, что "все неправы, Hub отправляет Query к Stub'у, для полученных от него сетей", в OCG v4 этого не было. Какие только топологии ни собирал, никак не могу добиться что бы Hub отправил Query по маршруту полученного от Stub'а (при любых условиях в отношении Stub-маршрутизатора - ECMP, UCMP, вообще не кандидат). Помнится @dmfigol в своем "вебинаре" тоже сосласлся на OCG v5 и назвал "bullshit" утверждение о том что стабу не отправляются query (правда никак это не подтвердил). Кто-то может подтвердить или опровергнуть (и продемонстрировать) утверждение о том, Hub отправляет Stub-маршрутизаторы Query по маршрутам от него полученным?

https://www.youtube.com/watch?v=WiQgfwAw8Ns&index=7&list=PL6Tc4k6dl9kL9SoDOXW7wQfkWGHzwp8OI

кажется сдесь.... сейчас без наушником, не могу утверждать наверняка. Но вроде в этой леции показывается debug для stab

Кто не смотрел лекции Travis Bonfigli, советую инструктора, особенно у кого Английский не особо... отличное произноешение и рассказывает подробно. Сейчас он препадаёт в INE, но у него хорошие курсы выложены на ютубе.

HUB не отправляет query в сторону stub, но вот в обратную сторону stub отправит query.

HUB не отправляет query в сторону stub, но вот в обратную сторону stub отправит query.

это логично

Алексей ) спасибо, не умоляя вашего авторитета, материал от Браена я тоже смотрел. Я согласен с тем, что к Stub не отрпавляются Query ни в каких случаях (по крайней мере я лично как не путался, не смог заставить отправлять). Но в качестве финальной точки, я хотел бы увидеть подтверждение (топология, условия, может быть даже дамп), где Hub отправляет Query к Stub'у. Был бы ооочень признателен если бы @dmfigol, который использовал красочное описание, bullshit, как-то прокомментировал. ЗЫ: Я знаю только два варианта, когда (и те притянутые за уши) когда можно сказать, что Hub отправляет Query Stub'у, 1)это если в одном broadcast-сегменте с Stub'ом находится еще один сосед, тогда Query будет отправлен мультикастом и можно сказать, что "да, смотрите, он отправил!" 2)когда Query носит характер "Update", т.е Hubне спрашивает а информирует

во всех остальных случаях, я не могу себе представить (и залаббить) ситуацию, когда Hub отправит Query к Stub, именно как запрос, а не как информирвоание о факте

/* за линк спасибо, я посмотрю, чуть позже */

@man1tou в вебинаре я был не прав. не отправляется :)

даже при лик меп

@dmfigol thanks, you saved my day

я думал, что читаю Нарбика и открываю для себя неизведанное

эх... никому доверия нет, даже учебникам =(

вот именно, особенно на уровне CCIE, все материалы нужно проверять по 7 раз

ни одному слову нельзя верить

я думал, что читаю Нарбика и открываю для себя неизведанное

я не уверен, почему я был уверен что могут отправляться

мы с ТАС ребятами при подготовке спорили на этот счет

что меня интересует, если не отправляются, то что тогда будет, если на всех роутерах в топологии мы сделаем "eigrp stub leak-map LEAK-MAP" в котором разрешены все префиксы

Спасибо, всем. Итого, Hub не отправляет Query к Stub, никогда, кроме двух случаев: 1/ если в одном broadcast-сегменте с Stub'ом находится еще один сосед, тогда Query будет отправлен мультикастом и можно сказать, что "да, смотрите, он отправил!" 2/ когда Query носит характер "Update", т.е Hub не спрашивает, а информирует В OCG v5 на эту тему написана ерунда.

что такое query носит характер апдейт?

когда hub отправляет query по какому-то ранее ему известному префиксу с метрикой infinity, что бы указать, что он потерял маршрут, такой query к stub'e прилетает (проверено лично с wireshark'ом в зубах)

я тоже где-то слышал, про "есть query к stub", например если у нас сеть в Passive, есть successor напрямую и есть бекапный маршрут не Successor, при изменении метрики для бекапного маршрута(чтобы он стал приоритетнее действующего successor) по идее запустится active + diff comp , query к stub не пойдет?

когда hub отправляет query по какому-то ранее ему известному префиксу с метрикой infinity, что бы указать, что он потерял маршрут, такой query к stub'e прилетает (проверено лично с wireshark'ом в зубах)

смысл любой query это делать

логично в таком сценарии же проверить, но если подумать то суть такого query лишь в сообщении о собственном изменении топологии, а stub любом случае её не изменит потому что сам подключен к этой сети и имеет CD =0 же, мне кажется все таки не будет там query, но проверять я конечно же не буду)

@dmfigol расслабься, это не наезд, я просто сам уже который день "ищу истину", вот решил у вас в чатике спросить

@man1tou не воспринимаю как наезд

наоборот, рад что кто-то в лабу пошел

пока тут играюсь получил: %DUAL-3-SIA: Route 150.1.5.5/32 stuck-in-active state in base 100. Cleaning up

:D

это само или зафильтровали ответ?

ну можно сказать само :)

клёва...

@man1tou у меня для тебя плохие новости, не спать тебе сегодня :)

сеть - ине. на R10 и на R9 лупбек 150.1.10.10/32

на R10, shut down lo0

конфиг на всех роутерах: eigrp stub leak-map LEAK

к стати, может кому интересно. У меня был на тесте маршрутизатор 881 с "демо" лицензией, которую оставил тикать и вот, прошло 2 месяца и она стала Life time, после ребута тоже всё ок... т.е. в каком-нибудь ацтойном случае можно обойтись без покупки лицензии advipservices

а там точно другого соседа нет в этом броадкаст сегменте помимо R9 ?)

Если взять топологию: 192.168.0.0/24 (lo0) ---(r1)----(r2-stub, connected) и сделать два теста: 1) положить lo0 - r1 отправляет Update, query нет; 2) увеличить delay на lo0 - r1 отправляет Update к r2-stub, а r2-stub отправляет обратно Query!

@dmfigol это какая-то фантастика, там явно какой-то косяк

а там точно другого соседа нет в этом броадкаст сегменте помимо R9 ?)

nope

@dmfigol это какая-то фантастика, там явно какой-то косяк

если бы :)

R9 и R10?

между ними же вся топология, они самые дальние друг от друга

да

но все роутеры стаб

ну так верно всё, просто выше там должен был быть Update от R10, о том что lo0 в даун ушел, дальше Stub`ы начинают query'ть, вот моем примере выше именно это и происходит

именно update от R10 был триггером

что именно верно?

что ты видишь в даме кучу query, которые нагенерили stub`ы

ERROR: S client not available

*дампе

так почему верно если у меня везде стабы и по идее никаких квери они видеть не должны?

а на R1 префикс от r2 точно не feasible?

Если взять топологию: 192.168.0.0/24 (lo0) ---(r1)----(r2-stub, connected) и сделать два теста: 1) положить lo0 - r1 отправляет Update, query нет; 2) увеличить delay на lo0 - r1 отправляет Update к r2-stub, а r2-stub отправляет обратно Query!

Если взять топологию: 192.168.0.0/24 (lo0) ---(r1)----(r2-stub, connected) и сделать два теста: 1) положить lo0 - r1 отправляет Update, query нет; 2) увеличить delay на lo0 - r1 отправляет Update к r2-stub, а r2-stub отправляет обратно Query!

вот пункт 2 смотри, пожалуйста

Ivan причему тут r2 если lo0 отправлялся в down на r1?

условия для diffusal computation

CD для Lo0 на r1 сколько было? 0 так?

до изменений

да, продолжай

не могу понять причем тут "префикс от r2 точно не feasible?"

какой перфикс от r2? он ничего не анонсировал

эм

это забавно :)

то есть там нет connected 192.168.0.0/24? а что проверяем то тогда?

ладно, пойду делом заниматься

смысл общий чтобы проверить есть ли query сперва условия создать, должен быть один и тот же префикс - от stub и другого соседа

причем от соседа он не должен быть feasible successor

Тогда при изменении delay запуститься diffusing computation

и можно будет посмотреть и сказать есть ли query в сторону stub для префикса, который этот же stub И анонсирует

если будет время соберу лабу все таки)

R1: interface Ethernet0/0 ip address 192.168.12.1 255.255.255.0 ! interface Ethernet0/1 ip address 192.168.13.1 255.255.255.0 ! router eigrp 1 network 192.168.0.0 0.0.255.255 R2: interface Ethernet0/0 ip address 192.168.12.2 255.255.255.0 ! interface Ethernet0/1 ip address 192.168.23.2 255.255.255.0 delay 2000 ! router eigrp 1 network 192.168.0.0 0.0.255.255 eigrp stub connected summary R3: interface Ethernet0/0 ip address 192.168.13.3 255.255.255.0 ! interface Ethernet0/1 ip address 192.168.23.3 255.255.255.0 ! router eigrp 1 network 192.168.0.0 0.0.255.255

Смотрим: R1#show ip eigrp topology all-links P 192.168.23.0/24, 1 successors, FD is 307200, serno 5 via 192.168.13.3 (307200/281600), Ethernet0/1 via 192.168.12.2 (793600/768000), Ethernet0/0 P 192.168.12.0/24, 1 successors, FD is 281600, serno 1 via Connected, Ethernet0/0 P 192.168.13.0/24, 1 successors, FD is 281600, serno 2 via Connected, Ethernet0/1

R2#debug eigrp packets query update (UPDATE, QUERY) EIGRP Packet debugging is on

для какого префикса вы планируете чтобы query отправилось?

попробуем 192.168.23.0/24 ?

минуту

ну тут R2 для него feasible successor же так?

нет, почему? FD is 307200, а RD от R2 768000

а да, ок