În prezent, mă lupt cu Juniper Switch Stack.
Topologia este așa Topologie
Porturile client de pe stivă sunt configurate ca acces etichetat cu dot1x (suplicant multiplu) și se comută în funcție de autentificarea Radius. Acest lucru funcționează fără probleme și VLAN-urile sunt alocate corect.
Cele 2 firewall-uri PFSense oferă o instanță DHCP pentru fiecare VLAN în configurație de failover cu un IP CARP pe aceeași subrețea ca și VLAN-ul. Deci nu este nevoie de DHCP Relay.
Clienții Windows pot obține un IP și pot funcționa corect, dar clienții Linux și boot PXE nu.
De la tcpdump și Wireshark vedem o buclă DHCP Discover/Offer pe clienții Linux. Oferta ajunge la client, dar acesta nu trimite o Solicitare DHCP. Am încercat mai multe derivate Linux și implementări PXE, dar fără succes. De asemenea, am comparat capturile Wireshark din Windows și Linux și nu există absolut nicio diferență.
Aveți sugestii despre cum să găsiți problema?
Mulțumesc anticipat.
Actualizați:
Doar pentru a adăuga mai multe informații.
Fluxul de atribuire a IP este astfel:
- Clientul pornește (NIC se conectează la stiva Switch)
- Switch autentifică clientul față de serverul Radius
- Radius Server răspunde cu Accept și VLAN ID 940
- Stiva de comutatoare atribuie VLAN 940 portului la care clientul îl conectează în modul de solicitant multiplu
- Clienții trimite DHCP Discover
- Serverul DHCP (ambele PFSense) răspund cu o ofertă.
- Clientul trimite o solicitare DHCP
- Serverul DHCP trimite un ACK DHCP
Deci, evident, 1-6 funcționează. Clientul este alocat la VLAN 940 prin Radius Server, trimite o descoperire DHCP, ambele PFSense au o instanță DHCP configurată pentru VLAN 940 (Interval IP 10.94.0.1-200/24) și trimit o ofertă.
Acesta este un tcpdump pe unul dintre firewall-urile PFsense în cazul în care ajută.
18:55:25.538580 IP (to 0x0, ttl 20, id 3, offset 0, steaguri [niciunul], proto UDP (17), lungime 576)
0.0.0.0.bootpc > 255.255.255.255.bootps: [udp sum ok] BOOTP/DHCP, Solicitare de la 00:19:99:f7:3d:23 (oui Necunoscut), lungime 548, xid 0x99f73d23, steaguri [19:99:f7:3d:23 Difuzare] (0x8000)
Client-Ethernet-Adresa 00:19:99:f7:3d:23 (oui Necunoscut)
Extensii Vendor-rfc1048
Cookie magic 0x63825363
DHCP-Message Opțiunea 53, lungime 1: Discover
Opțiunea de solicitare a parametrilor 55, lungime 36:
Subnet-Mask, Time-Zone, Default-Gateway, Time-Server
IEN-Name-Server, Domain-Name-Server, RL, Hostname
BS, nume de domeniu, SS, RP
EP, RSZ, TTL, BR
YD, YS, NTP, Opțiune de furnizor
Solicitat-IP, Lease-Time, Server-ID, RN
RB, Clasa furnizor, TFTP, BF
Opțiunea 128, Opțiunea 129, Opțiunea 130, Opțiunea 131
Opțiunea 132, Opțiunea 133, Opțiunea 134, Opțiunea 135
MSZ Opțiunea 57, lungime 2: 1260
Opțiunea GUID 97, lungime 17: 0.72.178.216.253.99.205.17.226.190.154.221.134.53.14.178.59
Opțiunea ARCH 93, lungime 2: 0
Opțiunea NDI 94, lungime 3: 1.2.1
Opțiunea 60 din clasa furnizorului, lungimea 32: „PXEClient:Arch:00000:UNDI:002001”
END Opțiunea 255, lungime 0
Opțiunea PAD 0, lungimea 0, apare 200
18:55:26.546900 IP (to 0x10, ttl 128, id 0, offset 0, flags [niciun], proto UDP (17), lungime 334)
10.94.0.253.bootps > 255.255.255.255.bootpc: [udp sum ok] BOOTP/DHCP, Răspuns, lungime 306, xid 0x99f73d23, secunde 18, Indicatori [Broadcast] (0x8000)
IP-ul dvs. 10.94.0.5
Server-IP 10.91.0.1
Client-Ethernet-Adresa 00:19:99:f7:3d:23 (oui Necunoscut)
fișierul „pxelinux.0”
Extensii Vendor-rfc1048
Cookie magic 0x63825363
DHCP-Message Opțiunea 53, lungime 1: Oferta
Server-ID Opțiunea 54, lungime 4: 10.94.0.253
Opțiunea de închiriere 51, lungime 4: 600
Subnet-Mask Opțiunea 1, lungime 4: 255.255.255.0
Opțiunea de gateway implicită 3, lungime 4: 10.94.0.254
Opțiunea Domain-Name-Server 6, lungime 8: 10.0.2.1,10.0.2.2
Opțiunea Domain-Name 15, lungimea 9: „domain.intra”
Opțiunea NTP 42, lungime 4: 10.94.0.254
Opțiunea TFTP 66, lungime 9: „10.91.0.1”
END Opțiunea 255, lungime 0
18:55:26.547180 IP (to 0x10, ttl 128, id 0, offset 0, flags [niciun], proto UDP (17), lungime 334)
10.94.0.252.bootps > 255.255.255.255.bootpc: [suma udp ok] BOOTP/DHCP, Răspuns, lungime 306, xid 0x99f73d23, secunde 18, Indicatori [Broadcast] (0x8000)
IP-ul dvs. 10.94.0.104
Server-IP 10.91.0.1
Client-Ethernet-Adresa 00:19:99:f7:3d:23 (oui Necunoscut)
fișierul „pxelinux.0”
Extensii Vendor-rfc1048
Cookie magic 0x63825363
DHCP-Message Opțiunea 53, lungime 1: Oferta
Server-ID Opțiunea 54, lungime 4: 10.94.0.252
Opțiunea de închiriere 51, lungime 4: 600
Subnet-Mask Opțiunea 1, lungime 4: 255.255.255.0
Opțiunea de gateway implicită 3, lungime 4: 10.94.0.254
Opțiunea Domain-Name-Server 6, lungime 8: 10.0.2.1,10.0.2.2
Opțiunea Domain-Name 15, lungimea 9: „domain.intra”
Opțiunea NTP 42, lungime 4: 10.94.0.254
Opțiunea TFTP 66, lungime 9: „10.91.0.1”
END Opțiunea 255, lungime 0
Clientul vede exact același lucru, dar pur și simplu îl ignoră.
Arată greșit?
Funcționează doar dacă fac același lucru cu o mașină virtuală Linux pe comutatoarele din partea serverului (unde este conectat serverul Radius). Deci sunt destul de sigur că problema este undeva în Juniper Switch Stack.
Actualizare 2:
Presupunerea mea despre o problemă în Switch Stack a fost corectă. Se pare că modul de port „acces-etichetat” nu se comportă așa cum ar trebui. Trecerea la modul port „acces” a rezolvat problema. Dar nu are prea mult sens pentru mine, deoarece modul „acces” nu ar trebui să poată gestiona mai mulți solicitanți în VLAN-uri diferite, dar, evident, are.
