Каталог Поиск 0 Сравнить 0 Закладки 0 Корзина Войти
Каталог
105082, Москва, ул. Фридриха Энгельса, 75с21, БЦ Бауманский ИТКОЛ
Пн - Пт: с 09-00 до 18-00 Сб: с 10-00 до 18-00 Вс: выходной
Страницы: 1
RSS
Похоже, балансировка нагрузки не работает., UniFi Network
 
Всем привет! Я использую USG3 в режиме Multiwan, чтобы подключить к своей сети два одинаковых интернет-соединения (тот же роутер, тот же контракт, та же скорость). По техническим причинам нам приходится использовать каскад роутеров (знаю, не самое изящное решение, но оно должно работать только до августа). Я настроил USG для балансировки нагрузки между обоими WAN-портами, но кажется, что он в основном использует только WAN2 (видно, что на WAN1 около 400 МБ, а на WAN2 — 140 ГБ). Кто-нибудь может объяснить, почему так? Буду признателен за любую помощь. Заранее спасибо! Вот несколько скриншотов моей настройки (на немецком, но думаю, суть понятна):  
 
 
 
 
@AdrianLevi

Ты прав, это было очевидно, но я всё ещё в состоянии новичка 😛 Для того чтобы настройки в config.gateway.json сохранялись после прошивки, это действительно нужно. Я также подтвердил, что установка IP как «Echo Server» в контроллере игнорируется USG, вместо этого используется ping.ubnt.com. Теперь я настроил это в своём config.gateway.json, и всё отлично работает 😀 Для тех, кто использует eth0/eth1 как WAN, это будет выглядеть так:

{
 "load-balance": {
   "group": {
     "wan_failover": {
       "interface": {
         "eth0": {
           "route-test": {
             "initial-delay": "20",
             "interval": "10",
             "type": {
               "ping": {
                 "target": "8.8.4.4"
               }
             }
           }
         },
         "eth2": {
           "failover-only": "''",
           "route-test": {
             "initial-delay": "20",
             "interval": "10",
             "type": {
               "ping": {
                 "target": "8.8.4.4"
               }
             }
           }
         }
       }
     }
   }
 }
}

Если используется pppoe, меняйте eth0/2 на pppoe0/1, или как в моём случае — eth0.vlanID и eth2.vlanID.
 
Если это изменено в графическом интерфейсе, то изменения сохранятся. В противном случае они будут перезаписаны значениями по умолчанию или тем, что предоставляет config.gateway.json. Я «предполагаю», что config.gateway.json применяется после настроек в GUI. С уважением, Адриан
 
set load-balance group wan_failover interface pppoe0 route-test type ping target 8.8.4.4  
set load-balance group wan_failover interface pppoe1 route-test type ping target 8.8.4.4  

После выполнения этих команд, нужно ли добавлять изменения в наш config.gateway.json, или они сохранятся после повторного применения конфигурации?  
К тому же, разве мы не можем просто изменить Echo Server на IP-адрес, как на скриншоте ниже? Или это нужно указывать на обоих портах?  
 
Просто добавлю в конце (только что нашёл эту тему в объявлении о релизе 4.4.18). Я уже просто рвал на себе волосы из-за этого. У меня настроено 2 балансировщика нагрузки на USG Pro 4, которые постоянно переключались без видимых причин. Сейчас тестирую идею с проверкой маршрута на пинг к 8.8.4.4 перед тем, как внедрять её в свой config.gateway.json. Держу пальцы скрещенными.
 
У меня тоже проблемы с балансировкой нагрузки. У меня есть два PPPoE-соединения, настроенные на LB по 50% каждое. Я применил команды, приведённые выше, это решает проблему на несколько минут:

configure  
set load-balance group wan_failover interface pppoe0 route-test type ping target 8.8.4.4  
set load-balance group wan_failover interface pppoe1 route-test type ping target 8.8.4.4  
commit  
save  
exit  

Через 10 минут после выполнения команд команда show load-balance watchdog показывает:

Group wan_failover  
 pppoe0  
 статус: Ожидание восстановления (0/3)  
 пинги: 3  
 ошибки: 3  
 сбои подряд: 3/3  
 отбрасывания маршрута: 6  
 пинг-шлюз: ping.ubnt.com - НЕДОСТУПЕН  
 последнее сбросы маршрута: чт, 15 фев 11:05:17 2018  
 последнее восстановление маршрута: чт, 15 фев 11:03:08 2018  

 pppoe1  
 статус: Ожидание восстановления (0/3)  
 пинги: 3  
 ошибки: 3  
 сбои подряд: 3/3  
 отбрасывания маршрута: 5  
 пинг-шлюз: ping.ubnt.com - НЕДОСТУПЕН  
 последнее сбросы маршрута: чт, 15 фев 11:05:17 2018  
 последнее восстановление маршрута: чт, 15 фев 11:03:08 2018  

Пинг-шлюз вернулся к ping.ubnt.com вместо 8.8.4.4, заданного в командах.  
Если применить команды, то на несколько минут вывод выглядит так:

Group wan_failover  
 pppoe0  
 статус: Работает  
 пинги: 0  
 ошибки: 0  
 сбои подряд: 0/3  
 отбрасывания маршрута: 6  
 пинг-шлюз: 8.8.4.4 - ДОСТУПЕН  
 последнее сбросы маршрута: чт, 15 фев 11:05:17 2018  
 последнее восстановление маршрута: чт, 15 фев 12:07:43 2018  

 pppoe1  
 статус: Работает  
 пинги: 0  
 ошибки: 0  
 сбои подряд: 0/3  
 отбрасывания маршрута: 5  
 пинг-шлюз: 8.8.4.4 - ДОСТУПЕН  
 последнее сбросы маршрута: чт, 15 фев 11:05:17 2018  
 последнее восстановление маршрута: чт, 15 фев 12:07:42 2018  

@UBNT-cmb  

Похоже, потребуется ещё время разработки, чтобы всё это исправить, потому что я вижу много проблем с балансировкой нагрузки и аварийным переключением.
 
Небольшое предупреждение: у USG много проблем с маршрутизацией в сценариях с несколькими WAN. Одна из таких проблем — он часто пытается обратиться к DNS-серверу, полученному от DHCP сервером провайдера ISP 1, через интерфейс, подключённый к ISP 2. Ещё хуже — если смотреть tcpdump, видно, что пакеты уходят через WAN2 с исходным IP-адресом WAN1. Полный бардак и всё сломано!

Один из способов частично решить эти проблемы (но не все) — задать предпочтительные DNS-серверы для каждого WAN-интерфейса и затем создать статический маршрут к этим DNS-серверам через WAN1/2.

Получится так:  
WAN1  
Предпочтительные DNS: 8.8.4.4, 208.67.222.222  
Статический маршрут к 8.8.4.4/32 и 208.67.222.222/32 через WAN1  

WAN2  
Предпочтительные DNS: 8.8.8.8, 208.67.220.220  
Статические маршруты к 8.8.8.8/32 и 208.67.220.220/32 через WAN2  

Если DNS заработает, команда «ping ping.ubnt.com» перестанет падать из-за ошибки DNS.  

Тем не менее, я бы использовал этот трюк только для режима резервирования — балансировка нагрузки в моём опыте слишком ненадёжна.
 
Вот скрипт, который можно запустить, если хотите отслеживать смену вашего IP. Я использую для этого raspberry pi, но он будет работать на любой системе Linux. Требуется настроить SSMTP. Код простой, если захотите, можете использовать другой почтовый клиент. Я добавляю его в crontab, чтобы проверять каждые 5 минут. Поскольку стандартное поведение балансировки нагрузки сломано, этот скрипт хотя бы поможет понять, когда происходит переключение.

#!/bin/bash

TO_ADDR="OUTGOING@DOMAIN.COM"
FROM_ADDR="\"Real Name\" <USER@DOMAIN.COM>"
SUBJECT="Subject: WAN IP CHANGED"

CURRENT_IP=`curl -s -m 5 checkip.dyndns.org | sed -e 's/<[^>]*>//g' | awk -F ' ' '{print $6}' | sed -e 's/\r//g'`
echo "cur ip: $CURRENT_IP"

if [ "$CURRENT_IP" == "" ]
then
       echo "curl failed"
else

       PRE_IP=$(</tmp/lastip)

       echo "pre ip: $PRE_IP"

       PRE_HOST=`host $PRE_IP | awk -F ' ' '{print $5}'`
       CUR_HOST=`host $CURRENT_IP | awk -F ' ' '{print $5}'`

       if [ $PRE_IP != $CURRENT_IP ]
       then
               echo "IP CHANGED!"
               MSG_BODY="IP CHANGED:"$'\n'"OLD: $PRE_IP $PRE_HOST"$'\n'"NEW: $CURRENT_IP $CUR_HOST"

               echo $MSG_BODY

               MESSAGE="To: $TO_ADDR"$'\n'"From: $FROM_ADDR"$'\n'"$SUBJECT"$'\n\n'"$MSG_BODY"

               echo "SENDING: $MESSAGE"

               /usr/sbin/ssmtp -vvv "$TO_ADDR" <<< "$MESSAGE"

       else
               echo "IP SAME"
       fi

       echo "${CURRENT_IP}" > /tmp/lastip
fi
 
Только что потратил 3 часа на решение одной и той же проблемы с USG.
 
Это откровенный сбой. Пожалуйста, срочно исправьте эту проблему!
 
В USG явно есть баг при попытке разрешить имена хостов для пинга. Из-за этого происходит случайное переключение на подключение WAN2, даже когда WAN1 активен.

На USG:  
admin@USG:~$ show load-balance status  
Group wan_failover  
 interface   : eth0  
 carrier     : up  
 status      : inactive  
 gateway     : 145.14.212.1  
 route table : 201  
 weight      : 0%  
 flows  
     WAN Out : 117000  
     WAN In  : 417  
   Local Out : 217  

 interface   : eth2  
 carrier     : up  
 status      : failover  
 gateway     : 172.31.255.5  
 route table : 202  
 weight      : 0%  
 flows  
     WAN Out : 89177  
     WAN In  : 0  
   Local Out : 4758  

admin@USG:~$ show load-balance watchdog  
Group wan_failover  
 eth0  
 status: Waiting on recovery (0/3)  
 pings: 3  
 fails: 3  
 run fails: 3/3  
 route drops: 3  
 ping gateway: ping.ubnt.com - DOWN  
 last route drop   : Tue Feb  6 19:48:39 2018  
 last route recover: Tue Feb  6 19:45:56 2018  

 eth2  
 status: Waiting on recovery (0/3)  
 failover-only mode  
 pings: 98  
 fails: 3  
 run fails: 3/3  
 route drops: 5  
 ping gateway: ping.ubnt.com - DOWN  
 last route drop   : Tue Feb  6 19:48:23 2018  
 last route recover: Tue Feb  6 19:29:15 2018  

admin@USG:~$ ping ping.ubnt.com  
ping: unknown host ping.ubnt.com  

В то же время с компьютера за USG:  
$ ping ping.ubnt.com  
PING d2cnv2pop2xy4v.cloudfront.net (13.32.163.105): 56 data bytes  
64 bytes from 13.32.163.105: icmp_seq=0 ttl=243 time=52.411 ms  
64 bytes from 13.32.163.105: icmp_seq=1 ttl=243 time=15.146 ms  

Когда я указал в качестве адреса для пинга Google Public DNS (8.8.4.4), как предложено в посте выше, проблема у меня тоже решилась.
 
Я заметил точно такое же поведение. Приходится каждый раз менять шлюз пинга. Кто-нибудь уже пожаловался на этот баг официально? Определённо есть проблема с разрешением имени хоста напрямую с USG при переключении на резерв. По умолчанию должен использоваться IP-адрес или должна быть возможность настроить это в интерфейсе. Использовать имя хоста для этой функции — плохая идея.
Страницы: 1
Читают тему (гостей: 1)