Sergey Ozerov

Посетитель
  • Content count

    2 147
  • Зарегистрировался

  • Last visited

  • Days Won

    13

Sergey Ozerov last won the day on Октябрь 8

Sergey Ozerov had the most liked content!

Community Reputation

126 Excellent

6 Followers

About Sergey Ozerov

  • Rank
    Профи
  • Birthday 31.05.1964

Contact Methods

  • ICQ
    28344437

Profile Information

  • Пол
    Мужчина
  • Откуда
    Bogorodskoye, Moscow, Russia

Recent Profile Visitors

14 778 profile views
  1. С 1:40 MSK 13 декабря отвалился прямой линк на M9-IX между Билайном (и не только Билайном: Комкор/Акадо тоже этим страдает -- на работе это наблюдаю) и московским сервером 1-го уровня (Stratum=1) ntp.ix.ru, причём этому предшествовал отказ этого сервера (в течение нескольких часов Offset превышал 1 секунду, что недопустимо для NTP-серверов, кроме специально анонсированных заранее (и не планировавшихся в этом декабре) ситуаций сдвига показаний часов на секунду). В настоящее время работоспособность сервера, судя по всему, восстановлена, но маршрут на него строится не директом через M9-IX, а в обход через Европу, что приводит к более чем 10-кратному увеличению пинга (с 3 до 50 миллисекунд) до этого сервера: C:\>tracert ntp.ix.ru Трассировка маршрута к ntp.ix.ru [194.190.168.1] с максимальным числом прыжков 30: 1 7 ms 2 ms 1 ms router.asus.com [192.168.1.1] 2 131 ms 171 ms 140 ms 0850890884.static.corbina.ru [95.31.0.1] 3 85 ms 130 ms 152 ms 0850890884.static.corbina.ru [95.31.0.1] 4 1 ms 1 ms 1 ms 10.2.254.70 5 35 ms 22 ms 20 ms mo-crs-be6.corbina.net [195.14.54.243] 6 18 ms 18 ms 18 ms tc-bb-ae2.sto.corbina.net [195.14.54.103] 7 20 ms 19 ms 19 ms xe-9-1-2.bar1.Stockholm1.Level3.net [213.242.110.105] 8 * * * Превышен интервал ожидания для запроса. 9 53 ms 53 ms 54 ms BR2.Amsterdam1.surf.net [213.244.164.2] 10 50 ms 51 ms 49 ms ae0-4.RT.OV.SPB.RU.retn.net [87.245.232.226] 11 49 ms 51 ms 53 ms GW-RosNIIROS.retn.net [87.245.250.156] 12 49 ms 49 ms 49 ms ntp.ix.ru [194.190.168.1] Трассировка завершена. Неплохо бы исправить -- тем более, что и Билайн (ntp.corbina.net) синхронизируется именно по этому серверу...
  2. 8-жильный (4-парный) кабель можно разбить на 2 части по 4 жилы (2 пары). И одну из этих частей задействовать под приставку. При таком способе подключения на каждой из этих 2-х частей кабеля скорость соединения не превысит 100 мегабит в секунду, ибо для гигабита требуются все 8 жил (4 пары).
  3. @Serpikk, попробуйте "покачать" (с единицы на ноль и обратно) в реестре винды DhcpConnForceBroadcastFlag, как описано здесь (даю ссылку на оригинальный текст, поскольку на русский переведено местами с точностью до наоборот). После внесения изменений в реестр в данном случае требуется перезагрузка винды: настройки сетевых интерфейсов считываются из реестра на этапе загрузки Windows.
  4. @Serpikk, походу, Вам надо собирать дампы сетевой активности на портах UDP 67 и 68 TcpDump'ом или WireShark'ом, после чего отправлять эти дампы на e-mail техподдержки Билайна с соответствующим комментарием -- для анализа системными администраторами. Ибо на форуме такого рода проблемы, как правило, не решаются, да и сисадмины Билайна сюда не заглядывают... Возможно, по результатам анализа собранных Вами дампов будет выполнена перенастройка обслуживающих Ваш сегмент сети DHCP-серверов таким образом, чтобы они не отвергали запросы к ним, приходящие не в конце, а в середине срока аренды.
  5. Возможно, DHCP-сервер так настроен, что принимает только запросы к 255.255.255.255, либо запросы отправлялись не на тот IP-адрес DHCP-сервера. Либо, как вариант, в запросах (в заголовках пакетов этих запросов) требуется наличие флага "Broadcast", т.е. без этого флага DHCP-сервер такие запросы игнорирует.
  6. Ну, тогда я -- пасс: у меня основная система -- Win-7, а интернет-соединение вообще на роутере поднимается, так что в тонкости настроек Linux'а я особо не вникал... Может, ещё кто подскажет... ...Кстати, раз такое дело, имеет смысл подключить комп через роутер, на котором и поднять L2TP-соединение: в этом случае отпадёт необходимость в этих "плясках с бубном" вокруг поднятия L2TP-соединения на компе... Только роутер придётся подобрать помощнее: L2TP требователен к производительности CPU роутера...
  7. Ну, я бы добавил маршрут на подсеть 0.0.0.0 с маской подсети 0.0.0.0 (т.е. дефолтный маршрут, по которому отсылать всё, что не подпадает под прочие описанные маршруты) через гейтвей 95.25.14.211 или, если не прокатит, через гейтвей 78.107.1.252, и удалил бы маршрут на 0.0.0.0/0.0.0.0 через гейтвей 0.0.0.0, чтобы не мешал, либо поставил бы этому маршруту метрику больше, чем у добавленного, поскольку при совпадении адреса и маски подсети приоритет имеет маршрут с меньшей метрикой, а при равенстве метрик возникает неопределённость (часть пакетов отправится по одному маршруту, а часть -- по другому).
  8. NetByNet, например. На тех же правах, что и BeeLine -- то есть, плей-лист не официален и ведётся пользователями в соответствующей теме техподдержки на форуме (раздел техподдержки анонимусам недоступен).
  9. IMHO, нет дефолтного (для 0.0.0.0/0.0.0.0) гейтвея. То есть, IMHO, в IP-адресе дефолтного гейтвея (в ответе на "route -n") должны быть не нули, а конкретный адрес (адрес PPP-интерфейса или 78.107.1.252?). Небось, traceroute "звездит" на первом же хопе -- по той же причине...
  10. Я всё-таки надеюсь, что это -- глюк, который будет исправлен в ближайший рабочий день...
  11. IMHO, до тех пор, пока не будет указан конкретный адрес дома, разговор будет "ни о чём", т.е. никакой конкретики не будет -- по определению...
  12. @Azanni, Вы компьютер уже просканировали на зловреды в автозагрузке, как я писал Вам выше? Ибо такие симптомы (периодический вызов процедуры Autonegotiation, которая по умолчанию сначала устанавливает скорость на сетевом интерфейса 10 Mbps, а затем поднимает её до сотни) характерны в том числе и для смены настроек сетевого интерфейса зловредами...
  13. IMHO, подобного рода заявки исполняются не оператором на телефоне (т.е. в процессе разговора по телефону с абонентом), а соответствующй службой в течение как минимум 3-х рабочих дней, а то и календарной недели...
  14. Чтобы проверить, закрыт ли на самом деле порт, предварительно запустите у себя что-либо, слушающее этот порт. Ибо если ничего не висит на порту, то операционка будет слать отлуп "RST", что и воспринимается сканером как "Port closed". Проверить можно Nmap'ом с рядом стоящего компа, кстати, дабы не гнать напраслину ни на роутер, ни на провайдера... Ну, или снифер на принимающем пакеты компе запустить, чтобы видеть, доходят ли эти пакеты до Вашего компа...
  15. @Neuro77 Если ссылку на прокси в настройках интернет-браузера не обнаружите, но при включении напрямую (без роутера) проблема уйдёт, то сбросьте настройки роутера в дефолт и заново настройте этот роутер (а по уму, надо бы обновить прошивку на ту, в которой закрыта дыра, позволившая перенаправить Ваш HTTP-трафик "налево").