SoulDivider

Покажите lsmod

День добрый, коллеги. Возникла следующая проблема. Имеем cisco WS-C6509-NEB-A s72033_rp-ADVIPSERVICESK9_WAN-M Version 12.2(33)SXI9 sh ip ro xx.xx.70.1 Routing entry for xx.xx.70.1/32 Known via "static", distance 1, metric 0 Redistributing via ospf 1 Advertised by ospf 1 subnets Routing Descriptor Blocks: * xx.xx.68.5 Route metric is 0, traffic share count is 1 При этом трафик к этому префиксу сидет через RP sh ip cef xx.xx.70.1 internal xx.xx.70.1/32, epoch 6, flags receive, RIB[s], refcount 6, per-destination sharing sources: RIB, Vrt feature space: IPRM: 0x00048000 Broker: linked ifnums: (none) path 47D0D8B0, path list 47D07F78, share 1/1, type receive, for IPv4 receive output chain: receive sh mls cef xx.xx.70.1 detail Codes: M - mask entry, V - value entry, A - adjacency index, P - priority bit D - full don't switch, m - load balancing modnumber, B - BGP Bucket sel V0 - Vlan 0,C0 - don't comp bit 0,V1 - Vlan 1,C1 - don't comp bit 1 RVTEN - RPF Vlan table enable, RVTSEL - RPF Vlan table select Format: IPV4_DA - (8 | xtag vpn pi cr recirc tos prefix) Format: IPV4_SA - (9 | xtag vpn pi cr recirc prefix) M(74 ): E | 1 FFF 0 0 0 0 255.255.255.255 V(74 ): 8 | 1 0 0 0 0 0 xx.xx.70.1 (A:14 ,P:1,D:0,m:0 ,B:0 ) M(74 ): E | 1 FFF 0 0 0 255.255.255.255 V(74 ): 9 | 1 0 0 0 0 xx.xx.70.1 (V0:0 ,C0:0 ,V1:0 ,C1:0 ,RVTEN:0 ,RVTSEL:0 ) Судя по sources: RIB, Vrt этот адрес должен был бы быть нашим Но данный адрес никогда ни под какие вррп/хсрп итд не использовался. Есть аналогичный статик роут через тот же некстхоп на соседний адрес, проблем с ним нет, adjacency index нормальный и в cef source только RIB. Статик роут на проблемный префикс менял/удалял, не помогло. Перезагрузка железа крайне нежелательна и не известно исправит ли это проблему. Куда копать?

Умник, порожден. Соединений не много, грубо говоря в качестве теста генерировал спуфленый icmp echo request. На rx все распределялось равномерно, а вот reply лился в одну очередь. Не уверен на 100%, но мне кажется что 1 ядро(core5 в моем случае), к которому привязана единственная задействованная очередь может быть тонким местом. Плюс, как мне кажется, будут частые копирования данных с ядер в ядро(core5).

Здравствуйте, коллеги. Прошу помощи в следующей проблеме. Имеется сервер с 82576 и 2 Xeon 5650: # uname -r 2.6.36.3 # ethtool -i eth0 driver: igb version: 3.4.7 firmware-version: 1.8-2 bus-info: 0000:05:00.0 прерывания разбросаны по ядрам 64: 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 PCI-MSI-edge eth0 65: 91 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 PCI-MSI-edge eth0-TxRx-0 66: 28 20 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 PCI-MSI-edge eth0-TxRx-1 67: 36 0 20 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 PCI-MSI-edge eth0-TxRx-2 68: 34 0 0 14 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 PCI-MSI-edge eth0-TxRx-3 69: 38 0 0 0 11 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 PCI-MSI-edge eth0-TxRx-4 70: 41 0 0 0 0 7 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 PCI-MSI-edge eth0-TxRx-5 71: 44 0 0 0 0 0 4 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 PCI-MSI-edge eth0-TxRx-6 72: 47 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 PCI-MSI-edge eth0-TxRx-7 Проблема в следующем. Не распределяются исходящие пакеты по всем очередям, а льются все в одну # ethtool -S eth0 | grep tx_queue | grep packets tx_queue_0_packets: 0 tx_queue_1_packets: 0 tx_queue_2_packets: 3 tx_queue_3_packets: 0 tx_queue_4_packets: 0 tx_queue_5_packets: 1210115 tx_queue_6_packets: 0 tx_queue_7_packets: 0 Уж не знаю куда копать, ставил для теста Debian 2.6.32, драйвер менял (проблема как на ядерном igb, так и на новых версиях), разносил tx и rx по разным векторам. Прошу помощи. UPD. tc qdisc add dev eth0 root handle 1: multiq так же ничего не меняет.

"специалисты определили, что речь идет об электромагнитном воздействии на сайт" ©Леонид Ивлев http://news.argumenti.ru/society/2012/03/161620

Значит про syn proxy с использованием syn cookie мы не занем? Ах да, посмотрел, не услышал нигде про нульроут, мб и у меня проблема в ДНК? ПыСы Костич, запарил стирать посты, сказал - не отказывайся от слов!

Костич, это как так 250 миллионов поделить на 250 тысяч получается 8?

C&W, не? через них процентов 30 еле прососалось... с потерями. сколько гиг было никто то не знает :) я бы даже сказал процентов 20 им пришлось, хотя кто его знает как там на самом деле. с bgp игрались как придется. Не думаю, что Андерс сможет принять те 70% от 100Гб (кстати, а был ли мальчик?)

C&W, не?

Throughput = TCP Win/RTT. Уменьшайте задержку, если возможно, либо увеличивайте окно.

conf t vtp mode transparent

Блин, не успел зарегистрироваться. Поезд ушел?

для транзитной защиты от синфлуда используют разные tcp reset-ы, в IPv6 как раз хендшейк расширили для удобства работы разных транзитных решений. Судя по описанию предоставляемой вами услуги http://netvillage.ru/protection вы используете технику реверс-проксирования. В этом случае прямой и обратный трафик будет идти по одинаковому маршруту, и, по-сути, такие механизмы защиты как tcp-reset не нужны, можно обойтись как syn-proxy на промежуточном оборудовании, так и syn-cache или syn-cookies на узлах очистки. А недостатки tcp-reset вы описывали сами.

По-моему ключевая мысль была в том, что вы везде светитесь за АС Андерса. И говорили вам то, что именно вы не являетесь транзитной АС. Для существования транзитной АС необходимо как минимум пириться с 2мя АС. Или вы считаете военной тайной BGP Anycast?

Скажите, а откуда у вас транзитный трафик? Вы же только за Андерсом. В качестве кого? Обвиняемых? Свидетелей? Помню как то мой препод по аппаратным средствам защиты информации на теме про алгоритмы шифрования сказал, что криптостойкость алгоритма не должна зависеть от знания этого алгоритма третьими лицами. Разве алгоритм генерации syn cookie не известен третьим лицам? А прекратить анонсить дорогому пиру атакуемые префиксы не? А вообще пир не может быть платным, платят за аплинк. КЭП.