Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[gericb]

Oh that I could go back to 1.21!!  It was so much more stable, reliable, useful - 1.31NA SUCKS!

We have several routers in our environment, Linksys, DI-624, DIR-655... like any structured I/T person would do, we setup all of our fixed assets, workstations, printers, iphones with STATIC IP's and then let
any additional devices get DHCP assigned IP's out of a different range, so that their traffic/useage can be managed.

In the DIR-655 FW 1.21, the model of what WAS working:

Router IP: 192.168.1.1
DHCP Pool Range: 192.168.1.100 to 192.168.1.199

Using DHCP Reservation:

Workstation #1 00:00:00:00:00:01 - 192.168.1.2
iPhone        #1 00:00:00:00:00:02 - 192.168.1.3

Any NEW devices on the network, would be assigned an IP from the 100-199 pool, NO ISSUES.



In the DIR-655 FW 1.31NA:

Router IP: 192.168.1.1
DHCP Pool Range: 192.168.1.100 to 192.168.1.199

Using DHCP Reservation:

Workstation #1 00:00:00:00:00:01 192.168.1.2 {Trying to SAVE, ERROR, IP MUST BE IN RANGE}

so then change...

DHCP Pool Range: 192.168.1.2 to 192.168.1.199

Workstation #1 00:00:00:00:00:01 - 192.168.1.2 {Trying to SAVE, WORKS FINE}

This TOTALLY defeats the purpose of a managed environment.  Even the old DI-624 works as it should!

[EddieZ]

I don't see the pro's of separating the two categories...

try changing back the DHCP pool to x.100 -x. 199 after setting the reservations with a x.1 - x.199 range.

[davevt31]

Technically that is the correct error response for outside the DHCP range.  DHCP reservation saves a IP address within the specified DHCP scope for a specific MAC address.  The environment is still manged because you specify the addresses for the items that you want to have the specific addresses. 

[lotacus]

I would be one embarassed IT specialist to not know that DHCP reservation wouldn't work on addresses outside the DHCP scope, and go posting such information that there is a firmware bug preventing such thing to take place. It kind of reminds me getting tech calls from such IT specialists about their network problem, blaming it on Comcast and it's equipment, when it turns out they didn't have their computer set up properly to connect to the network in the first place, or calls from such individuals claiming that connection problems are the fault of such hardware/company, only to find out they did not know anything about, or how to configure, their firewall, as well as not know what the command line tool is and how to use it.

I suppose people are not getting the value for their dollar in education these days.

[EddieZ]

I would be one embarassed IT specialist to not know that DHCP reservation wouldn't work on addresses outside the DHCP scope, and go posting such information that there is a firmware bug preventing such thing to take place. It kind of reminds me getting tech calls from such IT specialists about their network problem, blaming it on Comcast and it's equipment, when it turns out they didn't have their computer set up properly to connect to the network in the first place, or calls from such individuals claiming that connection problems are the fault of such hardware/company, only to find out they did not know anything about, or how to configure, their firewall, as well as not know what the command line tool is and how to use it.

I suppose people are not getting the value for their dollar in education these days.

I was really curious to see an answer to my suggestion from the OP. Just wanted to see if he actually tried it. You kinda ruined it 

[Arvald]

Technically that is the correct error response for outside the DHCP range.  DHCP reservation saves a IP address within the specified DHCP scope for a specific MAC address.  The environment is still manged because you specify the addresses for the items that you want to have the specific addresses. 

not as unusual as you may think.  think of it as a static DHCP assignment... you don't want IPs in the static range being assigned to random PCs so you have it assign away from it .  And not everyone wants to set a static IP on a machine.  Since the 655 does not allow the fine grained control to specify.  I believe the network terms we use at work are static DHCP and dynamic DHCP.  The reason there would be free IPs in the static range is to allow for future growth.

The solution of assigning the static assignment then change the range does not work... I just tried on 1.21 and I get that message... so the only way I could see you having it work was a glitch.  The 655 uses the range specified as the entire scope.

[davevt31]

Static DHCP? I think my head just exploded 

[lotacus]

Static DHCP? I think my head just exploded 

Yes, it's an oxymoron, network engineers are not the brightest crayons in the box.

[Arvald]

Ya I know that it is a little crazy.  but it has a use.

[Nnyan]

I'm sorry but as others have stated you can not reserve an IP from DHCP if the IP is OUT of the DHCP pool!  That option is meant (for example) for those of us that for whatever reason need to give a device a constant IP but can't change the IP of the device out of that range.

If you need a STATIC (non DHCP) ip then you assign that to a range/class out of the DHCP.

[gericb]

Well to pull from the highly over used term from the Presidental elections, "the fact of the matter is..."

It WORKED as needed and as it SHOULD in FW 1.21.

It works as it SHOULD in my DI-624 FW 2.76  (Section labeled as Static DHCP and Dynamic DHCP)

It works in my Linksys DD-WRT FW 2.4SP1

So the fact it DOES NOT work in 1.31 to me, is a BUG. 

Come on SUPPORT, fix it back!

[davevt31]

It is not a bug, that is excatly the way a DHCP Reservation is supossed to work.  You reserve a specific address within a pool of addresses.

The Bug would be that it actually worked like you stated in the previous firmwares.

[EddieZ]

It is not a bug, that is excatly the way a DHCP Reservation is supossed to work.  You reserve a specific address within a pool of addresses.

The Bug would be that it actually worked like you stated in the previous firmwares.

I agree. This is a memorable moment: the first time somebody wants a bug back 

[Lycan]

That is correct, IEEE states that the DHCP reservation must pull from the DHCP pool. We corrected that a few firmwares back I believe.