Controllerless Networks

I have a need to configure a DHCP Option 121 on a standalone IAP.

I have been researching this quite a bit including the RFC documentation on DHCP Option 121. It looks like we can configure this on the IAP DHCP configuration, but we are unsure of the syntax that is required on the IAP as the CLI and User Guide we have for the 6.5.0.0-4.3.1.0 firmware doesn’t have details on specifically configuring Option 121.

 

Could someone double check that we are using the proper syntax/parameters when configuring Option 121?

 

 As an example below:

 

If we were using the destination and gateway below.

 

Destination: 192.168.4.1/24

Gateway: 192.168.22.1

 

Option 121 according to the RFC documentation used the format 0xnnddddddddgggggggg where n=mask, d=destination, g=gateway.

 

Since  /24 is a 255.255.255.0 mask, we should only have to convert the non-zero octets to hex. This would leave us with the following converted value:

 

0x18C0A804C0A81601

 

However, when we add this value to the DHCP options, we do not seem to have the effect we are expecting.

 

We have also tried using just 18C0A804C0A81601.

 

Are we using the proper syntax for adding the route option?

I worked out this from the route in your post.

0x18C0A80401C0A81601

Looks slightly different to yours. Looks like you missed out a bit.

Thanks for the check, the value you have is what I originally computed as well, however, since this is a /24 mask, we shouldn't need the 01 in the string:

 

0x18C0A80401C0A81601

 

However, I have tried the following values and still haven't seen the desired effect:

 

0x18C0A80401C0A81601

0x18C0A804C0A81601

18C0A80401C0A81601

18C0A804C0A81601

 

Does the IAP (either WebUI or CLI) expect a different format input?

 

I don't know exactly what value the IAP is expecting I only know what the DHCP RFC says and other resources.

 

I would be surprised if the IAP didn't adhere to the DHCP standard.

 

So, lets break it down.

 

We know that the value shouyld be in this format:

 

0xnnddddddddgggggggg

where 0x specifies a hex value, n=mask, d=destination, g=gateway.

 

As per your example, lets say the destination = 192.168.4.0/24 and the gateway = 192.168.22.1

 

Using the hex converter here and Google, we can work out the following:

 

netmask = 18
destination = C0A80400

gateway = C0A81601

 

So, that equates to: 0x18C0A80400C0A81601

 

 

Okay, agreed there.

Seems to work one my test setup with one of the clients under my control.

 

It smells like our setup is correct so I'm starting suspect my vendor's client device.

Now I need to go to the vendor and figure out what the heck they are going with their routing table as this looks like it may be a problem on their side of things.

Zummarius,

 

Is your destination 192.168.4.1/24 as stated or did you mean 192.168.4.0/24?

 

edit: I ask because 192.168.4.1/24 isn't a valid destination, 192.168.4.1/32 would be valid and it would change your encoding.

Okay, as a heads up we tried the following:

 

18:C0:A8:04:C0:A8:16:01

 

The above actually worked.  So it looks like the colons are needed to separate the converted octets.

 

Simple syntax problem on the entry value.