6.4 DHCP Security

Hello,

 

I have a doubt concerning the command in the SG : "ip dhcp relay information policy keep". I think it is not necessary because, this command is useful on a relay agent in order to keep an existing relay information or it is put on the DHCP server.

Cam someone please clarify this.

 

Thanks.

 

Comments

  • Hi,

    This is useful on a relay agent. From cisco.com:

    "A DHCP relay agent may receive a message from
    another DHCP relay agent that already contains relay information. By
    default, the relay information from the previous relay agent is
    replaced. If this behavior is not suitable for your network, you can
    use the ip dhcp relay information policy {drop | keep | replace} global configuration command to change it."

    http://www.cisco.com/en/US/docs/ios/ipaddr/configuration/guide/iad_dhcp_rly_agt_ps6441_TSD_Products_Configuration_Guide_Chapter.html#wp1078844

     

    Baard

  • Yes i agree with you that it is necessary on the relay agent but in the SG they put it on the DHCP Server !!!

  • Hi,

    At the time of writing my first comment I had not gone through the SG, and I was very suprised by your answer. I had not expected that the command was needen on a ios dhcp server.

    I have now spent a lot of time trying to understand this, but I still have some issues to resolve. First of all, the SG config is not complete. In task 7.4, R6 is configured as active HSRP router, with udp broadcast forwarding integrated with hsrp. As long as Fa0/13 on SW1 is not configured as ip dhcp snooping trust, none of the clients on VLAN 367 will receive an IP address from the DHCP server, since SW1 will drop the dhcp relay packets from R6.

    But, once fixing that problem, I am still not able to make this work as long as SW1 inserts option 82. Configuring "ip dhcp relay information trust-all" on R1 does not fix the problem. Only when I disable option 82 insertion on SW1 the DHCP process works for clients in VLAN367.

    R3 and R6 is configured with " ip dhcp relay information trusted" and "ip dhcp relay information policy-action keep".

    Debug output from R1 (when option 82 insertion is enabled on SW1, and R1 configured with "ip dhcp relay information trust-all"):

    DHCPD: DHCPDISCOVER received from client 0063.6973.636f.2d30.3031.652e.6637.6630.2e36.6165.612d.4661.302f.30 through relay 139.1.0.6.
    DHCPD: Seeing if there is an internally specified pool class:
      DHCPD: htype 1 chaddr 001e.f7f0.6aea
      DHCPD: circuit id 00000000
    DHCPD: Sending DHCPOFFER to client 0063.6973.636f.2d30.3031.652e.6637.6630.2e36.6165.612d.4661.302f.30 (139.1.0.110).
    DHCPD: child  pool: 139.1.0.0 / 255.255.255.0 (VLAN367)
    DHCPD: pool VLAN367 has no parent.
    DHCPD: child  pool: 139.1.0.0 / 255.255.255.0 (VLAN367)
    DHCPD: pool VLAN367 has no parent.
    DHCPD: child  pool: 139.1.0.0 / 255.255.255.0 (VLAN367)
    DHCPD: pool VLAN367 has no parent.
    DHCPD: unicasting BOOTREPLY for client 001e.f7f0.6aea to relay 139.1.0.6.
    DHCPD: Sending notification of DISCOVER:
      DHCPD: htype 1 chaddr 001e.f7f0.6aea
      DHCPD: circuit id 00000000

    The client, R5´s Fa0/0 interface during testing, is not receiving any reply on its dhcp requests.

    Have you managed to get this working?

    Baard

     

  • Hi,

      It is needed just because the task asks for it' by default the relay agent will override it; theb task asks for the relay agent to keep the initial relay informstion option inserted by SW1.

     It is configured on the DHCP Relay Agent, not on the server.

    Hello,

     

    I have a doubt concerning the command in the SG : "ip dhcp relay information policy keep". I think it is not necessary because, this command is useful on a relay agent in order to keep an existing relay information or it is put on the DHCP server.

    Cam someone please clarify this.

     

    Thanks.

     

     

  • Hi Barhar,

       May updates will contain a detailed breakdown on this section.

    Regards,

  • Hi Christian,

    There is a typo in this task.

    "At the same time, R1 should accept BOOTREQUEST messages even with zero “giaddr” field."

    should be

    "At the same time, R3 should accept BOOTREQUEST messages even with zero “giaddr” field."

    Regards,

    Eric

  • Hello,

    Can you please explain to me what is the purpose of last requirement of this task?

    Just can't find any extra configuration to address this requirement, and cannot figure out why it is important.

    regards,

  • This task seems pretty messed up.

     

    Apart from the fact that it clashes with other tasks solution (like the configuration of R6 as a DHCP relay for that VLAN later on), I dont think the command "ip dhcp relay information policy keep" has any effect in this scenario.

     

    The relay information I believe is the giaddr field in the DHCP message.

    If R3 were to not modify it when it receives the DHCP request (which already contains a giaddr set to 0.0.0.0 due to DHCP snooping enabled on SW1 for VLAN367), then R1 when receiving the DHCP request would not know from which pool it would have to allocate the IP address.

    So, even with that command, R3 does modify the giaddr to 139.1.0.3 since forwarding a DHCP request with giaddr of 0.0.0.0 to the DHCP server would not make sense. If the giaddr was already set to some valid ip address, then I believe this command would make sense (i think it is only needed when a DHCP relay must relay a message received from another DHCP relay).

    We can see in the debug included in the SG that R3 indeed modify the giaddr :

    19:35:42.646: DHCPD: setting giaddr to 139.1.0.3.

     

    Secondly, the command

    ip dhcp relay information trust-all

    is still needed on R1. Not for the address allocation procedure (giaddr is set to R3 LAN address), but when a client wants to communicate to the DHCP server that it needs to release the address. In that case, the client sends a unicast message directly to the DHCP server, so the DHCP relay agent is not involved. However SW1 will still intercept the DHCP packet and add the giaddr 0.0.0.0. R1 will then reject the DHCP RELEASE message because by default it is considered invalid and the address is not released in the DHCP binding database :

     

    Oct 12 06:16:34.009: DHCPD: inconsistent relay information.
    Oct 12 06:16:34.009: DHCPD: relay information option exists, but giaddr is zero.
    Oct 12 06:16:34.053: DHCPD: inconsistent relay information.
    Oct 12 06:16:34.053: DHCPD: relay information option exists, but giaddr is zero.
    Oct 12 06:16:34.093: DHCPD: inconsistent relay information.
    Oct 12 06:16:34.093: DHCPD: relay information option exists, but giaddr is zero.
    Rack1R1#
    Rack1R1#
    Rack1R1#sh ip dhcp binding
    Bindings from all pools not associated with VRF:
    IP address          Client-ID/              Lease expiration        Type
                        Hardware address/
                        User name
    139.1.0.102         0063.6973.636f.2d30.    Infinite                Automatic
                        3030.622e.3566.3032.
                        2e31.3130.302d.566c.
                        3336.37
    Rack1R1#

     

    Once R1 is configured with "ip dhcp relay information trust-all", it will accept the DHCP RELEASE message even when the giaddr is 0.0.0.0 :

    Rack1R1#
    Oct 12 06:34:45.871: DHCPD: DHCPRELEASE message received from client 0063.6973.636f.2d30.3030.622e.3566.3032.2e31.3130.302d.566c.3336.37 (139.1.0.103).
    Oct 12 06:34:45.871: DHCPD: Sending notification of TERMINATION:
    Oct 12 06:34:45.871:  DHCPD: address 139.1.0.103 mask 255.255.255.0
    Oct 12 06:34:45.875:  DHCPD: reason flags: RELEASE
    Oct 12 06:34:45.875:   DHCPD: htype 1 chaddr 000b.5f02.1100
    Oct 12 06:34:45.875:   DHCPD: lease time remaining (secs) = 4294967295
    Oct 12 06:34:45.875: DHCPD: returned 139.1.0.103 to address pool V367.
    Oct 12 06:34:45.915: DHCPD: DHCPRELEASE message received from client 0063.6973.636f.2d30.3030.622e.3566.3032.2e31.3130.302d.566c.3336.37 (139.1.0.103).
    Oct 12 06:34:45.915: DHCPD: Finding a relay for client 0063.6973.636f.2d30.3030.622e.3566.3032.2e31.3130.302d.566c.3336.37 on interface Serial0/1.
    Oct 12 06:34:45.915: DHCPD: Seeing if there is an internally specified pool class:
    Oct 12 06:34:45.915:   DHCPD: htype 1 chaddr 000b.5f02.1100
    Oct 12 06:34:45.915:   DHCPD: circuit id 00000000
    Oct 12 06:34:45.915: DHCPD: there is no pool for 139.1.13.1.
    Oct 12 06:34:45.955: DHCPD: DHCPRELEASE message received from client 0063.6973.636f.2d30.3030.622e.3566.3032.2e31.3130.302d.566c.3336.37 (139.1.0.103).
    Oct 12 06:34:45.955: DHCPD: Finding a relay for client 0063.6973.636f.2d30.3030.622e.3566.3032.2e31.3130.302d.566c.3336.37 on interface Serial0/1.
    Oct 12 06:34:45.955: DHCPD: Seeing if there is an internally specified pool class:
    Oct 12 06:34:45.959:   DHCPD: htype 1 chaddr 000b.5f02.1100
    Oct 12 06:34:45.959:   DHCPD: circuit id 00000000
    Oct 12 06:34:45.959: DHCPD: there is no pool for 139.1.13.1.
    Rack1R1#
    Rack1R1#
    Rack1R1#
    Rack1R1#sh ip dhcp bin
    Rack1R1#sh ip dhcp binding
    Bindings from all pools not associated with VRF:
    IP address          Client-ID/              Lease expiration        Type
                        Hardware address/
                        User name
    Rack1R1#

     

    Cheers.

Sign In or Register to comment.