Cisco IOS XE DHCP Client - disable options from being sent in discover

[mcotherman]

I am running 17.9.04a on a C1111-8PLTEEAWB and trying to set up the DHCP client so that I can connect it to my ISP's Fiber ONT instead of their provided eero router without losing my IP address. The eero will faithfully get the IP it wants back, even after a long outage...  I can power-cycle the ONT and get a new address, but  really want to get mac-cloning working.

interface GigabitEthernet0/0/0
 description connected to Internet
 mac-address 5027.a92d.ffff
 ip dhcp client client-id ascii eero
 ip dhcp client broadcast-flag clear
 ip dhcp client class-id ascii
 ip dhcp client hostname eero
 ip dhcp client option 50 ip 47.***.***.***
 ip address dhcp
negotiation auto

I am looking at the IP Addressing Configuration Guide, Cisco IOS XE 17.x and other Cisco docs that allowed me to get part of the way, using commands like "ip dhcp client broadcast-flag clear" to set the unicast bootp flag. 

FYI - I am not able to use the command "ip dhcp client vendor-class disable" that is referenced.

packet capture of eero discover that gets a response and successfully negotiates the requested IP address:

No.     Time               Source                Destination           Protocol Length Info
      3 20:52:50.827999    0.0.0.0               255.255.255.255       DHCP     342    DHCP Discover - Transaction ID 0x7deccd76

Frame 3: 342 bytes on wire (2736 bits), 342 bytes captured (2736 bits) on interface \Device\NPF_{55FDD48B-D4C7-4C49-9A40-88F5C0C4155B}, id 0
Ethernet II, Src: 50:27:a9:2d:ff:ff (50:27:a9:2d:ff:ff), Dst: Broadcast (ff:ff:ff:ff:ff:ff)
Internet Protocol Version 4, Src: 0.0.0.0, Dst: 255.255.255.255
User Datagram Protocol, Src Port: 68, Dst Port: 67
Dynamic Host Configuration Protocol (Discover)
    Message type: Boot Request (1)
    Hardware type: Ethernet (0x01)
    Hardware address length: 6
    Hops: 0
    Transaction ID: 0x7deccd76
    Seconds elapsed: 10
    Bootp flags: 0x0000 (Unicast)
    Client IP address: 0.0.0.0
    Your (client) IP address: 0.0.0.0
    Next server IP address: 0.0.0.0
    Relay agent IP address: 0.0.0.0
    Client MAC address: 50:27:a9:2d:ff:ff (50:27:a9:2d:ff:ff)
    Client hardware address padding: 00000000000000000000
    Server host name not given
    Boot file name not given
    Magic cookie: DHCP
    Option: (53) DHCP Message Type (Discover)
    Option: (50) Requested IP Address (47.***.***.***))
    Option: (12) Host Name
    Option: (55) Parameter Request List
        Length: 13
        Parameter Request List Item: (1) Subnet Mask
        Parameter Request List Item: (28) Broadcast Address
        Parameter Request List Item: (2) Time Offset
        Parameter Request List Item: (3) Router
        Parameter Request List Item: (15) Domain Name
        Parameter Request List Item: (6) Domain Name Server
        Parameter Request List Item: (119) Domain Search
        Parameter Request List Item: (12) Host Name
        Parameter Request List Item: (44) NetBIOS over TCP/IP Name Server
        Parameter Request List Item: (47) NetBIOS over TCP/IP Scope
        Parameter Request List Item: (26) Interface MTU
        Parameter Request List Item: (121) Classless Static Route
        Parameter Request List Item: (43) Vendor-Specific Information
    Option: (255) End
    Padding: 0000000000000000000000000000000000000000000000000000000000

Packet capture of the latest iteration of the IOS-XE  DHCP Client configuration (no response from ISP's DHCP server). You will see that the Cisci IOS-XE DHCP client is adding in options 60,61, and124

I do not know if these are causing the ISP DHCP Server to not respond or if it is something else, but I would like to remove them (I am successful at *changing* the host identifier, the client identifier, and the vendor class identifier, and , but I really need to 'eliminate' them from being sent at all in the DHCP Discover message.

No.     Time               Source                Destination           Protocol Length Info
      1 23:18:13.503795    0.0.0.0               255.255.255.255       DHCP     349    DHCP Discover - Transaction ID 0x4954c014

Frame 1: 349 bytes on wire (2792 bits), 349 bytes captured (2792 bits) on interface \Device\NPF_{55FDD48B-D4C7-4C49-9A40-88F5C0C4155B}, id 0
Ethernet II, Src: 50:27:a9:2d:ff:ff (50:27:a9:2d:ff:ff), Dst: Broadcast (ff:ff:ff:ff:ff:ff)
Internet Protocol Version 4, Src: 0.0.0.0, Dst: 255.255.255.255
User Datagram Protocol, Src Port: 68, Dst Port: 67
Dynamic Host Configuration Protocol (Discover)
    Message type: Boot Request (1)
    Hardware type: Ethernet (0x01)
    Hardware address length: 6
    Hops: 0
    Transaction ID: 0x4954c014
    Seconds elapsed: 3
    Bootp flags: 0x0000 (Unicast)
    Client IP address: 0.0.0.0
    Your (client) IP address: 0.0.0.0
    Next server IP address: 0.0.0.0
    Relay agent IP address: 0.0.0.0
    Client MAC address: 50:27:a9:2d:ff:ff (50:27:a9:2d:ff:ff)
    Client hardware address padding: 00000000000000000000
    Server host name not given
    Boot file name not given
    Magic cookie: DHCP
    Option: (53) DHCP Message Type (Discover)
        Length: 1
        DHCP: Discover (1)
    Option: (57) Maximum DHCP Message Size
        Length: 2
        Maximum DHCP Message Size: 1200
    Option: (61) Client identifier
        Length: 5
        Type: 0
        Client Identifier: eero
    Option: (12) Host Name
        Length: 4
        Host Name: eero
    Option: (55) Parameter Request List
        Length: 8
        Parameter Request List Item: (1) Subnet Mask
        Parameter Request List Item: (6) Domain Name Server
        Parameter Request List Item: (15) Domain Name
        Parameter Request List Item: (44) NetBIOS over TCP/IP Name Server
        Parameter Request List Item: (3) Router
        Parameter Request List Item: (33) Static Route
        Parameter Request List Item: (150) TFTP Server Address
        Parameter Request List Item: (43) Vendor-Specific Information
    Option: (60) Vendor class identifier
        Length: 5
        Vendor class identifier: ascii
    Option: (124) V-I Vendor Class
        Length: 21
        Enterprise: ciscoSystems (9)
        CableLab Address Mode: 16
        NetInfo Parent Server Tag: \017C1111-8PLTEEAWB
    Option: (50) Requested IP Address (47.***.***.***)
        Length: 4
        Requested IP Address: 47.***.***.***)
    Option: (255) End
        Option End: 255

[mcotherman]

Sorry Paul, the R in the statement is a typo... It should say IOS-XE I have no idea what the the ISP DHCP Server is.

Using the 'client-id' command was my very first attempt.  After sniffing that exchange, I saw that the 'ip dhcp client client-id GigabitEthernet0/0/0' statement. just changed the option 61 section of the DHCP Discover packet from "cisco-50:27:a9:2d:ff:ff-Gi0/0/0" to "50:27:a9:2d:ff:ff".

The problem is most likely on the server side, and I have no control. If I use the most basic config with a default interface config and 'ip address dhcp', I get an address (and that is not automatic, If I power-cycle the ONT, I still have to then get on their chat bot and ask for tech support, like magic, they must bounce the interface, because their DHCP server then issues an address)

I am not able to complete the goal of getting the same address, so I will have to give up on 'swapability' between devices when the ISP says 'you are not using our router'.

[paul driver]

Hello Mike
Nw -- Just for you information mate, I have since labbed this up and using the client-id <interface> on IOS-XE for both server/client and it  does indeed work accordingly,

However with a client IOS-XE and server IOS-XR secure arp this does result in negating the cloning even with a host client utilizing the client-id <interface> feature.

[MHM Cisco World]

Hi again 

This time I check your post and other comments before I make suggestions.

Now any command is not effect' option or vendor-class

So I think the order of command is effect here' I read in cisco guide one day that you need to enter 

Ip dhcp client 

Ip address dhcp 

In specific order otherwise it will enter but not effective'

So try add 

Ip dhcp client only

If not working 

The  ip dhcp add

The  ip dhcp client 

Good luck and sorry for my previous reply.

MHM

[mcotherman]

Paul - Yes, the order matters if the interface happens to get an address before you add in the extra commands. If that happened, it would wait until the DHCP lease renews with the next request to implement the features. In my case, that is not an issue, as the commands are fully entered before I start the sniffer and insert the router into the environment. But I did add the 'ip address dhcp' at the end when I had multiple commands configured. 

The 'vendor-class disable' is not accepted in 17.9.4a, even though the docs specifically mention it, so I may try 17.12.x, but that is only one of the three sections of the Discover packet that I believe are giving the problems, and the more I see, the more I believe is is just a service provider configuration issue that may or may not be by design.