nerik Опубликовано 10 декабря, 2010 · Жалоба Всем доброго дня. Коллеги прошу помощи в советах. Не могу понять кто валит наш шлюз, либо физик какой-то, либо странность в сети. Имеются два шлюза IBM для ната, перед ними есть bras в роли циски ASR1002. Оба шлюза под управлением FreeBSD 7.3 с yandex драйверами 1.36.2.17 (сетевые Intel® PRO/1000, хорошие сетевые, с трафиком не подводили). Работают они отлично и уже очень длительное время. После bras default-маршрут идет на первый шлюз, а на второй мы скинули 16 сетей (Для балансировки входящего в нашу сеть трафика, знаю что криво, но работает). Оба шлюза физически подключены в разные места (в разные коммутаторы), поэтому проблема точно не в физике (т.к. при переносе всего трафика на один из шлюзов, проблема повторяется). Теперь о самой проблеме. Вчера первый шлюз стал загибаться, процессы rx_kthread стали взлетать до 100%, тем самым съедать весь процессор. При выводе команды netstat -hw 1 (данные пока не сохранил) увидел, что копятся errs на input, при этом количество пакетов начинает падать (например с 60K до 3-4K, а ошибки возрастают до 6-7K). Суть в том, что длится это не долго, было вчера 3 раза и каждый такой сбой был от 3 до 10 минут. Bras (ASR1002) не загибается. Колбасит при этом первый шлюз очень даже не дурно. А вот со вторым шлюзом все нормально. Я думал, что это сам шлюз глючит, но когда я весь трафик перекинул на второй, второй стал тоже загибаться с такими же симптомами. tcpdump не выявил ничего плохого. Посмотрел дебаг сетевух: sysctl dev.em.2.stats=1 Dec 10 08:48:41 gwibm kernel: em2: Excessive collisions = 0Dec 10 08:48:41 gwibm kernel: em2: Sequence errors = 0 Dec 10 08:48:41 gwibm kernel: em2: Defer count = 0 Dec 10 08:48:41 gwibm kernel: em2: Missed Packets = 7216624 Dec 10 08:48:41 gwibm kernel: em2: Receive No Buffers = 1084060 Dec 10 08:48:41 gwibm kernel: em2: Receive Length Errors = 0 Dec 10 08:48:41 gwibm kernel: em2: Receive errors = 0 Dec 10 08:48:41 gwibm kernel: em2: Crc errors = 0 Dec 10 08:48:41 gwibm kernel: em2: Alignment errors = 0 Dec 10 08:48:41 gwibm kernel: em2: Collision/Carrier extension errors = 0 Dec 10 08:48:41 gwibm kernel: em2: RX overruns = 101 Dec 10 08:48:41 gwibm kernel: em2: watchdog timeouts = 0 Dec 10 08:48:41 gwibm kernel: em2: RX MSIX IRQ = 0 TX MSIX IRQ = 0 LINK MSIX IRQ = 0 Dec 10 08:48:41 gwibm kernel: em2: XON Rcvd = 0 Dec 10 08:48:41 gwibm kernel: em2: XON Xmtd = 61562 Dec 10 08:48:41 gwibm kernel: em2: XOFF Rcvd = 0 Dec 10 08:48:41 gwibm kernel: em2: XOFF Xmtd = 7275240 Dec 10 08:48:41 gwibm kernel: em2: Good Packets Rcvd = 1779196668 Dec 10 08:48:41 gwibm kernel: em2: Good Packets Xmtd = 1735225671 Dec 10 08:48:41 gwibm kernel: em2: TSO Contexts Xmtd = 0 Dec 10 08:48:41 gwibm kernel: em2: TSO Contexts Failed = 0 sysctl dev.em.2.debug=1 Dec 10 08:49:21 gwibm kernel: em2: Adapter hardware address = 0xc566a218Dec 10 08:49:21 gwibm kernel: em2: CTRL = 0x581c0241 RCTL = 0x8002 Dec 10 08:49:21 gwibm kernel: em2: Packet buffer = Tx=16k Rx=32k Dec 10 08:49:21 gwibm kernel: em2: Flow control watermarks high = 30720 low = 29220 Dec 10 08:49:21 gwibm kernel: em2: tx_int_delay = 100, tx_abs_int_delay = 195 Dec 10 08:49:21 gwibm kernel: em2: rx_int_delay = 0, rx_abs_int_delay = 200 Dec 10 08:49:21 gwibm kernel: em2: fifo workaround = 0, fifo_reset_count = 0 Dec 10 08:49:21 gwibm kernel: em2: hw tdh = 1090, hw tdt = 1090 Dec 10 08:49:21 gwibm kernel: em2: hw rdh = 3104, hw rdt = 3103, next_rx_desc_to_check = 3104 Dec 10 08:49:21 gwibm kernel: em2: Num Tx descriptors avail = 4068 Dec 10 08:49:21 gwibm kernel: em2: Tx Descriptors not avail1 = 0 Dec 10 08:49:21 gwibm kernel: em2: Tx Descriptors not avail2 = 0 Dec 10 08:49:21 gwibm kernel: em2: Std mbuf failed = 0 Dec 10 08:49:21 gwibm kernel: em2: Std mbuf cluster failed = 0 Dec 10 08:49:21 gwibm kernel: em2: Driver dropped packets = 0 Dec 10 08:49:21 gwibm kernel: em2: Driver tx dma failure in encap = 0 Dec 10 08:49:21 gwibm kernel: em2: Packets pended due to reorder = 0 Dec 10 08:49:21 gwibm kernel: em2: RX interrupts has been masked = 99250334 Dec 10 08:49:21 gwibm kernel: em2: TX interrupts has been generated = 0 Единственное что я крутил у сетевух так это dev.em.2.rx_int_delay=100dev.em.2.tx_int_delay=100 dev.em.2.rx_abs_int_delay=200 dev.em.2.tx_abs_int_delay=200 dev.em.2.rx_kthreads=4 Коллеги помогите, пожалуйста. Подскажите, что за трафик такой может спровоцировать ошибки на сетевой при входе? Спасибо. P.S. Раньше когда трафика было много и шлюз был один, то при перегрузке ошибки появлялись на интерфейсе, но количество пакетов так сильно не падало (ну может на 2-3K, но не на 40K же). Когда появляется вышеописанная проблема, взлет трафика нет, по количеству пакетов сказать пока сложно, но вроде тоже не возрастает. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Giga-Byte Опубликовано 10 декабря, 2010 (изменено) · Жалоба tcpdump не выявил ничего плохого.для отлова аномального трафика я писал софтину на Си и запускал её на отдельной машине, на которую льётся инет-трафик с помошью port mirroring кошкит.к. надо быть Neo, либо хотябы кем-то из матрицы чтобы увидеть в выводе tcpdump аномалию на шлюзе интернет-провайдера где за энадцать килопакетов в секунду летит Посмотрел дебаг сетевух:и не увидел... чтоDec 10 08:49:21 gwibm kernel: em2: tx_int_delay = 100, tx_abs_int_delay = 195Dec 10 08:49:21 gwibm kernel: em2: rx_int_delay = 0, rx_abs_int_delay = 200 dev.em.2.rx_int_delay=100 dev.em.2.tx_int_delay=100 dev.em.2.rx_abs_int_delay=200 dev.em.2.tx_abs_int_delay=200 dev.em.2.rx_kthreads=4 да и вообще, мне кажется маловато 100 Коллеги помогите, пожалуйста. Подскажите, что за трафик такой может спровоцировать ошибки на сетевой при входе? Спасибо.на шлюзе кроме протоколов маршрутизации (BGP, OSPF etc) ещё что есть? в т.ч. фаерволлзапустите три терминала: один top -SP -s1 второй netstat -w1 -Iфизический_1 третий netstat -w1 -Iфизический_2 и смотрите чего будет происходить с топ-ом при появлении ошибок. ну и пара вопросов не особо относящихся к теме: - хватило зелени на ASR а на автономную систему нет? как-то неукладывается, зачем вам nat, с ним же проблемы одни - вы не из Тюмени случайно? (5-6-МЖК 2004-2005г. и провайдинг) Изменено 10 декабря, 2010 пользователем Giga-Byte Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
photon Опубликовано 10 декабря, 2010 · Жалоба tcpdump не выявил ничего плохого.для отлова аномального трафика я писал софтину на Си и запускал её на отдельной машине, на которую льётся инет-трафик с помошью port mirroring кошкит.к. надо быть Neo, либо хотябы кем-то из матрицы чтобы увидеть в выводе tcpdump аномалию на шлюзе интернет-провайдера где за энадцать килопакетов в секунду летит Если использовать статистический подход и строить распределение пакетрейта по IP, то DoS-атаки из внутренней сети вполне можно отлавливать. У атакующих IP пакетрейт всегда аномально большой. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
nerik Опубликовано 11 декабря, 2010 (изменено) · Жалоба На шлюзе кроме ната ничего нет, BGP на другом бордере. Шлюзы нужны для экономии выделенных адресов (используется pf). Сейчас подозреваю, что кто-то генерирует большое количество пакетов, тем самым ложится софтовый шлюз. tcpdump уже поставлен на мониторинг, будем анализировать его уже позже. По rx_int_delay, я видел, но параметр установлен. Счел это на баг самой сетевой. Но врятли это мешает, т.к. уже год все было отлично с этими параметрами. Насчет top я же писал, что взлетает в момент проблемы процесс rx_kthread до 100%. Какие-то пакеты переполняют буфер сетевой, а вот какие пока ещё неизвестно. Скорее всего дело в их количестве и в меньшем размере. Сейчас будем мониторить их. Изменено 11 декабря, 2010 пользователем nerik Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Giga-Byte Опубликовано 12 декабря, 2010 · Жалоба Шлюзы нужны для экономии выделенных адресов (используется pf).почему pf? он не годится для мультипроцессорности и большого трафика.есть libalias и ng_nat... попробуйте... Сейчас подозреваю, что кто-то генерирует большое количество пакетов, тем самым ложится софтовый шлюз.такого быть не должно. tcpdump уже поставлен на мониторинг, будем анализировать его уже позже.сомневаюсь, что найдете что-нибудь аномального. По rx_int_delay, я видел, но параметр установлен. Счел это на баг самой сетевой. Но врятли это мешает, т.к. уже год все было отлично с этими параметрами.как применяли параметры?если через sysctl.conf и /etc/rc.d/sysctl restart - то это бага этого скрипта. надо в два этапа, например dev.em.2.rx_int_delay=100 dev.em.2.rx_int_delay=500 Насчет top я же писал, что взлетает в момент проблемы процесс rx_kthread до 100%. Какие-то пакеты переполняют буфер сетевой, а вот какие пока ещё неизвестно. Скорее всего дело в их количестве и в меньшем размере. Сейчас будем мониторить их.у вас dev.em.2.rx_kthreads=4, должно быть 4 процесса (зачем опять-же)взлетает до 100% всего один rx_kthread? если да - советую обратить внимание на первый абзац этого сообщения. физическая сетевая одна и таже? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
nerik Опубликовано 12 декабря, 2010 · Жалоба почему pf? он не годится для мультипроцессорности и большого трафика.есть libalias и ng_nat... попробуйте... А смысл менять если с ним проблем не было, тем более асинхронный нат очень даже устраивает нас. При pf первый шлюз у нас прогоняет 700 Мегабит. Просто при использовании второго шлюза, мы сейчас через первый гоняем не более 300Мегабит. Проблема то заключается при входе трафика, так как взлетают input errs на сетевой, значит до pf не доходит. такого быть не должно. Если количество пакетов (с малым размером) будет больше, чем шлюз может прожевать, то он будет загибаться. как применяли параметры?если через sysctl.conf и /etc/rc.d/sysctl restart - то это бага этого скрипта. надо в два этапа, например dev.em.2.rx_int_delay=100 dev.em.2.rx_int_delay=500 через команду sysctl сначало добавляли. Да и перезагружали шлюз недавно (в sysctl.conf прописано). у вас dev.em.2.rx_kthreads=4, должно быть 4 процесса (зачем опять-же)взлетает до 100% всего один rx_kthread? если да - советую обратить внимание на первый абзац этого сообщения. нет, взлетают все rx_kthread, от 90 до 100%. Стоит 4 так как у нас 8 ядер на шлюзе. По 4 отдаем на каждую сетевую. физическая сетевая одна и таже? нет, сетевые две, внешние, двухпортовые, но используется только по одному порту, на вход и выход. Сейчас мы ожидаем когда проблема появится снова, чтобы точно сказать, что из-за количество пакетов становиться шлюзу плохо (поставили на мониторинг все магистрали на pps). Тогда будет все ясно. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
st_re Опубликовано 12 декабря, 2010 · Жалоба как применяли параметры?если через sysctl.conf и /etc/rc.d/sysctl restart - то это бага этого скрипта. надо в два этапа, например dev.em.2.rx_int_delay=100 dev.em.2.rx_int_delay=500 через команду sysctl сначало добавляли. Да и перезагружали шлюз недавно (в sysctl.conf прописано). в дровах есть проблема, насколько я вижу ее никто не правил. Единожды установленные парамеры (вот эти самые delay) сбрасываются по разным поводам, типа появления линка. т.е. на стандартной загрузке значения из sysctl.conf не работают никогда. при этом в sysctl они показываются, а в драйвере их нет. Там дефолтные. Соответственно после загрузки следует применить их еще раз (внимание, /etc/rc.d/sysctl не переустанавливает значения на уже стоящий там значения. т.е или в sysctl.conf их, как показано выше писать по 2 раза или звать что то типа egrep '^dev\.em\.' /etc/sysctl.conf | while read line; do sysctl $line; done и это запускать уже после загрузки) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Сильвер Опубликовано 13 декабря, 2010 · Жалоба Оба шлюза под управлением FreeBSD 7.3 с yandex драйверами 1.36.2.17 (сетевые Intel® PRO/1000, хорошие сетевые, с трафиком не подводили) [off] Просто интересно, а яндексные драйвера ещё актуальны по сравнению со стандартными? [/off] Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
nerik Опубликовано 13 декабря, 2010 · Жалоба Просто интересно, а яндексные драйвера ещё актуальны по сравнению со стандартными? С ними шлюзы очень хорошо трафик жуют. Тем более стандартные не разбрасывают по ядрам нагрузку. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
make.kernel Опубликовано 14 декабря, 2010 (изменено) · Жалоба Просто интересно, а яндексные драйвера ещё актуальны по сравнению со стандартными? С ними шлюзы очень хорошо трафик жуют. Тем более стандартные не разбрасывают по ядрам нагрузку. Шлюзы жуют трафик, нагрузка разбрасывается по ядрам, это хорошо. Но, при переходе на netisr сильнее грузится проц но пробегает больше трафика, пик подростает где-то так мегабит с 700 до 800. Конечно мои эксперименты могут дивным образом совпадать с фазой луны и направлением ветра, но разница между 700 и 800 мбит на разных драйверах заметна была. Списали на глюки с packet reordering из-за рандомной раскидки пакетов по ядрам под нагрузкой и забили, перешли на стандартные. Хотя это может быть у меня только так, вообще на подземный стук похоже. Изменено 14 декабря, 2010 пользователем make.kernel Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
nerik Опубликовано 14 декабря, 2010 · Жалоба Шлюзы жуют трафик, нагрузка разбрасывается по ядрам, это хорошо. Но, при переходе на netisr сильнее грузится проц но пробегает больше трафика, пик подростает где-то так мегабит с 700 до 800. Конечно мои эксперименты могут дивным образом совпадать с фазой луны и направлением ветра, но разница между 700 и 800 мбит на разных драйверах заметна была. Списали на глюки с packet reordering из-за рандомной раскидки пакетов по ядрам под нагрузкой и забили, перешли на стандартные. Хотя это может быть у меня только так, вообще на подземный стук похоже. Отходим от темы, я не писал что у меня проблема с перегрузкой трафика, шлюз выдерживает 700 Мегабит. Меня уже как год устраивают эти драйвера. Как только будет больше трафика и не будет резервов (новых шлюзов), вот тогда потестим стандартные драйвера. За информацию спасибо. А по факту сегодня 3 день как аномалий не было. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...