По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
Как правило, EIGRP-спикер роутер динамически обнаруживает своих соседей, отправляя multicast Hello сообщения. Однако есть возможность статически настроить этих соседей и общаться с ними с помощью unicast сообщений. Это делается крайне редко, но в таких случаях может оказаться полезным.
Предыдущие статьи из цикла про EIGRP:
Часть 1. Понимание EIGRP: обзор, базовая конфигурация и проверка
Часть 2. Про соседство и метрики EIGRP
Часть 2.2. Установка K-значений в EIGRP
Часть 3. Конвергенция EIGRP – настройка таймеров
Часть 4. Пассивные интерфейсы в EIGRP
Следующие статьи из цикла:
Часть 6. EIGRP: идентификатор роутера и требования к соседству
Рассмотрим для примера Frame Relay WAN. Представьте себе, что роутер А имеет интерфейс, настроенный на десять постоянных виртуальных каналов Frame Relay (PVC). На другом конце двух этих PVC каналов находятся EIGRP-спикер роутеры. Однако другие восемь PVC каналов не подключены к EIGRP-спикер роутерам. В данной топологии, если бы WAN-интерфейс роутера A участвовал в EIGRP, то роутер A должен был бы реплицировать свое приветственное сообщение EIGRP и отправить копию всем десяти PVC, что привело бы к увеличению нагрузки на роутер A и увеличило использование полосы пропускания на других восьми PVC, не подключающихся к EIGRP роутеру. Это ситуация, при которой выигрыш состоит в статической настройке соседей EIGRP, а не от использования процесса обнаружения на основе многоадресной рассылки. Давайте рассмотрим вариант конфигурации статического соседства EIGRP в этой статье.
Статическая конфигурация соседства
Команда neighbor ip_address outgoing_interface вводится в режиме конфигурации роутера EIGRP для статического указания соседства EIGRP. Обратите внимание, что эта настройка должна быть выполнена на обоих соседях. Кроме того, имейте в виду, что IP-адрес, указанный в команде neighbor, принадлежит той же подсети, что и указанный исходящий интерфейс. На основе топологии, показанной ниже, следующие примеры настроек показывают, как роутеры OFF1 и OFF2 статически указывают друг на друга, в отличие от использования динамического обнаружения.
OFF1#conf term
Enter configuration commands, one per line. End with CNTL/Z.
OFF1(config)#router eigrp 1
OFF1(config-router)#neighbor 10.1.1.2 gig 0/1
OFF1(config-router)#end
OFF1#
OFF2#conf term
Enter configuration commands, one per line. End with CNTL/Z.
OFF2(config)#router eigrp 1
OFF2(config-router)#neighbor 10.1.1.1 gig 0/1
OFF2(config-router)#end
OFF2#
На роутере OFF1 команда neighbor 10.1.1.2 gig 0/1 введенная в режиме конфигурации роутера EIGRP, дает команду процессу EIGRP прекратить отправку многоадресных сообщений из интерфейса Gig 0/1 и вместо этого начать использовать одноадресные сообщения. Он также инструктирует процесс маршрутизации EIGRP попытаться установить соседство с EIGRP-спикер роутером, по IP-адресу 10.1.1.2 (то есть IP-адрес интерфейса Gig 0/1 роутера OFF2). Поскольку статическая конфигурация соседа должна выполняться на обоих концах канала, роутер OFF2 аналогично настроен для отправки одноадресных сообщений EIGRP со своего интерфейса Gig 0/1 и для установления соседства с EIGRP-спикер роутером с IP-адресом 10.1.1.1 (то есть IP-адресом интерфейса gig 0/1 роутера OFF1).
Проверка статического соседства
Чтобы определить, какие интерфейсы на роутере статически настроены с соседом EIGRP, можно использовать команду show ip eigrp neighbors detail. В приведенном ниже примере показано, что эта команда выполняется на роутере OFF1. Обратите внимание, что выходные данные идентифицируют 10.1.1.2 как статически настроенного соседа.
Предостережение по применению статического соседства
Рассмотрим роутер, который должен установить более чем одно соседство EIGRP с одного интерфейса, например роутер OFF2 на рисунке ниже. В этой топологии роутеры OFF1 и OFF2 динамически cформировали соседство EIGRP. Позже был добавлен роутер OFF4, и роутеры OFF2 и OFF4 были настроены как соседи EIGRP статически. Однако после того, как была сделана статическая настройка, роутер OFF2 потерял свое соседство с роутером OFF1. Причина заключается в том, что роутер OFF2 отправляет только одноадресные сообщения EIGRP со своего интерфейса Gig0/1 и хочет получать только одноадресные сообщения EIGRP, поступающие на этот интерфейс. Однако роутер OFF1 все еще настроен (с настройками по умолчанию) для отправки и ожидания многоадресных сообщений EIGRP на своем интерфейсе Gig0/1. Итак, мораль этой истории заключается в том, что если вы настраиваете интерфейс роутера для установления соседства EIGRP статически, убедитесь, что все соседи EIGRP вне этого интерфейса также настроены для соседства статически.
Дело за малым - осталось последняя статья из цикла - EIGRP: идентификатор роутера и требования к соседству.
Вопрос о балансировке нагрузки на WAN-линках встает довольно часто, и, к сожалению, в отличие от некоторых других вещей, которые можно настроить на оборудовании MikroTik быстро и безболезненно - в случае настройки Load Balancing придется немного постараться. Тема относительно сложная, наличие нескольких WAN-линков и задача по настройке балансировки нагрузки включает в себя настройку нескольких шлюзов и маршрутов по умолчанию, множество правил трансляции NAT и так далее.
Настройка маршрутизатора
Итак, в наличие у нас имеется один маршрутизатор MikroTik, который подключен к двум провайдерам - Тарс Телеком и Милайн на портах ether1 и ether2 соответственно, и локальной сетью на порту ether3. Трафик из локальной сети будет NATирован из обоих WAN портов и будет сбалансирован по нагрузке. Топология ниже:
Настраиваем локальные IP-адреса:
/ip address
add address=1.1.1.199/24 interface=ether1 comment="Tars"
add address=2.2.2.199/24 interface=ether2 comment="Meeline"
add address=192.168.1.1/24 interface=ether3 comment="LAN Gateway"
Настраиваем шлюзы по умолчанию:
/ip route
add dst-address=0.0.0.0/0 check-gateway=ping gateway=1.1.1.1,2.2.2.1
Настраиваем NAT на WAN портах для исходящего направления:
/ip firewall nat
add action=masquerade chain=srcnat comment="Tars" out-interface=ether1
add action=masquerade chain=srcnat comment="Meeline" out-interface=ether2
Если на данном этапе перестать настраивать роутер, то это будет являть собой пример настройки отказоустойчивости. Если один из линков “отвалится”, то вместо него будет использоваться второй. Однако, никакой балансировки нагрузки здесь нет и в помине, и, с экономической точки зрения, это является плохой идеей - вряд ли найдется компания, которая захочет платить абонентскую плату за второй канал и использовать его только в случае аварии.
Исходящая и входящая Mangle маркировка
Одной из типичных проблем при использовании более одного WAN-соединения является то, что пакеты принятые на одном WAN интерфейсе, могут тут же быть отправлены через другой WAN-интерфейс, что может, к примеру, сломать VPN-based сеть. Нам нужно чтобы пакеты “принадлежащие” одному и тому же соединению принимались и отправлялись через один и тот же WAN порт. В случае аварии у одного из провайдеров, все подключения на порту “умрут” и затем будут переподключены на другом WAN порту. Для этого необходимо промаркировать соединения:
/ip firewall mangle
add action=mark-connection chain=input comment="Tars Input" in-interface=ether1 new-connection-mark="Tars Input"
add action=mark-connection chain=input comment="Meeline Input" in-interface=ether2 new-connection-mark="Meeline Input"
Это поможет маршрутизатору отслеживать порт для каждого входящего подключения.
Теперь мы будем использовать отметку подключения для входящих пакетов для вызова отметки маршрутизации. Это отметка маршрутизации будет использована позднее на маршруте, который будет сообщать подключению через какой WAN-порт необходимо слать пакеты наружу.
add action=mark-routing chain=output comment="Tars Output" connection-mark="Tars Input" new-routing-mark="Out Tars"
add action=mark-routing chain=output comment="Meeline Output" connection-mark="Meeline Input" new-routing-mark="Meeline Telecom"
Помеченные подключения затем получают метку маршрута, так что роутер сможет маршрутизировать пакеты так, как нам необходимо. В следующем шаге мы настроим роутер таким образом, чтобы помеченные пакеты отправлялись наружу из корректного WAN-подключения.
Маркировка LAN маршрута
Понадобится также настроить несколько Mangle правил - они необходимы, чтобы сообщить роутеру о необходимости балансировки пакетов, которые отправляются из локальной сети. Сам механизм балансировки в этой статье не описывается, можно только сказать что происходить много операций хеширования - если же интересно копнуть глубже, то вы можете обратиться к официальной документации MikroTik. В соответствии с этими правилами маршрутизатор будет балансировать трафик приходящий на порт ether3 (LAN-порт), который направлен на любой нелокальный адрес в Интернете. Мы захватываем трафик в цепочке предварительной маршрутизации для перенаправления его на необходимый нам WAN-порт в соответствии с меткой маршрутизации.
Следующие команды балансируют трафик на LAN-интерфейсе через две группы:
add action=mark-routing chain=prerouting comment="LAN load balancing 2-0"
dst-address-type=!local in-interface=ether3 new-routing-mark=
"Out Tars" passthrough=yes per-connection-classifier=
both-addresses-and-ports:2/0
add action=mark-routing chain=prerouting comment="LAN load balancing 2-1"
dst-address-type=!local in-interface=ether3 new-routing-mark=
"Out Meeline" passthrough=yes per-connection-classifier=
both-addresses-and-ports:2/1
Настройка меток маршрутизации выше была выполнена точно такие же как и в предыдущем шаге и соответствуют тем маршрутам, которые будут созданы в следующем шаге.
Особые маршруты по умолчанию.
В данный момент у нас должны быть помечены соединения поступающие на WAN-порты и эти метки были использованы для создания меток маршрутизации. Балансировка нагрузки в LAN, описанная в предыдущем шаге, также создает метки маршрутизации в соответствии со следующим шагом, в котором будут созданы маршруты по умолчанию, которые будут захватывать трафик с данными метками маршрутизации.
/ip route
add distance=1 gateway=1.1.1.1 routing-mark="Out Tars"
add distance=1 gateway=2.2.2.1 routing-mark="Out Meeline"
Данные маршруты используются только при наличии необходимой метки маршрутизации. Непомеченные пакеты используют обычный маршрут по умолчанию.
Маршруты, относящиеся к Тарс Телеком получают метку подключения, которая вызывает метку маршрутизации. Эта метка маршрутизации совпадает с меткой в маршруте выше и обратный пакет выходит из того же интерфейса, на котором был получен изначальный пакет.
Заключение
Итого, какие шаги по настройке роутера были выполнены:
Маркировка новых подключений в WAN
Соединения с этой маркировкой получают метку маршрутизации
Исходящий из локальной сети трафик балансируется с теми же метками маршрутизации
Метки маршрутизации соответствуют маршрутам по умолчанию и отправляются из соответствующего интерфейса
Если количество WAN-линков более 2 - необходимо проделать такие же действия для остальных подключений.
Итого, теперь у вас настроена балансировка трафика для двух WAN-соединений.
В этой серии статей мы обсуждаем темы администрирования RHEV 3.5. RHEV - это решение для виртуализации Red Hat Enterprise Virtualization, основанное на проекте oVirt (open-source Virtualization project). Red Hat Enterprise Virtualization - это комплексное решение управления виртуализацией для виртуализированных серверов и настольных компьютеров.
В этой статье мы обсуждаем среду RHEV и базовое использование. RHEV состоит из двух основных компонентов, таких как гипервизор и система управления.
RHEV-H - это гипервизор платформы RHEV, который используется для размещения виртуальных машин. В основе его лежит KVM и RHEL. RHEVM - это система управления средой, которая управляет гипервизорами среды. Он также используется для создания, перемещения, изменения и управления виртуальными машинами, размещенными на гипервизорах.
Особенности RHEV 3.5
Это решение с открытым исходным кодом основывается на ядре Red Hat Enterprise Linux с технологией гипервизора виртуальной машины на основе ядра (KVM).
Поддерживаемый предел до 160 логических процессоров и 4 ТБ для каждого узла и до 160 виртуальных процессоров и до 4 ТБ памяти на виртуальную машину.
Интеграция с OpenStack.
Поддерживаются ежедневные задачи, такие как автономное перемещение, высокая доступность, кластеризация и т. д.
Необходимые условия для использования
Мы будем работать на двух узлах: "гипервизоры" и "хосты" с одним менеджером и одним узлом хранения iscsi. Потом мы добавим один IPA-и DNS-сервер в нашу среду.
Мы планируем два сценария использования:
Физическое использование - реальная среда, поэтому вам понадобится как минимум три или более физических машины.
Виртуальное использование - тестовые лаборатории/среда, поэтому вам понадобится одна физическая машина с большими ресурсами, например, процессор i3 или i5 с оперативной памятью 8G или 12G, в дополнение к другому программному обеспечению виртуализации, например Vmware workstation.
В этой серии статей мы работаем над вторым сценарием:
Physical Host OS : Fedora 21 x86_64 with kernel 3.18.9-200
RHEV-M machine OS : RHEL6.6 x86_64
RHEV-H machines hypervisor : RHEV-H 6.6
Virtualization software : Vmware workstation 11
Virtual Network interface : vmnet3
Network : 11.0.0.0/24
Physical Host IP : 11.0.0.1
RHEV-M machine : 11.0.0.3
В будущих статьях мы добавим дополнительные компоненты, такие как ноды хранения и IPA-сервер, чтобы сделать среду максимально масштабируемой.Для RHEV-M позаботьтесь заранее об:
RHEL / CentOS6. 6 x86_64 new минимальная установка (чистая установка).
Убедитесь, что система обновлена.
Выделен статический IP-адрес.
Машине назначено имя и она доступна по FQDN, например
Обновите файл файл /etc/hosts с именем хоста и IP-адресом (убедитесь, что имя хоста резолвится).
Минимальные требования - 4G для памяти и 25 GB для жесткого диска.
Mozilla Firefox 37 - это рекомендуемый браузер для доступа к WUI.
Установка Red Hat Enterprise Virtualization Manager 3.5
1. Чтобы получить доступ к пакетам и обновлениям RHEV, вы должны получить бесплатную 60-дневную пробную подписку с официального сайта red hat, используя корпоративную почту отсюда: Red Hat Enterprise Virtualization 60-дневный пробный период
Примечние: после 60-дневного периода ваша виртуалка будет работать в нормальном режиме, однако без доступа к обновлениям системы, если таковые появятся.
2. Затем зарегистрируйте свою машину в RHN (Red Hat Network).
3. Далее установим пакет rhevm и его зависимости с помощью yum.
[root@rhevm ~]# yum install rhevm
4. Теперь пришло время настроить rhevm, запустив команду "engine-setup", которая проверит состояние rhevm и любые доступные обновления, делая это в интерактивном режиме и задавая вам вопросы следующего характера:
Вопросы, связанные с устанавливаемым продуктом
Пакеты
Конфигурация сети
Конфигурация базы данных
Конфигурация движка oVirt
Конфигурация PKI
Конфигурация Apache
Конфигурация системы
Предварительный просмотр конфигурации
Подсказка: предлагаемые значения конфигурации по умолчанию указаны в квадратных скобках; если предлагаемое значение является приемлемым для вас (а чаще всего так и бывает), нажмите Enter, чтобы принять это значение.Выполните команду и понеслась!
[root@rhevm ~]# engine-setup
1. Параметры продукта
Первое, о чем инсталлятор спросит вас, это установить и настроить движок на том же хосте. В рамках пробной инсталляции оставьте значение по умолчанию (да). Если вы хотите, чтобы прокси-сервер WebSocket был настроен этом же хосте, оставьте значение по умолчанию (да).
2. Пакеты
Скрипт проверит наличие любых обновлений. На этом этапе не требуется никакого пользовательского ввода.
3. Конфигурация сети
Далее скрипт автоматически настроит iptables. Мы пока не используем DNS, поэтому убедитесь, что имя хоста (как мы и говорили ранее) резолвится, дополнительно проверим /etc/hosts, как мы делали это ранее.
4. Конфигурация базы данных
Базой данных по умолчанию для RHEV3.5 является PostgreSQL. У вас есть возможность настроить его на том же хосте или на внешнем. В статье мы будем использовать локальный вариант и пусть скрипт настроит его автоматически.
5. Конфигурация движка oVirt
В этом разделе укажите пароль администратора и application mode для вашей инсталляции. Мы укажем Both:
6. Конфигурация PKI
RHEVM использует сертификаты для секьюрного подключения к хосту. Здесь указываем organization name для сертификата:
7. Конфигурация Apache
Для веб-интерфейса пользователя RHEVM, необходимо установить и настроить веб-сервер Apache. Инсталлятор дает возможность выполнить автоматическую настройку апач - сервера, ее мы и выберем:
8. Конфигурация системы
Среда RHEV содержит библиотеку ISO - файлов, в которой вы можете хранить множество ISO ОС - то есть это просто набор исо - файлов (образов) нужных операционных систем. Эта ISO библиотека называется также доменом ISO и этот домен является общей сетевой шарой. Эта шара будет находиться на том же хосте RHEVM и вы смонтировать его вручную или позволить скрипту настроить его автоматически.
9. Предварительный просмотр конфигурации
В этом разделе вы увидите все предыдущие настройки и убедитесь, что все в порядке.
Заключение
Это последний этап, который показывает дополнительную информацию о том, как получить доступ к панели администратора и запускает службы для работы продукта:
Подсказка: На этом этапе вы можете получить Warning (предупреждение), если ПО будет не хватать оперативной памяти. Будем честными: для тестовой среды это не очень важно, просто продолжайте работать. Однако на продуктивном контуре надо быть внимательным и прислушиваться к таким предупреждениям.
Чтобы открыть веб-интерфейс пользователя RHEVM откройте URL в броузере:
http://$your-ip/ovirt-engine
Затем выберите Administrator Portal и укажите свои учетные данные пользователя: admin и пароль, который вы ввели во время установки. Нажмите кнопку Login.
Обратите внимание, что вкладка hosts пуста, так как мы еще не добавили ни одного хоста/гипервизора в нашу среду.