tier Опубликовано 16 марта, 2011 Добрый день! Решили натить пользователей на linux. Сразу же столкнулись со странным поведением трафика: # vnstat -tr 60 -i eth0 6592399 packets sampled in 60 seconds Traffic average for eth0 rx 196.95 Mbit/s 57217 packets/s tx 58.27 Mbit/s 52655 packets/s # vnstat -tr 60 -i eth1 2397043 packets sampled in 60 seconds Traffic average for eth1 rx 31.96 Mbit/s 18037 packets/s tx 171.71 Mbit/s 21912 packets/s eth0 - смотрит в мир eth1 - в сторону клиентов одно правило SNAT: сеть /19 натится в /20 -t nat -A POSTROUTING -s 10.0.0.0/19 -o eth0 -j SNAT --to-source хх.хх.64.0-хх.хх.79.255 --persistent При тестовом переводе клиентов на этот нат, на пару часов, никаких жалоб не поступало, Да и сами попользовавшись инетом через нат никакого дискомфорта не ощутили. Очень смущает практически двух кратная разница по пакетам на интерфейсах :) Буду благодарен за любую помощь/подсказку. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Abram Опубликовано 16 марта, 2011 tier, uname -r ethtool -S eth0 ethtool -S eth1 ethtool -i eth0 ethtool -i eth1 По-моему, у Вас счетчики сломаны. Где-то в мейллисте проскакивало не так давно. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Алексей Андриянов Опубликовано 16 марта, 2011 еще tail /var/log/messages хорошо бы. Может, там conntrack table full. и ethtool -k eth0 ethtool -k eth1 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
tier Опубликовано 17 марта, 2011 Счетчики в порядке, загруженность также снимается с интерфейсов cisco к которому подключен сервер, там та-же картина. Самое интересное при переводе трафика обратно на cisco nat, трафик становиться одинаковым на обоих интерфейсах, и равен трафику на интерфейсе eth1. C conntrack table тоже все в норме, лог чист. # uname -r 2.6.35-27-server # ethtool -i eth0 driver: igb version: 2.4.13 firmware-version: 1.4-3 bus-info: 0000:01:00.0 # ethtool -i eth1 driver: igb version: 2.4.13 firmware-version: 1.4-3 bus-info: 0000:01:00.1 # ethtool -k eth0 Offload parameters for eth0: rx-checksumming: on tx-checksumming: on scatter-gather: on tcp-segmentation-offload: on udp-fragmentation-offload: off generic-segmentation-offload: on generic-receive-offload: on large-receive-offload: off ntuple-filters: off receive-hashing: off # ethtool -k eth1 Offload parameters for eth1: rx-checksumming: on tx-checksumming: on scatter-gather: on tcp-segmentation-offload: on udp-fragmentation-offload: off generic-segmentation-offload: on generic-receive-offload: on large-receive-offload: off ntuple-filters: off receive-hashing: off # ethtool -S eth0 NIC statistics: rx_packets: 740963610 tx_packets: 683196875 rx_bytes: 324084949312 tx_bytes: 101868487343 rx_broadcast: 3 tx_broadcast: 27 rx_multicast: 0 tx_multicast: 6 multicast: 0 collisions: 0 rx_crc_errors: 0 rx_no_buffer_count: 0 rx_missed_errors: 686 tx_aborted_errors: 0 tx_carrier_errors: 0 tx_window_errors: 0 tx_abort_late_coll: 0 tx_deferred_ok: 0 tx_single_coll_ok: 0 tx_multi_coll_ok: 0 tx_timeout_count: 0 rx_long_length_errors: 0 rx_short_length_errors: 0 rx_align_errors: 0 tx_tcp_seg_good: 40833 tx_tcp_seg_failed: 0 rx_flow_control_xon: 0 rx_flow_control_xoff: 0 tx_flow_control_xon: 0 tx_flow_control_xoff: 0 rx_long_byte_count: 324084949312 tx_dma_out_of_sync: 0 tx_smbus: 0 rx_smbus: 0 dropped_smbus: 0 rx_errors: 0 tx_errors: 0 tx_dropped: 0 rx_length_errors: 0 rx_over_errors: 0 rx_frame_errors: 0 rx_fifo_errors: 686 tx_fifo_errors: 0 tx_heartbeat_errors: 0 tx_queue_0_packets: 170357854 tx_queue_0_bytes: 24514313759 tx_queue_0_restart: 0 tx_queue_1_packets: 171167978 tx_queue_1_bytes: 25213824505 tx_queue_1_restart: 0 tx_queue_2_packets: 167858829 tx_queue_2_bytes: 23694875426 tx_queue_2_restart: 0 tx_queue_3_packets: 173812214 tx_queue_3_bytes: 24987430556 tx_queue_3_restart: 0 rx_queue_0_packets: 184846144 rx_queue_0_bytes: 79303004015 rx_queue_0_drops: 0 rx_queue_0_csum_err: 8341 rx_queue_0_alloc_failed: 0 rx_queue_1_packets: 187426815 rx_queue_1_bytes: 79888594132 rx_queue_1_drops: 0 rx_queue_1_csum_err: 73915 rx_queue_1_alloc_failed: 0 rx_queue_2_packets: 183818168 rx_queue_2_bytes: 80306063342 rx_queue_2_drops: 0 rx_queue_2_csum_err: 32430 rx_queue_2_alloc_failed: 0 rx_queue_3_packets: 184872483 rx_queue_3_bytes: 81623433383 rx_queue_3_drops: 0 rx_queue_3_csum_err: 36190 rx_queue_3_alloc_failed: 0 # ethtool -S eth1 NIC statistics: rx_packets: 227507872 tx_packets: 278109573 rx_bytes: 54237811266 tx_bytes: 276637724843 rx_broadcast: 0 tx_broadcast: 19 rx_multicast: 0 tx_multicast: 6 multicast: 0 collisions: 0 rx_crc_errors: 0 rx_no_buffer_count: 0 rx_missed_errors: 0 tx_aborted_errors: 0 tx_carrier_errors: 0 tx_window_errors: 0 tx_abort_late_coll: 0 tx_deferred_ok: 0 tx_single_coll_ok: 0 tx_multi_coll_ok: 0 tx_timeout_count: 0 rx_long_length_errors: 0 rx_short_length_errors: 0 rx_align_errors: 0 tx_tcp_seg_good: 30937219 tx_tcp_seg_failed: 0 rx_flow_control_xon: 0 rx_flow_control_xoff: 0 tx_flow_control_xon: 0 tx_flow_control_xoff: 0 rx_long_byte_count: 54237811266 tx_dma_out_of_sync: 0 tx_smbus: 0 rx_smbus: 0 dropped_smbus: 0 rx_errors: 0 tx_errors: 0 tx_dropped: 0 rx_length_errors: 0 rx_over_errors: 0 rx_frame_errors: 0 rx_fifo_errors: 0 tx_fifo_errors: 0 tx_heartbeat_errors: 0 tx_queue_0_packets: 68990943 tx_queue_0_bytes: 67941626306 tx_queue_0_restart: 0 tx_queue_1_packets: 70688539 tx_queue_1_bytes: 68253855839 tx_queue_1_restart: 0 tx_queue_2_packets: 68850608 tx_queue_2_bytes: 68868834145 tx_queue_2_restart: 0 tx_queue_3_packets: 69579483 tx_queue_3_bytes: 70338134959 tx_queue_3_restart: 0 rx_queue_0_packets: 57008133 rx_queue_0_bytes: 13325746443 rx_queue_0_drops: 0 rx_queue_0_csum_err: 123 rx_queue_0_alloc_failed: 0 rx_queue_1_packets: 57446776 rx_queue_1_bytes: 13975619659 rx_queue_1_drops: 0 rx_queue_1_csum_err: 110 rx_queue_1_alloc_failed: 0 rx_queue_2_packets: 55595857 rx_queue_2_bytes: 12641250659 rx_queue_2_drops: 0 rx_queue_2_csum_err: 85 rx_queue_2_alloc_failed: 0 rx_queue_3_packets: 57457106 rx_queue_3_bytes: 13385163017 rx_queue_3_drops: 0 rx_queue_3_csum_err: 89 rx_queue_3_alloc_failed: 0 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Ivan_83 Опубликовано 17 марта, 2011 mtu на интерфейсах линуха одинаковый? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
tier Опубликовано 17 марта, 2011 да, mtu одинаковые. пробовали увеличить mtu, но никакой разницы не заметили. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Abram Опубликовано 17 марта, 2011 (изменено) Еще для диагностики: iptables-save iptables -t nat -L -nv Попытка лечения (были с этим глюки, мало ли): ethtool -K eth0 gro off ethtool -K eth1 gro off Заодно и gso туда же. Если в iptables есть chain-ы, то обновиться до 2.6.35.11 либо 2.6.36 (была бага). А вообще, что это за линух? Неужли бубунта? :) Изменено 17 марта, 2011 пользователем Abram Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
tier Опубликовано 17 марта, 2011 (изменено) Неужли бубунта? :):) она самая. # uname -a Linux nat 2.6.35-27-server #48-Ubuntu SMP Tue Feb 22 21:53:16 UTC 2011 x86_64 GNU/Linux из iptables убрал все кроме SNAT # iptables-save # Generated by iptables-save v1.4.9.1 on Thu Mar 17 14:37:52 2011 [quot]raw :PREROUTING ACCEPT [29006194:8474717917] :OUTPUT ACCEPT [145032:21311996] COMMIT # Completed on Thu Mar 17 14:37:52 2011 # Generated by iptables-save v1.4.9.1 on Thu Mar 17 14:37:52 2011 [/quot]mangle :PREROUTING ACCEPT [29006209:8474724564] :INPUT ACCEPT [2627:159820] :FORWARD ACCEPT [28830541:8443643808] :OUTPUT ACCEPT [145032:21311996] :POSTROUTING ACCEPT [28975573:8464955804] COMMIT # Completed on Thu Mar 17 14:37:52 2011 # Generated by iptables-save v1.4.9.1 on Thu Mar 17 14:37:52 2011 [quot]nat :PREROUTING ACCEPT [523391:48756300] :OUTPUT ACCEPT [0:0] :POSTROUTING ACCEPT [149170:16448715] -A POSTROUTING -s 10.0.0.0/19 -o eth0 -j SNAT --to-source xx.xx.64.0-xx.xx.79.255 --persistent COMMIT # Completed on Thu Mar 17 14:37:52 2011 # Generated by iptables-save v1.4.9.1 on Thu Mar 17 14:37:52 2011 [/quot]filter :INPUT ACCEPT [2628:159872] :FORWARD ACCEPT [28831194:8443900055] :OUTPUT ACCEPT [145034:21312854] COMMIT # Completed on Thu Mar 17 14:37:52 2011 # iptables -t nat -L -nv Chain PREROUTING (policy ACCEPT 1094K packets, 94M bytes) pkts bytes target prot opt in out source destination Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes) pkts bytes target prot opt in out source destination Chain POSTROUTING (policy ACCEPT 311K packets, 32M bytes) pkts bytes target prot opt in out source destination 783K 63M SNAT all -- * eth0 10.0.0.0/19 0.0.0.0/0 to:xx.xx.64.0-xx.xx.79.255 persistent подкрутил gro и gso, картина та-же :( Изменено 17 марта, 2011 пользователем tier Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
SiXeD Опубликовано 17 марта, 2011 хх.хх.64.0-хх.хх.79.255 может я туплю, но не до хрена ли? 200мбит/с где-то 20т-25т пакетов нормального трафа, всё остальное скорее всего мусор. слишком большая под сеть в инет отключи tcp-segmentation-offload: on , он бьёт большие пакеты на фрагменты Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
tier Опубликовано 17 марта, 2011 Сейчас сеть /19 натится в сеть /20, далее в зависимости от того как поведет себя этот нат переведу туда еще /19 приватных адресов. Сейчас эти клиенты натятся на cisco 7301, и траффик на интерфейсах одинаковый, переключаю на linux nat и сюрприз в виде 2х кратного увеличения pps :) всё остальное скорее всего мусор.Вот и пытаюсь понять откуда этот мусор, как с ним бороться, и нужно ли.tcpdump на eth0 ловит множество мелких пакетов вида: 15:43:50.820188 IP 94.231.160.90.29928 > xx.xx.68.0.41220: UDP, length 30 15:48:31.452295 IP 213.79.113.130.35691 > xx.xx.78.204.49832: UDP, length 106 tso тоже выключил, без изменений. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Abram Опубликовано 17 марта, 2011 Неужли бубунта? :):) она самая. Ёбаный стыд.Уберите, поставьте Arch/Gentoo/Slackware (лично мне нравится первый), и будем разбираться дальше. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
tier Опубликовано 17 марта, 2011 Каюсь, сектант :) Пока смена OS на крайний случай. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
vitalyb Опубликовано 17 марта, 2011 проверьте, может у вас какая-то сеть закольцована - поэтому пакеты бегают туда-сюда пока ttl не истечет Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Abram Опубликовано 17 марта, 2011 tier, vitalyb дело говорит - попробуйте. Насчет бубунты, поменяйте хотя бы ядро на свежее ванильное. Хотя бы в порядке эксперимента. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
SiXeD Опубликовано 17 марта, 2011 проверьте, может у вас какая-то сеть закольцована - поэтому пакеты бегают туда-сюда пока ttl не истечетОчень может быть, route в студию.но чё гадать, ставишь сенсор на оба интерфейса, собираешь статистику (5 сек достаточно ) потом из статистики eth0 убираешь статистику eth1 анализируешь оставшийся мусор, и тебе сразу в голову приходит ответ Но так оставлять не в коем случае нельзя, поток увеличится до 400 мб и ляжет твоя Ubunta зы: Gentoo рулит (она не долго собирается, её долго собирают :))) ) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
tier Опубликовано 17 марта, 2011 проверьте, может у вас какая-то сеть закольцована - поэтому пакеты бегают туда-сюда пока ttl не истечетда, была такая мысль, роуты проверял. но чё гадать, ставишь сенсор на оба интерфейса, собираешь статистику (5 сек достаточно ) потом из статистики eth0 убираешь статистику eth1 анализируешь оставшийся мусор, и тебе сразу в голову приходит ответспс, как-то сразу в голову не пришло диффнуть статистику между интерфейсами, завтра попробую. Abram, SiXeD уже самому интересно сколько потянет убунта, на родном ядре, траффика :) но новое ядро уже собрали :) P.S. может кто сталкивался и есть решение как логировать nat трансляции, пока собираю лог с помощью Ulogd2 + NFCT plugin. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
SiXeD Опубликовано 17 марта, 2011 P.S. может кто сталкивался и есть решение как логировать nat трансляции, пока собираю лог с помощью Ulogd2 + NFCT plugin. а что это такое и зачем оно тебе надо? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
tier Опубликовано 17 марта, 2011 Требование начальства и органов. кто куда и когда ходил. На cisco все просто, логи шлются на syslog сервер, суточный лог выходит порядка 3-4 гиг. а тут за час 1 гиг получается. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
SiXeD Опубликовано 17 марта, 2011 (изменено) а тут за час 1 гиг получается.у меня за таже фигня с ipcad, 400 GB в месяц, решение лить в другое место и архивить, 40GB в месяц не так критично и ещё смотря как часто ты снимаешь инфу, каждые 5(400gb) минут или 1(70gb) раз за час Изменено 17 марта, 2011 пользователем SiXeD Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
bos9 Опубликовано 18 марта, 2011 Требование начальства и органов. кто куда и когда ходил. а можно подробнее? это в рамках СОРМ или все-таки блаж начальства? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
SiXeD Опубликовано 19 марта, 2011 Требование начальства и органов. кто куда и когда ходил. а можно подробнее? это в рамках СОРМ или все-таки блаж начальства? Сорм собирает только ту инфу на которую поставил фильтра админ(отд. К), а биллинг должен собирать детализацию согласно (Приказу Министерства Информационных Технологий и связи РФ от 2 июля 2007г. под номером 73) как известно за эти 4 года каналы выросли раз в 20, а что будет через 2-3 года думайте сами. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Ivan Rostovikov Опубликовано 19 марта, 2011 Будьте любезны цитату из этого приказа, которая прямо указывает на обязанность оператора хранить "детализацию" по трафику ? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
SiXeD Опубликовано 21 марта, 2011 Понятия "Детализация" там даже НЕТ. НО есть про сбор данных о трафике потребленных услуг по пропуску трафика с учетом их характеристик (длительность/объем оказанной услуги по пропуску трафика, дата и время начала оказания услуги по пропуску трафика и иные характеристики оказанной услуги по пропуску трафика, влияющие на результаты расчета) Которые можно трактовать как угодно, вплоть до каждой сессии, которая может в очередной момент стать бесплатной и её необходимо пересчитать. зы: Детальку хранить не обязательно. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Ivan Rostovikov Опубликовано 21 марта, 2011 Именно об этом я и говорю. Оператор обязан хранить информацию влияющую на тарифицирование. Выполнять функции правоохранительных органов - он не обязан. Перлюстрация трафика (выяснение кто куда ходил) это задача именно этих органов. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
tier Опубликовано 21 марта, 2011 Конечно их задача, вот они ее и решают наиболее простым способом :) По сабжу, все пытаюсь выяснить откуда лишние пакеты на внешнем интерфейсе, поставил сенсор, и коллектор flow, собрал данные с разбивкой по 1 минуте, за пол часа работы ната. Подскажите как получить разницу и выявить аномалии? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...