rus-p

Пользователи
  • Content count

    82
  • Joined

  • Last visited

Everything posted by rus-p

  1. Только напрямую, кабель в ваш ПК. И winMTR информативнее, чем трасероут в плане кол-ва итерации, т.к. у вас проблема не с маршрутами, а с доступом к сети.
  2. ЛС укажите. Напрямую, без роутера, ситуация аналогичная ? winmtr на 5.255.255.5 натравите и сюда выложите. У соседей как ?
  3. Не занимаюсь этой темой, тут есть участники с практическим опытом, они подскажут.
  4. Лучше с галкой. Мультискрин (второй телевизор) работает по юникасту. Очевидно, что при попытке работать без галки, и одновременно запустив закачку, вы получите дроп везде, и на первом телевизоре (мультикаст) и на втором, т.к. процессор не тянущий мультикаст, скорее всего дропает и юникаст, только обычно вы это не видите, т.к. не IPTV приложениям не критичны потери.
  5. Ваш роутер не тянет 100 мбит и мультикаст в режиме маршрутизации одновременно, когда весь мультикаст анализируется процессором и перенаправлятся в порты где есть запросы на него. Когда вы ставите галку вручную, вы явно указываете роутеру пропускать мультикаст в режиме коммутации - мультикаст не анализируется центральным процессором. Минус решения с галкой - вы можете направить мультикаст только в один выходной порт, т.е. не получиться подключить вторую приставку в соседний порт. Выставление галки - единственная рабочая схема на тарифах более 10 мбит. Провайдеру вы оказываете медвежью услугу, ваша приставка начинает получать адрес из пула провайдера, а не роутера. А на старших тарифах это реальные адреса, коих дефицит. Но провайдер сам виноват, позволяя покупать в магазинах и давая в аренду оборудование не тянущее тарифные скорости. Когда ему, провайдеру, наконец надоест слушать жалобы и объективно терять клиентов из-за описанной вами причины, так как не все доходят до вашего шага, возможно он сподобиться плотнее работать с Китаем и ставить корректный роутер бесплатно и управлять им будет сам. У самого провайдера
  6. У вас в ночь с 26 на 27 обновили ПО на коммутаторе доступа. Проверьте.
  7. Мысли такие: 1. Подключаетесь напрямую в кабель Онлайм 2. Когда сайт не доступен делаете пинг до него и трасерт. Не забывайте про www, если сайт у вас в браузере с www, то эти же буквы в пинге и трасерте. 3. Когда сайт не доступен включаете режим турбо в опере и пробуете зайти. 4. Когда сайт доступен делаете пинг и трасерт. 5. Указываете номер лицевого счета. Выкладываете все это сюда. Дальше будем думать.
  8. Client-ID не обязан совпадать с мак адресом физического интерфейса используемым для передачи пакета. Вы не ответили на вопрос, кто посылает эти пакеты, CPE или сетевая карточка ?
  9. Прикрепил снапшот обмена между вашим оборудованием и маршрутизатором онлайм. Дамп снят на маршрутизаторе, т.е. до вашего оборудования есть еще цепочка коммутаторов. Видно, что Онлайм отправляет вам Advertise сообщение протокола dhcpv6. По вашим словам, вы его не видите. С сетевой точки зрения, это возможно, только если вы смотрите пакеты в сниффере на компьютере, а сетевая карточка у вас производства TP-Link. Если это не так, и у вас CPE TP-Link, то пакеты вы в снифере не смотрели. Это совсем другая история. Расскажите, что там у вас. Это сообщение юникастное, проблему с доставкой через коммутаторы предположить сложно, т.к. другие юникаст сообщения до вашего IPv4 адреса проходят успешно. Различие пакета только в номере нижележащего протокола. Идеально было бы сделать подключение вашего CPE через коммутатор на котором выключить изучение мак адресов. И подключить в этот коммутатор другой компьютер, желательно с линуксом на котором запустить сниффер. Боюсь, что пока не будет массовых жалоб с аналогичной проблемой, решить проблему с организацией выезда нашего сотрудника и описанного стенда будет проблематично. Если в данной теме отпишутся еще несколько человек, и, сняв дамп, я увижу, что проблемы схожи, тогда организацию тестирования я смогу взять на себя. Повторюсь, проблемы решаем сейчас только с прямым подключением к онлайм без маршрутизатора. Все проблемы с CPE пока отложим, т.к. их может быть слишком много сейчас для анализа.
  10. Скиньте в личку номер ЛС. Если решитесь поставить онлаймовские dns, вот несложная диагностическая процедура, которая позволит зафиксировать проблему: 1. До пропадания связи с dns, через nslookup срезолвите произвольный сайт, запишите его IP на бумажку. 2. Во время аварии с dns засеките время с точностью до минуты. 3. Во время аварии запустите в командной строке nslookup и скормите ему сайт из пункта #1, чтобы было видно таймаут. 4. В это же время сделайте пинг до ранее записанного IP. 5. После того как dns оживет, срезолвите сайт еще раз и убедитесь, что адрес совпадает с ранее записанным IP адресом. Выложите сюда время и картинки из пунктов 3, 4. PS Эту процедуру может выполнить любой, кому захочется помочь провайдеру решить проблему.
  11. ICMP6 unreachable с сабкодом 1 (administratively prohibited) шлет именно система. С вопросом, для чего роутер это делает Владислав, насколько я понял, обратился в поддержку линксиса.
  12. Если у кого-то есть возможность оставить включенным компьютер с 9 до 17 часов, и на вывод команды netsh int ipv6 show neighbors шлюз по умолчанию сразу после перезагрузки пишет Reachable, а через 10-15 мин Stale скиньте пожалуйста ЛС в личку.
  13. Если Онлайм отдает вам /64, значит вы запросили только IA_NA префикс (назначается на WAN интерфейс компьютера/CPE). Чтобы получить /56 вам нужно запросить IA_PD, обычно его просит только CPE, она разбивает его на блоки по /64 и вешает каждую такую подсеть на отдельный L2 домен, самое простое ваш LAN интерфейс. Если есть два LAN, повесит две подсети /64, по одной на каждый. Это все прописано в стандартах тут никаких фокусов нет. SLAAC занимается "отдачей" просто неявно, он префикc /64 из блока /56 транслирует вниз через опцию в заголовке при посылке RA.
  14. Владислав, с вами все понятно. Прикрепил ваш дамп уже после 1 часа работы. Видно, что доступ по IPv6 у вас сломался из за установленного на сетевом устройстве защитного экрана. Характерное поведение - роутер шлет вам RA, хост тут же запрашивает ND, роутер шлет NA юникастом, т.к. на этом этапе все мак адреса известны, а ваш хост не пускает пакет на обработку в систему из-за правил фильтрации. Резюме, ищите почему ваш фаервол так себя ведет. PS Ограничения на загрузку какие-то есть, просто так не цепляет, переименовал файл на расширение *.bmp. Чтобы посмотреть, выберите пункт сохранить как, затем переименуйте обратно в *.pcap dump_v6.bmp
  15. Проблему пока не удалось локализовать. Подозрение на отсутствие ответа от оборудования провайдера на router solisitation со стороны клиента. Соответственно, становиться недоступен шлюз. У вас шлюз был доступен, это адрес начинающийся на fe80:......, если это так, то это другая проблема. В лаборатории, где мы пытаемся воссоздать проблему, все работает, в том числе с win8. Сейчас круг поиска сузился до коммутаторов доступа, их достаточно много и не все они рассчитаны на передачу ipv6 мультикаст, которым пользуется icmpv6 для проверки достижимости шлюза. Если кто-то сможет с 9 до 17 часов быть дома за компьютером, скиньте мне ЛС, я сниму дампы трафика на оборудовании. Здесь все верно. /56 выделяется на каждое подключение в Onlime. Затем роутер клиента самостоятельно может нарезать пулы из этого префикса как ему вздумается и отдавать вниз по SLAAC или dhcpv6. Логично делать это по /64.
  16. Номер ЛС скиньте. Была проблема, починили дней эдак 5 назад. Если сейчас снова повторяется, сделайте, пожалуйста, скриншот пинга до 208.87.35.103 и выполните в командной строке nslookup. Сначала скормите параметр server 77.37.251.33, потом имя хоста для резолва - www.com >nslookup > server 77.37.251.33 Default Server: ns1.onlime.ru Address: 77.37.251.33 > www.com Server: ns1.onlime.ru Address: 77.37.251.33 Non-authoritative answer: Name: www.com Address: 208.87.35.103
  17. Левел3 подключил клиента стыком /30. Адрес 212.72.46.190 резолвится в домене левел3, но принадлежит он оборудованию клиента, т.е. Sony-online. Name: SONY-ONLINE.edge6.Amsterdam1.Level3.net Address: 212.72.46.190 Name: xe-8-3-3.edge6.Amsterdam1.Level3.net Address: 212.72.46.189 По geoip адрес 69.174.194.165 выходит на америку, а не европу. Вариантов может быть масса. Например, у игры так называемый эникаст IP, т.е. один и тот же IP но в разных частях мира, в америке один, в европе другой, а у левел3 выиграл маршрут на американский IP. Соответственно левел3 обеспечивает транспорт по своей сети через пол земли. Вы эти хопы не увидите, т.к. провайдеры скрывают физическую топологию. Конечно может быть и банальная проблема на стыке левел3 и клиента.
  18. Seva5, ок. Еще бы дамп от вас, мне нужны icmpv6 & dhcpv6 И номер вашего ЛС в личку + точное время следующего дня с 10 до 17, когда будет включено устройство с win8, чтобы я смог снять дамп на оборудовании. 1,5 часа для win7 это не показатель, люди пишут, что и через сутки может начаться.
  19. IPv6 не является услугой, это побочный процесс модернизации оборудования, когда текущее перестает справляться. Ждать IPv6 не имеет смысла. Возвращаемся к проблеме пропадания IPv6 в тех районах где он есть. Если замечена проблема рассматриваемая в этом топике - через некоторое время пропадает связность по IPv6, а через один-два часа и сам IPv6 адрес (проверяется в выводе командной строки через ipconfig /all), то если есть возможность, нужно проделать следующее: 1. В командной строке, пока работает IPv6, даете netsh int ipv6 show neighbors 2. Ждете пока IPv6 связность пропадет (например перестает открываться ipv6.google.com) 3. Снова снимаете вывод netsh int ipv6 show neighbors 4. Выкладываете сюда результаты и версию операционной системы компьютера 5. Если есть возможность через wireshark проверить проблему, запустите его до начала проблемы и остановите после того, как пропадет IPv6 адрес с интерфейса. Затем примените фильтр dvcpv6 & icmpv6, далее save->displayed packets и выложите сюда. Если вы подключены через роутер, будет сложно понять какое он вносит влияние, т.к. объем необходимых действии и знаний увеличивается. Для упрощения ситуации включайтесь на время теста напрямую.
  20. В этом году скорее всего нет.
  21. Поглядел весь маршрут в Ростелекоме, все более или менее чисто было на даты ваших жалоб. И изменения маршрута не совпадают с периодами проблем. Поскольку через Телию работает, можно предположить, что проблемы есть у самого GTT. Можно конечно поприставать к ним, но боюсь овчина выделки не стоит. Сеть дышит, пока будем мучить GTT, у Телии начнутся проблемы. Как-то так.
  22. Не дошел еще Ipv6 до вашего района. А в связи с вдвое подорожавшим оборудованием, сами понимаете.