Статическая маршрутизация на Cisco
Содержание:
Маршрутизация в среде Cisco
Маршрутизация между двумя роутерами
Маршрутизация между VLAN
Маршрутизация между VLAN на коммутаторе (L3)
Дополнительно, более глубокая статья по теории и практике статической маршрутизации. А за данный пост спасибо сетям для самых маленьких, курсу статей, которые дают возможность кому угодно начать знакомство с теорией и практикой построения сетей.
Сейчас мы проделаем следующее:
1. Настраиваем маршрутизацию между вланами в нашей сети (InterVlan routing)
2. Пытаемся разобраться с процессами, происходящими в сети, и что творится с данными
3. Планируем расширение сети (IP-адреса, вланы, таблицы коммутации)
4. Настраиваем статическую маршрутизацию и разбираемся, как она работает
5. Используем L3-коммутатор в качестве шлюза
Ранее мы с вами создали несколько вланов в процессе настройки коммутаторов нашей локальной сети. Проблема сейчас в том, что хосты из разных вланов банально не видят друг друга. Серверная часть также существует где-то там совершенно обособленно. Исправим это.
В московском подразделении нашей шарообразной компании в вакууме будем использовать роутер Cisco 2811 для маршрутизации трафика между вланами.
Роутер будет терминировать вланы, в маршрутизаторе кадры заканчивают свою жизнь, из них извлекаются IP-пакеты, а заголовки с информацией канального уровня отбрасываются.
В принципе, настройка маршрутизатора не является особенно сложным процессом... Нет-нет, он очень сложный, но настройка для наших нужд в целом простая.
0. Сначала закончим с коммутатором msk-arbat-dsw1. На нём нам нужно настроить транковый порт в сторону маршрутизатора, чего мы не сделали в прошлый раз.
1. Назначаем имя маршрутизатора командой hostname, а для развития хорошего тона, надо упомянуть, что лучше сразу же настроить время на устройстве. Это поможет вам корректно идентифицировать записи в логах.
И да, желательно сразу настроить синхронизацию времени посредством NTP-сервера. Им может выступать сервис в интернете, коих много или же можно добавить данный функционал к одной из железок Cisco у вас в сети.
2. Теперь включим интерфейс, который смотрит в нашу локалку.
3. Создадим виртуальный интерфейс или иначе его называют подинтерфейс или ещё сабинтерфейс (sub-interface).
Что мы сейчас сделали? Всё довольно просто. Мы сначала указываем самым обычным образом физический интерфейс (fa0/0), к которому подключена нужная нам сеть, а после точки у нас будет стоять некий уникальный идентификатор этого виртуального интерфейса. Чтобы не запутаться и не взорвать свой мозг, дадим ему такой же номер, что и влану, который этот интерфейс терминирует.
4. Что еще... Ах да, как же стандарт 802.1q, забыли? Да-да, тот самый, который тегирует кадр меткой соответствующего влана. Теперь скажем маршрутизатору, чтобы он помечал кадры исходящие с этого виртуального интерфейса тегом 2-го влана. Соответственно, кадры входящие на физический интерфейс fa0/0 и имеющие тег 2 будут отправлены на виртуальный интерфейс fa0/0.2
Команда простейшая:
5. Навесим IP физическому L3-интерфейсу. Этот же IP будет являться шлюзом по-умолчанию (default gateway) для всех устройств в данном влане.
Точно также настраиваем остальные вланы. 101-ый, например:
Проверим, что из сети ПТО мы сможем увидеть сеть управления:
Абсолютно также настраиваются остальные интерфейсы.
Ранее мы говорили, что происходит с данными, передаваемыми в пределах одной подсети - т.е. хосты имеют IP-адреса в одном диапазоне, с одинаковой маской и одинаковым же шлюзом (GW, gateway).
Вот такой хост, например:
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. Ваш компьютер для начала отправляет широковещательный ARP-запрос, в пакет которого помещается IP-адрес искомого хоста, а вот MAC-адрес при инкапсуляции будет указан как FF:FF:FF:FF:FF:FF, то есть предназначаться всем устройствам в сети. Кадр уходит на ближайший коммутатор, где рассылается на все порты вашего влана (конечно, кроме порта-источника). Получатели принимают широковещательный запрос, т.к. могут оказаться искомым хостом и извлекают данные из кадра. Если IP из ARP-запроса не совпадает с IP хоста, то запрос спокойно игнорируется. А если IP совпал, то получатель вышлет запросившему свой MAC-адрес.
Отправитель поместит полученный MAC в таблицу соответствия IP и MAC, т.н. ARP-кэш.
Командой arp -a можно увидеть эту таблицу.
Отлично, теперь в наш полезный пакет информации помещается IP-адрес назначения, а при упаковке в Ethernet-кадр указывается взятый из ARP-кэша MAC-адрес. А дальше на коммутаторе данные отправляются на нужный порт в соответствии с MAC-таблицей этого коммутатора.
Но что если хосты находятся в разных вланах? В обычном случае ARP-запрос ничего нам не вернет, т.к. его не пропустит маршрутизатор за пределы искомого широковещательного L2-домена. Нужная сеть находится где-то там, за ним. А коммутатор тоже не пропустит кадры из одного влана в другой.
Для этого и нужен шлюз по-умолчанию (default gateway) на вашем компьютере. Если пакет предназначен для хоста в вашей подсети, то кадру навешивается метка с MAC-адресом конечного устройства и коммутатор отсылает его на соответствующий порт. Если же IP находится в любой другой подсети, то кадр отправляется на шлюз по-умолчанию и ему присваивается MAC destination маршрутизатора.
1. Устройство с IP 172.16.3.2/24 хочет отправить данные для ПК с IP 172.16.4.5.
Естественно, он видит, что IP находится в другой подсети, поэтому данные должны уйти на шлюз по-умолчанию. Что же делать? Тогда ПК нужен MAC-шлюза, и он делает запрос к своему ARP-кэшу, а там пусто!
2. Тогда ПК отправляет широковещательный 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-пакета, роутер узнаёт адрес получателя (DST, destination address), а из своей таблицы маршрутизации видит, что тот находится в непосредственно подключенной к нему сети (directly connected) на определённом сабинтерфейсе (в нашем случае FE0/0.102).
show ip route
10. Маршрутизатор отправляет ARP-запрос с этого сабинтерфейса — узнаёт MAC-адрес получателя.
11. Пришедший на роутер IP-пакет не изменяясь инкапсулируется уже в новый кадр. Какие у него отличия по сравнению с первоначальным?
• в качестве MAC-адреса источника указывается адрес интерфейса шлюза
• IP-адрес источника — адрес изначального хоста (в нашем случае 172.16.3.2)
• в качестве MAC-адреса получателя указывается адрес конечного хоста
• IP-адрес получателя — адрес конечного хоста (в нашем случае 172.16.4.5)
и отправляется в сеть с сабинтерфейса FastEthernet0/0.102, получая при этом метку 102-го влана.
12. И в итоге кадр доставляется коммутатором до конечного хоста, получателя.
На примере всё той же практической схемы будем двигаться далее. Сеть нашей компании растёт и перед нами встает задача подключить новых клиентов. Теперь всё будет выглядеть так:
То есть помимо Мск у нас появляются две точки в Спб и две в Кемерово. А для простоты представления всё это будет соединять один глобальный провайдер, который на выгодных тарифах предоставляет нам L2VPN. Позднее нужно будет рассказать об этом типе соединения подробнее, ну а пока грубо говоря скажем, что это VLAN проброшенный через коммутационную сеть провайдера.
Мы уже обсуждали IP-адресацию в самом начале, так что исходя из регламента распределим диапазоны вот таким образом:
Этот регламент крайне упрощенный, но мы теперь по крайней мере будем знать, что у шлюза всегда будет 1-ый адрес, IP-шники до 12-го мы выдадим различному сетевому оборудованию (типа коммутаторов и всяких WiFi-точек), диапазон 172.16.х.13-172.16.х.23 уйдет для серверов. Регламент можно сколько угодно дополнять и расширять по своему вкусу, вплоть до IP-адреса каждого хоста, добавлять в него правило формирования имён устройств, доменных имён, политику списков доступа и т.д. Чем точнее будет выстроена адресация, тем проще и удобнее впоследствии всё эксплуатировать и дебажить.
Теперь нужно составить IP-план для всех точек нашего присутствия. Использовать будем сети с маской 24 бита (255.255.255.0 или /24), в которых может быть максимум 254 устройства.
Можно было бы рассказать и про маски, но это будет далеко не в двух словах. Чтобы вникнуть, курните эту статью на хабре.
Резюмируем план, который составлялся в нулевом выпуске. Пул в Мск у нас 172.16.0.0-172.16.6.255, но под возможность расширения зарезервируем туда IP-адреса до 172.16.15.0/24 включительно. Пул адресов 172.16.0.0-172.16.15.255 кратко может быть представлен как 172.16.0.0/20. Данная сеть с префиксом /20 будет являться так называемой суперсетью, а операция объединения подсетей в суперсети называется суммированием подсетей (суммированием маршрутов, если быть точным, route summarization).
Для удобства существует множество IP-калькуляторов для расчета пулов и масок сетей, например вот этот.
С диапазоном в Мск мы разобрались, теперь перейдем к Спб. Там имеются две точки с подсетями 172.16.16.0/24 и 172.16.17.0/24, но мы зарезервируем адреса 172.16.18.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) будет у нас для Кемерово.
Делать всё вот так аккуратно, конечно, но обязательно, но... Если у вас несколько подряд идущих подсетей разбросаны по разным концам сети, то каждой из них соответствует одна запись в таблице маршрутизации каждого маршрутизатора. Если при этом вы вдруг используете только статическую маршрутизацию, то это ещё колоссальный труд по настройке и отслеживанию корректности настройки.
А если же они у вас все идут подряд, то несколько маленьких подсетей вы можете суммировать в одну большую.
Взглянем на наш с вами Питер:
Это 8 команд и 8 записей в таблице. Но при этом пришедший на маршрутизатор пакет в любую из сетей 172.16.16.0/21 в любом случае будет отправлен на устройство с адресом 172.16.2.2.
Вместо этого мы поступим так:
Коротко и ясно, так ведь куда удобнее? Раньше причиной такой рационализации была мощность процессоров у маршрутизаторов, а сейчас скорее правило хорошего тона. Но это больше исключение, т.к. фрагментация маршрутов с ростом сети вещь неизбежная.
Теперь ещё несколько слов о линковых сетях. В среде сетевых администраторов так называются сети точка-точка (Point-to-Point) между двумя маршрутизаторами.
Вот опять же в примере с Питером. Два маршрутизатора (в Москве и в Петербурге) соединены друг с другом прямым линком (неважно, что у провайдера это сотня коммутаторов и маршрутизаторов — для нас это просто влан). То есть кроме вот этих 2-х устройств здесь не будет никаких других. Мы знаем это наверняка. В любом случае на интерфейсах обоих устройств (смотрящих в сторону друг друга) нужно настраивать IP-адреса. И нам точно незачем назначать на этом участке сеть /24 с 254 доступными адресами, ведь 252 в таком случае пропадут почём зря. В этом случае есть прекрасный выход — бесклассовая IP-адресация.
Почему она бесклассовая? Если вы помните, то в нулевой части мы говорили о трёх классах подсетей: А, В и С. По идее только их вы и могли использовать при планировании сети. Бесклассовая междоменная маршрутизация (CIDR) позволяет очень гибко использовать пространство IP-адресов.
Берем самую маленькую сеть из 4 IP-адресов, это будет сетка с маской 30 (255.255.255.252). Совсем мелкая сеть 32 (255.255.255.255) нам не подойдет, т.к. состоит из 1 IP-адреса, а 31 (255.255.255.254) — это уже 2 адреса, но один из них (первый) — это адрес сети, а второй (последний) — широковещательный, поэтому на хосты у нас адресов не остается. Так что берем /30, где именно 2 адреса и остаются на наши маршрутизаторы.
Вообще говоря, самой узкой маской для подсетей в cisco таки является /31. При определённых условиях их можно использовать на P-t-P-линках.
Что же касается маски /32, то такие подсети, которые суть один единственный хост, используются для назначения адресов Loopback-интерфейсам.
Именно поэтому при подготовке мы зарезервировали сетку 172.16.2.0/24, которые распилим аж на 64 сети с размером /30. Их хватит на 64 линка.
Мы этого ждали, мы этого боялись, но вот мы пришли. Для чего нужен этот зверь страшный? Рассмотрим пример.
Я сижу перед ПК с IP 172.16.3.2, а моей задачей является получить доступ через телнет на L3-железку 172.16.17.1.
Откуда компьютеру знать, куда слать данные?
1. Этот момент мы уже обсуждали. Если IP получателя находится в другой подсети, то пакеты отправляются на шлюз по-умолчанию.
2. Следует ARP-запрос в ходе которого ПК узнает MAC-адрес маршрутизатора.
3. ПК создает кадр, в который инкапсулирует пакет информации и отправляет его по назначению. На маршрутизатор. А ПК уже тем временем выполнил свою работу, в дальнейшем он участия не принимает.
4. Кадр попадает на коммутатор, где исходя из таблицы MAC-адресов отправляется на маршрутизатор RT1.
5. Маршрутизатор ограничивает искомый широковещательный домен и поэтому изначальный кадр дальше уже не пройдет. Маршрутизатор откидывает заголовок канального уровня, ему нужен только пакет.
6. Задачей маршрутизатора является теперь принять решение, что делать с этим пакетом дальше. На какой интерфейс его отправлять?
Делать он это будет в соответствии с таблицей маршрутизации, которую можно посмотреть командой show ip route:
Каждая строка - это маршрут, способ добраться до той или иной конечной цели.
К примеру, пакет адресованный в сеть 172.16.17.0/24 отправится на IP 172.16.2.2.
Посмотрим поближе, из чего формируется таблица маршрутизации. Вариантов тут множество:
• Непосредственно подключенные сети (directly connected) — это сети, которые начинаются непосредственно на нём. В примере 172.16.3.0/24 и 172.16.2.0/30. В таблице они обозначаются буквой C;
• Статический маршруты (static route) — это те, которые вы прописали вручную командой ip route. Обозначаются буквой S;
• Маршруты, полученные с помощью протоколов динамической маршрутизации (OSPF, EIGRP, RIP, BGP и других).
7. В общем данные из сети 172.16.17.0 (мы же хотим приконнектиться к устройству 172.16.17.1) должны быть отправлены на следующий хоп, а этим следующим прыжком будет являться маршрутизатор 172.16.2.2. А таблица маршрутизации нам подсказывает, что этот IP находится за интерфейсом FE0/1.4 (подсеть 172.16.2.0/30)
8. Возможна ситуация, что в ARP-кэше циски нет соответствующего MAC-адреса устройства с IP 172.16.2.2, тогда следует выполнить ARP-запрос. RT1 посылает широковещательный кадр с порта FE0/1.4. В этом широковещательном домене присутствуют только два устройства, а значит получатель может быть только один. RT2 получает ARP-запрос, отбрасывает заголовок Ethernet и, понимая из данных протокола ARP, что искомый адрес принадлежит ему отправляет ARP-ответ со своим MAC-адресом.
9. Само собой, изначальный IP-пакет, пришедший от RT1 не меняется, просто инкапсулируется в совершенно новый кадр, который уйдет на интерфейс FE0/1.4, получив при этом метку VLAN 4.
10. Полностью аналогичные действия будут произведены на следующем маршрутизаторе. И далее на следующем, пока пакет не дойдет до крайнего маршрутизатора, к которому подключена искомая сеть.
11. Ну и последний маршрутизатор (хорошо-хорошо, в нашей практической задачке это L3-коммутатор) видит, что искомый IP-адрес принадлежит ему самому, извлекает данные транспортного уровня и понимает, что это telnet, передавая данные верхним уровням.
Таким образом путешествуют пакеты в сети от одного маршрутизатора к другому. При этом ни один маршрутизатор не знает дальнейшую судьбу пакета, он просто отправляет его дальше в соответствии со своей таблице маршрутизации.
Циска в Мск у нас имеет два интерфейса - FE0/0 смотрит в нашу локальную сеть, а FE0/1 используется для выхода в интернет и для подключения удаленных офисов. Для начала создадим саб-интерфейсы. Для Спб выделим VLAN 4, для Кемерово - 5. Адресация в соответствии с планом.
Теперь о настройке со стороны провайдера. В нашей практике позволим немного абстракции. Провайдер для нас может быть представлен в виде одного большого коммутатора. Какова будет настройка? В общем ничего сложного. Нужно принять транком линк с Арбата, а двумя другими портами отдадим их на удаленные узлы в Спб и Кемерово. Еще раз повторимся. Эти порты физически находятся на удалении в сотни километров, соединены сложной MPLS-сетью и только логически находятся "близко".
Наш игрушечный провайдер будет настроен таким образом:
В Питере у нас имеется железка spb-vsl-gw1, обратимся к ней.
Пусть FA0/0 смотрит в локалку, FA1/1 - на L3-коммутатор в Озерках, а вот FA1/0 будет у нас Uplink.
К слову по нумерации портов.
FastEthernet — это тип порта (Ethernet, Fastethernet, GigabitEthernet, POS, Serial или другие)
x/y/z.w=Slot/Sub-slot/Interface.Sub-interface.
Нужно договориться заранее как провайдер будет отдавать вам канал - транком или аксесом. В нашем примере мы решили, что это будет транк, т.к. чуть выше уже настроили коммутатор провайдера.
Добавим сюда локальную сеть:
Проверяем доступность адреса 172.16.2.2 с Москвы msk-arbat-gw1:
А вот 172.16.16.1 мы всё также не видим:
Конечно, ведь маршрутизатор не знает, куда ему слать пакет:
Надо это исправить:
Снова пробуем пинг-запросы:
Ура? Заработало? Не совсем. Проверяем связь с ПК:
Что за ерунда? Компьютер же знает, что пакет нужно отправлять на свой шлюз 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
Но тогда почему был пинг с 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, но тогда его придется прописывать и для других сетей. В Мск, потом в Кемерово, а при расширении сети еще черт знает где. Заметим, что выход в мир у нас получается через Мск, т.к. гейт в Озерки тупиковый, поэтому большая часть трафика все же будет идти в Москву (там и сетей большинство, и выход в интернет). И чем нам это поможет?
А вот чем.
Есть такое понятие как маршрут по-умолчанию (default route), он же "шлюз последней надежды".
Когда маршрутизатор решает, куда отправить пакет, он просматривает всё таблицу маршрутизации и, если не находит нужного маршрута, пакет отбрасывается — это если у вас не настроен шлюз последней надежды, если же настроен, то сиротливые пакеты отправляются именно туда — просто не глядя, предоставляя право уже следующему хопу решать их дальнейшую судьбу. То есть если некуда отправить, то последняя надежда — маршрут по умолчанию.
Настройка проста:
Проверяем!
Данная фича позволяет уменьшить сложность настройки и разгрузить таблицу маршрутизации отдельно взятых роутеров.
Настроим остальные маршрутизаторы. Санкт-Петербург. Озерки - в дальнейшем spb-ozerki-gw1.
Как мы помним у нас здесь L3-коммутатор, который для идеализации ситуации связан с spb-vsl-gw1 арендованным у провайдера волокном. Да, схема слишком идеальная, но о сложностях будем говорить в следующий раз.
Для начала ответим вопрос, зачем использовать коммутатор L3 уровня? Во-первых, интервлан роутинг в этом случае делается аппаратно и не нагружает процессор, в отличие от маршрутизатора. Во-вторых, один L3-коммутатор обойдётся вам значительно дешевле, чем L2-коммутатор и маршрутизатор по отдельности. Правда, в этом случае вы и полного функционала маршрутизатора не получите, поэтому заранее взвесьте все за и против.
Подготовим spb-vsl-gw1.
Для сети Озерков мы выделили 172.16.17.0/24, поэтому сразу настроим туда маршрут:
Объяснять следует? В качестве некст хопа мы указали IP-адрес интерфейса в Озерках - 172.16.2.6.
Теперь настраиваем железо в Озерках. Втыкаем на Васильевском острове кабель в spb-vsl-gw1: fa1/1 (порт уже настроен, как мы помним) и в 24-ый порт Cisco 3560 в Озерках. По дефолту все порты на ней работают в режиме обычного L2-свича, которые умеют во вланы. Но любой из них можно перевести в L3-режим, сделав портом маршрутизатора. Настраиваем на нем IP:
Пингуем:
Теперь настроим локальную сеть. Вендоры (в т.ч. циска) не рекомендуют использовать дефолтный влан, поэтому у нас будет VLAN 2.
Теперь все устройства во 2-ом влане будут иметь шлюзом 172.16.17.1:
И еще один магический пасс, превращающий коммутатор в почти маршрутизатор:
Тем самым мы включаем возможность маршрутизации. А маршрут нам понадобится только один, который по-умолчанию:
Проверяем связность с spb-vsl-gw1:
А вот с Москвой мы пока не подружились:
Конечно, дело тут в отсутствии маршрута. Воспользуемся трассировкой для локализации проблемы - traceroute.
От spb-vsl-gw1 ответ приходит, а дальше тишина, только мертвые с косами стоят. Существуют две самых очевидных вероятности:
> На хопе с адресом 172.16.2.5 не прописан маршрут в нужную сеть (но у нас там настроен маршрут по умолчанию, которого достаточно);
> Стоп... Или на следующем хопенет обратного маршрута?
И правда, отсутствует маршрут в сеть 172.16.17.0/24. Можно его взять и прописать, а можно подумать чуть подольше. Мы отгрузили в Питер сеть 172.16.16.0/21, поэтому достаточно прописать общий агрегированный маршрут:
Проверочка:
А теперь проверим доступность Москвы с spb-ozerki-gw1:
Нифига. А если в качестве source address указать 172.16.17.1:
Даже с ПК 172.16.17.26 он доступен:
Товарищи, да у нас проблемы с маршрутизацией!
Дело в том, что наш msk-arbat-gw1 прекрасно осведомлен о сети 172.16.17.0/24, а вот о 172.16.2.4/30 не имеет ни малейшего понятия. А именно IP 172.16.2.6 - адрес ближайшего к адресату интерфейса (имеется ввиду интерфейс, с которого отправляется IP-пакет - указывается в качестве источника, source address.
Вуаля.
Пропишем маршрут в подсеть 172.16.3.0/24 на роутере Васильевского острова не в Москву, а в Озерки.
Что произойдет? Образуется кольцо маршрутизации, сети 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 у заголовка будет уменьшаться на 1 со значения по-умолчанию 255. И когда TTL=0 маршрутизатор дропнет этот пакет. Это дает сети стабильность, не позволяя образовавшимся петлям существовать бесконечно до полного забивания канала.
А вот на канальном Ethernet-уровне такого механизма защиты нет, и при возникновении петли коммутатор будет плодить широковещательные (Broadcast) запросы до полного падения канала, что называется широковещательный шторм. Есть технология борьбы с этим - STP, но об этом позднее.
Очевидное следствие существования TTL - невозможность существования связной сети из более 255 маршрутизаторов. Но это и не требуется, т.к. даже самые длинные трейсы состоят максимум из 20-30 хопов.
А выглядит этот маршрутизатор таким образом:
Маршрутизатор связан с коммутатором одним кабелем, и посредством разных вланов внутри него передается и локальный и внешний трафик. Основная причина такого решения - обычно экономия средств. Ну один порт на маршрутизаторе, а покупать дополнительную плату или другой маршрутизатор накладно.
Подключение будет выглядеть так:
Настроим Uplink коммутатора. Помним, что договорились с провайдером на 5-ый влан транком.
Для локальной сети выберем VLAN 2. Ничего страшного, что такой уже имеется в Москве и Питере, они ведь не пересекаются, поэтому все в порядке. Тут как хотите, можете пилить для LAN один и тот же VLAN, а можете наделать уникальных VLAN ID.
Настроим транк в сторону маршрутизатора, там 5-ым вланом будут тегироваться кадры внешнего трафика, а 2-ым - локального.
Осталось настроить маршрутизатор:
Пара слов напоследок. Для траблшутинга, связанного с ошибками маршрутизации пользуйтесь командами traceroute и show ip route. В первом случае вам будет полезен адрес источника, а вторую можно применять с определенными параметрами. Например:
Да, в таблице маршрутизации нет записи по сети 172.16.17.0, но маршрутизатор покажет вам следующий хоп.
Также повторим важные вещи:
• Когда блок данных попадает на маршрутизатор, заголовок Ethernet полностью отбрасывается и при отправке формируется совершенно новый кадр. Но IP-пакет остаётся неизменным;
• Каждый маршрутизатор в случае статической маршрутизации принимает решение о судьбе пакета исключительно самостоятельно и не знает ничего о чужих таблицах;
• Поиск в таблице идёт НЕ до первой попавшейся подходящей записи, а до тех пор, пока не будет найдено самое точное соответствие (самая узкая маска). Например, если у вас таблица маршрутизации выглядит так:
И вы передаёте данные на 172.16.10.5, то он не пойдёт ни по маршруту через 172.16.2.22 ни через 172.16.2.26, а выберет самую узкую маску (самую длинную) /30 через 172.16.2.30.
• Если IP-адресу получателя не будет соответствовать ни одна запись в таблице маршрутизации и не настроен маршрут по умолчанию (шлюз последней надежды), пакет будет просто отброшен.
На этом первое знакомство с маршрутизацией можно закончить. Нам кажется, что читатель сам видит, сколько сложностей поджидает его здесь, может предположить, какой объём работы предстоит ему, если сеть разрастётся до нескольких десятков маршрутизаторов. Но надо сказать, что в современном мире статическая маршрутизация, не то чтобы не используется, конечно, ей есть место, но в подавляющем большинстве сетей, крупнее районного пионер-нета внедрены протоколы динамической маршрутизации. Среди них OSPF, EIGRP, IS-IS, RIP, которым мы посвятим отдельный выпуск и, скорее всего, не один. Но настройка статической маршрутизации в значительной степени поможет вашему общему пониманию маршрутизации.
Маршрутизация в среде Cisco
Маршрутизация между двумя роутерами
Маршрутизация между VLAN
Маршрутизация между VLAN на коммутаторе (L3)
Маршрутизация в среде Cisco
Маршрутизация между двумя роутерами
Маршрутизация между VLAN
Маршрутизация между VLAN на коммутаторе (L3)
Теория и практика
статической маршрутизации в среде Cisco
статической маршрутизации в среде Cisco
Дополнительно, более глубокая статья по теории и практике статической маршрутизации. А за данный пост спасибо сетям для самых маленьких, курсу статей, которые дают возможность кому угодно начать знакомство с теорией и практикой построения сетей.
Мальчик сказал маме: “Я хочу кушать”. Мама отправила его к папе.
Мальчик сказал папе: “Я хочу кушать”. Папа отправил его к маме.
Мальчик сказал маме: “Я хочу кушать”. Мама отправила его к папе.
И бегал так мальчик, пока в один момент не упал.
Что случилось с мальчиком? TTL кончился.
Мальчик сказал папе: “Я хочу кушать”. Папа отправил его к маме.
Мальчик сказал маме: “Я хочу кушать”. Мама отправила его к папе.
И бегал так мальчик, пока в один момент не упал.
Что случилось с мальчиком? TTL кончился.
Сейчас мы проделаем следующее:
1. Настраиваем маршрутизацию между вланами в нашей сети (InterVlan routing)
2. Пытаемся разобраться с процессами, происходящими в сети, и что творится с данными
3. Планируем расширение сети (IP-адреса, вланы, таблицы коммутации)
4. Настраиваем статическую маршрутизацию и разбираемся, как она работает
5. Используем L3-коммутатор в качестве шлюза
InterVlan Routing
Ранее мы с вами создали несколько вланов в процессе настройки коммутаторов нашей локальной сети. Проблема сейчас в том, что хосты из разных вланов банально не видят друг друга. Серверная часть также существует где-то там совершенно обособленно. Исправим это.
В московском подразделении нашей шарообразной компании в вакууме будем использовать роутер Cisco 2811 для маршрутизации трафика между вланами.
Роутер будет терминировать вланы, в маршрутизаторе кадры заканчивают свою жизнь, из них извлекаются IP-пакеты, а заголовки с информацией канального уровня отбрасываются.
В принципе, настройка маршрутизатора не является особенно сложным процессом... Нет-нет, он очень сложный, но настройка для наших нужд в целом простая.
0. Сначала закончим с коммутатором msk-arbat-dsw1. На нём нам нужно настроить транковый порт в сторону маршрутизатора, чего мы не сделали в прошлый раз.
msk-arbat-dsw1(config)#interface FastEthernet0/24
msk-arbat-dsw1(config-if)# description msk-arbat-gw1
msk-arbat-dsw1(config-if)# switchport trunk allowed vlan 2-3,101-104
msk-arbat-dsw1(config-if)# switchport mode trunk1. Назначаем имя маршрутизатора командой hostname, а для развития хорошего тона, надо упомянуть, что лучше сразу же настроить время на устройстве. Это поможет вам корректно идентифицировать записи в логах.
Router0#clock set 10:19:05 14 january 2018
Router0# conf t
Router0(config)#hostname msk-arbat-gw1И да, желательно сразу настроить синхронизацию времени посредством NTP-сервера. Им может выступать сервис в интернете, коих много или же можно добавить данный функционал к одной из железок Cisco у вас в сети.
2. Теперь включим интерфейс, который смотрит в нашу локалку.
msk-arbat-gw1(config)#interface fastEthernet 0/0
msk-arbat-gw1(config-if)#no shutdown 3. Создадим виртуальный интерфейс или иначе его называют подинтерфейс или ещё сабинтерфейс (sub-interface).
msk-arbat-gw1(config)#interface fa0/0.2
msk-arbat-gw1(config-if)#description ManagementЧто мы сейчас сделали? Всё довольно просто. Мы сначала указываем самым обычным образом физический интерфейс (fa0/0), к которому подключена нужная нам сеть, а после точки у нас будет стоять некий уникальный идентификатор этого виртуального интерфейса. Чтобы не запутаться и не взорвать свой мозг, дадим ему такой же номер, что и влану, который этот интерфейс терминирует.
4. Что еще... Ах да, как же стандарт 802.1q, забыли? Да-да, тот самый, который тегирует кадр меткой соответствующего влана. Теперь скажем маршрутизатору, чтобы он помечал кадры исходящие с этого виртуального интерфейса тегом 2-го влана. Соответственно, кадры входящие на физический интерфейс fa0/0 и имеющие тег 2 будут отправлены на виртуальный интерфейс fa0/0.2
Команда простейшая:
msk-arbat-gw1(config-if)#encapsulation dot1Q 25. Навесим IP физическому 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Проверим, что из сети ПТО мы сможем увидеть сеть управления:
Абсолютно также настраиваются остальные интерфейсы.
Логика процесса маршрутизации между VLAN.
Ранее мы говорили, что происходит с данными, передаваемыми в пределах одной подсети - т.е. хосты имеют IP-адреса в одном диапазоне, с одинаковой маской и одинаковым же шлюзом (GW, gateway).
Вот такой хост, например:
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. Ваш компьютер для начала отправляет широковещательный ARP-запрос, в пакет которого помещается IP-адрес искомого хоста, а вот MAC-адрес при инкапсуляции будет указан как FF:FF:FF:FF:FF:FF, то есть предназначаться всем устройствам в сети. Кадр уходит на ближайший коммутатор, где рассылается на все порты вашего влана (конечно, кроме порта-источника). Получатели принимают широковещательный запрос, т.к. могут оказаться искомым хостом и извлекают данные из кадра. Если IP из ARP-запроса не совпадает с IP хоста, то запрос спокойно игнорируется. А если IP совпал, то получатель вышлет запросившему свой MAC-адрес.
Отправитель поместит полученный MAC в таблицу соответствия IP и MAC, т.н. ARP-кэш.
Командой arp -a можно увидеть эту таблицу.
Отлично, теперь в наш полезный пакет информации помещается IP-адрес назначения, а при упаковке в Ethernet-кадр указывается взятый из ARP-кэша MAC-адрес. А дальше на коммутаторе данные отправляются на нужный порт в соответствии с MAC-таблицей этого коммутатора.
Но что если хосты находятся в разных вланах? В обычном случае ARP-запрос ничего нам не вернет, т.к. его не пропустит маршрутизатор за пределы искомого широковещательного L2-домена. Нужная сеть находится где-то там, за ним. А коммутатор тоже не пропустит кадры из одного влана в другой.
Для этого и нужен шлюз по-умолчанию (default gateway) на вашем компьютере. Если пакет предназначен для хоста в вашей подсети, то кадру навешивается метка с MAC-адресом конечного устройства и коммутатор отсылает его на соответствующий порт. Если же IP находится в любой другой подсети, то кадр отправляется на шлюз по-умолчанию и ему присваивается MAC destination маршрутизатора.
1. Устройство с IP 172.16.3.2/24 хочет отправить данные для ПК с IP 172.16.4.5.
Естественно, он видит, что IP находится в другой подсети, поэтому данные должны уйти на шлюз по-умолчанию. Что же делать? Тогда ПК нужен MAC-шлюза, и он делает запрос к своему ARP-кэшу, а там пусто!
2. Тогда ПК отправляет широковещательный 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-пакета, роутер узнаёт адрес получателя (DST, destination address), а из своей таблицы маршрутизации видит, что тот находится в непосредственно подключенной к нему сети (directly connected) на определённом сабинтерфейсе (в нашем случае FE0/0.102).
show ip route
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.10410. Маршрутизатор отправляет ARP-запрос с этого сабинтерфейса — узнаёт MAC-адрес получателя.
11. Пришедший на роутер IP-пакет не изменяясь инкапсулируется уже в новый кадр. Какие у него отличия по сравнению с первоначальным?
• в качестве MAC-адреса источника указывается адрес интерфейса шлюза
• IP-адрес источника — адрес изначального хоста (в нашем случае 172.16.3.2)
• в качестве MAC-адреса получателя указывается адрес конечного хоста
• IP-адрес получателя — адрес конечного хоста (в нашем случае 172.16.4.5)
и отправляется в сеть с сабинтерфейса FastEthernet0/0.102, получая при этом метку 102-го влана.
12. И в итоге кадр доставляется коммутатором до конечного хоста, получателя.
Планирование расширения
На примере всё той же практической схемы будем двигаться далее. Сеть нашей компании растёт и перед нами встает задача подключить новых клиентов. Теперь всё будет выглядеть так:
То есть помимо Мск у нас появляются две точки в Спб и две в Кемерово. А для простоты представления всё это будет соединять один глобальный провайдер, который на выгодных тарифах предоставляет нам L2VPN. Позднее нужно будет рассказать об этом типе соединения подробнее, ну а пока грубо говоря скажем, что это VLAN проброшенный через коммутационную сеть провайдера.
Мы уже обсуждали IP-адресацию в самом начале, так что исходя из регламента распределим диапазоны вот таким образом:
Этот регламент крайне упрощенный, но мы теперь по крайней мере будем знать, что у шлюза всегда будет 1-ый адрес, IP-шники до 12-го мы выдадим различному сетевому оборудованию (типа коммутаторов и всяких WiFi-точек), диапазон 172.16.х.13-172.16.х.23 уйдет для серверов. Регламент можно сколько угодно дополнять и расширять по своему вкусу, вплоть до IP-адреса каждого хоста, добавлять в него правило формирования имён устройств, доменных имён, политику списков доступа и т.д. Чем точнее будет выстроена адресация, тем проще и удобнее впоследствии всё эксплуатировать и дебажить.
IP-план
Теперь нужно составить IP-план для всех точек нашего присутствия. Использовать будем сети с маской 24 бита (255.255.255.0 или /24), в которых может быть максимум 254 устройства.
Можно было бы рассказать и про маски, но это будет далеко не в двух словах. Чтобы вникнуть, курните эту статью на хабре.
Резюмируем план, который составлялся в нулевом выпуске. Пул в Мск у нас 172.16.0.0-172.16.6.255, но под возможность расширения зарезервируем туда IP-адреса до 172.16.15.0/24 включительно. Пул адресов 172.16.0.0-172.16.15.255 кратко может быть представлен как 172.16.0.0/20. Данная сеть с префиксом /20 будет являться так называемой суперсетью, а операция объединения подсетей в суперсети называется суммированием подсетей (суммированием маршрутов, если быть точным, route summarization).
Для удобства существует множество IP-калькуляторов для расчета пулов и масок сетей, например вот этот.
С диапазоном в Мск мы разобрались, теперь перейдем к Спб. Там имеются две точки с подсетями 172.16.16.0/24 и 172.16.17.0/24, но мы зарезервируем адреса 172.16.18.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-адресов.
Берем самую маленькую сеть из 4 IP-адресов, это будет сетка с маской 30 (255.255.255.252). Совсем мелкая сеть 32 (255.255.255.255) нам не подойдет, т.к. состоит из 1 IP-адреса, а 31 (255.255.255.254) — это уже 2 адреса, но один из них (первый) — это адрес сети, а второй (последний) — широковещательный, поэтому на хосты у нас адресов не остается. Так что берем /30, где именно 2 адреса и остаются на наши маршрутизаторы.
Вообще говоря, самой узкой маской для подсетей в cisco таки является /31. При определённых условиях их можно использовать на P-t-P-линках.
Что же касается маски /32, то такие подсети, которые суть один единственный хост, используются для назначения адресов Loopback-интерфейсам.
Именно поэтому при подготовке мы зарезервировали сетку 172.16.2.0/24, которые распилим аж на 64 сети с размером /30. Их хватит на 64 линка.
Принципы маршрутизации
Мы этого ждали, мы этого боялись, но вот мы пришли. Для чего нужен этот зверь страшный? Рассмотрим пример.
Я сижу перед ПК с IP 172.16.3.2, а моей задачей является получить доступ через телнет на L3-железку 172.16.17.1.
Откуда компьютеру знать, куда слать данные?
1. Этот момент мы уже обсуждали. Если IP получателя находится в другой подсети, то пакеты отправляются на шлюз по-умолчанию.
2. Следует ARP-запрос в ходе которого ПК узнает MAC-адрес маршрутизатора.
3. ПК создает кадр, в который инкапсулирует пакет информации и отправляет его по назначению. На маршрутизатор. А ПК уже тем временем выполнил свою работу, в дальнейшем он участия не принимает.
4. Кадр попадает на коммутатор, где исходя из таблицы MAC-адресов отправляется на маршрутизатор RT1.
5. Маршрутизатор ограничивает искомый широковещательный домен и поэтому изначальный кадр дальше уже не пройдет. Маршрутизатор откидывает заголовок канального уровня, ему нужен только пакет.
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 отправится на IP 172.16.2.2.
Посмотрим поближе, из чего формируется таблица маршрутизации. Вариантов тут множество:
• Непосредственно подключенные сети (directly connected) — это сети, которые начинаются непосредственно на нём. В примере 172.16.3.0/24 и 172.16.2.0/30. В таблице они обозначаются буквой C;
• Статический маршруты (static route) — это те, которые вы прописали вручную командой ip route. Обозначаются буквой S;
• Маршруты, полученные с помощью протоколов динамической маршрутизации (OSPF, EIGRP, RIP, BGP и других).
7. В общем данные из сети 172.16.17.0 (мы же хотим приконнектиться к устройству 172.16.17.1) должны быть отправлены на следующий хоп, а этим следующим прыжком будет являться маршрутизатор 172.16.2.2. А таблица маршрутизации нам подсказывает, что этот IP находится за интерфейсом FE0/1.4 (подсеть 172.16.2.0/30)
8. Возможна ситуация, что в ARP-кэше циски нет соответствующего MAC-адреса устройства с IP 172.16.2.2, тогда следует выполнить ARP-запрос. RT1 посылает широковещательный кадр с порта FE0/1.4. В этом широковещательном домене присутствуют только два устройства, а значит получатель может быть только один. RT2 получает ARP-запрос, отбрасывает заголовок Ethernet и, понимая из данных протокола ARP, что искомый адрес принадлежит ему отправляет ARP-ответ со своим MAC-адресом.
9. Само собой, изначальный IP-пакет, пришедший от RT1 не меняется, просто инкапсулируется в совершенно новый кадр, который уйдет на интерфейс FE0/1.4, получив при этом метку VLAN 4.
10. Полностью аналогичные действия будут произведены на следующем маршрутизаторе. И далее на следующем, пока пакет не дойдет до крайнего маршрутизатора, к которому подключена искомая сеть.
11. Ну и последний маршрутизатор (хорошо-хорошо, в нашей практической задачке это L3-коммутатор) видит, что искомый IP-адрес принадлежит ему самому, извлекает данные транспортного уровня и понимает, что это telnet, передавая данные верхним уровням.
Таким образом путешествуют пакеты в сети от одного маршрутизатора к другому. При этом ни один маршрутизатор не знает дальнейшую судьбу пакета, он просто отправляет его дальше в соответствии со своей таблице маршрутизации.
Настройка
Циска в Мск у нас имеет два интерфейса - FE0/0 смотрит в нашу локальную сеть, а FE0/1 используется для выхода в интернет и для подключения удаленных офисов. Для начала создадим саб-интерфейсы. Для Спб выделим VLAN 4, для Кемерово - 5. Адресация в соответствии с планом.
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Теперь о настройке со стороны провайдера. В нашей практике позволим немного абстракции. Провайдер для нас может быть представлен в виде одного большого коммутатора. Какова будет настройка? В общем ничего сложного. Нужно принять транком линк с Арбата, а двумя другими портами отдадим их на удаленные узлы в Спб и Кемерово. Еще раз повторимся. Эти порты физически находятся на удалении в сотни километров, соединены сложной 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, обратимся к ней.
Пусть FA0/0 смотрит в локалку, FA1/1 - на L3-коммутатор в Озерках, а вот FA1/0 будет у нас Uplink.
К слову по нумерации портов.
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Проверяем доступность адреса 172.16.2.2 с Москвы msk-arbat-gw1:
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, но тогда его придется прописывать и для других сетей. В Мск, потом в Кемерово, а при расширении сети еще черт знает где. Заметим, что выход в мир у нас получается через Мск, т.к. гейт в Озерки тупиковый, поэтому большая часть трафика все же будет идти в Москву (там и сетей большинство, и выход в интернет). И чем нам это поможет?
А вот чем.
Есть такое понятие как маршрут по-умолчанию (default route), он же "шлюз последней надежды".
Когда маршрутизатор решает, куда отправить пакет, он просматривает всё таблицу маршрутизации и, если не находит нужного маршрута, пакет отбрасывается — это если у вас не настроен шлюз последней надежды, если же настроен, то сиротливые пакеты отправляются именно туда — просто не глядя, предоставляя право уже следующему хопу решать их дальнейшую судьбу. То есть если некуда отправить, то последняя надежда — маршрут по умолчанию.
Настройка проста:
spb-vsl-gw1(config)#ip route 0.0.0.0 0.0.0.0 172.16.2.1Проверяем!
Данная фича позволяет уменьшить сложность настройки и разгрузить таблицу маршрутизации отдельно взятых роутеров.
Настроим остальные маршрутизаторы. Санкт-Петербург. Озерки - в дальнейшем spb-ozerki-gw1.
Как мы помним у нас здесь L3-коммутатор, который для идеализации ситуации связан с spb-vsl-gw1 арендованным у провайдера волокном. Да, схема слишком идеальная, но о сложностях будем говорить в следующий раз.
Для начала ответим вопрос, зачем использовать коммутатор L3 уровня? Во-первых, интервлан роутинг в этом случае делается аппаратно и не нагружает процессор, в отличие от маршрутизатора. Во-вторых, один L3-коммутатор обойдётся вам значительно дешевле, чем L2-коммутатор и маршрутизатор по отдельности. Правда, в этом случае вы и полного функционала маршрутизатора не получите, поэтому заранее взвесьте все за и против.
Подготовим spb-vsl-gw1.
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Объяснять следует? В качестве некст хопа мы указали IP-адрес интерфейса в Озерках - 172.16.2.6.
Теперь настраиваем железо в Озерках. Втыкаем на Васильевском острове кабель в spb-vsl-gw1: fa1/1 (порт уже настроен, как мы помним) и в 24-ый порт Cisco 3560 в Озерках. По дефолту все порты на ней работают в режиме обычного 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Теперь настроим локальную сеть. Вендоры (в т.ч. циска) не рекомендуют использовать дефолтный влан, поэтому у нас будет VLAN 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Теперь все устройства во 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 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
И правда, отсутствует маршрут в сеть 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)Нифига. А если в качестве source address указать 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 не имеет ни малейшего понятия. А именно IP 172.16.2.6 - адрес ближайшего к адресату интерфейса (имеется ввиду интерфейс, с которого отправляется IP-пакет - указывается в качестве источника, source address.
Вуаля.
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 у заголовка будет уменьшаться на 1 со значения по-умолчанию 255. И когда TTL=0 маршрутизатор дропнет этот пакет. Это дает сети стабильность, не позволяя образовавшимся петлям существовать бесконечно до полного забивания канала.
А вот на канальном Ethernet-уровне такого механизма защиты нет, и при возникновении петли коммутатор будет плодить широковещательные (Broadcast) запросы до полного падения канала, что называется широковещательный шторм. Есть технология борьбы с этим - STP, но об этом позднее.
Очевидное следствие существования TTL - невозможность существования связной сети из более 255 маршрутизаторов. Но это и не требуется, т.к. даже самые длинные трейсы состоят максимум из 20-30 хопов.
Маршрутизатор на палочке (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. Ничего страшного, что такой уже имеется в Москве и Питере, они ведь не пересекаются, поэтому все в порядке. Тут как хотите, можете пилить для LAN один и тот же VLAN, а можете наделать уникальных VLAN ID.
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, которым мы посвятим отдельный выпуск и, скорее всего, не один. Но настройка статической маршрутизации в значительной степени поможет вашему общему пониманию маршрутизации.
Маршрутизация в среде Cisco
Маршрутизация между двумя роутерами
Маршрутизация между VLAN
Маршрутизация между VLAN на коммутаторе (L3)
Посетители, находящиеся в группе Гости, не могут оставлять комментарии к данной публикации.