По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
FHRP (Протокол резервирования первого перехода) - это группа протоколов способные обеспечить клиентов отказоустойчивым шлюзом.
Что за первый переход такой?. У нас есть коммутируемая среда (SW1) и есть Internet . Internet это маршрутизируемая среда . И для того чтобы перейти из коммутируемой среды , в маршрутизируемую среду для того чтобы выйти в интернет , как раз эти роутеры(R1,R2,VR - Virtual Router) обеспечивают данный переход и для того ,чтобы обеспечить отказоустойчивость этого перехода , его нужно резервировать . А потому и называется протоколы резервирования первого перехода.
И все протоколы группы FHRP будут работать в единой логике: R1 , R2 будут прикидываться VR и в случае отказа одного из маршрутизаторов, то его работу возьмет другой.
Forwarding Router ( FR ) - это роутер ,который данный момент активен и маршрутизирует трафик .
Standby Router ( SR ) - это роутер ,который стоит в резерве и ждет , когда накроется FR ,чтобы перехватите его работу на себя , в случае сбоя маршрутизатора.
FHRPs - это группа ,а значит пришло время познакомить вас с этими протоколами.
HSRP (Hot Standby Router Protocol) - Проприетарный протокол разработанный Cisco;
VRRP (Virtual Router Redundancy Protocol) - Свободный протокол ,сделан на основе HSRP;
GLBP (Gateway Load Balancing Protocol) - Проприетарный протоколCisco , обеспечивающий распределение нагрузки на несколько маршрутизаторов( шлюзов) используя 1 виртуальный адрес.
CARP( Common Address Redundancy Protocol) - свободный , разработан как часть OpenBSD , портирован во FreeBSD.
Итак начнём с HSRP
Протокол HSRP рассчитан на 2 роутера, 3 это уже лишний и с этим уже справиться протокол GLBP
Предположим ,что R1 это маршрутизатор выхода в интернет и для этого мы поднимем на нём Loopback 1 с адресом 200.200.200.200 и пропишем его в маршруте по умолчанию. Между маршрутизаторами будет настроен RIPv2 и будут анонсированы 2 классовые сети( network 10.0.0.0 и network 192.168.0.0) для простоты анонсирования маршрутов.
R2,R1 настраивается также. А теперь по порядку , настроим HSRP:
R1(config)# interface e 0/0 - переходим на интерфейс ethernet 0/0 (этот интерфейс смотрит в локальную сеть на коммутатор )
R1(config-if)# ip address 192.168.0.2 255.255.255.0 - задаем ip адрес для физического интерфейса
R1(config-if)# standby 1 ip 192.168.0.254 - задаем виртуальный ip адрес (который будет основным шлюзом для свитчей, смотрящих на конфигурируемый роутер). У обоих роутеров он одинаковый
R1(config-if)# stanby 1 priority 110 - устанавливаем приоритет данного роутера в 110 (по умолчанию приоритет 100)
R1(config-if)# standby 1 preempt - задаем режим приемтинга
R1(config-if)# standby 1 authentication md5 key-string MyPassword - задаем аутентификацию, если необходимо. Пароль будет передаваться с защитой алгоритмом хеширования md5, пароль будет MyPassword
R1(config-if)# standby 1 timers 100 255 - регулировка таймеров hsrp, где 100 - hello интервал в секундах (как часто посылаются пакеты hello пакеты keep-alive) и 255 - hold interval в секундах (через какой промежуток времени признавать соседа недоступным)
R1(config-if)# standby 1 preempt delay minimum 300 - настройка времени задержки (в секундах), через которое роутер будет становиться главным. Эта команда требуется для того,чтобы сначала отработали другие протоколы,прежде чем заработает HSRP . Пример: OSPF включенный на роутере в большой сети не успеет передать маршруты все ,а тут сразу заработает HSRP ,естественно он знать все маршруты не будет,а значить и стабильно гнать трафик тоже. Как раз время delay он будет использовать для того,чтобы дать OSPF передать все маршруты и после этого вкл HSRP.
Сам VPC должен получить следующие настройки: IP : 192.168.0.10/24 GW: 192.168.0.254
Главное ,чтобы клиент был в одной подсети и в качестве шлюза был виртуальный IP адрес.
TRACKING
Также полезно вешать TRACK на интерфейсы ,так как HSRP работает только в сторону ,куда направлен интерфейс ,то он не сможет отработать,когда упадут линки ,смотрящие на роутеры выше.(в данном случае это R3)
Router(config)# track 1 interface fa0/1 line-protocol - отслеживаем состояние интерфейса fa0/1, если он падает, то сработает объект отслеживания track 1.
Router(config-if)# standby 1 track 1 decrement 15 - если сработает объект отслеживания track 1, то текущий приоритет будет понижен на 15 единиц.
Router(config-if)# standby 1 track 1 fa0/1 20 - работает только в HSRP. Позволяет отслеживать интерфейс без дополнительного создания объекта отслеживания.
R1,R2,R0 будут настраиваться одинаково, принцип сохраняется.
А теперь нюансы HSRP
При работе нескольких VLAN , HSRP может идти трафик не совсем рационально из-за протокола STP. Представим ,что R1 это root primary за 10 VLAN, а R2 это ACTIVE router в HSRP . Это значит ,что любой трафик за этот VLAN будет идти следующим образом:VPC - R2 - R1 - R3 вместо того,чтобы идти напрямую VPC - R1 - R3. (L2 трафик всегда ходит через root во избежание петель)
Поэтому рекомендуют использовать HSRP version 2(по умолчанию вкл 1 максимум 255 процессов,а во 2 их 4095) и использовать наилучший приоритет для того роутера, который сейчас в сети root primary за текущий VLAN. И хорошей практикой будет если номер VLAN будет совпадать с номером процесса HSRP. ( № HSRP = VLAN )
3 Роутера в HSRP не имеет смысла держать,так как он всё равно будет в состоянии Listen и включиться только тогда,если active пропадет, standby займет его место , и только тогда он перейдет в состоянии standby.(речь идет о 3 роутере) Тоже самое будет касаться 4,5 ...n роутеров.
SLA
Бывает и другая ситуация ,когда не сам линк от R1 падает ,а устройство находящиеся за ним,к примеру SW2 упал link до R3. Проблему способен решить сервис SLA - Service Level Agreement.
Суть его проста,он ping сервис до провайдера и если он падает ,то отрабатывает track.
R1(config)# ip sla 1 - создаем зонд
R1(config-ip-sla)# icmp-echo 215.215.215.2 source-interface e0/2 - посылаем icmp echo ping на 215.215.215.2
R1(config-ip-sla-echo)# frequency 10 - посылаем icmp echo ping с частотой каждые 10 секунд
R1(config)# ip sla schedule 1 start-time now life forever - задаем расписание работы ip sla. В данном случае зон будет запущен прямо сейчас, при этом время окончания не задано (навсегда)
R1(config)# track 1 ip sla 1 reachability - устанавливаем объект отслеживания на доступность того хоста, на который посылаем icmp echo ping
R1(config)# ip route 0.0.0.0 0.0.0.0 2.2.2.2 track 1 - направляем трафик по этому маршруту если объект трекинга track 1 работает (хост пингуется)
R1(config)# ip route 0.0.0.0 0.0.0.0 3.3.3.3 10 - если не пингуется, направляем трафик в интернет по другому маршруту (Внимание! Здесь важно задать именно плохую метрику, например 10, иначе будут работать оба маршрута! (балансировка))
R1# show track 1 - показать состояние объекта отслеживания
VRRP
Настройка VRRP не сильно отличается от HSRP . Настраивается он также как и HSRP, только вместо standby используется vrrp. Router(config-if)# vrrp 1 ip 192.168.1.1 - включение vrrp. Проще пройтись по отличиям ,чем заново описывать все команды.
У VRRP тоже только 2 состояния Master и Backup(HSRP active и standby)
Preempt включен по умолчанию (HSRP он отключен)
При падении линка VRRP проводит выборы роутера(HSRP имеет запасной). Главного выбирают по IP адресу, когда проводят выборы.
Поддержка Аутентификации в VRRP отсутствует (RFC отсутствует),но в Cisco она реализована(HSRP по умолчанию)
VRRP по умолчанию hello таймер равен 1 секунде , dead таймер равен 3(у HSRP 3 и 10 соответственно)
Виртуальный адрес может совпадать с адресом интерфейса(HSRP такой адрес не даст прописать)
Использует Multicast HSRP равен 224.0.0.2 ( version 1) 224.0.0.102 (version 2) ,а VRRP 224.0.0.18
Может отслеживать только объекты , а HSRP и интерфейсы , и объекты.(смотри раздел tracking)
Диагностика
Router# show standby (vrrp or glbp) - показать общую информацию по протоколу группы FHRP
Router# show standby brief - показать информацию по протоколу группы FHRP в виде таблицы
Для любых интерфейсов 10/100 Мбит/с или 10/100/1000Мбит/с, то есть интерфейсов, которые могут работать на разных скоростях, коммутаторы Cisco по умолчанию устанавливают значение duplex auto и speed auto. В результате эти интерфейсы пытаются автоматически определить скорость и настройку дуплекса. Кроме того, как вы уже знаете, можно настроить большинство устройств, включая интерфейсы коммутатора, для использования определенной скорости и/или дуплекса.
В реальности, использование автосогласования не требует каких либо дополнительных настроек: просто можно выставить параметры скорости и дуплекса по умолчанию, и пусть порт коммутатора определяет, какие настройки использовать автоматически. Однако проблемы могут возникнуть из-за неудачных комбинаций настроек.
Автоматическое согласование в рабочих сетях
Устройства Ethernet, объединенные каналами связи, должны использовать один и тот же стандарт. В противном случае они не смогут корректно передавать данные. Например, старый компьютер с сетевым адаптером стандарта 100BASE-T, который использует двухпарный UTP-кабель со скоростью 100 Мбит /с, не сможет "общаться" с коммутатором, подключенному к ПК, так как порт коммутатора использует стандарт 1000BASE-T. Даже если подключите кабель, работающий по стандарту Gigabit Ethernet, канал не будет работать с оконечным устройством, пытающимся отправить данные со скоростью 100 Мбит /с на порт другого устройства, работающем со скоростью 1000 Мбит /с.
Переход на новые и более быстрые стандарты Ethernet становится проблемой, поскольку обе стороны должны использовать один и тот же стандарт. Например, если вы замените старый компьютер, который поддерживает стандарт передачи данных 100BASE-T , на новый, работающий по стандарту 1000BASE-T, то соответственно порты коммутатора на другом конце линии связи должны также работать по стандарту 1000BASE-T. Поэтому, если у вас коммутатор только с поддержкой технологии 100BASE-T, то вам придется его заменить на новый. Если коммутатор будет иметь порты, которые работают только по технологии 1000BASE-T, то соответственно вам придется заменить все старые компьютеры, подключенные к коммутатору. Таким образом, наличие как сетевых адаптеров ПК (NIC), так и портов коммутатора, поддерживающих несколько стандартов/скоростей, значительно облегчает переход к следующему улучшенному стандарту.
Протокол автосоглосования (IEEE autonegotiation) значительно облегчает работу с локальной сетью, когда сетевые адаптеры и порты коммутатора поддерживают несколько скоростей. IEEE autonegotiation (стандарт IEEE 802.3 u) определяет протокол, который позволяет двум узлам Ethernet, на основе витой пары, договариваться таким образом, чтобы они одновременно использовали одинаковую скорость и параметры дуплекса. Вначале каждый узел сообщает соседям, свои "возможности" по передаче данных. Затем каждый узел выбирает наилучшие варианты, поддерживаемые обоими устройствами: максимальную скорость и лучшую настройку дуплекса (full duplex лучше, чем half duplex) .
Автосогласование основывается на том факте, что стандарт IEEE использует одни и те же выводы кабеля для 10BASE-T и 100BASE-T (можно использовать кабель с двумя витыми парами). И что бы согласование проходило по технологии 1000BASE-T IEEE autonegotiation просто подключает новые две пары в кабеле (необходимо использовать кабель с четырьмя витыми парами).
Большинство сетей работают в режиме автосогласования, особенно между пользовательскими устройствами и коммутаторами локальной сети уровня доступа, как показано на рисунке 1. В организации установлено четыре узла. Узлы соединены кабелем с поддержкой Gigabit Ethernet (1000BASE-T). В результате, линия связи поддерживает скорость 10Мбит /с, 100Мбит /с и 1000Мбит /с. Оба узла на каждом канале посылают друг другу сообщения автосогласования. Коммутатор в нашем случае может работать в одном из трех режимов: 10/100/1000, в то время как сетевые платы ПК поддерживают различные опции. Настроены в ручную
Рисунок отображает концепцию автоматического согласования стандарта IEEE. В результате сетевая карта и порт на коммутаторе работают правильно. На рисунке показаны три ПК - 1, 2 и 3, подключенные к общему коммутатору. Сетевые адаптеры этих узлов имеют характеристики соответственно: 1 ПК 10 Mb/s, 2 ПК - 10/100 Mb/s и 3 ПК - 10/100/1000 Mb/s. ПК подключаются к коммутатору через порт поддерживающий режим работы 10/100/1000 Mb/s.
С обеих сторон автосогласование включено. Результатом во всех трех случаях является: дуплекс включен в режиме FULL, выставлена соответствующая скорость.
Далее разберем логику работы автосоглосования на каждом соединении:
ПК 1: порт коммутатора сообщает, что он может работать на максимальной скорости в 1000 Мбит /с, но сетевая карта компьютера утверждает, что ее максимальная скорость составляет всего 10 Мбит / с. И ПК, и коммутатор выбирают самую быструю скорость, на которой они могут работать совместно (10 Мбит /с), и устанавливают лучший дуплекс (full).
ПК2 сообщает коммутатору, что максимальная скорость передачи данных его сетевой карты составляет 100 Мбит /с. Это означает что ПК2 может работать по стандарту 10BASE-T или 100BASE-T. Порт коммутатора и сетевой адаптер договариваются использовать максимальную скорость в 100 Мбит /с и полный дуплекс (full).
ПК3: сообщает коммутатору, что его сетевая карта может работать в трех режимах: 10/100/1000 Мбит/с, и соответственно поддерживает все три стандарта. Поэтому и сетевая карта, и порт коммутатора выбирают максимальную скорость в 1000 Мбит /с и полный дуплекс (full).
Одностороннее автосогласовние (режим, при котором только один узел использует автоматическое согласование)
На рисунке 1 показано двухстороннее автосогласования IEEE (оба узла используют этот процесс). Однако большинство устройств Ethernet могут отключить автоматическое согласование, и поэтому важно знать, что происходит, когда один из узлов использует автосогласование, а другой нет.
Иногда возникает необходимость отключить автосогласование. Например, многие системные администраторы отключают автосогласование на соединениях между коммутаторами и просто настраивают желаемую скорость и дуплекс. Однако могут возникнуть ошибки, когда одно устройство использует автосогласование, а другое нет. В этом случае связь может не работать вообще, или она может работать нестабильно.
IEEE autonegotiation (автосогласование) определяет некоторые правила (значения по умолчанию), которые узлы должны использовать в качестве значений по умолчанию, когда автосогласование завершается неудачей-то есть когда узел пытается использовать автосогласование, но ничего не слышит от устройства.
Правила:
Скорость: используйте самую низкую поддерживаемую скорость (часто 10 Мбит / с).
Дуплекс: если ваша скорость равна 10 Мбит/, используйте полудуплекс (half duplex); Если 100 Мбит/с используйте полный дуплекс (full duplex) .
Коммутаторы Cisco могут самостоятельно выбирать наилучшие настройки порта по скорости и дуплексу, чем параметры IEEE, установленные по умолчанию (speed default). Это связано с тем, что коммутаторы Cisco могут анализировать скорость, используемую другими узлами, даже без автосогласования IEEE. В результате коммутаторы Cisco используют эту свою возможность для выбора скорости, когда автосогласование не работает:
Скорость: происходит попытка определения скорости (без использования автосогласования), если это не удается, используются настройки по умолчанию (устанавливается самая низкая поддерживаемая скорость, обычно 10 Мбит/с).
Дуплекс: в зависимости от установленной скорости настраиваются параметры дуплекса: если скорость равна 10 Мбит/с назначается полудуплекс (half duplex), если скорость равна 100 Мбит/с, то используется полный дуплекс (full duplex).
Гигабитные интерфейсы (1Gb/s) всегда используют полный дуплекс.
На рисунке 2 показаны три примера, в которых пользователи изменили настройки свих сетевых карт и отключили автоматическое согласование, в то время как коммутатор (на всех портах поддерживается скорость 10/100/1000 Мбит/с) пытается провести автосогласование. То есть, на портах коммутатора выставлены параметры скорости (speed auto) и (duplex auto) дуплекса в режим auto. В верхней части рисунка отображены настроенные параметры каждой сетевой карты компьютеров, а выбор, сделанный коммутатором, указан рядом с каждым портом коммутатора.
На рисунке показаны результаты работы автосогласования IEEE с отключенным режимом автосогласования на одной стороне. На рисунке показаны три компьютера - 1, 2 и 3, подключенные к общему коммутатору. Параметры сетевых адаптеров этих систем следующие: ПК1- 10/100Мбит/с, ПК2 - 10/100/1000 Мбит/с и ПК3 - 10/100Мбит/с. Компьютеры соединены с коммутатором через интерфейсы F0/1, F0/2 и F0/3. На стороне компьютеров автосогласование отключено, и произведены настройки скорости и дуплекса вручную, которые вы можете посмотреть на рисунке 2. На стороне коммутатора включено автосогласование (10/100/1000).
Разберем работу устройств на рисунке:
ПК1: коммутатор не получает сообщений автосогласования, поэтому он автоматически определяет скорость передачи данных ПК1 в 100 Мбит/с. Коммутатор использует дуплекс IEEE по умолчанию, основанный на скорости 100 Мбит/с (полудуплекс).
ПК2: коммутатор использует те же действия, что и при анализе работы с ПК1, за исключением того, что коммутатор выбирает использование полного дуплекса, потому что скорость составляет 1000 Мбит / с.
ПК3: пользователь установил самую низшую скорость (10 Мбит/с) и не самый лучший режим дуплекса (half). Однако коммутатор Cisco определяет скорость без использования автосогласования IEEE и затем использует стандарт IEEE duplex по умолчанию для каналов 10 Мбит / с (half duplex).
ПК1.Итог работы этой связки: дуплексное несоответствие. Оба узла используют скорость 100 Мбит/с, поэтому они могут обмениваться данными. Однако ПК1, используя полный дуплекс, не пытается использовать carrier sense multiple access (CSMA) для обнаружения столкновений (CSMA / CD) и отправляет кадры в любое время. В свою очередь интерфейс коммутатора F0/1 (в режиме half duplex), использует CSMA / CD. Отчего порт коммутатора F0/1 будет считать, что на канале происходят коллизии, даже если физически они не происходят. Порт остановит передачу, очистит канал, повторно отправит кадры и так до бесконечности. В результате связь будет установлена, но работать она будет нестабильно.
Для устранения неполадок мы должны пройти путь от нижней части модели OSI к верхней. Для этого нам придется начать с протоколов, которые используются для коммутации. Будем думать о VLAN, транкинге, об агрегировании каналов и связующем дерева. Мы рассмотрим различные протоколы и различные сценарии, где "что-то работает" не так. Мы решим эти проблемы с помощью комбинации команд show и debug. Первая остановка ... проблемы с интерфейсом!
Следующие статьи этого цикла:
Траблшутинг STP (Spanning tree protocol)
Устранение неисправностей EtherChannel
Case #1
В этом примере мы имеем коммутатор в центре и два компьютера, которые подключены к нему. Каждый компьютер имеет свой IP-адрес, и они должны иметь возможность пинговать друг друга. Мы будем считать, что компьютеры настроены правильно и там нет никаких проблем.
Интерфейс FastEthernet 0/1 находится в состоянии down. Это может указывать на проблему уровня 1, такую как неисправный кабель, неправильный кабель (кроссовер вместо прямого) или, возможно, нерабочая сетевая карта. Обратите внимание, что этот интерфейс работает в полудуплексном режиме. Если повезет, вы можете получить дуплексное сообщение через CDP, которое сообщит вам, что существует дуплексное несоответствие. Если вам не повезло, возможно, из-за этого ваш интерфейс переходит в состояние down. Имейте в виду, что гигабитный интерфейс не поддерживает halfduplex.
SwitchA(config)#interface fa0/1
SwitchA(config-if)#duplex auto
Изменим настройки интерфейса на duplex auto, чтобы коммутатор мог само настроиться.
Может быть, нам повезет...но не в этот раз, пинг не работает.
Интерфейс fa0 / 3, подключенный к хосту B, также не работает. После проверки кабелей и разъемов мы можем проверить ошибки дуплекса и скорости. Дуплекс включен в режим auto, так что это не является проблемой. Скорость была установлена на 10 Мбит, однако в то время как этот интерфейс является каналом Fast Ethernet (100 Мбит).
SwitchA(config)#interface fa0/3
SwitchA(config-if)#speed auto
Давайте переключим скорость на авто и посмотрим, что произойдет.
Похоже, что несоответствие скорости привело к тому, что интерфейс перешел в состояние down. Изменение его на auto-speed возвращает интерфейс в состояние up.
Это то, что мы искали. Интерфейсы, с которыми мы работаем, оба показывают состояние up/up. По крайней мере, теперь мы знаем, что нет никаких ошибок в кабеле, скорости или дуплексе.
Теперь наш пинг проходит.
Первый урок усвоен: Проверьте свои интерфейсы и посмотрите, отображаются ли они как up/up.
Case #2
Та же топология, но здесь другая проблема.
Хост A не может пропинговать хост B. Мы начнем с проверки интерфейсов:
Состояние интерфейса FastEthernet0/3 выглядит нормально, но что-то не так с интерфейсом FastEthernet 0/1.
Давайте изучим его подробнее:
Так так, мы видим сообщение err-disabled. Это уже дает нам понять, что проблема, где здесь (по крайней мере, это означает, что мы на что-то наткнулись).
Используйте команду show interfaces status err-disabled, чтобы узнать, почему интерфейс перешел в режим error-disabled. Это сообщит нам, что причина-безопасность порта.
Мы можем посмотреть на конфигурацию безопасности порта, и мы видим, что только 1 MAC-адрес разрешен. Последний MAC-адрес, который виден на интерфейсе - 000с.2928.5c6c.
Выше мы видим, что интерфейс был настроен для обеспечения безопасности на другой MAC-адрес. Именно по этой причине порт перешел в режим err-disabled.
SwitchA(config)#interface fa0/1
SwitchA(config-if)#no switchport port-security
Давайте уберем port security, чтобы решить эту проблему.
SwitchA(config)#interface fa0/1
SwitchA(config-if)#shutdown
SwitchA(config-if)#no shutdown
Главное, что вы не должны забыть сделать - это после очистки настройки от port security ваш интерфейс все еще находится в режиме err-disabled. Вам нужно выполнить команды отключения и включения порта (shutdown и no shutdown), чтобы он снова заработал!
Консоль сообщает нам, что интерфейс теперь включен.
Как мы видим эхо-запрос проходит между компьютерами. Проблема решена!
Урок 2 усвоен: проверьте, находится ли интерфейс в состоянии err-disabled, и если да, то: а) проверьте, почему это произошло, и Б) решите проблему.
Case #3
Давайте продолжим с другой проблемой. Та же топология, но опять проблема.
Эти два компьютера не "видят" друг друга.
Интерфейсы выглядят хорошо, никаких ошибок здесь нет.
И так мы видим, что port security отключена на этом коммутаторе. На данный момент мы, по крайней мере, знаем, что нет никаких проблем с интерфейсом и port security не фильтрует никакие MAC-адреса.
В данный момент это хорошая идея, чтобы проверить информацию о VLAN. Вы можете использовать команду show vlan, чтобы быстро проверить, к какой VLAN принадлежат интерфейсы.
Как вы можете видеть, наши интерфейсы находятся не в одной и той же VLAN.
SwitchA(config)#interface fa0/3
SwitchA(config-if)#switchport access vlan 1
Мы переместим интерфейс fa0/3 обратно в VLAN 1.
Теперь оба компьютера находятся в одной VLAN. Проблема решена! Урок 3 усвоен: убедитесь, что интерфейсы находится в нужной VLAN.
Case #4
Пришло время для другой проблемы! Наши два компьютера не пингуюся между собой. Вы теперь знаете, как выглядит неудачный пинг, поэтому скрин не будет публиковаться снова.
Интерфейсы не показывают никаких ошибок.
Мы изучим настройку VLAN. Вы видите, что FastEthernet 0/1 находится в VLAN 10, но мы нигде не видим FastEthernet 0/3. Вот возможные причины:
Что-то не так с интерфейсом. Мы проверили и убедились, что это не так, потому что он показывает состояние up/up, поэтому он кажется активным.
Интерфейс не в режиме access port, а в режиме trunk.
Быстрый взгляд на информацию о коммутаторе показывает нам, что нам нужно знать. Мы убедились, что интерфейс fa0/3 находится в режиме trunk, а native VLAN - 1. Это означает, что всякий раз, когда хост B отправляет трафик и не использует маркировку 802.1 Q, наш трафик заканчивается в VLAN 1.
SwitchA(config)#interface fa0/3
SwitchA(config-if)#switchport mode access
SwitchA(config-if)#switchport access vlan 10
Мы включим fa0/3 в режим доступа и убедимся, что он находится в VLAN 10.
Оба интерфейса теперь активны в VLAN 10.
Возможно, лучше проверить информацию на коммутаторе.
Теперь я могу отправить пинг с хоста а на хост Б...проблема решена!
Урок 4 усвоен: убедитесь, что интерфейс находится в нужном режиме (доступ или магистральный режим).
Case #5
Те же два компьютера, тот же коммутатор. Однако этот сценарий немного интереснее. Компьютеры не могут пинговать друг друга, поэтому давайте пройдемся по нашему списку "возможных" ошибок:
Интерфейсы выглядят хорошо, up/up-это очень хорошо.
Оба интерфейса находятся в VLAN 10, так что это тоже хорошо.
Просто чтобы быть уверенным...там нет port security. Это очень интересная ситуация. Интерфейсы работают (в состоянии up/up), мы находимся в одной VLAN, и нет никакой защиты портов. Что еще может быть причиной "перекрытия" трафика?
Ага! Это может быть не то, о чем нам может прийти в голову, но мы же можем использовать VACLs (VLAN access-list), чтобы разрешить или запретить трафик в пределах VLAN. Если вы устраняете неполадки коммутаторов, то необходимо проверить эту настройку, если все остальное кажется вам нормальным. В этом случае есть VACL, подключенный к VLAN 10, давайте проверим его.
Есть два порядковых номера ... 10 и 20. Порядковый номер 10 соответствует access-list 1, и его задача состоит в том, чтобы отбросить трафик. Давайте посмотрим, что это за access-list 1:
Не смущайтесь из-за заявления о разрешении здесь. Использование оператора permit в access-list означает, что он будет "соответствовать" подсети 192.168.1.0/24. Наши два компьютера используют IP-адреса из этого диапазона. Если он соответствует этому access-list, то VLAN access-map отбросит трафик.
SwitchA(config)# vlan access-map BLOCKSTUFF 10
SwitchA(config-access-map)# action forward
Давайте изменим действие на "forward" и посмотрим, решит ли оно нашу проблему.
Ну вот, все работает.
Урок 5 усвоен: если все остальное кажется нормальным, убедитесь, что нет никакого VACL!
Case #6
Давайте продолжим урок 6 с другой топологией. Теперь вы знаете, что нам нужно сначала проверить интерфейсы, а затем VLAN. В этом примере у нас есть те же два компьютера, но теперь у нас есть два коммутатора. Пинг от Хост А к Хосту Б не работает, так с чего начнем поиск?
Сначала мы проверим интерфейс fa0/1 на коммутаторе 1. Интерфейс запущен и работает, это switchport, назначенный для VLAN 10. Пока все выглядит неплохо. Port security не включен, так что нам не нужно беспокоиться об этом.
Давайте проверим то же самое на коммутаторе 2. Интерфейс работает, и он был назначен на VLAN 10.
В данный момент мы видим, что интерфейсы, "смотрящие" к компьютерам выглядят хорошо. В этот момент Вы могли бы сделать две вещи:
Подключите другой компьютер к коммутатору 1 и назначьте его во VLAN 10. Посмотрите, можно ли общаться между компьютерами во VLAN 10, когда они подключены к одному коммутатору. Сделайте то же самое на коммутаторе 2.
Проверьте интерфейсы между коммутатором 1 и коммутатором 2.
Мы сконцентрируем свое внимание на интерфейсах между коммутатором 1 и коммутатором 2, потому что там много чего может пойти не так!
Интерфейсы не показывают никаких проблем, время проверить информацию о switchport.
Коммутатор A находится в магистральном режиме и использует инкапсуляцию ISL.
Коммутатор B также находится в магистральном режиме, но использует инкапсуляцию 802.1Q. Имейте в виду, что (в зависимости от модели коммутатора) административный режим по умолчанию может быть dynamic auto. Два интерфейса, которые оба работают в dynamic auto режиме, станут портом доступа (access). Лучше всего самостоятельно переключить интерфейс в магистральный режим. В нашем случае оба интерфейса магистральные, так что это хорошо, но у нас есть несоответствие протокола инкапсуляции.
SwitchA(config)#interface fa0/15
SwitchA(config-if)#switchport trunk encapsulation dot1q
Мы изменим тип инкапсуляции, чтобы оба коммутатора использовали протокол 802.1Q.
Проблема решена! И опять все работает.
Урок 6 усвоен: убедитесь, что при настройке магистралей используется один и тот же протокол инкапсуляции.
Case #7
Вот опять тот же сценарий. Сейчас рассмотрим еще кое-что, что важно проверить при решении проблем trunk. Предположим, мы проверили и убедились, что следующие элементы не вызывают никаких проблем:
Интерфейсы (скорость/дуплекс).
Безопасность портов.
Конфигурация Switchport (назначение VLAN, интерфейс, настроенный в режиме доступа).
К сожалению, эхо-запрос между компьютерами все еще не проходит. Давайте взглянем на интерфейсы fa0/15 на коммутаторах:
Проверим, что оба интерфейса находятся в магистральном режиме и что мы используем один и тот же протокол инкапсуляции (802.1 Q). Здесь нет никаких проблем. Что-нибудь еще, что может пойти не так с этой магистральной связью? Да!
Магистраль может быть работоспособной, но это не означает, что все VLAN разрешены по магистральному каналу связи. В приведенном выше примере вы видите, что разрешена только VLAN 20.
SwitchA(config)#interface fa0/15
SwitchA(config-if)#switchport trunk allowed vlan all
SwitchB(config)#interface fa0/15
SwitchB(config-if)#switchport trunk allowed vlan all
Давайте позволим всем VLAN пройти магистраль.
По магистральной линии может передаваться трафик VLAN 10 между двумя коммутаторами. В результате пинг идет между компьютерами....еще одна проблема решена!
Урок 7 усвоен: всегда проверяйте, разрешает ли магистраль все VLAN или нет.
Case #8
Вот вам новый сценарий. Два компьютера, имеют разные IP-адреса. Коммутатор - это многоуровневый коммутатор. Поскольку компьютеры находятся в разных подсетях, нам приходится беспокоиться о маршрутизации.
Мы видим, что два компьютера не могут связаться друг с другом. С чего мы должны начать устранение неполадок?
Это статья не о настройке windows, но нам нужно обратить внимание на наши хосты. Поскольку компьютеры должны "выйти из своей собственной подсети", мы должны проверить, что IP-адрес шлюза по умолчанию в порядке и доступен.
Хост А может достичь шлюза по умолчанию, поэтому мы, по крайней мере, знаем, что хост А работает нормально.
Вот IP-конфигурация хоста B. Давайте проверим доступность шлюза по умолчанию!
Здесь тоже все работает. Мы знаем, что компьютеры рабочие, потому что они знают, как выйти из своей собственной подсети, и шлюз по умолчанию доступен. Пора проверить коммутатор.
Как мы видим, что хост А находится в VLAN 10 и хост B находится в VLAN 20. Мы не проверяли, включены ли интерфейсы, потому что мы можем пинговать IP-адреса шлюза по умолчанию. Это говорит о том, что fa0/1 и fa0/3 работают, но мы не знаем, к какой VLAN они принадлежат.
Были сконфигурированы два интерфейса SVI. Это IP-адреса, которые компьютеры используют в качестве шлюза по умолчанию. Так почему же наш коммутатор не маршрутизирует трафик?
Наличие IP-адресов на интерфейсах не означает автоматическую маршрутизацию трафика. Для этого нам потребуется таблица маршрутизации. Этот коммутатор не имеет
SwitchA(config)#ip routing
Давайте включим маршрутизацию на этом коммутаторе.
Давайте сделаем так, чтобы это выглядело получше. Теперь коммутатор знает, куда перенаправлять IP-пакеты на этом коммутаторе.
Вот так...теперь два компьютера могут достучаться друг до друга! Проблема решена! Урок 8 усвоен: если вы используете многоуровневый коммутатор для маршрутизации interVLAN, убедитесь, что интерфейсы SVI настроены правильно и что маршрутизация включена.
Мы рассмотрели наиболее распространенные ошибки, которые могут произойти с нашими интерфейсами, VLAN, транками и проблемами маршрутизации при использовании многоуровневых коммутаторов.
В следующей статье мы рассмотрим связующее дерево. Spanning-tree-довольно надежный протокол, но есть ряд вещей, которые могут пойти не так, как, вы ожидаете. Кроме того, из-за неправильной настройки могут произойти некоторые странные вещи...давайте рассмотрим траблшутинг STP в следующей статье.