One of the biggest questions that is asked is how does the controller handle DHCP, in earlier versions, and what is the difference between DHCP proxy and bridging in the newer versions. WLC supports two modes of DHCP operations in case an external DHCP server is used, DHCP proxy mode and DHCP bridging mode. The DHCP proxy mode serves as a DHCP helper function to achieve better security and control over DHCP transaction between the DHCP server and the wireless clients. DHCP bridging mode provides an option to make controller’s role in DHCP transaction entirely transparent to the wireless clients. The DHCP proxy is not a DHCP relay agent as specified in DHCP relay RFCs . It is essentially a helper function that utilizes some relay functionality to direct and transform DHCP transactions between the server and the client. It is not designed to be compliant with the DHCP relay RFCs.
Table 7-1 Proxy Mode and Bridging Mode in Comparison
|
Handling Client DHCP |
DHCP Proxy Mode |
DHCP Bridging Mode |
|
Modify giaddr |
Yes |
No |
|
Modify siaddr |
Yes |
No |
|
Modify Packet Content |
Yes |
No |
|
Redundant offers not forwarded |
Yes |
No |
|
Option 82 Support |
Yes |
No |
|
BOOTP support |
No |
Server |
|
Per WLAN configurable |
Yes |
No |
|
RFC Non-compliant |
Proxy and relay agent are not exactly the same concept. But DHCP bridging mode is recommended for full RFC compliance. |
No |
DHCP Proxy Mode
The DHCP proxy is not ideal for all network environments. The controller modifies and relays all DHCP transactions to provide helper function and address certain security issues. The controller’s virtual IP address is normally used as the source IP address of all DHCP transactions to the client. As a result, the real DHCP server IP address is not exposed in the air. This approach was adopted from the early days of the product to help address certain security concerns on open university campus who were among our first Beta customers. University campus usually have open WLAN deployed. Exposing real DHCP server IP would cause security issues. The virtual IP is displayed in debug output for DHCP transactions on the controller.
DHCP proxy mode operation maintains the same behavior for both symmetric and asymmetric mobility protocols. When multiple offers are coming from external DHCP servers, the DHCP proxy will always select the first one that comes in and set the ip address of the server in the client data structure. As a result, all following transactions, renews will go through the same server, until a transaction fails after retries. Then the proxy will likely to select a different server for the client. The DHCP renew will go through the DHCP proxy in DHCP proxy mode. This is how the designed proxy behavior is used to serve license requests in different scenarios:
Handling of packets for local mode clients:
■ DHCP Discover
■ giaddr is initialized to Wlan IP.
■ The Discover is unicast from Wlan IP to each of the DHCP servers that are configured on the interface (or the WLAN).
■ DHCP Offer
■ The first Offer received is processed and sent to the client. All subsequent offers are dropped by the proxy.
■ giaddr is set to INADDR_ANY.
■ The DHCP server identifier (Option 54) is set to Virt IP. As a result, the client believes this to be the IP address of its DHCP server.
■ The Offer is unicast from Virt IP to the client (yiaddr).
■ DHCP Request
■ giaddr is initialized to Wlan IP.
■ The Request is unicast from Wlan IP to the appropriate DHCP server (the server that returned the first Offer to the client).
■ DHCP Ack
■ giaddr is set to INADDR_ANY.
■ The DHCP server identifier (Option 54) is set to Virt IP.
■ The ACK is unicast from Virt IP to the client (yiaddr). Handling of packets for foreign clients:
■ DHCP Discover
■ giaddr is initialized to be Mgmt IP.
■ The Discover is unicast from Mgmt IP to the management IP address of the anchor controller.
■ DHCP Offer
■ Validation is done to make sure the Offer was received from the Anchor.
■ giaddr is set to INADDR_ANY.
■ The DHCP server identifier (Option 54) is set to Virt IP. As a result, the client believes this to be the IP address of its DHCP server.
■ The Offer is unicast from Virt IP to the client (yiaddr).
■ DHCP Request
■ giaddr is initialized to be Mgmt IP.
■ The Request is unicast from Mgmt IP to the management IP address of the anchor controller.
■ DHCP Ack (Same behavior as local mode)
■ giaddr is set to INADDR_ANY.
■ The DHCP server identifier (Option 54) is set to Virt IP.
■ The ACK is unicast from Virt IP to the client (yiaddr). Handling of packets for anchor clients:
■ DHCP Discover (Same behavior as local mode)
■ giaddr is initialized to be Wlan IP.
■ The Discover is unicast from Wlan IP to each of the DHCP servers that are configured on the interface (or the WLAN).
■ DHCP Offer
■ The first Offer received is processed and sent to the client. All subsequent offers are dropped by the proxy.
■ giaddr is initialized to INADDR_ANY.
■ siaddr is initialized to INADDR_ANY.
■ The Offer is unicast from Wlan IP to the management IP address of the foreign controller.
■ DHCP Request (Same behavior as local mode).
■ giaddr is initialized to Wlan IP.
■ The Request is unicast from Wlan IP to the appropriate DHCP server (the server that returned the first Offer to the client).
■ DHCP Ack
■ giaddr is initialized to INADDR_ANY.
■ The Ack is unicast from Wlan IP to the management IP address of the foreign controller.
Handling of packets for export-foreign clients:
In this case, DHCP packets are EoIP tunneled directly from the export-foreign to the export-anchor. The packets are never processed by the DHCP proxy.
Handling of packets for export-anchor clients:
In this case, the proxy handles packets for a client just as if the client were a local mode client. However, when sending packets to the client it performs EoIP encapsulation (rather than 802.11 encapsulation).
DHCP Bridging Mode
The DHCP bridging feature is designed to make controller’s role in the DHCP transaction entirely transparent to the client. With the exception of 802.11 to Ethernet II conversion, packets from the client are bridged unmodified from the LWAPP tunnel to the client’s VLAN (or EoIP tunnel in the L3 roaming case). Similarly, with the exception of Ethernet II to 802.11 conversion, packets to the client are bridged unmodified from the client’s VLAN (or EoIP tunnel in the L3 roaming case) to the LWAPP tunnel.
When the DHCP Proxy is disabled and the system is performing Bridging, packets are passed to/from the client unmodified. The only packet transformations performed by the DHCP proxy are encapsulation/decapsulation (e.g., 802.11 to Ethernet II or EoIP tunneling). All packets between controllers (anchor/foreign, export anchor/export foreign) are EoIP tunneled to preserve L2 information. For both the anchor and foreign case, the DHCP Proxy, when performing EoIP encapsulation, sets bit 1 of the EoIP header flags field. This indicates to the fast path on the receiving end of the tunnel that the encapsulated packet is DHCP and needs to be sent to the control path.
