Старая подсеть нашей компании была 255.255.255.0. Чтобы приспособиться к росту, мы решили внедрить подсеть 255.255.248.
После изменения этого в интерфейсе LAN нашего Sonicwall наши WAN-соединения перестали работать нормально. У нас есть 2 WAN-соединения, одно из которых используется для исходящего трафика, а другое - для входящего. Второй также настроен как аварийное переключение для первого.
Проверка связи с чем-либо, будь то внутри или вне сети, вернет несколько пакетов, а затем на несколько минут все откажет, а затем вернет еще несколько пакетов.
Я не знаю, что виноваты были порты WAN, но именно они отображаются в журнале ошибок.
Например:
Category Message Source Destination WAN Availability Probing succeeded on NAT Static IP x.x.x.x, 0, X2 4.2.2.1, 53, X2, a.resolvers.level3.net WAN Availability WLB Resource failed x.x.x.x, 0, X2 WAN Availability WLB Failover in progress x.x.x.x, 0, X2 y.y.y.y, 0, X1 WAN Availability The network connection in use is NAT Static IP y.y.y.y, 0, X1 WAN Availability Probing succeeded on NAT Static IP y.y.y.y, 0, X1 4.2.2.2, 53, X1, b.resolvers.Level3.net WAN Availability Probing succeeded on NAT Static IP y.y.y.y, 0, X1 4.2.2.1, 0, X1, a.resolvers.level3.net WAN Availability WLB Resource failed y.y.y.y, 0, X1 WAN Availability Probing failure on NAT Static IP y.y.y.y, 0, X1 4.2.2.2, 53, X1, b.resolvers.Level3.net WAN Availability Probing failure on NAT Static IP y.y.y.y, 0, X1 4.2.2.1, 0, X1, a.resolvers.level3.net WAN Availability WLB Resource is now available y.y.y.y, 0, X1 WAN Availability Probing failure on NAT Static IP x.x.x.x, 0, X2 4.2.2.1, 53, X2, a.resolvers.level3.net WAN Availability Probing failure on NAT Static IP x.x.x.x, 0, X2 4.2.2.2, 0, X2, b.resolvers.Level3.net WAN Availability WLB Resource is now available x.x.x.x, 0, X2 WAN Availability WLB Failback initiated by preemption due to a more preferred interface being operational y.y.y.y, 0, X1 x.x.x.x, 0, X2
Все это происходило в течение примерно 20 секунд и повторялось.
Нам сказали, что это была проблема с кабелями при разговоре со службой поддержки Sonicwall, но мы не смогли найти, где мы могли бы удвоить кабели. Мне также интересно, почему у нас не было бы той же проблемы в подсети 255.255.255.0.
Если бы где-то был сетевой адаптер с двумя IP-адресами в одной подсети, это вызвало бы то, что мы видим?
Помогите?