Send dhcp-users mailing list submissions to
        dhcp-users@lists.isc.org

To subscribe or unsubscribe via the World Wide Web, visit
        https://lists.isc.org/mailman/listinfo/dhcp-users
or, via email, send a message with subject or body 'help' to
        dhcp-users-requ...@lists.isc.org

You can reach the person managing the list at
        dhcp-users-ow...@lists.isc.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of dhcp-users digest..."


Today's Topics:

   1. Re: Failure of dhcp server failover (Simon Hobson)
   2. Re: Failure of dhcp server failover (Eugene Grosbein)
   3. Re: Failure of dhcp server failover (Eugene Grosbein)
   4. Re: Failure of dhcp server failover (Simon Hobson)
   5. Re: Failure of dhcp server failover (Niall O'Reilly)
   6. Re: Failure of dhcp server failover (Eugene Grosbein)
   7. Re: Failure of dhcp server failover (Eugene Grosbein)
   8. Re: Failure of dhcp server failover (Simon Hobson)


----------------------------------------------------------------------

Message: 1
Date: Mon, 2 May 2016 18:13:44 +0100
From: Simon Hobson <dh...@thehobsons.co.uk>
To: Users of ISC DHCP <dhcp-users@lists.isc.org>
Subject: Re: Failure of dhcp server failover
Message-ID: <7994569a-285e-4e68-8c0c-e5938f20d...@thehobsons.co.uk>
Content-Type: text/plain; charset=us-ascii

Eugene Grosbein <eu...@grosbein.net> 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.



------------------------------

Message: 2
Date: Tue, 3 May 2016 00:35:27 +0700
From: Eugene Grosbein <eu...@grosbein.net>
To: Users of ISC DHCP <dhcp-users@lists.isc.org>
Subject: Re: Failure of dhcp server failover
Message-ID: <57278fdf.4020...@grosbein.net>
Content-Type: text/plain; charset=UTF-8; format=flowed

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.



------------------------------

Message: 3
Date: Tue, 3 May 2016 00:43:47 +0700
From: Eugene Grosbein <eu...@grosbein.net>
To: "Niall O'Reilly" <niall.orei...@ucd.ie>
Cc: Users of ISC DHCP <dhcp-users@lists.isc.org>
Subject: Re: Failure of dhcp server failover
Message-ID: <572791d3.8000...@grosbein.net>
Content-Type: text/plain; charset=utf-8; format=flowed

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.


------------------------------

Message: 4
Date: Mon, 2 May 2016 18:57:23 +0100
From: Simon Hobson <dh...@thehobsons.co.uk>
To: Users of ISC DHCP <dhcp-users@lists.isc.org>
Subject: Re: Failure of dhcp server failover
Message-ID: <9cfcd2e1-1a99-4897-82ac-834d7c61b...@thehobsons.co.uk>
Content-Type: text/plain; charset=us-ascii

Eugene Grosbein <eu...@grosbein.net> 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 <eu...@grosbein.net> 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.



------------------------------

Message: 5
Date: Mon, 02 May 2016 19:00:46 +0100
From: "Niall O'Reilly" <niall.orei...@ucd.ie>
To: "Eugene Grosbein" <eu...@grosbein.net>
Cc: Users of ISC DHCP <dhcp-users@lists.isc.org>
Subject: Re: Failure of dhcp server failover
Message-ID: <42b28ae9-9037-4f18-814f-647f041bf...@ucd.ie>
Content-Type: text/plain; charset=utf-8; format=flowed

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


------------------------------

Message: 6
Date: Tue, 3 May 2016 02:19:44 +0700
From: Eugene Grosbein <eu...@grosbein.net>
To: Users of ISC DHCP <dhcp-users@lists.isc.org>
Subject: Re: Failure of dhcp server failover
Message-ID: <5727a850.7080...@grosbein.net>
Content-Type: text/plain; charset=UTF-8; format=flowed

03.05.2016 0:57, Simon Hobson ?????:

> Eugene Grosbein <eu...@grosbein.net> 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.



------------------------------

Message: 7
Date: Tue, 3 May 2016 02:22:06 +0700
From: Eugene Grosbein <eu...@grosbein.net>
To: "Niall O'Reilly" <niall.orei...@ucd.ie>
Cc: Users of ISC DHCP <dhcp-users@lists.isc.org>
Subject: Re: Failure of dhcp server failover
Message-ID: <5727a8de.8040...@grosbein.net>
Content-Type: text/plain; charset=utf-8; format=flowed

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?



------------------------------

Message: 8
Date: Mon, 2 May 2016 20:44:48 +0100
From: Simon Hobson <dh...@thehobsons.co.uk>
To: Users of ISC DHCP <dhcp-users@lists.isc.org>
Subject: Re: Failure of dhcp server failover
Message-ID: <be3bbc47-66b9-4369-aba1-095dd8832...@thehobsons.co.uk>
Content-Type: text/plain; charset=us-ascii

Eugene Grosbein <eu...@grosbein.net> wrote:

> 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.

That's good enough reason for me - and yes, it's one of those "niggles" with 
Ubiquiti stuff.

> Can you provide any references to standards
> or DHCP server documentation for restrictions on GI-Addr?

Try RFC2131 https://www.ietf.org/rfc/rfc2131.txt - section 4.3.1 for example :
> the address is selected based on ... or on the address of the relay agent 
> that forwarded the message ('giaddr' when not 0)



>> 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.

Ah, so what you are saying is that your VLANs are simply part of a bigger 
network, much like plugging multiple switches into each other to make one big 
network. It might have helped if you had described your network at the start, 
so people wouldn't be working on the assumption that it was a "normal" network.

You seem to have gone out of your way to make a complicated network - is there 
any fundamental reason behind this ?
But regardless of that, I see a way around it ...

> 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.

Wel it is well known that very small address ranges "do not work well" in 
failover situations. It's hard to balance free leases between two servers when 
there is only one lease !

Since each device-address mapping is mapping a single entity to a single 
address, I don't see what failover brings to the party other than problems. You 
could simply define the same (non-failover) single address pool on both servers 
and it'll work fine. On initial setup, the client will get two identical offers 
- one from each server - but after that it will simply renew with the server it 
accepted an offer from. If that server goes down, the other server will be able 
to give it the same address without having to involve failover.



------------------------------

_______________________________________________
dhcp-users mailing list
dhcp-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/dhcp-users

End of dhcp-users Digest, Vol 91, Issue 4
*****************************************

Reply via email to