Сети для самых маленьких. Часть третья. Статическая маршрутизация

Мальчик сказал маме: “Я хочу кушать”. Мама отправила его к папе.
Мальчик сказал папе: “Я хочу кушать”. Папа отправил его к маме.
Мальчик сказал маме: “Я хочу кушать”. Мама отправила его к папе.
И бегал так мальчик, пока в один момент не упал.
Что случилось с мальчиком? TTL кончился.


Итак, поворотный момент в истории компании “Лифт ми Ап”. Руководство понимает, что компания, производящая лифты, едущие только вверх, не выдержит борьбы на высококонкурентном рынке. Необходимо расширять бизнес. Принято решение о покупке двух заводов: в Санкт-Петербурге и Кемерово.
Нужно срочно организовывать связь до новых офисов, а у вас ещё даже локалка не заработала.
Сегодня:
  1. Настраиваем маршрутизацию между вланами в нашей сети (InterVlan routing)
  2. Пытаемся разобраться с процессами, происходящими в сети, и что творится с данными
  3. Планируем расширение сети (IP-адреса, вланы, таблицы коммутации)
  4. Настраиваем статическую маршрутизацию и разбираемся, как она работает
  5. Используем L3-коммутатор в качестве шлюза




Содержание:
  • InterVlan Routing
  • Планирование расширения
    • IP-план
  • Принципы маршрутизации
  • Настройка
    • Москва. Арбат
    • Провайдер
    • Санкт-Петербург. Васильевский остров
    • Санкт-Петербург. Озерки
    • Кемерово. Красная горка
  • Дополнительно
  • Материалы выпуска

InterVlan Routing


Чуточку практики для взбадривания.
В предыдущий раз мы настроили коммутаторы нашей локальной сети. На данный момент устройства разных вланов не видят друг друга. То есть фактически ФЭО и ПТО, например, находятся в совершенно разных сетях и не связаны друг с другом. Так же и серверная сеть существует сама по себе. Надо бы исправить эту досадную неприятность.
В нашей московской сети для маршрутизации между вланами мы будем использовать роутер cisco 2811. Иными словами он будет терминировать вланы. Кадры здесь заканчивают свою жизнь: из них извлекаются IP-пакеты, а заголовки канального уровня отбрасываются.



Процесс настройки маршрутизатора очень прост:

0) Сначала закончим с коммутатором msk-arbat-dsw1. На нём нам нужно настроить транковый порт в сторону маршрутизатора, чего мы не сделали в прошлый раз.

msk-arbat-dsw1(config)#interface FastEthernet0/24
msk-arbat-dsw1(config-if)# description msk-arbat-gw1
msk-arbat-dsw1(config-if)# switchport trunk allowed vlan 2-3,101-104
msk-arbat-dsw1(config-if)# switchport mode trunk

1) Назначаем имя маршрутизатора командой hostname, а для развития хорошего тона, надо упомянуть, что лучше сразу же настроить время на устройстве. Это поможет вам корректно идентифицировать записи в логах.

Router0#clock set 12:34:56 7 august 2012
Router0# conf t
Router0(config)#hostname msk-arbat-gw1

Желательно время на сетевые устройства раздавать через NTP (любую циску можно сделать NTP-сервером, кстати)

2) Далее переходим в режим настройки интерфейса, обращённого в нашу локальную сеть и включаем его, так как по умолчанию он находится в состоянии Administratively down.

msk-arbat-gw1(config)#interface fastEthernet 0/0
msk-arbat-gw1(config-if)#no shutdown

3) Создадим виртуальный интерфейс или иначе его называют подинтерфейс или ещё сабинтерфейс (sub-interface).

msk-arbat-gw1(config)#interface fa0/0.2
msk-arbat-gw1(config-if)#description Management

Логика тут простая. Сначала указываем обычным образом физический интерфейс, к которому подключена нужная сеть, а после точки ставим некий уникальный идентификатор этого виртуального интерфейса. Для удобства, обычно номер сабинтерфейса делают аналогичным влану, который он терминирует.

4) Теперь вспомним о стандарте 802.1q, который описывает тегирование кадра меткой влана. Следующей командой вы обозначаете, что кадры, исходящие из этого виртуального интерфейса будут помечены тегом 2-го влана. А кадры, входящие на физический интерфейс FastEthernet0/0 с тегом этого влана будут приняты виртуальным интерфейсом FastEthernet0/0.2.

msk-arbat-gw1(config-if)#encapsulation dot1Q 2

5) Ну и как на обычном физическом L3-интерфейсе, определим IP-адрес. Этот адрес будет шлюзом по умолчанию (default gateway) для всех устройств в этом влане.

msk-arbat-gw1(config-if)#ip address 172.16.1.1 255.255.255.0

Аналогичным образом настроим, например, 101-й влан:

msk-arbat-gw1(config)#interface FastEthernet0/0.101
msk-arbat-gw1(config-if)#description PTO
msk-arbat-gw1(config-if)#encapsulation dot1Q 101
msk-arbat-gw1(config-if)#ip address 172.16.3.1 255.255.255.0

и теперь убедимся, что с компьютера из сети ПТО мы видим сеть управления:


Работает и отлично, настройте пока все остальные интерфейсы. Проблем с этим возникнуть не должно.

Физика и логика процесса межвланной маршрутизации


Что происходит в это время с вашими данными? Мы рассуждали в прошлый раз, что происходит, если вы пытаетесь связаться с устройством из той же самой подсети, в которой находитесь вы. Под той же самой подсетью мы понимаем следующее: например, на вашем компьютере настроено следующее:
IP: 172.16.3.2
Mask: 255.255.255.0
GW: 172.16.3.1

Все устройства, адреса которых будут находиться в диапазоне 172.16.3.1-172.16.3.254 с такой же маской, как у вас, будут являться членами вашей подсети. Что происходит с данными, если вы отправляете их на устройство с адресом из этого диапазона? Повторим это с некоторыми дополнениями.

Для отправки данных они должны быть упакованы в Ethernet-кадр, в заголовок которого должен быть вставлен MAC-адрес удалённого устройства. Но откуда его взять?
Для этого ваш компьютер рассылает широковещательный ARP-запрос. В качестве IP-адреса узла назначения в IP-пакет с этим запросом будет помещён адрес искомого хоста. Сетевая карта при инкапсуляции указывает MAC-адрес FF:FF:FF:FF:FF:FF — это значит, что кадр предназначен всем устройствам. Далее он уходит на ближайший коммутатор и копии рассылаются на все порты нашего влана (ну, кроме, конечно, порта, из которого получен кадр). Получатели видят, что запрос широковещательный и они могут оказаться искомым хостом, поэтому извлекают данные из кадра. Все те устройства, которые не обладают указанным в ARP-запросе IP-адресом, просто игнорируют запрос, а вот устройство-настоящий получатель ответит на него и вышлет первоначальному отправителю свой MAC-адрес. Отправитель (в данном случае, наш компьютер) помещает полученный MAC в свою таблицу соответствия IP и MAC адресов ака ARP-кэш. Как выглядит ARP-кэш на вашем компьютере прямо сейчас, вы можете посмотреть с помощью команды arp -a


Потом ваши полезные данные упаковываются в IP-пакет, где в качестве получателя ставится тот адрес, который вы указали в команде/приложении, затем в Ethernet-кадр, в заголовок которого помещается полученный ARP-запросом MAC-адрес. Далее кадр отправляется на коммутатор, который, согласно своей таблице MAC-адресов, решает, в какой порт его переправить дальше.

Но что происходит, если вы пытаетесь достучаться до устройства в другом влане? ARP-запрос ничего не вернёт, потому что широковещательные L2 сообщения кончаются на маршрутизаторе(т.е., в пределах широковещательного L2 домена), нужная сеть находится за ним, а коммутатор не пустит кадры из одного влана в порт другого. И вот для этого нужен шлюз по умолчанию (default gateway) на вашем компьютере. То есть, если устройство-получатель в вашей же подсети, кадр просто отправляется в порт с мак-адресом конечного получателя. Если же сообщение адресовано в любую другую подсеть, то кадр отправляется на шлюз по умолчанию, поэтому в качестве MAC-адреса получателя подставится MAC-адрес маршрутизатора.

Проследим за ходом событий.

1) ПК с адресом 172.16.3.2/24 хочет отправить данные компьютеру с адресом 172.16.4.5.

Он видит, что адрес из другой подсети, следовательно, данные должны уйти на шлюз по умолчанию. Но в таком случае, ПК нужен MAC-адрес шлюза. ПК проверяет свой ARP-кэш в поисках соответствия IP-адрес шлюза — MAC-адрес и не находит нужного


2) ПК отправляет широковещательный ARP-запрос в локальную сеть. Структура ARP-запроса:
— на канальном уровне в качестве получателя — широковещательный адрес ( FF:FF:FF:FF:FF:FF), в качестве отправителя — MAC-адрес интерфейса устройства, пытающегося выяснить IP
— на сетевом — собственно ARP запрос, в нем содержится информация о том, какой IP и кем ищется.


3) Коммутатор, на который попал кадр, рассылает его копии во все порты этого влана (того, которому принадлежит изначальный хост), кроме того, откуда он получен.
4) Все устройства, получив этот кадр и, видя, что он широковещательный, предполагают, что он адресован им.
5) Распаковав кадр, все хосты, кроме маршрутизатора, видят, что в ARP-запросе не их адрес. А маршрутизатор посылает unicast’овый ARP-ответ со своим MAC-адресом.
6) Изначальный хост получает ARP-ответ, теперь у него есть MAC-адрес шлюза. Он формирует пакет из тех данных, что ему нужно отправить на 172.16.4.5. В качестве MAC-адреса получателя ПК ставит адрес шлюза. При этом IP-адрес получателя в пакете остаётся 172.16.4.5


7) Кадр посылается в сеть, коммутаторы доставляют его на маршрутизатор.
8) На маршрутизаторе, в соответствии с меткой влана, кадр принимается конкретным сабинтерфейсом. Данные канального уровня откидываются.
9) Из заголовка IP-пакета, рутер узнаёт адрес получателя, а из своей таблицы маршрутизации видит, что тот находится в непосредственно подключенной к нему сети на определённом сабинтерфейсе (в нашем случае FE0/0.102).

C 172.16.0.0/24 is directly connected, FastEthernet0/0.3
C 172.16.1.0/24 is directly connected, FastEthernet0/0.2
C 172.16.2.16/30 is directly connected, FastEthernet0/1.5
C 172.16.3.0/24 is directly connected, FastEthernet0/0.101
C 172.16.4.0/24 is directly connected, FastEthernet0/0.102
C 172.16.5.0/24 is directly connected, FastEthernet0/0.103
C 172.16.6.0/24 is directly connected, FastEthernet0/0.104

10) Маршрутизатор отправляет ARP-запрос с этого сабинтерфейса — узнаёт MAC-адрес получателя.
11) Изначальный IP-пакет, не изменяясь инкапсулируется в новый кадр, при этом:
  • в качестве MAC-адреса источника указывается адрес интерфейса шлюза
  • IP-адрес источника — адрес изначального хоста (в нашем случае 172.16.3.2)
  • в качестве MAC-адреса получателя указывается адрес конечного хоста
  • IP-адрес получателя — адрес конечного хоста (в нашем случае 172.16.4.5)
и отправляется в сеть с сабинтерфейса FastEthernet0/0.102, получая при этом метку 102-го влана.

12) Кадр доставляется коммутаторами до хоста-получателя.

Планирование расширения


Теперь обратимся к планированию. В нулевой части мы уже затронули эту тему, но тогда речь была только о двух офисах в Москве, теперь же сеть растёт.

Будет она вот такой:


То есть прибавляются две точки в Санкт-Петербурге: небольшой офис на Васильевском острове и сам завод в Озерках — и одна в Кемерово в районе Красная горка. Для простоты у нас будет один провайдер “Балаган Телеком”, который на выгодных условиях предоставит нам L2VPN до обеих точек. В одном из следующих выпусков мы тему различных вариантов подключения раскроем в красках. А пока вкратце: L2VPN — это, очень грубо говоря, когда вам провайдер предоставляет влан от точки до точки (можно для простоты представить, что они включены в один коммутатор).

Следует сказать несколько слов об IP-адресации и делении на подсети. В нулевой части мы уже затронули вопросы планирования, весьма вскользь, надо сказать. Вообще, в любой более или менее большой компании должен быть некий регламент — свод правил, следуя которому вы распределяете IP-адреса везде. Сеть у нас сейчас разрастается и разработать его очень важно.

Ну вот к примеру, скажем, что для офисов в других городах это будет так:


Это весьма упрощённый регламент, но теперь мы во всяком случае точно знаем, что у шлюза всегда будет 1-й адрес, до 12-го мы будем выдавать коммутаторам и всяким wi-fi-точкам, а все сервера будем искать в диапазоне 172.16.х.13-172.16.х.23. Разумеется, по своему вкусу вы можете уточнять регламент вплоть до адреса каждого сервера, добавлять в него правило формирования имён устройств, доменных имён, политику списков доступа и т.д. Чем точнее вы сформулируете правила и строже будете следить за их выполнением, тем проще разбираться в структуре сети, решать проблемы, адаптироваться к ситуации и наказывать виновных. Это примерно, как схема запоминания паролей: когда у вас есть некое правило их формирования, вам не нужно держать в голове несколько десятков сложнозапоминаемых паролей, вы всегда можете их вычислить. Вот так же и тут. Я некогда работал в средних размеров холдинге и знал, что если я приеду в офис где-нибудь в забытой коровами деревне, то там точно x.y.z.1 — это циска, x.y.z.2 — дистрибьюшн-свитч прокурва, а x.y.z.101 — компьютер главного бухгалтера, с которого надо дать доступ на какой-нибудь контур-экстерн. Другой вопрос, что надо это ещё проверить, потому что местные ИТшники такого порой наворотят, что слезами омываешься сквозь смех.
Было дело парнишка решил сам управлять всем доступом в интернет (обычно это делал я на маршрутизаторе). Поставил proxy-сервер, случайно поднял на нём NAT и зарулил туда трафик локальной сети, на всех машинах прописав его в качестве шлюза по умолчанию, а потом я минут 20 разбирался, как так: у них всё работает, а мы их не видим.

IP-план


Теперь нам было бы весьма кстати составить IP-план. Будем исходить из того, что на всех трёх точках мы будем использовать стандартную сеть с маской 24 бита (255.255.255.0) Это означает, что в них может быть 254 устройства.

Почему это так? И как вообще понять все эти маски подсетей? В рамках одной статьи мы не сможем этого рассказать, иначе она получится длинная, как палуба Титаника и запутанная, как одесские катакомбы. Крайне рекомендуем очень плотно познакомиться с такими понятиями, как IP-адрес, маска подсети, их представления в двоичном виде и CIDR (Classless InterDomain Routing) самостоятельно. Мы же далее будем только аргументировать выбор конкретного размера сети. Как бы то ни было, полное понимание придёт только с практикой.
Вообще, очень неплохо эта тема раскрыта в этой статье: http://habrahabr.ru/post/129664/


В данный момент (вспомним нулевой выпуск) у нас в Москве использованы адреса 172.16.0.0-172.16.6.255. Предположим, что сеть может ещё увеличиться здесь, допустим, появится офис на Воробьёвых горах и зарезервируем ещё подсети до 172.16.15.0/24 включительно.
Все эти адреса: 172.16.0.0-172.16.15.255 — можно описать так: 172.16.0.0/20. Эта сеть (с префиксом /20) будет так называемой суперсетью, а операция объединения подсетей в суперсети называется суммированием подсетей (суммированием маршрутов, если быть точным, route summarization)

Очень наглядный IP-калькулятор. Я и сейчас им периодически пользуюсь, хотя со временем приходит интуитивное и логическое понимание соответствия между длиной маски и границами сети.

Теперь обратимся к Питеру. В данный момент в этом прекрасном городе у нас 2 точки и на каждой из них подсети /24. Допустим это будут 172.16.16.0/24 и 172.16.17.0/24. Зарезервируем адреса 172.16.18.0-172.16.23.255 для возможного расширения сети.

172.16.16.0-172.16.23.255 можно объединить в 172.16.16.0/21 — в общем-то исходя именно из этого мы и оставляем в резерв именно такой диапазон.

В Кемерово нам нет смысла оставлять такие огромные запасы /21, как в Питере (2048 адресов или 8 подсетей /24), или тем более /20, как в Москве (4096 или 16 подсетей /24). А вот 1024 адреса и 4 подсети /24, которым соответствует маска /22 вполне рационально.

Таким образом сеть 172.16.24.0/22 (адреса 172.16.24.0-172.16.27.255) будет у нас для Кемерово.



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

ip route 172.16.16.0 255.255.255.0 172.16.2.2
ip route 172.16.17.0 255.255.255.0 172.16.2.2
ip route 172.16.18.0 255.255.255.0 172.16.2.2
……
ip route 172.16.23.0 255.255.255.0 172.16.2.2

Это 8 команд и 8 записей в таблице. Но при этом пришедший на маршрутизатор пакет в любую из сетей 172.16.16.0/21 в любом случае будет отправлен на устройство с адресом 172.16.2.2.
Вместо этого мы поступим так:

ip route 172.16.16.0 255.255.248.0 172.16.2.2

И вместо восьми возможных сравнений будет только одно.
Для современных устройств ни в плане процессорного времени ни использования памяти это уже не является существенной нагрузкой, однако такое планирование считается правилами хорошего тона и в конечном итоге вам же самим проще разобраться. Положа руку на сердце, такое планирование скорее исключение, нежели правило: так или иначе фрагментация маршрутов с ростом сети неизбежна.

Теперь ещё несколько слов о линковых сетях. В среде сетевых администраторов так называются сети точка-точка (Point-to-Point) между двумя маршрутизаторами.
Вот опять же в примере с Питером. Два маршрутизатора (в Москве и в Петербурге) соединены друг с другом прямым линком (неважно, что у провайдера это сотня коммутаторов и маршрутизаторов — для нас это просто влан). То есть кроме вот этих 2-х устройств здесь не будет никаких других. Мы знаем это наверняка. В любом случае на интерфейсах обоих устройств (смотрящих в сторону друг друга) нужно настраивать IP-адреса. И нам точно незачем назначать на этом участке сеть /24 с 254 доступными адресами, ведь 252 в таком случае пропадут почём зря. В этом случае есть прекрасный выход — бесклассовая IP-адресация.

Почему она бесклассовая? Если вы помните, то в нулевой части мы говорили о трёх классах подсетей: А, В и С. По идее только их вы и могли использовать при планировании сети. Бесклассовая междоменная маршрутизация (CIDR) позволяет очень гибко использовать пространство IP-адресов.

Мы просто берём сеть с самой маленькой возможной маской — 30 (255.255.255.252) — это сеть на 4 адреса. Почему мы не можем взять сеть с ещё более узкой маской? Ну 32 (255.255.255.255) по понятными причинам — это вообще один единственный адрес, сеть 31 (255.255.255.254) — это уже 2 адреса, но один из них (первый) — это адрес сети, а второй (последний) — широковещательный. В итоге на адреса хостов у нас и не осталось ничего. Поэтому и берём маску 30 с 4 адресами и тогда как раз 2 адреса остаются на наши два маршрутизатора.

Вообще говоря, самой узкой маской для подсетей в cisco таки является /31. При определённых условиях их можно использовать на P-t-P-линках.
Что же касается маски /32, то такие подсети, которые суть один единственный хост, используются для назначения адресов Loopback-интерфейсам.


Именно так мы и поступим. Для этого, собственно, в нулевой части мы и оставили сеть 172.16.2.0/24 — её мы будем дробить на мелкие сетки /30. Всего их получится 64 штуки, соответственно можно назначить их на 64 линка.



Здесь мы поступили так же, как и в предыдущем случае: сделали небольшой резерв для Питера, и резерв для Кемерово. Вообще резерв — это всегда очень хорошо о чём бы мы ни говорили. ;)

Принципы маршрутизации


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


Вот к примеру с компьютера ПК1 — 172.16.3.2 я хочу подключиться по telnet к L3-коммутатору с адресом 172.16.17.1.
Как мой компьютер узнает что делать? Куда слать данные?

1) Как вы уже знаете, если адрес получателя из другой подсети, то данные нужно отправлять на шлюз по умолчанию.
2) По уже известной вам схеме компьютер с помощью ARP-запроса добывает MAC-адрес маршрутизатора.
3) Далее он формирует кадр с инкапсулированным в него пакетом и отсылает его в порт. После того, как кадр отправлен, компьютеру уже по барабану, что происходит с ним дальше.
4) А сам кадр при этом попадает сначала на коммутатор, где решается его судьба согласно таблице MAC-адресов. А потом достигает маршрутизатора RT1.
5) Поскольку маршрутизатор ограничивает широковещательный домен — здесь жизнь этого кадра и заканчивается. Циска просто откидывает заголовок канального уровня — он уже не пригодится — извлекает из него IP-пакет.
6) Теперь маршрутизатор должен принять решение, что с ним делать дальше. Разумеется, отправить его на какой-то свой интерфейс. Но на какой?
Для этого существует таблица маршрутизации, которая есть на любом рутере. Выяснить, что у нас в данный момент находится в таблице маршрутизации, можно с помощью команды show ip route:

172.16.0.0/16 is variably subnetted, 10 subnets, 3 masks
C 172.16.3.0/24 is directly connected, FastEthernet0/0.101
C 172.16.2.0/30 is directly connected, FastEthernet0/1.4
S 172.16.17.0/24 [1/0] via 172.16.2.2

Каждая строка в ней — это способ добраться до той или иной сети.
Вот к примеру, если пакет адресован в сеть 172.16.17.0/24, то данные нужно отправить на устройство с адресом 172.16.2.2.
Таблица маршрутизации формируется из:
— непосредственно подключенных сетей (directly connected) — это сети, которые начинаются непосредственно на нём. В примере 172.16.3.0/24 и 172.16.2.0/30. В таблице они обозначаются буквой C
— статический маршруты — это те, которые вы прописали вручную командой ip route. Обозначаются буквой S
— маршруты, полученные с помощью протоколов динамической маршрутизации (OSPF, EIGRP, RIP и других).

7) Итак, данные в сеть 172.16.17.0 (а мы хотим подключиться к устройству 172.16.17.1) должны быть отправлены на следующий хоп — следующий прыжок, которым является маршрутизатор 172.16.2.2. Причём из таблицы маршрутизации видно, что находится следующий хоп за интерфейсом FE0/1.4 (подсеть 172.16.2.0/30).
8)Если в ARP-кэше циски нет MAC-адреса, то надо снова выполнить ARP-запрос, чтобы узнать MAC-адрес устройства с IP-адресом 172.16.2.2. RT1 посылает широковещательный кадр с порта FE0/1.4. В этом широковещательном домене у нас два устройства, и соответственно только один получатель. RT2 получает ARP-запрос, отбрасывает заголовок Ethernet и, понимая из данных протокола ARP, что искомый адрес принадлежит ему отправляет ARP-ответ со своим MAC-адресом.
9) Изначальный IP-пакет, пришедший на RT1 не меняется, он инкапсулируется в совершенно новый кадр и отправляется в порт FE0/1.4, получая при этом метку 4-го влана.
10) Полностью аналогичные действия происходят на следующем маршрутизаторе. И на следующем и следующем (если бы они были), пока пакет не дойдёт до последнего, к которому и подключена нужная сеть.
11) Последний маршрутизатор (коим является L3-коммутатор) видит, что искомый адрес принадлежит ему самому, а извлекая данные транспортного уровня, понимает, что это телнет и передаёт все данные верхним уровням.

Так вот и путешествуют данные с одного хопа на другой и ни один маршрутизатор представления не имеет о дальнейшей судьбе пакета. Более того, он даже не знает есть ли там действительно эта сеть — он просто доверяет своей таблице маршрутизации.

Настройка


Каким образом мы организуем каналы связи? Как мы уже сказали выше, в нашем офисе на Арбате есть некий провайдер Балаган-Телеком. Он обещает нам предоставить всё, что мы только захотим почти задарма. И мы заказываем у него две услуги L2VPN, то есть он отдаст нам два влана на Арбате в Москве, и по одному в Питере и Кемерово.
Вообще говоря, номера вланов вам придётся согласовывать с вашим провайдером по той простой причине, что у него они могут быть просто заняты. Поэтому вполне возможно, что у вас будет влан, например, 2912 или 754. Но предположим, что нам повезло, и мы вольны сами выбирать номер.

Москва. Арбат


На циске в Москве у нас два интерфейса, к одному — FE0/0 — уже подключена наша локальная сеть, а второй (FE0/1)мы будем использовать для выхода в интернет и для подключения удалённых офисов.
Как и в самом начале создадим саб-интерфейсы. Выделим для Санкт-Петербурга и Кемерова 4 и 5-й вланы соответственно. IP-адреса берём из нового IP-плана.

msk-arbat-gw1(config)#interface FastEthernet 0/1.4
msk-arbat-gw1(config-subif)#description Saint-Petersburg
msk-arbat-gw1(config-subif)#encapsulation dot1Q 4
msk-arbat-gw1(config-subif)#ip address 172.16.2.1 255.255.255.252
msk-arbat-gw1(config)#interface FastEthernet 0/1.5
msk-arbat-gw1(config-subif)#description Kemerovo
msk-arbat-gw1(config-subif)#encapsulation dot1Q 5
msk-arbat-gw1(config-subif)#ip address 172.16.2.17 255.255.255.252

Провайдер


Разумеется, мы не будем строить всю сеть провайдера. Вместо этого просто поставим коммутатор, ведь по сути сеть провайдера с нашей точки зрения будет одним огромным абстрактным коммутатором.

Тут всё просто: принимаем транком линк с Арбата в один порт и с двух других портов отдаём их на удалённые узлы. Ещё раз хотим подчеркнуть, что все эти 3 порта не принадлежат одному коммутатору — они разнесены на сотни километров, между ними сложная MPLS-сеть с кучей коммутаторов.

Настраиваем “эмулятор провайдера”:

Switch(config)#vlan 4
Switch(config-vlan)#vlan 5
Switch(config)#interface fa0/1
Switch(config-if)#switchport mode trunk
Switch(config-if)#switchport trunk allowed vlan 4-5
Switch(config-if)#exit
Switch(config)#int fa0/2
Switch(config-if)#switchport trunk allowed vlan 4
Switch(config-if)#int fa0/3
Switch(config-if)#switchport trunk allowed vlan 5

Санкт-Петербург. Васильевский остров


Теперь обратимся к нашему spb-vsl-gw1. Тут у нас тоже 2 порта, но решим вопрос нехватки портов иначе: добавим сюда плату. Плата с двумя FastEthernet-портам и двумя слотами для WIC вполне подойдёт.



Пусть встроенные порты будут для локальной сети, а порты на дополнительной плате мы используем для аплинка и связи с Озерками.



Здесь вы можете увидеть отличие в нумерации портов и понять их смысл.
FastEthernet — это тип порта (Ethernet, Fastethernet, GigabitEthernet, POS, Serial или другие)
x/y/z.w=Slot/Sub-slot/Interface.Sub-interface.

Каким образом здесь вам провайдер будет отдавать канал — транком или аксесом, вы решаете сообща. Как правило, для него не составит проблем ни один из вариантов.
Но мы уже настроили транк, поэтому соответствующим образом настраиваем порт на циске:

spb-vsl-gw1(config)interface FastEthernet1/0.4
spb-vsl-gw1(config-if)description Moscow
spb-vsl-gw1(config-if)encapsulation dot1Q 4
spb-vsl-gw1(config-if)ip address 172.16.2.2 255.255.255.252

Добавим ещё локальную сеть:

spb-vsl-gw1(config)#int fa0/0
spb-vsl-gw1(config-if)#description LAN
spb-vsl-gw1(config-if)#ip address 172.16.16.1 255.255.255.0

Вернёмся в Москву. С msk-arbat-gw1 мы можем увидеть адрес 172.16.2.2:

msk-arbat-gw1#ping 172.16.2.2

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.16.2.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 2/7/13 ms

Но так же не видим 172.16.16.1:

msk-arbat-gw1#ping 172.16.16.1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.16.16.1, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)

Опять же, потому что маршрутизатор не знает, куда слать пакет:

msk-arbat-gw1#sh ip route 

Gateway of last resort is not set

172.16.0.0/16 is variably subnetted, 8 subnets, 2 masks
C 172.16.0.0/24 is directly connected, FastEthernet0/0.3
C 172.16.1.0/24 is directly connected, FastEthernet0/0.2
C 172.16.2.0/30 is directly connected, FastEthernet0/1.4
C 172.16.3.0/24 is directly connected, FastEthernet0/0.101
C 172.16.4.0/24 is directly connected, FastEthernet0/0.102
C 172.16.5.0/24 is directly connected, FastEthernet0/0.103
C 172.16.6.0/24 is directly connected, FastEthernet0/0.104

Исправим это недоразумение:

msk-arbat-gw1(config)#ip route 172.16.16.0 255.255.255.0 172.16.2.2

msk-arbat-gw1#sh ip route
Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS inter area
* - candidate default, U - per-user static route, o - ODR
P - periodic downloaded static route

Gateway of last resort is not set

172.16.0.0/16 is variably subnetted, 9 subnets, 2 masks
C 172.16.0.0/24 is directly connected, FastEthernet0/0.3
C 172.16.1.0/24 is directly connected, FastEthernet0/0.2
C 172.16.2.0/30 is directly connected, FastEthernet0/1.4
C 172.16.2.16/30 is directly connected, FastEthernet0/1.5
C 172.16.3.0/24 is directly connected, FastEthernet0/0.101
C 172.16.4.0/24 is directly connected, FastEthernet0/0.102
C 172.16.5.0/24 is directly connected, FastEthernet0/0.103
C 172.16.6.0/24 is directly connected, FastEthernet0/0.104
S 172.16.16.0/24 [1/0] via 172.16.2.2

Теперь пинг появляется:

msk-arbat-gw1#ping 172.16.16.1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.16.16.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/10/24 ms

Вот, казалось бы оно — счастье, но проверим связь с компьютера:


В чём дело?!
Компьютер знает, куда отправлять пакет — на свой шлюз 172.16.3.1, маршрутизатор тоже знает — на хост 172.16.2.2. Пакет уходит туда, принимается spb-vsl-gw1, который знает, что пингуемый адрес 172.16.16.1 принадлежит ему. А обратно нужно отправить пакет на адрес 172.16.3.3, но в сеть 172.16.3.0 у него нет маршрута. А пакеты, сеть назначения которых неизвестна, просто дропятся — отбрасываются.

spb-vsl-gw1#sh ip route 

Gateway of last resort is not set

172.16.0.0/16 is variably subnetted, 2 subnets, 2 masks
C 172.16.2.0/30 is directly connected, FastEthernet1/0.4
C 172.16.16.0/24 is directly connected, FastEthernet0/0

Но, почему же, спросите вы, с msk-arbat-gw1 до 172.16.16.1 пинг был? Какая разница 172.16.3.1 или 172.16.3.2? Всё просто.
Из таблицы маршрутизации всем видно, что следующий хоп — 172.16.2.2, при этом адрес из 172.16.2.1 принадлежит интерфейсу этого маршрутизатора, поэтому он и ставится в заголовок в качестве IP-адреса отправителя, а не 172.16.3.1. Пакет отправляется на spb-vsl-gw1, тот его принимает, передаёт данные приложению пинг, которое формирует echo-reply. Ответ инкапсулируется в IP-пакет, где в качестве адреса получателя фигурирует 172.16.2.1, а 172.16.2.0/30 — непосредственно подключенная к spb-vsl-gw1 сеть, поэтому без проблем пакет доставляется по назначению. То етсь в сеть 172.16.2.0/30 маршрут известен, а в 172.16.3.0/24 нет.

Для решения этой проблемы мы можем прописать на spb-vsl-gw1 маршрут в сеть 172.16.3.0, но тогда придётся прописывать и для всех других сетей. Для всех сетей в Москве, потом в Кемерово, потом в других городах — очень большой объём настройки. Тут стоить заметить, что по сути у нас только один выход в мир — через Москву. Узел в Озерках — тупиковый, а других нет. То есть в основном все данные будут уходить в Москву, где большая часть подсетей и будет выход в интернет. Чем нам это может помочь? Есть такое понятие — маршрут по умолчанию, ещё он носит романтическое название шлюз — последней надежды. И второму есть объяснение. Когда маршрутизатор решает, куда отправить пакет, он просматривает всё таблицу маршрутизации и, если не находит нужного маршрута, пакет отбрасывается — это если у вас не настроен шлюз последней надежды, если же настроен, то сиротливые пакеты отправляются именно туда — просто не глядя, предоставляя право уже следующему хопу решать их дальнейшую судьбу. То есть если некуда отправить, то последняя надежда — маршрут по умолчанию.
Настраивается он так:

spb-vsl-gw1(config)#ip route 0.0.0.0 0.0.0.0 172.16.2.1

И теперь тадааам:



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

Санкт-Петербург. Озерки


Теперь озаботимся Озерками. Здесь мы поставим L3-коммутатор. Допустим, связаны они у нас будут арендованным у провайдера волокном (конечно, это идеализированная ситуация для маленькой компании, но можно же помечтать). Использование коммутаторов третьего уровня весьма удобно в некоторых случаях. Во-первых, интервлан роутинг в этом случае делается аппаратно и не нагружает процессор, в отличие от маршрутизатора. Кроме того, один L3-коммутатор обойдётся вам значительно дешевле, чем L2-коммутатор и маршрутизатор по отдельности. Правда, при этом вы лишаетесь ряда функций, естественно. Поэтому при выборе решения будьте аккуратны.

Настроим маршрутизатор на Васильевском острове, согласно плану:

spb-vsl-gw1(config)interface fa1/1
spb-vsl-gw1(config-if)#description Ozerki
spb-vsl-gw1(config-if)#ip address 172.16.2.5 255.255.255.252

Поскольку мы уже запланировали сеть для Озерков 172.16.17.0/24, то можем сразу прописать туда маршрут:

spb-vsl-gw1(config)#ip route 172.16.17.0 255.255.255.0 172.16.2.6

В качестве некст хопа ставим адрес, который мы выделили для линковой сети на Озерках — 172.16.2.6

Теперь перенесёмся в сами Озерки:
Подключим кабель в уже настроенный порт fa1/1 на стороне Васильевского острова и в 24-й порт 3560 в Озерках. По умолчанию все порты L3-коммутатора работают в режиме L2, то есть это обычные “свитчёвые” порты, на которых мы можем настроить вланы. Но любой из них мы можем перевести в L3-режим, сделав портом маршрутизатора. Тогда на нём мы сможем настроить IP-адрес:

Switch(config)#hostname spb-ozerki-gw1
spb-ozerki-gw1(config)#interface fa0/24
spb-ozerki-gw1(config-if)#no switchport
spb-ozerki-gw1(config-if)#ip address 172.16.2.6 255.255.255.252

Проверяем связь:

spb-ozerki-gw1#ping 172.16.2.5

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.16.2.5, timeout is 2 seconds:
.!!!!
Success rate is 80 percent (4/5), round-trip min/avg/max = 1/18/61 ms

Настроим ещё локальную сеть. Напомним, что Cisco и другие производители и не только производители не рекомендуют использовать 1-й влан, поэтому, мы воспользуемся 2-м:

spb-ozerki-gw1(config)#vlan 2
spb-ozerki-gw1(config-vlan)#name LAN
spb-ozerki-gw1(config-vlan)#exit
spb-ozerki-gw1(config)#interface vlan 2
spb-ozerki-gw1(config-if)#description LAN
spb-ozerki-gw1(config-if)#ip address 172.16.17.1 255.255.255.0
spb-ozerki-gw1(config)#interface fastEthernet 0/1
spb-ozerki-gw1(config-if)#description Pupkin
spb-ozerki-gw1(config-if)#switchport mode access
spb-ozerki-gw1(config-if)#switchport access vlan 2

После этого все устройства во втором влане будут иметь шлюзом 172.16.17.1



Чтобы коммутатор превратился в почти полноценный маршрутизатор, надо дать ещё одну команду:

spb-ozerki-gw1(config)#ip routing 

Таким образом мы включим возможность маршрутизации.

Никаких других маршрутов, кроме как по умолчанию нам тут не надо:

spb-ozerki-gw1(config)#ip route 0.0.0.0 0.0.0.0 172.16.2.5

Связь до spb-vsl-gw1 есть:

spb-ozerki-gw1#ping 172.16.16.1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.16.16.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 3/50/234 ms

А до Москвы нет:

spb-ozerki-gw1#ping 172.16.3.1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.16.3.1, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)

Опять же дело в отсутствии маршрута. Вообще удобный инструмент для нахождения примерного места расположения проблемы traceroute:

spb-ozerki-gw1#traceroute 172.16.3.1
Type escape sequence to abort.
Tracing the route to 172.16.3.1

1 172.16.2.5 4 msec 2 msec 5 msec
2 * * *
3 * * *
4 *

Как видите, что от spb-vsl-gw1 ответ приходит, а дальше глухо. Это означает, как правило, что или на хопе с адресом 172.16.2.5 не прописан маршрут в нужную сеть (вспоминаем, что у нас настроен там маршрут по умолчанию, которого достаточно) или на следующем нету маршрута обратно:

msk-arbat-gw1#sh ip rou

Gateway of last resort is not set

172.16.0.0/16 is variably subnetted, 9 subnets, 2 masks
C 172.16.0.0/24 is directly connected, FastEthernet0/0.3
C 172.16.1.0/24 is directly connected, FastEthernet0/0.2
C 172.16.2.0/30 is directly connected, FastEthernet0/1.4
C 172.16.2.16/30 is directly connected, FastEthernet0/1.5
C 172.16.3.0/24 is directly connected, FastEthernet0/0.101
C 172.16.4.0/24 is directly connected, FastEthernet0/0.102
C 172.16.5.0/24 is directly connected, FastEthernet0/0.103
C 172.16.6.0/24 is directly connected, FastEthernet0/0.104
S 172.16.16.0/24 [1/0] via 172.16.2.2

Действительно маршрута в подсеть 172.16.17.0/24 нет. Мы можем прописать его, вы это уже умеете, а можем вспомнить, что целую подсеть 172.16.16.0/21 мы выделили под Питер, поэтому вместо того, чтобы по отдельности добавлять маршрут в каждую новую сеть, мы пропишем агрегированный маршрут:

msk-arbat-gw1(config)#no ip route 172.16.16.0 255.255.255.0 172.16.2.2
msk-arbat-gw1(config)#ip route 172.16.16.0 255.255.248.0 172.16.2.2

Проверяем:

msk-arbat-gw1#ping 172.16.17.1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.16.17.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/10/18 ms

Но странной неожиданностью для вас может стать то, что с spb-ozerki-gw1 вы не увидите Москву по-прежнему:

spb-ozerki-gw1#ping 172.16.3.1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.16.3.1, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)

Но при этом, если в качестве адреса-источника мы укажем 172.16.17.1:

spb-ozerki-gw1#ping 
Protocol [ip]:
Target IP address: 172.16.3.1
Repeat count [5]:
Datagram size [100]:
Timeout in seconds [2]:
Extended commands [n]: y
Source address or interface: ping172.16.17.1
% Invalid source
Source address or interface: 172.16.17.1
Type of service [0]:
Set DF bit in IP header? [no]:
Validate reply data? [no]:
Data pattern [0xABCD]:
Loose, Strict, Record, Timestamp, Verbose[none]:
Sweep range of sizes [n]:
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.16.3.1, timeout is 2 seconds:
Packet sent with a source address of 172.16.17.1
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 5/9/14 ms

И даже с компьютера 172.16.17.26 связь есть:



Как же так? Ответ, вы не поверите, так же прост — проблемы с маршрутизацией.

Дело в том, что msk-arbat-gw1 о подсети 172.16.17.0/24 знает, а о 172.16.2.4/30 нет. А именно адрес 172.16.2.6 — адрес ближайшего к адресату интерфейса (или интерфейса, с которого отправляется IP-пакет) подставляет по умолчанию в качестве источника. Об этом забывать не нужно.

msk-arbat-gw1(config)#ip route 172.16.2.4 255.255.255.252 172.16.2.2

spb-ozerki-gw1#ping 172.16.3.1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.16.3.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 7/62/269 ms

Ещё интересный опыт: а что если адрес на маршрутизаторе на Васильевском острове маршрут в подсеть 172.16.3.0/24 пропишем на Озерки, а не в Москву? Ну чисто для интереса. Что произойдёт в этом случае?

spb-vsl-gw1(config)#ip route 172.16.3.0 255.255.255.0 172.16.2.6

В РТ вы этого не увидите, почему-то, но в реальной жизни получится кольцо маршрутизации. Сети 172.16.3.0/24 и 172.16.16.0/21 не будут видеть друг друга:
пакет идущий с spb-ozerki-gw1 в сеть 172.16.3.0 попадает в первую очередь на spb-vsl-gw1, где сказано: “172.16.3.0/24 ищите за 172.16.2.6”, а это снова spb-ozerki-gw1, где сказано: “172.16.3.0/24 ищите за 172.16.2.5” и так далее. Пакет будет шастать туда-обратно, пока не истечёт значение в поле TTL.
Дело в том, что при прохождении каждого маршрутизатора поле TTL в IP-заголовке, изначально имеющее значение 255, уменьшается на 1. И если вдруг окажется, что это значение равно 0, то пакет погибает, точнее маршрутизатор, увидевший это, задропит его. Таким образом обеспечивается стабильность сети — в случае возникновения петли пакеты не будут жить бесконечно, нагружая канал до его полной утилизации. Кстати, в Ethernet такого механизма нет и если получается петля, то коммутатор только и будет делать, что плодить широковещательные запросы, полностью забивая канал — это называется широковещательный шторм (эта проблема решается с помощью специальной технологии\протокола STP- об этом в следующем выпуске).

В общем, если вы пускаете пинг из сети 172.16.17.0 на адрес 172.16.3.1, то ваш IP-пакет будет путешествовать между двумя маршрутизаторами, пока не истечёт срок его жизни, пройдя при этом по линку между Озерками и Васильевским островом 254 раза. Кстати, следствием из работы этого механизма является то, что не может существовать связная сеть, где между узлами больше 255 маршрутизаторов. Впрочем это и не очень актуальная потребность. Сейчас даже самый долгий трейс занимает пару-тройку десятков хопов.

Кемерово. Красная горка


Рассмотрим последний небольшой пример — маршрутизатор на палочке (router on a stick). Название навеяно схемой подключения:


Маршрутизатор связан с коммутатором лишь одним кабелем и по разным вланам внутри него передаётся трафик и локальной сети, и внешний. Делается это, как правило, для экономии средств (на маршрутизаторе только один порт и не хочется покупать дополнительную плату). Подключим следующим образом:


Настройка коммутатора уже не должна для вас представлять проблем. На UpLink-интерфейсе настраиваем оговоренный с провайдером 5-й влан транком:

Switch(config)#hostname kmr-gorka-sw1
kmr-gorka-sw1(config)#vlan 5
kmr-gorka-sw1(config-vlan)#name Moscow
kmr-gorka-sw1(config)#int fa0/24
kmr-gorka-sw1(config-if)#description Moscow
kmr-gorka-sw1(config-if)#switchport mode trunk
kmr-gorka-sw1(config-if)#switchport trunk allowed vlan 5

В качестве влана для локальной сети выберем vlan 2 и это ничего, что он уже используется и в Москве и в Питере — если они не пересекаются и вы это можете контролировать, то номера могут совпадать. Тут каждый решает сам: вы можете везде использовать, например, 2-й влан, в качестве влана локальной сети или напротив разработать план, где номера вланов уникальны во всей сети.

kmr-gorka-sw1(config)#vlan 2
kmr-gorka-sw1(config-vlan)#name LAN
kmr-gorka-sw1(config)#int fa0/1
kmr-gorka-sw1(config-if)#description syn_generalnogo
kmr-gorka-sw1(config-if)#switchport mode access
kmr-gorka-sw1(config-if)#switchport access vlan 2

Транк в сторону маршрутизатора, где 5-ым вланом будут тегироваться кадры внешнего трафика, а 2-м — локального.

kmr-gorka-sw1(config)#int fa0/23
kmr-gorka-sw1(config-if)#description kmr-gorka-gw1
kmr-gorka-sw1(config-if)#switchport mode trunk
kmr-gorka-sw1(config-if)#switchport trunk allowed vlan 2,5

Настройка маршрутизатора:

Router(config)#hostname kmr-gorka-gw1
kmr-gorka-gw1(config)#int fa0/0.5
kmr-gorka-gw1(config-subif)#description Moscow
kmr-gorka-gw1(config-subif)#encapsulation dot1Q 5
kmr-gorka-gw1(config-subif)#ip address 172.16.2.18 255.255.255.252
kmr-gorka-gw1(config)#int fa0/0
kmr-gorka-gw1(config-if)#no sh
kmr-gorka-gw1(config)#int fa0/0.2
kmr-gorka-gw1(config-subif)#description LAN
kmr-gorka-gw1(config-subif)#encapsulation dot1Q 2
kmr-gorka-gw1(config-subif)#ip address 172.16.24.1 255.255.255.0

Полагаем, что маршрутизацию здесь между Москвой и Кемерово вы теперь сможете настроить самостоятельно.

Дополнительно


В случае, если с маршрутизацией не всё в порядке для траблшутинга вам понадобятся две команды:
traceroute и show ip route.
У первой бывает полезным, как вы видели, задать адрес источника. А последнюю можно применять с параметрами, например:

msk-arbat-gw1#sh ip route 172.16.17.0
Routing entry for 172.16.16.0/21
Known via "static", distance 1, metric 0
Routing Descriptor Blocks:
* 172.16.2.2
Route metric is 0, traffic share count is 1

Несмотря на то, что в таблице маршрутизации нет отдельной записи для подсети 172.16.17.0, маршрутизатор покажет вам, какой следующий хоп.

И ещё хотелось бы повторить самые важные вещи:
  • Когда блок данных попадает на маршрутизатор, заголовок Ethernet полностью отбрасывается и при отправке формируется совершенно новый кадр. Но IP-пакет остаётся неизменным
  • Каждый маршрутизатор в случае статической маршрутизации принимает решение о судьбе пакета исключительно самостоятельно и не знает ничего о чужих таблицах
  • Поиск в таблице идёт НЕ до первой попавшейся подходящей записи, а до тех пор, пока не будет найдено самое точное соответствие (самая узкая маска). Например, если у вас таблица маршрутизации выглядит так:

    172.16.0.0/16 is variably subnetted, 6 subnets, 3 masks
    S 172.16.0.0/16 [1/0] via 172.16.2.22
    C 172.16.2.20/30 is directly connected, FastEthernet0/0
    C 172.16.2.24/30 is directly connected, FastEthernet0/0.2
    C 172.16.2.28/30 is directly connected, FastEthernet0/0.3
    S 172.16.10.0/24 [1/0] via 172.16.2.26
    S 172.16.10.4/30 [1/0] via 172.16.2.30

    И вы передаёте данные на 172.16.10.5, то он не пойдёт ни по маршруту через 172.16.2.22 ни через 172.16.2.26, а выберет самую узкую маску (самую длинную) /30 через 172.16.2.30
  • Если IP-адресу получателя не будет соответствовать ни одна запись в таблице маршрутизации и не настроен маршрут по умолчанию (шлюз последней надежды), пакет будет просто отброшен
На этом первое знакомство с маршрутизацией можно закончить. Нам кажется, что читатель сам видит, сколько сложностей поджидает его здесь, может предположить, какой объём работы предстоит ему, если сеть разрастётся до нескольких десятков маршрутизаторов. Но надо сказать, что в современном мире статическая маршрутизация, не то чтобы не используется, конечно, ей есть место, но в подавляющем большинстве сетей, крупнее районного пионер-нета внедрены протоколы динамической маршрутизации. Среди них OSPF, EIGRP, IS-IS, RIP, которым мы посвятим отдельный выпуск и, скорее всего, не один. Но настройка статической маршрутизации в значительной степени поможет вашему общему пониманию маршрутизации. В качестве самостоятельного задания попробуйте настроить маршрутизацию между Москвой и Кемерово и ответить на вопрос, почему не пингуются устройства из сети управления.


Материалы выпуска


Новый IP-план, планы коммутации по каждой точке и регламент
Файл РТ с лабораторной
Конфигурация устройств

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

Авторы


Марат eucariot
Максим aka gluck.

160 комментариев

avatar
" В качестве самостоятельного задания попробуйте настроить маршрутизацию между Москвой и Кемерово и ответить на вопрос, почему не пингуются устройства из сети управления."

Можно узнать правильный ответ?

P.S. Огромное спасибо за ваш труд!
avatar
Как бы вам ответить в личку, чтобы не все сразу увидели ответ?
avatar
Может сразу в статье давать ответ под спойлер?

Спасибо за ответ, все понятно, просто я изучаю ваши статьи без Packet Tracer и, соответственно, настройки всех устройств держу в голове. Вопрос возник, потому что казалось, что изначально настроили все как надо.

P.S. Еще раз спасибо за ваш титанический труд. С нетерпением жду статьи об OSPF.
avatar
Статьи надо изучать с Packet Tracer, чтобы руку набивать, понимать, что к чему. Настоятельно рекомендую. А лучше сразу на тяжёлую артиллерию: GNS.
Кстати, возможно, это помогло бы вам ответить на вопрос.
OSPF кстати, уже опубликован: http://linkmeup.ru/blog/33.html. И именно в нём и реализовали такую схему с задачками: Задача и ссылка на ответ. Кстати, интересует как раз фидбэк по задачам, нужны они или нет. Пока его мало и мы думаем, стоит ли их добавлять дальше.

Спасибо на добром слове.
avatar
Спасибо большое за статью! Все очень доходчиво объяснено.
Можно тоже как-то получить ответ на вопрос «почему не пингуются устройства из сети управления»?
avatar
Ответ очень прост :)
Когда вы настраивает параметры IP на компьютере, вы указываете IP — адрес, маску и шлюз по умолчанию. Что мы не настроили на коммутаторах?
avatar
Спасибо, все прекрасно заработало! Наверно, нужно было отвлечься и подумать на свежую голову, действительно все оказалось очень просто:)
avatar
Попробуйте порешать наши <a href-«linkmeup.ru/challenges/»>задачки. Правда они пока про маршрутизацию.
avatar
Скажите пожалуйста как Вы настроили шлюзы по умолчанию для коммутаторов?
avatar
conf t
Switch(config)# ip default-gateway 172.16.1.1
avatar
Если не сложно, можете тоже ответ прислать.Как не старался, но не смог найти проблему.Хотя бы подсказку)
avatar
Ответил в личку.
avatar
Никак не могу понять действия на 31:46.
Больше всего вымораживает строчка int fa0/3.
Ведь на данном коммуникаторе мы этот шлюз вообще не используем(в Кемерово мы используем 24 шлюз).
Что я недоглядел?
avatar
На 31:25 я меняю номер порта со стороны Москвы на fa0/3. Сначала я выбрал ошибочно fa0/24.
avatar
Последний вопрос(На том-же коммуникаторе, в том же промежутке времени):
1.Мы создали Vlan 5
2.Switch(config-if)#switchport mode trunk — сделали порт транковым.
Но мы не должны били прописать на 0/3 порт 5 Vlan?
Вот что я хотел увидеть:3.Switch(config-if)#switchport trunk allowed vlan 5 на портах Fa0/1 и Fa0/3
P.S Огромное спасибо за проделанную работу.Вы мне очень помогаете разобраться в сетях.А то читаешь книги, знания получаешь, а в итоге каша в голове как была, так и осталась.
avatar
Такова специфика cisco. При включении 802.1q на порту в режиме транк, по умолчанию, пропускаются все кадры. А вот если вы явно зададите, например, vlan 5, то только кадры этого влана и будут пропускаться — остальные будут отброшены.
Правильно, разумеется, указывать конкретные вланы — секьюрнее это, но в нашем примере, чтобы не заморачиваться с лишней настройкой, я решил ограничиться просто включением 802.1q.
Кстати, не обольщайтесь — у других вендоров это может быть реализовано иначе. Например, в Хуавэй по умолчанию всё запрещено.
avatar
Господа,
пытаясь прописать дефолт, получаем:
msk-arbat-dsw1>ip route 0.0.0.0 0.0.0.0 172.16.1.1
^
% Invalid input detected at '^' marker.

Где грабли? :(
avatar
en
conf t

:)
avatar
Увы мне, я не верно поставил вопрос.
Да и не посмотрел, что скопипастил в листинг %)

При разборе домашнего задания, проблем с маршрутизацией в Москве и Кемерово не возникло,
но появилась проблема в части «почему не пингуются устройства из сети управления».
Анализ комментариев :), показал, что у коммутаторов не указан шлюз или маршрут по умолчанию,
тем самым они прекрасно пингуются из сети 172.16.1.0/24 но не пингуются из соседних сетей.
Т.к. на них нет правила куда отправлять пакеты из другой ip-подсети.

Для меня очевидно решение, прописать дефолт роут.
Но, видимо какой то момент я упустил или не понимаю, в следствии получаю вот такие грабли…

msk-arbat-asw3(config)#ip route 0.0.0.0 0.0.0.0 172.16.1.1
^
% Invalid input detected at '^' marker.
msk-arbat-asw3(config)#

Тем самым я пока в тупике.
Если не затруднит, укажите вектор движения.

Заранее благодарен.
avatar
Мысль понял. Решение ip default-gateway
avatar
Действительно, шлюз по умолчанию.
Сильно меня заморочило с маршрутом по умолчанию.

Спасибо! И с наступающими праздниками!)
avatar
И вас с наступающим! :)
avatar
Доброго время суток.
Хотелось сделать ремарку, на 25 минуте Вы создаете второй вилан, и говорите что первый не рекомендуеться цыско. Ето не рекомендуеться не только цыско, если у Вас не фирма «Лифт ми АП» а скажем домашняя сеть размеров города. Велан 1 ето дефолтный вилан, и он дает также право настраивать комутатор из сети. Вот Вам и ответ, если пойдут брут атаки от недоучки студента второкурсника ляжет вся сеть. И прийдеться конфиги ити заливать чуть ли не вручную на каждый комутатор отдельно.
avatar
Ну вообще, да, вы правы. Для управления устройствами вообще нужно выделять отдельный влан, непересекающийся с данными пользователей. Об этом я где-то на этих страницах уже говорил.
avatar
Здравствуйте
Спс за статьи — очень интересные. Подскажите на счет сети управления — в Кемерово и Спб создал сети для управления 172.16.17.0/29, 172.16.25.0/29, vlan 2. Маршруты прописаны на 172,16,0,0.24 и обратно. Как получить доступ по телнету на коммутаторы из Москвы в Спб и Кемерово? Они даже не пингуются — через tracert доходит только до их роутера.
avatar
Здравствуйте. Тут хочется начать с того, что 17.0 и 25.0 — это не сети управления, это LAN данных филиалов. Просто в этом же LAN находятся коммутаторы.

Не доступны они у вас, скорее всего, по той простой причине, что на них нет маршрута по умолчанию. Когда они получают ваши telnet-пакеты и должны на них ответить, они просто не знают, куда посылать этот самый ответ и отбрасывают его.
avatar
Приветствую!
Немного не понятно, почему же все таки я не могу пингануть сеть управления?
Я пигую с ПК (тег номер 2) в Кемерово 172.16.1.3, адрес не из этой сети, отправляю кадр шлюзу по-умолчанию (172.16.24.1). Маршрутизатор не находит записи в своиз таблицах маршрутизации и отправляет его на шлюз последней надежды в Москву, поменяв тег со 2 на 5-ый. Кадр приходит в Москву на маршрутизатор. Он видит, что адрес назначения находится на сабинтерфесе и отправляет туда. По идеи все должно пройти. Так в чем же дело?
avatar
Вам нужно смотреть не только на то, как пакет идёт к получателю, но и как он возвращается. Проследите его путь тщательно.
avatar
При настройке Кемерово, между коммутатором 2950-24 и маршрутизатором 2620XM нет линка если использовать перекрестный кабель. Глюк Packet Tracer?
Спасибо за ваши труды.
avatar
а зачем перекрестный? общее правило — перекрестным кабелем соединяются одинаковые виды оборудования: комп-комп или роутер-роутер. В остальных случаях прямой. К тому же, сейчас везде Auto-MDIX, так что прямой во всех случаях можно использовать.
avatar
Здравствуйте, сразу скажу не особо разбираюсь в теме, но очень хочу разобраться.
Вопросы следующие:
глобальный — зачем раскидывать группы на отдельные виланы, а потом настраивать маршрутизацию,
если можно их оставить в одной сети (без виланов, одна подсеть где всем все видно), (мои догадки это ограничение широковещательных пакетов),
правильно ли я понимаю принцип работы 2811 по маршрутизации виланов (что из одного вилана можно было зайти в другой) — по транковому порту маршрутизатор (2811) получает пакет с меткой вилана, отбрасывает ее, смотрим на какой ip надо отправить, добавляет соответсвующую метку вилана
(метку вилана в которой находится нужный нам ip адрес) и отправляет.
avatar
Зачем нужны вланы — не самый простой вопрос для объснения. Но я точно скажу, что это приходит со временем.
Это и ограничение широковещательных доменов и обеспечение безопасности и деление сети без необходимости выделять новые порты и «влан на абонента».
Ну вот простой пример — у вас один свободный порт на маршрутизаторе, нужно подключить 3 корпоративных клиента так, чтобы между ними не ходил широковещательный трафик. Что будете делать?

По второму вопросу, если не придираться к деталям, то да.
avatar
Видимо у меня одного траблы с маршрутизацией… Дело обстоит так:
С msk-arbat-gw1 до пк в Кемерово 24.26 пинг идет (через кемеровский роутер на палочке) Из сети ПТО тоже до сети 24.1 в Кемерово пинг идет.С пк в Кемерово — шлюз и интерфейс с ip 2.1 /30 в Москве тоже пинг идет, но вот в сеть 3.1 (уже через московский R) никак не хочет. При трассировке с 24.26 (пк в кемерово)ещё интересней:
Tracing route to 172.17.3.1 over a maximum of 30 hops:

1 14 ms 9 ms 8 ms 172.16.24.1
2 19 ms 13 ms 21 ms 172.16.2.17
3 14 ms * 20 ms 172.16.2.17
4 * 21 ms * Request timed out.
5 20 ms * 20 ms 172.16.2.17
и т.д. То есть дальше 2.17 на интерфейс москвы 2.1 /30 уже не проходит. Где искать?
ВОПРОС 2. Есть ли возможность посмотреть на свиче какие порты настроенны транком (и какие вланы там разрешены) а какие аксессом?
ВОПРОС 3 Зачем нужны default-gateway на свичах я понял, но на какой из интерфейсов ( или подинтерфейсов ) заворачивать например msk-arbat-asw3 на роутере выше (msk-arbat-gw1)
avatar
1) Выложите файл PT и конфиги устройств куда-нибудь или вышлите их на info@linkmeup.ru. Странная ситуация, на самом деле.
2) На вскидку не помню, посмотрю вечером.
3) Не понял вопрос. Что значит «на какой из интерфейсов ( или подинтерфейсов ) заворачивать например msk-arbat-asw3 на роутере выше (msk-arbat-gw1)»?
avatar
ответил на почту
avatar
Оказалось в PT интерфейс не доступен, пока на нем физически нет линка. Безрезультатно пытался пропинговать 172.16.17.1 (spb-ozerki-gw1), причем интерфейс был недоступен даже с самого свича (хотя он настроен и я сказал no shutdown). Убил минут 10, пока не догадался преципить ПК на порт=). Интересно это фишка PT или для «живых» цисок характерно такое же поведение?
Скажите, пожалуйста, по мультикасту статью не планируете? Я успешно настраивал IPTV на д-линках (IGMP-snopping, RP и прочее), все работает, но не скажу, что хорошо понял эту тему=) Спасибо!
avatar
Да, это стандартная ситуация. У вас ведь интерфейс находится в состоянии Down. Соответственно и его IP-адрес будет не доступен. В это и отличие, например, от Loopback-интерфейсов.

Статья по мультикасту будет, но нескоро — не раньше конца 2013 года. Будет и IGMP и PIM-SM/PIM-DM, и практика с показом видео :)
avatar
Спасибо, буду ждать! Не так уж и долго ждать осталось.
По поводу интерфейсов, настраивал маршрутизаторы Микротик, там ситуация другая: если интерфейс административно поднят и на нем висит ip, то он доступен с самого рутера, не зависимо от наличия физического сигнала на интерфейсе. Видимо от вендора зависит. Ну и опять же на обычном ПК, если сетевая рабочая и адрес есть, то пинговать можно. Надо будет запомнить эту особенность цисок, дабы не попасть в просак.
avatar
Напиши, пожалуйста, об этом в статье, потому что тоже убил минут 10 пока не догадался подцепить на порт ком.
Спасибо за труды )
avatar
Вы пишите:
Все эти адреса: 172.16.0.0-172.16.15.255 — можно описать так: 172.16.0.0/20. Эта сеть (с префиксом /20) будет так называемой суперсетью, а операция объединения подсетей в суперсети называется суммированием подсетей (суммированием маршрутов, если быть точным, route summarization)
но перед этими строками даете ссылку, где читаю:
Процесс объединения мелких префиксов (с длинной маской, в которых мало хостов) в крупные (с короткой маской, в которых много хостов) называется агрегацией или суммаризацией (вот не суммированием!).
Это о разном пишется?
Спасибо.
avatar
Добрый вечер

Совсем запутало последнее задание, не могли бы вы по подробнее объяснить как настроить доступ?
avatar
О каком задании идёт речь и что именно непонятно?
avatar
Пинг из сети ПТО в 172.16.1.x видел что нужно прописать дефолтный маршрут, но не понял почему
avatar
Если смотреть как ходят пакеты то пакет доходит до msk-arbat-gw1 от туда уже с адресом назначения нужного устройства допустим 172.16.1.2 он идет на эту железку и уже там отбрасывается. На всякий случай вот файл
avatar
Я настроил транки между msk-arbat-dsw1 и msk-arbat-asw1 так, что через них могут ходить тегированные кадры с метками 2 и 3, сеть PTO имеет метку 101, и почему-то у меня получается пропинговать, допустим, с ПК 172.16.3.2 (VLAN 101) сервер 172.16.0.2 (VLAN 3). Поясните?
avatar
Вы настроили сабинтерфейсы на маршрутизаторе? влан 101 прокинули между asw1 и dsw1?
avatar
Добрый день коллеги, настроил связь между провайдером и kmr-gorka-sw1, но линк ни в какую не хочет подниматся, уже все проверил хоть убей, что может быть?
avatar
Не поднимается линк — прям интерфейсы в состоянии Down? no shut сделали? Тип кабеля использовали правильный?
avatar
Разобрался в проблеме, причиной была коммутатор, изначально коммутатор провайдера установил 2950T-24, после чего поставил 2960-24TT и сразу линк поднялся в сторону кемерово, так можете объяснить в чем именно подвох?
avatar
Думаю, скорее всего, проблема с РТ.
avatar
Привет!
у меня проблемка с настройкой маршрутизации между Москвой и Кемерово… вот я пробую настроить следующие маршрут: На маршрутизаторе в Кемерово Шлюз по умолчанию 172.16.2.1; В москве 172.16.24.0 255.255.255.0 172.16.2.16, вот хотел спросить правильно я делаю или если есть ошибка? спасибо буду ждать ответа
avatar
Здравствуйте.

Попытаюсь дать подсказку.
1) Во-первых, 172.16.2.16/30 — это адрес сети. Адреса хостов здесь будут 172.16.2.17 и 172.16.2.18, что, собственно, и указано в IP-плане.
То есть я веду к тому, что 172.16.2.16 вы не можете указывать в качестве адреса шлюза при создании маршрута.
2) Во-вторых, в качестве шлюза вы должны указывать адрес, через который у вас организован линк между данными устройствами. Адрес 172.16.2.1 — это линковый адрес в сторону Петербурга, но никак не Кемерово.

Можно и по-другому сказать — маршрутизатор в Кемерово должен знать, как добраться до шлюза. Так вот, если вы выполните sh ip route в Кемерово, то вы не увидите там сеть 172.16.2.0/30, в которую и входит 172.16.2.1. Зато, вы увидите 172.16.2.16/0
Попробуйте настроить теперь)
avatar
Здравствуйте. Я начинающий сетевик и у меня вопрос возник по ходу выполнения лабы «Лифт ми ап». Часть 3.
Дело обстоит собственно в том, что комп группы ФЭО имеет IP 172.16.3.4/24 и заведен в VLAN 102, когда по плану адресации у группы ФЭО д.б. IP 172.16.4.x/24. Прошу дать немножко разъяснений, поскольку образовались два одинаковых ip адреса 172.16.3.4 в разных подсетях vlan101 и vlan102, но при этом на роутере msk-arbat-gw1 задана маршрутизация для vlan102 как 172.16.4.x.
avatar
Здравствуйте.
Если у вас есть одинаковые адреса в разных VLAN'ах, то они не будут конфликтовать, потому что находятся в разных широковещательных доменах. Другой вопрос в том, что шлюз у вас всё равно из другой подсети и маршрутизация работать не будет.
avatar
На данный момент я вижу одно решение в том, чтобы изменить ip адрес 172.16.3.4 на 172.16.4.5 и все на свои места встанет. Замечу, что в плане адресов для ФЭО определены адреса 172.16.4.x. А х.х.4.5 потому, что далее приведен пример по ping'у этого адреса, которого в сети нет.
avatar
Хочу выразить огромную благодарность за Ваш труд!
Это великолепный материал и очень полезный. Постепенное усложнение решаемых задач вместе с доступностью изложения материала и наличием гиперссылок на связанные материалы влечет неизбежный прогресс в понимании принципов построения сети, а практические задачи дают опыт применения знаний.
avatar
В комментарии выше всё верно. Желаю успеха.

Спасибо за тёплые слова. Мне очень приятно осознавать, что наш труд полезен. 15-го октября будет выпуск по IBGP. Приглашаю)
avatar
Здравствуйте, коллеги.
У меня случился затык с ARP. Я не понял можно ли этот протокол отнести однозначно к какому-то конкретному уровню (сетевому, канальному)?
Мне казалось что arp передает информацию с третьего уровня на второй. Но с другой стороны становится непонятно как он подставляет в эзернет кадр — широковещательный destination.
Или я просто запутался и arp работает на обоих уровнях и представляет собой отдельный, независящий от второго уровня, протокол?
avatar
ARP — это протокол сетевого уровня, по меньшей мере уже потому, что он использует IP.

как он подставляет в эзернет кадр — широковещательный destination.

Не вижу в этом проблемы. При ARP-запросе он ставит широковещательный IP и широковещательный MAC в destination. При ARP ответе MAC уже ставится получателя.

Говорить про него можно только в рамках Ethernet.
avatar
Ох, спасибо.
Т.е. получается что arp внутрь себя засовывает IP-адрес получателя, как информацию. Потом ставит в заголовок широковещательный ip, далее все это инкапсулируется во фрейм с широковещательным mac в заголовке. И доходя до каждого хоста декапсулируется до сетевого. Потом передает, грубо говоря, управление протоколу arp и уже сам arp проверяет совпадение ip-адреса получателя. Если совпадает, то таким же способом формирует arp-ответ? С тем отличием что ip и mac в заголовки ставит уже не широковещательные, а unicast.

Есть ли аналог arp в не-Ethernet сетях?
avatar
Вы всё верно поняли. Почти всё — в ответном ARP он не может поставить юникастовый IP — его ещё нет на хосте.

Необходимость в протоколе вроде ARP есть только в Broadcast или MultiAccess — сетях. В P2P в них нет необходимости — точно знаем, куда слать трафик.

Аналогом можно, например назвать NHRP, хотя он только отдалённо похож.
avatar
Хм, получается что в arp-ответ ставится широковещательный IP, но юникастовый mac? Если так, то я понял.
Спасибо что помогли разобраться. Ресурсы все по этому вопросу пишут разные вещи, вплоть до того что arp протокол канального уровня.
avatar
Ну принадлежность разных протоколов действительно спорна. Ответ зависит от того, кому вы задаёте вопрос)

То, что я сказал, это общая практика, но встречается и такая ситуация, что ответ некоторые тоже шлют широковещательный.
А есть также Gratious ARP, который вынуждает в сети все устройства обновить свои записи. Он тоже широковещательный.

Самый верный способ, Дункан — это RFC и дампы. Только там вы найдёте как реально должно быть и как реально есть (что тоже не всегда одно и то же.)
avatar
Спасибо за помощь =)
avatar
Здравствуйте! Во первых огромное спасибо за курс, прекрасно все повествуете. У меня вопрос. Маршрутизацию как понял настроил все пингуется. Но проблема с сетью управления. С kmr-gorka-gw1 пинг до 172.16.1.1 идет, а вот допустим до 172.16.1.2 и прочих нет. Маршруты:

kmr-gorka-gw1

172.16.0.0/16 is variably subnetted, 3 subnets, 2 masks
S 172.16.2.0/24 [1/0] via 172.16.2.17
C 172.16.2.16/30 is directly connected, FastEthernet0/0.5
C 172.16.24.0/24 is directly connected, FastEthernet0/0.2
S* 0.0.0.0/0 [1/0] via 172.16.2.1

msk-arbat-gw1

172.16.0.0/16 is variably subnetted, 11 subnets, 3 masks
C 172.16.0.0/24 is directly connected, FastEthernet0/0.3
C 172.16.1.0/24 is directly connected, FastEthernet0/0.2
C 172.16.2.0/30 is directly connected, FastEthernet0/1.4
S 172.16.2.4/30 [1/0] via 172.16.2.2
C 172.16.2.16/30 is directly connected, FastEthernet0/1.5
C 172.16.3.0/24 is directly connected, FastEthernet0/0.101
C 172.16.4.0/24 is directly connected, FastEthernet0/0.102
C 172.16.5.0/24 is directly connected, FastEthernet0/0.103
C 172.16.6.0/24 is directly connected, FastEthernet0/0.104
S 172.16.16.0/21 [1/0] via 172.16.2.2
S 172.16.24.0/24 [1/0] via 172.16.2.18
avatar
Это было одним из домашних заданий и даже обсуждалось где-то в комментариях.
Не хватает одной команды на коммутаторах.
avatar
написал ip def-get на всех коммутаторах, заработало. Думаю верно.
avatar
Если по def-gev вы подразумеваете default-gateway, то да :)
avatar
Добрый день!

У меня такой вопрос на видео, 29:58 вы пишите адрес 172.16.2.4 хотя вы его нигде не прописывали. Объясните пожалуйста для чего это делается если вы его нигде не указывали.
avatar
172.16.2.4 — это адрес сети. Полная запись в нотации CIDR: 172.16.2.4/30. В неё входят адреса 172.16.2.5 и 172.16.2.6, которые мы как раз-таки настраивали)
avatar
спасибо
avatar
Доброго времени суток!
Хотел выразить Вам благодарность за колоссальный труд и спросить.
Мне все равно не ясно.
С данной маской у нас получается четыре адреса
172.16.2.0 адрес сети
172.16.2.1 первый адрес

аааа
блин понял.
172.16.2.4 адрес сети (второй)

Спасибо!!!
avatar
Здравствуйте! Вопрос такой…
Если сделать
switchport trunk allowed vlan add X

Он не появляется в
Vlans in spanning tree forwarding state and not pruned

Иными словами если я сразу не добавил то мне приходится делать no, а затем добавлять по новой и тогда все ок.
Как правильно добавить Vlan?
avatar
Делалось все в Cisco Packet Tracer, попробовал еще раз на этот раз vlan добавился во все таблицы
avatar
Здравствуйте!
Серия статей супер! Большое спасибо за труд!
Такой вопрос…
В Кемерово и Питере мы настроили влан 2 как локальный, а разве мы не хотим иметь доступ к роутерам и свитчам для настройки из Москвы по 2 влану, тот который «Management»? Почему мы именно так настраиваем? Как я понимаю, влан 2 «Management» нужен только админу для настройки и чтобы все остальные не имели доступа к свитчам и роутерам. Если это так, то получается, что в Кемерово и Питере доступ к свитчам и роутерам имеют обычные пользователи, или я не правильно понимаю. Спасибо!
avatar
Здравствуйте.

Понимаете ли, VLAN — вещь сугубо локальная. Мы определили VLAN 2 в Москве для управления, но это не значит, что в Кемерово мы не можем использовать его для других целей. Они никак не пересекаются. Грубо говоря, VLAN'ы не проходят через маршрутизаторы и VLAN 2 в Кемерово совсем не тот же самый, что VLAN2 в Москве. Именно это я и хотел показать создав и там и там его.

А для управления маршрутизатор в Кемерово доступен по его IP-адресу.
Собственно по IP-адресу они будут доступны все для обычных пользователей, даже Москва, но плюс в том, что с помощью ACL в дальнейшем можно ограничить круг привилегированных лиц.
avatar
Спасибо! Теперь более менее понятно.
avatar
Здравствуйте. Огромное спасибо за такие шикарные статьи.! Спокойной можно перечитывать и пересматривать через время и находить в них то, что не знал!
Плюс очень понятно и доступно подаете непростой материал! Именно Ваши статьи подтолкнули уйти в изучение сетей.
Вопрос в продолжение вопроса об управлении…
А как мы будем управлять коммутаторами в Питере и Кемерово?
avatar
Здравствуйте. Очень рад, что статьи помогают. Уже 31-го марта, кстати, новый выпуск СДСМ, посвящённый мультикасту.

На коммутаторах вы настраиваете IP-адрес и будете иметь к нему доступ по telnet/ssh к этому IP-адресу. Для этого вы можете выделить специальный VLAN, как мы это сделали в Москве, а можете назначить свободный адрес из клиентского диапазона.
avatar
Доброго времени суток!
спасибо Вам, за статьи! Мне страшно представить, сколько Вы времени потратили времени на подготовки и подачу материала.
avatar
От месяца до четырёх. Разумеется, не с утра до ночи.
avatar
Здравствуйте! В обсуждениях выше не совсем понял насчет широковещательного IP при ARP-запросе.В нем, насколько я знаю, указываются конктретные IP-адреса отправителя и получателя(MAC адрес, которого мы хотим узнать).Разъясните пожалуйста этот момент.
avatar
Здравствуйте!
Столкнулся с одно странной и не понятной для меня ситуацией. Может вы объясните как такое может происходить.
Есть шлюз Kerio Contorl (следит за выходом пользователей в интернет, разрешает, запрещает). У него есть 2 сетевых интерфейса с адресами, скажем, XXX.XXX.XXX.XXX и YYY.YYY.YYY.YYY. При отправке arp запроса к ip XXX.XXX.XXX.XXX ответ получается от обоих интерфейсов:
:~$ sudo arping XXX.XXX.XXX.XXX
ARPING XXX.XXX.XXX.XXX
60 bytes from 00:30:05:a5:06:83 (XXX.XXX.XXX.XXX): index=0 time=365.862 usec
60 bytes from c8:be:19:d3:90:9e (XXX.XXX.XXX.XXX): index=1 time=655.669 usec
60 bytes from c8:be:19:d3:90:9e (XXX.XXX.XXX.XXX): index=2 time=447.974 usec
60 bytes from 00:30:05:a5:06:83 (XXX.XXX.XXX.XXX): index=3 time=494.706 usec
60 bytes from 00:30:05:a5:06:83 (XXX.XXX.XXX.XXX): index=4 time=357.011 usec
60 bytes from c8:be:19:d3:90:9e (XXX.XXX.XXX.XXX): index=5 time=399.088 usec

Это MAC адреса обоих интерфейсов.
При этом шлюз исправно выполняет свою работу.

В WireShark'е наблюдаю такую же картину ответов, как и выше.

У меня два вопроса: какого… и почему оно работает.
avatar
Здравствуйте. А это два физически разных интерфейса, на которых руками прописаны IP на каждом?
И что, кстати, в итоге попадает в ARP-таблицу?
avatar
Да, это физически два разных интерфейса. А что записывается в таблицу надо проверить. Несколько дней назад попадало то одно, то другое.
avatar
Из около 200 компьютеров в сети на одном проявилась проблема отсутствия интернета. На нем выл мак неверного интерфейса. Почему все остальные работают для меня до сих пор загадка.
avatar
Нет идей?)
avatar
Выглядит, как проблема этого самого Kerio.
Почему это работает? Возможно, потому, что MAC-то всё равно этого же самого устройства и в любом случае пакеты с коммутатора попадают на этот Kerio. А он волен поступать с ними как хочет.
avatar
К примеру, даже если пакет прилетел на интерфейс с другим ip (из другой подсети), он все-равно обрабатывает его как если бы пакет пришел на нужный интерфейс?
avatar
У меня тоже было только это предположение. Тогда он хитёр.
Кстати с этой же проблемой есть ветка на форуме Kerio. Правда разработчики ничего не комментируют, т. к. тех поддержка платная.
avatar
Собственно, вот и ответ) иногда всё работает не благодаря, а вопреки.
avatar
Демонстрация происходящего (для наглядности):
avatar
Боюсь, что я тут уже бессилен. Вопросы к Керию)
avatar
Заранее прошу прощение за, возможно, глупые вопросы.

Скажите, есть ли у управляемого коммутатора MAC-адрес? Если есть, то для чего используется? Для подключения по telnet и ssh? Также не понимаю для чего каждому порту коммутатора отдельный MAC-адрес?

И еще одно, у виртуальных интерфейсов маршрутизатора будут разные MAC-адреса или они будут наследовать MAC-адрес физического интерфейса?
avatar
У любого устройства, которое может получать и передавать пакеты, должен быть MAC-адрес. Ведь что-то должно записываться в MAC-адрес получателя и отправителя? Как без MAC'а найти получателя?
У коммутатора один системный MAC-адрес на все физические интерфейсы. То есть если он с любого порта отправит STP BPDU, то он поставит MAC-адрес, и он для всех портов будет одинаковый.
Для виртуальных интерфейсов обычно используется тот же системный MAC-адрес. Но могут быть и особенности.
avatar
Ну вот в том же Packet Tracer для Catalyst 60 команда show interfaces показывает разные MAC-адреса — для каждого интерфейса свой. Вот это не совсем ясно. То, что для передачи данных управляемому коммутатору необходим какой-то MAC, это понятно, иначе он не сможет инкапсулировать IP-пакет в Ethernet-фрейм. Но зачем для каждого интерфейса у switch свой MAC? Разве одного не достаточно?
avatar
Либо ответ на мой вопрос никто не знает, либо игнорят все( Печально, в любом случае(
avatar
Странно как-то.
У меня не получается настроить межвланный роутинг.

Вот, собсна, проектик.На gw настроены сабинтерфейсы под соответствующие вланы: 101(влан юзеров) и 401(влан управления)
101 интерфейс имеет ip 10.1.1.1 401 интерфейс имеет ip 10.200.1.1. Т.е. по сути все правильно:
10.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
C 10.1.0.0/22 is directly connected, GigabitEthernet2/0.101
C 10.200.1.0/24 is directly connected, GigabitEthernet2/0.401
Не проходят пинги до свичей с компа юзера.
При этом пинги до 10.200.1.1 проходят.
Не подскажете, в чем косяк?
avatar
Маршрутизация между VLAN'ами у вас работает. А вот на коммутаторах кое-чего, скорее всего, не хватает. Сравните конфигурацию коммутатора с тем, как вы настраиваете ПК.

P.S. Какая знакомая аватарка)
avatar
Да уже разобрался, в чем проблема. В шлюзе по умолчанию.Настроил-все ок. Появился еще вопрос: к dsw1 хочу добавить еще одно кольцо свичей из подсети 10.200.2.0/24 не нем, соответственно, появится интерфейс влана 402 с IP 10.200.2.2 а шлюз на нем уже настроен: 10.200.1.1. Не станет ли это проблемой?
avatar
Не понял вопрос.
Появится новый интерфейс с новым IP. А на чём шлюз настроен?
avatar
Ну, шлюз то не настраивается из конфигурации интерфейса, шлюз настраивается просто из режима конфигурации. А в интерфейсе влана можно настроить только айпишник и маску. Т.е. я на dsw1 добавлю интерфейс влан402 на нем настрою айпи и маску. При этом на этом же dsw1 я уже прописал комаду ip default-gateway 10.200.1.1 а он не из подсети 10.200.2.0/24
avatar
Если dsw1 не выступает в роли L3-коммутатор, то на нём достаточного одного L3-интерфейса для управления. В остальных VLAN'ах поднимать IP не имеет смысла.
avatar
Просто дело в том что dsw1 по замыслу у меня объединяет 3 свитчевых кольца 10.200.1.0/24 10.200.2.0/24 и 10.200.3.0/24.Вланы управления на них я хочу сделать разные(401,402,403). И с dsw1 хочу(как видно из картинки) пустить 3 линка до gw1 по каждому на кольцо. Т.е. чтобы пакеты из разных колец по разным линкам доходили до gw1.(Надеюсь не очень мудрено)
Ну и в каждом ринге получается свича агрегации я отвел айпи x.2 где x номер ринга.Просто для соблюдения логики.
Я так понял в этом нет смысла?
avatar
А чего ради такая избыточность? Для управления dsw1 вам достаточно одного IP.
avatar
Ну, опять же, просто для того чтобы все было логично.
avatar
Это будет таки противоречить логике)
avatar
А аватарку у вас подцепил. Стала моим рабочим девизом :)
avatar
:) Здорово.
avatar
Здравствуйте. Не могу выполнить пинг локальной сети в Питере из Москвы:
msk-arbat-gw1>ping 172.16.16.1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.16.16.1, timeout is 2 seconds:
.U.U.
Success rate is 0 percent (0/5)

При этом пингуется адрес 172.16.2.2:
msk-arbat-gw1>ping 172.16.2.2

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.16.2.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 22/33/40 ms

Вот конфиг московского маршрутизатора (часть, относящаяся к Питеру):
interface FastEthernet0/1.4
description Saint-Petersburg
encapsulation dot1Q 4
ip address 172.16.2.1 255.255.255.252

ip classless
ip route 172.16.16.0 255.255.255.0 172.16.2.2

Вот конфиг питерского маршрутизатора:
spb-vsl-gw1#sh running-config 
Building configuration...

Current configuration : 746 bytes
!
version 12.4
no service timestamps log datetime msec
no service timestamps debug datetime msec
no service password-encryption
!
hostname spb-vsl-gw1
!
interface FastEthernet0/0
description LAN
ip address 172.16.16.1 255.255.255.0
duplex auto
speed auto
!
interface FastEthernet0/1
no ip address
duplex auto
speed auto
!
interface FastEthernet1/0
no ip address
duplex auto
speed auto
!
interface FastEthernet1/0.4
description Moscow
encapsulation dot1Q 4
ip address 172.16.2.2 255.255.255.252
!
interface FastEthernet1/1
no ip address
duplex auto
speed auto
shutdown
!
interface Vlan1
no ip address
shutdown
!
router rip
!
ip classless
!
line con 0
line vty 0 4
login
!
end

Где я ошибся?
avatar
*Пинг 172.16.16.1 не идет даже с самого питерского маршрутизатора, порт fa 0/0 включен.
avatar
Нашел: в конфиге моего spb-vsl-gw1 нет строки
C 172.16.16.0/24 is directly connected, FastEthernet0/0

У него вообще работает только добавленная плата, на «родной» при включенных портах все лежит. Наверно глюк PT.
avatar
Рад, что вы нашли ответ на свой вопрос. Извините, не мог ответить раньше.
avatar
Огромное спасибо за титанический труд. С маршрутизацией разобрался. Но возник вопрос с командой, позволяющей свести настройки интерфейса к дефолтным. Есть команда — к примеру, — cisco(config)#default interface gigabitEthernet 0/44. На рнальном железе не пробовал, а в PT не работает. Либо я что-то делаю неправильно. Как решить эту проблему? Ведь бывает необходимость сделать откат настроек.
Спасибо.
avatar
Видимо, глюк РТ. На реальном я использовал эту команду. Правда только на некоторых железках.
У циски хорошо ещё есть такая команда, а вот на Хуавэе к примеру каждую команду нужно удалять вручную. Это, конечно, сделано в целях защиты от ошибки, но дюже неудобно.
avatar
Добрый день помогите пожалуйста разобраться, заранее благодарен

1 вопрос) никак не могу понять как определить на какой интерфейс надо прописывать маршрут по умолчанию, например есть R1 c интерфейсом s0/0/1 с ip-address 209.154.10.1 /30 этот интерфейс подключен напрямую к роутеру ISP с интерфесом S0/2/0 209.154.10.2, тогда маршрут по умолчанию будет выглядеть таким образом: ip route 0.0.0.0 0.0.0.0 209.154.10.2, правильно ли эта запись?
2 вопрос) и например тот же роутер R1 также ему надо по дефолту отправлять сети к ISP но при этом не будем знать какой ip адрес на s0/2/0, тогда как будет правильно выглядеть такая запись ip route 0.0.0.0 0.0.0.0 s0/2/0?
avatar
Подскажите, правильный ответ, я так и не понял. У меня получилось только если я убрал 30 маску на kmr-gorka-gw1 на 24 тогда стало все доступно. Но как я не пытался ни чего получалось с 30 маской. Может я что то делаю не там.
avatar
вроде получилось, заработался и совсем забыл что нужно прописать маршрут на 2 маршрутизаторах. Большое спасибо Вам пойду в следующий урок
avatar
Рад, что получилось.
Извините, что не ответил раньше — активная подготовка к отдыху. :)
avatar
Вставлю свои 5 копеек на счет «глючности » PT.
По домашнему заданию необходимо настроить Кемерово. Настроил и не работает. Думал, что ошибся. Скачал конфиги со следующей серии. Глянул, а конфиги сходятся, но у меня не работает. Скачиваю весь проект, запускаю, проект автора работает. Тут я тем более не понимаю, почему так?.. Игрался всяко разно, не работало.
Решение было достаточно простое, привязать к порту кемеровского свитча 5й Vlan access'ом (Kmr-gorka-dsw1) и воткнуть комп в порт, прописать ему IP 172.16.2.18/30 (kmr-gorka-gw1), пропинговать московский msk-arbat-gw1 и вуаля, пинг есть. Хотя ранее, если kmr-gorka-gw1 имел свой Ip IP 172.16.2.18, то не пинговал msk-arbat-gw1 172.16.2.17. Далее убирал комп из сети и подключал kmr-gorka-gw1.

Вот такие ситуации приходится решать и понимать настройки более лучше, а проблема всего лишь в PT.
P.S. PT version: 6.1.1.0001

Автору выражаю большую признательность за изложенный материал. Всё доступно и понятно! Учусь.
avatar
Спасибо большое. Очень хороший курс.
Хотелось бы узнать как можно сделать так, чтобы, допустим, сеть на Озерках в Санкт-Петербурге была бы в одном и том же влане «PTO» что и в Москве. То есть чтобы офисы в Питере и Москве находились в одном Влане хоть они и разделены маршрутизаторами.

Не уверен что целесообразно это делать, просто интересно))
Спасибо.
avatar
вы можете так сделать, безусловно. просто нужно разрешить транкам пересылать нужные вланы. Теперь по поводу целесообразности: вы действительно хотите пересылать весь бродкаст, которой будет внутри этого влана через wan? если да, то тогда целесообразно (ну просто мало ли, бывают таки ситуации). Но общая рекомендация: «держать вланы внутри сайта». Это означает в общем смысле, что лучше доверить это протоколу третьего уровня, чем второго. Проще: «Чем больше подсетей, тем лучше». Ну я так, совсем уж упростил, всегда есть варианты.
avatar
Ах, да. Точно. Спасибо большое за ответ.
avatar
Просто я думал что если используем VPNL2 провайдера, то достаточно сложно наверное будет выпросить у него транк большого числа вланов…
avatar
я тут немножко не понял. У вас с провайдером договоренность «l2vpn» или просто «интернет»? Если первое, то тогда вы (ну, теоретически при нормальном провайдере) можете пускать вланы через этот «wan» как вам хочется. если «интернет», то тогда вы, получается, сами организовываете канал между вашими офисами (по gre или по любому другому, на ваш выбор, протоколу)
avatar
Понято. Я начинающий) Из статьи понял что с провайдером нужно согласовывать номера вланов которые будут пропущены через l2vpn.
Вообще говоря, номера вланов вам придётся согласовывать с вашим провайдером по той простой причине, что у него они могут быть просто заняты. Поэтому вполне возможно, что у вас будет влан, например, 2912 или 754. Но предположим, что нам повезло, и мы вольны сами выбирать номер.

То есть я могу создать неограниченноеочень большое число вланов и пропустить через l2vpn провайдера согласовав с ним номера этиих вланов или же я могу пропустить только ограниченное число вланов которые опять же согласованы с провайдером?
Хотя эти тонкости зависят, скорее всего, от конкретного провайдера…
avatar
при l2vpn вы ничего не согласовываете с провайдером. l2vpn между вашими двумя (тремя- десятью) офисами это все равно что вы воткнули эти два (три-десять) офисов в некий свич (l2 свич).
avatar
Спасибо большое. Все прояснилось)
avatar
L2VPN может быть предоставлен разными способами и конечная реализация действительно зависит от вашей договорённости с провайдером.
Он может предоставить вам один единственный VLAN (услуга VPLS — Virtual Private LAN Servise), а может эмуляцию кабеля (VLL — Virtual Leased Line) — тогда уже через него вы что угодно можете пускать.
avatar
Добрый день, на дворе ноябрь 2014 года и космический зонд Филы, отправил уже много душераздирающих фоток!!! Авторам статьи большой респект, за проявленный умственный и физический труд.Материал очень доходчиво разъяснен!!! Ждем-с новых статей…
avatar
Николай, в декабре выпуск про MPLS. Приглашаю к чтению.
avatar
Добрый день. Стало интересно можно ли осуществить маршрутизацию между подсетями в данном случае не используя вланы?
avatar
Здравствуйте.

Поскольку обе сети у вас подключены в один интерфейс маршрутизатора и идут через один коммутатор, без VLAN'ов никак.
avatar
Спасибо
avatar
Доброго времени суток, спасибо большое за материал, всё очень понравилось, маршрутизацию между Кемерово настроил, не могу пингануть asw 3, задал ему default — gateway 172.16.1.5, нужно прописать статическую маршрутизацию на роутере?
avatar
Здравствуйте. А почему 172.16.1.5?
avatar
172.16.1.1 =) что то я туго соображаю ))))
avatar
Тогда всё должно работать. :) Проверяйте трассировкой в обе стороны.
avatar
класс всё заработало спасибо, и трассировка в обе стороны всё показывает ))))
avatar
Ну здорово же! Продолжайте :)
avatar
Доброго времени суток!
Огромное спасибо за ваш труд, все очень здорово и понятно написано.
Я решил перечитать все статьи с нулевой и тут на этой запнулся на протоколе ARP.
Т.е. ситуация такая:
Предположим, есть подсеть 172.16.1.0 255.255.255.0. В ней хост 172.16.1.2 отправляет icmp-запрос на 172.16.1.3. Также в сети есть маршрутизатор с ip-адресом 172.16.1.1, который прописан как шлюз по умолчанию для всех хостов сети. Сначала 172.16.1.2 отправляет arp-запрос.
Хост отправляет широковещательный arp-запрос и вместо mac адреса получателя ставит mac адрес FF:FF:FF:FF:FF:FF.
Далее коммутатор рассылает этот запрос по всем портам, кроме порта отправителя (flooding).
После этого запрос отбрасывается всеми хостами, кроме 172.16.1.3 и маршрутизатора. Что делает с пакетом маршрутизатор?
avatar
Здравствуйте.
Похвальное начинание.

После этого запрос отбрасывается всеми хостами, кроме 172.16.1.3 и маршрутизатора. Что делает с пакетом маршрутизатор?

А почему бы и маршрутизатору не отбросить этот запрос?
комментарий был удален
комментарий был удален
avatar
В Кемерово нам нет смысла оставлять такие огромные запасы /21, как в Питере (2048 адресов или 8 подсетей /24), или тем более /20, как в Москве (4096 или 16 подсетей /24). А вот 1024 адреса и 4 подсети /24, которым соответствует маска /22 вполне рационально.

Таким образом сеть 172.16.24.0/22 (адреса 172.16.24.0-172.16.27.255) будет у нас для Кемерово.

и ниже тут же в табличке для Кемерова пишите маску /21
avatar
Спасибо за замечание.
Когда буду заниматься правкой статей, обязательно учту.
avatar
Добрый вечер!
Не знаю отвечаете ли вы еще здесь на вопросы, но есть вопрос по настройке default-gatwey на коммутаторах.
Работаю в GNS3. На коммутаторе msk-arbat-dsw1 прописываю default-gatwey командой: #ip default-gaetwey 172.16.1.1. Но пинг с машины сети ПТО так и не появляется. Пинг проходит от msk-arbat-dsw1 до 172.16.1.1, но не до 172.16.3.1. Конечные устройства из разных сетей (ПТО и управления) пингуют друг друга, т.е. на маршрутизаторе все настроено. Где же может скрываться проблема?
avatar
Ан нет) Прошу прощения все работает) Но почемуто не сразу.
avatar
Разобрался) Почемуто приходится прописывать на коммутаторах «no ip routing» и тогда все начинает работать. Может подскажете почему у меня не так как у всех)
avatar
Привет. Кирилл.
Стараюсь отвечать. Но сейчас я в Китае и с этим проблемы.

Думаю, это связано с тем, что вы используете маршрутизаторы в качестве коммутаторов, а на них по умолчанию включена маршрутизация, соответственно команда «ip default gatewa» работать не будет. Исопльзуйте ip route 0.0.0.0 0.0.0.0
avatar
Никак не получается настроить маршрутизацию между Кемерово и Москвой. Из сети LAN (Кемерово) не получается пропинговать хост сети ПТО.
Причем из Москвы с msk-arbat-gw1 пингуется адрес, присвоенный интерфейсу в Кемерово (внутренний) 172.16.24.1

вот конфиги роутеров:
hostname kmr-gorka-gw1
!
interface FastEthernet0/0
no ip address
duplex auto
speed auto
!
interface FastEthernet0/0.2
description LAN
encapsulation dot1Q 2
ip address 172.16.24.1 255.255.255.0
!
interface FastEthernet0/0.5
description MSK
encapsulation dot1Q 5
ip address 172.16.2.18 255.255.255.252
!
ip classless
ip route 0.0.0.0 0.0.0.0 172.16.2.17

вот таблица маршрутизации:
172.16.0.0/16 is variably subnetted, 2 subnets, 2 masks
C 172.16.2.16/30 is directly connected, FastEthernet0/0.5
C 172.16.24.0/24 is directly connected, FastEthernet0/0.2
S* 0.0.0.0/0 [1/0] via 172.16.2.17

hostname msk-arbat-gw1
!
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.101
description PTO
encapsulation dot1Q 101
ip address 172.16.3.1 255.255.255.0
!
interface FastEthernet0/1
no ip address
duplex auto
speed auto
!
interface FastEthernet0/1.4
description SPB
encapsulation dot1Q 4
ip address 172.16.2.1 255.255.255.252
!
interface FastEthernet0/1.5
description KMR
encapsulation dot1Q 5
ip address 172.16.2.17 255.255.255.252
!
interface Vlan1
no ip address
shutdown
!
ip classless
ip route 172.16.16.0 255.255.248.0 172.16.2.2
ip route 172.16.2.4 255.255.255.252 172.16.2.2
ip route 172.16.24.0 255.255.255.252 172.16.2.18

вот таблица маршрутизации:
172.16.0.0/16 is variably subnetted, 11 subnets, 3 masks
C 172.16.0.0/24 is directly connected, FastEthernet0/0.3
C 172.16.1.0/24 is directly connected, FastEthernet0/0.2
C 172.16.2.0/30 is directly connected, FastEthernet0/1.4
S 172.16.2.4/30 [1/0] via 172.16.2.2
C 172.16.2.16/30 is directly connected, FastEthernet0/1.5
C 172.16.3.0/24 is directly connected, FastEthernet0/0.101
C 172.16.4.0/24 is directly connected, FastEthernet0/0.102
C 172.16.5.0/24 is directly connected, FastEthernet0/0.103
C 172.16.6.0/24 is directly connected, FastEthernet0/0.104
S 172.16.16.0/21 [1/0] via 172.16.2.2
S 172.16.24.0/30 [1/0] via 172.16.2.18
avatar
Я какой-то невежливый )
Для начала хотелось бы сказать вам большое спасибо, очень крутой материал. Хорошая подача, и грамотно подготовленный материал делают ваши уроки более полезными, чем практику в вузах.
Еще раз спасибо, парни! Вот от души )
avatar
не удержался и сам во всем разобрался.
Проблема оказалась в том, что Кемеровский Лаптоп оказался подключен к kmr-gorka-sw1 через транковый порт с одним разрешенным вланом 2 (LAN). Поменял trunk на access и всё заработало.
только не спрашивайте как это повлияло на маршрутизацию между Kmr-gorka-gw1 и msk-arbat-gw1 :-). Сам в шоке.
avatar
Оказалось, что в моей версии РТ одинаковые настройки на роутерах 2811 и 2620 дают разные результаты.
на 2620 не работала сеть LAN, поменял на 2811 и всё поднялось.
avatar
Огромное спасибо за Ваш труд! Очень полезно и познавательно!
При выполнении задания с пингом Сети Управления, догадался, что что-то не хватает в настройках коммутаторов. Почитав комментарии, видел, что люди прописывают default-gateway 172.16.1.1 на коммутаторах. Я прописал один def-gateway на коммутаторе msk-arbat-dsw1. Пинги с компьютеров пошли в Сеть Управления. Но я не понял, зачем мы это сделали, думал, что все межвланые пакеты придут на роутер, так как его саб-интерфейсы стоят по-умолчанию шлюзом в сетевых настройках компьютеров. Не могли бы описать в данном случае проход пакета, и как пакет взаимодействует с маршрутом по-умолчанию в коммутаторе. Надеюсь, вопрос понятно задал)
Заранее спасибо!
avatar
Этот маршрут мы прописываем только для того, что пакеты самого коммутатора могли быть отправлены — это не для транзитного трафика.

То есть, например, не имея IP-адреса на узле, вы не сможете на него подключиться telnet'ом или даже просто отправить пинг. А если добавляем IP-адрес, то нужно и шлюз настроить — куда отправлять пакет в другую сеть.
avatar
Да, я потом уже разобрался, что именно для этого и нужно было прописать дефолтный маршрут.
Как кто-то из комментаторов говорил уже здесь «надо думать на свежую голову»
Спасибо)
avatar
Ааааа! До меня дошло! Спасибо что задаёте вопросы и отвечаете на них! Дело в ответных пакетах))
avatar
Такой вопрос: а что если мне понадобится добавить, например, на Васильевском острове комп, который должен входить в влан 101 и иметь айпишник из той сети. Как в таком случае настроить маршрутизацию?
avatar
Здравствуйте!
Спасибо вам большое за бескорыстный труд для всех)
У меня снова вопрос: а чем отличается default-gateway на spb-ozerki-gw1 от прописанного нами маршрута по умолчанию?
Как я понимаю, и то, и другое будет слать непонятные ему пакеты на опр адрес?
Только зарегистрированные и авторизованные пользователи могут оставлять комментарии.