АК
координатор программный?
Size: a a a
2019 April 12
АК
по какому адресу координатор видит клиента, по физическому или виртуальному?
АК
на хв, в секции клиента поле accessip
AB
на хв, в секции клиента поле accessip
на вебке смотреть?
АК
можно через веб, можно через консоль (iplir show config)
АК
лутше маршруты переделайте
АК
для смены на реальный, надо будет поиграть с параметром visibility на хв
АК
незачто
Z
так сдали его свои же
Не верю! Русские своих на войне не бросают и не сдают!
A
Вот в чем магия и хорошо ли это для синхронизации ЦОДов по L2?
Коллеги, речь шла о L3.
OM
ALEXEY
Коллеги, речь шла о L3.
То есть на L2 в один поток будут такие же скорости, а задержки 100мс не будет?
A
Релиз 4.3.0 Список изменений (по сравнению с 4.2.4):
• Политики маршрутизации и проверка состояния шлюзов (Dead Gateway Detection, DGD)
Реализованы механизмы, позволяющие распределить нагрузку на сеть или настроить резервные каналы доступа в Интернет для сетей, в инфраструктуре которых используется несколько шлюзов (провайдеров):
• Пользовательские таблицы маршрутизации. С их помощью вы можете задать маршруты для различных ситуаций. Например, основную таблицу маршрутизации и дополнительную таблицу на случай, если шлюз основного провайдера станет недоступен и потребуется перенаправить трафик через шлюз альтернативного провайдера.
• Политики маршрутизации. С их помощью вы можете задать условия, при которых трафик будет перенаправляться по тем или иным маршрутам.
• Проверка состояния шлюзов (DGD). С помощью этой функции вы можете задавать выполнение политики маршрутизации в зависимости от доступности или недоступности шлюза. Данная функция также может использоваться для динамических сетевых интерфейсов (Wi-Fi, 3G).
• Оптимизированный механизм автоматического переключения на альтернативный канал связи с координатором
Оптимизирован механизм автоматического переключения на альтернативный канал связи с координатором при потере связи по основному каналу во время активной передачи данных. Теперь автоматическое переключение на альтернативный канал связи занимает не больше 10 секунд.
• Усовершенствованный механизм работы кластера горячего резервирования
В предыдущих версиях в кластере горячего резервирования необходимо было назначать дополнительные IP-адреса интерфейсам пассивного узла (passiveip в секциях [channel] конфигурационного файла failover.ini).
В HW версии 4.3.0 сетевым интерфейсам пассивного узла не назначаются IP-адреса, поэтому больше данный параметр не используется.
При этом проверка доступности интерфейсов активного узла кластера горячего резервирования пассивным происходит с помощью отправки ARP-запросов в режиме проверки наличия дублирующего IP-адреса.
Кроме того, повышена достоверность проверки работоспособности сетевого интерфейса путем опроса тестового IP-адреса, задаваемого с помощью параметра testip секции [channel] в конфигурационном файле failover.ini, так как теперь проверка производится только с сетевого интерфейса, указанного в данной секции.
• Расширенная функциональность DHCP-сервера
DHCP-сервер получил следующие новые функции:
• Работа в кластере горячего резервирования;
• Передача DHCP-клиентам дополнительных параметров сети, таких как:
o широковещательный IP-адрес;
o IP-адреса DNS- и NTP-сервера;
o имя домена;
o резервирование IP-адреса для заданного сетевого узла,
o и другие опции DHCP-сервера.
• Передача параметров сети DHCP-клиентам, находящимся в удаленной подсети;
• Работа с несколькими сетевыми интерфейсами. DHCP-сервер может работать на разных сетевых интерфейсах одновременно, и для каждого интерфейса можно задать свой набор параметров.
• Расширенная функциональность DHCP-relay
Для агента DHCP-relay были реализованы следующие полезные функции:
• Одновременное использование DHCP-сервера и DHCP-relay.
• Запуск нескольких процессов DHCP-relay для нескольких сетевых интерфейсов на одном ViPNet Coordinator HW.
• Возможность указать запасной DHCP-сервер.
• Возможность указать туннелируемый DHCP-сервер.
• Новая команда для проверки доступности активного узла кластера горячего резервирования
Добавлена команда failover show active-mac-address, позволяющая проверить, доступен ли активный узел кластера горячего резервирования со стороны пассивного узла.
• Улучшенная работа TCP-туннеля
Улучшена работа TCP-туннеля через неустойчивые каналы связи, для которых характерны потери IP-пакетов.
• Оптимизированный механизм определения IP-адреса доступа координатора по доменному имени (DNS-имени)
Оптимизирован механизм определения IP-адреса доступа по доменному имени и восстановления соединения с координаторами, IP-адреса которых периодически меняются. Теперь восстановление связи с такими координаторами занимает не более 10 секунд.
• Просмотр ARP-таблицы с фильтрацией по параметрам
Теп
• Политики маршрутизации и проверка состояния шлюзов (Dead Gateway Detection, DGD)
Реализованы механизмы, позволяющие распределить нагрузку на сеть или настроить резервные каналы доступа в Интернет для сетей, в инфраструктуре которых используется несколько шлюзов (провайдеров):
• Пользовательские таблицы маршрутизации. С их помощью вы можете задать маршруты для различных ситуаций. Например, основную таблицу маршрутизации и дополнительную таблицу на случай, если шлюз основного провайдера станет недоступен и потребуется перенаправить трафик через шлюз альтернативного провайдера.
• Политики маршрутизации. С их помощью вы можете задать условия, при которых трафик будет перенаправляться по тем или иным маршрутам.
• Проверка состояния шлюзов (DGD). С помощью этой функции вы можете задавать выполнение политики маршрутизации в зависимости от доступности или недоступности шлюза. Данная функция также может использоваться для динамических сетевых интерфейсов (Wi-Fi, 3G).
• Оптимизированный механизм автоматического переключения на альтернативный канал связи с координатором
Оптимизирован механизм автоматического переключения на альтернативный канал связи с координатором при потере связи по основному каналу во время активной передачи данных. Теперь автоматическое переключение на альтернативный канал связи занимает не больше 10 секунд.
• Усовершенствованный механизм работы кластера горячего резервирования
В предыдущих версиях в кластере горячего резервирования необходимо было назначать дополнительные IP-адреса интерфейсам пассивного узла (passiveip в секциях [channel] конфигурационного файла failover.ini).
В HW версии 4.3.0 сетевым интерфейсам пассивного узла не назначаются IP-адреса, поэтому больше данный параметр не используется.
При этом проверка доступности интерфейсов активного узла кластера горячего резервирования пассивным происходит с помощью отправки ARP-запросов в режиме проверки наличия дублирующего IP-адреса.
Кроме того, повышена достоверность проверки работоспособности сетевого интерфейса путем опроса тестового IP-адреса, задаваемого с помощью параметра testip секции [channel] в конфигурационном файле failover.ini, так как теперь проверка производится только с сетевого интерфейса, указанного в данной секции.
• Расширенная функциональность DHCP-сервера
DHCP-сервер получил следующие новые функции:
• Работа в кластере горячего резервирования;
• Передача DHCP-клиентам дополнительных параметров сети, таких как:
o широковещательный IP-адрес;
o IP-адреса DNS- и NTP-сервера;
o имя домена;
o резервирование IP-адреса для заданного сетевого узла,
o и другие опции DHCP-сервера.
• Передача параметров сети DHCP-клиентам, находящимся в удаленной подсети;
• Работа с несколькими сетевыми интерфейсами. DHCP-сервер может работать на разных сетевых интерфейсах одновременно, и для каждого интерфейса можно задать свой набор параметров.
• Расширенная функциональность DHCP-relay
Для агента DHCP-relay были реализованы следующие полезные функции:
• Одновременное использование DHCP-сервера и DHCP-relay.
• Запуск нескольких процессов DHCP-relay для нескольких сетевых интерфейсов на одном ViPNet Coordinator HW.
• Возможность указать запасной DHCP-сервер.
• Возможность указать туннелируемый DHCP-сервер.
• Новая команда для проверки доступности активного узла кластера горячего резервирования
Добавлена команда failover show active-mac-address, позволяющая проверить, доступен ли активный узел кластера горячего резервирования со стороны пассивного узла.
• Улучшенная работа TCP-туннеля
Улучшена работа TCP-туннеля через неустойчивые каналы связи, для которых характерны потери IP-пакетов.
• Оптимизированный механизм определения IP-адреса доступа координатора по доменному имени (DNS-имени)
Оптимизирован механизм определения IP-адреса доступа по доменному имени и восстановления соединения с координаторами, IP-адреса которых периодически меняются. Теперь восстановление связи с такими координаторами занимает не более 10 секунд.
• Просмотр ARP-таблицы с фильтрацией по параметрам
Теп