В настоящее время я борюсь со своим стеком коммутаторов Juniper.
Топология такая Топология
Клиентские порты в стеке настроены как тегированный доступ с dot1x (множественный запрашивающий) и переключаются в соответствии с аутентификацией Radius. Это работает без проблем, и VLAN назначаются правильно.
Два брандмауэра PFSense предоставляют один экземпляр DHCP для каждой VLAN в конфигурации аварийного переключения с IP-адресом CARP в той же подсети, что и VLAN. Таким образом, DHCP-ретранслятор не требуется.
Клиенты Windows могут получить IP-адрес и работать правильно, а клиенты Linux и загрузка PXE — нет.
Из tcpdump и Wireshark мы видим цикл DHCP Discover/Offer на клиентах Linux. Предложение достигает клиента, но клиент не отправляет DHCP-запрос. Мы пробовали несколько производных Linux и реализаций PXE, но безуспешно. Мы также сравнили захваты Wireshark из Windows и Linux, и абсолютно никакой разницы.
Любые предложения о том, как отследить проблему?
Заранее спасибо.
Обновлять:
Просто чтобы добавить больше информации.
Процесс назначения IP выглядит следующим образом:
- Клиент запускается (сетевой адаптер подключается к стеку коммутатора)
- Коммутатор аутентифицирует Клиента на Radius-сервере.
- Radius Server отвечает Accept и VLAN ID 940
- Стек коммутатора назначает VLAN 940 порту, к которому подключается клиент в режиме множественных запросов.
- Клиенты отправляют DHCP Discover
- DHCP-сервер (оба PFSense) отвечают предложением.
- Клиент отправляет запрос DHCP
- DHCP-сервер отправляет DHCP ACK
Итак, очевидно, 1-6 работает. Клиент назначается VLAN 940 через Radius Server, отправляет DHCP-обнаружение, оба PFSense имеют экземпляр DHCP, настроенный для VLAN 940 (диапазон IP-адресов 10.94.0.1-200/24), и они отправляют предложение.
Это tcpdump на одном из брандмауэров PFsense на случай, если это поможет.
18:55:25.538580 IP (tos 0x0, ttl 20, id 3, смещение 0, флаги [нет], proto UDP (17), длина 576)
0.0.0.0.bootpc > 255.255.255.255.bootps: [udp sum ok] BOOTP/DHCP, запрос от 00:19:99:f7:3d:23 (oui Unknown), длина 548, xid 0x99f73d23, 18 секунд, флаги [ Трансляция] (0x8000)
Клиент-Ethernet-адрес 00:19:99:f7:3d:23 (oui неизвестно)
Расширения Vendor-rfc1048
Волшебное печенье 0x63825363
DHCP-сообщение, опция 53, длина 1: обнаружение
Опция запроса параметров 55, длина 36:
Маска подсети, часовой пояс, шлюз по умолчанию, сервер времени
IEN-Name-Server, Domain-Name-Server, RL, Hostname
BS, доменное имя, SS, RP
ЭП, РСЗ, ТТЛ, БР
YD, YS, NTP, опция поставщика
Запрошенный IP, время аренды, идентификатор сервера, RN
RB, Vendor-Class, TFTP, BF
Опция 128, Опция 129, Опция 130, Опция 131
Опция 132, Опция 133, Опция 134, Опция 135
МСЗ Вариант 57, длина 2: 1260
GUID Option 97, длина 17: 0.72.178.216.253.99.205.17.226.190.154.221.134.53.14.178.59
АРКА Вариант 93, длина 2:0
Опция NDI 94, длина 3: 1.2.1
Vendor-Class Option 60, длина 32: «PXEClient: Arch: 00000: UNDI: 002001»
КОНЕЦ Опция 255, длина 0
PAD Option 0, длина 0, встречается 200
18:55:26.546900 IP (tos 0x10, ttl 128, id 0, смещение 0, флаги [нет], proto UDP (17), длина 334)
10.94.0.253.bootps > 255.255.255.255.bootpc: [udp sum ok] BOOTP/DHCP, ответ, длина 306, xid 0x99f73d23, 18 секунд, флаги [трансляция] (0x8000)
Ваш-IP 10.94.0.5
IP-адрес сервера 10.91.0.1
Клиент-Ethernet-адрес 00:19:99:f7:3d:23 (oui неизвестно)
файл "pxelinux.0"
Расширения Vendor-rfc1048
Волшебное печенье 0x63825363
DHCP-сообщение, опция 53, длина 1: предложение
Параметр идентификатора сервера 54, длина 4: 10.94.0.253
Опция аренды 51, длина 4: 600
Маска подсети Вариант 1, длина 4: 255.255.255.0
Вариант шлюза по умолчанию 3, длина 4: 10.94.0.254
Вариант 6 сервера доменных имен, длина 8: 10.0.2.1,10.0.2.2
Вариант доменного имени 15, длина 9: «domain.intra»
Опция NTP 42, длина 4: 10.94.0.254
Опция TFTP 66, длина 9: «10.91.0.1»
КОНЕЦ Опция 255, длина 0
18:55:26.547180 IP (tos 0x10, ttl 128, id 0, смещение 0, флаги [нет], proto UDP (17), длина 334)
10.94.0.252.bootps > 255.255.255.255.bootpc: [udp sum ok] BOOTP/DHCP, ответ, длина 306, xid 0x99f73d23, 18 секунд, флаги [трансляция] (0x8000)
Ваш-IP 10.94.0.104
IP-адрес сервера 10.91.0.1
Клиент-Ethernet-адрес 00:19:99:f7:3d:23 (oui неизвестно)
файл "pxelinux.0"
Расширения Vendor-rfc1048
Волшебное печенье 0x63825363
DHCP-сообщение, опция 53, длина 1: предложение
Параметр идентификатора сервера 54, длина 4: 10.94.0.252
Опция аренды 51, длина 4: 600
Маска подсети Вариант 1, длина 4: 255.255.255.0
Вариант шлюза по умолчанию 3, длина 4: 10.94.0.254
Вариант 6 сервера доменных имен, длина 8: 10.0.2.1,10.0.2.2
Вариант доменного имени 15, длина 9: «domain.intra»
Опция NTP 42, длина 4: 10.94.0.254
Опция TFTP 66, длина 9: «10.91.0.1»
КОНЕЦ Опция 255, длина 0
Клиент видит то же самое, но просто игнорирует это.
Это выглядит неправильно?
Это просто работает, если я делаю то же самое с виртуальной машиной Linux на коммутаторах на стороне сервера (где подключен сервер Radius). Поэтому я почти уверен, что проблема где-то в стеке коммутаторов Juniper.
Обновление 2:
Мое предположение о проблеме в стеке коммутаторов было верным. Кажется, что режим порта с тегированным доступом ведет себя не так, как должен. Переключение в режим порта «доступ» решило проблему. Но для меня это не имеет особого смысла, так как режим «доступа» не должен иметь возможность обрабатывать несколько запросов в разных VLAN, но, очевидно, он это делает.
