Overtime we forget things, especially Shared secret radius keys. This is pretty common, and I run into it a lot. For example – lets say a you setup NPS (Network Policy Server) and a Wireless controller for 802.1x auth, or a ASA doing radius authentication years ago. Some how or another that key was lost – no worries, you can get that back from the NPS server itself.
In just a few simple steps you can get that key back. So lets start by opening up NPS and then selecting “Radius Clients and Servers” and dropping down “Radius Clients”
In this example I am using a Ruckus Smartzone – lets say I forget the password. I can just right click on the client and select “Save and apply as Template.
Next we can create a new radius client by right clicking on “Radius Clients” and once the client info pops up to fill in, we will select to create it from the template, and select the template we made.
To see the *** Password, uncheck the box “Select and existing template” and then select the “Generate” Radio button – and bam! there is the PSK.
Finding what vlans are set on a switch port is a very needed thing for almost any config changes in Procurve software. This entry shows a quick way to check the vlans both tagged/untagged on a procurve. This works for all procurve I believe, but I am testing on a J9773A 2530 switch. This is a simple entry but might help someone out.
To show vlans associated with the ports the command “show vlan ports X” can be used, and to find out more info like tagged/untagged you can add the “detail” to the command to get more info. For example to get info for port 1
Show vlan ports 1
And more info:
show vlan ports 1 detail
The old Procurve switch line is very long in the tooth, but I run across them all the time. In this case its a 2520 switch that is in very bad need a of a firmware upgrade. I will detail where to go to get the firmware, and how to use TFTP to upload it. In my case, the web interface is having all kinds of java issues, and TFTP is just easier.
First lets get the software – it can be found at :
https://h10145.www1.hpe.com/support/SupportLookUp.aspx
Next, I download the firmware for the J9299A, and it seems the latest is from 2016. I download it, put it on my TFTP server which has full network connectivity to the switch.
SSH to the switch, and run these commands
If you get the error ” SFTP must be disabled before enabling tftp. ” you will need to run the “no ip ssh filetransfer” command first before enabling tftp client.
config t
no ip ssh filetransfer — This allows TFTP, if you enable this, and use SCP or SFTP then no need for TFTP
tftp client
exit
copy tftp flash 10.10.16.5 J_15_09_0028.swi primary
It will then write this to the primary flash. Next I will tell it to boot this firmware.
boot system flash primary – Now it will reboot with the latest firmware
AH-POE-Top# show ver
Image stamp:
/ws/swbuildm/J_rel_hartford_qaoff/code/build/walle(J_rel_hartford_qaoff)
Aug 23 2016 08:57:14
J.15.09.0028
1791
Boot Image: Primary
Today had a strange issue with a Zondirector 3k and thought I would share in case anyone else has the issue. For some reason all of a sudden the web interface started showing this error:
Request Error
Error logged at the server
Enable EjsErrors to see errors in the browser.
SSH, ping, and AP functionality all still worked great. First we tried to reboot the ZD, but this has no effect. Next we tried to redo the cert – and this was the fix.
First SSH into the ZD with proper user/pass
Ruckus> enable
Ruckus# config
Ruckus (config)# certificate
Ruckus (config-certificate)# restore
This will then reboot the ZD, and APs will connect back – I had a loss in AP connections (clients dropped), and then they all reconnected back.
I thought this might be helpful to share with anyone looking to quickly pull all vlans assigned to a port on a Dell S4810 switch. I think this command works in most FTOS switches.
In this example I need to get all vlans assigned to a port-channel regardless of tagged or untagged. I can always look through the config and see what ports are tagged/untagged on the vlan but this can be a real pain.
So lets see the better option. My port channel is 128. Below shows the output of the command “Show interface switchport X” .
S4810-SW1#show int switchport port 128
Codes: U – Untagged, T – Tagged
x – Dot1x untagged, X – Dot1x tagged
G – GVRP tagged, M – Trunk, H – VSN tagged
i – Internal untagged, I – Internal tagged, v – VLT untagged, V – VLT tagged
Name: Port-channel 128
Description: “Etherchannel to 6060 for internal”
802.1QTagged: Hybrid
Vlan membership:
Q Vlans
T 5,10,12,14-15,20,22,40,150,254,1337
Native VlanId: 999.
S4810-SW1#
This entry details the config for setting up and deploying VRFs on a Ruckus ICX 7250. Recently I had an issue where a client had a new ISP and that ISP gave them the Customer WAN /30 subnet, then routed their Customer LAN subnet (Public usable addresses) to their side of the /30. The customer did not want any extra equipment installed like a router to handle the WAN routing, so the next best thing was to split the Ruckus 7250 switch into a WAN/LAN router – One switch to rule them all! The VRF feature is in Ruckus’s Layer 3 Premium feature set so a license will be needed. In this scenario the 7250 is the local gateway for all Vlans – so local LAN routing, and the Internet router.
Of course there are a lot of problems with the following design, like single point of failure, but its a small site, with 1 48 port switch, Fortigate firewall and cloud Voip SD-WAN router. The purpose of this design is to allow the Voip SD-WAN solution to be outside the firewall, so using the 7250 for both LAN/WAN routing really and it worked well. If the ISP would have not required a customer routing device we would have just setup a Internet-Vlan, set Fortigate/INSpeed to public IPs, and placed them in that vlan. But, the ISP is requiring a routing device in this instance.
Here is the design.
Config:
I think the ICX series supported VRFs when it was running Brocade firmware, but I would recommend upgrading to Ruckus’s ICX firmware – Version number SPR08080 or greater. Of course the device has to be running the Routing firmware not the switching code. The VRF feature is in Ruckus’s Layer 3 Premium feature set so a license will be needed.
First lets enable the VRF, and increase the amount of routes.
system-max ip-route-default-vrf 9000
system-max ip-route-vrf 500
system-max ip6-route-vrf 500
These commands will enable the VRF functionality and it will need you to reboot.
Next we can start configuring our VRF. In this case my /30 will be 1.1.1.0/29 – so .1 will be the ISP, .2 will be us. I will setup the routes for the VRF, and then the Vlan interface and apply the /30. There is a keyword in the VE config to make sure its associated to a given VRF. Within the VRF config you need to specifcy the Route Identifier – only matters locally.
vrf INTERNET-VRF
rd 11:11
ip router-id 12.5.110.2
address-family ipv4
ip route 0.0.0.0/0 12.5.110.1
exit-address-family
exit-vrf
vlan 300 name INTERNET-VRF by port — My WAN Vlan for Fortigate WAN and SD-WAN router WAN interface. The Customer LAN Subnet goes here.
untagged ethe 1/1/19 ethe 2/1/23
router-interface ve 300
spanning-tree 802-1w
spanning-tree 802-1w priority 4094
!
vlan 400 name ISP-VRF by port — /30 ISP network
untagged ethe 1/1/24
router-interface ve 400
!
interface ve 400
vrf forwarding ISP-VRF – This is the command to associate the VE to the VRF
ip address 12.5.110.2/30
interface ve 300
vrf forwarding INTERNET-VRF – This is the command to associate the VE to the VRF
ip address 1.1.1.2/29
Here is a subset of my user config – Vlan 40 – this is where most of the desktops go, and the gateway in this case 10.6.40.1/24 lives on the switch, on the default VRF.
vlan 40 name Computers by port
untagged ethe 1/1/1 to 1/1/18 ethe 1/1/21 ethe 2/1/1 to 2/1/18 ethe 2/1/22
router-interface ve 40
spanning-tree 802-1w
spanning-tree 802-1w priority 4094
!
!
show run int ve 40
interface ve 40
ip address 10.6.40.1 255.255.252.0
ip helper-address 1 10.6.10.10
Thats it! A show IP route of the default VRF (Switching VRF) shows:
#show ip route
Total number of IP routes: 9
Type Codes – B:BGP D:Connected O:OSPF R:RIP S:Static; Cost – Dist/Metric
BGP Codes – i:iBGP e:eBGP
OSPF Codes – i:Inter Area 1:External Type 1 2:External Type 2
Destination Gateway Port Cost Type Upti me
1 0.0.0.0/0 10.6.254.2 ve 254 1/1 S 1d17 h — This is the Fortigate
2 10.6.0.0/22 DIRECT ve 1 0/0 D 1d17 h
3 10.6.10.0/24 DIRECT ve 10 0/0 D 21h4 m
4 10.6.40.0/22 DIRECT ve 40 0/0 D 1d17 h
5 10.6.100.0/24 DIRECT ve 100 0/0 D 1d18 h
6 10.6.254.0/24 DIRECT ve 254 0/0 D 1d17 h
7 172.16.6.0/29 DIRECT ve 650 0/0 D 1m5s
8 192.168.6.0/24 DIRECT ve 1 0/0 D 1d17 h
9 192.168.100.0/24 172.16.6.1 ve 650 1/1 S 1m4s
But, if we specifcally show the Internet-VRF routes:
#show ip route vrf INTERNET-VRF
Total number of IP routes: 3
Type Codes – B:BGP D:Connected O:OSPF R:RIP S:Static; Cost – Dist/Metric
BGP Codes – i:iBGP e:eBGP
OSPF Codes – i:Inter Area 1:External Type 1 2:External Type 2
Destination Gateway Port Cost Type Uptime
1 0.0.0.0/0 12.116.193.1 ve 400 1/1 S 21h4m
2 12.5.110.0/30 DIRECT ve 300 0/0 D 20h57m
3 1.1.1.0/29 DIRECT ve 400 0/0 D 21h5m
And there we have it, the devices is now in two VRFs, a default and INTERNET-VRF with specific interfaces assigned to it. If you want to test pinging from that VRF specifically you can use the following commands:
#ping vrf INTERNET-VRF 8.8.8.8
Sending 1, 16-byte ICMP Echo to 8.8.8.8, timeout 5000 msec, TTL 64
Type Control-c to abort
Reply from 8.8.8.8 : bytes=16 time=1ms TTL=122
Success rate is 100 percent (1/1), round-trip min/avg/max=1/1/1 ms.
These commands should be all that is needed to setup Sflow on OS10. In this example these commands used to setup Sflow on a Dell S4128F-ON running 10.4.2.0.226. I am using PRTG as a collector.
config t
sflow enable
sflow sample-rate 4096
sflow source-interface vlan5
sflow collector 10.10.5.152 agent-addr 10.10.5.246 2050
PRTG IP is 10.10.5.152 – my switch Vlan 5 IP is 10.10.5.246.
Then you have to specify the physical interfaces you want to send Sflow traffic.
config t
int eth 1/1/1
sflow enable
That should get flows going. You can confirm that by running the following command:
S4128-1# show sflow
sFlow services are enabled
Management Interface sFlow services are disabled
Global default sampling rate: 4096
Global default counter polling interval: 30
Global default extended maximum header size: 128 bytes
Global extended information enabled: none
1 collector(s) configured
Collector IP addr:10.10.5.152 Agent IP addr:10.10.5.246 UDP port:2050 VRF:Defaul t
7232 UDP packets exported
0 UDP packets dropped
39259 sFlow samples collected
Currently I am working with a client who has lots of Ruckus ICX 7250 PoE+ switches. These have been great switches, lots of features such as: large PoE budget, 10G, VRF/Routing capability. Recently the client has rolled out Mitel headsets that charge from their larger handset phone stations.
Strange issue has been happening though, when they put the headset in to charge the phone reboots, and the switch throws an error (you will see below) and basically kills power to the port, thus everything reboots. After some quick analysis it seems like the phone station is requesting 802.11AF (15.4 watts max) and then when the headset gets turned on to charge it spikes above 15.4 watts for a bit, and making the switch rightly throw the error. The phone pulls somewhere around 1-3 Watts, and the headset seems to add an additional 3 (according to its documentation). Still well within range of 802.11AF.
Link to Mitel headset: https://www.mitel.com/en-us/products/devices-accessories/ip-phones-peripherals/other/integrated-dect-headset
This is an assumption, I might go through and do some debugging and see if that’s the exact issue, but adding some commands to the switch did fix the problem. So before we go through commands and analysis; the commands used to resolve the issue basically set each port to 802.11AT which allocates 30 Watts for the port. An issue with this: simple math indicates that if we have a 48 port switch with a 740 Watt PoE budget, we can only really give each port 15 watts if every port is powered up. That’s true, but luckily we aren’t going to run into that problem here. Few headsets/Power needing ports.
When the headsets were plugged in the switch started throwing these errors:
This would then disable PoE on the port for a few seconds and make the phone reboot.
When checking to see how much power the phone was pulling the following was done prior to the fix commands – Please just look at Port 19:
The phone was showing up just asking for 3.6 Watts and it was only allocating 15.4.
Lots of ways to tackle the fix to this problem, the approach I used is to modify the allocated power by class – So instead of letting the switch decide how much power to allocate by letting the device tell it – I am forcing the switch to change the power class for the phones (in this case 3 ) to 4. This allocates a default of 30 Watts. Below is Ruckus’s outline for the Power classes
The commands to modify this:
After applying these commands check Port 19 out:
All devices are still requesting pretty much the same amount of power they were before except now we see the headsets requesting power as well. Not only that but each port does have 30 Watts allocated to it. So the thought that we could run out of allocated power if we had a lot of phones/PoE devices plugged in is a real concern. Right now, even though we are only using 47.7 Watts, the switch has provisioned 390.
There are better commands to use other than the power-by-class that I used. For example, since we know the phone with charging the headset only needs little over 4 Watts we could use the command “inline power power-limit 25000” to allocate 25 Watts instead of the full 30. This number could keep being modified to find the exact number where the port drops. Or you could just modify the ports with headsets only – But, like I mentioned above we have no real need to do that, so the power-by-class blanket command works fine in this case.
After applying the above command check out port 19’s PoE allocation:
Lots of ways to fix this issue, but all modify the amount of power allocated to the port.
Recently have been working with the S4128 switches. These have been great, and the price point is amazing.
The device comes with 2 ports that can be 10/40/or 100 Gig interfaces (given media). I needed to connect the port via a 40 gig DAC to a Dell server. When I plugged this in, a “show interface eth 1/1/26” would show the interface up, show the DAC model number and then would say “Protocol down”. I thought at first this could be mismatching vlans, etc. But after a few minutes found it had to be a negotiation issue.
After some checking I found this in the config:
interface breakout 1/1/25 map 100g-1x
interface breakout 1/1/26 map 100g-1x
Interface 1/1/26 is my connection to the server. After some digging with Dell we have to modify this. I ran the following command:
interface breakout 1/1/26 map 40g-1x
After running that command a sub-interface showed up. A “Show interface status” presents the following Eth 1/1/26:1. After configuring the sub interface as needed all seemed to work great.
I will post images of interface status later.
A client recently had an issue where a security audit found ciphers supported within HTTPS that are insecure. These ciphers were TLS 1.0 and TLS 1.2. The audit found these issues on the web interface of the Smartzone, nothing to do with EAP or WiFi authentication. . After trying quite a few things I decided to open a ticket with Ruckus support. They instructed me to run the following commands on the SmartZone to disable it:
vszh-50#debug
vszh-50(debug)#
vszh-50(debug)# no tlsv1
This seemed to fix the issue. The web service (Tomcat) restarts and takes about 5 minutes before you can log back into the SMZ again.
