Имеется следующая схема

Сервера Monitoring и cacti имеют связь до коммутаторов через шлюзовой сервер(является основным шлюзом как для серверов так и для коммутаторов)
На DGS-3700-3 возникла необходимость включить qinq. Спустя пару дней после включения cacti перестал рисовать графики с коммутатора.
При диагностике выявлено следующее
Код:
user@10.4.0.185:~$ ping 192.168.156.14
PING 192.168.156.14 (192.168.156.14) 56(84) bytes of data.
^C
--- 192.168.156.14 ping statistics ---
6 packets transmitted, 0 received, 100% packet loss, time 5040ms
user@10.4.0.185:~$ traceroute 192.168.156.14
traceroute to 192.168.156.14 (192.168.156.14), 30 hops max, 60 byte packets
1 10.4.0.181 (10.4.0.181) 0.335 ms 0.320 ms 0.314 ms
2 * * *
3 * * *
Как видим связь кончается на шлюзе, НО
Код:
user@10.4.0.185:~$ ping 192.168.156.2
PING 192.168.156.2 (192.168.156.2) 56(84) bytes of data.
64 bytes from 192.168.156.2: icmp_req=1 ttl=254 time=3.03 ms
64 bytes from 192.168.156.2: icmp_req=2 ttl=254 time=2.95 ms
64 bytes from 192.168.156.2: icmp_req=3 ttl=254 time=2.76 ms
^C
--- 192.168.156.2 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2002ms
rtt min/avg/max/mdev = 2.763/2.917/3.039/0.123 ms
user@10.4.0.185:~$ traceroute 192.168.156.2
traceroute to 192.168.156.2 (192.168.156.2), 30 hops max, 60 byte packets
1 10.4.0.181 (10.4.0.181) 0.401 ms 0.381 ms 0.371 ms
2 192.168.156.2 (192.168.156.2) 12.060 ms 12.843 ms 13.617 ms
Как видим со связью до сети 192.168.156.0/27 проблем не наблюдается
Свич без проблем доступен со шлюза.
Со стороны свича проверяем доступность до сети 10.4.0.0/24
Код:
dgs3700-3:5#show iproute
Command: show iproute
Routing Table
IP Address/Netmask Gateway Interface Cost Protocol
------------------ --------------- ------------ -------- --------
0.0.0.0/0 192.168.156.1 System 1 Default
192.168.156.0/27 0.0.0.0 System 1 Local
Total Entries : 2
dgs-3700-3:5#traceroute 10.4.0.185
Command: traceroute 10.4.0.185
* Request timed out.
* Request timed out.
* Request timed out.
* Request timed out.
* Request timed out.
* Request timed out.
dgs-3700-3:5#traceroute 10.4.0.180
Command: traceroute 10.4.0.180
<10 ms 192.168.156.1
<10 ms 10.4.0.180
Trace complete.
Спустя несколько дней аналогичная ситуация происходит и сервером monitoring. При этом проблема наблюдается только на 3-м коммутаторе.
Делаем следующий тест:
C коммутатора отправляем пинг на существующие и не существующие ip из сети 10.4.0.0/24 и смотрим наличие ICMP request и reply (в теории шлюз должен фиксировать всё)
видим следующую картину:
Имеются
1. несуществующие ip на которые отвечает шлюз:
Код:
10:58:01.434079 IP 192.168.156.14 > 10.4.0.170: ICMP echo request, id 1, seq 1, length 40
10:58:02.432343 IP 192.168.156.14 > 10.4.0.170: ICMP echo request, id 1, seq 2, length 40
10:58:03.432303 IP 192.168.156.14 > 10.4.0.170: ICMP echo request, id 1, seq 3, length 40
10:58:04.435320 IP 192.168.156.1 > 192.168.156.14: ICMP host 10.4.0.170 unreachable, length 68
10:58:04.435331 IP 192.168.156.1 > 192.168.156.14: ICMP host 10.4.0.170 unreachable, length 68
10:58:04.435339 IP 192.168.156.1 > 192.168.156.14: ICMP host 10.4.0.170 unreachable, length 68
2. Существующие ip c с нормальным обменом
Код:
59:38.796527 IP 192.168.156.14 > 10.4.0.186: ICMP echo request, id 1, seq 1, length 40
10:59:38.796787 IP 10.4.0.186 > 192.168.156.14: ICMP echo reply, id 1, seq 1, length 40
10:59:39.794591 IP 192.168.156.14 > 10.4.0.186: ICMP echo request, id 1, seq 2, length 40
10:59:39.794799 IP 10.4.0.186 > 192.168.156.14: ICMP echo reply, id 1, seq 2, length 40
3. Несуществующие ip обмен до которых шлюз даже не фиксирует: к примеру - отправляя пинг на ip из диапазона 10.4.0.170-10.4.0.180
проблема наблюдается с адресами, которые заканчиваются на 172, 173, 174, 177, 179, 180
Судя по всему коммутатор играет в русскую рулетку и не отправляет пакет в дефолт.
После диагностики обновили коммутатор до версии 2.00.B033 - стабильно проработал 2 дня и ситуация повторилась.
Акцентирую на то, что 3 свич отличается от 1-го и 2-го наличием qinq. В остальном конфигурация и версия ПО идентична.
Мониторинг с сервера 10.4.0.180 осуществляется по snmp. На шлюзовом сервере отсутствуют правила firewall применимые к данным сетям
Прошу посодействовать в решении вопроса.