Есть сервер на collocation у прова. OS SLES 9 SP3. NIC Intel PRO/100.
Наблюдается потеря пакетов.
Условия тестирования: были одновременно запущены два пинг процесса по 10000 пингов с сервера на 1) сервер провайдера у которого и стоит наш сервер (2 хопа) 2) на сервер другого провайдера (на 1 хоп дальше)
Наблюдается потеря пакетов в 17% для первого процесса и 3% для второго.
Вопросы:
1) Как найти причину потери пакетов?
2) Какое кол-во пакетов можно терять и по какой спецификации?
3) Как и кто контролирует качество оказание услуги?
4) Какое кол-во пакетов критично для httpS трафика?
>Есть сервер на collocation у прова. OS SLES 9 SP3. NIC Intel
>PRO/100.
>Наблюдается потеря пакетов.
>Условия тестирования: были одновременно запущены два пинг процесса по 10000 пингов с
>сервера на 1) сервер провайдера у которого и стоит наш
>сервер (2 хопа) 2) на сервер другого провайдера (на 1 хоп
>дальше)
>Наблюдается потеря пакетов в 17% для первого процесса и 3% для второго.
>
>Вопросы:
>1) Как найти причину потери пакетов?
>2) Какое кол-во пакетов можно терять и по какой спецификации?
>3) Как и кто контролирует качество оказание услуги?
>4) Какое кол-во пакетов критично для httpS трафика?
Как пинговали, с ключом -f?
Количество icmp сообщений в секунду ограничено на всех системах, во избежания DOS. Так сеть не проверяют.
>Как пинговали, с ключом -f?
без -f>Количество icmp сообщений в секунду ограничено на всех системах, во избежания DOS.
AFAIK по умолчанию идет 1 пакет в секунду, думаю достаточное время>Так сеть не проверяют.
Один из вопросов и был
>1) Как найти причину потери пакетов?
>>Как пинговали, с ключом -f?
>без -fесли на самом обычном ping'е потеря > 5% ДЕЛО ХУДОЕ
НО здесь следует иметь ввиду что МНОГО любителей закрывать соответствующие icmp
пакеты и UDP (в случае traceroute)>>Количество icmp сообщений в секунду ограничено на всех системах, во избежания DOS.
>AFAIK по умолчанию идет 1 пакет в секунду, думаю достаточное время
>
>>Так сеть не проверяют.
>Один из вопросов и был
>>1) Как найти причину потери пакетов?в нормальных системах - для начала netstat:
[alone]~ > netstat -I dc0 -w 1
input (dc0) output
packets errs bytes packets errs bytes colls
0 0 0 0 0 0 0
0 0 0 0 0 0 0
0 0 0 0 0 0 0
1 0 60 0 0 0 0
1 0 243 0 0 0 0
0 0 0 0 0 0 0
2 0 120 0 0 0 0
0 0 0 0 0 0 0
0 0 0 0 0 0 0
0 0 0 0 0 0 0
0 0 0 0 0 0 0
2 0 120 0 0 0 0
0 0 0 0 0 0 0
1 0 60 0 0 0 0
0 0 0 0 0 0 0
0 0 0 0 0 0 0
1 0 60 0 0 0 0
^C
[alone]~ ># man netstat (ключи для просмотра ошибок и коллизий на входящих и выходящих пакетах)
если не изменяет память по ethernet стандартам >14% ошибок и коллизий НЕПРИЕМЛЕМО для
работы.Ну и как всегда: проверять договор NET-CARD со СВИТЧОМ/ХАБОМ, факт давно известный о
том что после договора, карта и свитч встают в разные режимы, ну например они
договорились ПРАВИЛЬНО и с обеих сторон порт встал в 100Mbit, карта при этом в full-duplex, а порт на свитче в half-duplex
>>Количество icmp сообщений в секунду ограничено на всех системах, во избежания DOS.
>AFAIK по умолчанию идет 1 пакет в секунду, думаю достаточное время
>
>>Так сеть не проверяют.
>Один из вопросов и был
>>1) Как найти причину потери пакетов?
Не как, а где. Заходите на свой сервер, делаете оттуда traceroute , затем по всем пунктам
ping -s 1500, начиная от шлюза. И непрохождение или прохождение icmp ничего не гарантирует, максимум проблемы на физическом уровне до ближайшего хопа обнаружите
Для начала:
ip -s -s link
ethtool ethX