01-26-2017 12:29 PM - edited 03-08-2019 09:04 AM
Hello everyone, i have two subnets configured as follows:
I am using cisco Nexus 3548 Chassis
version 6.0(2)A6(7)
interface Vlan21
no shutdown
no ip redirects
ip address 192.168.21.2/24
hsrp version 2
hsrp 21
ip 192.168.21.1
ip dhcp relay address 192.168.24.4
interface Vlan505
no shutdown
no ip redirects
ip address 192.168.24.2/24
hsrp version 2
hsrp 505
ip 192.168.24.1
ip dhcp relay address 192.168.24.4
If I bring up a virtual machine in the vcenter on Vlan21 it gets an ip address from 192.168.24.4 dhcp server no problem.
However, if I try to PXE boot through Foreman automation tool which sits on 192.168.24.4 subnet, (and is a dhcp server as well ) the virtual machine does not get booted through the PXE boot....
Does the DHCP relay need extra options to be configured for option 66 & 67?
I never had this issue with Catalyst switches but with Nexus switches it might be a little different...
Any feedback is much appreciated.
Thank You
01-26-2017 02:06 PM
look like the nxos command "ip dhcp relay address" only forwards dhcp. Catalyst equivalent "ip helper-address" forwards additional protocols:
http://docwiki.cisco.com/wiki/Cisco_NX-OS/IOS_DHCP_Relay_Comparison
Have you tried the "ip forward-protocol udp" command to forward the other required ports in nxos?
hth
Andy
01-26-2017 02:34 PM
Hi Andy, I have already checkout that link and followed its instructions to set up the relay...
As for the ' ip forward-protocol upd ' command it does not exists on switch, any ideas?
01-26-2017 03:19 PM
Feature is supported in the following software:
"From Cisco NX-OS Release 7.3(0)D1(1), you can use the UDP relay feature to relay broadcasts destined for UDP ports except DHCPv4 port numbers 67 and 68."
So it look like this isn't supported on Nexus 3548
Do your clients receive the pxe dhcp options ok from the dhcp server?
Andy
01-26-2017 05:35 PM
Hi Andy, I have checked online at:
https://software.cisco.com/download/release.html?mdfid=284365099&catid=268438038&softwareid=282088129&release=6.0(2)A6(8)&relind=AVAILABLE&rellifecycle=&reltype=latest
The latest softwar release is:
Nexus 3500 Release 6.0(2)A8(3) System Image
n3500-uk9.6.0.2.A8.3.bin
So if we PXE boot on the same subnet where the foreman automation tool is installed that is ip 192.168.24.4 then the machine pxes only on the 192.168.24.0 subnet... but if we try to pxe boot on another subnet like 192.168.21.0 then it does not pxe boot...
The switch by default also has CoPP Policies, do you think it may be related to that?
07-28-2017 02:55 AM
Hopefully you've got this resolved. I ran into similar issue in the past. In my scenario, the problem was due to DHCP snooping. With DHCP snooping, you'll want to make sure all paths towards DHCP server are in trusted segment. There's also a global dhcp snooping command that was needed "ip dhcp snooping vlan <#>" Once those were in place, did I start seeing DHCP ACKs
01-26-2017 06:46 PM
Hi -
I think Andy is going in the right direction here. You likely need the "next server" field to be configured.
If you are using Windows for DHCP, then Option 66 is the correct one. If you are using a different DHCP platform, then check the documentation for which setting controls "next server" (may be documented as SIADDR).
You may or may not need option 67 depending on how your PXE client functions.
PSC
01-31-2017 12:20 PM
Hi Guys, sorry im a little late with the reply, been unexpectedly busy with other tasks...
So for the dhcp.conf file in our linux machine we are using these settings:
# dhcpd.conf
omapi-port 7911;
default-lease-time 43200;
max-lease-time 86400;
ddns-update-style interim;
allow booting;
allow bootp;
option fqdn.no-client-update on; # set the "O" and "S" flag bits
option fqdn.rcode2 255;
option pxegrub code 150 = text ;
log-facility local7;
include "/etc/dhcp/dhcpd.hosts";
#################################
# ops.prod.cog.fn.pvt
#################################
subnet 192.168.24.0 netmask 255.255.255.0 {
pool
{
range 192.168.24.4 192.168.24.254;
}
option subnet-mask 255.255.255.0;
option routers 192.168.24.1;
option domain-name "ops.prod.cog.fn.pvt";
option domain-name-servers 192.168.24.4, 10.106.160.103;
option ntp-servers none;
next-server 192.168.24.4;
filename "pxelinux.0";
}
#################################
# ae.dev.cog.fn.pvt
#################################
subnet 192.168.21.0 netmask 255.255.255.0 {
pool
{
range 192.168.21.4 192.168.21.254;
}
option subnet-mask 255.255.255.0;
option routers 192.168.21.1;
option domain-name "ae.dev.cog.fn.pvt";
option domain-name-servers 192.168.24.4, 10.106.160.103;
next-server 192.168.24.4;
filename "pxelinux.0";
}
02-01-2017 10:10 AM
Hi Paul -
I don't really see a problem with your Nexus or DHCP server configurations. You could add option 66/67, but I'm not sure if it will help.
Have you verified that your boot server is working correctly by booting a VM in the same subnet with the server? (Just to confirm my previous assumption that the boot server actually works.)
Interestingly, I found this support forums posting. Some of the information presented there may help you. (Particularly that you may need to reflect the broadcast in the local LAN using the directed broadcast address.)
At this point I would suggest capturing the DHCP conversations (using the client MAC as a filter), then examining what the client system is requesting versus what is being returned.
PSC
02-02-2017 07:21 AM
Hi Paul, So I can successfully PXE boot from the same vlan (192.168.24.0) where the automation tool resides, but cannot PXE boot from any subnets. Here is an interesting thing. When attempting to PXE boot from another subnet say ( 192.168.21.0) Im doing tcpdump on the automation tool where the dhcp is running and see the following:
2017-02-02T10:09:43.451567-05:00 foreman01 dhcpd[1375]: DHCPDISCOVER from 00:50:56:ae:08:15 via 192.168.21.2 2017-02-02T10:09:43.451849-05:00 foreman01 dhcpd[1375]: DHCPOFFER on 192.168.21.8 to 00:50:56:ae:08:15 via 192.168.21.2 |
So there is DHCPDISCOVER, DHCPOFFER but no DHCPACK. Surprisingly the switch does not show anything related in the logs too....
i also used the settings you referred in the suggested forum and was confident it would fix it but nothing :-)
Anyway I think I will open up a TAC with Cisco, as this is blocking our deployments etc... i will keep you guys posted on the solution once this bizzare issue is fixed...
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide