The OpenNET Project / Index page

[ новости/++ | форум | wiki | теги ]

Проблемы работы сети

   Корень / Администратору / Сетевая подсистема, маршрутизация / Проблемы работы сети

----* Решение проблемы с uTP-протоколом uTorrent (доп. ссылка 1)   Автор: Zzz  [комментарии]
  По многочисленным наблюдениям системных администраторов различных компаний предоставляющих доступ к сети интернет, с начала февраля 2010 года наблюдается ежедневный лавинообразный рост количества пакетов в сети, их фрагментация, а также существенный рост исходящего трафика. Данная проблема связана с новой версией торрент-клиента uTorrent вышедшего 3 февраля 2010 года с поддержкой протокола uTP, работающего поверх UDP. Призванный снизить нагрузку на провайдеров протокол uTP в результате привел к обратному эффекту.
...
[Слишком большой объем текста. Скрыт. Для просмотра см. продолжение
]
 
----* Tshark для мониторинга запросов http (доп. ссылка 1)   Автор: CHAPPAY  [комментарии]
  Tshark из комплекта сниффера Wireshark (http://www.wireshark.org/) позволяет наглядно проследить запросы к http-серверу.
...
[Слишком большой объем текста. Скрыт. Для просмотра см. продолжение
]
 
----* Решение проблемы с крахом Net-SNMP   [обсудить]
  В один прекрасный момент Net-SNMP начал слетать с оставлением в логе ошибки:
...
[Слишком большой объем текста. Скрыт. Для просмотра см. продолжение
]
 
----* Управление дуплексным режимом и скоростью линка в различных ОС. (доп. ссылка 1)   [комментарии]
  Solaris
...
[Слишком большой объем текста. Скрыт. Для просмотра см. продолжение
]
 
----* Как увеличить размер таблицы контроля сессий ip_conntrack в Linux   [комментарии]
 
Если ядро ругается "kernel: ip_conntrack: table full, dropping packet.", причину флуда 
(скорее всего вирус или сканирование портов) можно найти по списку /proc/net/ip_conntrack
Если просто общая загрузка большая, увеличить размер таблицы можно через /proc/sys/net/ipv4/ip_conntrack_max

Также можно увеличить размерность хэша через параметр  hashsize модуля ip_conntrack:
/etc/modules.conf:
   options ip_conntrack hashsize=N

Более тонкий тюнинг можно произвести через переменные определенные в /proc/sys/net/ipv4/netfilter
 
----* Примеры использования ngrep для выборки и просмотра содержимого пакетов (доп. ссылка 1)   Автор: Mayank Sharma  [комментарии]
 
ngrep служит для отображения проходящих сетевых пакетов удовлетворяющих заданной маске.
Как мне кажется ngrep гораздо проще и удобнее, чем tcpdump. Вот несколько примеров:

Показать содержимое всех пакетов, прошедших по 80 порту, со словом google 
   ngrep google port 80 

Вывод пакетов удовлетворяющих маске по одному в строке, для интерфейса eth0:
   ngrep -i \'game*|chat|recipe\' -W byline -d eth0

Слушать весь SMTP трафик на всех сетевых интерфейсах:
   ngrep -i \'rcpt to|mail from\' -d any tcp port smtp

Показать текущее время для каждого совпадения (кто и когда заходит на машину телнетом):
   ngrep -q -t -wi "login" port 23
 
----* Почему в FreeBSD 5.3 не работает форвадинг пакетов (ipfw fwd) (доп. ссылка 1)   Автор: Bushi  [комментарии]
 
Это ошибка в FreeBSD 5.3, патч здесь:
http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/71910
 
----* Как сгенерировать IPv6 пакет для отладки сети. (доп. ссылка 1)   [обсудить]
 
# netwox 142 --device "Eth0" --eth-dst "0:8:9:a:b:c" --ip6-src "fec0:0:0:1::1" 
     --ip6-dst "fec0:0:0:1::2" --tcp-src "1234" --tcp-dst "80" --tcp-syn
# netwox 142 --device "Eth0" --eth-src "00:11:22:33:44:55" --eth-dst "0:8:9:a:b:c" 
     --ip6-src "fec0:0:0:1::1" --ip6-dst "fec0:0:0:1::2" --tcp-src "1235" --tcp-dst "80" --tcp-syn

142 - код операции "Spoof EthernetIp6Tcp", netwox - http://laurentconstantin.by.ru/ru/
 
----* Почему при использовании туннеля возникают проблемы с некоторыми хостами. (доп. ссылка 1)   [комментарии]
 
Выход - поставить на интерфейсе туннеля MTU 1500, вместо 1476.
Проблема возникает при попытке протолкнуть пакет размером 1500 байт 
с выставленным DF (don't fragment запрещена фрагментация) битом через интерфейс 1476 байт. 
Другие решения:
interface ethernet0 
 ip policy route-map clear-df 
route-map clear-df permit 10 
 match ip address 101 
 set ip df 0 
access-list 101 permit tcp 10.1.3.0 0.0.0.255 any 

или
interface tunnel0 
 ip tcp adjust-mss 1436
 
----* В чем может быть причина неработы ассиметричного рутинга под Linux. (доп. ссылка 1)   [обсудить]
 
Linux отказывается маршрутизировать пакеты между двумя сетевыми 
картами, кода пакет входит через один интерфейс и выходит через другой, если
включен rp_filter (RFC1812).

Необходимо отключить rp_filter:
   /sbin/sysctl -w net.ipv4.conf.default.rp_filter = 0
   /sbin/sysctl -w net.ipv4.conf.all.rp_filter = 0

Для FreeBSD можно посоветовать:
   в /etc/rc.conf: tcp_extensions="NO"
   или sysctl -w net.inet.tcp.rfc1323=0
   А так же sysctl -w net.inet.tcp.rfc1644=1 и sysctl -w net.inet.tcp.rfc1323=0
 
----* С чем может быть связаны потери пакетов и нестабильная работа ethernet карт ? (доп. ссылка 1)   [комментарии]
 
Приходилось сталкиваться с проблемами согласования режимов работы карт Intel EtherExpress 100 и 
Reltek  RTL-8139 c коммутаторами и концентраторами различных производителей. Несогласование 
проявляется, например в работе карты в режиме half-duplex, а свича в
full-duplex и т.д. (в linux: /sbin/mii-tool -F 100baseTx-FD eth0)
 
----* Почему выкачиваются данные с машины нормально, как только пытаюсь что-то закачать - соединение останавливается, даже через ssh больше 5 мин. не удается поработать. Другие машины работают нормально.   [комментарии]
 
Неоднократно замечена проблема работы сетевых карт на базе RealTek 8129/8139 (машины под FreeBSD, 
но с другими ОС тоже проявляется) с некоторыми концентраторами и коммутаторами. 
Проявляется в замирании  сессий до истечения таймаута. 
Диагностика: ping -s N remote_ip, при больших N не проходят.
Решение: Смените сетевую карту, например, на Intel EtherExpress Pro.
 
----* Почему лог почтового сервера изобилует сообщениями о разрыве по Timeout, часто, при приеме большого объема данных, прокачка останавливается и замирает до истечения таймаута ?   [комментарии]
 
Вероятные причины: Туннель, блокировка ICMP, "path MTU discovery" и ECN
(Explicit Congestion Notification,
ECN проявляется в основном при доступе через Proxy).
При блокировке ICMP трафика, возможно блокируется не только
echo_replay/echo_request ICMP сообщения,
но и другие важные сообщения
передаваемые по ICMP. При блокировке ICMP сообщений типа 3.4 (fragmentation
needed and DF set) возможно
нарушение нормальной фрагментации пакетов, что вполне может проявляться как
внезапная остановка передачи
данных большого объема и разрыв сесcии по таймауту, например, если на пути
трафика встречается туннель.
Одним из путей решением проблемы, является установка на туннеле MTU > 1500 и
отмена блокировки ICMP трафика.
Проблемы с ECN в Linux лечатся: 
    echo 0 >/proc/sys/net/ipv4/tcp_ecn 
path MTU discovery:
    Linux: echo 1 > /proc/sys/net/ipv4/ip_no_pmtu_disc
    FreeBSD: sysctl -w net.inet.tcp.rfc1323=0
 

 Версия для печати




  Закладки на сайте
  Проследить за страницей
Created 1996-2017 by Maxim Chirkov  
ДобавитьРекламаВебмастеруГИД  
Hosting by Ihor TopList