Megas

Интересно, в 4ре муфты влезут все?

Первый раз вижу чтобы gluster отвалился. Можно больше подробностей, сколько чего и как? и какие версии.

Возможно вам подойдет что-то типо MX480 или MX960, вполне возможно они справятся с вашими задачами. Главное не берите брокад. В вот full к сожалению по нашему времени только в MX...

Mystray спасибо, уже перевел клиентов в ядро на ICX6610-48 К сожалению проблема стала еще лучше видна. Вот пример её: создаю новый влан: 222 #sh vlan 222 Total PORT-VLAN entries: 27 Maximum PORT-VLAN entries: 64 Legend: [stk=Stack-Id, S=Slot] PORT-VLAN 222, Name [None], Priority level0, in single spanning tree domain Untagged Ports: (U1/M1) 41 Tagged Ports: None Uplink Ports: None DualMode Ports: None Mac-Vlan Ports: None Monitoring: Disabled Проверяю порт который в нем: #sh vlan ethernet 1/1/41 Total PORT-VLAN entries: 27 Maximum PORT-VLAN entries: 64 Legend: [stk=Stack-Id, S=Slot] PORT-VLAN 222, Name [None], Priority level0, in single spanning tree domain Untagged Ports: (U1/M1) 41 Tagged Ports: None Uplink Ports: None DualMode Ports: None Mac-Vlan Ports: None Monitoring: Disabled SINGLE-SPANNING-TREE-VLAN, Name Single-spanning-tree-vlan, Priority level0, Untagged Ports: (U1/M1) 5 13 14 39 40 41 42 43 44 Untagged Ports: (U1/M2) 1 2 3 4 5 6 7 8 9 10 Untagged Ports: (U1/M3) 3 Tagged Ports: (U1/M1) 1 2 3 4 6 7 8 9 10 11 12 15 Tagged Ports: (U1/M1) 16 17 18 19 20 21 22 23 24 25 26 27 Tagged Ports: (U1/M1) 28 29 30 31 32 33 34 35 36 37 38 45 Tagged Ports: (U1/M1) 46 47 48 Tagged Ports: (U1/M3) 1 2 4 5 6 7 8 Uplink Ports: None DualMode Ports: None Mac-Vlan Ports: None Monitoring: Disabled Дальше просто на сервере шнур которого подключен в 41й порт запускаю tcpdump. Вот теперь действительно думаю, то ли я дурак, толи лыжи такие. Такое чувство что проблемы создает этот rstp на брокаде в ввиде 1го влана. Никаких igmp или multicast на свиче не включено.

К сожалению ситуация в ядре повторяется. Сейчас оформил запрос поставщикам, пусть попробуют разбьяснить что за магия такая, если конечно осилят.

NiTr0 да, я похоже не правильно выразился, в общем стало интересно... попробую разобраться какая железка дает сбой. Меня удивил тот факт что железки довольно мощные и чтобы на их базе такое творилось. Но по статистике маков: ядро 1.5к маков. ex3300 400 маков. ex2200 300 маков. HP тоже около 300маков.

Только не кидайте тухлыми помидорами, пожалуйста, но вот реально не могу понять. Схема такая: MX80 --- Brocade --- EX3300x2 (VirtualChassie) +-- EX2200 --- CLIENT1 ____________________________________+-- HP 2810 --- CLIENT2 Клиент на котором вижу проблему подключен к свичу EX2200 tcpdump на этом клиенте: 22:54:55.169371 88:62:7b:fd:be:90 > d2:35:24:3c:44:ca, ethertype IPv4 (0x0800), length 60: 178.94.179.232.51546 > 192.168.9.242.http: Flags [.], ack 887528, win 1117, length 0 22:54:55.170601 88:62:7b:fd:be:90 > d2:35:24:3c:44:ca, ethertype IPv4 (0x0800), length 60: 178.94.179.232.51546 > 192.168.9.242.http: Flags [.], ack 890448, win 1106, length 0 22:54:55.175535 88:62:7b:fd:be:90 > d2:35:24:3c:44:ca, ethertype IPv4 (0x0800), length 60: 178.94.179.232.51546 > 192.168.9.242.http: Flags [.], ack 894828, win 1100, length 0 22:54:55.176033 88:62:7b:fd:be:90 > d2:35:24:3c:44:ca, ethertype IPv4 (0x0800), length 60: 178.94.179.232.51546 > 192.168.9.242.http: Flags [.], ack 896288, win 1100, length 0 22:54:55.177540 88:62:7b:fd:be:90 > d2:35:24:3c:44:ca, ethertype IPv4 (0x0800), length 60: 178.94.179.232.51546 > 192.168.9.242.http: Flags [.], ack 900668, win 1134, length 0 22:54:55.180954 88:62:7b:fd:be:90 > d2:35:24:3c:44:ca, ethertype IPv4 (0x0800), length 60: 178.94.179.232.51546 > 192.168.9.242.http: Flags [.], ack 902128, win 1134, length 0 22:54:55.181457 88:62:7b:fd:be:90 > d2:35:24:3c:44:ca, ethertype IPv4 (0x0800), length 60: 178.94.179.232.51546 > 192.168.9.242.http: Flags [.], ack 906508, win 1163, length 0 22:54:55.182445 88:62:7b:fd:be:90 > d2:35:24:3c:44:ca, ethertype IPv4 (0x0800), length 60: 178.94.179.232.51546 > 192.168.9.242.http: Flags [.], ack 907968, win 1174, length 0 22:54:55.185894 88:62:7b:fd:be:90 > d2:35:24:3c:44:ca, ethertype IPv4 (0x0800), length 60: 178.94.179.232.51546 > 192.168.9.242.http: Flags [.], ack 910888, win 1174, length 0 22:54:55.186363 88:62:7b:fd:be:90 > d2:35:24:3c:44:ca, ethertype IPv4 (0x0800), length 60: 178.94.179.232.51546 > 192.168.9.242.http: Flags [.], ack 913808, win 1180, length 0 22:54:55.190605 88:62:7b:fd:be:90 > d2:35:24:3c:44:ca, ethertype IPv4 (0x0800), length 60: 178.94.179.232.51546 > 192.168.9.242.http: Flags [.], ack 919648, win 1174, length 0 22:54:55.192060 88:62:7b:fd:be:90 > d2:35:24:3c:44:ca, ethertype IPv4 (0x0800), length 60: 178.94.179.232.51546 > 192.168.9.242.http: Flags [.], ack 922568, win 1174, length 0 22:54:55.197998 88:62:7b:fd:be:90 > d2:35:24:3c:44:ca, ethertype IPv4 (0x0800), length 60: 178.94.179.232.51546 > 192.168.9.242.http: Flags [.], ack 925488, win 1174, length 0 22:54:55.198925 88:62:7b:fd:be:90 > d2:35:24:3c:44:ca, ethertype IPv4 (0x0800), length 60: 178.94.179.232.51546 > 192.168.9.242.http: Flags [.], ack 928408, win 1169, length 0 22:54:55.207433 88:62:7b:fd:be:90 > 62:68:46:aa:05:3e, ethertype IPv4 (0x0800), length 60: 109.87.238.140.53135 > 192.168.9.142.http: Flags [.], seq 620980824:620980825, ack 1156948483, win 16425, length 1 22:54:55.212372 88:62:7b:fd:be:90 > 62:68:46:aa:05:3e, ethertype IPv4 (0x0800), length 60: 109.87.238.140.53132 > 192.168.9.142.http: Flags [.], seq 1912653980:1912653981, ack 2083225405, win 16425, length 1 22:54:55.221096 88:62:7b:fd:be:90 > d2:35:24:3c:44:ca, ethertype IPv4 (0x0800), length 60: 178.94.179.232.51546 > 192.168.9.242.http: Flags [.], ack 931328, win 1163, length 0 22:54:55.222095 88:62:7b:fd:be:90 > d2:35:24:3c:44:ca, ethertype IPv4 (0x0800), length 60: 178.94.179.232.51546 > 192.168.9.242.http: Flags [.], ack 934248, win 1163, length 0 22:54:55.276052 88:62:7b:fd:be:90 > d2:35:24:3c:44:ca, ethertype IPv4 (0x0800), length 60: 178.94.179.232.51546 > 192.168.9.242.http: Flags [.], ack 934468, win 1162, length 0 22:54:55.412492 88:62:7b:fd:be:90 > 62:68:46:aa:05:3e, ethertype IPv4 (0x0800), length 60: 109.87.238.140.53133 > 192.168.9.142.http: Flags [.], seq 2619626723:2619626724, ack 1503975523, win 16425, length 1 Проверка всех связок arp на ядре и т.д. для d2:35:24:3c:44:ca и 62:68:46:aa:05:3e на роутере ведет на 192.168.9.142 и 192.168.9.242 Может кто-то неучу обьяснить, с какого лешего трафик который не принадлежит этому серверу и мак которого нету на CLIENT1 получает этот трафик? Я не верю что свич может плужить и слать трафик не туда, и сервер которому принадлежит 192.168.9.142 192.168.9.242 находятся в одной сети с нормальным клиентом 192.168.9.20 192.168.9.90 Чтобы еще раз прояснить, CLIENT1 на своем сетевом интерфейсе получает трафик который принадлежит CLIENT2, оба клиента находятся в одном влане но на разных коммутаторах.

Народ, а подскажите по шейперу на junos, если навесить шейпер на /24, это будет сумарный на всю сеть или на каждый /32 ?

Конечно не туда, может за вас сделать эту всю работу? Берите забикс и пилите пока не получите идеала, это как конструктор, только для взрослых и желающих, а не желающее в соседней теме просят у желающих...

Дык, какие проблемы берете обычного паучка и берете на выходе получаете нужного вам паучка

не в тему, но, у меня на qfx3500 после десятка перетыкиваний модулей порт стал раком и перестал принимать в обще модуля, вылился с ошибкой, в итоге пришлось бутать всю железку.

Да, похоже на то, mx по дефолту арп держит 20 минут кажется, от сюда наверное такая ситуация и возникла.

мы не провайдер) хостер. по этой причине не терменируем, на роутере шлюз для клиентов внутреней сети и bgp на аплинков, схема безумно простая без изврата. просто флуд осел на роутере и положил его начинку, вот это очень сильно смутило, так как уже много было ddos и прочего, но такого чтобы при этом умирали ссесии никогда.

роутер не терминирует, это обычный роутер не более, только белые ip машрутизируются.

да, совершенно верно, re ушел в полку и вернулся от туда только после blackhole ипа клиента.

к сожалению не был, но не совсем понятно как на него попадали пакеты если атака велась на хост в сети

Понимаю сейчас закидают помидорами, но хотелось бы понять что произошло. В один прекрасный вечер на одного клиента начали лить небольшой флуд: 2016-04-11 22:07:49.247926 18.130.60.236:49980 > *.*.*.*:80 protocol: tcp flags: syn frag: 0 packets: 1 size: 60 bytes sample ratio: 1 2016-04-11 22:07:49.247950 166.184.79.130:63220 > *.*.*.*:80 protocol: tcp flags: syn frag: 0 packets: 1 size: 64 bytes sample ratio: 1 2016-04-11 22:07:49.247960 175.92.175.135:63153 > *.*.*.*:80 protocol: tcp flags: syn frag: 0 packets: 1 size: 64 bytes sample ratio: 1 2016-04-11 22:07:49.247988 *.*.*.*:80 > 84.197.3.246:47685 protocol: tcp flags: syn,ack frag: 0 packets: 1 size: 62 bytes sample ratio: 1 2016-04-11 22:07:49.248017 *.*.*.*:80 > 167.108.187.130:38199 protocol: tcp flags: syn,ack frag: 0 packets: 1 size: 62 bytes sample ratio: 1 2016-04-11 22:07:49.248033 104.244.209.106:47334 > *.*.*.*:80 protocol: tcp flags: syn frag: 0 packets: 1 size: 64 bytes sample ratio: 1 2016-04-11 22:07:49.248044 1.35.153.2:58862 > *.*.*.*:80 protocol: tcp flags: syn frag: 0 packets: 1 size: 64 bytes sample ratio: 1 2016-04-11 22:07:49.248054 *.*.*.*:80 > 202.224.240.116:2082 protocol: tcp flags: syn,ack frag: 0 packets: 1 size: 62 bytes sample ratio: 1 2016-04-11 22:07:49.248065 *.*.*.*:80 > 171.245.171.109:17675 protocol: tcp flags: syn,ack frag: 0 packets: 1 size: 62 bytes sample ratio: 1 2016-04-11 22:07:49.248090 *.*.*.*:80 > 49.172.67.114:19329 protocol: tcp flags: syn,ack frag: 0 packets: 1 size: 62 bytes sample ratio: 1 2016-04-11 22:07:49.248110 *.*.*.*:80 > 117.80.78.229:51624 protocol: tcp flags: syn,ack frag: 0 packets: 1 size: 62 bytes sample ratio: 1 2016-04-11 22:07:49.248148 92.15.233.35:2832 > *.*.*.*:80 protocol: tcp flags: syn frag: 0 packets: 1 size: 60 bytes sample ratio: 1 2016-04-11 22:07:49.248189 32.18.162.33:40429 > *.*.*.*:80 protocol: tcp flags: syn frag: 0 packets: 1 size: 60 bytes sample ratio: 1 2016-04-11 22:07:49.248200 131.212.189.59:20669 > *.*.*.*:80 protocol: tcp flags: syn frag: 0 packets: 1 size: 64 bytes sample ratio: 1 2016-04-11 22:07:49.248211 *.*.*.*:80 > 82.156.230.46:20443 protocol: tcp flags: syn,ack frag: 0 packets: 1 size: 62 bytes sample ratio: 1 2016-04-11 22:07:49.248221 *.*.*.*:80 > 76.101.24.252:45931 protocol: tcp flags: syn,ack frag: 0 packets: 1 size: 62 bytes sample ratio: 1 2016-04-11 22:07:49.248232 *.*.*.*:80 > 203.187.149.165:57215 protocol: tcp flags: syn,ack frag: 0 packets: 1 size: 62 bytes sample ratio: 1 2016-04-11 22:07:49.248243 *.*.*.*:80 > 15.212.92.248:3338 protocol: tcp flags: syn,ack frag: 0 packets: 1 size: 62 bytes sample ratio: 1 2016-04-11 22:07:49.248254 *.*.*.*:80 > 216.134.85.195:21563 protocol: tcp flags: syn,ack frag: 0 packets: 1 size: 62 bytes sample ratio: 1 2016-04-11 22:07:49.248264 113.167.56.253:24624 > *.*.*.*:80 protocol: tcp flags: rst frag: 0 packets: 1 size: 64 bytes sample ratio: 1 2016-04-11 22:07:49.248275 244.61.58.12:7358 > *.*.*.*:80 protocol: tcp flags: syn frag: 0 packets: 1 size: 60 bytes sample ratio: 1 2016-04-11 22:07:49.248291 *.*.*.*:80 > 85.42.190.216:28081 protocol: tcp flags: syn,ack frag: 0 packets: 1 size: 62 bytes sample ratio: 1 2016-04-11 22:07:49.248308 *.*.*.*:80 > 195.158.42.156:25623 protocol: tcp flags: syn,ack frag: 0 packets: 1 size: 62 bytes sample ratio: 1 2016-04-11 22:07:49.248319 *.*.*.*:80 > 136.148.138.113:40637 protocol: tcp flags: syn,ack frag: 0 packets: 1 size: 62 bytes sample ratio: 1 2016-04-11 22:07:49.248329 *.*.*.*:80 > 125.196.40.11:49052 protocol: tcp flags: syn,ack frag: 0 packets: 1 size: 62 bytes sample ratio: 1 2016-04-11 22:07:49.248340 *.*.*.*:80 > 138.195.220.160:23985 protocol: tcp flags: syn,ack frag: 0 packets: 1 size: 62 bytes sample ratio: 1 2016-04-11 22:07:49.248351 *.*.*.*:80 > 148.2.58.166:42894 protocol: tcp flags: syn,ack frag: 0 packets: 1 size: 62 bytes sample ratio: 1 2016-04-11 22:07:49.248377 *.*.*.*:80 > 208.68.202.129:50132 protocol: tcp flags: syn,ack frag: 0 packets: 1 size: 62 bytes sample ratio: 1 2016-04-11 22:07:49.248392 73.16.255.195:51533 > *.*.*.*:80 protocol: tcp flags: syn frag: 0 packets: 1 size: 60 bytes sample ratio: 1 2016-04-11 22:07:49.248406 193.45.191.30:13713 > *.*.*.*:80 protocol: tcp flags: syn frag: 0 packets: 1 size: 60 bytes sample ratio: 1 2016-04-11 22:07:49.248419 38.247.145.228:37254 > *.*.*.*:80 protocol: tcp flags: syn frag: 0 packets: 1 size: 64 bytes sample ratio: 1 Трафик был смешной, около 30к пакетов и порядка 40мегабит, ок, выключил виртуалку клиенту, отправили уведомление и лег спать дальше, через 30 минут будет ТП, ссесии падают на аплинки, при чем из 10 сессий, уваливались 7 с внешними каналами и IX, в шоке, думал повреждение кабеля, так как на входящих каналах трафика так и не было, даже пакет рейт почти не поднялся, думал оптика лагает или где-то серьезно у кого-то упало на вышестоящих магистралях. Но спасибо pavel.odintsov за его продукт вижу тот же трафик: 2016-04-11 23:52:30.922482 35.101.210.147:34922 > *.*.*.*:80 protocol: tcp flags: syn frag: 0 packets: 1 size: 64 bytes sample ratio: 1 2016-04-11 23:52:30.922544 82.8.130.238:49856 > *.*.*.*:80 protocol: tcp flags: syn frag: 0 packets: 1 size: 64 bytes sample ratio: 1 2016-04-11 23:52:30.922571 229.155.110.52:14036 > *.*.*.*:80 protocol: tcp flags: syn frag: 0 packets: 1 size: 60 bytes sample ratio: 1 2016-04-11 23:52:30.922583 40.94.236.68:44544 > *.*.*.*:80 protocol: tcp flags: syn frag: 0 packets: 1 size: 64 bytes sample ratio: 1 2016-04-11 23:52:30.922593 232.96.71.41:34678 > *.*.*.*:80 protocol: tcp flags: syn frag: 0 packets: 1 size: 60 bytes sample ratio: 1 2016-04-11 23:52:30.922603 2.99.63.75:38556 > *.*.*.*:80 protocol: tcp flags: syn frag: 0 packets: 1 size: 64 bytes sample ratio: 1 2016-04-11 23:52:30.922613 90.217.55.25:45417 > *.*.*.*:80 protocol: tcp flags: syn frag: 0 packets: 1 size: 64 bytes sample ratio: 1 2016-04-11 23:52:30.922641 242.203.253.36:3654 > *.*.*.*:80 protocol: tcp flags: syn frag: 0 packets: 1 size: 60 bytes sample ratio: 1 2016-04-11 23:52:30.922652 56.85.240.73:14007 > *.*.*.*:80 protocol: tcp flags: syn frag: 0 packets: 1 size: 60 bytes sample ratio: 1 2016-04-11 23:52:30.922713 76.116.169.249:58495 > *.*.*.*:80 protocol: tcp flags: syn frag: 0 packets: 1 size: 64 bytes sample ratio: 1 2016-04-11 23:52:30.922728 208.177.2.125:55178 > *.*.*.*:80 protocol: tcp flags: syn frag: 0 packets: 1 size: 60 bytes sample ratio: 1 2016-04-11 23:52:30.922764 121.117.205.173:25636 > *.*.*.*:80 protocol: tcp flags: syn frag: 0 packets: 1 size: 64 bytes sample ratio: 1 2016-04-11 23:52:30.922787 168.63.117.77:45726 > *.*.*.*:80 protocol: tcp flags: syn frag: 0 packets: 1 size: 64 bytes sample ratio: 1 2016-04-11 23:52:30.922799 201.225.22.54:28647 > *.*.*.*:80 protocol: tcp flags: syn frag: 0 packets: 1 size: 60 bytes sample ratio: 1 2016-04-11 23:52:30.922830 168.29.138.146:17904 > *.*.*.*:80 protocol: tcp flags: syn frag: 0 packets: 1 size: 64 bytes sample ratio: 1 2016-04-11 23:52:30.922871 141.228.100.24:55396 > *.*.*.*:80 protocol: tcp flags: syn frag: 0 packets: 1 size: 64 bytes sample ratio: 1 Пакеты получается как летели на клиента так и летят, ок, отправляем в blackhole и все, роутер спустя 10 минут начинает жить нормальной жизнью. В качестве роутера стоит простой juniper mx 80, вот теперь чешится репа, оказывается просто вырубить конечного клиента уже не достаточно, надо весь трафик направлять в null, странная конечно ситуация и совсем не понятно почему умерла re на роутере.

Все очень просто, попробуйте использовать оборудование от Mikrotik.

Pavel, прекрасно вас понимаю, понимаю что в случае попыток встраивания алгоритма детекта брута тоже будет не сильно производительно, но может все таки вам удастся что-то влепить. Для меня например было бы достаточно увидеть когда один внешний хост делает больше N обращений к хостам внутри сети за N времени, к примеру по всем портам или только по опеределенным. Разбирать сам пакет не надо, только увидеть что кто-то сделал большее 100 обращений ко внутреним адресам в течении N времени.

http://www.truesystem.ru/press-center/release/360252/

Megas, не уважительно с вашей стороны лесть со своими проблемами в чужие темы! Создайте отделенную тему со своей проблемой, и мы с радостью её осудим. Согласен с вами, извиняюсь, но ваша тема она уже давно устарела, после того как есть fastnetmon и nfsen она себя исчерпала. В остальных случаях это только платные решения которые занимаются анализом flow потоков. У меня к вам встречный вопрос, ну задетектили вы дос и что дальше? Вот жизненый пример, льют 20ГБ, blackhole делать крайне не желательно, пострадают очень много клиентов, что делать в такой ситуации? Ваши внешние аплинки завалены, за overlimit вам уже операторы выставляют приличные счета, что вы будете делать в этой ситуации?

у меня тут другая напасть, как вот детектить глобальные брутфорсы на все сети... может у кого есть решение под рукой?

http://www.stableit.ru/2013/02/iptables-dns.html

Pavel, а скажите, на сколько сложно расширить чутка вашу систему и добавить в неё мониторинг не только pps, а мягко говорят брута? есть хосты которые делают брут сетей, хотелось бы отловить эту зараза, но вот какими средствами не совсем понятно пока. Я понимаю что в принципе можно сделать на роутере через дублирование пакетов и подсчет через тот же iptables но как-то хочется более элегантное решение и возможно стороними средствами.

Хм, а почему не? системный поможет администратор)