
- •Список vlan
- •План подключения оборудования по портам
- •Схемы сети
- •Порты доступа (access)
- •Транковые порты (trunk)
- •Сеть управления
- •Виды acl
- •Входящий и исходящий трафик
- •Практика
- •А) Доступ на web-сервер
- •Б)Доступ на файловый сервер
- •В) Доступ на почтовый сервер
- •Е) Права пользователей из сети Other
- •Ё) Сеть управления
- •Ж) Более никаких ограничений
- •Маска и обратная маска
- •Типы nat Статический
- •Динамический
- •Перенаправление портов
- •Слабости и силости nat
- •Практика nat
- •1) Сеть управления
- •2) Хосты из сети пто
- •3)Бухгалтерия
- •6) Филиалы в Санкт-Петербурге и Кемерово
- •7) Cервера
- •Б) Файловый сервер
- •В) Почтовый сервер
- •8) Доступ по rdp к компьютерам админа и нашему
- •Безопасность
- •Физика и логика процесса межвланной маршрутизации
- •Планирование расширения
- •Настройка
- •Москва. Арбат
- •Провайдер
- •Санкт-Петербург. Васильевский остров
- •Санкт-Петербург. Озерки
- •Кемерово. Красная горка
- •Дополнительно
- •Широковещательный шторм
- •Состояния портов
- •Виды stp
- •Агрегация каналов
- •Практика
Кемерово. Красная горка
Рассмотрим последний
небольшой пример — маршрутизатор на
палочке (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, которым мы посвятим
отдельный выпуск и, скорее всего, не
один. Но настройка статической
маршрутизации в значительной степени
поможет вашему общему пониманию
маршрутизации. В качестве самостоятельного
задания попробуйте настроить маршрутизацию
между Москвой и Кемерово и ответить на
вопрос, почему не пингуются устройства
из сети управления.
STP tutorial
проблему широковещательного шторма
работу и настройку протокола STP и его модификаций (RSTP, MSTP, PVST, PVST+)
технологию агрегации интерфейсов и перераспределения нагрузки между ними
некоторые вопросы стабильности и безопасности
как изменить схему существующей сети, чтобы всем было хорошо
В прошлом выпуске мы остановились на статической маршрутизации. Теперь надо сделать шаг в сторону и обсудить вопрос стабильности нашей сети. Однажды, когда вы — единственный сетевой админ фирмы “Лифт ми Ап” — отпросились на полдня раньше, вдруг упала связь с серверами, и директора не получили несколько важных писем. После короткой, но ощутимой взбучки вы идёте разбираться, в чём дело, а оказалось, по чьей-то неосторожности выпал из разъёма единственный кабель, ведущий к коммутатору в серверной. Небольшая проблема, которую вы могли исправить за две минуты, и даже вообще избежать, существенно сказалась на вашем доходе в этом месяце и возможностях роста. Итак, сегодня обсуждаем:
проблему широковещательного шторма
работу и настройку протокола STP и его модификаций (RSTP, MSTP, PVST, PVST+)
технологию агрегации интерфейсов и перераспределения нагрузки между ними
некоторые вопросы стабильности и безопасности
как изменить схему существующей сети, чтобы всем было хорошо
Оборудование, работающее на втором уровне модели OSI (коммутатор), должно выполнять 3 функции: запоминание адресов, перенаправление (коммутация) пакетов, защита от петель в сети. Разберем по пунктам каждую функцию. Запоминание адресов и перенаправление пакетов: Как мы уже говорили ранее, у каждого свича есть таблица сопоставления MAC-адресов и портов (aka CAM-table — Content Addressable Memory Table). Когда устройство, подключенное к свичу, посылает кадр в сеть, свич смотрит MAC-адрес отправителя и порт, откуда получен кадр, и добавляет эту информацию в свою таблицу. Далее он должен передать кадр получателю, адрес которого указан в кадре. По идее, информацию о порте, куда нужно отправить кадр, он берёт из этой же CAM-таблицы. Но, предположим, что свич только что включили (таблица пуста), и он понятия не имеет, в какой из его портов подключен получатель. В этом случае он отправляет полученный кадр во все свои порты, кроме того, откуда он был принят. Все конечные устройства, получив этот кадр, смотрят MAC-адрес получателя, и, если он адресован не им, отбрасывают его. Устройство-получатель отвечает отправителю, а в поле отправителя ставит свой адрес, и вот свич уже знает, что такой-то адрес находится на таком-то порту (вносит запись в таблицу), и в следующий раз уже будет переправлять кадры, адресованные этому устройству, только в этот порт. Чтобы посмотреть содержимое CAM-таблицы, используется команда show mac address-table. Однажды попав в таблицу, информация не остаётся там пожизненно, содержимое постоянно обновляется и если к определенному mac-адресу не обращались 300 секунд (по умолчанию), запись о нем удаляется. Тут всё должно быть понятно. Но зачем защита от петель? И что это вообще такое?