Wireless bridge between two C9124AXE

[B A]

Hello all,

we recently received 2x Cisco C9124AXE and we need to use them for a point-to-point wireless bridge between two buildings as shown in the image. How can we configure them? They are brand new, I didn't convert them to any mode or EWC... I am just asking for the correct steps. I would be glad for any suggestions. C9124AXE firmware version: 17.6.2.43

We have only these two APs and don't have a C9800 controller so we plan to convert one C9124 to EWC. This is our idea:

1. Convert C9124_A to EWC
2. Join C9124_B to this C9124_A EWC
3. Configure mesh according to documentation
4. Switch C9124_B to Flex+Bridge mode
5. Switch C9124_A to Flex+Bridge mode. But this C9124_A is EWC at the same time. Will this work? Or do I need a third device - C9800 WLC or AP that will server as EWC?

Or do you have any other suggestions on how to make it work?

Thank you!

[B A]

...

[B A]

Thank you! Where can I configure it? 

[S. K.]

Hi B A,

Could you solve the issue? I'm right now at the same point with my 2 x 9124. In Version 17.6.6 it was not possible to change the AP mode, then I did the upgrade to 17.9.4 which solved the issue.

Which documentation did you use for the mesh config on the EWC?

Greetings

[cmcclinton]

Hi BA and SK

Did you get your 9124s works as Mesh Bridge?
I have also tried to set this up and had quite a few frustrating problems, but I did get it working in the end.

Definitely had the problem of not being able to select set the mode to Flex+Bridge as mentioned above in version 17.9.4 this works as expected.

My other tips would be to only work on the base eWLC 9124 and get that working as a RAP first before plugging in the MAP as there are a number of reboots required and with both 9124 connected to the same switch the intended MAP was being converted to an eWLC and becoming the controller when the RAP and eWLC where rebooting.

So start with just the one 9124 use the wizard to get initial WLC up and running, add the MAC addresses and AAA authentication and authorization and Mesh profile up as per the guides. (or if this is purely a two AP bridge just use the default profiles and edit the default AP join profile to support Mesh).

Once the eWLC has rebooted confirm that the RAP mesh config has taken the mode and role etc.
Look under Monitoring/Mesh and it should confirm 1 RAP and 1 sector is up and running.
The fact that eWLC is running on the RAP and mode chnages require a reboot does mean that the config can look OK but things arent running yet until the host AP reboots.

Next plug the intended MAP into the same switch as the RAP so it can register as a normal AP and begin the conversion by changing the mode to Flex+Bridge and setting the role as Mesh. If you save the config at this point the AP should reboot to take on the mode change. Good idea to have a console cable connected so you can see where it is in the process.

Keep it connected to the same network as the RAP and let it register again.
Then again under the AP Mesh tab configure the mode to trunk, set the native VLAN to the VLAN back on the RAP side of the network that you want to manage the AP from. Then configured the allowed VLANs that you want to pass from the MAP side switch to the RAP side switch.

Save the config again and you should be ready to move the MAP AP to the remote switch.
Let it boot and it under Monitoring/Mesh you should see it as a child of the RAP and have 1 RAP and 1 MAP.

[S. K.]

Hi CMC....

Thanks a lot for your explanation.

I got it only working in version 17.9.4 with the most deafault config --> default AP join profile to support Mesh

I took the config if someone needs a proper default config.

BR

S.K.

[Paul Hanton]

I had a problem with 17.9.4 - after a reboot traffic would stop passing over the bridge unless I turned VLAN Transparent off and on again. Which isn't ideal  for a Live build.

[Paul Hanton]

For anyone having issues with this I had a problem with the AP's talking to each other.

changing the macs from delimited to just 1 string fixed the link for me (apparently there's a bug n I don't think its fixed)

efwq.efew.ewfq to efwqefewewfq

username efwqefewewfq mac description MeshAP-RootAP
username efwtefewewft mac description MeshAP-MAP

Edit:

Day 0 cli does give you the option to use either sting or delimited with commas (DON'T use commas)

[Rich R]

That's not a bug it's by design - MAC usernames must always be entered in lower case, without any separators.

https://bst.cloudapps.cisco.com/bugsearch/bug/CSCvr07920
Use only the format without separators which is the only one that will work for MAC authentication as of 17.3

https://www.cisco.com/c/en/us/td/docs/wireless/controller/9800/17-9/config-guide/b_wl_17_9_cg/m_mab_auth_bypass.html

Note	The mac-address must be in the following format: abcdabcdabcd

[Paul Hanton]

Is a Bug and not by design > Mesh Guide states

Important: As of 17.3.1 release, if any mac address delimiters like '.', ':' or '-' are added, the AP is not able to join. There are currently 2 enhancements opened for this: Cisco bug ID CSCvv43870 

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

Symptom: Username config for local mac authentication or ap authorization is working only using format "AABBCCDDEEF" however it is possible to configure following different formats AABBCCDDEEFF/AABB.CCDD.EEFF/AA-BB-CC-DD-EE-FF/AA:BB:CC:DD:EE:FF Conditions: local mac auth or ap authorization Workaround: Use format "AABBCCDDEEF"

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

and Cisco bug ID CSCvr07920. In the future, 9800 accepts all mac address formats.

[Rich R]

Sorry what's your point @Paul Hanton ?

CSCvv43870 is dup'd to CSCvr07920 so CSCvr07920 is the "definitive" ddts (bug) for the issue.
CSCvr07920 is still Open and clearly states that the workaround is "Use only the format without separators which is the only one that will work for MAC authentication as of 17.3" which suggests that the developers have no intention of changing the behaviour.  And this is further supported by the 17.9 documentation which also states "The mac-address must be in the following format: abcdabcdabcd"  That's still there in the 17.13 docs so unlikely to change.  More likely that CSCvr07920  will eventually be terminated.

So while it is undoubtedly a mess (Cisco has never achieved much consistency with MAC address formats so hardly a surprise) it seems the solution to this was to settle on abcdabcdabcd as the correct format.

ps: I've told our own software developers to always normalise any stored MAC format precisely to avoid any of these types of problems so our internal tools take any format provided and normalise to lower case with no separators.  Quite why this has never become standard/best practice for Cisco's software developers who've been writing code for networks for upwards of 30 years eludes me.  Cisco's own code uses just about every possible different format you can think of for representing MAC addresses!

[Paul Hanton]

Point is that one string is 'currently' the correct format but only using one string is a documented workaround. It was never intended that it was to be the only format that worked and there is documentation out there that may tell you multiple formats will work as some of these guides are pre 17.3 and will not have been updated, so its an issue to be aware of when configuring and taking your information from multiple sources. I'm also think CLI Auto config Wizard may tell you you can use multiple formats... but I don't want to wipe an AP to verify at this point..

[Rich R]

Ha ha that wouldn't surprise me at all - like I say Cisco do not have a good track record on this.