Wireless Access

Hi,

Could someone help me with the above error message?

It is generating from the IP address on the secondary controller on a site for a particular client VLAN however the option DHCP82 is not enabled on the vlan so I'm not sure how to get it to stop generating as it is clogging up syslog entries.

Thanks

Are you sending DHCP to an external server, or is it being served by the controller?

It is being sent to a DHCP Server

And you have this unchecked? See image: 

Yeah sure do:

Other than checking to make sure another L3 interface in that VLAN is not also relaying, and checking the ip information / masks for the scope are correct, I would say TAC to the rescue?

I noticed this on the controller:

(WLAN-1) [MDC] #show ip dhcp relay counters

Invalid/Missing GIADDR           537

Also in the logs there is multiple entries, all of the entries are from the IP addresses of the client VLANs on the secondary controller (WLAN-2):

Is there any type of L3 GW redundancy deployed on the client VLANs?

---

@scottm wrote:

I noticed this on the controller:

 

(WLAN-1) [MDC] #show ip dhcp relay counters

Invalid/Missing GIADDR           537

 

Also in the logs there is multiple entries, all of the entries are from the IP addresses of the client VLANs on the secondary controller (WLAN-2):

 

 

 

 

 

---

There is an open bug where DHCP-Option82 is mentioned wrongly in this log.  In ArubaOS 8.7 the "DHCP-Option82" string will be removed and this will be in logged at the debug level, instead.  The log right now is correctly  indicating that the giaddr is invalid or missing, however.  The DHCP-Option82 portion can be ignored.

Is there any way to stop it from generating this one log in the meantime?

It is uploading a lot of logs to the syslog server which is cloud hosted so adding on cost (not much) but still not required.  The thing is as this is an error log if I change the logging level to below this I will miss any other warning or error messages potentially.

Thanks

Do you have a helper address configured on any interfaces?

Yeah the helper addresses are configured on the interfaces which are showing in the log but the Option82 is not enabled

Do you have a helper address configure on the interface of the backup controller, as well?  Is the interface of the controller the default gateway of the clients?  Option 82 is erroneous and will be removed from that log message.

Yeah the helpers are configured on both on all the VLANS

Yes the controller is the default gateway for the client VLANs

Hold on:

You have a backup controller that is also the default gateway for clients?

No the VRRP is created on the controllers for each client VLAN - with the VRRP address of each VLAN listed as the default gateway.  Therefor whichever controllers is the active will be the correct gateway. 

Hopefully both controller VLAN  interfaces have the same subnet mask.  What is the bogus giaddr that the controller is complaining about?

Yes they have the same subnet masks.

So for one of them, the primary controller is complaining the bogus address is the IP that is assigned to the one of the client VLANs on the secondary controller

So, how many client VLANs do you have on these controllers?  Is that the only client VLAN that it is complaining about?

On these particular controllers there is two client VLANS.  It is only complaining about that one and they are setup the same.  

I have another two controllers on another site which is complaining about both client VLANs. 

Then I have another two controllers on another site that is not complaining at all.  All set up the same and using the same firmware versions.  Strange just trying to get to the bottom of it so it stops generating the logs.

Also I noticed that this log appears in the show log errorlog - however in the configuration of the syslog events we can see, wireless, user, system, security, network, arm, ap logs to enable or disable however nothing for the errorlog - are events for this forwarded automatically ?

Thanks

OK so a bigger issue than first thought it doesn't allow clients trying to connect to get an IP address from the DHCP helper.  Then in the logs I can see it generates that error message about DHCP82 even though this isn't ticked anywhere on the controller and it is giving the interface IP as a bogus address.  I think this is something to do with having these set up in a cluster.  In the meantime i have removed the cluster and everything is working as expected and the DHCP82 messages have now disappeared.  Any ideas what I have done wrong?

You should consider opening a TAC case. 

I have one raised just waiting on response.

Just thought i would share findings here in case anyone else experienced similar issues.  Hopefully get to the bottom of it soon

Hi,

Just wanted to update this with findings.

So the topology currently of the site was:

2 x Controller connected to Switch then switch trunked to Firewall

On the 2 controllers main VLANs we had an access port.  The default gateway of the client networks was the controller (VRRP address) and the default gateway of the controller itself was the firewall.

For clustering I had excluded the 2 client VLANs as it was showing as L3 and not L2.

What we found was the DHCP requests were coming from one client to the DHCP server but then going back it could not find it's way back to the original client.  

What I found with the help of TAC was if I changed the controllers main interface to a trunk port and added the client VLANs to trusted VLANs and also changed my config on the switch to be a trunk and included these VLANs I could then set up cluster without excluding the client VLANs - this meant the controller could probe all VLANs on L2 and the DHCP packets were able to find the way to the client.  

Is there any issue with adding these client VLANs to the controllers trunk or is it ok as the default gateways of the client VLANs are still set to the VRRP address and the default gateway of the controller is our firewall?

Thanks

Scott

Why not:

- Make the client VLAN on the firewall

- Make the firewall the default gateway of the client VLAN

- Make the firewall do dhcp for that VLAN

- Allow both controllers to simply bridge traffic to the Client VLAN on the firewall

Everything else you are doing are workarounds to account for the fact that (1) the controllers are the default gateway and (2) controllers have to split the dhcp scope to provide redundancy

Controllers are really designed to just bridge traffic to an existing infrastructure.  They are not designed to be the default gateway of traffic or to route traffic.  Leverage the existing infrastructure for the client VLAN and the controllers would just simply place client traffic onto that.  You then wouldn't have to jump through all of the hoops of VRRP, routing, split scopes, excluding vlans, etc.