DHCP forwarding with virtual machines, bridges and CISCO switch

netmask127 · ‎05-12-2015

Hi,

I have this rather unusual set up for a company product that we are experimenting with and can't seem to get it to work...it may be that it can't work as is but I don't know enough about CISCO switches and networking in general to be sure.

Basically I am trying to DHCP boot a bunch of virtual machines from a virtual DHCP server that is on a different VLAN.

The network is as follows:

On switch B I have VLAN 13 DHCP relay (i.e ip helper-address 66.23.101.1), where 66.23.101.1 is the IP of the virtual machine with the DHCP server.

The DHCP server is bridged to host A Ethernet card with bridge IP 10.200.2.1. Host A has IP 172.16.2.1 and VLAN 12 has network ID 172.16.2.0.

Host C has IP 172.16.3.1 and VLAN 13 has network ID 172.16.3.0. The VMs on host C are bridged to the host C ethernet card with bridge IP 10.200.3.1.

When I use wireshark and SPAN to read the incoming packets on the physical port (0/13) that host C is connected to, I can see the DHCP discovery messages coming from the VMs on host C. But using SPAN and wireshark to read packets going out of VLAN 13 I don't see any udp DHCP unicast messages going out. Similarly I don't see any DHCP messages going into VLAN 12. It seems the DHCP packets never got relayed.

Is what I'm trying to do possible??

Seb Rupik · ‎05-13-2015

Hi there,

What you are trying to achieve is possible, but I sense the reason it is failing is down to a lack of IP routes on your switches.

If you run 'sh ip route' on SwitchB, does it have a route for 66.23.101.0/24 (I'm guessing all HostA VMs sit on the same /24 subnet?) ? Or does it have a default route, where does that point?

Essentially you need the following routes:

!

ip route 66.23.101.0 255.255.255.0 172.16.2.1

ip route 10.200.3.0 255.255.255.0 172.16.3.1

!

This means when the DHCP requests are relayed by SwitchB and forward as unicast to 66.23.101.1 it knows to forward it to the host 172.16.2.1...which will then know to forward it onto its internal bridged network.

The second route isn't strictly necessary for this scenrio, but it is need in the event HostA VMs initiate traffic to HostC.

cheers,

Seb.

netmask127 · ‎05-13-2015

Ok so I've looked at the experimental setup more now and yes you are right there was no route to 66.23.101.1.

So I tried adding the ip route 66.23.101.0 255.255.255.0 172.16.2.1, but it does not seem to work. When I try to ping 66.23.101.1 on host C I get time to live exceeded.

Then I tried ip route 66.23.101.0 255.255.255.0 vlan 12, which allows me to ping, but DHCP boot still does not work.

I had a look at the VM setups on host A and host C, all the VMs are linked to a bridge which is using an alias of the physical ethernet card. There is also a second bridge (primary) on host A and host C which I think is the one that allows the hosts to communicate. This is on a different sub net to the VMs.

Would things work easier if host C and host A where on the same vlan?

Seb Rupik · ‎05-14-2015

hmmm perhaps the issue is that your VM boxes are not actually bridging the subnets which they are connected to into the vSwitches. If there were, the VMs on hostA would be on the same subnet as the host (172.16.2.0/24) and HostB VMs would be on 172.16.3.0/24 . This would allow them to respond to the redirected traffic.

At the moment it soulds like you might be using NAT on Host{A,B} in which case you'd need to configure port forwarding on Host A to send UDP/67 to the DHCP VM.

If you put them on the same VLAN and retain the NAT you will still need the port forwarding. If you configure bridged adapters, then it will DHCP will work without any further configuration.

cheers,

Seb.

netmask127 · ‎05-14-2015

I double checked the VMs on host A and as you said they are indeed on the 172.16.2.0/24 subnet. I can ping the VM with the DHCP server (172.16.2.201). So I think the bridge is working on host A. Host C has the same setup as A as far as I know, so I assume the bridge will work in a similar way.

It seems the problem is the switch. When I port mirror rx traffic on gi1/0/13 (the port host C is connected to); I can see DHCP bootp broadcasts coming in. But it just doesn't get forwarded for some reason. Does CISCO IOS have some security feature enabled by default?

Seb Rupik · ‎05-15-2015

OK, if you have determined that VMs are on the same subnet as the Hosts have you changed the ip-helper statement on VLAN13 to reflect this?

As a sanity check, are you able to ping from HostC to a VM on HostA?

netmask127 · ‎05-17-2015

I've tried putting the ip-helper address to 172.16.2.201 which is the address of the DHCP VM, doesn't seem to do much. I see DHCP bootp broadcast coming in on 0/13 but nothing going out 0/2 as before.

From host C I can ping all the VMs 172.16.2.20X addresses on host A. I cannot ping the VMs 66.23.101.X address without adding a static route path.

Could there be anything wrong with the DHCP broadcast from the VMs on host C?

I'm not that familiar with bridges...do they work like a NAT? The VM packets on host A would have source address changed from 66.23.101.X to 172.16.2.20X by the bridge on A, is that correct?

Seb Rupik · ‎05-19-2015

OK so you *are* running NAT. In that case broadcast packets on your VM network will not leave the subnet. You will need to create a bridge interface.

Essentially the Host interface will provide a 'bridge' between your physical and virtual networks:

https://www.vmware.com/support/ws5/doc/ws_net_configurations_bridged.html

If you can re-address and re-subnet your VM infrastructure you will get DHCP forwarding to work.

cheers,

Seb.

netmask127 · ‎05-19-2015

Ok thanks Seb, I will check that.