cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
2876
Views
5
Helpful
9
Replies

Nexus 3548 cannot PXE Boot!

Paul Bedorf
Level 1
Level 1

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

9 Replies 9

andrewswanson
Level 7
Level 7

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

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?

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

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  Login & Valid Contract Required
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?

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

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

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";
}

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

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...

Review Cisco Networking for a $25 gift card