return

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

2 ноября 2012, 17:04

Мальчик сказал маме: “Я хочу кушать”. Мама отправила его к папе.

Мальчик сказал папе: “Я хочу кушать”. Папа отправил его к маме.

Мальчик сказал маме: “Я хочу кушать”. Мама отправила его к папе.

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

Что случилось с мальчиком? TTL кончился.

Итак, поворотный момент в истории компании “Лифт ми Ап”. Руководство понимает, что компания, производящая лифты, едущие только вверх, не выдержит борьбы на высококонкурентном рынке. Необходимо расширять бизнес. Принято решение о покупке двух заводов: в Санкт-Петербурге и Кемерово.

Нужно срочно организовывать связь до новых офисов, а у вас ещё даже локалка не заработала.

Сегодня: настраиваем маршрутизацию между вланами в нашей сети (InterVlan routing), пытаемся разобраться с процессами, происходящими в сети, и что творится с данными, планируем расширение сети (IP-адреса, вланы, таблицы коммутации), настраиваем статическую маршрутизацию и разбираемся, как она работает, используем L3-коммутатор в качестве шлюза.


Содержание выпуска

  • InterVlan Routing
  • Настройка
  • Дополнительно
  • Материалы выпуска

  • InterVlan Routing

    Чуточку практики для взбадривания.

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

    В нашей московской сети для маршрутизации между вланами мы будем использовать роутер cisco 2811. Иными словами он будет терминировать вланы. Кадры здесь заканчивают свою жизнь: из них извлекаются IP-пакеты, а заголовки канального уровня отбрасываются.

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

    1. Сначала закончим с коммутатором 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
      
    2. Назначаем имя маршрутизатора командой hostname, а для развития хорошего тона, надо упомянуть, что лучше сразу же настроить время на устройстве. Это поможет вам корректно идентифицировать записи в логах.
      Router0#clock set 12:34:56 7 august 2012
      Router0# conf t
      Router0(config)#hostname msk-arbat-gw1
      

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

    3. Далее переходим в режим настройки интерфейса, обращённого в нашу локальную сеть и включаем его, так как по умолчанию он находится в состоянии Administratively down.
      msk-arbat-gw1(config)#interface fastEthernet 0/0
      msk-arbat-gw1(config-if)#no shutdown 
      
    4. Создадим виртуальный интерфейс или иначе его называют подинтерфейс или ещё сабинтерфейс (sub-interface).
      msk-arbat-gw1(config)#interface fa0/0.2
      msk-arbat-gw1(config-if)#description Management
      

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

    5. Теперь вспомним о стандарте 802.1q, который описывает тегирование кадра меткой влана. Следующей командой вы обозначаете, что кадры, исходящие из этого виртуального интерфейса будут помечены тегом 2-го влана. А кадры, входящие на физический интерфейс FastEthernet0/0 с тегом этого влана будут приняты виртуальным интерфейсом FastEthernet0/0.2.
      msk-arbat-gw1(config-if)#encapsulation dot1Q 2
      
    6. Ну и как на обычном физическом 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) самостоятельно. Мы же далее будем только аргументировать выбор конкретного размера сети. Как бы то ни было, полное понимание придёт только с практикой.

    Вообще, очень неплохо эта тема раскрыта в этой статье: https://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-план, планы коммутации по каждой точке и регламент

    Файл РТ с лабораторной

    Конфигурация устройств

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



    Авторы

    Оставайтесь на связи

    Пишите нам: info@linkmeup.ru
    Канал в телеграме: t.me/linkmeup_podcast
    Канал на youtube: youtube.com/c/linkmeup-podcast
    Подкаст доступен в iTunes, Google Подкастах, Яндекс Музыке, Castbox
    Сообщество в вк: vk.com/linkmeup
    Группа в фб: www.facebook.com/linkmeup.sdsm
    Добавить RSS в подкаст-плеер.
    Пообщаться в общем чате в тг: https://t.me/linkmeup_chat

    Поддержите проект:

like 18 views 881809 message 197

197 коментарий

  • Некропост. Между сабинтерфейсами на роутере msk-gw1 работает маршрутизация, верно? С msk-gw1-gw1 я пингую все коммутаторы по ip на vlan2 , если смотреть sh ip route 172.16.1.0, вывод дает мне маршрут на сабинтерфейс 2. Но трассировка с ПК PTO показывает, что дальше 172.16.3.1 пакет не идет. Лабу делаю в GNS3 , конфиги я все проверял, все один в один. Или я не неправильно понимаю и с PTO коммутаторы не должны пинговаться?

    30 мая 2022, 14:06
  • Владимир Гартман

    Что-то совсем я запутался в этих подсетях
    Не могу понять в каком случае надо вешать ptp адрес, в каком случае адрес шлюза
    И вообще какой ip Москвы должен пинговаться чтобы всё работало, ибо план для меня, как новичка ВООБЩЕ непонятный

    26 февраля 2020, 08:28
  • Алексей Семенов

    Не уверен, что еще актуально задавать вопросы, но он второй день меня мучает. Возможно рано его задавать и потом прояснится. Но сейчас уж очень непонятно 🙂
    В чем цель создания InterVLAN Routing на msk-arbat-gw1? Этим же мы, по сути, открываем доступ всем пользователям из разных созданных ранее VLAN-ов друг к другу. Т.е. отменяем ограничения доступа, наложенные ранее распределением их по разным VLANам. Зачем мы это делаем? Или я неверно понял суть InterVLAN Routing?

    20 декабря 2017, 13:32
    • Сеть на VLAN разделяется на несколько широковещательных домена, они не будут друг на друга какать запросами MAC адресов, в сети получается меньше «мусора». В прошлых статьях описывалось 2 или 3 пункта полезности разделение широковещательного домена на разные включая этот.

      16 мая 2022, 16:01
  • Конфиг к предыдущему вопросу

    msk-arbat-dsw1#show running-config
    Building configuration…

    Current configuration: 1618 bytes
    !
    ! Last configuration change at 03:09:59 EET Thu Aug 31 2017
    !
    version 15.2
    service timestamps debug datetime msec
    service timestamps log datetime msec
    no service password-encryption
    service compress-config
    !
    hostname msk-arbat-dsw1
    !
    boot-start-marker
    boot-end-marker
    !
    !
    !
    no aaa new-model
    clock timezone EET 2 0
    !
    !
    !
    !
    !
    !
    !
    !
    ip cef
    no ipv6 cef
    !
    !
    !
    spanning-tree mode rapid-pvst
    spanning-tree extend system-id
    !
    vlan internal allocation policy ascending
    !
    !
    !
    !
    !
    !
    !
    !
    !
    !
    !
    !
    !
    interface Ethernet0/0
    description trunk msk-arbat-asw1
    switchport trunk allowed vlan 2,3
    switchport trunk encapsulation dot1q
    switchport mode trunk
    !
    interface Ethernet0/1
    description trunk msk-arbat-asw2
    switchport trunk allowed vlan 2,3
    switchport trunk encapsulation dot1q
    switchport mode trunk
    !
    interface Ethernet0/2
    description msk-rubl-acsw1
    switchport trunk allowed vlan 2,101,104
    switchport trunk encapsulation dot1q
    switchport mode trunk
    !
    interface Ethernet0/3
    description msk-arbat-gw1
    switchport trunk allowed vlan 2,3,101-104
    switchport trunk encapsulation dot1q
    switchport mode trunk
    !
    interface Ethernet1/0
    description trunk msk-arbat-acsw3
    switchport trunk allowed vlan 2,101-104
    switchport trunk encapsulation dot1q
    switchport mode trunk
    !
    interface Ethernet1/1
    !
    interface Ethernet1/2
    !
    interface Ethernet1/3
    !
    interface Vlan2
    description Management
    ip address 172.16.1.2 255.255.255.0
    !
    ip default-gateway 172.16.1.1
    ip forward-protocol nd
    !
    no ip http server
    no ip http secure-server
    !
    !
    !
    !
    !
    !
    control-plane
    !
    !
    line con 0
    logging synchronous
    line aux 0
    line vty 0 4
    login
    !
    !
    end

    msk-arbat-dsw1#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)
    msk-arbat-dsw1#trac
    msk-arbat-dsw1#traceroute 172.16.3.1
    Type escape sequence to abort.
    Tracing the route to 172.16.3.1
    VRF info: (vrf in name/id, vrf out name/id)
    1 * * *
    2 * * *
    3 * * *
    4 * * *
    5 * * *
    6 * * *
    7 * * *
    8
    msk-arbat-dsw1#

    msk-arbat-gw1#show running-config
    Building configuration…

    Current configuration: 1902 bytes
    !
    ! Last configuration change at 03:12:13 EET Thu Aug 31 2017
    !
    version 15.4
    service timestamps debug datetime msec
    service timestamps log datetime msec
    no service password-encryption
    !
    hostname msk-arbat-gw1
    !
    boot-start-marker
    boot-end-marker
    !
    !
    !
    no aaa new-model
    clock timezone EET 2 0
    mmi polling-interval 60
    no mmi auto-configure
    no mmi pvc
    mmi snmp-timeout 180
    !
    !
    !
    !
    !
    !
    !
    !

    !
    !
    !
    !
    ip cef
    no ipv6 cef
    !
    multilink bundle-name authenticated
    !
    !
    !
    !
    !
    !
    !
    !
    !
    redundancy
    !
    !
    !
    !
    !
    !
    !
    !
    !
    !
    !
    !
    !
    !
    !
    interface Ethernet0/0
    description trunk msk-arbat-dsw1
    no ip address
    !
    interface Ethernet0/0.2
    description Management
    encapsulation dot1Q 2
    ip address 172.16.1.1 255.255.255.0
    !
    interface Ethernet0/0.3
    description Servers
    encapsulation dot1Q 3
    ip address 172.16.0.1 255.255.255.0
    !
    interface Ethernet0/0.101
    description PTO
    encapsulation dot1Q 101
    ip address 172.16.3.1 255.255.255.0
    !
    interface Ethernet0/0.102
    description FEO
    encapsulation dot1Q 102
    ip address 172.16.4.1 255.255.255.0
    !
    interface Ethernet0/0.103
    description Buh
    encapsulation dot1Q 103
    ip address 172.16.5.1 255.255.255.0
    !
    interface Ethernet0/0.104
    description Other
    encapsulation dot1Q 104
    ip address 172.16.6.1 255.255.255.0
    !
    interface Ethernet0/1
    description trunk Prov_L2
    no ip address
    !
    interface Ethernet0/1.4
    description SPB
    encapsulation dot1Q 4
    ip address 172.16.2.1 255.255.255.252
    !
    interface Ethernet0/1.5
    description KMR
    encapsulation dot1Q 5
    ip address 172.16.2.17 255.255.255.252
    !
    interface Ethernet0/2
    no ip address
    shutdown
    !
    interface Ethernet0/3
    no ip address
    shutdown
    !
    ip forward-protocol nd
    !
    !
    no ip http server
    no ip http secure-server
    ip route 172.16.2.4 255.255.255.252 172.16.2.2
    ip route 172.16.16.0 255.255.248.0 172.16.2.2
    !
    !
    !
    !
    control-plane
    !
    !
    !
    !
    !
    !
    !
    !
    line con 0
    logging synchronous
    line aux 0
    line vty 0 4
    login
    transport input none
    !
    !
    end

    msk-arbat-gw1#ping 172.16.3.2
    Type escape sequence to abort.
    Sending 5, 100-byte ICMP Echos to 172.16.3.2, timeout is 2 seconds:
    !!!
    Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/2 ms
    msk-arbat-gw1#ping 172.16.1.2
    Type escape sequence to abort.
    Sending 5, 100-byte ICMP Echos to 172.16.1.2, timeout is 2 seconds:
    !!!
    Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/1 ms

    VPCS> show ip

    NAME: VPCS[1]
    IP/MASK: 172.16.3.2/24
    GATEWAY: 172.16.3.1
    DNS:
    MAC: 00:50:79:66:68:07
    LPORT: 20000
    RHOST:PORT: 127.0.0.1:30000
    MTU: 1500

    VPCS> ping 172.16.1.1

    84 bytes from 172.16.1.1 icmp_seq=1 ttl=255 time=1.966 ms
    84 bytes from 172.16.1.1 icmp_seq=2 ttl=255 time=1.508 ms
    ^C
    VPCS> ping 172.16.1.2

    172.16.1.2 icmp_seq=1 timeout
    172.16.1.2 icmp_seq=2 timeout
    172.16.1.2 icmp_seq=3 timeout
    ^C
    VPCS> trace 172.16.1.2
    trace to 172.16.1.2, 8 hops max, press Ctrl+C to stop
    1 172.16.3.1 1.736 ms 2.154 ms 1.336 ms
    2 * * *
    3 * * *
    4 * * *
    5 * * *
    6 * * *
    7 * * *
    8 * * *

    31 августа 2017, 05:35
  • Здравтствуйте, заранее спасибо за такой поучительный курс.
    Я тут новенький и может задаю морально устаревшие вопросы, собрал сеть в EVE-NG, не могу сообразить почему не доступна сеть управления из сети ПТО, скинул конфиг, посмотрите пожалуйста что не так. Шлюз по умолчанию 172.16.1.1 на свиче прописан. Например сервера из ПТО пингуются, управление нет. Заранее спасибо.

    31 августа 2017, 05:33
  • Виталий Чернов

    Прошу помочь, не удается настроить Кемерово
    ptp адреса не пингуются с роутеров

    msk-arbat-gw1>sh run
    interface FastEthernet0/1
    description Uplink
    no ip address
    duplex auto
    speed auto
    !
    interface FastEthernet0/1.4
    description Saint-Petersburg
    encapsulation dot1Q 4
    ip address 172.16.2.1 255.255.255.252
    !
    interface FastEthernet0/1.5
    description Kemerovo
    encapsulation dot1Q 5
    ip address 172.16.2.17 255.255.255.252

    Provider#sh run
    interface FastEthernet0/3
    description Kemerovo
    switchport trunk allowed vlan 5
    switchport mode trunk

    kmr-gorka-sw1#sh run
    interface FastEthernet0/23
    switchport trunk allowed vlan 5
    switchport mode trunk
    !
    interface FastEthernet0/24
    switchport trunk allowed vlan 5
    switchport mode trunk

    kmr-gorka-gw1#sh run
    interface FastEthernet0/0
    description Uplink
    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
    encapsulation dot1Q 5
    ip address 172.16.2.18 255.255.255.252

    Причем когда убираю kmr-gorka-sw1 и подключаю kmr-gorka-gw1 к интерфейсу fa0/3 на свиче провайдера, то ptp адреса пингуются

    6 июня 2017, 17:53
  • Помогите начинающему. Я только начал читать статью и сразу завис над настройкой роутера 2811. От роутера я вижу все вланы, но при попытке, например, пинговать сеть ФЕО с компьютера из сети ПТО ничего не получается.

    !
    hostname msk-arbat-gw1
    !
    !
    !
    !
    !
    !
    !
    !
    ip cef
    no ipv6 cef
    !
    !
    !
    !
    !
    !
    !
    !
    !
    !
    !
    !
    spanning-tree mode pvst
    !
    !
    !
    !
    !
    !
    interface FastEthernet0/0
    no ip address
    duplex auto
    speed auto
    !
    interface FastEthernet0/0.2
    description Management
    encapsulation dot1Q 2
    ip address 172.16.1.1 255.255.255.0
    !
    interface FastEthernet0/0.3
    description Servers
    encapsulation dot1Q 3
    ip address 172.16.0.1 255.255.255.0
    !
    interface FastEthernet0/0.101
    description PTO
    encapsulation dot1Q 101
    ip address 172.16.3.1 255.255.255.0
    !
    interface FastEthernet0/0.102
    description FEO
    encapsulation dot1Q 102
    ip address 172.16.4.1 255.255.255.0
    !
    interface FastEthernet0/0.103
    description Accounting
    encapsulation dot1Q 103
    ip address 172.16.5.1 255.255.255.0
    !
    interface FastEthernet0/0.104
    description Others
    encapsulation dot1Q 104
    ip address 172.16.6.1 255.255.255.0
    !
    interface FastEthernet0/1
    no ip address
    duplex auto
    speed auto
    shutdown
    !
    interface Vlan1
    no ip address
    shutdown
    !
    router rip
    !
    ip classless
    !
    ip flow-export version 9
    !
    !
    !
    !
    !
    !
    !
    line con 0
    !
    line aux 0
    !
    line vty 0 4
    login
    !
    !
    !
    end
    13 мая 2017, 21:01
  • Кирилл Бондаренко

    Добрый день. Возникло еще пару вопросов касательно Trunk портов и Vlan.
    1. Я создал на свитче rubl-asw1 вланы согласно условий ( 2,101,104) и через транк порт fa0/24 пропустил их в сторону arbat-dsw1. Так же я создал вланы на rubl-asw3 (2,101-104) и пропустил их через транк порт gi1/1 в сторону rubl-dsw1 На самом dsw1 я не создавал транки ни на одном порту ( т.е. fa0/1 в сторону rubl-asw1 и gi1/2 в сторону arbat-asw3)Но пинг из сети ПТО свободно ходит между 172.16.3.2-3 и 172.16.3.4. Вопрос почему??? (сторону серверов в пример не брал).

    2. Еще заметил следующее: я не создавал специально на dsw1 vlan 104, но в этот раз транк настроил абсолютно между всеми портами в разные стороны как в вашем видео. И пинг все равно проходит между 172.16.6.2 (arbat-asw3) и 172.16.6.3 (rubl-asw1). Почему проходит пинг 104 влана если на свитче dsw1 он не создан, но в транке пропущен?? Если я правильно понял то не обязательно создавать влан на проходящем коммутаторе. Достаточно просто указать, что этот влан проходит через транк?

    23 апреля 2017, 19:35
  • Кирилл Бондаренко

    Добрый день, немного не понятно для чего на свитче и маршрутизаторе Кемерово делать 5 влан. Почему нельзя так же сделать 4 влан? Ведь провайдер из условия дал 4 влан и через него идет связь в Интернет.

    13 апреля 2017, 17:51
  • Вячеслав Осипов

    а все сам разобрлся)

    7 апреля 2017, 10:03
  • Вячеслав Осипов

    Здравствуйте! спасибо за урок. Все настроил и работает, вопрос только один, что это за сеть 172.16.2.4? откуда она взялась когда прописываем на московском роутере маршрут через 172.16.2.2?

    6 апреля 2017, 11:00
  • Спасибо большое! На счет маски в Ip route к Kmr, все нормально было, я просто сделал меньший диапазон подсетей, может в будущем мне аукнуться конечно, но пока там вроде не планировалось дальнейшее расширение, в связи с чем 255 адресов вполне хватает) а вот с адресом «шлюза последней надежды» я допустил ошибку, забыл, что должен стучаться к созданной и отведенной под горку сети, пытался к другой прописать, он мне не сохранял конфу( а вот к шлюзу 2.17 все подключилось. Еще раз спасибо! Обожаю этот портал!

    27 марта 2017, 12:35
  • Добрый день! Сам только учусь и разбираюсь, поэтому может и неправильно подскажу. Скорее всего ты забыл прописать в маршрутизаторе kmr-gorka-gw1
    ip route 0.0.0.0 0.0.0.0 172.16.2.17 и у тебя в msk-arbat-gw1 на мой взгляд неверно указана маска ip route 172.16.24.0 255.255.255.0 172.16.2.18, у меня 255.255.248.0. Попробуй может поможет.

    24 марта 2017, 18:22
  • Добрый день.
    Во первых хочу поблагодарить автора этих прекрасных статей, за его работу!)

    ВО вторых у меня такая проблема, вроде все настроил, но…

    Ping из msk-arbat-gw1 до kmr-gorka-gw1 идет, из spb-vsl-gw1 я вижу все сети настроенные на msk-arbat-gw1 (естественно могу до них достучаться), а вот с маршрутизатора KMR-GORKA-GW1 пинг идет только до сети 172.16.2.17 на MSK-ARBAT, остальные сети (PTO, FEO и тд.) мне не видно.

    Вопрос — что не так?

    Конфиг kmr-gorka-gw1

    interface FastEthernet0/0
    description msk
    no ip address
    duplex auto
    speed auto
    !
    interface FastEthernet0/0.4
    description LAN
    encapsulation dot1Q 4
    ip address 172.16.24.1 255.255.255.0
    !
    interface FastEthernet0/0.5
    description msc
    encapsulation dot1Q 5
    ip address 172.16.2.18 255.255.255.252
    !
    ip classless
    !
    ip flow-export version 9
    !
    !
    !
    !
    !
    !
    !
    line con 0
    !
    line aux 0
    !
    line vty 0 4
    login
    !
    !
    !
    end

    Конфиг msk-arbat-gw1

    interface FastEthernet0/0
    no ip address
    duplex auto
    speed auto
    !
    interface FastEthernet0/0.2
    description management
    encapsulation dot1Q 2
    ip address 172.16.1.1 255.255.255.0
    !
    interface FastEthernet0/0.3
    description Servers
    encapsulation dot1Q 3
    ip address 172.16.0.1 255.255.255.0
    !
    interface FastEthernet0/0.101
    description PTO
    encapsulation dot1Q 101
    ip address 172.16.3.1 255.255.255.0
    !
    interface FastEthernet0/0.102
    description FEO
    encapsulation dot1Q 102
    ip address 172.16.4.1 255.255.255.0
    !
    interface FastEthernet0/0.103
    description BUH
    encapsulation dot1Q 103
    ip address 172.16.5.1 255.255.255.0
    !
    interface FastEthernet0/0.104
    description Other
    encapsulation dot1Q 104
    ip address 172.16.6.1 255.255.255.0
    !
    interface FastEthernet0/1
    no ip address
    duplex auto
    speed auto
    !
    interface FastEthernet0/1.4
    description Saint-Petersburg
    encapsulation dot1Q 4
    ip address 172.16.2.1 255.255.255.252
    !
    interface FastEthernet0/1.5
    description Kemerovo
    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.0 172.16.2.18
    !
    ip flow-export version 9
    !
    !
    !
    !
    !
    !
    !
    line con 0
    !
    line aux 0
    !
    line vty 0 4
    login
    !
    !
    !
    end

    Я еще начинающий, не судите строго)

    23 марта 2017, 14:45
  • Доброго времени суток! Подскажите пожалуйста, на видео 4:41 Вы говорите что cisco 2811 мы устанавливали и настраивали ранее. Я не могу найти статью или видео где это объясняется.

    21 ноября 2016, 19:00
  • У меня такой вопрос, дело в том что я изучаю ваш курс как на «Cisco Packet Tracer», а также дублирую его на eNSP Huawei, так вот, в схемке с соединением сетей Москва и Васильевский остров через провайдера (который представлен коммутатором), соединение через 4-й VLAN, маршрутизаторы msk-arbat-gw1 и spb-vsl-gw1 не видят друг-друга ну никак… пинг не проходит… на cisco всё работает идеально… почему так?.. настроил всё точно также, логистика настроек cisco и huawei очень схожи… подскажите почему на cisco всё работает а на huawei нет?..
    Заранее брагодарен…
    CISCO
    msk-arbat-gw1
    interface FastEthernet0/1.4
    description SPB
    encapsulation dot1Q 4
    ip address 172.16.2.1 255.255.255.252

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

    коммутатор (провайдер)
    interface FastEthernet0/1
    switchport trunk allowed vlan 4-5
    switchport mode trunk
    !
    interface FastEthernet0/2
    switchport trunk allowed vlan 4-5
    switchport mode trunk

    HUAWEI
    msk-arbat-gw1
    interface Ethernet0/0/1.4
    description SPB
    dot1q termination vid 4
    ip address 172.16.2.1 255.255.255.252

    spb-vsl-gw1
    interface Ethernet0/0/1.4
    description Moscow
    dot1q termination vid 4
    ip address 172.16.2.2 255.255.255.252

    коммутатор (провайдер)
    interface Ethernet0/0/1
    port link-type trunk
    port trunk allow-pass vlan 4 to 5

    interface Ethernet0/0/2
    port link-type trunk
    port trunk allow-pass vlan 4 to 5

    21 ноября 2016, 03:25
  • ARP-запрос ничего не вернёт, потому что широковещательные L2 сообщения кончаются на маршрутизаторе

    Это опечатка или, всё-таки, на маршрутизаторе?

    5 июня 2016, 19:09
  • Ярослав Давидяк

    Товарищи помогите. Я только начинаю свой путь по сетям. Все получилось, все всех видят НО! по поводу «почему не пингуются устройства из сети управления» — ничего не пойму( как это должно быть.В Кемерово тоже должен быть ПК с адресом из сети 172.16.1.0/24 и он должен видеть своего товарища в Москве(с адресом из той же подсети) или как? Если да то объясните кто-нибуть как это сделать, я совсем запутался(

    31 мая 2016, 16:17
  • Анна Шихардина

    Здравствуйте!
    Спасибо вам большое за бескорыстный труд для всех)
    У меня снова вопрос: а чем отличается default-gateway на spb-ozerki-gw1 от прописанного нами маршрута по умолчанию?
    Как я понимаю, и то, и другое будет слать непонятные ему пакеты на опр адрес?

    17 февраля 2016, 12:43
  • Такой вопрос: а что если мне понадобится добавить, например, на Васильевском острове комп, который должен входить в влан 101 и иметь айпишник из той сети. Как в таком случае настроить маршрутизацию?

    20 июля 2015, 11:54
  • Огромное спасибо за Ваш труд! Очень полезно и познавательно!
    При выполнении задания с пингом Сети Управления, догадался, что что-то не хватает в настройках коммутаторов. Почитав комментарии, видел, что люди прописывают default-gateway 172.16.1.1 на коммутаторах. Я прописал один def-gateway на коммутаторе msk-arbat-dsw1. Пинги с компьютеров пошли в Сеть Управления. Но я не понял, зачем мы это сделали, думал, что все межвланые пакеты придут на роутер, так как его саб-интерфейсы стоят по-умолчанию шлюзом в сетевых настройках компьютеров. Не могли бы описать в данном случае проход пакета, и как пакет взаимодействует с маршрутом по-умолчанию в коммутаторе. Надеюсь, вопрос понятно задал)
    Заранее спасибо!

    4 июля 2015, 18:01
  • Никак не получается настроить маршрутизацию между Кемерово и Москвой. Из сети 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

    14 апреля 2015, 16:28
  • Добрый вечер!
    Не знаю отвечаете ли вы еще здесь на вопросы, но есть вопрос по настройке 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. Конечные устройства из разных сетей (ПТО и управления) пингуют друг друга, т.е. на маршрутизаторе все настроено. Где же может скрываться проблема?

    28 марта 2015, 21: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) будет у нас для Кемерово.

    и ниже тут же в табличке для Кемерова пишите маску /21

    4 февраля 2015, 15:24
  • Miembros. Hjälper Priligy mot prestationsångest — Erektil dysfunktion läkemedel Priligy online. 0 amigos Escribir mensaje Añadir como amigo. Viagra vs stendra, Priligy mot prestationsångest. För tidig utlösning — Skaffa hjälp för problem med för tidig. Onlinedoktorn erbjuder Priligy mot för tidig utlösning. Ta bort begränsningarna i ditt sexliv – prova PriligyDu ska INTE ta CIALIS mer än en gång per dag, Få tag på Cialis snabbt. Om du har tagit för stor mängd av CIALIS Kontakta din läkare. Om du har glömt att ta CIALIS Ta inte dubbel dos för att kompensera för glömd tablett. Stockholm: Liber AB; 2005, ss. Rigla M, Sanchez-Quesada JL, Ordonez-Llanos J, Prat T, Caixas A, Jorba O, et al. Effect of physical exercise on lipoprotein(a) and low-density lipoprotein modifications in type 1 and type 2 diabetic patients. Henriksson J, Sahlin K, Beställa Kamagra piller utan recept i Sverige.

    16 января 2015, 17:06
  • , Казино zero предоставляет возможность играть более анонимно выигрыш получаетПосмотрите правила игры прежде чем начинать тратить свои деньги. Однако помните, что если какое либо правило действует в пользу игрока, то обязательно казино вводит другие правила ухудшающие его положение. При длительной игре ухудшения правил будут складываться не в вашу пользу. Если открытая карта дилера не 10 или туз, игра идет в обычном порядке, Производство игровые автоматы нижний новгород аэрохоккей. Игрок эту карту не видит. Если у дилера из двух карт выпадает блэк джек, то игра сразу прекращается. А регулярные бонусы и подарки сделают игру еще более интересной. К Вашим услугам также круглосуточная служба поддержки, готовая в любой момент прийти Вам на помощь. Сегодня не так просто подобрать онлайн казино, ведь оно должно быть честным, в нем должны быть интересные игры и оперативная служба поддержки. Также стоит отметить необходимость хотя бы нескольких способов пополнения депозита и вывода выигрыша, Игровые автоматы 9 и 5 линейные без регистрации и смс. Помощь игрокам на сайте оказывается круглосуточно, грамотные специалисты ответят на любые Ваши вопросы и решат все проблемы, касающиеся игры в интернет казино онлайн.

    16 января 2015, 17:03
  • Доброго времени суток!
    Огромное спасибо за ваш труд, все очень здорово и понятно написано.
    Я решил перечитать все статьи с нулевой и тут на этой запнулся на протоколе 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 и маршрутизатора. Что делает с пакетом маршрутизатор?

    16 января 2015, 12:52
  • Доброго времени суток, спасибо большое за материал, всё очень понравилось, маршрутизацию между Кемерово настроил, не могу пингануть asw 3, задал ему default — gateway 172.16.1.5, нужно прописать статическую маршрутизацию на роутере?

    14 января 2015, 14:07
  • Добрый день. Стало интересно можно ли осуществить маршрутизацию между подсетями в данном случае не используя вланы?

    13 января 2015, 23:39
  • Добрый день, на дворе ноябрь 2014 года и космический зонд Филы, отправил уже много душераздирающих фоток!!! Авторам статьи большой респект, за проявленный умственный и физический труд.Материал очень доходчиво разъяснен!!! Ждем-с новых статей…

    16 ноября 2014, 17:07
    • Да, я потом уже разобрался, что именно для этого и нужно было прописать дефолтный маршрут.
      Как кто-то из комментаторов говорил уже здесь «надо думать на свежую голову»
      Спасибо)

      6 июля 2015, 12:20
  • Спасибо большое. Очень хороший курс.
    Хотелось бы узнать как можно сделать так, чтобы, допустим, сеть на Озерках в Санкт-Петербурге была бы в одном и том же влане «PTO» что и в Москве. То есть чтобы офисы в Питере и Москве находились в одном Влане хоть они и разделены маршрутизаторами.

    Не уверен что целесообразно это делать, просто интересно))
    Спасибо.

    11 ноября 2014, 20:52
  • Вставлю свои 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

    Автору выражаю большую признательность за изложенный материал. Всё доступно и понятно! Учусь.

    5 октября 2014, 19:17
  • Подскажите, правильный ответ, я так и не понял. У меня получилось только если я убрал 30 маску на kmr-gorka-gw1 на 24 тогда стало все доступно. Но как я не пытался ни чего получалось с 30 маской. Может я что то делаю не там.

    14 сентября 2014, 16:48
  • Добрый день помогите пожалуйста разобраться, заранее благодарен

    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?

    23 июля 2014, 14:37
  • Огромное спасибо за титанический труд. С маршрутизацией разобрался. Но возник вопрос с командой, позволяющей свести настройки интерфейса к дефолтным. Есть команда — к примеру, — cisco(config)#default interface gigabitEthernet 0/44. На рнальном железе не пробовал, а в PT не работает. Либо я что-то делаю неправильно. Как решить эту проблему? Ведь бывает необходимость сделать откат настроек.
    Спасибо.

    9 июля 2014, 10:29
  • Нашел: в конфиге моего spb-vsl-gw1 нет строки

    C 172.16.16.0/24 is directly connected, FastEthernet0/0

    У него вообще работает только добавленная плата, на «родной» при включенных портах все лежит. Наверно глюк PT.

    7 июля 2014, 22:39
  • *Пинг 172.16.16.1 не идет даже с самого питерского маршрутизатора, порт fa 0/0 включен.

    6 июля 2014, 00:43
  • Здравствуйте. Не могу выполнить пинг локальной сети в Питере из Москвы:

    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

    Где я ошибся?

    6 июля 2014, 00:39
  • Странно как-то.
    У меня не получается настроить межвланный роутинг.

    Вот, собсна, проектик.На 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 проходят.
    Не подскажете, в чем косяк?

    25 июня 2014, 18:26
  • Заранее прошу прощение за, возможно, глупые вопросы.

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

    И еще одно, у виртуальных интерфейсов маршрутизатора будут разные MAC-адреса или они будут наследовать MAC-адрес физического интерфейса?

    19 июня 2014, 05:12
  • Здравствуйте!
    Столкнулся с одно странной и не понятной для меня ситуацией. Может вы объясните как такое может происходить.
    Есть шлюз 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’е наблюдаю такую же картину ответов, как и выше.

    У меня два вопроса: какого… и почему оно работает.

    15 мая 2014, 05:09
  • Здравствуйте! В обсуждениях выше не совсем понял насчет широковещательного IP при ARP-запросе.В нем, насколько я знаю, указываются конктретные IP-адреса отправителя и получателя(MAC адрес, которого мы хотим узнать).Разъясните пожалуйста этот момент.

    12 мая 2014, 00:11
  • Доброго времени суток!
    спасибо Вам, за статьи! Мне страшно представить, сколько Вы времени потратили времени на подготовки и подачу материала.

    1 мая 2014, 20:42
  • Здравствуйте!
    Серия статей супер! Большое спасибо за труд!
    Такой вопрос…
    В Кемерово и Питере мы настроили влан 2 как локальный, а разве мы не хотим иметь доступ к роутерам и свитчам для настройки из Москвы по 2 влану, тот который «Management»? Почему мы именно так настраиваем? Как я понимаю, влан 2 «Management» нужен только админу для настройки и чтобы все остальные не имели доступа к свитчам и роутерам. Если это так, то получается, что в Кемерово и Питере доступ к свитчам и роутерам имеют обычные пользователи, или я не правильно понимаю. Спасибо!

    17 февраля 2014, 08:23
  • Здравствуйте! Вопрос такой…
    Если сделать

    switchport trunk allowed vlan add X

    Он не появляется в

    Vlans in spanning tree forwarding state and not pruned

    Иными словами если я сразу не добавил то мне приходится делать no, а затем добавлять по новой и тогда все ок.
    Как правильно добавить Vlan?

    5 февраля 2014, 13:25
  • Добрый день!

    У меня такой вопрос на видео, 29:58 вы пишите адрес 172.16.2.4 хотя вы его нигде не прописывали. Объясните пожалуйста для чего это делается если вы его нигде не указывали.

    23 января 2014, 12:48
  • написал ip def-get на всех коммутаторах, заработало. Думаю верно.

    31 октября 2013, 15:13
  • Здравствуйте! Во первых огромное спасибо за курс, прекрасно все повествуете. У меня вопрос. Маршрутизацию как понял настроил все пингуется. Но проблема с сетью управления. С 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

    30 октября 2013, 16:01
  • Здравствуйте, коллеги.
    У меня случился затык с ARP. Я не понял можно ли этот протокол отнести однозначно к какому-то конкретному уровню (сетевому, канальному)?
    Мне казалось что arp передает информацию с третьего уровня на второй. Но с другой стороны становится непонятно как он подставляет в эзернет кадр — широковещательный destination.
    Или я просто запутался и arp работает на обоих уровнях и представляет собой отдельный, независящий от второго уровня, протокол?

    11 октября 2013, 09:18
  • Здравствуйте. Я начинающий сетевик и у меня вопрос возник по ходу выполнения лабы «Лифт ми ап». Часть 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.

    9 октября 2013, 17:25
  • Привет!
    у меня проблемка с настройкой маршрутизации между Москвой и Кемерово… вот я пробую настроить следующие маршрут: На маршрутизаторе в Кемерово Шлюз по умолчанию 172.16.2.1; В москве 172.16.24.0 255.255.255.0 172.16.2.16, вот хотел спросить правильно я делаю или если есть ошибка? спасибо буду ждать ответа

    28 сентября 2013, 13:09
  • Добрый день коллеги, настроил связь между провайдером и kmr-gorka-sw1, но линк ни в какую не хочет подниматся, уже все проверил хоть убей, что может быть?

    22 сентября 2013, 20:05
  • Я настроил транки между msk-arbat-dsw1 и msk-arbat-asw1 так, что через них могут ходить тегированные кадры с метками 2 и 3, сеть PTO имеет метку 101, и почему-то у меня получается пропинговать, допустим, с ПК 172.16.3.2 (VLAN 101) сервер 172.16.0.2 (VLAN 3). Поясните?

    17 августа 2013, 19:33
  • Если смотреть как ходят пакеты то пакет доходит до msk-arbat-gw1 от туда уже с адресом назначения нужного устройства допустим 172.16.1.2 он идет на эту железку и уже там отбрасывается. На всякий случай вот файл

    23 июля 2013, 13:48
  • Пинг из сети ПТО в 172.16.1.x видел что нужно прописать дефолтный маршрут, но не понял почему

    23 июля 2013, 13:36
  • Добрый вечер

    Совсем запутало последнее задание, не могли бы вы по подробнее объяснить как настроить доступ?

    22 июля 2013, 22:00
  • Вы пишите:

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

    но перед этими строками даете ссылку, где читаю:

    Процесс объединения мелких префиксов (с длинной маской, в которых мало хостов) в крупные (с короткой маской, в которых много хостов) называется агрегацией или суммаризацией (вот не суммированием!).

    Это о разном пишется?
    Спасибо.

    7 июля 2013, 00:48
  • Оказалось в PT интерфейс не доступен, пока на нем физически нет линка. Безрезультатно пытался пропинговать 172.16.17.1 (spb-ozerki-gw1), причем интерфейс был недоступен даже с самого свича (хотя он настроен и я сказал no shutdown). Убил минут 10, пока не догадался преципить ПК на порт=). Интересно это фишка PT или для «живых» цисок характерно такое же поведение?
    Скажите, пожалуйста, по мультикасту статью не планируете? Я успешно настраивал IPTV на д-линках (IGMP-snopping, RP и прочее), все работает, но не скажу, что хорошо понял эту тему=) Спасибо!

    30 июня 2013, 01:19
  • Видимо у меня одного траблы с маршрутизацией… Дело обстоит так:
    С 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)

    12 мая 2013, 22:59
  • Здравствуйте, сразу скажу не особо разбираюсь в теме, но очень хочу разобраться.
    Вопросы следующие:
    глобальный — зачем раскидывать группы на отдельные виланы, а потом настраивать маршрутизацию,
    если можно их оставить в одной сети (без виланов, одна подсеть где всем все видно), (мои догадки это ограничение широковещательных пакетов),
    правильно ли я понимаю принцип работы 2811 по маршрутизации виланов (что из одного вилана можно было зайти в другой) — по транковому порту маршрутизатор (2811) получает пакет с меткой вилана, отбрасывает ее, смотрим на какой ip надо отправить, добавляет соответсвующую метку вилана
    (метку вилана в которой находится нужный нам ip адрес) и отправляет.

    18 апреля 2013, 17:31
  • При настройке Кемерово, между коммутатором 2950-24 и маршрутизатором 2620XM нет линка если использовать перекрестный кабель. Глюк Packet Tracer?
    Спасибо за ваши труды.

    12 марта 2013, 17:59
  • Приветствую!
    Немного не понятно, почему же все таки я не могу пингануть сеть управления?
    Я пигую с ПК (тег номер 2) в Кемерово 172.16.1.3, адрес не из этой сети, отправляю кадр шлюзу по-умолчанию (172.16.24.1). Маршрутизатор не находит записи в своиз таблицах маршрутизации и отправляет его на шлюз последней надежды в Москву, поменяв тег со 2 на 5-ый. Кадр приходит в Москву на маршрутизатор. Он видит, что адрес назначения находится на сабинтерфесе и отправляет туда. По идеи все должно пройти. Так в чем же дело?

    2 марта 2013, 22:52
  • Здравствуйте
    Спс за статьи — очень интересные. Подскажите на счет сети управления — в Кемерово и Спб создал сети для управления 172.16.17.0/29, 172.16.25.0/29, vlan 2. Маршруты прописаны на 172,16,0,0.24 и обратно. Как получить доступ по телнету на коммутаторы из Москвы в Спб и Кемерово? Они даже не пингуются — через tracert доходит только до их роутера.

    31 января 2013, 14:36
  • Доброго время суток.
    Хотелось сделать ремарку, на 25 минуте Вы создаете второй вилан, и говорите что первый не рекомендуеться цыско. Ето не рекомендуеться не только цыско, если у Вас не фирма «Лифт ми АП» а скажем домашняя сеть размеров города. Велан 1 ето дефолтный вилан, и он дает также право настраивать комутатор из сети. Вот Вам и ответ, если пойдут брут атаки от недоучки студента второкурсника ляжет вся сеть. И прийдеться конфиги ити заливать чуть ли не вручную на каждый комутатор отдельно.

    7 января 2013, 11:31
  • Господа,
    пытаясь прописать дефолт, получаем:
    msk-arbat-dsw1>ip route 0.0.0.0 0.0.0.0 172.16.1.1
    ^
    % Invalid input detected at ‘^’ marker.

    Где грабли? 🙁

    29 декабря 2012, 23:20
  • Никак не могу понять действия на 31:46.
    Больше всего вымораживает строчка int fa0/3.
    Ведь на данном коммуникаторе мы этот шлюз вообще не используем(в Кемерово мы используем 24 шлюз).
    Что я недоглядел?

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

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

    P.S. Огромное спасибо за ваш труд!

    9 ноября 2012, 12:42
  • Можно и мне ответ, пожалуйста

    15 сентября 2020, 14:03
  • Еркебулан Абен

    Это виноват DTP (проприетарный протокол Cisco) Ссылка

    18 апреля 2018, 11:09
  • Алексей Семенов

    Значит я неправильно понял изначальную цель деления по VLAN. Думал, что таким образом мы пользователей ограничиваем не только на уровне L2, но и на L3. По сути, до введения Inter-VLAN Routing-а это ведь так и было?
    А после настройки Inter-VLAN Routing мы даем им доступ на уровне L3, но получаем возможность управлять доступами на этом уровне, правильно? Забегая вперед, хочу спросить — а вешать политики и управлять доступами мы можем только по конкретным пользователям, только по VLAN-ам или можно комбинировать оба способа?

    22 декабря 2017, 12:38
  • Нормально, актуально.
    Задачи деления по VLAN:
    1) Уменьшить широковещательный домен
    2) Разграничить пользователей на уровне L2
    Inter-VLAN Routing на L3-коммутаторе позволяет им общаться (а это обязательно необходимо), но только через этот L3-коммутатор, где мы можем повесить политики и управлять доступами.

    22 декабря 2017, 12:06
  • Виталий Чернов

    Вопрос снимается, нашел ошибку. vlan 5 не создал на свиче

    6 июня 2017, 21:16
  • Кирилл Бондаренко

    Георгий, спасибо за ответ

    19 апреля 2017, 17:24
  • Георгий ниже в целом всё верно ответил.
    В моём примере в статье, провайдер отдаёт транком, поэтому и надо согласовывать номер ВЛАНа.
    Я бы даже сказал, что если речь не о просто доступе в интернет, а о сервисах, например, VPN, то это чаще всего именно транк.

    17 апреля 2017, 19:23
  • Георгий Владимиров

    Обычно провайдеры отдают канал с аксессного порта, без тега. Но иногда бывает необходимость организовать несколько независимых каналов в одном порту (например порты на коммутаторе закончились, либо протягивать новый провод трудно), скажем один для корпоративной сети, а другой для доступа в интернет. Или вариант со стыком с другим провайдером — т.е. порт один, а каналов много (часть для копоративных сетей, часть для интернета) и они должны быть изолированы друг от друга.

    14 апреля 2017, 20:43
  • Кирилл Бондаренко

    Спасибо за ответ. Возник еще один вопрос. Точно не помню на какой минуте или в тексте говорилось, что мы должны договориться с провайдером о номере ВЛАНА. И порты для получения трафика делаем транковыми. Я так понимаю провайдер на своем коммутаторе делает тоже конечный порт транковым??? Или он делает свой конечный порт Акссесом??

    14 апреля 2017, 15:38
  • У нас здесь не говорится, о том, что мы организуем связь с другими офисами через интернет. Предполагается, что это некие арендованные каналы — один до СПБ, другой до Кемерова, поэтому и разные VLAN. Строго говоря, это формальность.

    13 апреля 2017, 19:35
  • Отлично!

    7 апреля 2017, 20:02
  • Да, проблема с маской, которая помещает адреса в разные подсети, случается. Надо быть аккуратнее. 🙂

    27 марта 2017, 20:27
  • Попробовал — хост-комутатор-хост, всё работает отлично, хосты вешал как на access-порты так и на trunk, всё работает… а маршрутизатор-комутатор-маршрутизатор — ну никак… может это глюк самой программы, или в оборудовании huawei по этому поводу есть какие-то дополнительные настройки?..
    Дело в том что в eNSP есть некоторые особенности, например компьютеры находящиеся в разных вланах и подсоединённые к одному маршрутизатору не будут видеть друг друга пока каждый из них не пропингует свой gateway…

    27 ноября 2016, 18:00
  • Попробуйте схему попроще — хост-коммутатор-хост. Работает ли так?

    22 ноября 2016, 03:26
  • Ярослав Давидяк

    Хотел понять все за один день и вот посыпались глупые вопросы( Теперь все понял
    Эти уроки- титанический труд! Спасибо Вам большое!!!

    31 мая 2016, 20:13
  • Ярослав Давидяк

    Так как на скрине:https://photos.google.com/album/AF1QipNWyPB5FFCUM-Q8YU3pwOn6BFadk-l64F7UxQXm/photo/AF1QipNzrfy_KKAZotV01EdwTYIh9uEOwoHMSRsu8oPT
    2 пк из management справа? если да то как их связать?

    31 мая 2016, 16:26
  • Ярослав Давидяк

    file:///media/downloads/%D0%A5%D0%BB%D0%B0%D0%BC/%D0%A1%D0%94%D0%A1%D0%9C/Ask/Screenshot%20at%202016-05-31%2015:17:34.png

    31 мая 2016, 16:19
  • Анна Шихардина

    Ааааа! До меня дошло! Спасибо что задаёте вопросы и отвечаете на них! Дело в ответных пакетах))

    18 февраля 2016, 08:57
  • Этот маршрут мы прописываем только для того, что пакеты самого коммутатора могли быть отправлены — это не для транзитного трафика.

    То есть, например, не имея IP-адреса на узле, вы не сможете на него подключиться telnet’ом или даже просто отправить пинг. А если добавляем IP-адрес, то нужно и шлюз настроить — куда отправлять пакет в другую сеть.

    6 июля 2015, 12:04
  • Доброго времени суток!
    Хотел выразить Вам благодарность за колоссальный труд и спросить.
    Мне все равно не ясно.
    С данной маской у нас получается четыре адреса
    172.16.2.0 адрес сети
    172.16.2.1 первый адрес

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

    Спасибо!!!

    24 апреля 2015, 19:55
  • спасибо

    27 января 2014, 09:44
  • Оказалось, что в моей версии РТ одинаковые настройки на роутерах 2811 и 2620 дают разные результаты.
    на 2620 не работала сеть LAN, поменял на 2811 и всё поднялось.

    15 апреля 2015, 16:26
  • не удержался и сам во всем разобрался.
    Проблема оказалась в том, что Кемеровский Лаптоп оказался подключен к kmr-gorka-sw1 через транковый порт с одним разрешенным вланом 2 (LAN). Поменял trunk на access и всё заработало.
    только не спрашивайте как это повлияло на маршрутизацию между Kmr-gorka-gw1 и msk-arbat-gw1 :-). Сам в шоке.

    15 апреля 2015, 16:10
  • Я какой-то невежливый )
    Для начала хотелось бы сказать вам большое спасибо, очень крутой материал. Хорошая подача, и грамотно подготовленный материал делают ваши уроки более полезными, чем практику в вузах.
    Еще раз спасибо, парни! Вот от души )

    14 апреля 2015, 16:31
  • Привет. Кирилл.
    Стараюсь отвечать. Но сейчас я в Китае и с этим проблемы.

    Думаю, это связано с тем, что вы используете маршрутизаторы в качестве коммутаторов, а на них по умолчанию включена маршрутизация, соответственно команда «ip default gatewa» работать не будет. Исопльзуйте ip route 0.0.0.0 0.0.0.0

    29 марта 2015, 13:00
  • Разобрался) Почемуто приходится прописывать на коммутаторах «no ip routing» и тогда все начинает работать. Может подскажете почему у меня не так как у всех)

    28 марта 2015, 21:32
  • Ан нет) Прошу прощения все работает) Но почемуто не сразу.

    28 марта 2015, 21:28
  • Спасибо за замечание.
    Когда буду заниматься правкой статей, обязательно учту.

    4 февраля 2015, 20:30
  • Здравствуйте.
    Похвальное начинание.

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

    А почему бы и маршрутизатору не отбросить этот запрос?

    16 января 2015, 20:46
  • Спасибо

    14 января 2015, 22:09
  • Ну здорово же! Продолжайте 🙂

    14 января 2015, 20:44
  • класс всё заработало спасибо, и трассировка в обе стороны всё показывает ))))

    14 января 2015, 20:43
  • Тогда всё должно работать. 🙂 Проверяйте трассировкой в обе стороны.

    14 января 2015, 20:39
  • 172.16.1.1 =) что то я туго соображаю ))))

    14 января 2015, 20:37
  • Здравствуйте. А почему 172.16.1.5?

    14 января 2015, 20:31
  • Здравствуйте.

    Поскольку обе сети у вас подключены в один интерфейс маршрутизатора и идут через один коммутатор, без VLAN’ов никак.

    14 января 2015, 20:30
  • Николай, в декабре выпуск про MPLS. Приглашаю к чтению.

    16 ноября 2014, 19:48
  • L2VPN может быть предоставлен разными способами и конечная реализация действительно зависит от вашей договорённости с провайдером.
    Он может предоставить вам один единственный VLAN (услуга VPLS — Virtual Private LAN Servise), а может эмуляцию кабеля (VLL — Virtual Leased Line) — тогда уже через него вы что угодно можете пускать.

    12 ноября 2014, 05:46
  • при l2vpn вы ничего не согласовываете с провайдером. l2vpn между вашими двумя (тремя- десятью) офисами это все равно что вы воткнули эти два (три-десять) офисов в некий свич (l2 свич).

    12 ноября 2014, 00:33
  • Спасибо большое. Все прояснилось)

    12 ноября 2014, 00:35
  • Понято. Я начинающий) Из статьи понял что с провайдером нужно согласовывать номера вланов которые будут пропущены через l2vpn.

    Вообще говоря, номера вланов вам придётся согласовывать с вашим провайдером по той простой причине, что у него они могут быть просто заняты. Поэтому вполне возможно, что у вас будет влан, например, 2912 или 754. Но предположим, что нам повезло, и мы вольны сами выбирать номер.

    То есть я могу создать неограниченноеочень большое число вланов и пропустить через l2vpn провайдера согласовав с ним номера этиих вланов или же я могу пропустить только ограниченное число вланов которые опять же согласованы с провайдером?
    Хотя эти тонкости зависят, скорее всего, от конкретного провайдера…

    12 ноября 2014, 00:19
  • я тут немножко не понял. У вас с провайдером договоренность «l2vpn» или просто «интернет»? Если первое, то тогда вы (ну, теоретически при нормальном провайдере) можете пускать вланы через этот «wan» как вам хочется. если «интернет», то тогда вы, получается, сами организовываете канал между вашими офисами (по gre или по любому другому, на ваш выбор, протоколу)

    11 ноября 2014, 23:42
  • Просто я думал что если используем VPNL2 провайдера, то достаточно сложно наверное будет выпросить у него транк большого числа вланов…

    11 ноября 2014, 23:20
  • Ах, да. Точно. Спасибо большое за ответ.

    11 ноября 2014, 23:18
  • вы можете так сделать, безусловно. просто нужно разрешить транкам пересылать нужные вланы. Теперь по поводу целесообразности: вы действительно хотите пересылать весь бродкаст, которой будет внутри этого влана через wan? если да, то тогда целесообразно (ну просто мало ли, бывают таки ситуации). Но общая рекомендация: «держать вланы внутри сайта». Это означает в общем смысле, что лучше доверить это протоколу третьего уровня, чем второго. Проще: «Чем больше подсетей, тем лучше». Ну я так, совсем уж упростил, всегда есть варианты.

    11 ноября 2014, 23:10
  • Рад, что получилось.
    Извините, что не ответил раньше — активная подготовка к отдыху. 🙂

    15 сентября 2014, 19:30
  • вроде получилось, заработался и совсем забыл что нужно прописать маршрут на 2 маршрутизаторах. Большое спасибо Вам пойду в следующий урок

    14 сентября 2014, 17:55
  • Рад, что вы нашли ответ на свой вопрос. Извините, не мог ответить раньше.

    13 июля 2014, 16:22
  • Видимо, глюк РТ. На реальном я использовал эту команду. Правда только на некоторых железках.
    У циски хорошо ещё есть такая команда, а вот на Хуавэе к примеру каждую команду нужно удалять вручную. Это, конечно, сделано в целях защиты от ошибки, но дюже неудобно.

    13 июля 2014, 16:08
  • Либо ответ на мой вопрос никто не знает, либо игнорят все( Печально, в любом случае(

    28 июня 2014, 07:16
  • Это будет таки противоречить логике)

    25 июня 2014, 21:09
  • Ну, опять же, просто для того чтобы все было логично.

    25 июня 2014, 20:59
  • А чего ради такая избыточность? Для управления dsw1 вам достаточно одного IP.

    25 июня 2014, 20:52
  • Просто дело в том что 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 номер ринга.Просто для соблюдения логики.
    Я так понял в этом нет смысла?

    25 июня 2014, 20:50
  • Если dsw1 не выступает в роли L3-коммутатор, то на нём достаточного одного L3-интерфейса для управления. В остальных VLAN’ах поднимать IP не имеет смысла.

    25 июня 2014, 20:38
  • Ну, шлюз то не настраивается из конфигурации интерфейса, шлюз настраивается просто из режима конфигурации. А в интерфейсе влана можно настроить только айпишник и маску. Т.е. я на dsw1 добавлю интерфейс влан402 на нем настрою айпи и маску. При этом на этом же dsw1 я уже прописал комаду ip default-gateway 10.200.1.1 а он не из подсети 10.200.2.0/24

    25 июня 2014, 20:30
  • 🙂 Здорово.

    25 июня 2014, 20:25
  • Не понял вопрос.
    Появится новый интерфейс с новым IP. А на чём шлюз настроен?

    25 июня 2014, 20:25
  • А аватарку у вас подцепил. Стала моим рабочим девизом 🙂

    25 июня 2014, 20:17
  • Да уже разобрался, в чем проблема. В шлюзе по умолчанию.Настроил-все ок. Появился еще вопрос: к dsw1 хочу добавить еще одно кольцо свичей из подсети 10.200.2.0/24 не нем, соответственно, появится интерфейс влана 402 с IP 10.200.2.2 а шлюз на нем уже настроен: 10.200.1.1. Не станет ли это проблемой?

    25 июня 2014, 20:17
  • Маршрутизация между VLAN’ами у вас работает. А вот на коммутаторах кое-чего, скорее всего, не хватает. Сравните конфигурацию коммутатора с тем, как вы настраиваете ПК.

    P.S. Какая знакомая аватарка)

    25 июня 2014, 19:46
  • Ну вот в том же Packet Tracer для Catalyst 60 команда show interfaces показывает разные MAC-адреса — для каждого интерфейса свой. Вот это не совсем ясно. То, что для передачи данных управляемому коммутатору необходим какой-то MAC, это понятно, иначе он не сможет инкапсулировать IP-пакет в Ethernet-фрейм. Но зачем для каждого интерфейса у switch свой MAC? Разве одного не достаточно?

    19 июня 2014, 08:43
  • У любого устройства, которое может получать и передавать пакеты, должен быть MAC-адрес. Ведь что-то должно записываться в MAC-адрес получателя и отправителя? Как без MAC’а найти получателя?
    У коммутатора один системный MAC-адрес на все физические интерфейсы. То есть если он с любого порта отправит STP BPDU, то он поставит MAC-адрес, и он для всех портов будет одинаковый.
    Для виртуальных интерфейсов обычно используется тот же системный MAC-адрес. Но могут быть и особенности.

    19 июня 2014, 08:17
  • Боюсь, что я тут уже бессилен. Вопросы к Керию)

    26 мая 2014, 19:15
  • Демонстрация происходящего (для наглядности):

    26 мая 2014, 08:59
  • Собственно, вот и ответ) иногда всё работает не благодаря, а вопреки.

    21 мая 2014, 09:06
  • У меня тоже было только это предположение. Тогда он хитёр.
    Кстати с этой же проблемой есть ветка на форуме Kerio. Правда разработчики ничего не комментируют, т. к. тех поддержка платная.

    20 мая 2014, 10:03
  • К примеру, даже если пакет прилетел на интерфейс с другим ip (из другой подсети), он все-равно обрабатывает его как если бы пакет пришел на нужный интерфейс?

    20 мая 2014, 10:01
  • Выглядит, как проблема этого самого Kerio.
    Почему это работает? Возможно, потому, что MAC-то всё равно этого же самого устройства и в любом случае пакеты с коммутатора попадают на этот Kerio. А он волен поступать с ними как хочет.

    20 мая 2014, 09:42
  • Нет идей?)

    20 мая 2014, 08:19
  • Из около 200 компьютеров в сети на одном проявилась проблема отсутствия интернета. На нем выл мак неверного интерфейса. Почему все остальные работают для меня до сих пор загадка.

    18 мая 2014, 12:27
  • Да, это физически два разных интерфейса. А что записывается в таблицу надо проверить. Несколько дней назад попадало то одно, то другое.

    16 мая 2014, 02:44
  • Здравствуйте. А это два физически разных интерфейса, на которых руками прописаны IP на каждом?
    И что, кстати, в итоге попадает в ARP-таблицу?

    15 мая 2014, 20:11
  • От месяца до четырёх. Разумеется, не с утра до ночи.

    4 мая 2014, 19:40
  • Здравствуйте. Очень рад, что статьи помогают. Уже 31-го марта, кстати, новый выпуск СДСМ, посвящённый мультикасту.

    На коммутаторах вы настраиваете IP-адрес и будете иметь к нему доступ по telnet/ssh к этому IP-адресу. Для этого вы можете выделить специальный VLAN, как мы это сделали в Москве, а можете назначить свободный адрес из клиентского диапазона.

    25 марта 2014, 06:12
  • Здравствуйте. Огромное спасибо за такие шикарные статьи.! Спокойной можно перечитывать и пересматривать через время и находить в них то, что не знал!
    Плюс очень понятно и доступно подаете непростой материал! Именно Ваши статьи подтолкнули уйти в изучение сетей.
    Вопрос в продолжение вопроса об управлении…
    А как мы будем управлять коммутаторами в Питере и Кемерово?

    24 марта 2014, 03:11
  • Спасибо! Теперь более менее понятно.

    18 февраля 2014, 06:05
  • Здравствуйте.

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

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

    17 февраля 2014, 20:35
  • Делалось все в Cisco Packet Tracer, попробовал еще раз на этот раз vlan добавился во все таблицы

    6 февраля 2014, 10:25
  • 172.16.2.4 — это адрес сети. Полная запись в нотации CIDR: 172.16.2.4/30. В неё входят адреса 172.16.2.5 и 172.16.2.6, которые мы как раз-таки настраивали)

    24 января 2014, 19:19
  • Если по def-gev вы подразумеваете default-gateway, то да 🙂

    31 октября 2013, 17:47
  • Это было одним из домашних заданий и даже обсуждалось где-то в комментариях.
    Не хватает одной команды на коммутаторах.

    30 октября 2013, 19:35
  • Спасибо за помощь =)

    11 октября 2013, 17:49
  • Ну принадлежность разных протоколов действительно спорна. Ответ зависит от того, кому вы задаёте вопрос)

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

    Самый верный способ, Дункан — это RFC и дампы. Только там вы найдёте как реально должно быть и как реально есть (что тоже не всегда одно и то же.)

    11 октября 2013, 17:41
  • Хм, получается что в arp-ответ ставится широковещательный IP, но юникастовый mac? Если так, то я понял.
    Спасибо что помогли разобраться. Ресурсы все по этому вопросу пишут разные вещи, вплоть до того что arp протокол канального уровня.

    11 октября 2013, 17:38
  • Вы всё верно поняли. Почти всё — в ответном ARP он не может поставить юникастовый IP — его ещё нет на хосте.

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

    Аналогом можно, например назвать NHRP, хотя он только отдалённо похож.

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

    Есть ли аналог arp в не-Ethernet сетях?

    11 октября 2013, 11:07
  • ARP — это протокол сетевого уровня, по меньшей мере уже потому, что он использует IP.

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

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

    Говорить про него можно только в рамках Ethernet.

    11 октября 2013, 09:50
  • В комментарии выше всё верно. Желаю успеха.

    Спасибо за тёплые слова. Мне очень приятно осознавать, что наш труд полезен. 15-го октября будет выпуск по IBGP. Приглашаю)

    10 октября 2013, 10:43
  • Хочу выразить огромную благодарность за Ваш труд!
    Это великолепный материал и очень полезный. Постепенное усложнение решаемых задач вместе с доступностью изложения материала и наличием гиперссылок на связанные материалы влечет неизбежный прогресс в понимании принципов построения сети, а практические задачи дают опыт применения знаний.

    10 октября 2013, 10:34
  • На данный момент я вижу одно решение в том, чтобы изменить ip адрес 172.16.3.4 на 172.16.4.5 и все на свои места встанет. Замечу, что в плане адресов для ФЭО определены адреса 172.16.4.x. А х.х.4.5 потому, что далее приведен пример по ping’у этого адреса, которого в сети нет.

    10 октября 2013, 10:04
  • Здравствуйте.
    Если у вас есть одинаковые адреса в разных VLAN’ах, то они не будут конфликтовать, потому что находятся в разных широковещательных доменах. Другой вопрос в том, что шлюз у вас всё равно из другой подсети и маршрутизация работать не будет.

    9 октября 2013, 18:42
  • Здравствуйте.

    Попытаюсь дать подсказку.
    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
    Попробуйте настроить теперь)

    28 сентября 2013, 16:09
  • Думаю, скорее всего, проблема с РТ.

    22 сентября 2013, 21:14
  • Разобрался в проблеме, причиной была коммутатор, изначально коммутатор провайдера установил 2950T-24, после чего поставил 2960-24TT и сразу линк поднялся в сторону кемерово, так можете объяснить в чем именно подвох?

    22 сентября 2013, 20:33
  • Не поднимается линк — прям интерфейсы в состоянии Down? no shut сделали? Тип кабеля использовали правильный?

    22 сентября 2013, 20:09
  • Вы настроили сабинтерфейсы на маршрутизаторе? влан 101 прокинули между asw1 и dsw1?

    18 августа 2013, 10:50
  • conf t
    Switch(config)# ip default-gateway 172.16.1.1

    9 августа 2013, 14:06
  • О каком задании идёт речь и что именно непонятно?

    22 июля 2013, 22:19
  • Скажите пожалуйста как Вы настроили шлюзы по умолчанию для коммутаторов?

    18 июля 2013, 22:09
  • Попробуйте порешать наши <a href-«linkmeup.ru/challenges/»>задачки. Правда они пока про маршрутизацию.

    6 декабря 2012, 17:49
  • Напиши, пожалуйста, об этом в статье, потому что тоже убил минут 10 пока не догадался подцепить на порт ком.
    Спасибо за труды )

    7 июля 2013, 00:39
  • Спасибо, буду ждать! Не так уж и долго ждать осталось.
    По поводу интерфейсов, настраивал маршрутизаторы Микротик, там ситуация другая: если интерфейс административно поднят и на нем висит ip, то он доступен с самого рутера, не зависимо от наличия физического сигнала на интерфейсе. Видимо от вендора зависит. Ну и опять же на обычном ПК, если сетевая рабочая и адрес есть, то пинговать можно. Надо будет запомнить эту особенность цисок, дабы не попасть в просак.

    30 июня 2013, 11:24
  • Да, это стандартная ситуация. У вас ведь интерфейс находится в состоянии Down. Соответственно и его IP-адрес будет не доступен. В это и отличие, например, от Loopback-интерфейсов.

    Статья по мультикасту будет, но нескоро — не раньше конца 2013 года. Будет и IGMP и PIM-SM/PIM-DM, и практика с показом видео 🙂

    30 июня 2013, 08:06
  • ответил на почту

    13 мая 2013, 20:47
  • 1) Выложите файл PT и конфиги устройств куда-нибудь или вышлите их на info@linkmeup.ru. Странная ситуация, на самом деле.
    2) На вскидку не помню, посмотрю вечером.
    3) Не понял вопрос. Что значит «на какой из интерфейсов ( или подинтерфейсов ) заворачивать например msk-arbat-asw3 на роутере выше (msk-arbat-gw1)»?

    13 мая 2013, 07:56
  • Зачем нужны вланы — не самый простой вопрос для объснения. Но я точно скажу, что это приходит со временем.
    Это и ограничение широковещательных доменов и обеспечение безопасности и деление сети без необходимости выделять новые порты и «влан на абонента».
    Ну вот простой пример — у вас один свободный порт на маршрутизаторе, нужно подключить 3 корпоративных клиента так, чтобы между ними не ходил широковещательный трафик. Что будете делать?

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

    19 апреля 2013, 14:50
  • а зачем перекрестный? общее правило — перекрестным кабелем соединяются одинаковые виды оборудования: комп-комп или роутер-роутер. В остальных случаях прямой. К тому же, сейчас везде Auto-MDIX, так что прямой во всех случаях можно использовать.

    13 марта 2013, 07:25
  • Вам нужно смотреть не только на то, как пакет идёт к получателю, но и как он возвращается. Проследите его путь тщательно.

    3 марта 2013, 06:59
  • Здравствуйте. Тут хочется начать с того, что 17.0 и 25.0 — это не сети управления, это LAN данных филиалов. Просто в этом же LAN находятся коммутаторы.

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

    4 февраля 2013, 21:03
  • Ну вообще, да, вы правы. Для управления устройствами вообще нужно выделять отдельный влан, непересекающийся с данными пользователей. Об этом я где-то на этих страницах уже говорил.

    9 января 2013, 10:29
  • И вас с наступающим! 🙂

    31 декабря 2012, 07:57
  • Действительно, шлюз по умолчанию.
    Сильно меня заморочило с маршрутом по умолчанию.

    Спасибо! И с наступающими праздниками!)

    31 декабря 2012, 00:32
  • Мысль понял. Решение ip default-gateway

    30 декабря 2012, 22:36
  • Увы мне, я не верно поставил вопрос.
    Да и не посмотрел, что скопипастил в листинг %)

    При разборе домашнего задания, проблем с маршрутизацией в Москве и Кемерово не возникло,
    но появилась проблема в части «почему не пингуются устройства из сети управления».
    Анализ комментариев :), показал, что у коммутаторов не указан шлюз или маршрут по умолчанию,
    тем самым они прекрасно пингуются из сети 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)#

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

    Заранее благодарен.

    30 декабря 2012, 12:05
  • en
    conf t

    🙂

    30 декабря 2012, 05:22
  • Ответил в личку.

    14 декабря 2012, 09:00
  • Если не сложно, можете тоже ответ прислать.Как не старался, но не смог найти проблему.Хотя бы подсказку)

    13 декабря 2012, 17:08
  • Может сразу в статье давать ответ под спойлер?

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

    P.S. Еще раз спасибо за ваш титанический труд. С нетерпением жду статьи об OSPF.

    9 ноября 2012, 15:58
  • Такова специфика cisco. При включении 802.1q на порту в режиме транк, по умолчанию, пропускаются все кадры. А вот если вы явно зададите, например, vlan 5, то только кадры этого влана и будут пропускаться — остальные будут отброшены.
    Правильно, разумеется, указывать конкретные вланы — секьюрнее это, но в нашем примере, чтобы не заморачиваться с лишней настройкой, я решил ограничиться просто включением 802.1q.
    Кстати, не обольщайтесь — у других вендоров это может быть реализовано иначе. Например, в Хуавэй по умолчанию всё запрещено.

    12 декабря 2012, 06:03
  • Последний вопрос(На том-же коммуникаторе, в том же промежутке времени):
    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 Огромное спасибо за проделанную работу.Вы мне очень помогаете разобраться в сетях.А то читаешь книги, знания получаешь, а в итоге каша в голове как была, так и осталась.

    12 декабря 2012, 00:34
  • На 31:25 я меняю номер порта со стороны Москвы на fa0/3. Сначала я выбрал ошибочно fa0/24.

    11 декабря 2012, 16:59
  • Спасибо, все прекрасно заработало! Наверно, нужно было отвлечься и подумать на свежую голову, действительно все оказалось очень просто:)

    6 декабря 2012, 17:40
  • Ответ очень прост 🙂
    Когда вы настраивает параметры IP на компьютере, вы указываете IP — адрес, маску и шлюз по умолчанию. Что мы не настроили на коммутаторах?

    6 декабря 2012, 17:17
  • Спасибо большое за статью! Все очень доходчиво объяснено.
    Можно тоже как-то получить ответ на вопрос «почему не пингуются устройства из сети управления»?

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

    Спасибо на добром слове.

    9 ноября 2012, 16:32
  • Как бы вам ответить в личку, чтобы не все сразу увидели ответ?

    9 ноября 2012, 12:44

Ещё статьи

Задача №7.5
Схема: «GRE_over_IPSec»Конфигурация: прилагаетсяОписание проблемы:После настройки GRE over IPSec между R1 и R3, всё прекрасно работает, трафик между R1 и R3 (c 10.0.0.0 на 10.1.1.0) передается.Однако, через несколько дней, когда администратор ...
like 0 11806 5
27 февраля 2013
Большая уборка в СДСМ
Нам пишут, что половина картинок в статьях СДСМ уже потерялись, потому что хранились на яндекс-фотках, а гифки превратились в тыкву. И я (eucariot) уже думал, что от оформления и иллюстраций ...
like 0 1798 0
9 января 2023
Бесчеловечные сети
Статья опубликована на nag.ru и на habrahabr.ru. ======================== Когда-то управление автомобилем было почти искусством. Во времена славной классики (шестёрок и пятёрок) нужно было знать, как прочистить карбюратор, заменить топливный насос ...
like 0 15942 16
29 октября 2013