Megas Posted June 12, 2016 (edited) Только не кидайте тухлыми помидорами, пожалуйста, но вот реально не могу понять. Схема такая: MX80 --- Brocade --- EX3300x2 (VirtualChassie) +-- EX2200 --- CLIENT1 ____________________________________+-- HP 2810 --- CLIENT2 Клиент на котором вижу проблему подключен к свичу EX2200 ifconfig eth0 Link encap:Ethernet HWaddr 68:05:CA:2F:03:09 inet addr:192.168.9.90 Bcast:192.168.9.255 Mask:255.255.255.0 inet6 addr: fe80::6a05:caff:fe2f:309/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:1733954250 errors:0 dropped:8664 overruns:0 frame:0 TX packets:2766902402 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:260225231158 (242.3 GiB) TX bytes:3709556555653 (3.3 TiB) Interrupt:16 Memory:f7cc0000-f7ce0000 eth0:0 Link encap:Ethernet HWaddr 68:05:CA:2F:03:09 inet addr:192.168.9.20 Bcast:192.168.9.20 Mask:255.255.255.255 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 Interrupt:16 Memory:f7cc0000-f7ce0000 eth1 Link encap:Ethernet HWaddr FC:AA:14:67:62:EB inet addr:192.168.0.1 Bcast:192.168.0.7 Mask:255.255.255.248 inet6 addr: fe80::feaa:14ff:fe67:62eb/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:25756609124 errors:0 dropped:0 overruns:0 frame:0 TX packets:17896311360 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:27183362912079 (24.7 TiB) TX bytes:4935626003345 (4.4 TiB) lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 inet6 addr: ::1/128 Scope:Host UP LOOPBACK RUNNING MTU:65536 Metric:1 RX packets:260803414 errors:0 dropped:0 overruns:0 frame:0 TX packets:260803414 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:629087912874 (585.8 GiB) TX bytes:629087912874 (585.8 GiB) 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, оба клиента находятся в одном влане но на разных коммутаторах. Edited June 12, 2016 by Megas Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
NiTr0 Posted June 12, 2016 Я не верю что свич может плужить и слать трафик не туда элементарно: 1) коллизия маков 2) переполнение таблицы маков (свич превращается в хаб). смотреть таблицы маков, и думать... Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
Megas Posted June 12, 2016 (edited) NiTr0 да, я похоже не правильно выразился, в общем стало интересно... попробую разобраться какая железка дает сбой. Меня удивил тот факт что железки довольно мощные и чтобы на их базе такое творилось. Но по статистике маков: ядро 1.5к маков. ex3300 400 маков. ex2200 300 маков. HP тоже около 300маков. Edited June 12, 2016 by Megas Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
zhenya` Posted June 13, 2016 Если хп включён в 3300, то проблема в 3300. В коллизиях дело не в числе ) Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
Megas Posted June 13, 2016 К сожалению ситуация в ядре повторяется. Сейчас оформил запрос поставщикам, пусть попробуют разбьяснить что за магия такая, если конечно осилят. Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
Mystray Posted June 13, 2016 EX3300 знатно флудит, страдаем от этого. Попробуйте почистить на нем таблицу маков пару раз, может не повезет другому маку. Насколько я знаю, полноценного решения не существует (можно попробовать set ethernet-switching-options mac-lookup-length 12, но повысятся задержки и не факт, что поможет) Посмотрите show ethernet-switching mac-learning-log, там может быть ваш мак заучился и тут же разучился. А может и не быть. Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
Megas Posted June 13, 2016 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. 08:14:16.923436 88:62:7b:fd:be:90 > 26:c7:55:82:b8:73, ethertype IPv4 (0x0800), length 60: 50.63.202.9.80 > 192.168.9.102.61421: Flags [s.], seq 1590757148, ack 3351072856, win 16384, options [mss 1460], length 008:14:17.040492 88:62:7b:fd:be:90 > 62:68:46:aa:05:3e, ethertype IPv4 (0x0800), length 857: 46.211.66.188.28435 > 192.168.9.80: Flags [P.], seq 0:791, ack 36046, win 5068, options [nop,nop,TS val 3963633 ecr 1901386227], length 791 08:14:17.080436 88:62:7b:fd:be:90 > 62:68:46:aa:05:3e, ethertype IPv4 (0x0800), length 78: 46.211.66.188.28590 > 192.168.9.80: Flags [.], ack 2423006514, win 7059, options [nop,nop,TS val 3963644 ecr 1901381127,nop,nop,sack 1 {1449:26065}], length 0 08:14:17.124860 88:62:7b:fd:be:90 > 62:68:46:aa:05:3e, ethertype IPv4 (0x0800), length 78: 46.211.66.188.28590 > 192.168.9.80: Flags [.], ack 1, win 7059, options [nop,nop,TS val 3963648 ecr 1901381127,nop,nop,sack 1 {1449:27513}], length 0 08:14:17.280175 88:62:7b:fd:be:90 > 62:68:46:aa:05:3e, ethertype IPv4 (0x0800), length 78: 46.211.66.188.28590 > 192.168.9.80: Flags [.], ack 1, win 7059, options [nop,nop,TS val 3963656 ecr 1901381127,nop,nop,sack 1 {1449:28961}], length 0 08:14:17.300410 88:62:7b:fd:be:90 > 62:68:46:aa:05:3e, ethertype IPv4 (0x0800), length 78: 46.211.66.188.28590 > 192.168.9.80: Flags [.], ack 1, win 7059, options [nop,nop,TS val 3963662 ecr 1901381127,nop,nop,sack 1 {1449:30409}], length 0 08:14:17.339832 88:62:7b:fd:be:90 > 62:68:46:aa:05:3e, ethertype IPv4 (0x0800), length 78: 46.211.66.188.28590 > 192.168.9.80: Flags [.], ack 1, win 7059, options [nop,nop,TS val 3963668 ecr 1901381127,nop,nop,sack 1 {1449:31857}], length 0 08:14:17.339838 88:62:7b:fd:be:90 > 62:68:46:aa:05:3e, ethertype IPv4 (0x0800), length 78: 46.211.66.188.28590 > 192.168.9.80: Flags [.], ack 1, win 7059, options [nop,nop,TS val 3963672 ecr 1901381127,nop,nop,sack 1 {1449:33305}], length 0 08:14:17.360204 88:62:7b:fd:be:90 > 62:68:46:aa:05:3e, ethertype IPv4 (0x0800), length 78: 46.211.66.188.28590 > 192.168.9.80: Flags [.], ack 1, win 7059, options [nop,nop,TS val 3963679 ecr 1901381127,nop,nop,sack 1 {1449:34753}], length 0 08:15:19.782751 88:62:7b:fd:be:90 > 00:0c:29:78:60:0a, ethertype IPv4 (0x0800), length 60: 50.63.202.9.80 > 10.226.30.139.45006: Flags [s.], seq 693496655, ack 48522492, win 16384, options [mss 1460], length 0 08:15:21.953992 88:62:7b:fd:be:90 > ee:21:7c:97:5f:3f, ethertype IPv4 (0x0800), length 60: 50.63.202.9.80 > 192.168.9.127.45035: Flags [s.], seq 203507949, ack 1066741291, win 16384, options [mss 1460], length 0 Вот теперь действительно думаю, то ли я дурак, толи лыжи такие. Такое чувство что проблемы создает этот rstp на брокаде в ввиде 1го влана. Никаких igmp или multicast на свиче не включено. Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
uxcr Posted June 14, 2016 (edited) Судя по тому что мак-адрес dst нормальный - unicast flood у вас на каком-то из L2 по пути возникает часто. Stp logging есть возможность включить? Конкретно нужно смотреть частоту генерации пакетов tcn, и проверить что access-порты не влияют на топологию stp (edge). Edited June 14, 2016 by uxcr Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...