|
|
12
|
|
Hi!
Is it possibly to run pair of ISC DHCP Servers in a failover mode
and reliably supply static allocations for some DHCP clients,
e.g. using pools containing single IPv4 address?
I run ISC DHCP Servers version 4.3.3P1 with --enable-secs-byteorder configuration option enabled.
This version runs just fine for "ordinary" IPv4 pools containing multiple addresses.
It also runs just fine for single-address pools when not in failover mode.
In failover mode, ordinary pools run just fine, but single-address pools sometimes
run fine, sometimes do not, that is:
- first DHCP server logs:
Apr 18 00:00:02 k-45-monitor dhcpd: DHCPDISCOVER from 44:d9:e7:58:fd:e1 via 31.220.160.2: load balance to peer default
- second one logs:
Apr 18 00:00:02 m-19-monitor dhcpd: DHCPDISCOVER from 44:d9:e7:58:fd:e1 via 31.220.160.2: peer holds all free leases
And DHCP client obtains no address.
Some more details: I have several UniFi wireless access points (AP) controlled by UniFi Controller software.
These access points act as transparent L2 bridges supporting several distinct WLANs and vlans
for their wireless clients plus extra management vlan. They have wired uplink connected
to L2 manageable switches that insert DHCP option 82 to all request from AP themselves and their clients.
Mentioned vlans are routed by Cisco routers acting as DHCP relays. These routers relay DHCP requests
to pair of ISC DHCP Servers. There is ordinary IP pool for wireless clients and it works just fine.
UniFi access points theyselves obtain their IP addressess and additional DHCP vendor options from DHCP servers.
Each AP makes use of at least two IP addresses, one per vlan.
Each request of single AP comes from single MAC address of that AP but has distinct option 82
corresponding to distinct vlans and falls in distinct classes configured for DHCP servers.
The following part of DHCP Server configuration describes single UniFi AP:
# vlan 1600 = 0x640
class "ward2-vlan1600" {
match if binary-to-ascii(16, 8, ":", hardware) = "1:44:d9:e7:58:fd:e1"
and substring(binary-to-ascii(16, 8, ".", option agent.circuit-id), 0, 8) = "0.4.6.40";
}
# vlan 2065 = 0x811
class "ward2-vlan2065" {
match if binary-to-ascii(16, 8, ":", hardware) = "1:44:d9:e7:58:fd:e1"
and substring(binary-to-ascii(16, 8, ".", option agent.circuit-id), 0, 8) = "0.4.8.11";
}
pool { failover peer "default"; allow members of "ward2-vlan1600"; range 10.19.50.13; }
pool { failover peer "default"; allow members of "ward2-vlan2065"; range 62.231.174.13; }
All access points run the same hardware and software versions and their DHCP server
configuration of uniform but only some of they are served by DHCP servers just fine,
and some do not obtain an answer with logs cited above until I stop second DHCP server.
There seem to be some race condition problem in failover mode.
If I stop second (or first) DHCP server, remaining one servs all APs just fine.
Here is head part of DHCP server configuration:
# default ports tcp/647
failover peer "default" {
secondary;
address 62.231.191.174;
peer address 62.231.191.161;
max-response-delay 60;
max-unacked-updates 10;
mclt 60;
auto-partner-down 60;
load balance max seconds 3;
}
subnet 62.231.191.172 netmask 255.255.255.252 {}
include "/usr/local/etc/dhcpd.master";
# EOF
The second server resides in another network segment and IP network
and has the same configuration except for its IP address.
Both servers share single dhcpd.master containing main configuration,
part of which describing classess and pools is cited above.
Please help to debug this. I am ready to change configuration, test patches etc.
For the time being, I'm forced to stop using failover mode and stop second server.
Eugene Grosbein
_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users
|
|
|
On 30 Apr 2016, at 22:41, Eugene Grosbein wrote:
> Hi!
>
> Is it possibly to run pair of ISC DHCP Servers in a failover mode
> and reliably supply static allocations for some DHCP clients,
> e.g. using pools containing single IPv4 address?
Yes, but I wouldn’t configure for the statically-addressed devices
using the class/fool/failover technique. Instead, I would use
simple host declarations, duplicated in each server’s
configuration.
So, instead of
> # vlan 1600 = 0x640
> class "ward2-vlan1600" {
> match if binary-to-ascii(16, 8, ":", hardware) =
> "1:44:d9:e7:58:fd:e1"
> and substring(binary-to-ascii(16, 8, ".", option
> agent.circuit-id), 0, 8) = "0.4.6.40";
> }
I would use
host ward2-vlan1600 {
fixed-address 10.19.50.13;
hardware ethernet 44:d9:e7:58:fd:e1;
}
I expect that using agent.circuit-id is redundant, as the MAC address
should
uniquely identify each device. If you need to defend against
hardware address
collisions, you have “other problems”.
I hope this helps.
Best regards,
Niall O’Reilly
_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users
|
|
|
01.05.2016 13:23, Niall O'Reilly пишет:
> On 30 Apr 2016, at 22:41, Eugene Grosbein wrote:
>
>> Hi!
>>
>> Is it possibly to run pair of ISC DHCP Servers in a failover mode
>> and reliably supply static allocations for some DHCP clients,
>> e.g. using pools containing single IPv4 address?
>
> Yes, but I wouldn’t configure for the statically-addressed devices
> using the class/fool/failover technique. Instead, I would use
> simple host declarations, duplicated in each server’s configuration.
>
> So, instead of
>
>> # vlan 1600 = 0x640
>> class "ward2-vlan1600" {
>> match if binary-to-ascii(16, 8, ":", hardware) = "1:44:d9:e7:58:fd:e1"
>> and substring(binary-to-ascii(16, 8, ".", option agent.circuit-id), 0, 8) = "0.4.6.40";
>> }
>
> I would use
>
> host ward2-vlan1600 {
> fixed-address 10.19.50.13;
> hardware ethernet 44:d9:e7:58:fd:e1;
> }
>
> I expect that using agent.circuit-id is redundant, as the MAC address should
> uniquely identify each device. If you need to defend against hardware address
> collisions, you have “other problems”.
As I have wrote in the first letter, AP makes use of several IP addresses (one per vlan)
asking for them using the same MAC address. Such requests differ in option 82 only,
so I'm forced to use classes and matching against agent.circuit-id.
Is it possible to assign more than one fixed-address to the same MAC depending on vlan tag
without usage of classes?
Eugene Grosbein
_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users
|
|
|
> As I have wrote in the first letter, AP makes use of several IP addresses (one per vlan)
> asking for them using the same MAC address. Such requests differ in option 82 only,
> so I'm forced to use classes and matching against agent.circuit-id.
>
> Is it possible to assign more than one fixed-address to the same MAC depending on vlan tag
> without usage of classes?
Keep in mind that the DHCP server knows nothing about VLANs. It knows
about interfaces and their IP addresses. However, because the DHCP
server needs to be able to handle broadcast traffic (unless you use a
relay agent), there may be problems keeping broadcast traffic from
different VLAN-based interfaces apart, at least for some operating
systems.
You should be able to match on circuit ID just fine, though.
Steinar Haug, Nethelp consulting, [hidden email]
_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users
|
|
|
01.05.2016 15:56, [hidden email] пишет:
>> As I have wrote in the first letter, AP makes use of several IP addresses (one per vlan)
>> asking for them using the same MAC address. Such requests differ in option 82 only,
>> so I'm forced to use classes and matching against agent.circuit-id.
>>
>> Is it possible to assign more than one fixed-address to the same MAC depending on vlan tag
>> without usage of classes?
>
> Keep in mind that the DHCP server knows nothing about VLANs. It knows
> about interfaces and their IP addresses.
And it known about option 82 that can carry vlan information :-)
> However, because the DHCP
> server needs to be able to handle broadcast traffic (unless you use a
> relay agent), there may be problems keeping broadcast traffic from
> different VLAN-based interfaces apart, at least for some operating
> systems.
I do use DHCP relays, as I've wrote in the first message.
My DHCP servers reside in distinct network segments separated from clients
by routers and do not see any broadcasts, only unicast-relayed queries.
> You should be able to match on circuit ID just fine, though.
My problem still persists. How do I debug it?
Eugene Grosbein
_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users
|
|
|
When you get the error and fail to obtain an address, can you confirm that the single address is not actually assigned to another device?
We ran using failover mode with singleton pools like this - hundreds of them - identified by option-82 for quite a while. However, that was some versions ago and I inherited the configuration. I really don't know what special sauce made it tick, if any. But I would think it's still possible, so I would be inclined to troubleshoot it as you would for a normal (larger) pool.
Patrick
> On Apr 30, 2016, at 4:42 PM, Eugene Grosbein < [hidden email]> wrote:
>
> Hi!
>
> Is it possibly to run pair of ISC DHCP Servers in a failover mode
> and reliably supply static allocations for some DHCP clients,
> e.g. using pools containing single IPv4 address?
>
> I run ISC DHCP Servers version 4.3.3P1 with --enable-secs-byteorder configuration option enabled.
>
> This version runs just fine for "ordinary" IPv4 pools containing multiple addresses.
> It also runs just fine for single-address pools when not in failover mode.
>
> In failover mode, ordinary pools run just fine, but single-address pools sometimes
> run fine, sometimes do not, that is:
>
> - first DHCP server logs:
>
> Apr 18 00:00:02 k-45-monitor dhcpd: DHCPDISCOVER from 44:d9:e7:58:fd:e1 via 31.220.160.2: load balance to peer default
>
> - second one logs:
>
> Apr 18 00:00:02 m-19-monitor dhcpd: DHCPDISCOVER from 44:d9:e7:58:fd:e1 via 31.220.160.2: peer holds all free leases
>
> And DHCP client obtains no address.
>
> Some more details: I have several UniFi wireless access points (AP) controlled by UniFi Controller software.
> These access points act as transparent L2 bridges supporting several distinct WLANs and vlans
> for their wireless clients plus extra management vlan. They have wired uplink connected
> to L2 manageable switches that insert DHCP option 82 to all request from AP themselves and their clients.
> Mentioned vlans are routed by Cisco routers acting as DHCP relays. These routers relay DHCP requests
> to pair of ISC DHCP Servers. There is ordinary IP pool for wireless clients and it works just fine.
>
> UniFi access points theyselves obtain their IP addressess and additional DHCP vendor options from DHCP servers.
> Each AP makes use of at least two IP addresses, one per vlan.
> Each request of single AP comes from single MAC address of that AP but has distinct option 82
> corresponding to distinct vlans and falls in distinct classes configured for DHCP servers.
> The following part of DHCP Server configuration describes single UniFi AP:
>
> # vlan 1600 = 0x640
> class "ward2-vlan1600" {
> match if binary-to-ascii(16, 8, ":", hardware) = "1:44:d9:e7:58:fd:e1"
> and substring(binary-to-ascii(16, 8, ".", option agent.circuit-id), 0, 8) = "0.4.6.40";
> }
> # vlan 2065 = 0x811
> class "ward2-vlan2065" {
> match if binary-to-ascii(16, 8, ":", hardware) = "1:44:d9:e7:58:fd:e1"
> and substring(binary-to-ascii(16, 8, ".", option agent.circuit-id), 0, 8) = "0.4.8.11";
> }
> pool { failover peer "default"; allow members of "ward2-vlan1600"; range 10.19.50.13; }
> pool { failover peer "default"; allow members of "ward2-vlan2065"; range 62.231.174.13; }
>
> All access points run the same hardware and software versions and their DHCP server
> configuration of uniform but only some of they are served by DHCP servers just fine,
> and some do not obtain an answer with logs cited above until I stop second DHCP server.
> There seem to be some race condition problem in failover mode.
> If I stop second (or first) DHCP server, remaining one servs all APs just fine.
>
> Here is head part of DHCP server configuration:
>
> # default ports tcp/647
> failover peer "default" {
> secondary;
> address 62.231.191.174;
> peer address 62.231.191.161;
> max-response-delay 60;
> max-unacked-updates 10;
> mclt 60;
> auto-partner-down 60;
> load balance max seconds 3;
> }
> subnet 62.231.191.172 netmask 255.255.255.252 {}
> include "/usr/local/etc/dhcpd.master";
> # EOF
>
> The second server resides in another network segment and IP network
> and has the same configuration except for its IP address.
> Both servers share single dhcpd.master containing main configuration,
> part of which describing classess and pools is cited above.
>
> Please help to debug this. I am ready to change configuration, test patches etc.
> For the time being, I'm forced to stop using failover mode and stop second server.
>
> Eugene Grosbein
> _______________________________________________
> dhcp-users mailing list
> [hidden email]
> https://lists.isc.org/mailman/listinfo/dhcp-users_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users
|
|
|
01.05.2016 18:44, Patrick Trapp пишет:
> When you get the error and fail to obtain an address, can you confirm that the single address is not actually assigned to another device?
Yes: this IP does not belong to any other pool and there is no another device in that vlan having same MAC
and the lease is immediately assigned after I stop one of DHCP servers as device keeps trying to get an address.
_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users
|
|
|
01.05.2016 18:44, Patrick Trapp wrote:
> We ran using failover mode with singleton pools like this - hundreds of them - identified by option-82 for quite a while. However, that was some versions ago and I inherited the configuration. I really don't know what special sauce made it tick, if any. But I would think it's still possible, so I would be inclined to troubleshoot it as you would for a normal (larger) pool.
Did you use failover mode? Without that, I have no problems with such pools.
_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users
|
|
|
On 1 May 2016 09:24:00 BST, Eugene Grosbein < [hidden email]> wrote:
>
>As I have wrote in the first letter, AP makes use of several IP
>addresses (one per vlan)
>asking for them using the same MAC address. Such requests differ in
>option 82 only,
>so I'm forced to use classes and matching against agent.circuit-id.
>
>Is it possible to assign more than one fixed-address to the same MAC
>depending on vlan tag
>without usage of classes?
I think so, but details of your network topology may give problems.
If the tuple (Mac address, relay IP address) is unique and trustworthy for each IP address you need to assign, there is a simple solution without needing failover or classes. In this case, you'll need either
(a) multiple fixed-address values in the host { } declaration, or
(b) multiple host { } declarations, each with the same MAC address, but with its own distinct name and IP address.
The DHCP relay will insert its own IP address as gwaddr to identify the originating (v)LAN, and each DHCP server will select a host declaration with matching fixed-address. ISC DHCP server can't do anything useful with dot1q tags.
With either of these approached, you must duplicate the host declaration on the different DHCP servers. With multiple host declarations, each needs a unique name, which needn't match anything in the DNS.
IHTH
Niall O'Reilly
--
Sent from Kaiten Mail. Please excuse my brevity.
_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users
|
|
|
02.05.2016 1:13, Niall O'Reilly wrote:
>> Is it possible to assign more than one fixed-address to the same MAC
>> depending on vlan tag
>> without usage of classes?
>
> I think so, but details of your network topology may give problems.
> If the tuple (Mac address, relay IP address) is unique and trustworthy for each IP address you need to assign, there is a simple solution without needing failover or classes. In this case, you'll need either
>
> (a) multiple fixed-address values in the host { } declaration, or
>
> (b) multiple host { } declarations, each with the same MAC address, but with its own distinct name and IP address.
>
> The DHCP relay will insert its own IP address as gwaddr to identify the originating (v)LAN, and each DHCP server will select a host declaration with matching fixed-address. ISC DHCP server can't do anything useful with dot1q tags.
>
> With either of these approached, you must duplicate the host declaration on the different DHCP servers. With multiple host declarations, each needs a unique name, which needn't match anything in the DNS.
Thank you, this is interesting. But in my case all requests from single AP came with the same gwaddr,
so tuples (MAC address, relay IP address) are not unique, they are the same for requests
coming from distinct vlans. That is, same DHCP relay processes requests from multiple vlans
and inserts same gwaddr into them.
_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users
|
|
|
On 1 May 2016, at 19:41, Eugene Grosbein wrote:
> Thank you, this is interesting. But in my case all requests from
> single AP came with the same gwaddr,
Ah. Whenever I have configured Cisco router, I have been able to
configure the relay function
per-VLAN rather than per port. If that’s a possibility for you, it
may be interesting. From
what you say, router isn’t currently separating the VLANs.
> so tuples (MAC address, relay IP address) are not unique, they are the
> same for requests
> coming from distinct vlans. That is, same DHCP relay processes
> requests from multiple vlans
> and inserts same gwaddr into them.
I’ve never used option 82 with a host { } declaration, and don’t
know how to.
I suspect that the place to put the option-82 filtering may be in the
subnet { } declaration rather than in the host { } declaration
itself.
It may be that your best solution is to take courage from Patrick
Trapp’s
assurance the option 82 works, and debug as he suggests.
I’m sorry that I’m not able to offer a solution.
Best regards,
Niall O’Reilly
_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users
|
|
|
We did and still do.
> On May 1, 2016, at 6:53 AM, Eugene Grosbein < [hidden email]> wrote:
>
> 01.05.2016 18:44, Patrick Trapp wrote:
>
>> We ran using failover mode with singleton pools like this - hundreds of them - identified by option-82 for quite a while. However, that was some versions ago and I inherited the configuration. I really don't know what special sauce made it tick, if any. But I would think it's still possible, so I would be inclined to troubleshoot it as you would for a normal (larger) pool.
>
> Did you use failover mode? Without that, I have no problems with such pools.
>
> _______________________________________________
> dhcp-users mailing list
> [hidden email]
> https://lists.isc.org/mailman/listinfo/dhcp-users_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users
|
|
|
It will be a while before I have visibility on our current configuration to compare it to yours or to Niall's suggestion. We did not replace the old configuration, just removed those singleton pools when their devices migrated to a different solution, so I am hopeful there remain useful clues.
> On May 1, 2016, at 2:38 PM, Niall O'Reilly < [hidden email]> wrote:
>
>> On 1 May 2016, at 19:41, Eugene Grosbein wrote:
>>
>> Thank you, this is interesting. But in my case all requests from single AP came with the same gwaddr,
>
> Ah. Whenever I have configured Cisco router, I have been able to configure the relay function
> per-VLAN rather than per port. If that’s a possibility for you, it may be interesting. From
> what you say, router isn’t currently separating the VLANs.
>
>> so tuples (MAC address, relay IP address) are not unique, they are the same for requests
>> coming from distinct vlans. That is, same DHCP relay processes requests from multiple vlans
>> and inserts same gwaddr into them.
>
> I’ve never used option 82 with a host { } declaration, and don’t know how to.
> I suspect that the place to put the option-82 filtering may be in the
> subnet { } declaration rather than in the host { } declaration itself.
>
> It may be that your best solution is to take courage from Patrick Trapp’s
> assurance the option 82 works, and debug as he suggests.
>
> I’m sorry that I’m not able to offer a solution.
>
> Best regards,
> Niall O’Reilly
> _______________________________________________
> dhcp-users mailing list
> [hidden email]
> https://lists.isc.org/mailman/listinfo/dhcp-users_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users
|
|
|
Eugene Grosbein < [hidden email]> wrote:
> I have several UniFi wireless access points (AP) controlled by UniFi Controller software.
> These access points act as transparent L2 bridges supporting several distinct WLANs and vlans
> for their wireless clients plus extra management vlan. They have wired uplink connected
> to L2 manageable switches that insert DHCP option 82 to all request from AP themselves and their clients.
> Mentioned vlans are routed by Cisco routers acting as DHCP relays. These routers relay DHCP requests
> to pair of ISC DHCP Servers. There is ordinary IP pool for wireless clients and it works just fine.
>
> UniFi access points theyselves obtain their IP addressess and additional DHCP vendor options from DHCP servers.
> Each AP makes use of at least two IP addresses, one per vlan.
I'm using UniFi APs and they only get one address - on the management VLAN. They certainly do not get any other addresses - I've just checked the leases file at work to confirm.
This is the case both in the office (HP switch), and on a customer site (Cisco switches).
Could it be that your VLANs are not properly configured, and so your DHCP server is seeing one DHCP request from the AP repeated across multiple virtual interfaces ?
As pointed out before, if everything is correctly configured then the DHCP server will automagically work out the right subnet based on either the interface for non-relayed packets, or the GIAddr for relayed packets.
_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users
|
|
|
03.05.2016 0:13, Simon Hobson пишет:
>> I have several UniFi wireless access points (AP) controlled by UniFi Controller software.
>> These access points act as transparent L2 bridges supporting several distinct WLANs and vlans
>> for their wireless clients plus extra management vlan. They have wired uplink connected
>> to L2 manageable switches that insert DHCP option 82 to all request from AP themselves and their clients.
>> Mentioned vlans are routed by Cisco routers acting as DHCP relays. These routers relay DHCP requests
>> to pair of ISC DHCP Servers. There is ordinary IP pool for wireless clients and it works just fine.
>>
>> UniFi access points theyselves obtain their IP addressess and additional DHCP vendor options from DHCP servers.
>> Each AP makes use of at least two IP addresses, one per vlan.
>
> I'm using UniFi APs and they only get one address - on the management VLAN. They certainly do not get any other addresses - I've just checked the leases file at work to confirm.
> This is the case both in the office (HP switch), and on a customer site (Cisco switches).
My UniFi APs run with UniFi Controller 3.2.10 and Captive Portal/HotSpot enabled.
They request IP within untagged management VLAN and another IP within WLAN-assigned tagged vlan.
The Captive Portal does not work if AP cannot obtain IP from the same IP subnet as its wifi clients use.
> Could it be that your VLANs are not properly configured, and so your DHCP server is seeing one DHCP request from the AP repeated across multiple virtual interfaces ?
These requests come with different option 82 inserted and distinct DHCP XID, so they are not repeated.
> As pointed out before, if everything is correctly configured then the DHCP server will automagically work out the right subnet based on either the interface for non-relayed packets, or the GIAddr for relayed packets.
I use "ip unnumbered" routed network interfaces so GIAddr is the same for all vlans.
_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users
|
|
|
02.05.2016 2:37, Niall O'Reilly пишет:
> On 1 May 2016, at 19:41, Eugene Grosbein wrote:
>
>> Thank you, this is interesting. But in my case all requests from single AP came with the same gwaddr,
>
> Ah. Whenever I have configured Cisco router, I have been able to configure the relay function
> per-VLAN rather than per port. If that’s a possibility for you, it may be interesting. From
> what you say, router isn’t currently separating the VLANs.
My Cicso router is separating VLANs and relay works per-VLAN. These are just "ip unnumbered" vlans:
interface Loopback2
description "DHCP default gateway"
ip address 31.220.160.2 255.255.255.255
no ip redirects
!
interface Vlan1000
description "DHCP Guest"
ip unnumbered Loopback2
ip helper-address X.X.X.X
ip helper-address Y.Y.Y.Y
ip verify unicast source reachable-via rx
!
interface Vlan2000
description "DHCP Guest"
ip unnumbered Loopback2
ip helper-address X.X.X.X
ip helper-address Y.Y.Y.Y
ip verify unicast source reachable-via rx
!
The routers also runs DHCP snooping, it sees as DHCP server assigns IP addresses
and installs corresponding /32 route to corresponding network interface and
removes such route later when lease expires. These are standard functions
of Cisco DHCP relaying/snooping.
_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users
|
|
|
Eugene Grosbein < [hidden email]> wrote:
> My UniFi APs run with UniFi Controller 3.2.10
That is pretty ancient - there have been a LOT of improvements since (and new firmware for some of the APs). Unless there's been an update released in the last few days, 4.8.15 is current.
> and Captive Portal/HotSpot enabled.
Ah, we're not using that.
> They request IP within untagged management VLAN and another IP within WLAN-assigned tagged vlan.
> The Captive Portal does not work if AP cannot obtain IP from the same IP subnet as its wifi clients use.
I'll check that out sometime when I've a bit of spare time.
Eugene Grosbein < [hidden email]> wrote:
> My Cicso router is separating VLANs and relay works per-VLAN. These are just "ip unnumbered" vlans:
>
> interface Loopback2
> description "DHCP default gateway"
> ip address 31.220.160.2 255.255.255.255
> no ip redirects
> !
> interface Vlan1000
> description "DHCP Guest"
> ip unnumbered Loopback2
> ip helper-address X.X.X.X
> ip helper-address Y.Y.Y.Y
> ip verify unicast source reachable-via rx
That is broken. For DHCP to work properly, you **MUST** have the GI-Addr within the subnet served by the interface on the relay agent - using an un-numbered interface is pretty well guaranteed not to work properly.
Once you've fixed that, unless you need the APs to have specific addresses*, you can remove all the fudges and they'll "just work".
* And if you do, you can just do :
host ap1 {
hardware ethernet ....
fixed-address a.b.c.d, e.f.g.h, i.j.k.l, ...
}
and for each network, the AP will be given an IP address appropriate to the subnet.
_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users
|
|
|
On 2 May 2016, at 18:43, Eugene Grosbein wrote:
> 02.05.2016 2:37, Niall O'Reilly пишет:
>> On 1 May 2016, at 19:41, Eugene Grosbein wrote:
>>
>>> Thank you, this is interesting. But in my case all requests from
>>> single AP came with the same gwaddr,
>>
>> Ah. Whenever I have configured Cisco router, I have been able to
>> configure the relay function
>> per-VLAN rather than per port. If that’s a possibility for you,
>> it may be interesting. From
>> what you say, router isn’t currently separating the VLANs.
>
> My Cicso router is separating VLANs and relay works per-VLAN. These
> are just "ip unnumbered" vlans:
I would say that a relay which sets the same gwaddr on different
VLANs is definitely NOT working
oer-VLAN, and that using "ip unnumbered" is incompatible with correct
operation of DHCP.
I hope this helps.
Best regards,
Niall O'Reilly
_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users
|
|
|
03.05.2016 0:57, Simon Hobson пишет:
> Eugene Grosbein < [hidden email]> wrote:
>
>> My UniFi APs run with UniFi Controller 3.2.10
>
> That is pretty ancient - there have been a LOT of improvements since (and new firmware for some of the APs).
I known abount new firmware, I use APs compatible with 3.2.10 firmware.
> Unless there's been an update released in the last few days, 4.8.15 is current.
UniFi does not maintain Controller API compatibility between major releases
of the Controller and I cannot just upgrade to 4.x series as I have lots of custom code
utilizing the API. However, I'd like to not discuss this in this list.
>> My Cicso router is separating VLANs and relay works per-VLAN. These are just "ip unnumbered" vlans:
>>
>> interface Loopback2
>> description "DHCP default gateway"
>> ip address 31.220.160.2 255.255.255.255
>> no ip redirects
>> !
>> interface Vlan1000
>> description "DHCP Guest"
>> ip unnumbered Loopback2
>> ip helper-address X.X.X.X
>> ip helper-address Y.Y.Y.Y
>> ip verify unicast source reachable-via rx
>
> That is broken.
It works just fine when not in failover mode. Can you provide any references to standards
or DHCP server documentation for restrictions on GI-Addr?
> For DHCP to work properly, you **MUST** have the GI-Addr
> within the subnet served by the interface on the relay agent -
> using an un-numbered interface is pretty well guaranteed not to work properly.
"Subnet of the interface" is common notion but an IP network can work without
such notion at all. We use large plain IP pool (like /19) and multiple vlans
routed by set of routers and Router/DHCP relay creates "static" /32 routes
pointing to interface of client on the fly. In such case, interfaces do not have "subnet" notion
but the pool does have its netmask and client has it too. Routers do arp-proxying, of course.
It works just fine when not in failover mode. I can't think a reason
this could work for single ISC DHCP server and not work for a cluster other than bug/race.
_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users
|
|
|
03.05.2016 1:00, Niall O'Reilly пишет:
> I would say that a relay which sets the same gwaddr on different VLANs is definitely NOT working
> oer-VLAN, and that using "ip unnumbered" is incompatible with correct operation of DHCP.
Perhaps. Would you kindly provide any references to standards
or DHCP server documentation for restrictions on gwddr?
_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users
|
12
|
Locked
