Wireless Access

Hello,

 

Ever since we upgraded our Aruba wireless controllers to OS 8.2 from 6.5, we have been getting complaints of IP conflicts from our wired windows users on the vlans that we tag to our controllers to (We only tag to a few wired vlans, so it's pretty obvious).  The IP listed as a conflict is 0.0.0.0 on the windows computers, and their logs point back to the MAC address of our controllers.  Is this a known issue, or maybe we forgot to check a box somewhere to prevent this on our controllers?

 

Controllers:

Count: 2

Model 7210

Redundancy is setup as a cluster

ArubaOS: 8.2.0.2

AP count: 400~ with a mix of 325s and 225s

 

Computers:

 

Windows 7 64Bit

 

Thanks

 

Having the exact same issue I've just opened a TAC case with Aruba. Will let you know if I learn something.

I'm curious... Do either of you have the controller IP address on the same VLAN that the users are connected to? Thanks, Tim

No, the controller address is in VLAN 3660 and the conflict appeared in VLAN 1160. The controller does NOT have any address in VLAN 1160 :)

 

Just wondering, can the problem be the same as one described here?

https://www.cisco.com/c/en/us/support/docs/ios-nx-os-software/8021x/116529-problemsolution-product-00.html

Yes, I had IP addresses assigned to the VLANs.  Currently I have the VLANS untagged because of the issue.

 

One thing to note, we are running wired Dot1X on our access switches.

I got it solved. The problem is the same as described in the Cisco paper - the controllers send out arp probes from IP address 0.0.0.0 and sometimes windows machines evaluate this a an address conflict.

 

After a couple of emails with TAC I was advised to turn off openflow. Apparently when you turn it off the issues disappear - no more arp probes with IP 0.0.0.0 and I haven't got an incident with duplicate adresses for a while now.

And one more piece of information for those who want to use Openflow with AOS 8 - there should be a workaround around this in 8.3.0.0.

Hi knizmi1,

 

Did you enable openflow or was it on by default?  Running into the same issue.  Thanks in advance!

documentation says it is disabled by default:

For OpenFlow to be functional in a network, you must enable SDN Controller on the Mobility Master and OpenFlow agent on the required Managed devices. By default, OpenFlow is disabled on Mobility Master as well as the managed devices.

---

 

I don't recall ever turning it on (why would I?), but if the manual says that it is disabled by default I am not really certain anymore.

Do this in your MD that causes the arp issue, if the state is "Disabled", you are good to go:

(LAB7005) #show openflow-profile

Openflow-profile "default"
--------------------------
Parameter                        Value
---------                        -----
controller-ip                    masterip:6633
State                            Disabled
Openflow mode                    passive
Openflow version                 v1.3
Auxiliary State                  Disabled
Auxiliary Channel Port           6633
VLAN ID or range(s) of VLAN IDs  1-4094
certificate-file                 none
key-file                         none
ca-certificate-file              none
openflow tls                     Disabled

 

It looks like this bug ID 169151 is resolved in 8.3.0 that just released on Apr 29th. 

 

 

Thanks for contributing your post.  It saved me a call to the TAC.

 

My Rockwell PLC's were throwing duplicate IP address errors, and at first I thought it was the Cisco switches, but I quickly ruled the Ciscos out.  The Rockwell PLC's actually show the MAC address of the conflicting device, in the duplicate IP error message they display, so it was eay to track the problem to the Aruba Controllers.  the right search on the Airheads and I've got my solution.

I couldn't find this bug id in the release notes for 8.3.0.0 or 8.3.0.1, but does anyone know if this is fixed in 8.2.1.1? Found it in the 8.3.0.0 Release Notes (thought 8.3.0.1 had contained previous resolved versions for 8.3.0.0 as well. I can't seem to find any reference to Bug 169151 in the 8.2.X.X code path. We just ran into this problem a couple weeks ago. OpenFlow is enabled for AirGroup Centralized Mode. Concerning though that during the time we hit this IP Address conflict, we were on 8.3.0.0 already at that time, but have since downgraded to 8.2.1.1. Will have to investigate further.

Aruba TAC informed me that Bug ID 169151 is not fixed in the 8.2.x.x iterations currently. Currently working with them further as we downgraded to 8.2.1.1 (Conservative Release) per recommendation from TAC for another issue to get this patched in 8.2.X.X - as we were running into issues with AirGroup (Centralized/Distributed Mode) in 8.3.0.1.

Unfortunately it appears the fix missed the PR cut-off date for 8.2.2.1 release. I couldn't get any more details beyond that for 8.2.X.X - possibly it will be patched in the next code-version after 8.2.2.1 for Conservative Release.

Has this issue been fixed in 8.2.2.2?  Have been waiting patiently for over 10 months...

---

@Bobberson wrote:

Has this issue been fixed in 8.2.2.2?  Have been waiting patiently for over 10 months...

---

The fix of 169151 to date has not been requested for back prop to 8.2.2.x, I'll file a request for 8.2.2.4 which is due mid January 2019 but I cannot control if it will be accepted or not as fixes in 8.2.2.x are being considered case by case now.

 

In the short term you would have to consider either disabling openflow or moving to 8.3.0.4.

 

 

---

@jgoff wrote:

---

@Bobberson wrote:

Has this issue been fixed in 8.2.2.2?  Have been waiting patiently for over 10 months...

---

The fix of 169151 to date has not been requested for back prop to 8.2.2.x, I'll file a request for 8.2.2.4 which is due mid January 2019 but I cannot control if it will be accepted or not as fixes in 8.2.2.x are being considered case by case now.

 

In the short term you would have to consider either disabling openflow or moving to 8.3.0.4.

 

 

---

Thanks jgoff for requesting it. That's very unfortunate as this defect was seen in the Conservative Relesae 8.2.X.X train and was brought up again in my TAC Case back in August. I'll have to follow-up with our reps about that.

Our Aruba representatives looked further into this for us. They've informed us that the patch will be included in the 8.2.2.4 release (they consulted with PLM and engineering). Unfortunately they're not sure why none of the TACs put in the request for back-port.

Thanks for the update, cbjohns.  We tried out 8.3.0.1 a month back and it didn't solve our problems with the IP conflicts (at least from what I coudld tell), so I have openflow and centralized turned off until this is figured out.

Our situation is the following:

 

Deployed new controllers running 8.2 in order to replace our existing controllers that are older hardware and max out at 6.4.

 

Currently running the new controllers in parallel for testing, and all of our existing AP's and users still connect to the OLD controllers running 6.4.

 

Finally caught this happening to a user and it turns out that the duplicate IP for 0.0.0.0 was claimed by the MAC Address of one of the NEW controllers (they are on the same subnet as the controllers running 6.4)

 

I don't think it's related to the issue in the Cisco doc, as we have 2 sites with a Cisco Core, and one with an Avaya Core and the same behavior happens at both.

 

Thanks,

Tim