[AlKov]

Решил перенести "внутреннюю" часть маршрутизации офиса с Centos сервера на DGS-3120-24TC.

Столкнулся со странной проблемой..

Конфиг DGS-а:

IP Interface                : System
VLAN Name                   : management
Interface Admin State       : Enabled
Link Status                 : LinkUp
IPv4 Address                : 192.168.7.243/25 (Manual)  Primary
Proxy ARP                   : Disabled   (Local : Disabled)
IP Directed Broadcast       : Disabled
IPv4 State                  : Enabled
IPv6 SLAAC state            : Disabled   (Default Router: Disabled)
DHCPv6 Client State         : Disabled   (Rapid commit : Disabled)
IPv6 State                  : Disabled
DHCP Option12 State         : Disabled
DHCP Option12 Host Name     :

IP Interface                : Office
VLAN Name                   : Office
Interface Admin State       : Enabled
Link Status                 : LinkUp
IPv4 Address                : 192.168.2.250/24 (Manual)  Primary
Proxy ARP                   : Disabled   (Local : Disabled)
IP Directed Broadcast       : Disabled
IPv4 State                  : Enabled
IPv6 SLAAC state            : Disabled   (Default Router: Disabled)
DHCPv6 Client State         : Disabled   (Rapid commit : Disabled)
IPv6 State                  : Disabled

IP Interface                : servers_int
VLAN Name                   : servers_int
Interface Admin State       : Enabled
Link Status                 : LinkUp
IPv4 Address                : 10.254.213.251/24 (Manual)  Primary
Proxy ARP                   : Disabled   (Local : Disabled)
IP Directed Broadcast       : Disabled
IPv4 State                  : Enabled
IPv6 SLAAC state            : Disabled   (Default Router: Disabled)
DHCPv6 Client State         : Disabled   (Rapid commit : Disabled)
IPv6 State                  : Disabled

Command: show iproute


Routing Table

IP Address/Netmask  Gateway          Interface     Cost      Protocol
------------------  ---------------  ------------  --------  --------
0.0.0.0/0           10.254.213.250   servers_int   1         Default
10.254.213.0/24     0.0.0.0          servers_int   1         Local
192.168.2.0/24      0.0.0.0          Office        1         Local
192.168.7.128/25    0.0.0.0          System        1         Local

 

Офисная подсеть: 192.168.2.0/24

Подсеть "сервисов": 10.254.213.0/24

DHCP, DNS и NAT-сервера на Centos-6 с IP 10.254.213.250, подключён соотв. к DGS-3120.

Все подсети, включая management, в разных vlan.

 

Суть проблемы - офисные клиенты (Windows-7/Windows-XP) после старта некоторое время не могут ходить никуда, кроме шлюза и собственной подсети.

При этом с них пингуется собственно шлюз (192.168.2.250) и любой интерфейс на DGS (тот же 10.254.213.251, например).

Всё, что расположено "за" DGS-ом, не доступно. Даже тот же 10.254.213.250, с которого клиенты успешно получают сетевые реквизиты (IP/Gateway/DNS).

Не доступен также и DNS-сервер. На сервере маршрут для 192.168.2.0/24 естественно есть и все необходимые сервисы разрешены в фаерволе (iptables).

Далее.. Если на офисном клиенте открыть браузер и "потыкать" любую ссылку, то через несколько секунд чудесным образом всё начинает работать. Работает до ребута, или до "засыпания" компа.

После чего всё повторяется..

 

При разборе полётов выяснилось следующее - tcpdump-ом на сервере видно, что при старте Win клиент стучится к DNS, запрашивая какие-то свои мелкософтовые ссылки.

DNS ему исправно отвечает!! Но ответ почему-то улетает в никуда..

Аналогично "в никуда" уходят и ответы на пинги до 10.254.213.250.

В "нерабочий" момент ARP клиента на DGS присутствует.

 

Сломал весь мозг... Пробовал "понизить" версию прошивки на DGS до Build 4.04.R004 - ничего не изменилось.. Пробовал прописывать статикой ARP клиентов - то же самое..

Игрался с ARP agging time. На клиентах пробовал "статику", отключал NetBIOS, выдавал маршруты в 10.254.213.0/24 и к IP DNS.

Ничего не помогает..

Где искать эту чёрную кошку? На DGS-е? Клиентах? В кривой маршрутизации?

 

Updated.

Посмотрел wireshark-ом на клиенте стандартный запрос nslookup и параллельно на ДНС сервере.

На ДНС запрос приходит, он отвечает. В это время на клиенте тишина (только запрос).

Делаю ещё раз nslookup - аналогично. Делаю третий раз - перед последним пакетом запроса, клиент отправляет "Who has 192.168.2.250" (шлюз). DGS отвечает, и после этого ответ DNS приходит клиенту.

Что бы это могло значить? Почему клиент теряет шлюз?

Изменено 21 мая, 2017 пользователем AlKov

[Butch3r]

Какая версия прошивки?

[AlKov]

Какая версия прошивки?

 

... Пробовал "понизить" версию прошивки на DGS до Build 4.04.R004

Сейчас эта. До танцев с бубном была самая последняя - Build 4.11.R006

Разницы никакой..

[gr0mW]

А в DHCP shared-network или просто subnet клиентов? Попробуйте настроить shared-network и прописать в нем типа

 

shared-network OFFICE {

shared-network-specific parameters...

subnet 192.168.2.0 netmask 255.255.255.0 {

subnet-specific parameters...

range 192.168.2.X 192.168.2.Y;

}

subnet 10.254.213.0 netmask 255.255.255.0 {

subnet-specific parameters...

range 10.254.213.X 10.254.213.Y;

}

shared-network MANAGEMENT {

и.тд

клиент и сервер должна быть в одной подсети shared-network

Изменено 20 мая, 2017 пользователем gr0mW

[AlKov]

А в DHCP shared-network или просто subnet клиентов? Попробуйте настроить shared-network и прописать в нем типа

...

 

А для чего это? Подсеть 10.254.213.0/24 сконфигурирована статикой. Для 192.168.2.0/24 DHCP имеет следующую конфигурацию

#
shared-network Office  {
#
###########################
# Office subnet           #
###########################
#
subnet 192.168.2.0 netmask 255.255.255.0 {

   authoritative;
   deny unknown-clients;
   deny duplicates;
   option routers                  192.168.2.250;
   option subnet-mask              255.255.255.0;
   option broadcast-address        192.168.2.255;

   ddns-domainname                 "mydomain.com";
   option domain-name-servers      XXX.YYY.ZZZ.76;

   option time-offset              10800;
   option time-servers             10.254.213.250;
   option ntp-servers              10.254.213.250;
   option ms-classless-static-routes       29, XXX,YYY,ZZZ,72, 192,168,2,250, 24, 10,254,213, 192,168,2,250; 
   option rfc3442-classless-static-routes  29, XXX,YYY,ZZZ,72, 192,168,2,250, 24, 10,254,213, 192,168,2,250;
   default-lease-time 21600;
   max-lease-time 43200;
#
# disable NetBIOS
   vendor-option-space MSFT;
   option MSFT.DisableNetBIOS 2;
   option MSFT.ReleaseOnShutdown 1;
#
#
   option microsoft.disable-netbios-over-tcpip 2;
#
# End 192.168.2.0/24 subnet
}
#
# End of shared-network Office
#
}
#

Да и не в DHCP, похоже, дело, т.к. клиенты ИСПРАВНО получают и ПРИМЕНЯЮТ выдаваемые DHCP-сервером опции.

Выяснился ещё один архистранный момент.

Если на машине с CentOS выполнить nmap -sn 10.254.213.0/24, то через пару секунд с неё пропадает доступ в подсеть 192.168.2.0/24 !!

Доступ восстанавливается, если на DGS выполнить clear arp... Никак не могу это упорядочить в мозгУ...

Каким боком скан подсети 10... может повлиять на подсеть 192...??? Причём свихивается от этого именно DGS..

Сначала подумалось, что скан переполняет ARP таблицу на DGS, но show arpentry на нём (перед clear) говорит, что ARP записей ~90..

Вообщем, зашёл в ступор вместе с DGS-ом, но в отличие от него, мне clear arp не помогает. Пойти принять стакан что ли.?? :-)

[infery]

Кто ж в здравом уме длинки как L3 использует...

Изменено 20 мая, 2017 пользователем infery

[AlKov]

Кто ж в здравом уме длинки как L3 использует...

Наверное, не здоровые умом производители длинков, кому ж ещё? ;)

Ну и некоторые товарищи, им поверившие в

Управляемый коммутатор 3 уровня

вот тут.

Видимо, сиё написано, как на заборе.. Оказались дрова.. :)

[AlKov]

Принял стакан.. Чуток полегчало (мне, но не задаче) и потянуло на "философию" (меня, конечно же).. :-)

От этого возник вопрос - "а для чего же тогда, с точки зрения вендора, тогда всё это предназначено?"

Функции уровня 3

• Макс. количество IP-интерфейсов: 16

• ARP Proxy

• VRRP

• IPv6 Neighbour Discovery (ND)

• Туннелирование IPv6

 

Функции маршрутизации

• Статическая маршрутизация

- 512 записей о статической маршрутизации для IPv4/IPv6

• RIP

• OSPF

• IP Directed Broadcast

По своему "скудоумию" предположил, что всё это для использования железки в качестве "static/RIP/OSPF" полноценного маршрутизатора..

Ошибаюсь? И всё это не более чем маркетинговые выверты?

Или всё же, не к ночи будет помянуто - "если ... (тьфу-тьфу три раза).. не работает, то это значит, не умеем его готовить" ;-) ?

[Butch3r]

Кто ж в здравом уме длинки как L3 использует...

но при этом народ юзает снр, итекс, кутеч на л3 и всё норм. А вот длинк юзать нельзя :)

У меня стоят 3120 как л3. пим+оспф. Всё работает, вот только я использую 3 ветку софта.

 

Вот только почему возникают выше перечисленные проблемы сказать не готов.

[NiTr0]

По своему "скудоумию" предположил, что всё это для использования железки в качестве "static/RIP/OSPF" полноценного маршрутизатора..

Ошибаюсь? И всё это не более чем маркетинговые выверты?

ну почему же. оно как-то работает. и для офиса, скорее всего, его должно хватить. но, конечно, тараканов у них имеется, и чем больше фич юзать - тем жирнее тараканы лезут.

 

их обычно не используют как л3 там, где важна безотказная работа годами, и где есть много клиентов.

[AlKov]

ну почему же. оно как-то работает. и для офиса, скорее всего, его должно хватить. но, конечно, тараканов у них имеется, и чем больше фич юзать - тем жирнее тараканы лезут.

 

их обычно не используют как л3 там, где важна безотказная работа годами, и где есть много клиентов.

Именно в таком сегменте и хочу использовать. Клиентов не более 30, из всех "фич" - статический роутинг, ну может ещё RIP, да и то без особой надобности.

Butch3r, а Вы не в курсе, можно ли откатиться с 4-й на 3-ю ветку софта? Где-то читал, что могут быть проблемы, но не помню, какие именно..

 

И вообще, не связана ли описываемая проблема с неудачным дизайном сети? В 10.254.213.0/24 у меня немало другого железа.

В-основном, те же DSG-ы и сервера на CentOS и FreeBSD. Всё находится в одном L2 сегменте, в отдельном vlan.

[hRUst]

Покажите маршрутизацию на сервере

[AlKov]

Покажите маршрутизацию на сервере

[root@router ~]# route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
XXX.YYY.ZZZ.72     0.0.0.0         255.255.255.248 U     0      0        0 vlan61
192.168.33.0    10.254.213.251  255.255.255.128 UG    0      0        0 vlan7
192.168.6.0     10.254.213.17   255.255.255.0   UG    0      0        0 vlan7
192.168.2.0     10.254.213.251  255.255.255.0   UG    0      0        0 vlan7
10.254.213.0    0.0.0.0         255.255.255.0   U     0      0        0 vlan7
192.168.13.0    0.0.0.0         255.255.255.0   U     0      0        0 vlan13
192.168.10.0    10.254.213.251  255.255.255.0   UG    0      0        0 vlan7
192.168.4.0     10.254.213.251  255.255.252.0   UG    0      0        0 vlan7
192.168.16.0    10.254.213.251  255.255.240.0   UG    0      0        0 vlan7
0.0.0.0         XXX.YYY.ZZZ.74     0.0.0.0         UG    0      0        0 vlan61

[Butch3r]

ну почему же. оно как-то работает. и для офиса, скорее всего, его должно хватить. но, конечно, тараканов у них имеется, и чем больше фич юзать - тем жирнее тараканы лезут.

 

их обычно не используют как л3 там, где важна безотказная работа годами, и где есть много клиентов.

Именно в таком сегменте и хочу использовать. Клиентов не более 30, из всех "фич" - статический роутинг, ну может ещё RIP, да и то без особой надобности.

Butch3r, а Вы не в курсе, можно ли откатиться с 4-й на 3-ю ветку софта? Где-то читал, что могут быть проблемы, но не помню, какие именно..

 

И вообще, не связана ли описываемая проблема с неудачным дизайном сети? В 10.254.213.0/24 у меня немало другого железа.

В-основном, те же DSG-ы и сервера на CentOS и FreeBSD. Всё находится в одном L2 сегменте, в отдельном vlan.

Да вроде можно откатываться, но я не пробовал

[AlKov]

Да вроде можно откатываться, но я не пробовал

 

Вот нашёл

updated 22.05.2014

ВАЖНО!!! Откатывать коммутаторы rev.B1, которые из коробки идут с R4, до прошивок R3 не рекомендуется, т.к. слетит лицензия с RI/EI до SI. Для восстановления придется обращаться к нам с выводом show switch и фотографиями наклеек с корпуса коммутатора.

тут, но не знаю, что за фирмварь была на моём DGS-е из коробки..

Да и что-то уже нет никакой уверенности, что откат решит проблему..

[vurd]

Дело явно не в длинке. Этот свитч используют на сегменты в реальных сетях, нет таких проблем с ним.

Дело в какой-нибудь дубликате ip-адресов, видно же, что чинится всё после clear arp. Надо смотреть что там за маки, сравнивать. Кароче, обычная диагностика при конфликте ip.

Сделайте миррор порта с офисной сетью в конце концов, посмотрите что там бегает после запуска пк.

[Butch3r]

Дело явно не в длинке. Этот свитч используют на сегменты в реальных сетях, нет таких проблем с ним.

Дело в какой-нибудь дубликате ip-адресов, видно же, что чинится всё после clear arp. Надо смотреть что там за маки, сравнивать. Кароче, обычная диагностика при конфликте ip.

Сделайте миррор порта с офисной сетью в конце концов, посмотрите что там бегает после запуска пк.

Да, у меня тоже нет таких проблем.

[AlKov]

Дело явно не в длинке. Этот свитч используют на сегменты в реальных сетях, нет таких проблем с ним.

Дело в какой-нибудь дубликате ip-адресов, видно же, что чинится всё после clear arp. Надо смотреть что там за маки, сравнивать. Кароче, обычная диагностика при конфликте ip.

Сделайте миррор порта с офисной сетью в конце концов, посмотрите что там бегает после запуска пк.

Думал уже над этим.. Я с самого начала, ещё до написания поста, склонялся к этому же. В первую очередь облазил всю сеть на предмет дубликатов, но ничего не нарыл..

Возможно, конечно, что просто не нашёл, где-то глубоко зарыто..

Да и не очень похоже оно на конфликт IP. В этом случае свитч в лог матерится типа таким "Conflict IP was detected with this device.."

И "чинится всё после clear arp" только в случае, если сканер запустить.

Можно вообще ничего не "чинить", просто тупо потыкаться браузером в интернет, и всё заработает.

Тут что-то другое..

[vurd]

Ага, подземные стуки, видимо, тут.

Я не понимаю проблемы соснифать что там происходит. 99% где-то в arp надо искать.

Миррорите порт, тыкаете бук, запускаете шарк с фильтром arp, запускаете сканер свой, который приводит к проблеме, потом чините, сохраняете дамп и минут 30 на анализ. Всё. Чо гадать сидеть, не понимаю.

Ну еще варианты, что это марсиане или ким чен ын лично спуфит арпы.

[AlKov]

Т.к. на данный момент физического доступа к DGS-у нет (он в серверной, я дома), решил тупо поснифать ARP на клиенте (домашний комп. в офисной подсети).

Увидел странную (на мой взгляд) ситуацию - DGS довольно часто (до 10 запросов в секунду) шлёт "Who has 192.168.2..." на несуществующие IP подсети.

Причём инициатором запроса является именно DGS. Вот например

20:31:36.516879000 78:54:2e:b8:08:20 ff:ff:ff:ff:ff:ff ARP 60 Who has 192.168.2.107? Tell 192.168.2.250

Что примечательно, IP 192.168.2.107 никому никогда в сети не назначался.

Это нормально? Если "нет", то что сие может означать?

 

P.S. Посмотрел также tcpdump-ом подсеть 10.254.213.0/24, там такого безобразия не наблюдается. Правда, в этой подсети нет ни одного Win клиента.

[myth]

Ну, если эту подсеть сканировали, то это, в принципе, нормально

[edo]

Решил перенести "внутреннюю" часть маршрутизации офиса с Centos сервера на DGS-3120-24TC.

оффтопик конечно, но есть ли в этом смысл?

я завожу все vlan на linux-хост, он уже занимается роутингом/фильтрацией/шейпингом. производительности хватает, удобно, что все фильтры в одном месте.

[AlKov]

Ну, если эту подсеть сканировали, то это, в принципе, нормально

Гм.. Вы хотите сказать, что если подсеть хоть один раз сканировали, то DGS будет вечно флудить арпами?!

И это для него "нормально"?! И почему запросы идут от DGS, а не от машины-сканера?

Бред какой-то...

[myth]

потому что он маршрутизатор и сканирование идет через него. И не постоянно, а определенное время. Скорее всего, время жизни арп записи.

[Butch3r]

Решил перенести "внутреннюю" часть маршрутизации офиса с Centos сервера на DGS-3120-24TC.

оффтопик конечно, но есть ли в этом смысл?

я завожу все vlan на linux-хост, он уже занимается роутингом/фильтрацией/шейпингом. производительности хватает, удобно, что все фильтры в одном месте.

да нормально эта схема на л3 свичах работает.