Finally managed to get the logs from Juniper.
Feb 2 17:59:16.979283 [MSTR][DEBUG][default:default][SVR][INET][ge-0/0/1.0] --[ DHCP/BOOTP from == 172.16.5.42, port == 68 ]--
Feb 2 17:59:16.979332 [MSTR][DEBUG][default:default][SVR][INET][ge-0/0/1.0] --[ DHCP/BOOTP size == 300, op == 1 ]--
Feb 2 17:59:16.979370 [MSTR][DEBUG][default:default][SVR][INET][ge-0/0/1.0] --[ DHCP/BOOTP flags == 8000 ]--
Feb 2 17:59:16.979409 [MSTR][DEBUG][default:default][SVR][INET][ge-0/0/1.0] --[ DHCP/BOOTP htype == 1, hlen == 16 ]--
Feb 2 17:59:16.980218 [MSTR][DEBUG][default:default][SVR][INET][ge-0/0/1.0] --[ DHCP/BOOTP hops == 0, xid == edd51852 ]--
Feb 2 17:59:16.980274 [MSTR][DEBUG][default:default][SVR][INET][ge-0/0/1.0] --[ DHCP/BOOTP secs == 768, flags == 8000 ]--
Feb 2 17:59:16.980318 [MSTR][DEBUG][default:default][SVR][INET][ge-0/0/1.0] --[ DHCP/BOOTP ciaddr == 0.0.0.0 ]--
Feb 2 17:59:16.980358 [MSTR][DEBUG][default:default][SVR][INET][ge-0/0/1.0] --[ DHCP/BOOTP yiaddr == 0.0.0.0 ]--
Feb 2 17:59:16.980398 [MSTR][DEBUG][default:default][SVR][INET][ge-0/0/1.0] --[ DHCP/BOOTP siaddr == 0.0.0.0 ]--
Feb 2 17:59:16.980437 [MSTR][DEBUG][default:default][SVR][INET][ge-0/0/1.0] --[ DHCP/BOOTP giaddr == 0.0.0.0 ]--
Feb 2 17:59:16.980495 [MSTR][DEBUG][default:default][SVR][INET][ge-0/0/1.0] --[ DHCP/BOOTP chaddr == ab 05 57 f4 ba ba cb 47 b0 c7 5f fc 40 b3 86 56 ]--
Feb 2 17:59:16.980533 [MSTR][DEBUG][default:default][SVR][INET][ge-0/0/1.0] --[ DHCP/BOOTP sname == ]--
Feb 2 17:59:16.980570 [MSTR][DEBUG][default:default][SVR][INET][ge-0/0/1.0] --[ DHCP/BOOTP file == ]--
Feb 2 17:59:16.980619 [MSTR][DEBUG][default:default][SVR][INET][ge-0/0/1.0] --[ OPTION code 53, len 1, data DHCP-DISCOVER ]--
Feb 2 17:59:16.980665 [MSTR][DEBUG][default:default][SVR][INET][ge-0/0/1.0] --[ OPTION code 116, len 1, data 01 ]--
Feb 2 17:59:16.980726 [MSTR][DEBUG][default:default][SVR][INET][ge-0/0/1.0] --[ OPTION code 61, len 17, data 01 ab 05 57 f4 ba ba cb 47 b0 c7 5f fc 40 b3 86 56 ]--
Feb 2 17:59:16.980773 [MSTR][DEBUG][default:default][SVR][INET][ge-0/0/1.0] --[ OPTION code 12, len 4, data 42 4c 55 45 ]--
Feb 2 17:59:16.980820 [MSTR][DEBUG][default:default][SVR][INET][ge-0/0/1.0] --[ OPTION code 60, len 8, data 4d 53 46 54 20 35 2e 30 ]--
Feb 2 17:59:16.980875 [MSTR][DEBUG][default:default][SVR][INET][ge-0/0/1.0] --[ OPTION code 55, len 14, data 01 03 06 0f 1f 21 2b 2c 2e 2f 77 79 f9 fc ]--
Feb 2 17:59:16.980915 [MSTR][INFO] [default:default][SVR][INET][ge-0/0/1.0] --[ OPTION code 255, len 0 ]--
Feb 2 17:59:16.980958 [MSTR][NOTE] [default:default][SVR][INET][ge-0/0/1.0] jdhcpd_packet_decode: packet has an invalid hardware addressFeb 2 17:59:16.981001 [MSTR][NOTE] [default:default][SVR][INET][ge-0/0/1.0] jdhcpd_packet_handle: Packet decode failed
When looking at the Wireshark trace, I also see:
Client hardware address: ab0557f4babacb47b0c75ffc40b38656
compared to the Log
DHCP/BOOTP chaddr == ab 05 57 f4 ba ba cb 47 b0 c7 5f fc 40 b3 86 56
Ethernet II, Src: Mellanox_7c:1f:72 (
f4:52:14:7c:1f:72), Dst: Broadcast (ff:ff:ff:ff:ff:ff)
So, the mac address used by the Windows Cluster resources doesn't even look like a MAC address.. hmmm
------------------------------
Roelf Zomerman
------------------------------
Original Message:
Sent: 02-02-2021 07:25
From: Unknown User
Subject: DHCP for Windows & Kubernetes Clusters
Thats what resolved my issue.. but here is my full overrides just to show you.
set system services dhcp-local-server overrides process-inform
set system services dhcp-local-server overrides include-option-82 nak
set system services dhcp-local-server group jdhcp-group interface irb.0
set system services dhcp-local-server group jdhcp-phone interface irb.3000
Im sure its a knob to adjust somewhere.. Please take no offense to this question. Did you commit , and did the commit not roll back ?
also in your trace add
set system processes dhcp-service traceoptions level all
That should give way more data in your trace..**if you care I wrote an update on how to get traces off box to a remote syslog server and posted to community*.
Can you do a full pcap on the device not working via srx dhcp and one that works when you run off other dhcp server ?
Since i was rabbit holing myself last time. Ive learned even when tshooting dhcp always get full pcap and filter out the display ** 2 bad days of hurt on my own time
Original Message:
Sent: 02-02-2021 06:43
From: Roelf Zomerman
Subject: DHCP for Windows & Kubernetes Clusters
Yeah it seems like the request is coming in from one the primary nodes running the cluster - a machine that already has an IP from the DHCP
the machine itself does get an IP from the Juniper DHCP - but the resources inside the cluster on that host will not..
really strange.. do i need to put additional values after the override? without it it does not solve the problem..
------------------------------
Roelf Zomerman
Original Message:
Sent: 02-02-2021 05:39
From: Unknown User
Subject: DHCP for Windows & Kubernetes Clusters
Ive ran into ODD things with SRX dhcp and posted a ER.
Try this set system services dhcp-local-server overrides process-inform.
I to only had odd issues with dhcp issues on my srx . My lab linux dhcp worked 100% my office Infoblox 100%, remote sites running Palo Altos.
So try what i posted and I hope it helps you out. FYI I have posted a ER but got nothing back as of yet . So if anyone reading that can do anything about ERs..
Please request to have this option set on by default in jdhcp ! If they say no please ask them to explain why. If there is a good reason id like to know.
Personally Id recommend to have all your customers enable this if they are running dhcp on their Juniper gear.
My tshoot story/notes if you care
The odd thing about the access point. It would get its IP from my SRX just fine, Extreme ap boot up in a discovery mode WING and Identify
1st it goes into WiNG mode if its not able to connect to its controller via dhcp options 190, 191 .. Then it sends out a dhcp inform with src 169.254.39.40 but inside the dhcp inform it posted its Client add it got on bootup . Took me a few days to get the right capture as I used a filter on the SRX ONLY looking for the ip address the AP had via dhcp 10.3.208.0/24 .. not the 169.254.39.40 ..
I keep thinking it was a vpn / polciy issue were something was getting alg and dropped but not getting logged.
Original Message:
Sent: 02-01-2021 00:07
From: Roelf Zomerman
Subject: DHCP for Windows & Kubernetes Clusters
Hi all,
I'm running a dhcp-local-server on my SRX340, and while it works for my clients (Windows, Linux, IOT etc..) it doesn't seem to work for Windows Clusters and Kubernetes clusters - the DHCP request itself times out.
When installing a Windows DHCP on the same subnet, everything works, but then I'd have 2 DHCP servers on my network which I'd rather not have..
Is there any filter or option I have to enable to allow Windows Clusters to be able to receive a DHCP as well? (perhaps it's like dual MAC protection or something??)
I know - clusters should have fixed IP's, but Azure Kubernetes Services on Azure Stack HCI uses DHCP mostly..
Roelf
------------------------------
Roelf Zomerman
------------------------------