Gateway Monitoring при Multi-WAN
-
К роутеру с pfsense 2.5.1 подключено 2 провайдера по меди - WAN0 300Мбит/с и WAN1 200Мбит/с. Настроены Load Balancing и Failover. Настройки Gateway Settings для обоих Gateways заданы по умолчанию за исключением Monitor IP. Gateway Monitoring показывает, что качество соединения по WAN1 стабильно хуже, чем по WAN0. На порядки чаще случаются потери пакетов (packet loss), и WAN1 исключается из группы Load Balancing. Иногда это 3-10 раз в день по 1-5 минут, иногда это 1-2 раза в день по 1-8 часов, реже это 30-40 раз в день по 1-5 минуты. Бывают дни, когда всё хорошо и качество соединения по WAN1 укладывается в значения Gateway Settings по умолчанию (<20% потерь, <500мс задержки). Для Monitor IP для WAN1 я перепробовал и шлюз провайдера, и DNS провайдера, и общедоступные узлы - DNS от Яндекса, Google, OpenDNS, Cloudflare. Это никак не влияет на потерю пакетов (packet loss), и WAN1 регулярно чаще исключается из группы Load Balancing. При этом, насколько я понимаю, у WAN1 проблемы только с пингом до Monitor IP, в целом соединение с глобальной сетью по WAN1 не теряется, traceroute по WAN1 до различных узлов в интерне успешный.
Можно ли снизить проблемы с пингом до Monitor IP по WAN1 самостоятельно или при взаимодействии с провайдером? Или единственный вариант - сменить провайдера? -
@nockdown
Покажите настройки Load Balancing и Failover. -
@werter ,
System - Routing - Gateway Groups
-
Group Name: WANLoadBalancing
Gateway Priority:
WAN1INETCOM_DHCP - Tier 1
WAN0WIFIRE_DHCP - Tier 1
Trigger Level: Member Down -
Group Name: WANFailover1
Gateway Priority:
WAN1INETCOM_DHCP - Tier 1
WAN0WIFIRE_DHCP - Tier 2
Trigger Level: Packet Loss -
Group Name: WANFailover0
Gateway Priority:
WAN1INETCOM_DHCP - Tier 2
WAN0WIFIRE_DHCP - Tier 1
Trigger Level: Packet Loss
System - Routing - Default gateway
Default gateway IPv4: WANLoadBalancingFirewall — Rules — LAN
-
Action: Pass
Interface: LAN
Protocol: Any
Source: LAN net
Destination: any
Description: Default allow LAN to any rule (WANLoadBalancing)
Advanced Features — Gateway — WANLoadBalancing -
Action: Pass
Interface: LAN
Protocol: Any
Source: LAN net
Destination: any
Description: WANFailover1
Advanced Features — Gateway — WANFailover1 -
Action: Pass
Interface: LAN
Protocol: Any
Source: LAN net
Destination: any
Description: WANFailover0
Advanced Features — Gateway — WANFailover0 -
DISABLE Default allow LAN to any rule
-
-
@nockdown
В Status-Interfaces в это время
Не появляются ли
In/out errors
Collisions?Выпустите один хост на LAN явным образом через проблемного провайдера.
И помониторьте с него внешние узлы этим, например:
https://winmtr.ru
https://www.pingplotter.com
Будет ли корреляция с потерями на pfSense? -
Зачем еще и failover при loadbalance? И так резервирование будет. ИМХО, лишние группы и правила с WANFailover.
При балансировке трафик идет через 2 линка. Пропал один ВАН - ВЕСЬ трафик пойдет через другой автоматом.
Можете проверить.Зы. Галки поставить на :
System/Advanced/Miscellaneous:
Use sticky connections
Flush all states when a gateway goes down
Do not create rules when gateway is down -
@pigbrother , огромное спасибо за совет, так и сделаю!
Сейчас в Status - Interfaces у всех интерфейсов
In/out errors - 0/0
Collisions - 0
Я обязательно проверю Status - Interfaces в момент потери пакетов (packet loss). -
@werter , вы правы. Failover на случай, когда определённые протоколы или адреса нужно выпустить именно через Failover, чтобы не было балансировки.
-
@nockdown said in Gateway Monitoring при Multi-WAN:
Я обязательно проверю Status - Interfaces в момент потери пакетов (packet loss)
Все же проверка с локального хоста тоже будет не лишней.
-
К роутеру с pfsense 2.5.1 подключено 2 провайдера по меди - WAN0 300Мбит/с и WAN1 200Мбит/с. Настроен
ыLoad Balancingи Failover. Настройки Gateway Settings для обоих Gateways заданы по умолчанию за исключением Monitor IP. Gateway Monitoring показывает, что качество соединения по WAN1 стабильно хуже, чем по WAN0. На порядки чаще случаются потери пакетов (packet loss), и WAN1 исключается из группы Load Balancing. Иногда это 3-10 раз в день по 1-5 минут, иногда это 1-2 раза в день по 1-8 часов, реже это 30-40 раз в день по 1-5 минуты. Бывают дни, когда всё хорошо и качество соединения по WAN1 укладывается в значения Gateway Settings по умолчанию (<20% потерь, <500мс задержки). Для Monitor IP для WAN1 я перепробовали шлюз провайдера,и DNS провайдера, и общедоступные узлы - DNS от Яндекса, Google, OpenDNS, Cloudflare. Это никак не влияет на потерю пакетов (packet loss), и WAN1 регулярно чаще исключается из группы Load Balancing.При этом, насколько я понимаю, у WAN1 проблемы только с пингом до Monitor IP, в целом соединение с глобальной сетью по WAN1 не теряется, traceroute по WAN1 до различных узлов в интерне успешный.
UPDATE1:
Пост отредактирован, я был не прав.- Если не задавать Monitor IP для WAN1, то, насколько я понимаю, проверяется качество соединения со шлюзом провайдера. В этом случае качество соединения по WAN1 стабильное, нет потери пакетов (packet loss), и WAN1 НЕ исключается из группы Load Balancing.
- Стоит задать Monitor IP для WAN1, например на 77.88.8.7, и через 61 часов 9 минут Gateway Monitoring показывает, что заданный Monitor IP 77.88.8.7 перестаёт пинговаться, и WAN1 исключается из группы Load Balancing. При ручной диагностики в этот момент с роутера с pfsense (Diagnostics - Ping, Traceroute), если задать Source Address как WAN1:
а) ping и traceroute успешно проходят только до шлюза провайдера,
б) DNS сервера провайдера, web сайт провайдера, 8.8.8.8, 1.1.1.1, 77.88.8.3 не пингуются, traceroute до них по UDP и ICMP доходит только до шлюза провайдера и обрывается на втором скачке.
Во время потери пингов до 77.88.8.7 в Status - Interfaces у всех интерфейсов: In/out errors - 0/0, Collisions - 0. - Выключение и включение интерфейса WAN1 проблемного провайдера (Interfaces - WAN1INETCOM (igb1) - Enable interface) восстанавливает соединение по WAN1. Пинги до 77.88.8.7 начинают ходить, WAN1 возвращается в группу Load Balancing.
- Выключение и включение другого интерфейса WAN0 (Interfaces - WAN0WIFIRE (igb0) - Enable interface) в такой же ситуации также восстанавливает соединение по WAN1. Пинги до 77.88.8.7 начинают ходить, WAN1 возвращается в группу Load Balancing.
- Отключение и повторное подключение кабеля WAN1 от роутера с pfsense также восстанавливает соединение по WAN1. Пинги до 77.88.8.7 начинают ходить, WAN1 возвращается в группу Load Balancing.
UPDATE2:
- оставил в System — Routing — Gateway Groups только одну группу WANLoadBalancing, удалил группы WANFailover1 и WANFailover0,
- удалил в Firewall — Rules — LAN правила WANFailover1 и WANFailover0, оставил только правило WANLoadBalancing
Можно ли снизить проблемы с пингом до Monitor IP по WAN1 самостоятельно или при взаимодействии с провайдером? Или единственный вариант - сменить провайдера?
-
@pigbrother , я к сожалению никак не пойму, как правильно выпустить один хост из LAN явным образом через проблемного провайдера. Правилами в Firewall'е?
Во время потери пингов до 77.88.8.7 в Status - Interfaces у всех интерфейсов: In/out errors - 0/0, Collisions - 0
-
@werter ,
- оставил в System — Routing — Gateway Groups только одну группу WANLoadBalancing, удалил группы WANFailover1 и WANFailover0,
- удалил в Firewall — Rules — LAN правила WANFailover1 и WANFailover0, оставил только правило WANLoadBalancing
- включил опции:
System/Advanced/Miscellaneous:
Load Balancing - Load Balancing - Use sticky connections
Gateway Monitoring - State Killing on Gateway Failure - Flush all states when a gateway goes down
Gateway Monitoring - Skip rules when gateway is down - Do not create rules when gateway is down
Очень жалко, что включение Use sticky connections не позволяет скачивать торренты сразу по двум WAN.
-
@nockdown said in Gateway Monitoring при Multi-WAN:
я к сожалению никак не пойму, как правильно выпустить один хост из LAN явным образом через проблемного провайдера. Правилами в Firewall'е?
Да. Создаете правило для конкретного IP на LAN указав в Advanced Options нужный шлюз. Помещаете это правило выше Default allow LAN to any rule. Сбрасываете states (можно - для этого конкретного IP) .
@nockdown said in Gateway Monitoring при Multi-WAN:
что включение Use sticky connections не позволяет скачивать торренты сразу по двум WAN
Сталкивался с похожими странностями. Торренты скачиваются, выбирая произвольный шлюз. Что странно - не всегда.
@nockdown said in Gateway Monitoring при Multi-WAN:
проблемы с пингом до Monitor IP по WAN1 самостоятельно или при взаимодействии с провайдером? Или единственный вариант - сменить провайдера?
В любом случае пообщаться с провайдером стоит. Доведите до него свои наблюдения, логи.
@nockdown said in Gateway Monitoring при Multi-WAN:
igb0
Имел с такой платой проблемы, переполнялся MBUF. Пришлось в System-Advanced-System Tunables
kern.ipc.nmbclusters увеличить до 262144https://docs.netgate.com/pfsense/en/latest/hardware/tune.html
-
@pigbrother , большое спасибо за советы!
- Правило создал, жду повторения проблемы.
- Общение с провайдером к сожалению происходит на уровне:
Высылаю лог:
May 1 21:42:03 rc.gateway_alarm 50674 >>> Gateway alarm: WAN1INETCOM_DHCP (Addr:194.187.205.226 Alarm:1 RTT:.355ms RTTsd:.031ms Loss:22%) May 1 21:42:04 php-fpm 32823 /rc.openvpn: MONITOR: WAN1INETCOM_DHCP has packet loss, omitting from routing group WANLoadBalancing May 2 07:51:45 rc.gateway_alarm 70949 >>> Gateway alarm: WAN1INETCOM_DHCP (Addr:194.187.205.226 Alarm:0 RTT:.349ms RTTsd:.020ms Loss:5%) May 2 07:51:46 php-fpm 91403 /rc.openvpn: MONITOR: WAN1INETCOM_DHCP is available now, adding to routing group WANLoadBalancing
Ответ тех.поддержки: "По логам, что Вы прислали не удается определить временной интервал, когда наблюдались потери."
-
Попробуйте Падение интерфейса вместо пакетлосс пользовать для переключения на резервный ВАН.
-
@werter , спасибо. У меня так и настроено уже:
System - Routing - Gateway Groups
Group Name: WANLoadBalancing
Gateway Priority:
WAN1INETCOM_DHCP - Tier 1
WAN0WIFIRE_DHCP - Tier 1
Trigger Level: Member Down -
Попытка диагностики во время потери соединения с интернетом по проблемному WAN1:
Пинг шлюза провайдера:
PING 176.99.160.1 (176.99.160.1) from MYIP: 56 data bytes 64 bytes from 176.99.160.1: icmp_seq=0 ttl=255 time=0.324 ms 64 bytes from 176.99.160.1: icmp_seq=1 ttl=255 time=0.283 ms 64 bytes from 176.99.160.1: icmp_seq=2 ttl=255 time=0.283 ms --- 176.99.160.1 ping statistics --- 3 packets transmitted, 3 packets received, 0.0% packet loss round-trip min/avg/max/stddev = 0.283/0.296/0.324/0.019 ms
Трассировка до шлюза провайдера:
tracert 176.99.160.1 Tracing route to 176.99.160.1 over a maximum of 7 hops: 1 10.204.46.1 2.135 ms * 0.419 ms
Пинг сайта провайдера:
PING 194.187.205.230 (194.187.205.230) from MYIP: 56 data bytes --- 194.187.205.230 ping statistics --- 3 packets transmitted, 0 packets received, 100.0% packet loss
Трассировка до сайта провайдера:
tracert 194.187.205.230 Tracing route to 194.187.205.230 over a maximum of 7 hops: 1 10.204.46.1 0.302 ms 0.272 ms 0.269 ms 2 * * * 3 * * * 4 * * * 5 * * * 6 * * * 7 * * *
Пинг DNS yandex:
PING 77.88.8.7 (77.88.8.7) from MYIP: 56 data bytes --- 77.88.8.7 ping statistics --- 3 packets transmitted, 0 packets received, 100.0% packet loss
Трассировка до DNS yandex:
tracert 77.88.8.7 Tracing route to 77.88.8.7 over a maximum of 7 hops: 1 10.204.46.1 0.303 ms 0.264 ms 0.249 ms 2 * * * 3 * * * 4 * * * 5 * * * 6 * * * 7 * * *
Диагностика извне с IP 5.61.X.X:
Пинг своего IP из глобальной сети:ping MYIP Pinging MYIP with 32 bytes of data: Request timed out. Request timed out. Request timed out. Request timed out. Ping statistics for MYIP: Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),
Трассировка своего IP из глобальной сети:
tracert MYIP Tracing route to MYIP.inetcom.ru [MYIP] over a maximum of 20 hops: 1 <1 ms <1 ms <1 ms 192.168.1.1 2 <1 ms <1 ms <1 ms 5.61.8.113 3 <1 ms 8 ms 7 ms 172.30.1.17 4 1 ms 1 ms 1 ms 172.30.1.13 5 35 ms 3 ms 1 ms 198.18.9.94 6 1 ms 1 ms 1 ms 10.0.92.41 7 1 ms 6 ms 1 ms 10.0.91.9 8 1 ms <1 ms 1 ms 169.254.0.25 9 * * * Request timed out. 10 * * * Request timed out. 11 * * * Request timed out. 12 * * * Request timed out. 13 * * * Request timed out. 14 * * * Request timed out. 15 * * * Request timed out. 16 * * * Request timed out. 17 * * * Request timed out. 18 * * * Request timed out. 19 * * * Request timed out. 20 * * * Request timed out.
-
@nockdown
Покажите General с вашего пф. -
@werter , пожалуйста:
Jun 4 04:26:30 rc.gateway_alarm 16939 >>> Gateway alarm: WAN1INETCOM_DHCP (Addr:77.88.8.7 Alarm:1 RTT:7.033ms RTTsd:.041ms Loss:22%) Jun 4 04:26:30 check_reload_status 524 updating dyndns WAN1INETCOM_DHCP Jun 4 04:26:30 check_reload_status 524 Restarting ipsec tunnels Jun 4 04:26:30 check_reload_status 524 Restarting OpenVPN tunnels/interfaces Jun 4 04:26:30 check_reload_status 524 Reloading filter Jun 4 04:26:31 php-fpm 13563 /rc.openvpn: MONITOR: WAN1INETCOM_DHCP has packet loss, omitting from routing group WANLoadBalancing Jun 4 04:26:31 php-fpm 13563 77.88.8.7|X.X.X.X(myIP1)|WAN1INETCOM_DHCP|7.032ms|0.111ms|23%|down|highloss Jun 4 04:26:31 php-fpm 91403 /rc.filter_configure_sync: Gateway, switch to: WAN0WIFIRE_DHCP Jun 4 04:26:31 php-fpm 91403 /rc.filter_configure_sync: Default gateway setting Interface WAN0WIFIRE_DHCP Gateway as default. Jun 4 04:26:33 php 39413 notify_monitor.php: Message sent to X@X.X(myEmail) OK Jun 4 04:28:03 rc.gateway_alarm 11997 >>> Gateway alarm: WAN1INETCOM_DHCP (Addr:77.88.8.7 Alarm:0 RTT:5.355ms RTTsd:1.678ms Loss:5%) Jun 4 04:28:03 check_reload_status 524 updating dyndns WAN1INETCOM_DHCP Jun 4 04:28:03 check_reload_status 524 Restarting ipsec tunnels Jun 4 04:28:03 check_reload_status 524 Restarting OpenVPN tunnels/interfaces Jun 4 04:28:03 check_reload_status 524 Reloading filter Jun 4 04:28:04 php-fpm 13563 /rc.openvpn: MONITOR: WAN1INETCOM_DHCP is available now, adding to routing group WANLoadBalancing Jun 4 04:28:04 php-fpm 13563 77.88.8.7|X.X.X.X(myIP1)|WAN1INETCOM_DHCP|5.385ms|1.676ms|3%|online|none Jun 4 04:28:05 php 37030 notify_monitor.php: Message sent to X@X.X(myEmail) OK Jun 4 05:47:05 rc.gateway_alarm 90656 >>> Gateway alarm: WAN1INETCOM_DHCP (Addr:77.88.8.7 Alarm:1 RTT:7.039ms RTTsd:.059ms Loss:22%) Jun 4 05:47:05 check_reload_status 524 updating dyndns WAN1INETCOM_DHCP Jun 4 05:47:05 check_reload_status 524 Restarting ipsec tunnels Jun 4 05:47:05 check_reload_status 524 Restarting OpenVPN tunnels/interfaces Jun 4 05:47:05 check_reload_status 524 Reloading filter Jun 4 05:47:06 php-fpm 686 /rc.openvpn: MONITOR: WAN1INETCOM_DHCP has packet loss, omitting from routing group WANLoadBalancing Jun 4 05:47:06 php-fpm 686 77.88.8.7|X.X.X.X(myIP1)|WAN1INETCOM_DHCP|7.039ms|0.08ms|24%|down|highloss Jun 4 05:47:07 php 14060 notify_monitor.php: Message sent to X@X.X(myEmail) OK Jun 4 07:06:42 php-fpm 18070 /index.php: Successful login for user 'XXX(myLogin)' from: 192.168.100.5 (Local Database) Jun 4 10:15:36 rc.gateway_alarm 98839 >>> Gateway alarm: WAN0WIFIRE_DHCP (Addr:77.88.8.3 Alarm:1 RTT:8.637ms RTTsd:.370ms Loss:21%) Jun 4 10:15:36 check_reload_status 524 updating dyndns WAN0WIFIRE_DHCP Jun 4 10:15:36 check_reload_status 524 Restarting ipsec tunnels Jun 4 10:15:36 check_reload_status 524 Restarting OpenVPN tunnels/interfaces Jun 4 10:15:36 check_reload_status 524 Reloading filter Jun 4 10:15:37 php-fpm 91403 /rc.openvpn: MONITOR: WAN0WIFIRE_DHCP has packet loss, omitting from routing group WANLoadBalancing Jun 4 10:15:37 php-fpm 91403 77.88.8.3|X.X.X.X(myIP0)|WAN0WIFIRE_DHCP|8.639ms|0.379ms|23%|down|highloss Jun 4 10:15:37 php-fpm 32823 /rc.filter_configure_sync: An error occurred while trying to find the interface got 95.220.0.1 . The rule has not been added. Jun 4 10:15:37 php-fpm 32823 /rc.filter_configure_sync: An error occurred while trying to find the interface got 176.99.160.1 . The rule has not been added. Jun 4 10:16:01 php 21320 notify_monitor.php: Could not send the message to X@X.X(myEmail) -- Error: Failed to connect to ssl://smtp.gmail.com:465 [SMTP: Failed to connect socket: No route to host (code: -1, response: )] Jun 4 10:16:07 php-fpm 91403 /rc.openvpn: API to Telegram did not return data in expected format! Jun 4 10:17:00 rc.gateway_alarm 66265 >>> Gateway alarm: WAN0WIFIRE_DHCP (Addr:77.88.8.3 Alarm:0 RTT:8.720ms RTTsd:.875ms Loss:5%) Jun 4 10:17:00 check_reload_status 524 updating dyndns WAN0WIFIRE_DHCP Jun 4 10:17:00 check_reload_status 524 Restarting ipsec tunnels Jun 4 10:17:00 check_reload_status 524 Restarting OpenVPN tunnels/interfaces Jun 4 10:17:00 check_reload_status 524 Reloading filter Jun 4 10:17:01 php-fpm 91403 /rc.openvpn: MONITOR: WAN0WIFIRE_DHCP is available now, adding to routing group WANLoadBalancing Jun 4 10:17:01 php-fpm 91403 77.88.8.3|X.X.X.X(myIP0)|WAN0WIFIRE_DHCP|8.717ms|0.864ms|4%|online|none Jun 4 10:17:12 php 21320 notify_monitor.php: Message sent to X@X.X(myEmail) OK Jun 4 20:12:48 rc.gateway_alarm 45630 >>> Gateway alarm: WAN1INETCOM_DHCP (Addr:77.88.8.7 Alarm:0 RTT:7.169ms RTTsd:.943ms Loss:5%) Jun 4 20:12:48 check_reload_status 524 updating dyndns WAN1INETCOM_DHCP Jun 4 20:12:48 check_reload_status 524 Restarting ipsec tunnels Jun 4 20:12:48 check_reload_status 524 Restarting OpenVPN tunnels/interfaces Jun 4 20:12:48 check_reload_status 524 Reloading filter Jun 4 20:12:49 php-fpm 18070 /rc.openvpn: MONITOR: WAN1INETCOM_DHCP is available now, adding to routing group WANLoadBalancing Jun 4 20:12:49 php-fpm 18070 77.88.8.7|X.X.X.X(myIP1)|WAN1INETCOM_DHCP|7.166ms|0.941ms|3%|online|none Jun 4 20:12:50 php 68275 notify_monitor.php: Message sent to X@X.X(myEmail) OK Jun 4 21:27:34 php-fpm 686 /index.php: Successful login for user 'XXX(myLogin)' from: 192.168.100.5 (Local Database)
-
General - раздел настроек пф в ГУИ.
И Advanced тоже. -
This post is deleted!