Bear_UA

Вот как раз на материнках под i7-12k нужна видеокарта. Без неё даже фрибсд не стартует. Ни 12.3 ни 13.1. Странно очень надеюсь это как-то починят :( Поставили дешманскую видеокарту, включили CSM режим. Установочная флешка стартует.

Материнская плата с фантазиями. Для того чтоб включить CSM надо вставить и оставить в ней внешнюю видеокарту (не понимаю зачем). Пока в поисках либо 2U видеокарты либо другой материнской платы :(

Это первое что я сделал. Биос сохраняется но после рестарта secure boot снова включён. Никак не полечить UEFI? Самое обидное что пингвин установился с полпинка и работает :(

Принёс клиент машину для установки FreeBSD 12.3. Процессор INTEL Core i7 12700 (BX8071512700) Материнская плата ASRock (B660 Steel Legend) Система установилась но начала крешиться рандомно при дисковых операциях. Думали винт, поменяли - тоже самое. Посоветовали обновить биос. Обновил - после обновления ни с флешки ни с уже установленной системы на обоих винтах не загружается - выдаёт проблему с UEFI. Перекачал перезалил флешку - тоже самое. При этом скачал установил Deb11 - все без проблем и никаких крешей под дисковым операциям. Может кто сталкивался и знает как «полечить» глюк с UEFI в FreeBSD 12.3? Ошибка которая вылазит приложил.

Проблема никак не решилась. Сделали по влану на каждый олт. Вроде все стало нормально работать. Жаль что не нашлось решение :(

Ип пакет ОТ абонентов уходит в сторону шлюза, причём тут отключение arp inspection?

Ставил, пинговал, не пингуется (мак также не появляется). Не могу понять почему :((( Ведь связанность до клиента есть. Клиент достукивается до дхцп сервера и получает ип.

Вы все правильно говорите. Но вопрос в том - почему это происходит? И самое интересное что клиентов в этом влане который затянут на пачку олтов не так много - человек 200. Сомнительно чтоб где-то срабатывал шторм контроль или броадкаст контроль. И на эту машину затянут всего один dhcp влан с широкой ип маской и все.

Доступ - олты бдком. Перекидываем клиентов которые жалуются в другой влан - все начинает работать (но надолго ли). На столе не получается сделать стенд - все нормально работает, ип получает, инет бежит :( Клиенты включены по пон. На ону - один мак от клиента и он правильный. Включён dhcp snooping и arp inspection. На олтах все нормально, пакеты от абонов долетают до сервера но вот арп запрос-ответ не от всех :( Может какие-то есть крутилки sysctl на FreeBSD (типа количество маков на влан или ещё что-то). Голова уже третий день квадратная от этого :(

Третий день мучаюсь не могу разобраться. Раздается инет методом dhcp option 82 Клиент получает ИП, шлюз, днс от dhcpd но при этом на сервере почему-то его arp выглядит как incomplete. ( Более глубокий анализ показал следующее. Роутер клиента получает ип, видит мак шлюза, пытается слать какие-то пакеты на шлюз. Пакеты от клиента приходят на сервер 22:20:04.146455 5c:a6:e6:2a:55:a4 > 00:1b:21:ba:b7:15, ethertype IPv4 (0x0800), length 71: 10.13.1.49.34647 > 1.1.1.1.53: 21+ A? tp-link.com. (29) 22:20:04.146464 5c:a6:e6:2a:55:a4 > 00:1b:21:ba:b7:15, ethertype IPv4 (0x0800), length 68: 10.13.1.49.34647 > 1.1.1.1.53: 22+ A? bing.com. (26) 22:20:04.146501 5c:a6:e6:2a:55:a4 > 00:1b:21:ba:b7:15, ethertype IPv4 (0x0800), length 78: 10.13.1.49.37418 > 8.8.8.8.53: 6096+ A? a.root-servers.net. (36) 22:20:04.146507 5c:a6:e6:2a:55:a4 > 00:1b:21:ba:b7:15, ethertype IPv4 (0x0800), length 71: 10.13.1.49.34647 > 8.8.8.8.53: 19+ A? tp-link.com. (29) 22:20:04.146511 5c:a6:e6:2a:55:a4 > 00:1b:21:ba:b7:15, ethertype IPv4 (0x0800), length 68: 10.13.1.49.34647 > 8.8.8.8.53: 20+ A? bing.com. (26) и при этом сервер пытается определить мак клиента отправляя arp запрос 22:19:54.170633 00:1b:21:ba:b7:15 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 10.13.1.49 tell 10.13.0.1, length 28 22:19:55.170640 00:1b:21:ba:b7:15 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 10.13.1.49 tell 10.13.0.1, length 28 22:19:56.171657 00:1b:21:ba:b7:15 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 10.13.1.49 tell 10.13.0.1, length 28 22:19:58.170317 00:1b:21:ba:b7:15 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 10.13.1.49 tell 10.13.0.1, length 28 И не получает от клиентского роутера ответ. Причем проблема с некоторыми клиентами (не со всеми). Также непонятно зачем шлется arp запрос если на сервер приходит ipv4 пакет уже с мак адресом клиента? Если я прибиваю arp -S мак клиента - у клиента все начинает счастливо работать. Через какое-то время если таки клиентское железо отвечает на запрос и мак добавляется в таблицу на серваке - все также счастливо работает пока не пройдет таймаут и мак не удалится. Если мак появляется и его удалить принудительно - то заново он не добавляется и снова висит в incomplete. Если перекидываем клиентов которые жалуются в другой влан (на этом же сервере) - у них все начинает работать. В общем мучаюсь третий день не могу разобраться. Возможно кто-то сталкивался с данной проблемой и может помочь решить.

Там схема - [OLT BDCom] --- [OLT Gcom] --- [DHCPD] так вот на гейкоме на порту в сторону бдкома вписано dhcp option82 strategy keep - по документации он не должен трогать пакеты с option82 но оказывается что некоторые таки трогал. Пришлось на порту вбить no dhcp option82 - тогда лыжи поехали.

Проблема была в транзитном коммутаторе который почему-то при запросе Request с существующего ИП - затирал свои мак адресом поля agent.id и circuit.id. Всем спасибо за помощь!

Вот что происходит по tcpdump. Помогите разобраться 14:12:43.550273 dc:2c:6e:05:b0:64 > 00:1b:21:d6:bb:75, ethertype IPv4 (0x0800), length 360: (tos 0x0, ttl 16, id 0, offset 0, flags [none], proto UDP (17), length 346) 10.169.12.107.68 > 10.169.15.254.67: [no cksum] BOOTP/DHCP, Request from dc:2c:6e:05:b0:64, length 318, xid 0x188e30b2, Flags [none] (0x0000) Client-IP 10.169.12.107 Client-Ethernet-Address dc:2c:6e:05:b0:64 Vendor-rfc1048 Extensions Magic Cookie 0x63825363 DHCP-Message Option 53, length 1: Request Parameter-Request Option 55, length 8: Subnet-Mask, Classless-Static-Route, Default-Gateway, Static-Route Domain-Name-Server, NTP, Option 138, Vendor-Option Hostname Option 12, length 8: "MikroTik" Client-ID Option 61, length 7: ether dc:2c:6e:05:b0:64 Agent-Information Option 82, length 16: Circuit-ID SubOption 1, length 6: ^@^JZM-!^GM-R Remote-ID SubOption 2, length 6: ^@^JZM-!^GM-R 14:12:43.550898 00:1b:21:d6:bb:75 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 343: (tos 0x10, ttl 128, id 0, offset 0, flags [none], proto UDP (17), length 329) 10.169.15.254.67 > 255.255.255.255.68: [udp sum ok] BOOTP/DHCP, Reply, length 301, xid 0x188e30b2, Flags [Broadcast] (0x8000) Server-IP 10.169.15.254 Client-Ethernet-Address dc:2c:6e:05:b0:64 Vendor-rfc1048 Extensions Magic Cookie 0x63825363 DHCP-Message Option 53, length 1: NACK Server-ID Option 54, length 4: 10.169.15.254 MSG Option 56, length 31: "requested address not available" Agent-Information Option 82, length 16: Circuit-ID SubOption 1, length 6: ^@^JZM-!^GM-R Remote-ID SubOption 2, length 6: ^@^JZM-!^GM-R 14:12:43.804918 dc:2c:6e:05:b0:64 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 388: (tos 0x0, ttl 16, id 0, offset 0, flags [none], proto UDP (17), length 370) 0.0.0.0.68 > 255.255.255.255.67: [no cksum] BOOTP/DHCP, Request from dc:2c:6e:05:b0:64, length 342, xid 0x28f063f0, Flags [Broadcast] (0x8000) Client-Ethernet-Address dc:2c:6e:05:b0:64 Vendor-rfc1048 Extensions Magic Cookie 0x63825363 DHCP-Message Option 53, length 1: Discover Parameter-Request Option 55, length 8: Subnet-Mask, Classless-Static-Route, Default-Gateway, Static-Route Domain-Name-Server, NTP, Option 138, Vendor-Option Hostname Option 12, length 8: "MikroTik" Client-ID Option 61, length 7: ether dc:2c:6e:05:b0:64 Agent-Information Option 82, length 40: Circuit-ID SubOption 1, length 5: ^C^M^@^H< Remote-ID SubOption 2, length 6: M-@~@F^GM-F Unknown SubOption 9, length 23: 0x0000: 0000 0cf8 1201 0002 0853 6e79 6163 6869 0x0010: 7603 04ac 1001 38 14:12:43.805560 00:1b:21:d6:bb:75 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 362: (tos 0x10, ttl 128, id 0, offset 0, flags [none], proto UDP (17), length 348) 10.169.15.254.67 > 255.255.255.255.68: [udp sum ok] BOOTP/DHCP, Reply, length 320, xid 0x28f063f0, Flags [Broadcast] (0x8000) Your-IP 10.169.12.107 Client-Ethernet-Address dc:2c:6e:05:b0:64 Vendor-rfc1048 Extensions Magic Cookie 0x63825363 DHCP-Message Option 53, length 1: Offer Server-ID Option 54, length 4: 10.169.15.254 Lease-Time Option 51, length 4: 43200 Subnet-Mask Option 1, length 4: 255.255.252.0 Default-Gateway Option 3, length 4: 10.169.15.254 Domain-Name-Server Option 6, length 8: 8.8.8.8,1.1.1.1 Agent-Information Option 82, length 40: Circuit-ID SubOption 1, length 5: ^C^M^@^H< Remote-ID SubOption 2, length 6: M-@~@F^GM-F Unknown SubOption 9, length 23: 0x0000: 0000 0cf8 1201 0002 0853 6e79 6163 6869 0x0010: 7603 04ac 1001 38 14:12:43.837109 dc:2c:6e:05:b0:64 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 388: (tos 0x0, ttl 16, id 0, offset 0, flags [none], proto UDP (17), length 370) 0.0.0.0.68 > 255.255.255.255.67: [no cksum] BOOTP/DHCP, Request from dc:2c:6e:05:b0:64, length 342, xid 0x28f063f0, Flags [Broadcast] (0x8000) Client-Ethernet-Address dc:2c:6e:05:b0:64 Vendor-rfc1048 Extensions Magic Cookie 0x63825363 DHCP-Message Option 53, length 1: Request Server-ID Option 54, length 4: 10.169.15.254 Requested-IP Option 50, length 4: 10.169.12.107 Parameter-Request Option 55, length 8: Subnet-Mask, Classless-Static-Route, Default-Gateway, Static-Route Domain-Name-Server, NTP, Option 138, Vendor-Option Hostname Option 12, length 8: "MikroTik" Client-ID Option 61, length 7: ether dc:2c:6e:05:b0:64 Agent-Information Option 82, length 40: Circuit-ID SubOption 1, length 5: ^C^M^@^H< Remote-ID SubOption 2, length 6: M-@~@F^GM-F Unknown SubOption 9, length 23: 0x0000: 0000 0cf8 1201 0002 0853 6e79 6163 6869 0x0010: 7603 04ac 1001 38 14:12:43.837712 00:1b:21:d6:bb:75 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 362: (tos 0x10, ttl 128, id 0, offset 0, flags [none], proto UDP (17), length 348) 10.169.15.254.67 > 255.255.255.255.68: [udp sum ok] BOOTP/DHCP, Reply, length 320, xid 0x28f063f0, Flags [Broadcast] (0x8000) Your-IP 10.169.12.107 Client-Ethernet-Address dc:2c:6e:05:b0:64 Vendor-rfc1048 Extensions Magic Cookie 0x63825363 DHCP-Message Option 53, length 1: ACK Server-ID Option 54, length 4: 10.169.15.254 Lease-Time Option 51, length 4: 120 Subnet-Mask Option 1, length 4: 255.255.252.0 Default-Gateway Option 3, length 4: 10.169.15.254 Domain-Name-Server Option 6, length 8: 8.8.8.8,1.1.1.1 Agent-Information Option 82, length 40: Circuit-ID SubOption 1, length 5: ^C^M^@^H< Remote-ID SubOption 2, length 6: M-@~@F^GM-F Unknown SubOption 9, length 23: 0x0000: 0000 0cf8 1201 0002 0853 6e79 6163 6869 0x0010: 7603 04ac 1001 38 Почему dhcpd в Offer предлагает время лизы 43200 а в ACK - 120? Что за непонятный глюк? :(

Ок, нашел еще одного клиента только что. Микротик. Лиза не expired. lease 10.169.12.107 { starts 3 2022/03/16 10:51:58; ends 3 2022/03/16 22:51:58; cltt 3 2022/03/16 10:51:58; binding state active; next binding state free; rewind binding state free; hardware ethernet dc:2c:6e:05:b0:64; uid "\001\334,n\005\260d"; option agent.circuit-id 3:d:0:8:3c; option agent.remote-id c0:7e:40:46:7:c6; option agent.unknown-9 0:0:c:f8:12:1:0:2:8:53:6e:79:61:63:68:69:76:3:4:ac:10:1:38; client-hostname "MikroTik"; } Выдается клиенту все равно лиза в 120 секунд :(

Захардкодено 120 секунд в моей версии dhcpd? Потому как лизу с 120 секунд отдает же мой dhcpd клиенту.

Судя по мак адресу у клиента роутер тп-линк. Может он так как-то работает. Захардкодено в dhcpd моем что при discover выдавать двухминутный таймер? снес. а hardware ethernet - это ж мак адрес клиентского оборудования - а у нас идет по remote.id в option82 пакете

Почему-то по некоторым клиентам дважды записи в dhcpd.leases. вот пример lease 10.169.12.82 { starts 2 2022/03/15 18:24:35; ends 2 2022/03/15 18:36:10; tstp 2 2022/03/15 18:36:10; cltt 2 2022/03/15 18:24:36; binding state free; hardware ethernet e8:94:f6:bb:ee:99; uid "\001\350\224\366\273\356\231"; set vendor-class-identifier = "MSFT 5.0"; } lease 10.169.12.82 { starts 2 2022/03/15 19:35:58; ends 3 2022/03/16 07:35:58; cltt 2 2022/03/15 19:35:58; binding state active; next binding state free; rewind binding state free; hardware ethernet e8:94:f6:bb:ee:99; uid "\001\350\224\366\273\356\231"; option agent.circuit-id 3:d:0:9:1e; option agent.remote-id 4:8d:38:70:94:b8; option agent.unknown-9 0:0:c:f8:12:1:0:2:8:53:6e:79:61:63:68:69:76:3:4:ac:10:1:38; client-hostname "TL-WR841N"; } Причем это клиент которому выдавалась лиза по 120 секунд, после рестарта dhcp сервера - выдалась лиза на 12 часов и появилась вторая запись в dhcpd.leases Ничего не могу понять :( До рестарта dhcpd вот какая запись была по этому клиенту которому выдавалась лиза в 120 секунд lease 10.169.12.82 { starts 2 2022/03/15 18:24:35; ends 2 2022/03/15 18:36:10; cltt 2 2022/03/15 18:24:36; binding state active; next binding state free; rewind binding state free; hardware ethernet e8:94:f6:bb:ee:99; uid "\001\350\224\366\273\356\231"; set vendor-class-identifier = "MSFT 5.0"; option agent.circuit-id 3:d:0:9:1e; option agent.remote-id 4:8d:38:70:94:b8; option agent.unknown-9 0:0:c:f8:12:1:0:2:8:53:6e:79:61:63:68:69:76:3:4:ac:10:1:38; } Причем время starts и ends далеко уже просроченное от фактического времени на сервере.

option domain-name "mydomain"; option domain-name-servers 8.8.8.8, 1.1.1.1; default-lease-time 43200; max-lease-time 86400; min-lease-time 28800; authoritative; ddns-update-style none; one-lease-per-client true; log-facility local7; subnet 10.169.16.0 netmask 255.255.252.0 { option routers 10.169.19.254; option domain-name-servers 8.8.8.8, 1.1.1.1; pool { range 10.169.16.1;allow members of "46-0";} ...... } class "46-0" { match if suffix(option agent.remote-id,6)=c0:7e:40:a7:2a:32;} .... там где многоточия просто перечисленны классы и ип остальных клиентов. вот все :) уже не могу посмотреть, ребутнул дхцп сервер, стало все ок. Пока поставил "костыль" с ребутом раз в сутки. Но хочется таки разобраться почему это происходит :(((

Выстаили min-lease-time 28800; Все равно через некоторое время dhcp сервер начинает выдавать лизу в 120 секунд. Подскажите как исправить :((( Вот что показывает tcpdump 10:07:14.714746 bc:62:ce:55:07:93 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 641: (tos 0x0, ttl 64, id 45677, offset 0, flags [none], proto UDP (17), length 623) 0.0.0.0.68 > 255.255.255.255.67: [no cksum] BOOTP/DHCP, Request from bc:62:ce:55:07:93, length 595, xid 0x2d4d475e, Flags [none] (0x0000) Client-Ethernet-Address bc:62:ce:55:07:93 Vendor-rfc1048 Extensions Magic Cookie 0x63825363 DHCP-Message Option 53, length 1: Request Client-ID Option 61, length 7: ether bc:62:ce:55:07:93 Vendor-Class Option 60, length 8: "MSFT 5.0" Requested-IP Option 50, length 4: 10.169.16.101 Server-ID Option 54, length 4: 10.169.19.254 Parameter-Request Option 55, length 12: Subnet-Mask, Default-Gateway, Domain-Name-Server, Domain-Name BR, Static-Route, YD, YS NTP, Netbios-Name-Server, Classless-Static-Route-Microsoft, Classless-Static-Route Agent-Information Option 82, length 41: Circuit-ID SubOption 1, length 5: ^C^N^@^H^S Remote-ID SubOption 2, length 6: M-`M-hM-fM-9M-^HM-} Unknown SubOption 9, length 24: 0x0000: 0000 0cf8 1301 0002 0947 6c69 626f 6368 0x0010: 6f6b 0304 ac10 0139 10:07:14.715397 00:1b:21:d6:bb:75 > bc:62:ce:55:07:93, ethertype IPv4 (0x0800), length 376: (tos 0x10, ttl 128, id 0, offset 0, flags [none], proto UDP (17), length 362) 10.169.19.254.67 > 10.169.16.101.68: [udp sum ok] BOOTP/DHCP, Reply, length 334, xid 0x2d4d475e, Flags [none] (0x0000) Your-IP 10.169.16.101 Client-Ethernet-Address bc:62:ce:55:07:93 Vendor-rfc1048 Extensions Magic Cookie 0x63825363 DHCP-Message Option 53, length 1: ACK Server-ID Option 54, length 4: 10.169.19.254 Lease-Time Option 51, length 4: 120 Subnet-Mask Option 1, length 4: 255.255.252.0 Default-Gateway Option 3, length 4: 10.169.19.254 Domain-Name-Server Option 6, length 8: 8.8.8.8,1.1.1.1 Domain-Name Option 15, length 11: "mydomain" Agent-Information Option 82, length 41: Circuit-ID SubOption 1, length 5: ^C^N^@^H^S Remote-ID SubOption 2, length 6: M-`M-hM-fM-9M-^HM-} Unknown SubOption 9, length 24: 0x0000: 0000 0cf8 1301 0002 0947 6c69 626f 6368 0x0010: 6f6b 0304 ac10 0139 Как мы видим в ответе Lease-Time - 120 секунд :((( После рестарта dhcpd Lease-Time Option 51, length 4: 43200

Клиент получает нужный ип который ему назначен - насколько я помню когда делал tcpdump во время глюка - то таки сервер отвечал с 120 секунд лизой. После рестарта дхцп сервера - стало все ок. Непонятно почему такое. У нас строго привязан ип к мак адресу ОНУ клиента. Неизвестным клиентам просто не выдаются ип. Internet Systems Consortium DHCP Server 4.3.1

Один дхцп сервер. Нет возможности проверить. Клиенты подключить по пон, в таблице dhcp snooping на олте видно лизтайм. Когда наступает глюк - все новые лизы - 120 секунд, перегружаем дхцп сервер - 43200 секунд.

Здравствуйте Используем isc-dhcpd для выдачи клиентам ип. В последнее время заметили странный глюк. В конфиге у нас прописано default-lease-time 43200; max-lease-time 86400; проходит какое-то время (2-3 дня приблизительно) и dhcpd начинает выдавать ип с временем жизни в 120 секунд. После перезагрузки dhcpd - дальше выдает нормальное время жизни. Может кто сталкивался и знает как побороть данный глюк? Пока сделали костыльное решение с рестартом dhcpd по крону - но это как-то не по-православному :(

Спасибо :) Мы раскинули линки по разным каналам - ситуация сразу вылечилась.

Огромное спасибо за помощь :)

#show asic slot 2 Module in slot 2 has 6 type(s) of ASICs ASIC Name Count Version KUMA 2 (3.0) METRO_ARGOS 2 (3.0) METRO_KRYPTON 2 (3.0) SSA 2 (9.0) R2D2 8 (2.0) TIANGANG 4 (54.0) Роутим в другие платы... Роутить внутри платы не особо получится.