05-16-2012 06:12 AM
My situation is odd I know and i'll try to explain the best I can.
I need to Relay DHCP broadcasts from one vlan to another via a different physical port than the originating vlan. Here is my example setup in a nutshell:
Port 0: Trunk, vlan 1,2,3,4... (core network)
Port 3: Access, vlan 100 (guest wirless)
Vlan 100 is completely segmented from our core network so that there is no pathway for guests to transverse the lan equipment. So we put them on a seperate port going to our internet router.
Currently DHCP is handled by the controller, however we are being asked to attempt to bring all DHCP into a central management piece that is located on the core network.
I have disabled the DHCP Server on the controller and configured DHCP IP Helper on the vlan however, it is doing as I expected and leaving on Port 3 of the controller (verified with dhcp debug). Is there a way that we can configure the Relay to send out it's request on Port 0 (core network) or is there possibly another option (besides trunking vlan 100 across the internal LAN)?
05-16-2012 06:24 AM
Once the DHCP helper picks up the broadcast and converts it to unicast, it is sent to its destination using the routing table on the controller. So, if your DHCP server is 10.1.1.100 (for example), the helper will pick up the DHCP broadcast from VLAN 100, convert it to a unicast to 10.1.1.100, place the IP address of VLAN 100 inside the DHCP request (so that the DHCP server will know where the request orginated) and then lookup the route to the 10.1.1.100 and forward the packet.
Make sure you have a route (on the controller) to the subnet where your DHCP server lives that points to something on VLAN 1,2,3,4...
05-17-2012 06:04 AM
I have my default gateway setup pointing to my internal core LAN (and the our core will route appropriately). I can ping and trace our DHCP server from the controller. Do I need to be more specific in the routing table? Cause I was thinking the GoLR would take care of that unicast.
Here is an example of the debug from yesterday (i changed MAC and IPs for safety):
May 16 06:45:11 :202541: <DBUG> |dhcpdwrap| |dhcp| Received DHCP packet from Datpath, sos msg hdr flags 0x440 opcode 0x5a ingress 0x1397 vlan 300 egress 0x12c src mac AA:AA:AA:AA:AA:AA (this is the MAC of the client)
May 16 06:45:11 :202534: <DBUG> |dhcpdwrap| |dhcp| Datapath vlan300: DISCOVER AA:AA:AA:AA:AA:AA Options 37:0103060f77fc 39:05dc 3d:010454531d933c 33:0076a700
May 16 06:45:11 :202523: <DBUG> |dhcpdwrap| |dhcp| dhcprelay: dev=eth1, length=300, from_port=68, op=1, giaddr=0.0.0.0
May 16 06:45:11 :202532: <DBUG> |dhcpdwrap| |dhcp| got 2 relay servers
May 16 06:45:11 :202533: <DBUG> |dhcpdwrap| |dhcp| Relayed: DISCOVER server=10.1.1.100 giaddr=192.168.0.1 MAC=AA:AA:AA:AA:AA:AA
May 16 06:45:11 :202533: <DBUG> |dhcpdwrap| |dhcp| Relayed: DISCOVER server=10.1.1.101 giaddr=192.168.0.1 MAC=AA:AA:AA:AA:AA:AA
Port 0 IP: 10.10.10.10 (VLAN 1, with truck 2,3,4)
Port 3 IP: 192.168.0.1
Route table (again, IPs changed for safety):
#show ip route
Codes: C - connected, O - OSPF, R - RIP, S - static
M - mgmt, U - route usable, * - candidate default
Gateway of last resort is Imported from DHCP to network 0.0.0.0 at cost 10
Gateway of last resort is Imported from CELL to network 0.0.0.0 at cost 10
Gateway of last resort is Imported from PPPOE to network 0.0.0.0 at cost 10
Gateway of last resort is 10.10.10.10 to network 0.0.0.0 at cost 1
S* 0.0.0.0/0 [1/0] via 10.10.10.10*
C 10.10.10.0 is directly connected, VLAN1
C 192.168.0.0 is directly connected, VLAN300
05-17-2012 06:12 AM
From those logs, it looks like the controller is sending the DHCP request to 10.1.1.100 and 10.1.1.101 with the GI_ADDR of 192.168.0.1.
Does either 10.1.1.100 or 10.1.1.101 have a scope for 192.168.0.x (assuming /24)?
The packets to those DHCP servers should be routed via 10.10.10.10, since that is your default route and there is not a more specific route. Are you saying you have seen them leaving via VLAN 300?
05-18-2012 12:53 PM
I have looked at the logs for the DHCP server and we are seeing the DISCOVER messages coming from the Controller. So that is good. We are seeing the OFFERS coming from the DHCP server but are not seeing anything after that in the DHCP logs.
Is there some CLI command beyond just setting DHCP Logging to "debugging" and just always doing sh logg? More like 'tail' in the unix world?
So it seems like it is working just not getting beyond the OFFER stage and need a little extra help on what to look at.
05-19-2012 10:32 AM
I recommend you to capture the DHCP Discover packet from Aruba controller and look at "Relay agent IP address".
In my case with Catalyst 2960 switch, if the port for Aruba controller is Fa0/10 and monitoring port is Fa0/48,
(config)monitor session 1 source interface fa0/10
(config)monitor session 1 destination interface fa0/48
Then I connected a laptop with wireshark installed.
Select Capture - Option and choose interface. Click on "Capture Filter" and choose "TCP or UDP port 80 (HTTP) and chagne filer string as "port 68" Click OK.
On Capture - Option screen click Start to capture the trace.
You only see DHCP (bootp) protocol in the screen.
If you see DHCP Discover packet, find "Bootp flags: 0x0000 (unicast)
Client IP address 0.0.0.0 (0.0.0.0)
Your (client) IP address 0.0.0.0 (0.0.0.0)
Next sever IP address 0.0.0.0 (0.0.0.0)
Relay agent IP address 0.0.0.0 (0.0.0.0)
In order the central DHCP server to handle DHCP scope correctly, Aruba should set Relay agent IP addres as VLAN interface's IP address. If your VLAN100's interface IP is 172.21.100.1, this Relay agent IP address should be set as 172.21.100.1, so that central DHCP server can recognize which DHCP scope to respond. If the central DHCP server has a scope 172.21.100.x, the central DHCP server should send DHCP Offer with 172.21.100.x.