1. Изменилась логика работы проксирования в схеме с схеме с BRAS. Ранее использовались порты 3128/3129 (http/https). Начиная с версии 1.4.1 слушающий порт прокси будет открыт для каждого ядра ESR. Для ESR1000/1200 это будет:
Без форматирования |
---|
http 3128 + CPU_CORES (16) = 3128-3143 |
...
https 3144 + CPU_CORES (16) = 3144-3159 |
Для 1700:
Без форматирования |
---|
http 3128 + CPU_CORES (80) = 3128-3207 |
...
https 3208 + CPU_CORES (80) = 3208-3287 |
Нужно открыть в настройках файрвола ESR возможность пользователям подключаться на эти порты.
Для ESR1000/1200:
Без форматирования |
---|
object-group service redirect |
...
port-range 3128-3143 |
...
port-range 3144-3159 |
...
exit |
Для ESR1700:
Без форматирования |
---|
object-group service redirect |
...
port-range 3128-3207 |
...
port-range 3208-3287 |
...
exit |
2. Изменилась логика работы правил PBR. Ранее для используемой в настройке PBR на интерфейсе route-map правила обрабатывались снизу вверх.
В версии 1.4.0:
Без форматирования |
---|
route-map users |
...
rule 11 |
...
match ip access-group users_all |
...
action set ip next-hop verify-availability 10.254.0.5 10 |
...
action permit |
...
exit |
...
rule |
...
12 #Трафик начнёт обрабатываться с последнего в |
...
спиcке правила поднимаясь в вверх по порядку |
...
match ip access-group users_dns_dhcp |
...
action set ip next-hop verify-availability 10.254.0.1 10 |
...
action permit |
...
exit |
...
exit |
В версии 1.4.1 обработка будет идти по порядку следования правил сверху вниз:
Без форматирования |
---|
route-map users |
...
rule |
...
10 #Трафик начнет обрабатываться с первого правила вниз по порядку |
...
match ip access-group users_dns_dhcp |
...
action set ip next-hop verify-availability 10.254.0.1 10 |
...
action permit |
...
exit |
...
rule 11 |
...
match ip access-group users_all |
...
action set ip next-hop verify-availability 10.254.0.5 10 |
...
action permit |
...
exit |
...
exit |
3. Реализован механизм фильтрации VRRP ананосов, что бы они рассылались только в влане бриджа и не отправлялись во включенные в бридж интерфейсы:
Без форматирования |
---|
bridge 1 |
...
ports vrrp filtering |
...
enable #Запрещаем рассылку VRRP анонсов в интерфейсы, включенные в бридж |
...
ports vrrp filtering exclude vlan #Разрешаем рассылку VRRP анонсов в влане бриджа |
...
exit |
4. Для механизм VRRP реализована возможность мониторинга доступности определённого IP-адреса. В случае его недоступности VRRP инстанс перейдет в FAULT, переведя в это же состоняие всех членов группы, в которой он состоит.
Без форматирования |
---|
bridge 1 |
...
vrrp track-ip <IP |
...
адрес> #IP-адрес, доступность которого проверяется путем отправки пингов на него. ICMP должен быть разрешён в настройках файрвола удаленного стороны. |
...
vrrp track-ip packets <1- |
...
5> #Количество пингов, которое отправляется при мониторинге удаленного адреса, значение по умолчанию 1. |
...
vrrp track-ip interval <3- |
...
60> #Интервал, через который осуществляется отправка пингов, значение по умолчанию 3. |
...
exit |
Для срабатывания механизма, требуется, что бы не пришли ответы на все пинги, число которых указано в vrrp track-ip packets.
5. Реализован механизм GRE keepalive, для ESR-10, который проверяет доступность адреса внутри GRE тунеля и начинает перезапускать DHCP-клиента в слючае его недоступности.
Без форматирования |
---|
tunnel gre 1 |
...
keepalive dst-address <IP |
...
адрес> #Адрес, доступность которого мониториться. Адрес должен быть доступен через GRE. |
...
keepalive retries <1-255> |
...
keepalive timeout <1-32767> #Интервал, через который отправляються пинги, для контроля доступности удаленно адреса, по умолчанию 10.
keepalive dhcp dependent-interface <интерфейс> #Интерфейс, на котором перезапускаем DHCP-клиента, например bridge 1.
keepalive dhcp dependent-interface <интерфейс> #Ещё один интерфейс, на котором перезапускаем DHCP-клиента, например bridge 2.
keepalive enable #Включаем механизм keepalive.
#Количество пакетов PING, который отправляются через определенный интервал времени, по умолчанию 6. keepalive timeout <1-32767> #Интервал, через который отправляются пинги, для контроля доступности удаленно адреса, по умолчанию 10. keepalive dhcp dependent-interface <интерфейс> #Интерфейс, на котором перезапускаем DHCP-клиента, например bridge 1. keepalive dhcp dependent-interface <интерфейс> #Ещё один интерфейс, на котором перезапускаем DHCP-клиента, например bridge 2. keepalive enable #Включаем механизм keepalive. exit |
Важно! Для корректной работы механизма keepalive требуется чтобы на адреса, с которого терминируется GRE и время аренды адреса удовлетворяло формуле
...
6. Реализована возможность указать MTU для саб-тунеля GRE. При этом, значение этого MTU не может быть больше, чем на основном интерфейсе. При скачивании конфигурации по tftp этот параметр обязательно должен быть указан для саб-тунеля (при условии, что он указан для основного тунеля) иначе настройки для саб-тунеля не применяться, т.к. будет считаться, что у него дефолтный MTU (1500). При обновлении со старых версий ПО параметр MTU для саб-тунелей будет унаследован от родительского тунеля.
Без форматирования |
---|
tunnel gre 1 |
...
mtu 1462 |
...
mode ethernet |
...
local interface bridge 1 |
...
remote address 192.168.7.1 |
...
enable |
...
exit |
...
tunnel gre 1.1 |
...
bridge-group 3 |
...
mtu |
...
1458 #Значение MTU для саб-тунеля |
...
exit |
7. Для ESR1200/1700 реализована аппаратная поддержка EoGRE тунелей. При этом на ESR1200/1700 требуется, что бы пакеты GRE попадали на роутер через физический интерфейс. Т.к. пакет GRE распакованный из IPsec появится сразу в ядре, то его надо будет передать на ESR через физический интерфейс. Для этого потребуется вынести терминацию IPsec в отдельный VRF, а затем, соединив петлёй интерфейсы из которых GRE пакет будет выходить из VRF IPsec и передаваться в дефолтный VRF ESR. Т.к. эта схема отличается от существующей - потребуется перенастройка ESR1200/1700 OTT для возможности работы в схеме с аппартными тунелямиаппаратными туннелями. Подробнее Настройка ESR OTT в схеме с петлёй через физические порты
8. Для ESR1200/1700 реализована аппаратная поддержка EoGRE тунелейтуннелей, для корректной фиксации permanent записей для mngt адресов нужно активировать ip helper-address vrrp-group на Bridge управления. Данной командой запрещается отправка DHCP Discover пакетов, перехваченные DHCP Relay-агентом, если VRRP-группа находится в состоянии DOWN.
...