Posted March 8, 2015 Ситуация: Домашняя сетка Роутер 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
Posted March 9, 2015 что это? и как с этим бороться? Опять же, предупреждаю, что опыт практической работы с сетями у меня ограниченный, но соображения следующие: 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
Posted March 9, 2015 Подскажите, пожалуйста, кто-нибудь пробовал настроить 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
Posted March 16, 2015 (edited) на вывод команды netsh int ipv6 show neighbors шлюз по умолчанию сразу после перезагрузки пишет Reachable, а через 10-15 мин Stale Решить проблему можно прописав постоянную запись для шлюза по умолчанию в таблицу "соседей" командой netsh int ipv6 add neighbors <....> store=persistent Работает постоянно, после перезарузки не слетает, при необходимости удаляется командой netsh int ipv6 delete neighbors Edited March 16, 2015 by Seva5 0 Share this post Link to post Share on other sites
Posted March 18, 2015 Решить проблему можно прописав постоянную запись для шлюза по умолчанию в таблицу "соседей" командой netsh int ipv6 add neighbors <....> store=persistent В моём случае не помогает — симптомы прежние, адрес иногда вообще не выдаётся, иногда выдаётся, но не может обновиться. 0 Share this post Link to post Share on other sites
Posted March 25, 2015 (edited) Сегодня входящий IPv6 трафик пропал почти полностью. Приходят только ответы на запросы Neighbour Solicitation от маршрутизатора. Ответы на DHCP Solicit не приходят. Edited March 25, 2015 by KMickle 0 Share this post Link to post Share on other sites
Posted March 31, 2015 Что-то зарубеж отвалился, с впски пинг6 домашнего адреса пишет: Destination unreachable: No route. 0 Share this post Link to post Share on other sites
Posted April 1, 2015 Сегодня входящий IPv6 трафик пропал почти полностью. Приходят только ответы на запросы Neighbour Solicitation от маршрутизатора. Ответы на DHCP Solicit не приходят. Прикрепил снапшот обмена между вашим оборудованием и маршрутизатором онлайм. Дамп снят на маршрутизаторе, т.е. до вашего оборудования есть еще цепочка коммутаторов. Видно, что Онлайм отправляет вам Advertise сообщение протокола dhcpv6. По вашим словам, вы его не видите. С сетевой точки зрения, это возможно, только если вы смотрите пакеты в сниффере на компьютере, а сетевая карточка у вас производства TP-Link. Если это не так, и у вас CPE TP-Link, то пакеты вы в снифере не смотрели. Это совсем другая история. Расскажите, что там у вас. Это сообщение юникастное, проблему с доставкой через коммутаторы предположить сложно, т.к. другие юникаст сообщения до вашего IPv4 адреса проходят успешно. Различие пакета только в номере нижележащего протокола. Идеально было бы сделать подключение вашего CPE через коммутатор на котором выключить изучение мак адресов. И подключить в этот коммутатор другой компьютер, желательно с линуксом на котором запустить сниффер. Боюсь, что пока не будет массовых жалоб с аналогичной проблемой, решить проблему с организацией выезда нашего сотрудника и описанного стенда будет проблематично. Если в данной теме отпишутся еще несколько человек, и, сняв дамп, я увижу, что проблемы схожи, тогда организацию тестирования я смогу взять на себя. Повторюсь, проблемы решаем сейчас только с прямым подключением к онлайм без маршрутизатора. Все проблемы с CPE пока отложим, т.к. их может быть слишком много сейчас для анализа. 0 Share this post Link to post Share on other sites
Posted April 1, 2015 Что-то зарубеж отвалился, с впски пинг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
Posted April 1, 2015 Проблема с IPV6 всеже есть . Хоть адрес и получаю дальше никуда по v6 не пройдешь (и через роутер ,и напрямую) . Странно хотя ping google.com идет по v6 0 Share this post Link to post Share on other sites
Posted April 1, 2015 Прикрепил снапшот обмена между вашим оборудованием и маршрутизатором онлайм. Дамп снят на маршрутизаторе, т.е. до вашего оборудования есть еще цепочка коммутаторов. Видно, что Онлайм отправляет вам 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
Posted April 1, 2015 Проблема с 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
Posted April 1, 2015 (edited) Проверить 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 April 1, 2015 by zawaloff 0 Share this post Link to post Share on other sites
Posted April 1, 2015 dns в норме <…> началось все 31 марта -до этого все в норме было при этом данная проблема на всех компьютерах не зависимо от подключения(напрямую или через роутер) Если всё пингуется нормально, значит, связь на сетевом уровне есть, следовательно — проблемы на канальном. В рамках моего небольшого, но всё-таки опыта, причина такого поведения — фильтрация портов. Иначе говоря, что-то типа межсетевого экрана блокирует подключения. Для начала надо попробовать аккуратно и кратковременно отключить локальный и проверить. Если не поможет — то не знаю. 0 Share this post Link to post Share on other sites
Posted April 2, 2015 (edited) Если всё пингуется нормально, значит, связь на сетевом уровне есть, следовательно — проблемы на канальном. В рамках моего небольшого, но всё-таки опыта, причина такого поведения — фильтрация портов. Иначе говоря, что-то типа межсетевого экрана блокирует подключения. Для начала надо попробовать аккуратно и кратковременно отключить локальный и проверить. Если не поможет — то не знаю. и вот я не знаю . порты ведь не могут блокироваться сразу на всех устройствах одновременно . я даже специально от соседа комп брал ,напрямую подключал эффект тот же. видимо что то в общей сети у онлайма , будем ждать . все дождались .сегодня после 12 дня все пакеты уходят и приходят в норме Edited April 2, 2015 by zawaloff 0 Share this post Link to post Share on other sites
Posted April 2, 2015 все дождались .сегодня после 12 дня все пакеты уходят и приходят в норме И правда заработало, круто 0 Share this post Link to post Share on other sites
Posted April 2, 2015 .... Проблема проявляется в том, что при получении 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
Posted April 2, 2015 Вы не ответили на вопрос, кто посылает эти пакеты, CPE или сетевая карточка ? Указанный в вашем дампе MAC совпадает с MAC моего сетевого адаптера. Client-ID не обязан совпадать с мак адресом физического интерфейса используемым для передачи пакета. Зачем тогда он вообще указывается? 0 Share this post Link to post Share on other sites
Posted April 4, 2015 Зачем тогда он вообще указывается? В 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
Posted April 4, 2015 (edited) В IPv6 ввели дополнительный уровень абстракции - обязательный link-local адрес Опечатался. Link-Layer Address. Я внимательно изучил пакеты Solicit, которые отправляет клиент и обнаружил подозрительную вешь: в секции Client-Id поле Link-Layer Address содержит неверный MAC-адрес — вы можете проследить это и в своём логе, т.к. Advertise приходит с точно таким же неверным MAC в Client-Id. Вероятно, это служит причиной из отбрасывания («Ответ не мне»). Там натуральный, характерный 48-битный MAC. И он натурально НЕПРАВИЛЬНЫЙ. Edited April 4, 2015 by KMickle 0 Share this post Link to post Share on other sites
