I'm configuring HSRP having scenario described in figure below. One gateway is active for one network and standby for other network and vice versa for other gateway. DHCP is configured on both Gateways and clients get automatic IPs. My question is if one Gateway (Switch A) is down other Gateway (Switch B) automatically becomes active for network for whome it is standby. Which DHCP option we need to configure on both Gateways DHCPs so that when Switch B is active and Switch a is down, and another client plugs in to network for which Switch A is active how come Switch B knows which IPs are allready assigned by Switch A and Switch B assign IPs to new clients other than IPs previously assigned by Switch A.
isc-dhcp-server now supports rfc6939 as of version 4.3, and I would like to be able use it as it is quite nice to be able to just use the mac address to identify dhcpv6 clients. However, I can't seem to find a dhcpv6 relay that supports rfc 6939, option 79, or dhcp6.client-linklayer-addr, other than the one on a Cisco switch as in this article:
https://insinuator.net/2015/02/is-rfc-6939-support-finally-here-checking-the-implementation-of-the-client-link-layer-address-option-in-dhcpv6/
I imagine the isc-dhcp-relay should be able to do this since isc-dhcp-server does, but it doesn't out of the box and the man page on ubuntu 16.04 server doesn't mention a way of turning it on. Does anyone either know how to enable this option, or know of a dhcpv6 relay that is installable on linux that does support it.
I have a pfSense applicance running version 2.x. I want to disable NetBios over TCP/IP via the DHCP Server so it is not activated on Windows clients. It's possible to do it with a Windows server but I can't find a way to do it properly on pfSense. Reading this tutorial, I thought not configuring a WINS server was sufficient, but it appears not. The only place where I found an option is in the OpenVPN section.
Any hints on how to do disable NetBios via DHCP server on pfSense ?
Thank you. Florent
I admin the network for a small business which has an IPCop firewall box providing DHCP services to the network (and various other services). The DHCP server in IPCop appears to be dhcpd and IPCop provides a web-based front end to editing the configuration file.
I'm looking to use the vendor-encapsulated-options option to send particular values for DHCP options 66 and 67 to a particular vendor-class-identifier. The purpose being the auto-configuration of some VoIP phones which support DHCP options 66/67 and 43/60.
I've already managed to get options 66 tftp-server-name and 67 bootfile-name working to auto-configure the phones. But of course these options are global and sent to all DHCP clients. I'm looking to experiment with the vendor-class-indentifier and vendor-encapsulated-options DHCP options to send the auto-configure information only to the phones. I realise this is probably overkill for a small business network but this is all to broaden my knowledge.
So I started reading through some information that's out there and I just cannot work out how to encode options 66/67 within a vendor-encapsulated-options string.
Here's the relevant RFC... https://www.rfc-editor.org/rfc/rfc2132#section-8 section 8.4
And here's the man page for dhcpd http://www.daemon-systems.org/man/dhcp-options.5.html under "VENDOR ENCAPSULATED OPTIONS"
Those documents seem to suggest that the options are to be encoded in HEX format, however looking at the man page example of the vendor-encapsulated-options option...
The value of this option can be set in one of two ways.
The first way is to simply specify the data directly,
using a text string or a colon-separated list of hexadecimal values.
For example:
option vendor-encapsulated-options
2:4:AC:11:41:1:
3:12:73:75:6e:64:68:63:70:2d:73:65:72:76:65:72:31:37:2d:31:
4:12:2f:65:78:70:6f:72:74:2f:72:6f:6f:74:2f:69:38:36:70:63;When I try and decode that lot from HEX to ASCII I get the following:
????A?????????sundhcp-server17-1????????/export/root/i86pc
So I'm sure I'm not understanding the format/encoding properly.
Here's my snippet from IPCop's dhcpd.conf
subnet 192.168.1.0 netmask 255.255.255.0 #GREEN
{
range 192.168.1.30 192.168.1.200;
option subnet-mask 255.255.255.0;
option domain-name "domain.com";
option routers 192.168.1.1;
option domain-name-servers 192.168.1.1;
option ntp-servers 192.168.1.1;
option netbios-name-servers 192.168.1.3;
default-lease-time 43200;
max-lease-time 172800;
option vendor-encapsulated-options "hello";
option vendor-class-identifier "snom320";
option vendor-class-identifier "snom821";
option bootfile-name "voipsettings/firstboot.xml";
option tftp-server-name "http://username:[email protected]";
} #GREEN
I have the vendor-class-identifiers set per the value submitted by the VoIP phones (Snom) in the DHCP request. The bootfile-name and tftp-server-name are the options (66/67) that I'm looking to encode in the vendor-encapsulated-options.
Snom have a guide on their wiki here...
http://wiki.snom.com/Networking/DHCP/Options#Auto_Provisioning_Options
(Apologies, my reputation is too low to post >2 links in a question)
That wiki seems to suggest that I need to encode the vendor-class-identifier as a "string of n octets"
Furthermore, the examples of the vendor-encapsulated-options given on that wiki article also return gibberish when converting from HEX to ASCII. So there's something critical that I'm not understanding here.
Can anyone give me a run-down of how to format/encode these DHCP options properly?
So I change jobs recently and in this new workplace I've found that we've actually got two DHCP servers. In the very same subnet, and they both have the same scope. I did not set up this but I see there are a lot of IP address conflicts, which must be because they aren't connected to one another in any way. So, this is probably the reason right?
I did however see that there are settings in the DHCP console which is called "Server connection bindings" and there are IP adresses that can be entered there. The IP entered is however the same IP address of itself, the same as 127.0.0.1. I don't know if they should point to one another though.
Now, the way I see it, only one DHCP is needed. OR, we could split the scopes. But I'm not really sure if that's necessary at all really. I mean, we only have a couple of hundred computers in the domain, as well as a bunch of iPhones and other smart phones.
So, am I way off here or should one of them be disabled? Or should I split the scopes?