По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
В статье мы покажем, как использовать команды маршрутизации в Linux (в UNIX подобных системах) чтобы отображать или конфигурить информацию о дефолтных маршрутах. Погнали разбираться!
Показать маршруты по умолчанию
Ловите 2 команды, которые помогут отобразить текущую таблицу маршрутизации в Linux:
# route
Вывод такой команды будет примерно следующим:
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
192.168.1.0 * 255.255.255.0 U 0 0 0 ra0
default dsl-router 0.0.0.0 UG 0 0 0 ra0
Или можно использовать второй вариант:
$ /sbin/route
”Выхлоп” такой команды в той же самой таблице маршрутизации:
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
191.255.255.0 * 255.255.255.0 U 0 0 0 eth0
169.254.0.0 * 255.255.0.0 U 0 0 0 eth0
default 191.255.255.1 0.0.0.0 UG 0 0 0 eth0
Настройка дефолтного маршрута
Синтаксис настройки категорически прост. Смотрите:
route add default gw {IP-АДРЕС} {ИНТЕРФЕЙС}
Тут:
IP-АДРЕС - IP - адрес шлюза;
ИНТЕРФЕЙС - имя интерфейса, за которым сидит указанный выше шлюз;
Например, если IP - адрес вашего роутера 192.168.1.254 и он сидит на интерфейсом eth0, то из под root выполните команду:
# route add default gw 192.168.1.254 eth0
Или можно использовать хостнейм (только проверьте, чтобы он резолвился на уровне DNS):
# route add default gw dsl-router eth0
Или можно использовать команду ip, чтобы маршрутизировать весь трафик через шлюз 192.168.1.254, который подключен к интерфейсу eth0:
# ip route add 192.168.1.0/24 dev eth0
Либо вместо eth0 интерфейса можно прописать в явном виде адрес шлюза. Тут ап ту ю, как говорится :)
# ip route add 192.168.1.0/24 via 192.168.1.254
Профит!
Предыдущая статья этого цикла:
Устранение неполадок коммутации Cisco
Следующая статья этого цикла:
Устранение неисправностей EtherChannel
Case #1
На рисунке представлена топология, состоящая из трех коммутаторов, и между коммутаторами у нас есть два канала связи для резервирования. Коммутатор А был выбран в качестве корневого моста для VLAN 1. Когда вы имеете дело со связующим деревом, лучше всего нарисовать небольшую схему сети и записать роли интерфейса для каждого коммутатора (назначенного, не назначенного/альтернативного или заблокированного). Обратите внимание, что одним из каналов связи между коммутатором A и коммутатором C является интерфейс Ethernet (10 Мбит). Все остальные каналы — это FastEthernet.
Мы используем команду show spanning-tree для проверки ролей интерфейса для коммутатора A и коммутатора C. Вы видите, коммутатор C выбрал свой интерфейс Ethernet 0/13 как корневой порт, а интерфейс FastEthernet 0/14 выбран в качестве альтернативного порта. Это не очень хорошая идея. Это означает, что мы будем отправлять весь трафик вниз по линии 10 Мбит, в то время как 100 Мбит не используется вообще. Когда коммутатор должен выбрать корневой порт он выберет его следующим образом:
Выбирается интерфейс, который имеет самую низкую стоимость для корневого моста.
Если стоимость равная, выбирается наименьший номер интерфейса. Обычно стоимость интерфейса Ethernet выше, чем Fast Ethernet, поэтому он должен выбрать интерфейс FastEthernet.
Почему коммутатор выбрал интерфейс Ethernet 0/13?
Мы видим, что интерфейс Ethernet 0/13 и FastEthernet0/14 имеют одинаковую стоимость. Затем коммутатор С выберет самый низкий номер интерфейса, который является interface Ethernet 0/13.
После проверки конфигурации интерфейса, видно, что кто-то изменил стоимость интерфейса на 19 (по умолчанию для интерфейсов FastEthernet).
SwitchC(config)#interface Ethernet 0/13
SwitchC(config-if)#no spanning-tree cost 19
Уберем настройки команды cost.
После того, как мы убрали настройки команды cost, видно, что состояние порта изменилось. FastEthernet 0/14 теперь является корневым портом, а стоимость интерфейса Ethernet 0/13 равна 100 (это значение по умолчанию для интерфейсов Ethernet). Задача решена!
Извлеченный урок: убедитесь, что интерфейс, которым вы хотите сделать в качестве корневого порта, имеет наименьшую стоимость пути.
Case #2
Итак, новый сценарий. Все интерфейсы равны (FastEthernet). Коммутатор A является корневым мостом для VLAN 10, и после проверки ролей интерфейса мы находим следующее:
Хм, интересно... Коммутатор A является корневым мостом, а FastEthernet 0/17 был выбран в качестве резервного порта. Это то, что вы видите каждый день. Коммутатор B выбрал корневой порт, а все остальные интерфейсы являются альтернативными портами. Мы ничего не видим на коммутаторе С.
Мы видим, что Коммутатор A и Коммутатор B используют связующее дерево для VLAN 10. Коммутатор C, однако, не использует связующее дерево для VLAN 10. В чем может быть проблема?
Конечно, неплохо проверить, работают ли интерфейсы на коммутаторе C или нет (но, конечно, это то, что вы уже изучили и сделали в первой статье).
Интерфейсы выглядят хорошо. VLAN 10 активна на всех интерфейсах коммутатора C. Это означает, что остовное дерево должно быть активным для VLAN 10.
Давайте еще раз посмотрим на это сообщение. Это говорит о том, что остовное дерево для VLAN 10 не существует. Есть две причины, по которым можно увидеть это сообщение:
Для VLAN 10 нет активных интерфейсов.
Spanning-дерево было отключено для VLAN 10.
Мы подтвердили, что VLAN 10 активна на всех интерфейсах коммутатора C, поэтому, может быть, связующее дерево было отключено глобально?
SwitchC(config)#spanning-tree vlan 10
Вот так выглядит лучше! Теперь связующее дерево включено для VLAN 10 и работает ... проблема решена! Эта проблема может показаться немного странной, но она появляется ее время от времени в реальном мире. Сценарий, который мы рассмотрели раньше, - это событие из реальной жизни, где клиент, которому поставщик беспроводной связи отключил остовное дерево для интерфейсов, которые подключаются к точке беспроводного доступа. Ниже то, что клиент ввел на коммутаторе:
SwitchC(config)#interface fa0/1
SwitchC(config-if)#no spanning-tree vlan 10
SwitchC(config)#
В интерфейсе они набрали no spanning-tree vlan 10, но как вы видите, что они оказались в режиме глобальной конфигурации. Нет команды для отключения остовного дерева на интерфейсе, подобного этой, поэтому коммутатор думает, что вы ввели глобальную команду для отключения остовного дерева. Коммутатор принимает команду отключения остовного дерева для VLAN 10 и возвращает вас в режим глобальной конфигурации... проблема решена!
Извлеченный урок: проверьте, включено ли связующее дерево.
Case #3
Давайте продолжим по другому сценарию! Та же топология... наш клиент жалуется на плохую работу. Начнем с проверки ролей интерфейсов:
Посмотрите на картинку выше. Видите ли вы, что интерфейс FastEthernet 0/16 на коммутаторе B и коммутаторе C обозначены? На Коммутаторе A все интерфейсы обозначены. Как вы думаете, что произойдет, когда один из наших коммутаторов переадресует трансляцию или должен передать кадр? Правильно! У нас будет цикл ...
Обычно в этой топологии интерфейсы FastEthernet 0/16 и 0/17 на коммутаторе C должны быть альтернативными портами, поскольку коммутатор C имеет худший ID моста. Так как они оба обозначены, мы предполагаем, что Коммутатор C не получает BPDU на этих интерфейсах.
Так почему же остовное дерево провалилось здесь? Здесь важно помнить, что связующему дереву требуются блоки BPDU, передаваемые между коммутаторами для создания топологии без петель. BPDU могут быть отфильтрованы из-за MAC access-lists, VLAN access-maps или из-за spanning-tree toolkit?
SwitchA#show vlan access-map
SwitchB#show vlan access-map
SwitchC#show vlan access-map
Ни на одном из коммутаторов нет VLAN access maps.
SwitchA#show access-lists
SwitchB#show access-lists
SwitchC#show access-lists
Нет списков доступа...
Нет port security... как насчет команд, связанных с остовным деревом?
Вот что-то есть!Фильтр BPDU был включен на интерфейсах FastEthernet 0/16 и 0/17 коммутатора B. Из-за этого коммутатор C не получает BPDU от коммутатора B.
SwitchB(config)#interface fa0/16
SwitchB(config-if)#no spanning-tree bpdufilter enable
SwitchB(config-if)#interface fa0/17
SwitchB(config-if)#no spanning-tree bpdufilter enable
Удалим настройки фильтра BPDU.
Теперь вы видите, что FastEthernet 0/16 и 0/17 являются альтернативными портами и блокируют трафик. Наша топология теперь без петель... проблема решена!
Извлеченный урок: убедитесь, что блоки BPDU не заблокированы и не отфильтрованы между коммутаторами.
Case #4
Новая топология. Коммутатор A был выбран в качестве корневого моста для VLAN 10. Все интерфейсы являются FastEthernet каналами.
После использования команды show spanning-tree vlan 10 вот, что мы видим. Все интерфейсы одинаковы, но по какой-то причине коммутатор B решил выбрать FastEthernet 0/16 в качестве корневого порта. Разве вы не согласны с тем, что FastEthernet 0/13 должен быть корневым портом? Стоимость доступа к корневому мосту ниже, чем у FastEthernet 0/16.
Используем команду show spanning-tree interface, чтобы проверить информацию о spanning-tree для каждого интерфейса. Как вы можете видеть, существует только связующее дерево для VLAN 1, активное на интерфейсе FastEthernet 0/13 и 0/14.
Есть несколько вещей, которые мы могли бы проверить, чтобы увидеть, что происходит:
Во-первых, всегда полезно проверить, активно ли связующее дерево для определенной VLAN. Можно отключить spanning-tree с помощью команды no spanning-tree vlan X. В этом сценарии связующее дерево активно для VLAN 10, потому что мы можем видеть на FastEthernet 0/16 и 0/17.
Мы знаем, что остовное дерево активно глобально для VLAN 10, но это не значит, что оно активно на всех интерфейсах. Мы можем использовать команду show interfaces switchport, чтобы проверить, работает ли VLAN 10 на интерфейсе FastEthernet 0/13 и 0/14. Это отобразит нам некоторую интересную информацию. Вы видите, что эти интерфейсы оказались в режиме доступа, и они находятся в VLAN 1.
SwitchB(config)#interface fa0/13
SwitchB(config-if)#switchport mode trunk
SwitchB(config-if)#interface fa0/14
SwitchB(config-if)#switchport mode trunk
Давайте изменим режим интерфейсов на магистральный, чтобы трафик VLAN 10 мог проходить через эти интерфейсы.
Ну вот, теперь все намного лучше выглядит. Трафик VLAN 10 теперь передается по интерфейсу FastEthernet 0/13 и 0/14, и вы видите, что интерфейс FastEthernet 0/13 теперь выбран в качестве корневого порта. Задача решена!
Извлеченный урок: убедитесь, что VLAN активна на интерфейсе, прежде чем рассматривать проблемы связующего дерева.
В следующей статье мы расскажем, как траблшутить проблемы с EtherChannel.
NFV - виртуализация сетевых функций, это замена привычного оборудования (маршрутизаторов, коммутаторов и пр.) виртуальными аналогами, что даёт следующие возможности:
Более эффективное использование ресурсов;
Возможность использовать обычные высокопроизводительные сервера для любой задачи;
Гибкое перераспределение ресурсов.
Network Functions Virtualization
Сети операторов связи состоят из большого многообразия различного физического оборудования. Для запуска новой службы или услуги часто необходима установка нового оборудования, что влечет за собой необходимость поиска свободного места в стойке, отдельного источника питания, специалиста обладающего необходимыми компетенциями и т.д. Более того, любое физическое оборудование в конце концов выходит из строя и перестает поддерживаться производителем, что провоцирует новый цикл интеграции оборудования на замену. Однако, в настоящее время темпы развития технологий крайне высоки и жизненный цикл оборудования еще более сокращается. Виртуализация сетевых функций нацелена на трансформацию принципа построения сетей за счет эволюции стандартов в технологиях виртуализации. Это поможет консолидировать сетевое оборудование в виде виртуальных машин на высокопроизводительных серверах, открытых коммутаторах и системах хранения, которые будут находиться в ЦОДах. Как было упомянуто, наибольшего прироста можно достичь с помощью одновременного использования SDN и NFV.
На рисунке показано отношение между NFV, SDN и открытыми разработками в виде пересекающихся множеств.
Виртуализации сетевых функций NFV
Как видно из рисунка, виртуализация сетевых функций имеет общие черты с SDN технологией, однако не зависит от SDN, и наоборот. То есть NFV можно использовать без SDN, однако, при использовании сразу двух технологий можно, в перспективе, достичь хороших результатов. Кроме того, концепция SDN так же подразумевает использование мощных стандартизированных серверов и коммутаторов. Примеры использования виртуализации сетевых функций в корпоративных сетях и сетях операторов связи:
Маршрутизаторы, шлюзы;
HLR/HSS, SGN, SGSN, RNC, Node B, eNode B;
Криптошлюзы;
Офисные АТС;
Сетевые экраны и системы предотвращения нежелательного доступа;
DPI и анализаторы QoS;
Мониторинговые и биллинговые службы;
Сервера IMS - платформы;
Сервера авторизации, балансировщики нагрузки.
Преимущества виртуализации сетевых функций
Как было упомянуто, использование данной концепции предоставляет много преимуществ, таких как:
Уменьшенные капитальные расходы и токопотребление, увеличенные коэффициенты использования серверов;
Уменьшение цикла инноваций и более быстрая разработка и предоставление инноваций;
Возможность проводить тестирование, отладку на том же оборудовании, на котором запущены основные системы, что позволит сократить операционные расходы;
При наличии распределенных ЦОДов возможность быстрой ре-локации виртуального оборудования без перерыва в работе для уменьшения задержки;
Использование открытых разработок, большое количество документации, независимость от производителей оборудования;
Оптимизация сетевой конфигурации иили топологии в зависимости от нагрузки в реальном времени;
Возможность использования оркестраторов для полной автоматизации и независимости от человеческого фактора;
Отказ от дорогого закрытого оборудования;
Возможность временной реконфигурации в случае возникновения аварии, таким образом можно отказаться от операторов, следящих за состоянием сети и ЦОДа 24 часа в сутки;
Возможность обновления без перерывов в работе, с легким возвратом версии в случае возникновении неполадок, возможность дупликации оборудования и синхронизации его состояния.
Факторы, ускоряющие развитие виртуализации сетевых функций
В первую очередь, таким фактором является быстрое развитие облачных технологий и появление большого количества ЦОДов. Виртуализация уже является ядром облачных технологий, и набирает ход использование таких открытых протоколов как OpenFlow - протокол для управления SDN - контроллером коммутаторами, OpenStack - оркестратор ЦОДа.
Ранее, серьезным ограничителем являлось то, что серверные процессоры не были оптимизированы для обработки пакетов или потоков, но в настоящее время появились процессоры Intel Xeon, которые могут соперничать по производительности с граничными маршрутизаторами. Использование стандартизированных серверов на архитектуре x86 или x64, производство которых выросло за последние несколько лет позволит утилизировать преимущества NFV максимально.
Факторы, сдерживающие развитие SDN и NFV
Существует несколько известных проблем, сдерживающих быстрый рост ПКС и ВСФ:
Проблема транспортировки виртуальных машин между ЦОДами, принадлежащих различных компаниям. Необходимо создание стандартизированного интерфейса, который позволил бы перемещать виртуальные машины с любого оборудования с использованием любого ПО для виртуализации. В настоящее время по причине большого количества вендоров ПО и оборудования — это практически невозможно;
Проблема быстрого и однозначного выигрыша в производительности, так как необходимо использовать стандартные высокопроизводительные сервера, не получится использовать наработки различных вендоров, которые программно и аппаратно ускоряли обработку пакетов, потоков и т.д. Главный вопрос состоит в минимизации падения производительности по сравнению со старой схемой;
Проблема миграции с физического оборудования на виртуализированное: для массового внедрения ВСФ необходимо проводить работы одновременно на всех крупных операторах связи для поддержания работоспособности и совместимости между оборудованием и системами управления сетью, OSS/BSS. Кроме того, необходимы инструменты для осуществления миграции с физического оборудования на виртуализированное;
Стандартизация средств управления и автоматизации NFV. Использование и дальнейшее развитие ПКС позволит эффективно управлять виртуальными машинами и виртуализированным оборудованием с помощью контроллеров SDN;
Вопрос масштабируемости будет закрыт только при условии полной автоматизации всех процессов виртуализации;
Сетевая стабильность: необходима полная отказоустойчивость систем при управлении ЦОДом и автоматизации работы большого количества виртуальных машин от разных производителей оборудования. Особенно этот вопрос важен при обновлении и ре-локации систем. Вопрос безошибочного взаимодействия систем управления трафиком, балансировщиков нагрузки, контроллеров коллизий. Однако, данный вопрос до сих пор остается нерешенным в нынешних ЦОДах;
Вопрос безопасности и отказоустойчивости: необходимо доказать, что использование SDN и NFV не ухудшит состояние систем информационной безопасности. Необходимо создание сертифицированных с точки зрения безопасности гипервизоров и виртуальных машин;
Сложность управления: необходимо добиться серьезного уменьшения затрат на обслуживание и управление системами и избежать смены одной системы, на управление которой тратятся значительные ресурсы на другую;
Проблемы интеграции: необходима легкая интеграция различного виртуального оборудования с различным физическим оборудованием при присутствии на рынке предложений от большого количества производителей. Обязательна легкая интеграция новейших разработок и стороннего ПО в системы управления и взаимодействия.