DimOriN

Ivan_83, поподробнее, пожалуйста. Куда смотреть/копать?

Отключен #net.ipv6.conf.all.forwarding=1 #net.ipv6.conf.all.accept_redirects = 0 #net.ipv6.conf.all.accept_source_route = 0 net.ipv6.conf.all.disable_ipv6 = 1 net.ipv6.conf.default.disable_ipv6 = 1 net.ipv6.conf.lo.disable_ipv6 = 1

Добрый день. Недавно сменили старый добрый BIND на Unbound и сразу заметили положительные моменты сего перехода. Уменьшилось время отклика и увеличилась стабильность в часы пик, однако есть одно толстое волосатое "НО". Начали поступать жалобы от абонов на то, что поотваливались некоторые сервисы, в частности viber.com. Хотел бы спросить пользующихся этим DNS-сервером как резолвится сей ресурс у вас? Unbound Version 1.5.6 linked libs: libevent 2.0.19-stable (it uses epoll), OpenSSL 1.0.1e 11 Feb 2013 linked modules: dns64 python validator iterato nslookup viber.com 10.6.1.254 DNS request timed out. timeout was 2 seconds. ╤хЁтхЁ: UnKnown Address: 10.6.1.254 DNS request timed out. timeout was 2 seconds. DNS request timed out. timeout was 2 seconds. DNS request timed out. timeout was 2 seconds. DNS request timed out. timeout was 2 seconds. *** Превышено время ожидания запроса UnKnown

Поднимаю из глубин =) 64-разрядный дебиан. Хочу вывести в таймштампе. Сейчас же выходит в формате MMDD.HH:mm:SS.sss

Абоны на доступе висят в одном vlan'e, однако на доступе запрещен любой пакет с неизученного MAC'а, так что левые arp с левых маков не летают. SNR CPE работает в режиме свича во время загрузки, L2-подъездный скорее всего тоже (D-LINK DES 3200), но проблема возникла без скачков напряжения. Получается, что летает ахинея с изученых маков и как защититься пока-что не понятно. Запрещать любые arp пакеты, кроме запроса клиента на мак шлюза.

sfstudio, Сбросили настройки в дефолт - ARP Proxy отключен по умолчанию - "Все чудесатее и чудесатее". Однако не как не могу объяснить проявление проблемы именно сейчас, ведь если она есть, то она была 2 с лишним года.

В логах ничего криминального. Пока что предварительный диагноз - виноват ARP Proxy. Сняли рутер, поставили в офисе, включили. Подключили винду проводом, забили статику 192.168.1.22, сразу же словили "Конфликт адресов". Меняли адреса, так же ловили аларм винды. Если получать адрес по DHCP, то процесс идет нормально, однако клиентская машина не могла получить MAC-адрес шлюза (Рассылала ARP WHO IS 192.168.1.1 и не получала ответа). Колупавшись в настройках обнаружили включенный ARP Proxy. После выключения более менее все пришло в норму. Завтра будем бегать по абонам и тестировать нашу догадку.

Добрый день. У нас в сети возникла катастрофическая ситуация с маршрутизаторами SNR CPE-W4N и его старшим другом CPE-W4G. В один день, 16 сентября 2015 года, как по волшебству глюкнули эти рутеры у абонентов. Пострадали Wi-Fi Windows клиенты этих точек доступа. Глюк выражается в том, что у абонов рисовался аларм винды "Обранужен конфликт IP адресов в сети" и не работал интернет. (Технология провайдера IPoE, IP абонов от провайдера 10.0.0.0/15. Подсеть внутри дома на SNR 192.168.1.0/24) Всем рутерам более двух лет. Уже зарегистрировано более 30 случаев (с положительной динамикой роста цифры) на сегодняшний день (хвала яйцам ушли от них и пострадали не все абоны). Кто сталкивался?

Подскажите пожалуйста, где взять SNMP MIB'ы для этой модели?

У всех появились проблемы с одноклассниками? Screenshot: С кэшем Без Ссылка на картинку

Ситуация такая. Дано 2 провайдера, авторизация по pppoe. В квартиру заходят по оптике в HUAWEI'евские рутеры (у каждого из них свой отдельный рутер). Рутеры настолько неважно работают с большим трафиком, что решил их перевести в бридж. С рутеров HUAWEI зацеплены двумя кабелями в L2 комутатор. В нем поднято 2 ВЛАНа и прокинуты до машины одним кабелем (физический интерфейс: eth0; vlan'ы: eth0.4017, eth0.4018) На машине стоял Debian Squeeze ну и в данный момент Ubuntu Server 12.04. На машине соответственно так же поднял 2 влана. Рутеры с машины пингуются. pppoe настраивал с помощью утилитки pppoeconf. первый тунель создался усепешно. второй пришлось делать ручками, т.к. pppoeconf настраивает соединение на том интерфейсе, который первый найдет. переименовал созданное им /etc/ppp/peers/dsl-povider в /etc/ppp/peers/inet1 и скопировал конфиг в /etc/ppp/peers/inet2 конфиги ниже: После чего забил логины/пасы в /etc/ppp/chap-secrets и /etc/ppp/pap-secrets поднимаю тунели pon inet1 pon inet2 Первое поднимается сразу Второе тупит, в логах видно, что таймаут на ppp дискавер, но через минуту все же поднимается нормально через ifconfig все выглядит хорошо. Маршрутизацией начинаю пилить интернет дабы загрузить оба соединения. Если гружу их по отдельности, то все замечательно, но если начинаю грузить оба, то появляется потеря пакетов и, в конце концов, одно из соединений отваливается с сообщением "Conection closed. Modem hangup.". Полный текст логов выложу позже. UPD: пробовал с разными значениями MTU