Вот конфигурация роутеров.

>>213062
Разбираться надо не в пакет трейсере, а в том, как маршрутзиация работает. После прочтения конфига ролтона2 подумал что просто очепятку допустил в адресе шлюза. А вот при настройке роутера 3 кое-кто, похоже, знатно запутался.
Что будет если следующим заданием окажется настройка какого-нибудь там OSPF?

>>213064
Да это тестовая работа, просто лабораторку писал сегодня, и там это задание было.
Просто хочу понять в чем ошибка и как исправить.

Я настраивал в своё время соединение компьютеров разными способами. И со всей ответственностью заявляю, что до сих пор не понимаю как это работает. Когда читаю - понимаю. На практике же впадаю в ступор. Опыт как и любой другой вид знаний забывается. Поэтому нужно понимание. И это не то понимание, которое приходит при прочтении википедии или любого другого руководства для чайников, а подсознательная чуйка на уровне рефлексов. Вот ты знаешь как завязывать шнурки или чистить зубы без объяснений? А у некоторых людей до самой старости с этим проблемы, даже с объяснениями. Иногда правда бывает, что нисходит озарение и человек сразу начинает всё понимать. К сожалению поговорка "нет глупых учеников, есть глупые преподаватели" у нас не популярна. Так что подобные перерождения сознания большая редкость и почти всегда случайны.
В общем я к тому, что часто люди делают дело без понимания. И вроде делают неплохо. Но покуда для них не будет ясно и очевидно как день, никудышные они специалисты. Пусть делают что очевидно. Или ищут способ осознать. Как его найти? Не знаю. Всё индивидуально. Еслиб знал, давно нашёл того кто бы собрал мои знания в картину мира.

>>213065
В качестве адреса шлюза должен быть указан IP, прописанный на интерфейсе соседней железки. То есть на ПеКа1 шлюзом должен быть IP болтающийся на G0/0 R2, На R2 шлюзом должен быть IP, прописанный на G0/1 R3. И наоборот.
А если ты ещё и интерфейсы перепутал, то совсем бака.

Есть кто живой?
Я хочу объяснить ОПу про маршруты.

>>214778
Зачем тебе живые, так объясняй

И то правда.
Я немного переделал схему, чтобы она была нагляднее и подсети были видны сразу.

Чтобы пакеты долетали от PC1 до PC2, между ними должен быть проложен маршрут в обе стороны. Это проверяется по таблицам маршрутизации на всех узлах.
1) У PC1 маршрут всего один - по умолчанию. Он шлет все свои пакеты, не предназначающиеся подсети 1.0/24, на 192.168.1.1 (Router1), чтобы тот разобрался, как эти пакеты дальше передавать.

2) Router1 у нас пока почти не настроен. У него нет маршрута по умолчанию, но есть маршрут для пакетов, предназначающихся подсети 3.0/24. Обрабатывает их его сосед по подсети - 192.168.2.2 (Router2). Это строка, которая начинается с S - static. Статический маршрут, прописанный руками.

2) Router2 почти как Router1 - у него тоже только один статический маршрут, на этот раз для пакетов, которые надо передать в 1.0/24 подсеть.

4) PC2 - у него маршрут по умолчанию лежит через Router2.

Итого:
PC1 хочет отправить эхо-запрос на PC2 и получить эхо-ответ.
PC1 смотрит на введенный адрес и видит, что он не из его подсети (192.168.3.2 - не входит в подсеть 192.168.1.0/24), поэтому передает его по маршруту по умолчанию - на Router1.
Router1 смотрит в адрес получателя эхо-запроса и видит, что он входит в подсеть, до которой у него прописан маршрут (192.168.3.2 - входит в 192.168.3.0/24), и передает пакет по этому маршруту - на Router2.
Router2 видит, что получатель эхо-запроса находится в одной из его напрямую подключенных подсетей и передает полученный эхо-запрос клиенту PC2.
PC2 получает эхо-запрос и отвечает на него, инициируя отправку в обратную сторону. Получателем эхо-ответа будет PC1 (192.168.1.2), и так как он не входит в подсеть 192.168.3.0/24, пакет передается по маршруту по умолчанию для PC2 - на Router2. В общем, то же самое, но наоборот.

>>214779
Мне тяжко без аудитории. Надо понимать, где я слушателя потерял и что надо объяснить иначе.

>>214788
Какую аудиторию ты рассчитываешь тут получить?

Чайникам надо как минимум объяснять, что 255.255.255.0 и /24 - это одно и то же, и неплохо было бы в принципе рассказать что такое маска и как её используют.
А если объяснять глубже, то надо сразу убирать неточности вида

>PC1 (192.168.1.2), и так как он не входит в подсеть 192.168.3.0/24, пакет передается по маршруту по умолчанию

>>214789
Отлично, спасибо.
Я так и думал, что надо будет про маски получше рассказать.

>>214789
Забавно, что за четверть века и несмотря на весь пиар, IPv6 так и не стал чем-то, стоящим ознакомления чайнику.

>>214791
Ну, цены на IPv4 на вторичном рынке продолжают расти и довольно заметно, а первичный рынок уже пару лет как высох полностью.
Рано или поздно, но экономика заставит переходить на IPv6. Количество подключенных устройств-то не уменьшается, если конечно не произойдет какого-нибудь глобального катаклизма.

>>214792
Не заставит. Слишком неудобно для большинства применений.

Смерть ip4 можно сравнить с многочисленными "концами света", дату которых постоянно переносят и переносят.

Проблему количества устройств успешно решают старым добрым NAT. Большинству таких устройств реальный адрес абсолютно не нужен.

>>214792
Я далеко не сетевик, так, самому настроить домашнюю сетку или поднять впн на впс, но мне проще будет просто больше платить, потому что:
1) подавляющее большинство домашних провайдеров и большая часть хостеров выдают по-умолчанию IPv4
2) те кто все-таки выдаёт, делают это странно.
Открываешь статьи о работе с IPv6, читаешь красивые и правильные вещи про выделение /56-/64 каждому пользователю, удобства статический адресации и необходимость править только верхнюю часть адреса при смене аплинка, пот это все...
Один хостер впс мне выдал 16 (прописью: шестнадцать) адресов IPv6. Не от нуля /64 блока. То есть, если с таким строить большую локалку, это будет опять NAT, опять возня с пробросом портов, без какого-либо положительного выхлопа, за что боролись-то. Да, для хостинга впн или мелкого сайта этого хватит, но это расхождение с документацией и потенциально лишние усилия на непрофильную работу, раз обжегся - начнёшь избегать.
3) крупнейший производитель сетевого оборудования использует корпоративный впн, и раздаёт десятку тысяч сотрудников удалённые машины со статическими глобальными ipv4, не ipv6, и не адреса из локальной сети, хотя ресурсы на последних тоже используются и доступны из того же впн. Правильно это, не правильно, осмысленно, просто легаси и использование миллионов хапнутых в 80е адресов - судить не берусь, опять же, не мой профиль, но очень не располагает воспринимать дефицит ipv4 всерьёз.

>>214794
Да понятно, что IPv4 не умрет за день, год, или даже десятилетие. Тем не менее кажется как-то невероятным, что человечество продолжит использовать IPv4 с ценами за адрес, уходящими далеко за 1000 долларов за штуку, и с таблицей маршрутизации в 10 миллионов записей, когда через пару десятилетий при индустриализации Африки и Индии будут соответствующие потребности в адресах, продолжится рост облачных провайдеров и всякой контейнеризации да виртуализации, будут новые технологии с всякими автономными системами, требующими обмена пакетами без задержки и проблем NAT-а, и так далее,

>>214795
Если хочешь поэкспериментировать с глобальным IPv6 таким каким он должен быть, то есть https://tunnelbroker.net/. Можешь даже /48 получить там.
Кривые реализации у провайдеров и хостеров же отомрут, когда спрос и конкуренция за лучшие условия будет больше.
Да и даже сейчас, если требуется можно найти хостеров, которые дадут /56-/48 по запросу.

>>214792
IPv6 толком не решает существующих проблем и привносит множество новых, именно поэтому с массовым переходом тянут и будут тянуть до последнего.

И не факт, что кто-нибудь не придумает что-нибудь более удобоваримое.

>>214797
IPv6 решает главную проблему количества адресов и делает чуть лучше ситуацию с размером таблицы маршрутизации.
Придумывание более удобоваримого не поможет. Текущее сетевое железо хотя бы обычно поддерживает IPv6, а принятие нового стандарта — это полтора десятилетия на обновление железа сразу же нужно прибавлять.

>>214798
Проблеме количества ipv4 лет немногим меньше, чем интернету. Тем не менее, я до сих пор могу купить у кучи хостеров за пару баксов целую впску с выделенным ipv4. Мой личный рекорд - один евро в месяц за полноценную vps с ipv4, хоть и с крайне ограниченным количеством ресурсов.
То есть проблема в целом решаемая, а те, у кого вместо белого адреса - NAT, в большинстве случаев и не знают что это такое и не ощущают никаких неудобств.

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

>>214796
>>214798
А с чего ты взял, что цена будет пробивать небеса? Это wild guess.

Рынок активно перераспределяется внутри, "не очень нужные адреса" становится иметь невыгодно (домашная статика, которую массово забирают, например). У крупных потребителей-контейнеровозов пулы давно закуплены впрок. Миллионам потенциальных негров и индусов, как уже говорил выше, реальные адреса вообще не сдались. То есть проблема дефицита острой проблемой в ближне-средней перспективе не выглядит. Что-то в духе глобального потепления на полградуса, обожемывсеумрем. Стоить будет дороже, конечно - но не на порядки. Просто кому не надо - тот не купит.

>новые технологии с всякими автономными системами, требующими обмена пакетами без задержки и проблем NAT-а, и так далее,

У всего этого есть свои протоколы и сети. Так что вдогонку к "кому не надо".

Да и слабо представляю реализацию стека v6 на дохлом контроллере без ОС. К вопросу "слишком неудобно". А всякие решения на пердуинах идут нафиг со своей энергонеэффективностью.

Проблемы NAT вообще больше городская легенда сисадминов и сочувствующих, чем проблема. Рядовой пользователь с айфоном в руке давно живет за NAT без каких-либо проблем и смотрит свои тиктоки в fullhd.

>>214797
Как и большинство "окончательных решений вопроса" в IT за всю его историю. Существующее простое решение будет расширяться до тех пор, пока им совсем невозможно будет пользоваться. Пока диапазон v4 успешно "расширяется" за счет NAT и приватных сетей, переходить на глобальный v6 на всех устройствах нафиг не сдалось никому, кроме кучки энтузиастов.

Вот достаточно интересная статья на тему, попавшаяся на днях

https://www.ixbt.com/editorial/spiral.shtml

>>214796

>Да и даже сейчас, если требуется можно найти хостеров, которые дадут /56-/48 по запросу.

Так в том и суть, что для неискушенного в сетях, вот что важно при выборе провайдера или хостинга?
1) цена
2) скорость/трафик
В случае провайдера далее идёт вопрос физики подключения и нужное оборудование, и только в конце для ну может единиц процентов вопрос, что там за протокол и есть ли статический адрес.
В случае хостера тоже куда приоритетнее будет вопрос количества ядер/памяти/хранилища/способа оплаты.
При этом в обоих случаях практически гарантированно будет ipv4, и он будет просто работать. Выбирать хостера по наличию ipv6 мне кажется странно.
Ну то есть, сложностей добавляется, а именно выгоды от смены как просто пользователю не видно, это же, например, не ускорение трафика на десятки процентов снижением оверхеда в пакетах, или какой-нибудь принципиально новый функционал, не знаю, встроенного хранения пакета до востребования, или встроенной способности авторазбивать трафик через десятки медленных нестабильных каналов.

>>214799

>Проблеме количества ipv4 лет немногим меньше, чем интернету.

Нет. Первичные адреса закончились не так давно у RIRов и вторичный рынок пока достаточно насыщенный, но так будет не всегда при конечности ресурса, но продолжающемся росте базы пользователей и парка серверов.

И что все-таки проще: заставить все же ленивых админов настроить IPv6 или принять какой-то новый стандарт и пройти весь путь по адаптации в железе и софте, который IPv6 уже прошел за 25 лет?

>>214800
Интернет-рынок еще очень далек от насыщения. Любая компания, которая сейчас захочет войти на хостинг, облачный или провайдерский рынок в любой точке мира прежде всего столкнется с нехваткой адресов и довольно значительными суммами необходимыми на покупку прав на вторичном рынке. 10 000 долларов за минимальный глобально маршрутизируемый /24-префикс, помимо членских взносов RIRа — это уже приличная сумма. Учитывая, что IP-адреса являются критически важным для функционирования бизнеса ресурсом, можно легко сделать прогноз, что эта цена будет только расти при продолжающемся увеличении спроса.
Миллионам африканцам и индусов понадобятся датацентры, которые их будут обслуживать, в том числе и от местных компаний. Как эти датацентры будут развиваться без адресов или с сумасшедшими ценами на них?

Про очевидные неудобства отсутствия домашней статики и про очевидные неудобства совместного использования IP-адресов и совместного попадания под различные ограничения на конечных сервисах и даже говорить не стоит.

>>214802

>продолжающемся росте базы пользователей и парка серверов.

Продолжающемся ли?
Опять же, с точки зрения простого смертного, подавляющее большинство бытовых умных девайсов ломится в облака сами, не полагаясь на наличие ната и/или статичность адресов. С точки зрения менее простого - хостинг сайтов или почтовика под кроватью - это, во-первых, удел гиков, во-вторых, им4ет кучу технических и юридических проблем помимо дефицита адресов, поди найди провайдера, откроющего 25й порт или согласного править ptr, например.
Насчёт числа пользователей, на неназываче при нескольких миллионах банов, из которых наверное многие приходятся на дальнее зарубежье, практически невозможно найти работающую прокси из СНГ. В то что баны идут широкими подсетями тоже верится с трудом, вряд ли все полтыщи модераторов знают что такое маска подсети. Итого кажется, что в СНГ счёт "белых пользователей" идёт на миллио6 или даже сотни тысяч, в мире миллионов на 10, и нет тенденции к сильному росту населения.

>>214802
Ленивых админов заставит только необходимость. Технической необходимости нет и в ближайшем обозримом будущем не предвидится. Про экономическую необходимость много говорят, но воз и ныне там. Административная необходимость более реальна, есть пример тех же индусов, которые массово переходят на ipv6. Но при этом тот же китай на v6 так же массово забивает, хотя и декларирует какие-то намерения.

Впрочем, повторюсь - если бы ipv6 отличался от ipv4 только размером адреса, этой дискуссии бы сейчас не было.

>>214806
Только таблица маршрутизации IPv4 выросла за 10 лет в три раза. Да, большая часть из этого — это фрагментация в следствии трансферта блоков IP, но если бы роста потребности не было, то и трансфертов бы не было.
Графики траффика, различных количеств соединений и конечных пользователей не слишком отличаются от этого в масштабах планеты.

>>214808
Насколько я понимаю, кпд, в плане доли полезной нагрузки на число бит в оптике у протоколов не отличается, логично вместе с увеличением трафика ожидать и расширения размеров таблиц адресации. Или там какой-то прямо-таки жёсткий физический размер в реализации таблиц маршрутизации есть, примерно как человекам сложно запоминать более длинные адреса? Почему под более длинные адреса в памяти не должно быть нужно кратно больше, с потенциально неограниченным ростом? Или это только активные соединения? Тогда по идее бороться с этим и наращивать железяки придётся аналогично как под наты сейчас, возможно даже хуже, 5сли пользователю выдано сразу /64 подсети.
Непонятно, в общем, в чем профит. Или это просто констатация роста числа "белых" пользователей?

>>214808
Ещё бы посчитать отдельно - фрагментацию, и отдельно - реальные нужды пользователей. ДЦ анонсируют сотни префиксов, которые на самом деле принадлежат их клиентам и не могут быть объединены. Есть и географические разделения. IPv6 ждёт то же самое, только префиксов будет больше просто в силу количества желающих и фактического отсутствия ограничений.

>>214811
Как ты их разделишь-то?
В IPv6 все-таки лучше должно быть за счет меньшей фрагментации и возможности легко выделять большие блоки клиентам от хостера.

По IPv6 аналогичный график количества BGP-записей.
В 2010 году их было всего 2500, а сейчас 150 000.
Так что адаптация идет, что бы там кто не говорил.

>>214812
Я говорю про то, что рост количества префиксов - это следствие роста сети, и фрагментация является одним из, и при этом далеко не самым значимым фактором.

Спасибо за бампы вашим дерейлом.
>>214789
Кстати, о "тут". Тред бы начат человеком, которому именно это и надо было объяснить. Может, другими словами, может, другому человеку с такими же проблемами (>>213066).
Вообще-то я хочу показывать это на примере. Собрать лабораторный стенд в настольной стойке из нескольких свичей, роутеров, серверов, и показать на практике, как и зачем работает сеть. Ну да ладно. Буду дальше искать людей вроде ОПа.

О, кстати, есть задача. На будущее, но уже таки есть.
Предположим, имеется три сетевых устройства: роутер, NAS с беспроводной карточкой и компьютер. Компьютер и NAS подключены к роутеру по гигабитной витой паре, NAS с компьютером дополнительно соединён десятигигабитной оптикой. Задача: как правильно сконфигурировать сеть, чтобы и компьютер, и NAS выходили в интернет через роутер, а между собой общались по оптике?

>>214820 А, и ещё: вайфай, раздаваемый NAS-ом, не должен включать в себя возможность выхода в интернет, только доступ к файлам на дисках.

>>214820
А в чём проблема?

Можно сделать статику в другой подсети и ходить напрямую оптикой. Грубо говоря в медной сети - 192.168.0.0/24, роутер - .1, комп - .2, нас - .3, а в оптической соответственно поставить 192.168.1.2/24 на компе и 192.168.1.3/24 на насе.

Можно ещё добавить маршруты через оптику и ходить по адресам из основной сети. Т.е. на компе добавляем маршрут до 192.168.0.3/32 через 192.168.1.3, и то же самое на насе с 192.168.0.2 через 192.168.1.2.

Раздаваемый насом вайфай с конфигурацией по умолчанию не будет иметь доступ в интернет (рассматриваем нетронутый линукс и hostapd в режиме точки без моста). Правильная конфигурация так же должна запрещать маршрутизацию без явного разрешения, т.е перед sysctl net.ipv4.ip_forward=1 делается iptables -P FORWARD DROP.

При необходимости использования ipv6 всё вышеописанное делается ещё раз.

>Cisco Packet Tracer

Как это добро ещё не закопали, когда есть GNS3?

>>214845
На GNS3 нельзя тесты из netacad проходить. Ну и собирать GNS под линукс это тот еще кошмар.