Header Only - DO NOT REMOVE - Extreme Networks

Create a script that will automatically toggle POE on a port if an AP goes down


One of the first things we try to do if an AP goes down in the controller is to find where that AP is and toggle POE.

It would be neat to have a script in netsight that would automatically do this to a port if it detects that an AP went down.

11 replies

Userlevel 5
Hello Byron,

you can achieve that if you have NAC in place. This is the rough structure for the program:

  1. Alarm Manager detects the if a AP goes down and start the program with the AP info (name, ip, ...) from alam manager.
  2. The program use the AP info to ask the NAC (via Rest-API) for the switch and port
  3. The program connects to the switch and do an port disable/enable
I think the new XMC workflow can help if you want do to that with more single steps not in one program.

Best regards
Stephan
SH wrote:

Hello Byron,

you can achieve that if you have NAC in place. This is the rough structure for the program:

  1. Alarm Manager detects the if a AP goes down and start the program with the AP info (name, ip, ...) from alam manager.
  2. The program use the AP info to ask the NAC (via Rest-API) for the switch and port
  3. The program connects to the switch and do an port disable/enable
I think the new XMC workflow can help if you want do to that with more single steps not in one program.

Best regards
Stephan

Where does the nac have info on where an AP is physically plugged into on a switch?

I've only ever seen the NAC report that that an AP is connected to the Wireless controller as a switch.
Userlevel 4
SH wrote:

Hello Byron,

you can achieve that if you have NAC in place. This is the rough structure for the program:

  1. Alarm Manager detects the if a AP goes down and start the program with the AP info (name, ip, ...) from alam manager.
  2. The program use the AP info to ask the NAC (via Rest-API) for the switch and port
  3. The program connects to the switch and do an port disable/enable
I think the new XMC workflow can help if you want do to that with more single steps not in one program.

Best regards
Stephan

Hi Byron,

You have to authenticate your AP for that and NAC will get the AP location like it does for PC end-systems, ie. from a switch perspective.

Regards,
Tomasz
SH wrote:

Hello Byron,

you can achieve that if you have NAC in place. This is the rough structure for the program:

  1. Alarm Manager detects the if a AP goes down and start the program with the AP info (name, ip, ...) from alam manager.
  2. The program use the AP info to ask the NAC (via Rest-API) for the switch and port
  3. The program connects to the switch and do an port disable/enable
I think the new XMC workflow can help if you want do to that with more single steps not in one program.

Best regards
Stephan

Sorry, but how do you authenticate an AP to the NAC? This would be great if in Netsight would show where an AP is physically plugged into from the end systems tab, rather than having to look it up by mac address in compass.
Userlevel 7
SH wrote:

Hello Byron,

you can achieve that if you have NAC in place. This is the rough structure for the program:

  1. Alarm Manager detects the if a AP goes down and start the program with the AP info (name, ip, ...) from alam manager.
  2. The program use the AP info to ask the NAC (via Rest-API) for the switch and port
  3. The program connects to the switch and do an port disable/enable
I think the new XMC workflow can help if you want do to that with more single steps not in one program.

Best regards
Stephan

e.g. I've enabled MAC based auth on the switch port with a allow all rule = in that case it's just to feed the information to the NAC.

That allows me to see the whole link (device-AP-switch) if I do a search for a device...

=
SH wrote:

Hello Byron,

you can achieve that if you have NAC in place. This is the rough structure for the program:

  1. Alarm Manager detects the if a AP goes down and start the program with the AP info (name, ip, ...) from alam manager.
  2. The program use the AP info to ask the NAC (via Rest-API) for the switch and port
  3. The program connects to the switch and do an port disable/enable
I think the new XMC workflow can help if you want do to that with more single steps not in one program.

Best regards
Stephan

That is awesome!
Can you do MAC based auth per switch port? Say we had 500 AP's, would that use up 500 more end user licences in the NAC? If we had to pull in all the switches and on all ports just to feed the NAC we would be way over the end system capacity license. Unless there is some audit mode that can be used that wouldn't count against the licenses
Userlevel 7
SH wrote:

Hello Byron,

you can achieve that if you have NAC in place. This is the rough structure for the program:

  1. Alarm Manager detects the if a AP goes down and start the program with the AP info (name, ip, ...) from alam manager.
  2. The program use the AP info to ask the NAC (via Rest-API) for the switch and port
  3. The program connects to the switch and do an port disable/enable
I think the new XMC workflow can help if you want do to that with more single steps not in one program.

Best regards
Stephan

Yes you'd enable it per port.

Here a sample config for a EXOS switch....

https://gtacknowledge.extremenetworks.com/articles/How_To/How-to-configure-Mac-based-Netlogin-with-R...
SH wrote:

Hello Byron,

you can achieve that if you have NAC in place. This is the rough structure for the program:

  1. Alarm Manager detects the if a AP goes down and start the program with the AP info (name, ip, ...) from alam manager.
  2. The program use the AP info to ask the NAC (via Rest-API) for the switch and port
  3. The program connects to the switch and do an port disable/enable
I think the new XMC workflow can help if you want do to that with more single steps not in one program.

Best regards
Stephan

I'm looking at that screenshot closer, it shows what switch the AP is plugged into but it still doesn't show what port its in. Unless its on a different tab or screen.
Userlevel 5
SH wrote:

Hello Byron,

you can achieve that if you have NAC in place. This is the rough structure for the program:

  1. Alarm Manager detects the if a AP goes down and start the program with the AP info (name, ip, ...) from alam manager.
  2. The program use the AP info to ask the NAC (via Rest-API) for the switch and port
  3. The program connects to the switch and do an port disable/enable
I think the new XMC workflow can help if you want do to that with more single steps not in one program.

Best regards
Stephan

Hello Byron,

there are different views to see the switch port. Here is one:



and here is another one (and there are much more)

Userlevel 5
SH wrote:

Hello Byron,

you can achieve that if you have NAC in place. This is the rough structure for the program:

  1. Alarm Manager detects the if a AP goes down and start the program with the AP info (name, ip, ...) from alam manager.
  2. The program use the AP info to ask the NAC (via Rest-API) for the switch and port
  3. The program connects to the switch and do an port disable/enable
I think the new XMC workflow can help if you want do to that with more single steps not in one program.

Best regards
Stephan

If you use MAC-Auth for the APs, the AP is like a Client for the NAC-GW. Therefore you need a End-System license each system. If you have 500 APs you need 500 licenses, yes. Nevertheless if you use MAC-Auth or 802.1x.

The license counter works during a 24 hour period. Means all authentication requests from different devices over 24 hours are added together. You need no license per switch port or AP.

If you have 500 APs and 200 Laptops and all devices authenticate during 24 hours you need 700 End-System licenses.

Best regards
Stephan
Userlevel 2
SH wrote:

Hello Byron,

you can achieve that if you have NAC in place. This is the rough structure for the program:

  1. Alarm Manager detects the if a AP goes down and start the program with the AP info (name, ip, ...) from alam manager.
  2. The program use the AP info to ask the NAC (via Rest-API) for the switch and port
  3. The program connects to the switch and do an port disable/enable
I think the new XMC workflow can help if you want do to that with more single steps not in one program.

Best regards
Stephan

I don't have Extreme Access Points and I had a similar issue with my Aerohive Access Points. I found that they would go offline but still show power draw on the Extreme switch ( zombie mode I called it ).

In the Aerohive management system, I had LLDP data for the Access Point giving me the switch MAC and port for the switch the Access Point was connected to.

I wrote a script that did the following:

  • Connect via REST API to may wireless management system to get a list of potential "zombie" access points.
  • Connect to Extreme Management Center via XML API to get a list of all switches
  • Resolve the switch MAC in the the Access Point data to a switch IP address by building a MAC keyed table of my switches
  • Connect to the switch and interrogate the port state ( basically is current being drawn )
  • Toggle PoE on the switch port
  • Wait for five minutes to see if I can detect that the AP is now up ( its MAC visible on the port with "show fdb port xx" command )
I could share the code if anybody wanted to use it as the basis for a similar script. The Extreme elements would be reusable and the Aerohive stuff would show a template for implementing on another Wireless system.

Reply