По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
Для устранения неполадок мы должны пройти путь от нижней части модели 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 в следующей статье.
Международная организации ISO представляет свою уникальную разработку под названием OSI, которой необходимо создать базу для разработки сетевых стандартов.
Сетевая модель TCP/IP контролирует процесс межсетевого взаимодействия между компьютерными системами. Несмотря на это, модель OSI включает в себя 7 уровней сетевого взаимодействия, а модель TCP/IP - 4.
Межсетевой экран Netfilter определяет протоколы Некоторые из них могут быть заданы только косвенно.
Протоколы сетевого уровня и межсетевое экранирование
Для формирования сквозной транспортной системы необходимо предоставить сетевой уровень (Network Layer). Он определяет маршрут передачи данных, преобразует логические адреса и имена в физические; в модели OSI (Таблица 2.1) данный уровень получает дейтаграммы, определяет маршрут и логическую адресацию, и направляет пакеты в канальный уровень, при этом сетевой уровень прибавляет свой заголовок.
Протокол IP (Internet Protocol)
Основным протоколом является IP, который имеет две версии: IPv4 и IPv6. Основные характеристики протокола IPv4:
Размер адреса узла - 4 байта
В заголовке есть поле TTL
Нет гарантии при доставке, что будет правильная последовательность
Пакетная передача данных.
Если превысится максимальный размер для пакета, тогда обеспечивается его фрагментация.
Версия состоящее из четырех бит поле, которое содержит в себе номер версии IP протокола (4 или 6).
Длина заголовка - состоящее их 4х бит поле, которое определяет размер заголовка пакета.
Тип обслуживания поле, которое состоит из 1 байта; на сегодняшний день не используется. Его заменяют на два других:
DSCP, которое делит трафик на классы обслуживания, размер его составляет 6 бит.
ECN - поле, состоящее из 2 бит, используется в случае, если есть перегрузка при передаче трафика.
Смещение фрагмента используется в случае фрагментации пакета, поле которого равно 13 бит. Должно быть кратно 8.
"Время жизни" поле, длиной в 1 байт, значение устанавливает создающий IP-пакет узел сети, поле, состоящее из 1 байта
Транспорт поле, размером в один байт.
Доп. данные заголовка поле, которое имеет произвольную длину в зависимости от содержимого и используется для спец. задач.
Данные выравнивания. Данное поле используется для выравнивания заголовка пакета до 4 байт.
IP уникальный адрес. Адреса протокола четвёртой версии имеют длину 4 байта, а шестой 16 байт. IP адреса делятся на классы (A, B, C). Рисунок 2.2. Сети, которые получаются в результате взаимодействия данных классов, различаются допустимым количеством возможных адресов сети. Для классов A, B и C адреса распределяются между идентификатором (номером) сети и идентификатором узла сети
Протокол ICMP
Протокол сетевого уровня ICMP передает транспортную и диагностическую информацию.
Даже если атакующий компьютер посылает множество ICMP сообщений, из-за которых система примет его за 1 из машин.
Тип поле, которое содержит в себе идентификатор типа ICMP-сообщения. Оно длиною в 1 байт.
Код поле, размером в 1 байт. Включает в себя числовой идентификатор, Internet Header + 64 bits of Original Data Datagram включает в себе IP заголовок и 8 байт данных, которые могут быть частью TCP/UDP заголовка или нести информацию об ошибке.
Типы ICMP-сообщений, есть во всех версиях ОС Альт, и они подразделяются на две большие категории.
Протоколы транспортного уровня и межсетевое экранирование
При ПТУ правильная последовательность прихода данных. Основными протоколами этого уровня являются TCP и UDP.
Протокол UDP
Основные характеристики протокола UDP приведены ниже.
Простую структура, в отличие от TCP
Сведения придут неповрежденными, потому что проверяется контрольная сумма
Нет гарантии надёжной передачи данных и правильного порядка доставки UDP-пакетов
Последнее утверждение нельзя рассматривать как отрицательное свойство UDP. Поддержка протокола не контролирует доставку пакетов, значит передача данных быстрее, в отличие от TCP.
UDP-пакеты являются пользовательскими дейтаграммами и имеют точный размер заголовка 8 байт.
Адрес порта источника - поле, размером 16 бит, с № порта.
Адрес порта пункта назначения - поле, размером 16 бит, в котором есть адрес порта назначения.
Длина - размером 16 бит. Оно предназначено для хранения всей длины дейтаграммы пользователя и заголовка данных.
Контрольная сумма. Данная ячейка обнаруживается всею пользовательскую дейтаграмму.
В UDP контрольная сумма состоит из псевдозаголовока, заголовка и данных, поступивших от прикладного уровня.
Псевдозаголовок это часть заголовка IP-пакета, в котором дейтаграмма пользователя закодирована в поля, в которых находятся 0.
Передающее устройство может вычисляет итоговую сумму за восемь шагов:
Появляется псевдозаголовок в дейтаграмме.
В поле КС по итогу ставится 0.
Нужно посчитать число байтов. Если четное тогда в поле заполнения мы пишем 1 байт (все нули).
Конечный результат - вычисление контрольной суммы и его удаление.
Складываются все 16-битовых секций и дополняются 1.
Дополнение результата. Данное число и есть контрольная сумма
Убирается псевдозаголовка и всех дополнений.
Передача UDP-сегмента к IP программному обеспечению для инкапсуляции.
Приемник вычисляет контрольную сумму в течение 6 шагов:
Прописывается псевдозаголовок к пользовательской дейтаграмме UDP.
Если надо, то дополняется заполнение.
Все биты делятся на 16-битовые секции.
Складывается все 16-битовых секций и дополняются 1.
Дополнение результата.
Когда результат = нулю, убирается псевдозаголовок и дополнения, и получает UDP-дейтаграмму только семь б. Однако, если программа выдает иной рез., пользовательская дейтаграмма удаляется. Чтобы передать данные - инкапсулируется пакет.
В хосте пункта назначения биты декодируются и отправляются к звену данных. Последний использует заголовок для проверки данных, заголовок и окончание убираются, если все правильно, а дейтаграмма передается IP. ПО делает свою проверку. Когда будет все правильно, заголовок убирается, и пользовательская дейтаграмма передается с адресами передатчика и приемника. UDP считает контрольную сумму для проверки . Если и в этот раз все верно, тогда опять заголовок убирается, и прикладные данные передаются процессу.
Протокол TCP
Транспортный адрес заголовка IP-сегмента равен 6 (Таблица 2.2). Протокол TCP совсем другой, в отличие от протокола UDP. UDP добавляет свой собственный адрес к данным, которые являются дейтаграммой, и прибавляет ее IP для передачи.
TCP образует виртуальное соединение между хостами, что разрешает передавать и получать данные как поток байтов.
Также добавляется заголовок перед передачей пакету СУ.
Порт источника и порт приемника поля размером по 16 бит. В нем есть номер порта службы источника.
Номер в последовательности поле размером в 32 бита, содержит в себе номер кадра TCP-пакета в последовательности.
Номер подтверждения поле длиной в 32 бита, индикатор успешно принятых предыдущих данных.
Смещение данных поле длиной в 4 бита (длина заголовка + смещение расположения данных пакета.
Биты управления поле длиной 6 бит, содержащее в себе различные флаги управления.
Размер окна поле размером 16 бит, содержит в себе размер данных в байтах, их принимает тот, кто отправил данный пакет. Макс.значение размера окна - 40967байт.
Контр. сумма поле размером 16 бит, содержит в себе значение всего TCP-сегмента
Указатель поле размером 16 бит, которое используется, когда устанавливается флаг URG. Индикатор количества пакетов особой важности.
Опции - поле произв. длины, размер которого зависит от данных находящихся в нём.
Чтобы повысить пропускную функцию канала, необходим способ "скользящего окна". Необходимы только поля заголовка TCP-сегмента: "Window". Вместе с данным полем можно отправлять максимальное количество байт данных.
Классификация межсетевых экранов
Межсетевые экраны не позволяют проникнуть несанкционированным путем, даже если будет использоваться незащищенныеместа, которые есть в протоколах ТСР/IP.
Нынешние МЭ управляют потоком сетевого трафика между сетями с различными требованиями к безопасности. Есть несколько типов МЭ. Чтобы их сравнить, нужно с точностью указать все уровни модели OSI, которые он может просчитать. МЭ работают на всех уровнях модели OSI.
Пакетные фильтры
Изначально сделанный тип МЭ и есть пакетный фильтр. ПФ - часть маршрутизаторов, которые могут быть допущены к разным сист.адресам.
ПФ читают информацию заголовков пакетов 3-го и 4-го уровней.
ПФ применяется в таких разделай сетевой инфраструктуры, как:
пограничные маршрутизаторы;
ос;
персональные МЭ.
Пограничные роутеры
Главным приоритетом ПФ является скорость. Также пф ограничивать доступ при DoS-атаки. Поэтому данные пф встроены в большинство роутеров.
Преимущества пф:
Пф доступен для всех, так как остается в целостности ТСР-соединение.
Недостатки пакетных фильтров:
Пфпропускают данные с высших уровней
МЭ имеет доступ не ко всей информации
Большинство пф не аутентифицируют пользователя.
Для исходящего и входящего трафика происходит фильтрация.
МЭ анализирующие состояние сессии
Такие МЭ являются пакетными фильтрами, которые считывают сохраняемый пакет 4-го уровня OSI.
Плюсы МЭ четвертого уровня:
Информацию могут узнать только установленные соединения
Пф доступен для всех, остается в целостности ТСР-соединение
Прокси-сервер прикладного уровня
Если применять МЭ ПУ, тогда нам не потребуется устройство, чтобы выполнить маршрутизацию.
Прокси-сервер, анализирующий точный протокол ПУ, называется агентом прокси.
Такой МЭ имеют много преимуществ.
Плюсы прокси-сервера ПУ:
Прокси требует распознавание пользователя
МЭ ПУ проанализирует весь сетевой пакет.
Прокси ПУ создают детальные логи.
Минусы прокси-сервера ПУ:
МЭ использует больше времени при работе с пакетами
рикладные прокси работают не со всеми сетевыми приложениями и протоколами
Выделенные прокси-серверы
Эти прокси-серверы считывают трафик определенного прикладного протокола и не анализируют его полностью.
Прокси-серверы нужны для сканирования web и e-mail содержимого:
отсеивание Java-приложений;
отсеивание управлений ActiveX;
отсеивание JavaScript;
уничтожение вирусов;
блокирование команд, определенных для приложений и пользователя, вместе с блокирование нескольких типов содержимого для точных пользователей.
Третья статья будет посвящена поиску и устранению неисправностей EtherChannels. Большинство проблем с EtherChannels происходит из-за неправильной конфигурации.
Предыдущие статьи этого цикла:
Устранение неполадок коммутации Cisco
Траблшутинг STP (Spanning tree protocol)
Case #1
В этом сценарии есть только два коммутатора и два интерфейса. Идея состоит в том, чтобы сформировать etherchannel путем объединения интерфейсов FastEthernet 0/13 и 0/14, но это не работает
Сначала мы проверим, все ли интерфейсы работают. Да они все работают.
Мы можем проверить, что port-channel interface был создан, но он не работает.
Вот хорошая команда для проверки EtherChannel. Используйте суммарную информацию от команды show etherchannel summary, чтобы увидеть ваши port-channels. Мы видим, что коммутатор A настроен для LACP и коммутатор B для PAgP, а это никогда не будет работать.
Лучшая команда для использования это show etherchannel detail. Это дает вам много информации, но нам особенно интересно узнать, настроен ли LACP для пассивного или активного режима. Интерфейсы в активном режиме будут "активно" пытаться сформировать EtherChannel. Интерфейсы в пассивном режиме будут отвечать только на запросы LACP.
Вот вывод команды show etherchannel detail на коммутаторе B. Мы видим, что он был настроен для PAgP, и интерфейсы настроены для desirable режима. Если бы они были настроены на автоматический режим, мы бы увидели флаг А.
SwitchB(config)#no interface po1
SwitchB(config)#interface fa0/13
SwitchB(config-if)#channel-group 1 mode passive
SwitchB(config-if)#exit
SwitchB(config)#interface fa0/14
SwitchB(config-if)#channel-group 1 mode passive
Давайте сначала избавимся от port-channel interface. Если мы этого не сделаем, вы увидите ошибку при попытке изменить channel-group mode на интерфейсах.
После изменения конфигурации мы видим, что port-channel1 поднялся. Задача решена!
Извлеченный урок: убедитесь, что вы используете один и тот же режим EtherChannel с обеих сторон.
Case #2
Ну что же давайте рассмотрим другую ошибку! Та же топология и EtherChannel, который не функционирует:
Мы проверяем, что port-channel interface существует, но он не работает с обеих сторон.
Мы также видим, что интерфейс FastEthernet 0/13 и 0/14 были добавлены к port-channel interface.
Интерфейсы FastEthernet рабочие, поэтому мы знаем, что проблема не в этом. Давайте углубимся в конфигурацию EtherChannel.
Мы видим, что FastEthernet 0/13 и 0/14 на коммутаторе A оба настроены на автоматический режим PAgP (из-за флага "A").
FastEthernet 0/13 и 0/14 на коммутаторе B также настроены на автоматический режим PAgP. Это никогда не сбудет работать, потому что оба коммутатора теперь пассивно ждут сообщений PAgP.
SwitchB(config)#interface fa0/13
SwitchB(config-if)#channel-group 1 mode desirable
SwitchB(config-if)#interface fa0/14
SwitchB(config-if)#channel-group 1 mode desirable
Давайте изменим один из коммутаторов, чтобы он активно отправлял сообщения PAgP.
EtherChannel сейчас работает. Проблема решена!
Извлеченный урок: при использовании PAgP убедитесь, что хотя бы один из коммутаторов использует требуемый режим, или в случае LACP убедитесь, что один коммутатор находится в активном режиме.
Case #3
Еще одна ситуация: EtherChannel настроен между коммутатором A и коммутатором B, но клиент жалуется, что соединение медленное ... что может быть не так?
Быстрая проверка говорит нам, что port-channel interface работает.
Команда show etherchannel detail дает нам много выходных данных, но она так же нам говорит, что происходит. Вы видите, что интерфейс FastEthernet 0/13 и 0/14 были настроены для port-channel, но коммутатор не смог связать их, потому что FastEthernet 0/14 настроен на 10 Мбит. Возможно, что это основная причина медленной скорости передачи данных.
Мы будем использовать один из операторов для команды show. Нас интересует только то, чтобы увидеть вероятную причину, которую команда "show etherchannel detail" покажет.
SwitchA(config)#interface fa0/14
SwitchA(config-if)#speed auto
SwitchB(config)#interface fa0/14
SwitchB(config-if)#speed auto
Давайте изменим скорость на авто. Мы должны убедиться, что FastEthernet 0/13 и 0/14 имеют одинаковую конфигурацию.
Вероятно, вы увидите пару сообщений о том, что ваши интерфейсы переходят в состояние up и down.
Теперь мы видим, что оба интерфейса были добавлены в port-channel... проблема решена!
Извлеченный урок: убедитесь, что все интерфейсы, которые будут добавлены в port-channel, имеют одинаковую конфигурацию!