Azamat Опубликовано 15 октября, 2019 · Жалоба Всем доброго дня. в эксплуатации Nexus 3064 вылез странный глюк с обучением мак-адреса устройства - ни в какую не хочет помещать в таблицу. Суть такова: к nex3064 подключен c2960, к 2960 подключены 2 устройства одного типа. Оба должны получать адрес по dhcp. Оба шлют правильные discover, которые доходят до dhcp-сервера, и этот сервер на них отвечает. Причем dhcp пакеты проходят насквозь через 2960 и целевой nexus. Вот здесь начинается прикол. До одного из устройств offer доходит, до второго нет. Разбор показал, что мак-адрес первого устройства (которое получает offer от dhcp-сервера) внесен в таблицу мак-адресов на nexus, а мак второго - никак не хочет изучаться и вноситься в таблицу. Причем, если внести мак адрес статиком - все начинает работать, offer доходит. Удалить статическую запись - мак снова перестает фиксироваться в таблице. Вот сами маки: корявый - 00:1a:79:51:56:54 нормальный - 00:1a:79:3b:5c:fb Может кто-то сталкивался с подобным ? Будем признательны за любую подсказку Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
alexgreat Опубликовано 16 октября, 2019 · Жалоба Конфиги бы показали... И какая версия NXOSa? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Azamat Опубликовано 16 октября, 2019 · Жалоба NXOS 6.0(2)U5(3) где-то 113К маков на борту. Проблема пока только с одним. Конфиг примитивен, как и его функция в целом. Если какой-то конкретный участок конфига может вызвать сомнения - плз озвучьте. Это чтобы всю портянку не вываливать. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
azhur Опубликовано 16 октября, 2019 · Жалоба Может коллизия хэша при изучении МАК-адресов? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Azamat Опубликовано 16 октября, 2019 · Жалоба А как узнать ? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
azhur Опубликовано 16 октября, 2019 · Жалоба По найденной мной инфе, у этого коммутатора MAC table size (non-vPC) - 128000. Ваши 113000 адресов довольно близко подошли к этому лимиту, так что коллизии очень даже вероятны. Для начала нужно посмотреть в логи коммутатора, нет ли там сообщений типа 2019 May 19 22:09:56 csw-c3064-kir58-1 %-SLOT1-5-BCM_L2_HASH_COLLISION: L2 ENTRY unit=0 mac=20:89:84:f6:c2:69 vlan=417 port=0x0800081c 2019 May 19 22:09:57 csw-c3064-kir58-1 last message repeated 13 times Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Azamat Опубликовано 16 октября, 2019 · Жалоба нет, в логах все чисто. Более того, если этот мак внести статиком - все снова начинает нормально работать, статик/динамик - коллизия бы никуда не делась бы. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Umux Опубликовано 17 октября, 2019 · Жалоба Попробуйте поставить этот мак на сетевой карте какого-нибудь компьютера и запросить с него адрес по dhcp Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Azamat Опубликовано 17 октября, 2019 (изменено) · Жалоба первым делом сделали - адрес на нотник прилетел по dhcp нормально, но мак-адрес на нексусе не появлялся в таблице маков. Средствами нексуса сняли дамп по мак-адресу, в процессор dhcp пакет от устройства попадает (inband-low) - но в таблице мака нет: Frame 1: 444 bytes on wire (3552 bits), 348 bytes captured (2784 bits) on interface 0 Interface id: 0 Encapsulation type: Ethernet (1) Arrival Time: Oct 17, 2019 18:28:05.221254000 KGT [Time shift for this packet: 0.000000000 seconds] Epoch Time: 1571315285.221254000 seconds [Time delta from previous captured frame: 0.000000000 seconds] [Time delta from previous displayed frame: 0.000000000 seconds] [Time since reference or first frame: 0.000000000 seconds] Frame Number: 1 Frame Length: 444 bytes (3552 bits) Capture Length: 348 bytes (2784 bits) [Frame is marked: False] [Frame is ignored: False] [Protocols in frame: eth:vlan:ip:udp:bootp] Ethernet II, Src: 00:1a:79:51:56:54 (00:1a:79:51:56:54), Dst: ff:ff:ff:ff:ff:ff (ff:ff:ff:ff:ff:ff) Destination: ff:ff:ff:ff:ff:ff (ff:ff:ff:ff:ff:ff) Address: ff:ff:ff:ff:ff:ff (ff:ff:ff:ff:ff:ff) .... ..1. .... .... .... .... = LG bit: Locally administered address (this is NOT the factory default) .... ...1 .... .... .... .... = IG bit: Group address (multicast/broadcast) Source: 00:1a:79:51:56:54 (00:1a:79:51:56:54) Address: 00:1a:79:51:56:54 (00:1a:79:51:56:54) .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default) .... ...0 .... .... .... .... = IG bit: Individual address (unicast) Type: 802.1Q Virtual LAN (0x8100) 802.1Q Virtual LAN, PRI: 0, CFI: 0, ID: 207 000. .... .... .... = Priority: Best Effort (default) (0) ...0 .... .... .... = CFI: Canonical (0) .... 0000 1100 1111 = ID: 207 Type: IP (0x0800) Internet Protocol Version 4, Src: 0.0.0.0 (0.0.0.0), Dst: 255.255.255.255 (255.255.255.255) Version: 4 Header length: 20 bytes Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00: Not-ECT (Not ECN-Capable Transport)) 0000 00.. = Differentiated Services Codepoint: Default (0x00) .... ..00 = Explicit Congestion Notification: Not-ECT (Not ECN-Capable Transport) (0x00) Total Length: 330 Identification: 0x0000 (0) Flags: 0x00 0... .... = Reserved bit: Not set .0.. .... = Don't fragment: Not set ..0. .... = More fragments: Not set Fragment offset: 0 Time to live: 64 Protocol: UDP (17) Header checksum: 0x79a4 [correct] [Good: True] [Bad: False] Source: 0.0.0.0 (0.0.0.0) Destination: 255.255.255.255 (255.255.255.255) User Datagram Protocol, Src Port: 68 (68), Dst Port: 67 (67) Source port: 68 (68) Destination port: 67 (67) Length: 310 Checksum: 0x1357 [validation disabled] [Good Checksum: False] [Bad Checksum: False] Bootstrap Protocol Message type: Boot Request (1) Hardware type: Ethernet (0x01) Hardware address length: 6 Hops: 0 Transaction ID: 0x7b78aa25 Seconds elapsed: 16141 Bootp flags: 0x0000 (Unicast) 0... .... .... .... = Broadcast flag: Unicast .000 0000 0000 0000 = Reserved flags: 0x0000 Client IP address: 0.0.0.0 (0.0.0.0) Your (client) IP address: 0.0.0.0 (0.0.0.0) Next server IP address: 0.0.0.0 (0.0.0.0) Relay agent IP address: 0.0.0.0 (0.0.0.0) Client MAC address: 00:1a:79:51:56:54 (00:1a:79:51:56:54) Client hardware address padding: 00000000000000000000 Server host name not given Boot file name not given Magic cookie: DHCP Option: (53) DHCP Message Type Length: 1 DHCP: Discover (1) Option: (61) Client identifier Length: 7 Hardware type: Ethernet (0x01) Client MAC address: 00:1a:79:51:56:54 (00:1a:79:51:56:54) Option: (57) Maximum DHCP Message Size Length: 2 Maximum DHCP Message Size: 576 Option: (55) Parameter Request List Length: 8 Parameter Request List Item: (1) Subnet Mask Parameter Request List Item: (3) Router Parameter Request List Item: (6) Domain Name Server Parameter Request List Item: (12) Host Name Parameter Request List Item: (15) Domain Name Parameter Request List Item: (28) Broadcast Address Parameter Request List Item: (42) Network Time Protocol Servers Parameter Request List Item: (43) Vendor-Specific Information Option: (60) Vendor class identifier Length: 13 Vendor class identifier: InfomirMAG322 Option: (82) Agent Information Option Length: 18 Option 82 Suboption: (1) Agent Circuit ID Length: 6 Agent Circuit ID: 000400cf0101 Option 82 Suboption: (2) Agent Remote ID Length: 8 Agent Remote ID: 0006189c5d2dcc00 Option: (255) End Option End: 255 Изменено 17 октября, 2019 пользователем Azamat Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...