Probleem met PXE boot met Juniper SRX

[FatalError]

Ik heb een probleem met de Juniper SRX thuis waar ik maar niet uit kom.
Ik wil PXE boot kunnen doen. Eigenlijk totaal niet spannend. Daarvoor heb ik de opties voor de boot server en filename in DHCP geconfigureerd mijn Juniper SRX router:

code:

[edit access address-assignment pool Lokaal family inet dhcp-attributes]
onno@router# show
maximum-lease-time 14400;
next-server 10.0.2.250;
name-server {
    10.0.2.1;
    208.67.220.220;
    208.67.220.222;
}
router {
    10.0.2.1;
}
boot-file pxelinux.0;
boot-server 10.0.2.250;

10.0.2.250 is een linuxdoosje welke tftp doet. Dat werkt allemaal prima, want ik kan prima een bestand ophalen via TFTP.

Als ik echter een willekeurige PXE client wil laten booten zie ik dat hij niet met 10.0.2.250 maar met 10.0.2.1 (de router) verbinding wil maken om zijn bootfile op te halen. Hier gaat het booten dus stuk.

Als ik een capture maak zie ik dat DHCP optie 66 het juiste IP adres van de server weergeeft, Next server IP address is echter leeg (0.0.0.0).
Aangezien optie 66 goed gegeven wordt zou het toch moeten werken?
Wat ik in mijn router ook opgeef als nex-server adres, de capture laat 0.0.0.0 zien.

code:

Bootp flags: 0x8000 (Broadcast)
Client IP address: 0.0.0.0 (0.0.0.0)
Your (client) IP address: 10.0.2.120 (10.0.2.120)
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: WistronI_36:80:08 (20:6a:8a:36:80:08)
Client hardware address padding: 00000000000000000000
Server host name: 10.0.2.250
Boot file name: pxelinux.0
Magic cookie: DHCP
<knip>
Option: (66) TFTP Server Name
TFTP Server Name: 10.0.2.250
Option: (67) Bootfile name
Bootfile name: pxelinux.0

Snap ik iets niet van het PXE bootproces? Is dit een bug in de Juniper (die er dan al heel lang in zit)?

[CyBeR]

gebruik 'next-server'.

Heb je erin staan zie ik nu (keek alleen onder aan). Ik heb 't zo en dat werkt:

# show system services dhcp   
name-server {
    8.8.8.8;
    8.8.4.4;
}
pool 192.168.2.0/24 {
    address-range low 192.168.2.10 high 192.168.2.200;
    default-lease-time 86400;
    domain-name cyberhq.nl;
    router {
        192.168.2.1;
    }
    boot-file pxelinux.0;
    next-server 62.21.178.35;
}

Wat ben je aan het PXE-booten? Sommige devices willen ook nog dat je magic values zet voor ze iets doen.

[ Voor 101% gewijzigd door CyBeR op 13-07-2014 19:00 ]

[FatalError]

Zo te zien gebruik jij dhcp 'oude stijl', onder system services. Ik moet dhcp 'nieuwe stijl' (onder access address-assignment) gebruiken vanwege dhcpv6.
Ik wil een normale PC/laptop kunnen PXE-booten. Ik heb diverse machines waarbij het niet werkt.

[CyBeR]

Klopt. Ik zal zo 's kijken wat er gebeurt als ik dat even omkat.

[FatalError]

Ik ben wel nieuwsgierig of je tegen hetzelfde probleem aanloopt.
Ik kan me bijna niet voorstellen dat het een bug in Junos is. Juniper geeft overal op hun site aan dat je maar beter de nieuwe dhcp service kan gebruiken o.a. vanwege de extra features van de nieuwe versie.

[CyBeR]

Ik krijg die nieuwe dhcp überhaupt nog niet aan de gang. Volgens de statistics en 'monitor interface traffic' krijgt 'ie wel requests en stuurt 'ie antwoorden, maar op m'n clients komen die antwoorden niet aan…

Even kijken wat er gebeurt met een lege config; heb ook nog een srx100 liggen die ik niet meer gebruik verder.

[ Voor 20% gewijzigd door CyBeR op 13-07-2014 23:07 ]

[Thralas]

edit:
Hmm, je specificeert wel degelijk next-server. Misschien dat onderstaande quotes dan alsnog verklaren waarom het niet werkt, al weet je dan nog niet wat je fout doet in junos

quote: http://www.ietf.org/rfc/rfc2131.txt

DHCP clarifies the interpretation of the 'siaddr' field as the address of the server to use in the next step of the client's bootstrap process. A DHCP server may return its own address in the 'siaddr' field, if the server is repared to supply the next bootstrap service (e.g., delivery of an operating system executable image).

Dus in beginsel is siaddr (aka next-server) het juiste veld. Maar hoe zit het dan met option 66?

quote: http://www.ietf.org/rfc/rfc2132.txt

9.4 TFTP server name

This option is used to identify a TFTP server when the 'sname' field
in the DHCP header has been used for DHCP options.

The code for this option is 66, and its minimum length is 1.

9.3. Option Overload

This option is used to indicate that the DHCP 'sname' or 'file'
fields are being overloaded by using them to carry DHCP options. A
DHCP server inserts this option if the returned parameters will
exceed the usual space allotted for options.

If this option is present, the client interprets the specified
additional fields after it concludes interpretation of the standard
option fields.

The code for this option is 52, and its length is 1. Legal values
for this option are:

Value Meaning
----- --------
1 the 'file' field is used to hold options
2 the 'sname' field is used to hold options
3 both fields are used to hold options

Dus:
- Is er een option 52?
- In je dump zie ik een 'server host name'. Als dat 'sname' betreft dan zou de overloaded moeten zijn om option 66 enig effect te laten hebben

Een pcapje is misschien handig?

[ Voor 16% gewijzigd door Thralas op 14-07-2014 01:16 ]

[CyBeR]

Ik heb 't even getest met de huidige recommended versie van JunOS voor SRX (12.1X44-D35.5) vers geinstalleerd met een default config en daar krijg ik 't ook niet voor elkaar.

Option 66 is inderdaad weinig boeiend; die komt (met 'boot-server') inderdaad netjes in het packet terecht maar wordt iig door de client waar ik mee test (iPXE in VirtualBox) niet gebruikt.

De next-server optie komt op geen enkele manier in een reply terecht, dus dat lijkt inderdaad een bug te zijn in de nieuwe DHCP server van JunOS. Ik zie ook geen enkele manier om dat alsnog te doen; als je de 'server-identifier' optie zet, komt dat als optie 54 tevoorschijn.

In de oude (system services dhcp) doet 'ie het prima.

Wat bij mij wel werkt maar nogal afhankelijk is van de pxe client, is een URL als boot-file zetten. Dus bijvoorbeeld 'boot-file tftp://12.34.56.78/pxelinux.0'.

[FatalError]

Ben je die niet vergeten? ..of begrijp ik goed dat dhcp nieuwe stijl al werkt?

code:

[edit system services dhcp-local-server]
onno@router# show 
group Lokaal {
    interface vlan.0;
}

Ik ben aan het werk.. morgen ga ik met jullie tips aan de slag.
Ik draai hier:
Model: srx210he2
JUNOS Software Release [12.1X46-D20.5]

[ Voor 39% gewijzigd door FatalError op 14-07-2014 03:57 ]

[CyBeR]

FatalError schreef op maandag 14 juli 2014 @ 03:42:
Ben je die niet vergeten ?;-)

code:

[edit system services dhcp-local-server]
onno@router# show 
group Lokaal {
    interface vlan.0;
}

Duh

Ik weet niet wat 't tegenhoudt op m'n srx210 maar ik heb 't idee dat de oude dhcp server ook gewoon beter functioneert. Als ik m'n laptop in die srx100 met jdhcp stop duurt 't ten eerste bijnameer dan een minuut ofzo voor 'ie een IP krijgt, en dat is dan nog elke keer dat ik 't probeer een nieuwe ook.

[FatalError]

Ik heb geprobeerd de url als bootfile te geven, maar mn client snapt het niet lijkt het.
En wat ik ook als option 52 geef, hij doet er niks mee.
Ik zal het probleem ook maar op het Juniper forum neerleggen.

Bij mij is de DHCP niet traag, ik heb binnen enkele secondes een adres.
Ik wil per se deze DHCP server gebruiken, want anders moet ik DHCPv6-Prefix Delegation missen.

[ Voor 29% gewijzigd door FatalError op 14-07-2014 14:43 ]

[Thralas]

Hoewel 't volgens mij al redelijk duidelijk was, ter referentie, mijn Mikrotik stuurt ook enkel 'standaard' DHCP-opties (boot-file, next-server) met de meest straightforward PXE-config, geen option 66 oid.

Vervelend dat het in jou geval niet werkt. Kun je als workaround niet je router een iPXE binary laten serveren, welke enkel dient om te chainloaden vanaf je 'werkelijke' PXE-server?

[Zjemm]

ik zag jouw topic toevallig omdat ik zelf ook een srx100 wil gaan gebruiken met PXE boot.
welliswaar gewoon met alleen ipv4.

nu heb ik alle interfaces in 1 vlan zitten (switching modus) en daarop een dhcp server geactiveerd.

start ik nu een windows client dan krijgt die netjes een IP uit de pool.
start ik dezelfde (en ook andere clients) met PXE boot, dan krijg ik geen IP en dus een timeout en dus geen server met TFTP

lijkt erop dat heel het PXE boot stuk met DHCP niet meer werkt in de huidige (laatste srx versie)

[CyBeR]

Gebruik jij de nieuwe of de oude dhcp server? Met de oude werkt 't namelijk zeker weten wel.

[Zjemm]

ik gebruik hem zo:

# show system services dhcp
name-server {
8.8.8.8;
8.8.4.4;
}
pool 192.168.1.0/24 {
address-range low 192.168.1.100 high 192.168.1.200;
default-lease-time 3600;
domain-name xxxxxx.net;
router {
192.168.1.1;
}
boot-file pxelinux.0;
boot-server 192.168.1.23;
}

de DHCP is vervolgens als allow host inbound traffic gezet op het vlan waarin alle netwerkpoorten zitten

het rare is gewoon dat ik geen IP krijg binnen PXE maar via windows wel.
heb net nog even getest om te PXE booten met mijn modem als DHCP server
dan krijg ik netjes een IP, verder kom ik niet omdat ik daar geen boot opties mee kan geven.

of zou je van de SRX geen IP krijgen binnen het PXE verhaal als de bootserver niet werkt oid?

[CyBeR]

Jij moet niet boot-server gebruiken maar next-server. Zie mijn eerste post in dit topic, dat is mijn config en die werkt.

[Zjemm]

Hmmmm zal het testen, maar het blijft vaag omdat ik helemaal geen ip krijg via dhcp

[CyBeR]

Zjemm schreef op donderdag 21 augustus 2014 @ 17:29:
Hmmmm zal het testen, maar het blijft vaag omdat ik helemaal geen ip krijg via dhcp

Waarschijnlijk wel, maar de meeste PXE-firmwares accepteren een DHCPOFFER zonder next-server niet, en negeren dat dan gewoon.

[Zjemm]

Klinkt logisch morgen laat ik ff weten of het gelukt is of niet.

Weet jij toevallig een antwoord op het volgende?

Als ik nou 2 clients heb op het netwerk met alle 2 een eigen dns naam. Kunnen ze die dan van elkaar resolven via de srx ? Dus speelt de srx in deze dan een soort dns server rol?

Ik heb op dit moment een checkpoint 620 ( te koop trouwens) in gebruik die dat bijvoorbeeld wel kan. Ik heb daarop bijvoorbeeld gewoon mijn server met vast ip in de object lijst toegevoegd met naam en de clients gebruiken de checkpoint als dns server en kunnen dan die host gewoon resolven.

[CyBeR]

Nee SRX'en houden zich niet echt met DNS bezig.

[Zjemm]

maakt dus geen verschil

het volgende heb ik nu staan:
dhcp {
default-lease-time 3600;
domain-name xxxxx.net;
domain-search {
xxxxx.net;
}
router {
192.168.1.1;
}
boot-file pxelinux.0;
next-server 192.168.1.23;
traceoptions {
file dhcp_client.dbg;
level all;
flag client;
}
pool 192.168.1.0/24 {
address-range low 192.168.1.200 high 192.168.1.254;
router {
192.168.1.1;
}
}
propagate-settings ge-0/0/0.0;
}
}


en in de log file krijg ik het volgende:

Aug 22 13:47:44 signalled dcd (pid 1407) to overlay
Aug 22 13:47:44 Send DHCPDISCOVER packet for ifl_index = 0 ifl_name=fe-0/0/0.0
Aug 22 13:47:44 Packing 3 bytes of options
Aug 22 13:47:44 dhcp client packet sent failed bytes sent = -1 dci_ifl_name = fe-0/0/0.0 dest addr = 255.255.255.255 dest port = 67 dci_ifl_index = 0 Client MAC = 10:0e:7e:7c:31:c0
Aug 22 13:47:44 Emptied the name_tree
Aug 22 13:47:48 DHCP client state timeout: ifl = fe-0/0/0.0
Aug 22 13:47:48 Send DHCPDISCOVER packet for ifl_index = 0 ifl_name=fe-0/0/0.0
Aug 22 13:47:48 Packing 3 bytes of options
Aug 22 13:47:48 dhcp client packet sent failed bytes sent = -1 dci_ifl_name = fe-0/0/0.0 dest addr = 255.255.255.255 dest port = 67 dci_ifl_index = 0 Client MAC = 10:0e:7e:7c:31:c0
Aug 22 13:47:56 DHCP client state timeout: ifl = fe-0/0/0.0
Aug 22 13:47:56 Send DHCPDISCOVER packet for ifl_index = 0 ifl_name=fe-0/0/0.0
Aug 22 13:47:56 Packing 3 bytes of options
Aug 22 13:47:56 dhcp client packet sent failed bytes sent = -1 dci_ifl_name = fe-0/0/0.0 dest addr = 255.255.255.255 dest port = 67 dci_ifl_index = 0 Client MAC = 10:0e:7e:7c:31:c0
Aug 22 13:48:12 DHCP client state timeout: ifl = fe-0/0/0.0
Aug 22 13:48:12 Send DHCPDISCOVER packet for ifl_index = 0 ifl_name=fe-0/0/0.0
Aug 22 13:48:12 Packing 3 bytes of options
Aug 22 13:48:12 dhcp client packet sent failed bytes sent = -1 dci_ifl_name = fe-0/0/0.0 dest addr = 255.255.255.255 dest port = 67 dci_ifl_index = 0 Client MAC = 10:0e:7e:7c:31:c0
Aug 22 13:48:44 DHCP client state timeout: ifl = fe-0/0/0.0
Aug 22 13:48:44 Send DHCPDISCOVER packet for ifl_index = 0 ifl_name=fe-0/0/0.0
Aug 22 13:48:44 Packing 3 bytes of options
Aug 22 13:48:44 dhcp client packet sent failed bytes sent = -1 dci_ifl_name = fe-0/0/0.0 dest addr = 255.255.255.255 dest port = 67 dci_ifl_index = 0 Client MAC = 10:0e:7e:7c:31:c0
Aug 22 13:49:48 DHCP client state timeout: ifl = fe-0/0/0.0
Aug 22 13:49:48 Num of Retransmission attemptsexhausted. No Server on the LAN ifl=fe-0/0/0.0
Aug 22 13:49:48 Lease filename to delete /var/db/leases/fe-0_0_0.0
Aug 22 13:49:48 Error deleting leasefilename /var/db/leases/fe-0_0_0.0 Error:No such file or directory


misschien maar een case bij juniper aanmaken

[CyBeR]

Dat is de log voor de dhcp client, niet voor de dhcp server.

[Zjemm]

fok
je hebt gelijk..... ik ga gauw terug mijn hoek in haha

nog eens even opnieuw doen dan

[Zjemm]

hmm het lijkt erop dat het interface staat te klapperen:

Aug 22 19:56:31 changed ifd fe-0/0/2 to up
Aug 22 19:56:31 rtsock ifl message for vlan.1
Aug 22 19:56:31 changed ifl vlan.1 to up
Aug 22 19:56:36 rtsock ifd message for fe-0/0/2
Aug 22 19:56:36 changed ifd fe-0/0/2 to down
Aug 22 19:56:36 rtsock ifl message for vlan.1
Aug 22 19:56:36 changed ifl vlan.1 to down
Aug 22 19:56:38 rtsock ifd message for fe-0/0/2
Aug 22 19:56:38 changed ifd fe-0/0/2 to up
Aug 22 19:56:38 rtsock ifl message for vlan.1
Aug 22 19:56:38 changed ifl vlan.1 to up
Aug 22 19:56:40 .. Walking leases on entry 0x5522c0
Aug 22 19:56:40 .... Walking lease 0x57d100
Aug 22 19:57:00 .. Walking leases on entry 0x5522c0
Aug 22 19:57:00 .... Walking lease 0x57d100
Aug 22 19:57:08 rtsock ifd message for fe-0/0/2
Aug 22 19:57:08 changed ifd fe-0/0/2 to down
Aug 22 19:57:08 rtsock ifl message for vlan.1
Aug 22 19:57:08 changed ifl vlan.1 to down
Aug 22 19:57:10 rtsock ifd message for fe-0/0/2
Aug 22 19:57:10 changed ifd fe-0/0/2 to up
Aug 22 19:57:10 rtsock ifl message for vlan.1
Aug 22 19:57:10 changed ifl vlan.1 to up


en daardoor dus nooit een ip krijgt, start ik daarna gewoon door naar windows krijg ik wel netjes een link en een IP.

ik ga mijn config maar eens volledig resetten. misschien de poorten uit switching mode weg halen en uit het vlan en eens proberen met 1 poort

[Zjemm]

Nou factory reset, geen resultaat
Downgrade naar de recommanded version, geen resultaat

Wat op valt is dat het device heel traag een lease uit geeft voor zowel een Windows als een Mac client, duurt wel tot 30 seconden.

Bij de pxe client dus helemaal niets

Misschien maar eens een andere srx 100 erbij pakken, kijken wat dat doet

[FatalError]

Sinds een paar dagen is 12.1X47 uit. Helaas heb ik hier nog steeds het probleem.
Ook werkt 12.1X47 niet meer op apparaten met 512MB RAM.

[Zjemm]

Nog wat nieuwe tests gedaan.
in elk geval duurt het veels te lang voordat de client een IP krijgt.
na lang wachten binnen pxe eindelijk een IP (+-60 seconden)

met boot-server ==> tftp timeout
set system services dhcp pool 192.168.1.0/24 address-range low 192.168.1.2
set system services dhcp pool 192.168.1.0/24 address-range high 192.168.1.254
set system services dhcp pool 192.168.1.0/24 router 192.168.1.1
set system services dhcp pool 192.168.1.0/24 boot-file pxelinux.0
set system services dhcp pool 192.168.1.0/24 boot-server 192.168.1.23
set system services dhcp propagate-settings fe-0/0/0


met next-server ==> tftp file not found
set system services dhcp pool 192.168.1.0/24 address-range low 192.168.1.2
set system services dhcp pool 192.168.1.0/24 address-range high 192.168.1.254
set system services dhcp pool 192.168.1.0/24 router 192.168.1.1
set system services dhcp pool 192.168.1.0/24 boot-file pxelinux.0
set system services dhcp pool 192.168.1.0/24 next-server 192.168.1.23
set system services dhcp propagate-settings fe-0/0/0


deze laatste optie lijkt dus beter te zijn zoals ook al aangegeven. alleen kan hij de file niet vinden.

word vervolgt

[CyBeR]

Zjemm schreef op woensdag 27 augustus 2014 @ 11:37:
met next-server ==> tftp file not found

Moet je even met tftp op een computer kijken of 'get pxelinux.0' werkt. Ik gok van niet. Iig dat lijkt me een configuratiefout in je tftp server.

Waarom 't zo lang duurt geen idee, wellicht die propagate-settings weg halen en alle relevante info zelf invullen?

[ Voor 26% gewijzigd door CyBeR op 27-08-2014 11:54 ]

[Zjemm]

het werkt zeker wel, of ik moet me in de bootfile naam vergissen.
ik heb namelijk ook nog een checkpoint 600 firewall waarop dit alles zonder problemen werkt. echter wil ik over stappen op de juniper

overigens hier de log van het moment van aanzetten van de client tot de file not found melding op de client.
je ziet hier duidelijk dat het zeker een minuut duurt voordat er een IP is.

http://textuploader.com/osib

[Zjemm]

kijk, de log van de tftp server, de eerste twee zijn van de pxe boot via de srx en de laaste regel via de checkpoint.

er wordt iets aan de naam toegevoegd wat er niet hoort door de srx. zo lijkt het tenminste

Aug 27 16:07:03 xx in.tftpd[1479]: RRQ from ::ffff:192.168.1.2 filename pxelinux.0▒
Aug 27 16:07:03 xx in.tftpd[1480]: RRQ from ::ffff:192.168.1.2 filename pxelinux.0▒

Aug 27 16:13:53 xx in.tftpd[1571]: RRQ from ::ffff:192.168.1.75 filename pxelinux.0


ik kom er wel.........ooit

[Zjemm]

nou ben weer een stukje verder.

De trage DHCP kwam doordat ik STP aan had staan. (word standaard aangezet als je de wizzard gebruikt)
nadat deze uitgezet is krijg ik op normale snelheid een lease.

het rare teken achter de pxelinux.0 file word veroorzaakt door een bug in de SRX DHCP server.
daar staat een 0xff in waardoor dat rare teken verschijnt.

ik zal juniper eens vragen of ze dat kunnen fixxen. Een workaround zou kunnen zijn door op de tftp server zel een remap file te maken die dat rare teken weer weg haalt.


Of heeft een van jullie misschien een idee waar ik de DHCPd config kan vinden op de SRX? wellicht is die gewoon zelf makkelijk aan te passen via cli

[ Voor 12% gewijzigd door Zjemm op 04-09-2014 16:10 ]

[FatalError]

Erg late reactie, maar ik wil even kwijt dat er diverse bugs gefixt zijn in de laatste softwareversies.
o.a. is het 0.0.0.0 adres in het next-server veld van het DHCP pakket opgelost. Het probleem waarvoor ik dit topic gestart ben.
Ook is er een probleem in opgelost in de DHCP communicatie waarbij de juniper TTL=1 zet en de eerste router het pakket weggooit en je dus geen ip adres krijgt.
Er zijn nog andere DHCP bugs opgelost die ik inmiddels weer vergeten ben..