How to configure Extreme 7522 via CLI

  • 18 October 2018
  • 13 replies
  • 2868 views

Hello,
I'm looking for a basic guide on how to configure Extreme 7522 via CLI. I need 3 SSIDs with WPA2 authentication assigned to separate VLANs. I can't find any simple guide on how to do this, the CLI reference guide doesn't help me at all, there is too much information on hundreds of pages.

So far I've created a virtual controller with static IP.

Please help!

13 replies

Hi Adam,

You should be able to find this information in the WiNG 5.9.2 Wireless Controller and Service Platform CLI Reference Guide:

https://documentation.extremenetworks.com/WiNG/5.9.2/CRG/9035491_WiNG_5_9_2_WC_CRG.pdf

Thank you,
Sree
Userlevel 5
Hello Adam,

May I ask why you'd like to do this from CLI versus GUI?
what firmware version is the AP on?
Do the VLANs you want to create on the AP already exist and are segregated on your router/switch?
Is this a new deployment?

There is no 'How to doc' that directly addresses this specific type of configuration; however the main components are as follows:

1 - Configure country code
2 - Create vlans
3 - Create wlans, configure security and map to vlans
4 - enable smart-rf and configure power and channels
5 - Map the wlans to the radios
6 - Trunk the ge1 port and map the vlans to said port

I would suggest you contact GTAC for assistance on this, or if this a new AP, the partner you purchased it from should be able to assist you as well.
Userlevel 5
Adam, I don't think there are any docs that cover quick AP setup via CLI.
Essentially though, you need to create the WLAN(s), map the WLANs to the radios, and setup the ge1 interface to include your VLANs that are assigned to the WLANs.

log in
enable
config

(Build a bare-bones WLAN)
wlan (hint: make the WLAN name the same as what you plan to use for the SSID - it will be like this by default though once you issue this command.)
show context (this will show you what you have in the WLAN so far)
encryption-type ccmp
wpa-wpa2 psk 0
vlan
commit write
exit

(Map the WLAN to a radio)
profile ap7522 interface radio 1 (This is for 2.4GHz)
wlan
interface radio 2 (This is for 5GHz)
wlan
commit write

Setup the ge1 interface (This assumes no DHCP, captive portal services running on the AP)
interface ge1
switchport mode trunk
switchport trunk allowed vlan <10,20,30, 50-100> list out the VLANs like this, as needed
commit write
end

(Define the regulatory area the APs will operate)
config
rf-domain [i]
commit write

(Give device a hostname)
self
hostname
commit write

show run
(see your config you've built)

There are a lot more options you can add at this point, but you should see the SSIDs beaconing from the AP now. (unless I missed something)
Thank you very much, Christoph and Chris, for detailed answers! You really saved me!

@Christoph, I'd love to use GUI, but the company I work for, have just bought Extreme 7522 and we have to wait 2 weeks for maintenance subscription, I have no login credentials and can't download the standard firmware, all 8 APs have LEAN version and they have to work as soon as possible. Unfortunately, I always configure them via GUI and have little experience with CLI 😞.

I stayed in a warehouse all night to make it work and without your help it would be a disaster.

I also have a problem with connecting via mint, I get a connection timeout. Do I have to set an AP as a controller to be able to connect with mint neighbours? It shows the controller as a mint neighbour but doesn't connect.

Thank you very much again!
Userlevel 5
Adam, to have the APs able to hear/talk to each other via MiNT level-1 (which is what would be occurring between APs local to each other) you just need to ensure that the connection points between APs allows Layer-2 Ethertype 0x8783 (just make sure they share the same management VLAN).
There's no need to have either an actual WiNG controller (hardware or VM) or even an AP configured as a VC (virtual controller) to make this work. These APs can operate as if their were old-school FAT-APs, completely autonomous (just means that any configurations has to be done manually on each AP, right?).
Even operating that way, as long as the MiNT mlcp vlan configuration option is enabled on the APs, they will discover and form level-1 MiNT links with each other. If you want to check this option, look at the running config. Run this command. You should see 'mint mlcp vlan' w/o a 'no' statement in front. If you see: 'no mint mlcp vlan' then that is your problem.
# show running-config include-factory |in mlcp

If it has the default settings, you should see:
mint mlcp vlan
mint mlcp ip
mint mlcp ipv6

In case you haven't already discovered it yet, you can check various MiNT connections/stats using different commands. Where I'd start first is with this one. This will confirm if an AP is able to discover the other APs via MiNT.
# show mint neighbors
If the result of this command comes up empty, then it means that the AP is not able to discover the other APs on its management VLAN. What I would do next in that case is see if you can simply PING one of those other APs (This presumes that they have an SVI configured with an IP that should be PING'able). If you can, then you have layer-3 connectivity to them. The problem then is with the layer-2 connection between them. That part, YOU will have to figure out. :)

When you say it shows the controller as a MiNT neighbor....you didn't mention until this point, but do you have an actual controller in this mix?
Thank you, Chris!
I was changing settings on my mint controller, used some guides found on the internet and changed management VLAN from 1 to 43 without changing IP (it was a part of a bigger sequence), I'm a little bit ashamed, because I wouldn't do it again from GUI (some time ago I had a problem with deleting IP from my mgmt VLAN) but from CLI it didn't worry me at all, because I thought VLAN 43 was on DHCP by default and I ended up with no connection. So I think that the part of your response with a different VLAN explains exactly what happens in my case. The question is how to set the same management VLAN safely via CLI, it would be easy in GUI, here it's a little bit harder and I want to be sure before doing some wrong changes and losing another AP 🙂. My APs work in subnet 10.104.14.65/26.

By the way, I only used a command to make it a virtual controller, when I made any changes on it they weren't propagated automatically. I think it is the last thing I need to know to have a basic idea of how to configure APs from scratch via CLI, most of it thanks to you ofc 🙂.

Thank you for your time and help! I hope that your detailed answers will help more people than just me, it's really hard to find step by step solutions on forums or even on google.
Userlevel 5
Ahh...okay. So you *are* using one of the APs as a virtual controller....(is this what you are referring to as your "MiNT controller" ?)

Regarding the mgmt VLAN - So you are using VLAN-43 as your mgmt VLAN? Untagged?

If so, then to implement a static IP address for an AP in the CLI, it would look like this:
log in
config
self
interface vlan <43?>
ip address 10.104.x.x/26
.. (yes, that is two dots - backs you out one level)
ip default gateway x.x.x.x
commit wr
show context

You would need to configure the ge1 port to properly reflect the trunk settings as well. Make sure that all of the allowed VLANs are included and specify the native VLAN (and if it's tagged or untagged)

Setting up an AP as a virtual controller takes a couple of steps too...but there SHOULD be existing documentation out there that walks you through this. As of a recent release of WiNG software, the VC capabilities have also been expanded....so if you are using new enough code, you would need/want to setup those extra new VC capabilities too.

Great, thanks! Yes, I meant virtual controller, thought about mint protocol and ended up with mint controller 🙂

Yes, VLAN 43 is LAN-Devices, not used in wireless networks, purely for device management and it's untagged on my switch port, other VLANs which are used for WLANs, are tagged on a port connected to AP and should be allowed on interface ge1. I think that this part should be set correctly. Even when there is a problem with it, it's pretty easy to figure it out 🙂. I wonder if I could just leave VLAN 1 for management with assigned static IP address when VLAN 1 is not used in my network. I think it doesn't make any difference, while 43 is untagged on APs port on the switch.

IP address 10.104.x.x/26 - it's a command, right?
Userlevel 5
Technically, you SHOULD be able to just leave VLAN-1 as your native VLAN (untagged) on the AP. It shouldn't matter what VLAN-ID it is...just the fact that it's untagged would allow it to work.

So would look like this: (actual commands are in bold)
log in
en
config
self
interface vlan 1
ip address 10.104.x.x/26 <--Yep, that's a command. Just give it the actual full IP address with the slash /26 at the end, as shown
.. (yes, that is two dots - backs you out one level out of the interface vlan1 section)
ip default gateway x.x.x.x
commit wr
show context
Ok, one last question.

I try to access the one which I cannot connect by changing native vlan to 43 on another one, connect via mint and reverse native vlan change to enable connection.

So, I did:

ap02(config-device-xx-78)#interface vlan 43
ap02(config-device-xx-78-if-vlan43)#ip address 10.104.14.80/26
ap02(config-device-xx-78-if-vlan43)#..
ap02(config-device-xx-78)#ip default gateway 10.104.14.65
^
% Invalid input detected at '^' marker.

ap02(config-device-xx-78)#commit write

And lost connection because interfaces 1 and 43 overlaped.

I connected with ap02 via mint and changed tagged vlan:

interface ge1
switchport mode trunk
switchport trunk native vlan 43
switchport trunk native tagged
switchport trunk allowed vlan 1,42-44,163

I tried to change vlan1 IP address, or to delete it, with no luck:

% Error: Commit failed for the following reason:

[device 'xx-78'][interface 'vlan1'] ap02: Interface vlan1:1.1.1.1/0 and interface vlan43:10.104.14.80/26 overlap

And I did a final, fatal mistake:

ap02(config-device-xx-78-if-vlan1)#ip address ?

A.B.C.D/M IP address (e.g. 10.0.0.1/8)
NETWORK-ALIAS Network Alias
dhcp Use DHCP Client to obtain IP address for this interface
zeroconf Use zeroconf to generate an IP address for this interface

ap02(config-device-xx-78-if-vlan1)#ip address zeroconf
ap02(config-device-xx-78-if-vlan1)#show context
interface vlan1
ip address zeroconf
ap02(config-device-xx-78-if-vlan1)#commit write
Connection closed by foreign host

Now it doesn't even appear when I use command show mint neighbors. Any chance to solve this without console cable? It appears on my router with ip 10.104.14.80 but I can't ping it.

Priority for me is to get back network traffic with those two, so I need to safely set management vlan to 43, connect and change back native vlan to 1 on both.

Getting back connection with ap02 would be harder 😞
Userlevel 5
With this AP, you set to 10.104.14.80, you then tried to enter the default gateway...which it didn't take:
ap02(config-device-xx-78)#ip default gateway 10.104.14.65
^
% Invalid input detected at '^' marker.

When you see that sort of output, it means it didn't like the command and it wasn't taken.

I'm not sure why it acted this way. From the response, it didn't seem to like that you tried to enter "default" after "ip". This should be completely valid. In any case, you entered the new static IP address for VLAN-43, but the new default gateway wasn't taken. Now the AP is trying to use whatever default gateway was already configured. I think that's the issue with being able to communicate with that AP. Your traffic is likely making it *to* the AP, but when the AP responds, its traffic is going to the wrong place and not making it back to you. (AP is sending responses to the wrong default gateway)

Then I see where VLAN-1 no longer is configured to receive DHCP. So now VLAN-1 is not usable.
I think what broke here is the default gateway setting when configuring VLAN-43. Looking back now...you should have stopped at that point and not committed the changes...but 20/20 hind-site, right?
Here's a quick handy tip: Whenever you are making changes like this and want to leave yourself a 'fail-safe', only issue the 'commit'...and not the full 'commit write'.
the 'commit' only saves changes to the running config
The 'commit write' save to running config *and* the startup config.

If you only save to the running config and things blow up, you can just power cycle the AP and when it reboots, it will load the config from the *startup config* settings...and that at least gets you back to square one.

Okay....the more I look at this, it would probably be easier to just see what the current running config looks like in its entirety. This way, I could see exactly what's going on and what needs to be changed.
If you cannot SSH into AP2 and cannot see it via MiNT, then there's no way to access it remotely. You're only means of fixing the config is going to be a local visit. Sorry.
Try to grab a copy of the running config and edit out any sections you don't want to show and post that.
We can come up with a very specific plan then for what needs to be changed to get this all working.
I don't know how and why but when I left them for a few hours I'm finally able to see both of them:

(apxx-xx) at level 1, best adjacency vlan-42
(apxx-xx) at level 1, best adjacency vlan-42

Furthermore, I can connect with them, login and make changes!!!

It's a miracle!

The part with default gateway worked for me this way:

#ip default 10.104.14.65

Anyway, the problem is finally solved! I wonder why when I do "commit write" it doesn't save some settings like hostname. There is also a command "write memory", maybe this one will work better?

Thank you Chris, for your commitment to helping me, you deserve a truck full of beer for it
Userlevel 5
Okay....so whichever AP you ran that mint neighbor query on is seeing those other 2 APs on VLAN-42 (used for the MiNT level-1 links to talk to each other). That's what you want to see (as long as VLAN-42 is your mgmt VLAN). I thought your mgmt VLAN was VLAN-43 though?

As for the default gateway config, what version of WiNG is this? Wondering if maybe an older version of WiNG maybe had a different syntax than it does not for this setting. Newest versions of WiNG, the syntax should be ip default-gateway x.x.x.x (just FYI)

In any case, if VLAN-42 *is* your mgmt VLAN, then it sounds like you're good to go...maybe just want to define the static IP address on all the APs now for VLAN-42 - not mandatory though.
In case you weren't away, even if an AP doesn't have an IP address but you can *see* the AP from another WiNG device via MiNT...you can connect to it via MiNT...instead of SSH.
From a WiNG device, enter:
# connect mint-id (must run this NOT in config mode)

you can see the mint-id of the other device by running the show mint neighbors command. It will look something like this: 4D.82.03.E0

When you connect, it will look EXACTLY like you're just SSH'ing into the AP.

Reply