1,106 posts in this topic

Ситуация:

Домашняя сетка

Роутер Mikrotik

за ним зоопарк устройств (win 7, win 8, linux, разные версии android)

роутер раздает 192.168.88.*

Пару дней назад, внезапно:

 

win 7, старый android получают адреса из диапазона 192.168.88.* интернета НЕТ

 

win 8, linux, новый android берут хз где адреса из диапазона 178.140.*.* + ipv6 адрес интернет ЕСТЬ

 

ротер тоже интернет раздает, но сам его не видит (не может проверить наличие прошивок)

 

что это? и как с этим бороться?

 

 

0

Share this post


Link to post
Share on other sites
что это? и как с этим бороться?

 

Опять же, предупреждаю, что опыт практической работы с сетями у меня ограниченный, но соображения следующие:

1. broadband-178-140-*-*.nationalcablenetworks.ru — это диапазон адресов из автономной системы ОнЛайма (судя по привязанным доменным именам). То есть, ваши устройства получают «сквозь» роутер внешние IP-адреса.

2. Необходимо проверить, есть ли доступ к Интернет по IPv4 в принципе. Т.к., ио вашим показаниям, доступ есть только с устройств, где есть IPv6-адрес.

3. Базовое предположение: видимо, роутер чем-то прошился и на нём включился механизм трансляции DHCP пакетов (DHCP Relay Agent, или что-то в этом роде). Другими словами, вместо того, чтобы обрабатывать DHCP-запросы от устройств локальной сети и выдавать в ответ адреса из своего пула 192.168.188.0, стал пересылать запросы дальше, на DHCP-сервера ОнЛайма, что объясняет появление внешних адресов во внутренней сети. Как это сказалось на маршрутизации — сильно зависит от настроек маршрутизатора, но что там пошла полная неразбериха — это точно.

 

Рекомендация: создать резервную копию настроек маршрутизатора, после чего отключить маршрутизацию IPv6 и все вспомогательные сервера: DHCP, DNS,… и функции. Затем возвращать из по одной, начиная с самых важных. Это позволит выявить источник проблемы.

0

Share this post


Link to post
Share on other sites

Подскажите, пожалуйста, кто-нибудь пробовал настроить ipv6 на DD-WRT?

На кастоме асуса все работает, а на DD-WRT роутер не раздает ipv6, получаю только Локальный IPv6-адрес канала . . . : fe80::..., ping6 ya.ru с роутера проходит.

 

IPv6 - Enable

IPv6 Type - DHCPv6 with Prefix Delegation

Prefix Length - 64

Dhcp6s - Enable

Radvd - Enable

0

Share this post


Link to post
Share on other sites
на вывод команды

netsh int ipv6 show neighbors

шлюз по умолчанию сразу после перезагрузки пишет Reachable, а через 10-15 мин Stale

Решить проблему можно прописав постоянную запись для шлюза по умолчанию в таблицу "соседей" командой

netsh int ipv6 add neighbors <....> store=persistent

 

Работает постоянно, после перезарузки не слетает, при необходимости удаляется командой

netsh int ipv6 delete neighbors

Edited by Seva5
0

Share this post


Link to post
Share on other sites
Решить проблему можно прописав постоянную запись для шлюза по умолчанию в таблицу "соседей" командой

netsh int ipv6 add neighbors <....> store=persistent

 

В моём случае не помогает — симптомы прежние, адрес иногда вообще не выдаётся, иногда выдаётся, но не может обновиться.

0

Share this post


Link to post
Share on other sites

Сегодня входящий IPv6 трафик пропал почти полностью. Приходят только ответы на запросы Neighbour Solicitation от маршрутизатора. Ответы на DHCP Solicit не приходят.

Edited by KMickle
0

Share this post


Link to post
Share on other sites

Что-то зарубеж отвалился, с впски пинг6 домашнего адреса пишет: Destination unreachable: No route.

0

Share this post


Link to post
Share on other sites
Сегодня входящий IPv6 трафик пропал почти полностью. Приходят только ответы на запросы Neighbour Solicitation от маршрутизатора. Ответы на DHCP Solicit не приходят.

 

Прикрепил снапшот обмена между вашим оборудованием и маршрутизатором онлайм.

Дамп снят на маршрутизаторе, т.е. до вашего оборудования есть еще цепочка коммутаторов.

Видно, что Онлайм отправляет вам Advertise сообщение протокола dhcpv6.

По вашим словам, вы его не видите.

С сетевой точки зрения, это возможно, только если вы смотрите пакеты в сниффере на компьютере, а сетевая карточка у вас производства TP-Link. Если это не так, и у вас CPE TP-Link, то пакеты вы в снифере не смотрели.

Это совсем другая история.

Расскажите, что там у вас.

 

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

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

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

 

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

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

Повторюсь, проблемы решаем сейчас только с прямым подключением к онлайм без маршрутизатора.

Все проблемы с CPE пока отложим, т.к. их может быть слишком много сейчас для анализа.

post-6660-1427878702_thumb.jpg

0

Share this post


Link to post
Share on other sites
Что-то зарубеж отвалился, с впски пинг6 домашнего адреса пишет: Destination unreachable: No route.

Ап. У вас, примерно с 03:05 31.03.2015, BGP-роута префикса нет ни на одном зарубежном Looking glass: проверил lg.he.net и www.sprint.net/lg/ :(

 

Wed Apr  1 11:15:46.120 UTC
% Network not in table

0

Share this post


Link to post
Share on other sites

Проблема с IPV6 всеже есть . Хоть адрес и получаю дальше никуда по v6 не пройдешь (и через роутер ,и напрямую) . Странно хотя ping google.com идет по v6

0

Share this post


Link to post
Share on other sites
Прикрепил снапшот обмена между вашим оборудованием и маршрутизатором онлайм.

Дамп снят на маршрутизаторе, т.е. до вашего оборудования есть еще цепочка коммутаторов.

Видно, что Онлайм отправляет вам Advertise сообщение протокола dhcpv6.

По вашим словам, вы его не видите.

 

Как правило, отклики Advertise мне приходят. Их отсутствие — какая-то временная аномалия, относительно непродолжительная и редкая (было 2 раза за последнюю неделю в пределах нескольких часов). В остальное время в моих дампах присутствует и Solicit от клиента, и Advertise от сервера.

 

Проблема проявляется в том, что при получении Advertise клиент его (по всей видимости) дропает, причём, безо всяких записей в лог.

 

Я внимательно изучил пакеты Solicit, которые отправляет клиент и обнаружил подозрительную вешь: в секции Client-Id поле Link-Local Address содержит неверный MAC-адрес — вы можете проследить это и в своём логе, т.к. Advertise приходит с точно таким же неверным MAC в Client-Id. Вероятно, это служит причиной из отбрасывания («Ответ не мне»).

 

Что ещё интереснее, иногда всё же получается получить, а иногда — и продлевать аренду. При этом MAC в Solicit-е всё равно неверный.

 

Когда аренда висит, подключение по IPv6 есть, но из тестовых сайтов ( test-ipv6.com ) 30~40% недоступны. Что, может быть, и нормально. Браужеры под Windows Server 2008 упорно предпочитают IPv4 и отказываются от его использования только когда он недоступен.

 

С сетевой точки зрения, это возможно, только если вы смотрите пакеты в сниффере на компьютере, а сетевая карточка у вас производства TP-Link. Если это не так, и у вас CPE TP-Link, то пакеты вы в снифере не смотрели.

Это совсем другая история.

Расскажите, что там у вас.

Проверил локальные дампы, адрес канального уровня сетевой карты совпадает с указанным в вашем дампе.

 

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

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

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

 

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

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

Повторюсь, проблемы решаем сейчас только с прямым подключением к онлайм без маршрутизатора.

Все проблемы с CPE пока отложим, т.к. их может быть слишком много сейчас для анализа.

Дамп посмотрел, идентификаторы сверил. По всей видимости, промежуточных маршрутизаторов между мной и устройством, на котором снимался дамп, нету (фрейм передан напрямую).

Исчезновение ответов Advertise — аномальная ситуация, которая наблюдается лишь изредка и на данный момент не имеет приоритета.

Главная загвоздка — клиент DHCPv6 игнорирует входящие Advertise. Единственную странность, что удалось выявить в трафике DHCPv6 описал выше.

 

Последние несколько дней аренда отсутствует. В списке соседних узлов следующее (никогда раньше такого не видел):

Internet Address                              Physical Address   Type
--------------------------------------------  -----------------  -----------
fe80::21a:f0ff:fe1c:1a6b                      00-1a-f0-1c-1b-ae  Probe (Router)
ff02::2                                       33-33-00-00-00-02  Permanent
ff02::c                                       33-33-00-00-00-0c  Permanent
ff02::16                                      33-33-00-00-00-16  Permanent
ff02::1:2                                     33-33-00-01-00-02  Permanent
ff02::1:3                                     33-33-00-01-00-03  Permanent
ff02::1:ff00:2                                33-33-ff-00-00-02  Permanent
ff02::1:ff1c:1a6b                             33-33-ff-1c-1a-6b  Permanent
ff02::1:ffc6:eb29                             33-33-ff-c6-eb-29  Permanent

0

Share this post


Link to post
Share on other sites
Проблема с IPV6 всеже есть . Хоть адрес и получаю дальше никуда по v6 не пройдешь (и через роутер ,и напрямую) . Странно хотя ping google.com идет по v6

Проверить DNS.

1. http://[2a02:6b8::3]

2. nslookup ipv6.yandex.ru

0

Share this post


Link to post
Share on other sites
Проверить DNS.

1. http://[2a02:6b8::3]

2. nslookup ipv6.yandex.ru

 

dns в норме

C:\Users\zawaloff>nslookup ipv6.yandex.ru

╤хЁтхЁ: router

Address: 192.168.88.1

 

╚ь : ipv6.yandex.ru

Address: 2a02:6b8::3

 

 

C:\Users\zawaloff>

а пакеты дальше не идут

 

началось все 31 марта -до этого все в норме было

при этом данная проблема на всех компьютерах не зависимо от подключения(напрямую или через роутер)

Edited by zawaloff
0

Share this post


Link to post
Share on other sites
dns в норме

<…>

началось все 31 марта -до этого все в норме было

при этом данная проблема на всех компьютерах не зависимо от подключения(напрямую или через роутер)

Если всё пингуется нормально, значит, связь на сетевом уровне есть, следовательно — проблемы на канальном. В рамках моего небольшого, но всё-таки опыта, причина такого поведения — фильтрация портов. Иначе говоря, что-то типа межсетевого экрана блокирует подключения. Для начала надо попробовать аккуратно и кратковременно отключить локальный и проверить. Если не поможет — то не знаю.

0

Share this post


Link to post
Share on other sites
Если всё пингуется нормально, значит, связь на сетевом уровне есть, следовательно — проблемы на канальном. В рамках моего небольшого, но всё-таки опыта, причина такого поведения — фильтрация портов. Иначе говоря, что-то типа межсетевого экрана блокирует подключения. Для начала надо попробовать аккуратно и кратковременно отключить локальный и проверить. Если не поможет — то не знаю.

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

видимо что то в общей сети у онлайма , будем ждать .

 

все дождались .сегодня после 12 дня все пакеты уходят и приходят в норме

Edited by zawaloff
0

Share this post


Link to post
Share on other sites
все дождались .сегодня после 12 дня все пакеты уходят и приходят в норме

И правда заработало, круто

0

Share this post


Link to post
Share on other sites
....

Проблема проявляется в том, что при получении Advertise клиент его (по всей видимости) дропает, причём, безо всяких записей в лог.

.....

Я внимательно изучил пакеты Solicit, которые отправляет клиент и обнаружил подозрительную вешь: в секции Client-Id поле Link-Local Address содержит неверный MAC-адрес — вы можете проследить это и в своём логе, т.к. Advertise приходит с точно таким же неверным MAC в Client-Id. Вероятно, это служит причиной из отбрасывания («Ответ не мне»).

 

Client-ID не обязан совпадать с мак адресом физического интерфейса используемым для передачи пакета.

Вы не ответили на вопрос, кто посылает эти пакеты, CPE или сетевая карточка ?

 

0

Share this post


Link to post
Share on other sites
Вы не ответили на вопрос, кто посылает эти пакеты, CPE или сетевая карточка ?

Указанный в вашем дампе MAC совпадает с MAC моего сетевого адаптера.

Client-ID не обязан совпадать с мак адресом физического интерфейса используемым для передачи пакета.

Зачем тогда он вообще указывается?

0

Share this post


Link to post
Share on other sites
Зачем тогда он вообще указывается?

В IPv6 ввели дополнительный уровень абстракции - обязательный link-local адрес, сделав необязательным наличие мак-адреса даже для link-layer протоколов. От того теперь клиент идентифицируется по DUID(Client ID), соответствующему MAC-адресу, а не самому MAC-адресу. Из плюсов - протоколы NDP, DHCPv6, SLAAC теперь можно использовать в PPP-туннелях и Infiniband, например.

0

Share this post


Link to post
Share on other sites
В IPv6 ввели дополнительный уровень абстракции - обязательный link-local адрес

Опечатался. Link-Layer Address.

Я внимательно изучил пакеты Solicit, которые отправляет клиент и обнаружил подозрительную вешь: в секции Client-Id поле Link-Layer Address содержит неверный MAC-адрес — вы можете проследить это и в своём логе, т.к. Advertise приходит с точно таким же неверным MAC в Client-Id. Вероятно, это служит причиной из отбрасывания («Ответ не мне»).

Там натуральный, характерный 48-битный MAC. И он натурально НЕПРАВИЛЬНЫЙ.

Edited by KMickle
0

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now