faq обучение настройка
Текущее время: Пн июл 21, 2025 13:23

Часовой пояс: UTC + 3 часа




Начать новую тему Ответить на тему  [ Сообщений: 4 ] 
Автор Сообщение
СообщениеДобавлено: Чт июл 05, 2012 04:22 
Не в сети

Зарегистрирован: Пт дек 09, 2011 01:53
Сообщений: 19
Имеется следующая схема
Изображение

Сервера 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 применимые к данным сетям

Прошу посодействовать в решении вопроса.


Вернуться наверх
 Профиль  
 
СообщениеДобавлено: Вт июл 17, 2012 10:26 
Не в сети

Зарегистрирован: Пт дек 09, 2011 01:53
Сообщений: 19
Тема актуальна - по прежнему жду комментарии


Вернуться наверх
 Профиль  
 
СообщениеДобавлено: Вт июл 17, 2012 10:47 
Не в сети
Сотрудник D-LINK
Сотрудник D-LINK

Зарегистрирован: Вт янв 18, 2011 13:29
Сообщений: 8999
Где у вас настроен qinq? Между коммутаторами? Или управляющий vlan прокинут прозрачно, без qinq и пр?


Вернуться наверх
 Профиль  
 
СообщениеДобавлено: Вт июл 17, 2012 14:47 
Не в сети

Зарегистрирован: Пт дек 09, 2011 01:53
Сообщений: 19
qinq используется для агрегации dslam на 1 и 2 портах (uni). Коммутаторы, как правило, соединены через последние порты (9-12), которые являются nni. Управляющий vlan на dslam совпадает с управляющим vlan коммутатора - соответственно имеется vlan_translation replace на 1 и 2 порту.


Вернуться наверх
 Профиль  
 
Показать сообщения за:  Сортировать по:  
Начать новую тему Ответить на тему  [ Сообщений: 4 ] 

Часовой пояс: UTC + 3 часа


Кто сейчас на форуме

Сейчас этот форум просматривают: Ivan Karbovskii и гости: 10


Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете добавлять вложения

Найти:
Перейти:  
Создано на основе phpBB® Forum Software © phpBB Group
Русская поддержка phpBB