rus-p

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

    82
  • Joined

  • Last visited

Community Reputation

0 Обычный

About rus-p

Контакты

  • ICQ
    0
  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.