Временная недоступность сайтов. (Странное поведение сети.)

[AlexeyVtb]

Доброго времени суток всем!
Вычитал вот эту тему Недоступны некоторые сайты. Вечное ожидание ответа. - ничего не помогло.

Сеть такая: 2 компа, один рабочий (федора 15), второй под dev-сервер (центось 5.6), подключены в инет через ADSL модем.
Работаю под 15-й федорой, и еще с 14-й начал замечать пробллемы с доступом к некоторым серверам.

Пример один - кратковременная недоступность.
Например, захожу я на srv1.domain.com - в браузере ожидание ответа, в консоли wget к 80-му порту - тоже ожидание, ssh к 22-му - тоже ждет. Но если подождать 10-30 секунд - связь появляется и все некоторое время работает. Такие перебои случаются частенько.
Причем пинги, трейс до сервера проходят без проблем. Фаерволы на сервере ради чистоты эксперимента отрубил.

Пример два - почти полная недоступность сервера.
Есть некий сервер srv2.domain.com, вот он совсем не доступен, в браузере долгое ожидание ответа, и естественно ни по SSH, ни по другим портам к нему не достучатся. Получаем connection timeout.
Как и в предыдущем примере, пинг, трейс - работает, фаервол вырублен.
Если послушать tcpdump-ом - видим SYN, которые с интервалом около секунды посылаются на сервер, а с серверной стороны видим их прием.
Но, интересно, что примерно после 7-8 вечера он доступен всю ночь, потом снова исчезает))) Да, и еще, если на модеме сбросить wan соединение, то сразу же после того как оно реконнектится, сервер доступен 10-30 секунд, и снова исчезает. Модемы менял - бесполезно.

На всех серверах - RHEL 6, 6.1. Всего их 16, настраивал сам своими руками, все выполняют типовые действия, поэтому конфиги одинаковые, ничего специфического. Причем проблемы со связью наблюдаются к 2-4 серверам, на остальных совершенно идеально все работает. Сервера в одной же стойке, одна и та же подсеть, одни и те же дыры в инет. Дело точно не в них.

Но в этоих примерах я описал поведение соединений с fedora 15.
Самое интересное, что в этой же локалке с dev-компа на Центосе 5.6 - всегда все доступно и работает, прямо в то же самое время как с федоры я вижу connection timeout.


Курю гугл уже с месяц, не могу ничего найти, а то что находил - не подходит для решения проблемы, она остается.

[sash-kan]

mtu на интерфейсе, соединяющем компьютер с adsl-модемом, какое значение сейчас имеет?

[AlexeyVtb]

на сетевушке компа стандарт - 1500

Добавлю, что такая же история на буке с федорой, который я подключаю с wi-fi модема.
Интересно, что если подключить комп с виндой - тоже всегда все работает.

Кстати, на компе CentOs тоже mtu 1500 и там все всегда работает...

[sash-kan]

1500

говорите, что всё перепробовали, а самое первое и не проверили·
попробуйте поставить, ну, допустим, 576·

[AlexeyVtb]

попробуйте поставить, ну, допустим, 576·

Пробовал мту менять, но именно 576 не ставил.
ок, буду дома - попробую.

Но тогда встречный вопрос, почему если я на своей гружусь в винду - работает и на 2-й машинке на centos-е все и с 1500 работает?

[AlexeyVtb]

576

Поставил. Результат 0.

Что еще можно попробовать?

[KiWi]

Если послушать tcpdump-ом - видим SYN, которые с интервалом около секунды посылаются на сервер, а с серверной стороны видим их прием.

Уже хорошо.
Ответ есть? Какой?

[AlexeyVtb]

Ответа нет... просто syn посылаются с интервалом в несколько секунд, а на сервере их же ловит tcpdump.
И тишина...

[KiWi]

Ответа нет... просто syn посылаются с интервалом в несколько секунд, а на сервере их же ловит tcpdump.
И тишина...

Я правильно понимаю, что в tcpdumpе на сервере никаких ответов не видно?
Можно включить дебаг-логи у того же sshd и посмотреть, что там пишут.
Ещё можно посмотреть всякие dropped на сетевой.

[sash-kan]

а на сервере их же ловит tcpdump.
И тишина...

т.е., httpd-емон не отвечает?
смотрите его логи (повысис его «разговорчивость»)·

[AlexeyVtb]

т.е., httpd-емон не отвечает?

Не отвечает, ведь tcp соединение даже не устанавливается.

[root@alex alexey]# tcpdump -n -i any host 111.222.333.444
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on any, link-type LINUX_SLL (Linux cooked), capture size 65535 bytes
22:57:24.404706 IP 192.168.1.2.41946 > 111.222.333.444.http: Flags [S], seq 174905385, win 14520, options [mss 1452,sackOK,TS val 3240972 ecr 0,nop,wscale 4], length 0
22:57:27.408314 IP 192.168.1.2.41946 > 111.222.333.444.http: Flags [S], seq 174905385, win 14520, options [mss 1452,sackOK,TS val 3243976 ecr 0,nop,wscale 4], length 0

вот такое я вижу у себя и такое же на сервере, когда пытаюсь лезть на ssh, httpd и т.д.

[sash-kan]

запишите два syn-пакета, отправленных на srv2·
один с рабочей машины, другой с нерабочей·
и сравнивайте их хоть побитово·

записывать надо, естественно, на самом srv2·

[AlexeyVtb]

sash-kan это как? Чем записать? Такого делать не приходилось еще)

[sash-kan]

Чем записать?

tcpdump-ом, к примеру· см. описание опций "-w" и "-r"·

не помню, можно ли в фильтрах tcpdump-а углубиться до флагов tcp·
если не найдёте, воспользуйтесь tshark-ом, в нём точно такие фильтры имеются· (tshark — это, типа, «tcpdump extended edition»)·
если совсем лень читать man-ы, запишите пакеты кучей· просто потом дольше придётся рыться в выдаче "tcpdump -r"·

p.s. при просмотре весьма способствуют опции "-v[v...]"· ну и всякие "-x* -X*" до кучи·

[Ism]

Очень хотелось бы знать структуру сети между машиной и сервером. Включены ли протоколы маршрутизации ? Какие ?
Возможны, например, петли маршрутизации.

Длина кабелей соответствует стандартам ?
Есть ли потери пакетов при обмене ?
Задействован и vlan ?
Как дела с mac адресами ? С китайским оборудованием все возможно.

Очень похоже на то, что срабатывает какая то "адаптивная" система, которая после первого обращения к сайту у себя чтото там перенастраивает

Но, интересно, что примерно после 7-8 вечера он доступен всю ночь, потом снова исчезает)))

Очевидно же, что в это время в сети что-то происходит, например уборщица убирает ведро с wi-fi антенны

[AlexeyVtb]

...

Вот попробовал tcpdump-ом записать пакеты с сервера.
В первом случае, как я и описывал, временная недоступность, это когда при обращении к серверу он (на примере wget, но разницы нет) дооолго думает, потом пробивается к нему и на следующий раз - уже все быстро... И так случается частенько.

Так вот, 1-й раз, медленно в slow, 2-й быстро в fast соответственно.


Второй случай. Так как тот сервер, который у нас вечно днями не доступен, а под вечер работает, я уже опоздал протестить, то занялся другим. У него симптом такой: (в сети, как я и писал ранее АДСЛ модем, к его портам 3 компа, 1 цнтось, 2 других с 15й федорой рабочие). Так вот, если к нему обратится с любого из рабочих компов, то на другом рабочем - он недоступен. Ради интереса переждал немного, в 1-м рабочем в iptables добавил DROP на исходящие к тому серверу, и чудо, со второго рабочего он начинает открываться, тогда когда с первого уже нет (iptables сбрасывал). В это же самое время с центоса все всегда открывалось и открывается.

Записал это в work и work_not соответственно.
Тут я вижу что пакет толи обрыается, толи черти что.

[sash-kan]

Так вот, если к нему обратится с любого из рабочих компов, то на другом рабочем - он недоступен.

для начала роутер поменяйте· вместе с провайдером·
и обратите внимание на пост уважаемого Ism

[AlexeyVtb]

для начала роутер

Менял, 0 реакции, все так же.

вместе с провайдером·

O_o !! Круто))
Такая же история (только со временной недоступностью у меня и на офисе, там 14-е федоры и другой провайдер.

Очевидно же, что в это время в сети что-то происходит, например уборщица убирает ведро с wi-fi антенны

нет, 100% нет.

[Ism]

На вашем бы месте я wireshark записал процесс соединения и детально изучил параметры пакетов , mac адресов, arp запросов, причину потери пакетов, mtu, вплоть до состояния флагов пакетов. Уверен, что найдете какуюто мелкую деталь , которая все объяснит. (wireshark очень наглядно все показывает)
Мне нравится вариант недоступности сервера по причине совпадения mac адресов или даже ip адресов, вечером проблемная рабочая станция выключается и о чудо все работает.
Также нужно проверить корректность работы dhcp в вашей сети, например два тупых роутера раздают адреса как попало (была у меня фигня с adsl модемом, который раздавал адрес привязываясь к mac, но не проверял существует ли уже такой ip адрес в сети. Выяснилось это, когда я назначил на одну машину статический ip адрес )

для начала роутер

Вообще-то роутер и провайдера надо не менять, а проверять их настройки.

[AlexeyVtb]

ок.. попробуем на днях.

Кстати, а вот в чем принципиальная разница двух типов соединений

1. на роутере pppoe соединение, у меня шлюз - этот роутер (вариант с глюками)
2. на роутере бридж, pppoe соединение на компе - все в порядке, всё доступно.

Ведь в этом случае одно звено добавляется - роутер рулит мои запросы к pppoe соединению. Роутеры пробовал менять, со всеми такая же беда...\
Чисто логически - разницы то нет

[Ism]

Очень похоже на слишком большой mtu
http://ru.wikipedia.org/wiki/PPPoE

MTU протокола ниже, чем на стандартном Ethernet, что иногда вызывает проблемы с плохо настроенными межсетевыми экранами.