Wireless Access

Hello,

In ArubaOS 6.4.2.x, the 'gre-striping-ip' system profile setting has been removed and replaced with a global 'ap-lacp-striping-ip' table which must be manually synchronised across all controllers.

It appears the new feature has a global 'enable' setting which I assume means: if the AP supports LACP (e.g. an AP-225) and the LMS IP is one of the ones in the list, then supply the GRE striping address from the table.

If this is the case, this behaves slightly differently from the old method, where individual APs could be enabled with LACP by assigning them different system profiles.  Am I right in thinking that the only way of stopping LACP, once enabled, is to set up a distinct LMS IP for those that need LACP (and will be listed in the striping table) and those that don't.  If I'm wrong, can someone please explain how it works?

Following on from that, we have clashes under 6.3.x.x between wired ports and GRE striping: if an AP group has a system profile with GRE striping enabled, we can't assign a wired port profile.  And vice-versa.  This makes sense.

However, on a test 6.4.2.x system I have, I have tried setting a system profile with an LMS IP that is listed in the [enabled] striping IP table and then have been able to assign a wired port profile to a group using that system profile.  This would not have been possible under the old system.  Presumably the two settings can't work together, so how will the system behave in this situation?  Will it disable LACP if the wired port profile is configured, or ignore the wired port profile because LACP is enabled?

[I could test this, but it's quite tedious to do all this and, given that 6.4 hasn't gone GA yet, it could be either broken or subject to change.]

Thanks in advance,

  - Bob

Hello,

did you test this in mean time? I am in the same situation now

Kind regards,

I did test it at the time and found the behaviour to be rather odd (or maybe "broken"!)...

Setting the wired port profile for eth1 and then connecting the AP to a pair of LACP-configured ports (on eth0 and eth1) caused eth1's wired port profile to be ignored and it to be used as part of the LACP group.

However, once the AP was up, if I reconfigured eth1 then it would take effect and cause the port to drop out of LACP.  I would say that this should not be allowed.  I don't know if there are any other odd situations where eth1 should suddenly break like this.

I did log a call with Aruba Support at the time and they advised me not to do that and, instead, leave eth1 unconfigured.  As such, we arrange that an AP group profile with an eth1 wired port profile configured is never applied to an AP model which supports LACP - this works for us as we normally only configure eth1 on either H (hospitality - 93H, 103H, etc.) models and these tend to go in a special group.

This makes sense as the two settings are conflicting but works fine for us - it would just be nicer if the software prevented you from getting in this muddle.

Note, also, the problem a colleague found with PoE being supplied to E1 - we document this here:

http://www.ucs.cam.ac.uk/network/infoinstitutions/wireless/wireless-support-networking#wired-aggregation

... we've spent a long time discussing this with Aruba Support and they advise us it's a chipset issue that can't be resolved.  Basically, the AP can take power through E0 or E1 but, if it takes it from E1 there is a bug which means the LLDP-MED negotiation to upgrade the power from 15.4W to 30W (PoE to PoE+) takes place over E0 regardless and the switch refuses that, if power is not being taken over E0 (the switch says "you can't have that - I've not even giving you PoE over that port").

We advise (on the above web page) people to disable PoE on the port connected to E1 to resolve the issue.

Hope all that helps!

I thought I'd update this thread further as things seem to have changed again, making what we previously did no longer work...

We noticed a problem when trying to add another controller (with associated VRRP LMS and LACP striping addresses) and hit an error we'd never seen before.  We're running 6.4.3.7 so I suspect this has come in at some point in 6.4.3.x, but I can't find when in the Release notes.

Anyway -- it seems Aruba have decided to prevent the potential conflict between a wired-port-profile being assigned to ENET1 and LACP being enabled through the striping table.  Previously we could configure both and just had to ensure they didn't both get used at the same time: typically by not putting an LACP-capable AP in a group with an enet1-port-profile configured.  This no longer works and we get an error, e.g.:

(binevenagh) (config) #ap-group TEST-E1 

(binevenagh) (AP group "TEST-E1") #ap-system-profile nms_sys

(binevenagh) (AP group "TEST-E1") #enet1-port-profile shutdown

Error: Enet1 1 is shutdown or wired-ap-enbale is set in wired-ap profile. You cannot use the LACP with the lms-ip in System Profile.

nms_sys specifies an LMS IP address which is listed in the LACP striping table:

(binevenagh) #show ap system-profile nms_sys | include "LMS IP"

LMS IP                                  192.0.2.42

...

(binevenagh) #show ap-lacp-striping-ip | include 192.0.2.42

GRE Striping IP     192.0.2.43 LMS 192.0.2.42

The workaround (or fix, depending on your parlance) to this is to use an LMS address for APs (and groups) where you want to configure an enet1-port-profile which is NOT listed in the LACP striping table.  We've done this by creating another system-profile that uses the striping address (the LMS IP address +1) and using that for groups where enet1-port-profile is configured - for example:

(binevenagh) (config) #ap system-profile nms-wired_sys

(binevenagh) (AP system profile "nms-wired_sys") #clone nms_sys

(binevenagh) (AP system profile "nms-wired_sys") #lms-ip 192.0.2.43

(binevenagh) (config) #ap-group TEST-E1

(binevenagh) (AP group "TEST-E1") #ap-system-profile nms-wired_sys

(binevenagh) (AP group "TEST-E1") #enet1-port-profile shutdown

(binevenagh) (AP group "TEST-E1") #

This seems to work fine: we use more LACP-connected APs than ones with wired-port-profiles and we always put the latter in special groups anyway.

There are some gotchas:

The first is that the check against this conflict is only performed where the controller has an LACP striping table.  In our case, we have a Master and Standby Master that don't terminate any APs, so there was never any reason to install the table on them; they weren't checking for this problem but pushing conflicting configurations to the Locals.  Which brings us to gotcha number two...

The other thing is that you can't modify the LACP striping table if there are ANY conflicts between these settings: in our case, we were trying to remove an errant entry from the striping table on a Local where the LMS address wasn't even in use, but the check was preventing us from doing that because another entry conflicted.  We had to first locate all of the problems in the configuration on the Master and fix those.  That brings us to gotcha number three...

The above illustration of the problem is very clearly caused by setting enet1-port-profile to "shutdown" but, if you have a configuration which contains a conflict that is reported only when you're trying to modify the striping table, you'll get the same error which may or may not be particularly helpful: if it's caused by a wired-port-profile with a name, you'll get told what that name is, so you have a good chance of guessing the group that needs fixing (you can always use "show references ap wired-ap-profile ..." anyway).  If, however, the port is "shutdown" then you won't be told anything else (such as the group name) other than there's a shutdown port conflicting -- you then have to scan through the whole configuration, trying to locate it.  To do this, I found "show running-config", then using "/enet1" to search for "enet1" lines, checking the system profile was the new "xxx-wired" one and, if not, using "u" to go up a page and locate the group name that needed fixing.

So -- the moral of this story is that it's changed again.  My top tips:

1. Put APs with enet1-port-profiles configured in separate groups from ones where LACP are used.
2. Create separate system-profiles for use with these groups.
3. These system-profiles must use an LMS address not listed in the LACP striping table: I suggest you use the striping address itself (LMS +1, typically) rather than configuring a new address.
4. Install the LACP striping table on the Master / Standby Master, even if you don't normally terminate APs there, as it'll help spot any configuration mistakes before they get pushed to Locals.

Ultimately, I think this is all a good thing and fixes the ambiguous configuration situation.  However, I think it could do with being written up in the User Guide for best practice.

I hope this helps you and have fun fixing your configurations before modiying your striping table!