Now we will look at a larger topology with multiple switches, routers, portchannel and SVI interfaces to see how DHCP work.
Clients are connected VLAN101 on switches with Layer 2 functionality only, they are then connected with multiple connections creating a logical Layer2 portchannel interface between itself and the Layer3 switches (Port-Channel 1 for North-South connection, Port-Channel 2 diagonal connection). They are the first hop and run VRRP/HSRP for redundancy and they are further connected to routers which is the connection further where we have the actual DHCP servers.
Client is connected to Swicth3 and the switchport is configured as an access port in vlan 101. Vlan 101 is also enabled on the trunk to switch1 and 2.
On switch1 and 2 there is a SVI created for vlan 101 and there is also HSRP created on vlan 101 for clients to use as the Default Gateway.
When Client broadcast a DHCP Discover it will just pass through switch3 and land on SVI vlan 101 on switch1 and 2. on Interface vlan 101 we need to configure ip-helper (dhcp relay agent) to convert the broadcast to a direct unicast to the DHCP servers in the network. You can and should have multiple ip-helper addresses configured for redundancy and loadbalancing.
SW1(config)#interface Vlan101
SW1(config-if)#ip helper-address 10.10.10.1
One thing that might trip you off here is that when the DHCP relay agent on Switch1 or 2 convert the broadcast to unicast and send it to DHCP server it will use its own SVI interface address as the source and you must have correct routing between DHCP server and the SVI interface.
No surprise here even though it’s a larger environment than the small we started with in DHCP take 1
Now over to some security concerns regarding to DHCP.
What if someone introduce a new DHCP server (either by mistake or maliciously) on vlan where we have clients? This rouge DHCP server might be handing out IP addresses that don’t work on our network which will cause clients to not be able to reach its resources or even worse handing out correct addresses but with wrong options such as default gateway to another address where the "bad" people sit and listen for traffic from clients picking up all kinds of information that should be kept secret. This could be done without even clients noticing something bad is happening. Traffic will be instead of the wanted between client and directly to the HSRP address shared between Switch1 and 2 going from client to the bad gateway where traffic can be intercepted and send on to the correct gateway (the HSRP address).
There is switch function called "DHCP snooping" to our rescue here. DHCP snooping will actually block DHCP server traffic if the port is categorized as untrusted and only allow full DHCP traffic if the port is "DHCP snooping trusted". DHCP snooping sit and listen for DHCP traffic and over time build up a database of mac-addresses, IP-addresses, vlan, lease time and ports, this information will then be used by the switch to block DHCP traffic which don’t match what the dhcp snooping database say, such as sending a DHCP release from wrong port or mac-address. The Snooping information can also be used by other functions in the switch such as arp-inspection, ip-source guard.
Configure DHCP snooping:
On interfaces leading towards DHCP servers you set the port as trusted to allow DHCP server responses.
SW3(config)#interface port-channel 1
SW3(config-if)#ip dhcp snooping trust
Then you enable DHCP snooping globally on the switch
SW3(config)#ip dhcp snooping
You must then enable DHCP snooping on the vlan's
SW3(config)#ip dhcp snooping vlan 101
You would think this is enough, no no no. when we enable dhcp snooping on switch3 it will not only listen for the dhcp traffic and build the database but also inject DHCP option 82 (Agent Information Option). DHCP relay agent insert information in option 82 to signaling to DHCP server which scope to use, this is done with option 82 field "giaddr", (gateway interface/ip address). Since our switch3 is layer2 only and actually run the relay agent it set the giaddr to null. When traffic comes to DHCP relay agent on switch1 it will be dropped because of giaddr is blank. To see this you must first enable debug for dhcp server.
SW1#debug ip dhcp server packet
and then you will see
---
00:37:45: DHCPD: Reload workspace interface Vlan101 tableid 0.
00:37:45: DHCPD: tableid for 10.1.101.2 on Vlan101 is 0
00:37:45: DHCPD: client's VPN is .
00:37:45: DHCPD: inconsistent relay information.
00:37:45: DHCPD: relay information option exists, but giaddr is zero.
---
With this we need to configure the relay agent on switch1 to accept empty giaddr field, we do this by allow the interface to trust option 82 information.
SW1(config)#interface vlan 101
SW1(config-if)#ip dhcp relay information trusted
Wireshark capture also reveals that option 82 is in the DHCP Discover packet.
Information in option 82 can be used by the DHCP server to further make a choice which DHCP pool to use or parts of pools or options to send back in the offer to clients. You can get some type of clients a special range of addresses or if clients are connected to a specific switch they will get some option in the offer. What information in option 82 and how its structured will differ between vendors and possibly software versions. I will not go into how to do this nor how to make the DHCP server make decisions on what to offer clients.
There are other option you can use on switch1 to allow the empty giaddr such as set all interface to trusted or trust all untrusted which will allow all DHCP discover packets with empty giaddr regardless of which interface it comes in on, that’s bad idea in my opinion, better to be specific. Don’t forget in case of a network failure where traffic is received on other interfaces to set the other interfaces to trust the empty giaddr.
