Limited access subnet with DHCP on VLANs

[jtokach]

Hi. We have a network where we don't have control of the subnet router and can't utilized DHCP for managing the clients, but we need DHCP on management VLAN (20) that can route to the primary VLAN (10).

We use Microsoft MDT/WDS/PXE for imaging our Windows clients. Our current procedure to physically patch a client at a time from access port VLAN10 to access port VLAN20 which has DHCP scope of two IPs, with 10 minute leases. We reboot, PXE boot to WDS, reimage. When complete, we move the patch back to VLAN10 and join the domain. Fine for one or two re-images a month, but now we're looking to refresh all of the clients, 100 or spread across 12 rooms.

We can't roll out DHCP to fully manage the 172.16.3.0 clients due to requirements so we're looking for options for deploying DHCP on VLAN20 with a few 172.16.3.0 addresses where we could just logically change the ports from VLAN10 to 20, reimage with routing ability to the DC and the MDT/WDS host and then move them back to VLAN10 when complete.

We won't be allowed to added a static addresses back to 192.168.3.0 on the routers we don't manage.

[jtokach]

FWIW, private VLAN sounds promising or some sort of configuration with a 172.16.3.0/28 on VLAN20 so we might not need to add a new gateway? Not sure if that would be able to cross back from the DC.

[paul driver]

Hello

What you could do is enable dhcp sever on the core switch for vlan 20 users and negate  any other vlan user to be able to respond to/from the new dhcp server

example:

int vlan 20
PXE clients
ip address 20.20.20.254 255.255.255.0

ip dhcp pool Vlan 20
network 20.20.20.0 255.255.255.0
default-router 20.20.20.254
lease 0 0 10

access-list 100 deny udp host 20.20.20.254 range bootps bootpc any range bootps bootpc
access-list 100 deny udp any range bootps bootpc host 20.20.20.254 range bootps bootpc
access-list 100 permit ip any any

int vlan 10
ip access-group 100 in
ip access-group 100 out

int vlan 11
ip access-group 100 in
ip access-group 100 out

etc ...

[jtokach]

Paul, thanks for the response. That'll help lockdown the DHCP. Take a look at the drawing I attached. I'm unable to get routing working from the 192 subnet. Perhaps I'm doing something wrong, but I thought I'd need a static route on 172.16.3.1 which I can't do hence why I'm considering subnetting and P-VLANs.

[paul driver]

Hello
Not sure i understand the 192.x is that for the build srv, if so you show a core switch (172.16.3.5) isnt that performing L3, Can this reach the 192.x subnet from the core?

[jtokach]

• The 192.x was to keep DHCP out of band.
• The build server is multi-homed, with one IP in each subnet. MDT/WDS are currently configured for the 192.x.
• 172.16.3.5 is running DHCP only handing out addresses in the 192.x scope on VLAN 20. It's a "core" switch by name and location in the spine only. The gateway of all 172.x nodes is set to 172.16.3.1.
• VLAN 20 is trunked to all switches.
• We have a single access port on each switch in VLAN 20. When we re-image, we physically patch the target workstation to that port, PXE boot, reimage, move the patch back to it's former VLAN 10 port, then join the domain.

[jtokach]

• The 192.x was to keep DHCP out of band.
• The build server is multi-homed, with one IP in each subnet. MDT/WDS are currently configured for the 192.x.
• 172.16.3.5 is running DHCP only handing out addresses in the 192.x scope on VLAN 20. It's a "core" switch by name and location in the spine only. The gateway of all 172.x nodes is set to 172.16.3.1.
• VLAN 20 is trunked to all switches.
• We have a single access port on each switch in VLAN 20. When we re-image, we physically patch the target workstation to that port, PXE boot, reimage, move the patch back to it's former VLAN 10 port, then join the domain.

[jtokach]

Sorry for the duplicate posts. Had some trouble with the site yesterday. Any thoughts on this?

[jtokach]

The 192.x was to keep DHCP out of band.
The build server is multi-homed, with one IP in each subnet. MDT/WDS are currently configured for the 192.x.
172.16.3.5 is running DHCP only handing out addresses in the 192.x scope on VLAN 20. It's a "core" switch by name and location in the spine only. The gateway of all 172.x nodes is set to 172.16.3.1.
VLAN 20 is trunked to all switches.
We have a single access port on each switch in VLAN 20. When we re-image, we physically patch the target workstation to that port, PXE boot, reimage, move the patch back to it's former VLAN 10 port, then join the domain.

[paul driver]

Hello 

Can you share the configuration of l2/l3 switch 172.16.3.5  in a file and attach it to the post.

sh run
sh ip int brief
sh arp
sh vlan
sh int trunk
sh ip route

[jtokach]

Unfortunately, I cannot, it's on a closed network. There are no special configs.

Default VLAN = 1 and interface state is disabled (STIG req?)

VLAN 10 is defined.

SVI for VLAN 10 172.16.3.5. Route is direct attached to 172.16.3.0.

VLAN 20 is defined.

No SVI

VLAN 10 and 20 are trunked to down stream switches.

All used ports are access VLAN 10, except one is access VLAN 20.

VLAN 99 is defined.

Port sec is enabled. All unused ports are down and assigned to VLAN 99.