IP helpers, native VLANs, and PXE boot with Satellite 6.5

I’ve started a bit of an upgrade to my home lab. Well, not sure if you’d call it an upgrade, but something different.

I’m building a cloud, based on Intel NUC hardware. Specifically I’m using this NUC, with 16GB RAM, a 120GB M.2 SSD for the OS, and a 480GB SSD as an OSD for Ceph storage.

More on that later though. This post is about my wrestling with my Cisco 3560 L3 switch, and taking a crash course in its use.

For my home network, I have a Satellite 6.5 server that lives on my home-routable network – 192.168.0.0/24. This Satellite I have configured to provide PXE boot and kickstart provisioning.

VLANs

I have the following VLANs for home purposes:

  • VLAN10 – Home network. Anything connected to the switch that needs to be on my home subnet or access the gateway lives here. An access port with VLAN 10 as the access VLAN is connected to my wireless router.
  • VLAN50 – Provisioning network. Used for PXE booting hardware and keeping the DHCP traffic isolated from the home network (otherwise the wireless router will respond).

I need to get PXE-boot broadcast traffic from VLAN 50, over to the Satellite running in VLAN10.

Switch Configuration

Each of the ports down to the NUCs is a trunk port since I want to carry multiple VLANs down to those NUCs. VLAN 50 (provisioning) is the native VLAN on each interface.

For reference, here’s my configuration for each of these ports:

switcheroo#show run int gi0/7 
Building configuration...

Current configuration : 263 bytes
!
interface GigabitEthernet0/7
description "nucloud1 internal"
switchport trunk encapsulation dot1q
switchport trunk native vlan 50
switchport trunk allowed vlan 10,20,30,40,50
switchport mode trunk
switchport nonegotiate
spanning-tree portfast trunk
end

switcheroo#

Of the above, a critical line is spanning-tree portfast trunk. This forced the trunk port to start forwarding traffic as soon as it came up, rather than entering a spanning tree learning process. Note there is also the command “spanning-tree portfast” – this is for access ports only.

Without trunk portfast, the ports to the NUCs were not ready to start forwarding traffic when the first PXE-boot DHCP requests hit. By the time the port was ready the PXE-boot requests had timed out and failed.

Further, even running debug commands on the switch I would see no broadcast frames being received by the switch – even when I could see the NUC attempting PXE boot.

That one command took me hours to chase down. Sigh.

ip helpers

IP helpers are needed when your DHCP server is on one VLAN, and the client is on another. In my case the client is on VLAN50, and the DHCP server is on VLAN10.

I have specified ip helper-address in the virtual interface configuration for VLAN50, like so:

switcheroo#show run int vlan50 
Building configuration...

Current configuration : 93 bytes
!
interface Vlan50
ip address 10.10.10.1 255.255.255.0
ip helper-address 192.168.0.40
end

switcheroo#

Now, when DHCP broadcast traffic arrives in VLAN50 (i.e. from the NUCs), the switch will unicast it directly to the IP address of my Satellite server. It will also add some DHCP options so that the Satellite server can send the response back to the switch, also via unicast.

The dhcpd service running on Satellite needs to be configured to respond to requests originating from that subnet. To do so, I amended /etc/dhcp/dhcpd.conf to include the below:

subnet 10.10.10.0 netmask 255.255.255.0 { 
 pool
 {
   range 10.10.10.10 10.10.10.50;
 }

 option subnet-mask 255.255.255.0;
 option routers 10.10.10.1;
}

Now, even though Satellite doesn’t have an interface on 10.10.10.0, it will respond to requests originating in that subnet, issuing an IP address in the range 10.10.10.10-50.

Leave a Reply

Your email address will not be published. Required fields are marked *