I have been working a lot with the Dell N-series over last few years, and now the N2248-ON which can run OS10 as well as the default OS6. We upgraded firmware to the latest 220.127.116.11 and all seemed to go well. Somehow it did not and hosed both primary/secondary firmware. The device was boot looping – the only option was to drop into ONIE Recovery and re-install the firmware. Here are the steps I used:
The ONIE recovery area runs a version of Linux. First check out your NIC to make sure it finds it:
Perfect! My laptop is 192.168.1.99 – and connected directly to the out of band MGMT port.
Next we will TFTP the file up. This file is located in the software archive you download from Dell – Its located in the “Otherfiles” folder. In this case the file name is onie-installer-x86_64-dellemc_n22xx_18.104.22.168. Next I put this on my TFTP server and we can start the install.
First lets turn off the ONIE-Discovery attempts with the onie-stop command.
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
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 :
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
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
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.
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.
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 22.214.171.124/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 126.96.36.199 address-family ipv4 ip route 0.0.0.0/0 188.8.131.52 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 184.108.40.206/30
interface ve 300 vrf forwarding INTERNET-VRF – This is the command to associate the VE to the VRF ip address 220.127.116.11/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 18.104.22.168 ve 400 1/1 S 21h4m 2 22.214.171.124/30 DIRECT ve 300 0/0 D 20h57m 3 126.96.36.199/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 188.8.131.52 Sending 1, 16-byte ICMP Echo to 184.108.40.206, timeout 5000 msec, TTL 64 Type Control-c to abort Reply from 220.127.116.11 : bytes=16 time=1ms TTL=122 Success rate is 100 percent (1/1), round-trip min/avg/max=1/1/1 ms.
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.
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:
Dec 20 19:41:27:C:System: PoE: Power disabled on port 1/1/19 because of PD overload. Dec 20 19:41:27:C:System: PoE: Power disabled on port 1/1/19 because of PD overload.
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:
interface ethernet 1/1/19 inline power power-by-class 4
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.