Categories
Ruckus Ruckus ICX Switches

Ruckus ICX7150-C12P – Multiple Address Pools and DHCP Option 54

Note: this was tested on Software Version 08.0.61 of the ICX switch firmware.  If you are using a different release, you may want to verify my findings.


Introduction

I recently came across an interesting problem when trying to add more than one DHCP address pool to my home laboratory’s ICX 7150-C12P switch.  I wanted to add two new address pools to make attaching new x86 server hardware and Wi-Fi access points a little easier!

The rest, is history:

Setting Up Multiple Address Pools

I followed the steps to configure my DHCP address pools contained in this article and ended up with the final configuration of the new pools as follows:

ip dhcp-server enable
ip dhcp-server server-identifier 172.31.255.1
! 
ip dhcp-server pool mgmt_1
 dhcp-default-router 172.31.255.1 
 dns-server 10.0.0.254 8.8.8.8 
 excluded-address 172.31.255.1 172.31.255.99
 lease 0 6 0
 network 172.31.255.0 255.255.255.0
 deploy
!
!
ip dhcp-server pool x86_hosts
 dhcp-default-router 172.31.128.1 
 dns-server 172.31.128.1 8.8.8.8 8.8.4.4 
 excluded-address 172.31.128.1
 lease 1 0 0
 network 172.31.128.0 255.255.255.0
 deploy
!
!
ip dhcp-server pool ap-default
 dhcp-default-router 172.31.129.1 
 dns-server 172.31.129.1 
 excluded-address 172.31.129.1
 lease 0 6 0 
 network 172.31.129.0 255.255.255.0
 deploy
!

I assumed this was a perfectly simple change and that everything would work perfectly and went ahead and attached ALL THE HARDWARE!  I logged into the switch and used the command show ip dhcp-server binding and saw that the DHCP server had indeed, assigned some addresses to the newly attached hardware from my newly configured address pools.

“All is well!”  I smugly thought.  I thought wrong.

Symptom 1: Hello?  Anybody Home?

I attempted to reach the attached hardware, first by WEB UI, then by SSH, and then finally, and rather dejectedly I might add, by using a ping.  Nothing was responding.  This was very strange.  I could reach the gateway of each of my new networks, there was no special routing required to get back to me.   What on earth could it be?  The DHCP server had assigned the addresses… WTF man!?

I decided to plug my laptop into one of the switch ports and check what was going on.  Lo and behold, my laptop reported no assigned IP address.  But the Switch reported that it had in fact assigned me an address.  “The plot thickens…” I thought.

Symptom 2: Acknowledge Me!

At this point I knew that the switch had assigned the laptop an address, and I also knew that the laptop had not received one.  Something, somewhere was going missing and I needed a packet trace to actually see what was happening with the DHCP packets.  I disconnected from the switch, opened up Wireshark, set my filter to udp.port==68, started the trace, and reconnected to the switch.

This is what I saw:

Packet trace of the DHCP exchange with no DHCP Ack.

The packet capture showed up the problem pretty quickly – the switch was not sending a DHCP ACK.

Comparing with a working Address Pool

I knew that the address pool for my management network was working fine. Plugging a client device into an interface using the mgmt_1 address pool worked perfectly! So I had a look at the configuration of the switch (above), and tried to see if there was anything that was different about the DHCP server configs for 172.31.255.1/24 vs 172.31.129.1/24.  Turns out there was only one thing that seemed different:

ip dhcp-server enable
ip dhcp-server server-identifier 172.31.255.1
!

What is the Server-Identifier?

The server identifier is a global configuration for the DHCP Server on the switch. It provides clients with a unique identifier for the DHCP Server in the form of the DHCP server’s IP address. The attribute is sent by the server in DHCP option 54 in the DHCP OFFER packet, and is also used by the client when sending the DHCP REQUEST packet.

This can be a useful feature in environments with multiple DHCP servers.  Remember that DHCP messages sent by the client are always broadcasts.  This feature provides the client with a mechanism to specify which DHCP server, it is sending the DHCP REQUEST message to.   Here is a note from Microsoft explaining the same idea.

Solutions

Changing the Server-Identifier

First I tried configuring the server-identifier to 172.31.129.1. I reconnected to the switch and took another packet trace.  DHCP for my APs now worked, but DHCP on the interfaces dedicated to my management network stopped working.

It is my deduction that the switch’s DHCP Server sees the server-identifier in the DHCP REQUEST Packet and attempts to broadcast the DHCP ACK from the same IP Address.  If you are not in the same network segment as that IP Address, you won’t see the broadcasted DHCP ACK.  In this case 172.31.129.1 is not visible on layer 2 from the management network, meaning that the management network cannot receive any broadcast DHCP ACK messages from that IP.

This isn’t really a great solution, as it still only allows one address pool in the switch’s internal DHCP server to work at any given time.

Removing the Server Identifier

Secondly I tried removing the dhcp-server server-identifier completely.  I can do this because I only have one DHCP server in the network; I don’t really need to worry about giving clients a unique identifier to select a specific server’s lease offer.  This gave me good results! DHCP now works on all my interfaces. Each interface now responds directly to the broadcasted DHCP REQUEST messages they receive.  This solution works well, but only in simple environments where you’re sure your DHCP discover messages will only be heard by one server!

What About Using a Loopback Interface?

Well, I tried this, and rather unsurprisingly, I got the same results I got in my first option.  The DHCP OFFER and DHCP REQUEST packets are sent with the loopback interface’s IP Address specified as the server-identifier in Option 54. The switch fails to send back a DHCP ACK to any physical interface, breaking the DHCP exchange everywhere.  So this is a no go.

Working with DHCP in More Complex Environments

Sometimes we are required to work in more complex environments that may contain multiple DHCP servers serving multiple address pools.  Given what we have seen above, in these scenarios I would strongly advise NOT using the switch’s internal DHCP server.  I would be more inclined to use external DHCP servers along with the switch’s DHCP relay function.   You can configure any interface on your switch with an ip helper-address, that will forward any UDP broadcast messages to the specified DHCP server for that interface.  This also allows you to place DHCP servers in a centralised location, define which DHCP server will respond to a request on any given interface and cuts down on the amount of broadcast traffic flying about in your network.  Ideally, if you are working in a more complicated environment, this is the way to go!

 

As Always, I hope this was useful!

Categories
Ruckus Ruckus ICX Switches Ruckus Wi-Fi

My Ruckus Laboratory – Virtual Network Topology

This post is part of a series on building my Ruckus home laboratory environment. Previous articles in this series include:

  1. Building a Ruckus Home/Office Laboratory on a Budget – Part 1 
  2. Building a Ruckus Home/Office Laboratory on a Budget – Part 2
  3. My Ruckus Laboratory – Home Network Architecture & Limitations
  4. My Ruckus Laboratory – Physical Network

In this post I document the high level network topology inside my Dell R610 server and share some of my thoughts on why it is designed the way it is.

Choosing a Topology

A Flat Network

The simplest possible network topology is a flat network with all of the virtual machines, APs and clients in the same subnet.  Once you’re done building out the physical network, simply place your virtual machines inside the host on a single subnet behind a virtual switch and you’re good to go right?  In one way you are right, this is the simplest possible deployment and the quickest way to getting your hands dirty with various machines, but it is also the most limited approach.

A flat network does not allow you to test scenarios where a SmartZone controller is deployed using 3 separate interfaces for Management, Control and Clustering.  It cannot test scenarios where APs and controllers communicate through NAT.  It cannot test scenarios where clients require a tunneled connection for mobility between subnets.  It prevents you from testing things like dynamic VLANs and Policy control.  It also removes the ability to learn about many other entities and technologies that are at play in a network and how they interact with the Ruckus products and that is really the one of the fundamental reasons I am building this laboratory.

A Layer 3 Network

Overall, it makes the most sense to build a layer 3 network for the virtual network, but what should this network look like?  I could simply slap down a virtual Router and run my laboratory network with all the entities connected to that.  This is a great deal better than the flat network we described above and will enable you to test many more features, but it still doesn’t quite hit the mark in my book.

Before I dive into the topology that I have chosen for my virtual network, let’s consider the three primary requirements of the virtual network topology.

First the chosen network topology must allow testing of as many features and technologies as possible without requiring major architectural changes.  I want this laboratory to be as productive as possible, and for that I need to be able to test a feature or a configuration whilst making only limited changes to the underlying network.

Second, if the laboratory is really to have any value, it must be roughly analogous to most customer network topologies in the field.  This way when I test a feature or a configuration, it must map to an as yet unknown production network as easily as possible.  This is key for any person reading about testing I have done, who wishes to use the same approach in their own network.

Third,  the network topology should act as a template that enables best practice network design, segmentation and security.  The motivation here is to re-enforce network design best practices and address topics including network performance and security.

The Triangle

The shape I have chosen for the virtual network topology is that of a triangle, hardly an original choice but there it is.  The points at the base of the triangle represents two remote locations, separated from the network core at the apex of the triangle by Layer2/Layer 3 connections.

Ruckus Laboratory Virtual Network Topology

Whether you are looking at an enterprise network with a head office and several remote offices/locations, a carrier network with multiple sites connected into a regional core network, or a campus network with multiple buildings, you will always be able to discern this shape.  Even if we think of a scenario in which a hotel group chooses to manage multiple properties from a single controller in a datacenter available over the Internet, this shape persists in some form.  Of course, the exact protocols that run between the sites will differ between the different scenarios.  In a campus network you would be likely to encounter OSPF, or perhaps some campus fabric implementation,  in an enterprise network you may encounter SD-WAN or MPLS.  In our last example, you’d be likely to encounter connectivity directly over the internet with NAT traversal on either side.  Either way though, the shape holds.  The additional benefit of this shape is that it enables you to test communications from the edge to the core network and between two edge locations.

Virtual Network Topology

The final virtual network topology showing the segmentation of the laboratory network according to services is shown below.

Virtual Network Topology & Segmentation

Network Segmentation

Abstraction & Simplification

In order to escape the exponential complexity of assigning and tracking subnets on the fly, I have subdivided my virtual network into functional groups.  The functional group into which an entity is placed informs me what services the entity should be providing and which other entities it should be communicating with.  For instance, I don’t want any of the client subnets to be able to reach the Core Network Services or OSS Subnets that manage and run the network.  I also only want subscribers to be able to use specific services/protocols in the Subscriber Core Services and Subscriber Services subnets.  The only entities that should be able to manage the network are those in the Management Access group.

Organizing the network entities this way also allows me to get an idea for how many subnets I may need in each functional group and gives me the ability to assign IP Address ranges at a functional level in a predictable manner, that allow for future customization and expansion.

Security & Role Based Design

Each entity within a functional group will also have a customized security profile based on its role.  For instance both Super and Network Admin class users (separate subnets) have connectivity to the OSS Network and the entities that provide services in the Subscriber Services and Subscriber Core Services subnets.  An entity in the network attempting to relay API commands to the SmartZone Controller would have to reside in either of the management Access Subnets and have access to the controller API with a valid username and password.

Only Super Admins have the ability to even reach the Network Core Services subnet to manage the entities there, let alone attempt a login.  In addition, the only entities capable of receiving services from the Core Network Services subnet are network devices on their own management VLANs.

OSS Network Subnets

The OSS network provides a management interface to the OSS infrastructure including the SmartZone Controller, SmartCell Insight Analytics, SPoT location services and any other NMS (SNMP / Syslog etc) that I have chosen to learn about.   It is useful to note that if the SmartZone controller is deployed with 3 separate interfaces, the Management subnet will be the subnet that interfaces with Management Access.  The AP Ctrl interface will be given its own policy.

vSZ-D Placements

Ruckus’ SmartZone platform provides a wide range of options for deployment and provides features such as CALEA mirroring for lawful intercept and roaming of clients between Data Planes.  I have placed the virtual SmartZone – Data Planes asymmetrically in the network to quickly demonstrate the various deployment options and test the software’s features.  One is placed in the core network, whilst the other is placed locally in Edge Network B.  

 

That’s all for now!

 

Categories
Ruckus Ruckus ICX Switches Ruckus Wi-Fi

Ruckus ICX Switches – Power over Ethernet

In my previous post we covered the configuration of some basic layer 3 services for my Ruckus ICX 7150-C12P which is going into my home laboratory.  But now we actually want to start plugging things in and turning APs ON!  In this post I dig into the details of working with PoE on the ICX Switches.

When I started this post I really thought it would be quite trivial, at best a purely supplemental post.  Turns out, I was a little wrong, this really does deserve its place as a standalone post!

A Quick Refresher

Yes, I know, you’ve been working in this field for ages, or are just starting out, and either way, you, like me, think that you know pretty much everything there is to know about boring old PoE. Regardless, let’s revise a little:

Terminology

The PSE is the Power Sourcing Equipment, and is located on the switch ethernet interface / PoE injector “out” interface.  The PD is the Powered Device, and is located on the other end of the Cat5e/Cat6 ethernet cable.

Power at the PSE vs Power at the PD

The Ethernet cable is made of copper wires and has a certain resistance and impedance specified by the standard to which it adheres (Cat 6 characteristics here).  This means that not all power at the PSE will reach the PD.  We must accommodate power losses for up to 100m of cable.

PoE Standards

802.3af allows a maximum of 15.4 Watts at the PSE / 12.95 Watts at the PD.  802.3at allows a maximum of 30 Watts at the PSE / 25.5 Watts at the PD.  You may see 60 Watt “Ultra Power PoE” or “PoE++” injectors or similar, these use a modified version of 802.3at but are typically not standardized.  Power over HDBaseT (PoH) allows a maximum of 100 Watts at the PSE.  PoH enables the PD to detect cable length/resistance and to maximize power draw whilst remaining below the limits of 100 Watts at the PSE.  There is also a newer standard called 802.3bt which aims to update the 802.3af/802.3at standards and allow operation with up to 90 Watts of power at the PSE / 71 Watts at the PD.  The latest timeline states it will be released as a standard in 2018.

For more on the various PoE standards check out the wikipedia article which is pretty useful!

Which Twisted Pairs Carry Power?

Ethernet cables have 4 twisted-pairs of copper wire.  A 100/1000 Ethernet link using 802.3af or 802.3at use only 2 twisted pairs in the Cat5e / Cat6 cable to transfer power and data, and 2 twisted pairs to transfer data only.   Originally in the days of 10/100 Ethernet, only 2 twisted pairs were used for data transfer.   The decision of which two pairs to use for power transfer depended on the type of device injecting the power.  For an end-span device like a PoE Switch, power is transferred on the same pairs used for data transfer (Pins 1, 2, 3 , & 6) called Mode A.  For a mid-span device like a PoE injector, power is injected on the unused twisted pairs (pins 4, 5, 7, & 8) called Mode B.  When selecting 802.3af/at compatible devices, be aware that they typically only support Mode B operation.  802.3af/at compliant devices however support BOTH Mode A and Mode B.   By comparison, PoH and 802.3bt both use 4 twisted pairs to transfer power and data. The  60 Watt “Ultra Power PoE” injectors use all 4 twisted pairs to deliver power and data.   You will sometimes see 60 Watt “Ultra Power PoE” injectors or similar, these use all 4 twisted pairs to deliver power and data, but are typically not standardized.

If you want to dig into this specific hole a bit more:

What Can I Power with PoE?

All the things that you can power with PoE. And I am sure there is more, just keep looking.

Ruckus ICX7150 PoE Capabilities

First, let’s just talk quickly about the main PoE capabilities of the Ruckus ICX Switching range when it comes

802.3at Power – For Everyone

All Ruckus ICX switches are capable of 802.3at power at the PSE.  The number of ports that can handle simultaneous 802.3at power depends on the power budget of the switch.  A summary of the limits on these switches (you can check it in the datasheets yourself) is presented in the table below.

Model PoE+ Ports PoH Ports PoE Power Budget Simultaneous
 802.3af Ports 802.3at Ports PoH ports
ICX7150-C12P 12 124 Watts 8 4
ICX7150-24P 24 370 Watts 24 12
ICX7150-48P 48 370 Watts 24 12
ICX7150-48PF 48 740 Watts 48 24
ICX7150-48ZP 32 16 1480 Watts (2 PSU) 48 48
(2 PSU)
16
(2 PSU)

As you can see from the table, the ICX7150-C12P I am using in the lab at least gets me over the hump on 802.3at for up to four APs.

Power by Class

PoE devices are separated into classes by how much power they require.  You can configure a port to only support a specific class of power.  For instance:

RobLab_7150_C12P_1(config)#inline power ethernet 1/1/12 power-by-class 2

This command limits the port to operating on class 2 only (3.84 to 6.49 Watts at the PD, 7 Watts at the PSE).

Power Adjust Class

You can also adjust the amount of power being fed to devices that belong to a certain class.  For instance, consider a batch of access points that should work in class 0 (0 to 12.95 Watts), but for some reason end up drawing just a bit more than that at boot up or some other scenario.  In these cases often a switch will simply shut the port down!  Well you can work around that with this command, shown in the example below:

RobLab_7150_C12P_1(config)#inline power adjust class 0 
  delta     delta power to be allocated over the LLDP request for the PD class
  minimum   Minimum power to be allocated for the PD class
RobLab_7150_C12P_1(config)#inline power adjust class 0 delta 1000
RobLab_7150_C12P_1(config)#inline power adjust class 0 minimum 16400

Power Limiting

In some scenarios you may have to budget your power quite carefully.  The last thing you want is someone plugging in a new PoE+ or PoH capable device and exceeding the PoE power budget of the switch.  To protect yourself against this possibility, you can set power limits on specific PoE interfaces of the switch.  Limiting the maximum power budget on specific interfaces will prove useful in scenarios where you are using equipment that is capable of running on multiple PoE standards like the Ruckus R720 / R710 / R610 APs.  Below is a table of recommended PoE power limits for different Ruckus AP models that I have gathered from the product data sheets.  In my home laboratory, I know that the maximum power draw for the mesh AP into my home network should be no more than 15.4 watts at the switch.

Ruckus AP Model 802.3af PoE (15.4 Watts) 802.3at PoE+ (30 Watts) PoH Power (< 90 Watts)
H510  PoE Output 4 Watts
Peak 9.2 Watts (no PoE out)
Typical 7.3 Watts
Recommended
PoE Output 12.95 Watts
 –
R310 Recommended
Peak 11 Watts
Typical 7.8 Watts
 –  –
R510  Recommended
Peak 12.6 Watts
Typical 7.5 Watts
 –  – 
R610 2 Chain Transmit (2.4 & 5 GHz)
3 Chain Receive
18dBm / chain (2.4 & 5GHz)
USB Disabled
Secondary Ethernet Disabled
Recommended
Peak 18.8 Watts
Typical 10.4 Watts
 –
R710 2 chain Transmit (2.4GHz only)
4 chain Receive
16dBm/Chain (2.4GHz Only)
USB Disabled

Secondary Ethernet Disabled

 Recommended
Peak 25 Watts (With USB)
Typical 9.4 Watts (no USB)

 –
R720 1 Chain Transmit (2.4 & 5GHz)
4 Chain Receive
18dBm/chain 2.4GHz
20dBm/chain 5GHz
USB Disabled
Secondary Ethernet Disabled
4 Chain Transmit
4 Chain Receive
18dBm/chain 2.4GHz
20dBm/chain 5GHz
USB Disabled
Secondary Ethernet Disabled 

Recommended
Peak 35 Watts (With USB)
Typical 11.4 Watts (No USB)

T300  Recommended
Peak 11 Watts
Typical 7.5 Watts
 –  –
T610

2 Chain Transmit
2 Chain Receive

USB Disabled
Secondary Ethernet Disabled

Recommended
Peak 25 Watts (With USB)
Typical 10.4 Watts (No USB)
– 
T710 –   Recommended
Peak 25 Watts
Typical 10.4 Watts
(PoE Output Disabled)
 802.3at PoE Output enabled.
Peak 60 Watts.

Power Prioritization

Another tool in your arsenal is power prioritization.  This is especially useful if you are running 2 PSUs in a switch and need to plan for a failure of one of the PSU’s.  Or what about if you are uncertain of the power requirements of the PoE devices that will be connected?  When the power budget of the switch is exceeded, what do you keep running and what do you kill?  In my laboratory environment, I want to make sure that the mesh AP into the home network stays up in case anything maxes out the power budget of the switch.   Priority levels can be set between 1 (highest) and 3 (lowest), all interfaces are set to priority 3 by default.

Decoupled PoE & Data Link Operations

Heads up WLAN people, this one is for you!  There are some scenarios where editing an Ethernet interface’s settings can cause power delivery on those interfaces to be affected.  Scenarios include adding / removing a PSE port from a LAG, adding / removing a tagged PSE port from a VLAN or VLAN group, or enabling / disabling the Ethernet port.  In these scenarios, you may want the data link to go up and down, but not the power!

OverDrive

This a VERY cool feature.  Overdrive allows Class 0 & Class 4 powered devices to negotiate for more than 30 Watts using LLDP on a normal PoE+ port!  For example, a Ruckus R720 requires about 35 Watts (Peak) to enable all of its features.  The Overdrive feature allows a powered device (like an AP) to request more than 30 Watts from a standard 802.3at, PoE+ capable PSE, up to the maximum rated power for the PSE.  This feature is available on the PoE+ ports of the switches in the below table:

Switch Model Max PSE Power (PoE+)
ICX 7150-48ZP 47 Watts
ICX7450-24P 42 Watts
ICX7450-32ZP 35 Watts
ICX7450-48P 35 Watts

Notes:

  • PoE overdrive was only introduced in 08.0.61, make sure to update your PoE firmware on the switch to ensure this feature works!
  • PoE Overdrive is only supported on PoE+ / PoH capable Ports.
  • Maximum power output is limited by the hardware limitation of the PSE on the switch port.
  • Overdrive is only valid on Ports that use 2 pairs for power, or on 4-pair ports configured for 2-pair operation.  i.e Overdrive is supported by default on PoE+ ports, but you will need to configure any PoH ports to use only 2 twisted pairs for power and data.

Inline Power on Secondary LAG Ports

You can also configure the switch to deliver power over multiple interfaces that make up a LAG.  For example you can add several ethernet interfaces to a LAG and supply power over one, two or every one of them.  This is a useful feature if you require redundant power to some device or perhaps a large amount of power delivered, for example a 200 Watt digital signage display?

Thats all for now!

(PS: have fun reading the command guide!)

Categories
Ruckus Ruckus ICX Switches

Ruckus ICX7150-C12P – Basic Layer 3 Services

In the previous posts focused on the topic of configuring Ruckus ICX Switches, we got the ICX 7150-C12P up and running and upgraded to the latest Layer 3 image.  In this post I want to start configuring it to act as a Layer 3 switch for my Ruckus laboratory environment.

If you are learning about Ruckus ICX Switches and their capabilities, I recommend reviewing the following useful documentation (along with everything else) available on the Ruckus support site:

  • Command Reference Guide
  • Layer 2 Switching Configuration Guide
  • Layer 3 Routing Configuration Guide
  • DHCP Configuration Guide

Configuring IP Addresses

The first thing I am going to need is an IP address on the ICX switch.  The ICX layer 3 switch firmware gives you the ability to define an IP Address on the following types of interfaces:

  • Ethernet Ports
  • Virtual Interfaces / Virtual Ethernet  (VE)
  • Loopback interfaces
  • GRE Tunnels

Ethernet Interfaces

You can assign an IP address directly to a specified Ethernet interface.  For example you can assign the address 10.0.0.1/24 to Ethernet interface 1/1/1 on the switch.  You can also load multiple IP addresses onto a given Ethernet interface.  This is useful in scenarios where you know exactly which Ethernet Interface the traffic will arrive on.  A good example of when to apply this configuration is if you are running a point to point link between two locations using a specific interface on either side of the link.

Example

As it turns out, this is exactly the kind of scenario I have in my home laboratory between the Ruckus ICX7150-C12P and the Internet NAT router!  Here is an example where I assign an IP address directly to uplink port 1/2/2 on the ICX7150 switch in my laboratory.

SSH@RobLab_7150_C12P_1#configure terminal
SSH@RobLab_7150_C12P_1(config)#interface ethernet 1/2/2 
SSH@RobLab_7150_C12P_1(config-if-e1000-1/2/2)#ip address 172.31.254.2/30
SSH@RobLab_7150_C12P_1(config-if-e1000-1/2/2)#exit
SSH@RobLab_7150_C12P_1(config)#write memory
Flash Memory Write (8192 bytes per dot)
. 
Write startup-config done. Copy Done. 
SSH@RobLab_7150_C12P_1(config)#

Virtual Interfaces

A virtual interface is the same as a “sub interface” on Cisco routers and is referred to as Virtual Ethernet or VE in Ruckus ICX nomenclature.  A virtual interface acts as the layer 3 interface to terminate VLAN tagged Ethernet traffic.  The advantage of this interface type over an Ethernet interface is that you can aggregate traffic entering the switch via multiple Ethernet interfaces.

Consider a scenario in which you have Layer 2 traffic tagged with VLAN 100 entering the Layer 3 switch. You want the Layer 3 switch to route that traffic to destinations on other subnets, but the traffic may enter through multiple ethernet interfaces.  The Layer 3 switch solves this scenario with a Virtual Interface that can be assigned to multiple Ethernet interfaces.

Maximum Virtual Interfaces

Be aware that your chosen switch model may have some limitations in terms of the number of Virtual Interfaces it can support. Consult the data sheet and configuration guides of your switch model and firmware releases to be certain of how many Virtual Interfaces (VEs) are supported.

Configuring a Virtual Interface

Management VLAN

The management VLAN exists to allow me to access all physical and virtual network components from a single location.  The Management VLAN will be exclusively enabled, untagged on Ethernet interface 1/1/12.  The management VLAN will be assigned to

RobLab_7150_C12P_1>enable 
User Name:<user> 
Password: 
RobLab_7150_C12P_1#conf t 
RobLab_7150_C12P_1(config)#vlan 101 name MGMT 
RobLab_7150_C12P_1(config-vlan-100)#untagged ethernet 1/1/12 
Added untagged port(s) ethe 1/1/12 to port-vlan 101. 
RobLab_7150_C12P_1(config-vlan-100)#router-interface ve 2 
RobLab_7150_C12P_1(config-vlan-100)#interface ve 2 
RobLab_7150_C12P_1(config-vif-2)#ip address 172.31.255.1/24 
RobLab_7150_C12P_1(config-vif-2)#write memory 
Flash Memory Write (8192 bytes per dot)  
. 
Write startup-config done. 
Copy Done. 
RobLab_7150_C12P_1(config-vif-2)#exit 
RobLab_7150_C12P_1(config)#exit 
RobLab_7150_C12P_1#

x86 Hosts VLAN

The x86_Hosts VLAN (VLAN 100) will be exclusively enabled, untagged on ethernet interfaces 1/1/1 to 1/1/6.  The x86 Hosts VLAN will be assigned to router-interface ve 1 with IP address 172.31.0.1/24.  This will allow me to gain direct access to the switch CLI should anything go wrong with my Management VLAN.

RobLab_7150_C12P_1>enable
User Name:<user>
Password:
RobLab_7150_C12P_1#conf t
RobLab_7150_C12P_1(config)#vlan 100 name x86_Hosts
RobLab_7150_C12P_1(config-vlan-100)#untagged ethernet 1/1/1 to 1/1/6
Added untagged port(s) ethe 1/1/1 to 1/1/6 to port-vlan 100.
RobLab_7150_C12P_1(config-vlan-100)#router-interface ve 1
RobLab_7150_C12P_1(config-vlan-100)#interface ve 1
RobLab_7150_C12P_1(config-vif-1)#ip address 172.31.0.1/24
RobLab_7150_C12P_1(config-vif-1)#write memory
Flash Memory Write (8192 bytes per dot) 
.
Write startup-config done.
Copy Done.
RobLab_7150_C12P_1(config-vif-1)#exit
RobLab_7150_C12P_1(config)#exit
RobLab_7150_C12P_1#

Additional VLANs

Additional VLANs will be enabled on the switch to provide Layer 2 services on an as needed basis in my testing.  These will include VLANs for Access Points and Client Subnets.  These VLANs will simply allow the traffic to pass through to the routers in the virtual lab.

Loopback Interfaces & GRE Interfaces

I am rather conspicuously not talking about configuring these interfaces at this point in time.  But I believe the topic will come up in a later post.  If you cannot wait, I strongly recommend reading the Ruckus ICX Layer 3 Routing Configuration Guide.

Configuring DHCP

I will require a DHCP server in the Management VLAN that provides addresses to clients as they connect.  I also want this DHCP server to work on the out of band management port, just in case my access via WLAN fails or using a cable is faster!

Let me start by saying there is a ton you can do with this DHCP server and the DHCP capabilities in the switch.  The below configuration is truly trivial.

RobLab_7150_C12P_1#conf t
RobLab_7150_C12P_1(config)#ip dhcp-server enable
RobLab_7150_C12P_1(config)#ip dhcp-server pool mgmt_1      
RobLab_7150_C12P_1(config-dhcp-mgmt_1)#network 172.31.255.0/24
RobLab_7150_C12P_1(config-dhcp-mgmt_1)#dhcp-default-router 172.31.255.1
RobLab_7150_C12P_1(config-dhcp-mgmt_1)#dns-server 172.31.255.1
RobLab_7150_C12P_1(config-dhcp-mgmt_1)#excluded-address 172.31.255.1 172.31.255.99
RobLab_7150_C12P_1(config-dhcp-mgmt_1)#lease 0 6 0
RobLab_7150_C12P_1(config-dhcp-mgmt_1)#deploy      
RobLab_7150_C12P_1(config)#write memory

Note 1: If you ever change the DHCP pool config, remember to issue the DEPLOY command again, otherwise the DHCP address pool will simply remain in a “pending” state after your changes!

Useful Commands

Here are some useful commands to check the status of the DHCP server and the address pools.

SSH@RobLab_7150_C12P_1#show ip dhcp-server        
  address-pools   Display all address pools
  binding         Display DHCP lease-binding database
  flash           Displays the lease-binding database stored in flash memory
  summary         Displays the DHCP servers statistics 
---
SSH@RobLab_7150_C12P_1#show ip dhcp-server summary       
DHCP Server Summary:
                    Total number of active leases:  2
           Total number of deployed address-pools:  1
         Total number of undeployed address-pools:  0
                                    Server uptime:  04d:09h:32m:16s
---
SSH@RobLab_7150_C12P_1#show ip dhcp-server address-pools 
Showing all address pool(s):
                    Pool Name:  mgmt_1
 Time elapsed since last save:  00d:00h:29m:34s
Total number of active leases:  2
           Address Pool State:  active
        IP Address Exclusions:  172.31.255.1 172.31.255.99
      Pool Configured Options:
          dhcp-default-router:  172.31.255.1
                   dns-server:  10.0.0.254  8.8.8.8 
                        lease:  0 6 0
                      network:  172.31.255.0 255.255.255.0
---
SSH@RobLab_7150_C12P_1#show ip dhcp-server binding       
Bindings from all pools:
        IP Address    Client-ID/        Lease expiration Type
                      Hardware address
    172.31.255.100    c0d0.1274.2590   000d:05h:58m:15s   Automatic
    172.31.255.101    48d7.05be.758d   000d:05h:59m:24s   Automatic
SSH@RobLab_7150_C12P_1#

Routing Between Subnets

To provide Internet access for the subnets I have configured above, I must provide a default route to the internet.  Internet access in the laboratory is provided by a Mikrotik router (172.31.254.1) connected to the Ethernet Interface 1/2/2 on the ICX7150 switch.

Ruckus ICX switches have a feature called Integrated Switch Routing (ISR), which allows routing traffic between virtual interfaces in the switch without the need for an external router.  You don’t (shouldn’t) need to do anything to enable this feature.  You do, however, have to configure routes to reach external entities using either static or dynamic routing protocols.  Thus far I am sticking to static routing protocols.

Setting a Default Route

RobLab_7150_C12P_1#conf t RobLab_7150_C12P_1(config)#
SSH@RobLab_7150_C12P_1(config)#ip route 0.0.0.0/0 172.31.254.1   
SSH@RobLab_7150_C12P_1(config)#write memory
Flash Memory Write (8192 bytes per dot) 
.
Write startup-config done.
Copy Done.
SSH@RobLab_7150_C12P_1(config)#exit
SSH@RobLab_7150_C12P_1#

About Management Access

On the Ruckus ICX layer 3 switch you can use any one of the configured IP addresses on the switch for management access to the switch.  I can access the switch over ssh via 172.31.0.1, 172.31.255.1 and 172.31.254.2.  I will discuss hardening the switch configuration in a later post.

Quick Summary Config

Here is the current running config of the switch (also the config startup!) to summarize what we have done so far.

SSH@RobLab_7150_C12P_1#show run
Current configuration:
!
ver 08.0.61T213
!
stack unit 1
  module 1 icx7150-c12-poe-port-management-module
  module 2 icx7150-2-copper-port-2g-module
  module 3 icx7150-2-sfp-plus-port-20g-module
!
...
vlan 1 name DEFAULT-VLAN by port
!
vlan 100 name x86_Hosts by port
 untagged ethe 1/1/1 to 1/1/6 
 router-interface ve 1
!
vlan 101 name MGMT by port
 tagged ethe 1/1/12 
 router-interface ve 2
!
...
aaa authentication enable default local
aaa authentication login default local
aaa authentication login privilege-mode
hostname RobLab_7150_C12P_1
ip dhcp-server enable
ip dhcp-server server-identifier 172.31.255.1
!
ip dhcp-server pool mgmt_1
 dhcp-default-router 172.31.255.1 
 dns-server 172.31.255.1 
 excluded-address 172.31.255.1 172.31.255.99
 lease 0 6 0                                                      
 network 172.31.255.0 255.255.255.0
 deploy
!
ip route 0.0.0.0/0 172.31.254.1
!
username <user> password .....
!
...
interface ethernet 1/2/2
 ip address 172.31.254.2 255.255.255.252
!
interface ve 1
 ip address 172.31.0.1 255.255.255.0
!
interface ve 2
 ip address 172.31.255.1 255.255.255.0
!
...
ip ssh  key-exchange-method dh-group14-sha1 
!
!
end
SSH@RobLab_7150_C12P_1#

 

Thats All for Now!

Categories
Ruckus Ruckus ICX Switches Ruckus Wi-Fi

My Ruckus Laboratory – Physical Network

This post is part of a series on building my Ruckus home laboratory environment. Previous articles in this series include:

  1. Building a Ruckus Home/Office Laboratory on a Budget – Part 1 
  2. Building a Ruckus Home/Office Laboratory on a Budget – Part 2
  3. My Ruckus Laboratory – Home Network Architecture & Limitations

In this post I discuss the physical network components and the physical / logical connectivity of the laboratory equipment.

Physical Network Overview

The image below gives you a view of the physical components of the laboratory network and their connections to one another.

Home Laboratory – Physical Connectivity

Dell PowerEdge R610

The Dell PowerEdge R610 is connected to the ICX7150-C12P using 2 Ethernet interfaces configured in a LAG to provide 2 Gb/s full duplex connectivity.  This connection will provide for Layer 2 communications between the physical hosts using untagged frames (placed onto VLAN 100 inside the ICX 7150).  Additional tagged VLANs for Access Points and Client subnets will be enabled on the LAG interface on an as needed basis.

For the specifications of the Dell R610 server that I am using, check out one of my earlier posts on the topic!

Laboratory Access Points

Ethernet interfaces 7 through 11 are reserved for use by Access Points in the laboratory.  These interfaces are not configured yet but will provide L2 services between the APs and the virtual routers only.  This will maintain the logical separation between the Physical and virtual network environments.

Management AP

Port 12 of the switch is reserved for access to the network management subnet.  This interface is configured as an access port on VLAN 101.  That is to say, it will place all untagged traffic onto the management subnet on VLAN 101 and will drop any tagged VLAN traffic entering the interface.  This makes it easy to connect to the management network via an Ethernet cable directly or via a dedicated wireless access point using a WPA2-Personal SSID, as shown in the diagram.

Mikrotik HAP AC

Originally, I intended on using an 802.11ac capable, DD-WRT router that I had in the back of my cupboard from about 2014.  After a week of fist clenching frustration and dealing with a WEB UI that was unresponsive and didn’t correlate to the actual settings in the box, I decided I had had enough and went out and bought the Mikrotik HAP AC (you should be able to get one for about $130.00).

The Mikrotik HAP AC  is a dual band, 802.11ac, 3×3:3 capable Access Point running Mikrotik’s RouterOS (including a level 4 license), capable of fulfilling just about all of my needs in the laboratory.  The primary purpose of the Mikrotik HAP AC router is to provide the physical and virtual laboratory networks with connectivity to external networks whilst keeping both as isolated as possible.

The Mikrotik provides me with options for connecting the laboratory to the Internet via Wireless LAN, Ethernet or even a USB 3G/4G modem in a pinch.  It also supports dynamic routing protocols such as OSPF and BGP if I decide to start toying around with those…

In my home laboratory, the Mikrotik is configured as a wireless client that connects to my Home WLAN.  Traffic from the physical hosts and management subnets is routed to the Mikrotik via uplink port 1/2/2 on the ICX7150-C12P switch.  Traffic from the virtual environment is routed directly from Ethernet Interface 3 on the Dell R610 (by a virtual router) to the Mikrotik.

The traffic from each environment is thoroughly isolated using the builtin firewall and routed to the Internet.  The firewall allows connectivity from the management subnet into the virtual environment, but not the other way around.   The firewall also prevents laboratory traffic from reaching devices in my Home WLAN as it traverses that network on its way out to the internet!

Ruckus ICX7150-12

The ICX7150 holds the entire network together.  It provides L3 services to the physical hosts, management subnet and NAT router.  It also provides Layer 2 services to the laboratory access points, and the virtual environment.  More detailed configurations details of the switch are given in future posts.

Layer 3, Logical Network Diagram

The logical structure of the Layer 3 network, including part of the virtual environment is shown below.  Connectivity between the ICX7150 switch and Laboratory Access Points via Ethernet interfaces 1/1/7-11, and their connection into the virtual environment via Ethernet 1/1/1-6 is excluded since those are limited to Layer 2 only.

Home Laboratory – Logical, Layer 3, Network Diagram

 

 

 

Thats all for now!

Categories
Ruckus Ruckus Wi-Fi

My Ruckus Laboratory – Home Network Architecture & Limitations

This post is a continuation of the two part series Building a Ruckus Home/Office Laboratory on a Budget. This post starts with a new series name because from this point on, the topics discussed are more specific to my own laboratory environment.  This post details some of the limitations I have run into when designing my home laboratory, specifically around my Internet service provider and home LAN.

The Internet Connection Wrinkle

My home-office environment is sadly complicated by my Internet service provider’s lack of features (the irony).  I have a fiber connection installed at home,  which (considering how much the connection costs me per month) is connected to an offensively cheap home gateway.

The home gateway provides connectivity to the home LAN via four 10/100/1000 RJ-45 Ethernet interfaces on the back.  The home gateway performs basic DHCP and DNS forwarding for a single subnet (10.0.0.0/24) which is sent to the Internet via a NAT behind a dynamically assigned Public IP address.

I am not about to pay the ISP a premium for the luxury of a static IP address, and I am blocked from altering any of the settings on this device.  These two factors become material if I ever want remote access to my lab via an inbound NAT.  I don’t really trust the home gateway to do anything more than what it does already, and want my laboratory network to have as little to do with it as possible.  When they installed this plastic shoebox, at least they did me the favor of disabling the even cheaper Wi-Fi radio.  So my life is not all bad.

A Hidden Advantage

An unexpected advantage is that my debilitated home network has given me the impetus to design a laboratory environment that can fit in almost anywhere.  The entire laboratory environment including both physical and virtual components will be able to function behind a NAT inside almost any LAN.  More on this later!

The Home Network

The LAN provided by the home gateway router is still useful for running a Home Wireless LAN with Ruckus Cloud.  I use this service at home to keep up to date with new features and enhancements, and to perform continuous testing and monitoring of the service, allowing me to eat my own dog food so to speak.  The other advantages of this setup are that my home WLAN is remotely manageable/demo-able and is kept separate from my laboratory environment.

Overview

The image below is an illustration of my home WLAN.  The Ruckus APs are R600 (Root Node) / R500 (Mesh Node) connected over a 5GHz mesh link.  The R600 plugs into the Home Gateway and is the primary wireless connection to the Internet.  The home entertainment goodies are connected by the R500 mesh AP.  The two port switch on the R500 mesh node has proven useful for connecting the Raspberry Pi Home Media Server with the 3TB NAS for quick media playback & reducing unnecessary wireless utilization.  The Apple TV connects directly to the Home WLAN.

 

Full Disclosure: The Mesh links in the picture imply that I am using only 40MHz channels, but I decided to go with 80 MHz channels as none of my neighbors are using 5GHz yet, poor souls!

Limiting BSSIDs

The home SSID and any other client SSIDs are only available from the root AP on 2.4GHz and/or 5GHz as I require them.  My abode is not very big and a single AP placed roughly in the middle easily covers the entire area.

The mesh AP publishes no WLAN services except the mesh SSID.  This makes the network topology and connectivity a bit simpler, ensuring that clients are always directly connected to the root AP. It also means clients cannot connect to the mesh AP and then do an unnecessary double wireless hop to the Internet.

Ruckus Cloud does not support AP & WLAN groups just yet, so you can’t very easily choose to place specific SSIDs onto specific APs within a venue.  But, you can still accomplish the task above by disabling the 2.4GHz and 5GHz radios in the individual mesh APs’ Radio Settings.  The APs will maintain their full mesh functionality, acting both as mesh clients, and beaconing the hidden mesh SSID, allowing other APs to connect into the mesh if needs be.

Why Mesh?

First off, to test mesh features and stability with the Ruckus Cloud controller, but that is obvious I guess.

The other reason is that connectivity options on the Raspberry Pi Model 3 that I am using as my Home Media Server are truly basic.  The Raspberry Pi 3 only has a 2.4GHz, 802.11n, single stream radio, and a 10/100 Ethernet connection.  These connectivity options are SLOOOW for the 3TB NAS when you’re doing backups or big file dumps from a wireless client.  I also don’t want to muck around with an external USB Wi-Fi adapter (although that is an option).  The best option for me was the Ruckus R500 as a high throughput mesh client with a 1Gb/s Ethernet connection straight to the NAS and a 100Mb/s connection to the Pi.

I could, if I wanted to, replace the Raspberry Pi with something more capable like the ODROID C2 which would eliminate the need for having the mesh AP, but there would be no performance improvement and quite possibly a performance degradation over the current setup.

That about sums up the home network, we will discuss more in later posts!

Categories
Ruckus ICX Switches

Ruckus ICX7150-C12P – Software Upgrade & Licenses

In the previous post regarding the Ruckus ICX Switches, I detailed the configuration and some best practices to allow further configuration/management of a Ruckus ICX switch via SSH. This post will cover the next important step in setting up your ICX switching environment: Upgrading the firmware.

SHOW US WHAT YOU GOT!

Before starting with any configurations, it is a good idea to make sure you know which firmware your switch has loaded on it and what licenses you currently have.  From the command prompt of your switch:

ICX7150-C12 Switch>show version
Copyright (c) 1996-2017 Brocade Communications Systems, Inc. All rights reserved.
    UNIT 1: compiled on Feb 17 2017 at 16:03:13 labeled as SPS08060
      (23946048 bytes) from Primary SPS08060.bin
        SW: Version 08.0.60T211
      Compressed Boot-Monitor Image size = ######, Version:10.1.09T225 (######)
       Compiled on Sat Feb 18 00:15:43 2017
  HW: Stackable ICX7150-C12-POE
==========================================================================
UNIT 1: SL 1: ICX7150-C12-2X10GR POE 12-port Management Module
      Serial  #:###########
      Current License: 2X10GR
      P-ASIC  0: type B160, rev 11  Chip BCM56160_B0
==========================================================================
UNIT 1: SL 2: ICX7150-2X1GC 2-port 2G Module
==========================================================================
UNIT 1: SL 3: ICX7150-2X10GF 2-port 20G Module
==========================================================================
1000 MHz ARM processor ARMv7 88 MHz bus
8192 KB boot flash memory
2048 MB code flash memory
1024 MB DRAM
STACKID 1  system uptime is 1 day(s) 3 hour(s) 14 minute(s) 25 second(s)
The system started at 00:01:37 GMT+00 Sat Jan 01 2000

The system : started=cold start

ICX7150-C12 Switch>

Layer 2 vs Layer 3 Firmware

Ruckus ICX switches can ship with two different software images, a Layer 2 “switch” firmware version and a Layer 3 capable “router” firmware version.  You can choose which image to load onto the device depending on your needs.  You should be able to load either firmware type onto the 7150 switch.  The switch in my example is currently running the Layer 2 firmware, version 08.0.60.  You will see the firmware version that is currently loaded on the switch, in the output of the show version command.  I have highlighted it in red on the second and third lines,  it should read SPS08060.bin for the layer 2 firmware or SPR08060.bin for the layer 3 firmware.

You can also verify the code version installed on the switch by running the show flash command:

ICX7150-C12 Switch> show flash   
Stack unit 1:
  Compressed Pri Code size = 23946048, Version:08.0.60T211 (SPS08060.bin)
  Compressed Sec Code size = 23946048, Version:08.0.60T211 (SPS08060.bin)
  Compressed Boot-Monitor Image size = 786944, Version:10.1.09T225
  Code Flash Free Space = 1307029504
ICX7150-C12 Switch>

Licensing

Some ICX switch features are controlled by licenses, the best thing to do here is consult the software licensing guide for the specific firmware release and switch model you intend to use.  At the present moment, you will typically require a software license for Dynamic Routing Protocols, Multicast, MacSec, and a “Ports on Demand” license for enabling 10Gb/s functionality on the interfaces of some switch models.  Useful commands for checking up on the installed licenses include:

  • show version –  example above.
  • show pod – shows the status of the Ports on Demand license.
  • show license – shows the current licenses on the device.  This is a standard command in the command line reference guide, but seems to be missing from my 7150 running version 08.0.60.   So I used the show version command to view the license information instead.

Speaking specifically about the  ICX7150-C12P, there are only two license levels available, 2x1G and 2x10GR.  You will see that the current license loaded onto my 7150 is the 2x10GR license.  This allows me to use the 10Gb/s SFP+ ports for uplinks and/or stacking and it also allows me to use the more advanced layer 3 features of the switch.

Choosing the Right Firmware Release

Layer 2 or Layer 3?

The first decision you need to make is whether you are going to use the Layer 2 or Layer 3 firmware version.  I guess everyone will have their own arguments for placing a certain version of code on the switch.  Whatever your reasoning, be aware that using the Layer 3 firmware will typically mean that some limitations may be introduced to the switch to accommodate additional functionality and features.  For example, in the Ruckus ICX7750 core switch, running the Layer 3 firmware reduces the maximum amount of MAC addresses stored in the CAM table from 96,000 to 32,000.  Make sure you read the switch Data Sheet and check that using the Layer 3 firmware doesn’t somehow invalidate your design.

Now that you have cogitated over your network design and which firmware goes where and why, you need to choose a specific release.

Ruckus ICX Release Numbering Scheme

Quickly here, Ruckus ICX switching firmware releases that end with a “0” are feature releases.  For example version 08.0.60 is a feature release with major feature additions.  Version 08.0.61 by comparison, is a maintenance release, and may contain some minor feature additions and enhancements along with a large number of bug fixes (>100).  Finally, if your firmware release has a letter appended to the end, like 08.0.30n that designates it as a patch release, containing no feature enhancements and a small number of bug fixes (<50).

Target Path Releases

If stability/reliability is a critical factor in your network design, head on over to the Ruckus support site and read the Target Path Selection Guide which will give you guidance on selecting a stable firmware version for your switches.  Target Path releases are are specifically designed for stability and reliability and are extensively tested in a sufficiently large number of deployments over a period of time to ensure that there are no known critical issues or defects.  In my view, the Target Path Release should really be the oldest version of code you run on your system, unless your hardware is too old to support it.

Features

If the target path release does not contain the necessary features you require, then you will need to start reading the release notes of later releases to see when the feature you require was implemented.  I would advise using the minimum release (above the target path release) that supports your feature, with the highest maintenance and patch level.  That strategy should more often than not, give you the features you need with the best possible stability.  Make sure to read the release notes and known issues.  It’s a pain, but worth it in the long run!

Upgrading in Anger

Now that we have done all our homework, let’s actually upgrade the switch!  I am using the Ruckus ICX7150-C12P and currently the best firmware for my needs is the 08.0.61 maintenance release. Upgrading an ICX switch follows the process below:

  1. Download the firmware you require from the Ruckus Support Site.
  2. Erase the primary and secondary flash images on the switch
  3. Copy the new boot code to the switch
  4. Copy the new flash code to the switch
  5. Verify the flash code version
  6. Reboot the device

Upgrade via TFTP

No. Stop it now! 

Upgrade via SCP

I have dowloaded the zip file containing all the switch firmware images and unzipped it into the Downloads directory on my MacBook Air.  I am going to install the Layer 3 firmware on the switch.  Let’s get started:

Erase Flash Images:

SSH@RobLab_7150_C12P_1#erase flash primary
Erase flash Done.
SSH@RobLab_7150_C12P_1#erase flash secondary 
Erase flash Done.
SSH@RobLab_7150_C12P_1#

Copy Boot Code

MacBook-Air:~ user$ cd Downloads/08061/ICX7150/Boot
MacBook-Air:Boot user$ ls
mnz10110.bin
MacBook-Air:Boot user$ scp mnz10110.bin <user>@172.31.0.1:flash:bootrom
Password:
mnz10110.bin                                                     100%  769KB  95.6KB/s   00:08    
Connection to 172.31.0.1 closed by remote host.
MacBook-Air:Boot user$ 

Copy Flash Code

MacBook-Air:~ user$ cd Downloads/08061/ICX7150/Images
MacBook-Air:Images user$ ls
SPR08061.bin SPS08061.bin
MacBook-Air:Images user$ scp SPR08061.bin <user>@172.31.0.1:flash:primary
Password:
SPR08061.bin                                                     100%   27MB 484.1KB/s   00:57    
Connection to 172.31.0.1 closed by remote host.
MacBook-Air:Images user$ scp SPR08061.bin admin@172.31.0.1:flash:secondary
Password:
SPR08061.bin                                                     100%   27MB 484.3KB/s   00:57    
Connection to 172.31.0.1 closed by remote host.
MacBook-Air:Images user$ 

Verify the Flash Code

SSH@RobLab_7150_C12P_1#show flash
Stack unit 1:
  Compressed Pri Code size = 28313480, Version:08.0.61T213 (primary)
  Compressed Sec Code size = 28313480, Version:08.0.61T213 (secondary)
  Compressed Boot-Monitor Image size = 786432, Version:10.1.10T225
  Code Flash Free Space = 1307041792
SSH@RobLab_7150_C12P_1#

Reboot the Switch

SSH@RobLab_7150_C12P_1#reload
Are you sure? (enter 'y' or 'n'): Connection to 172.31.0.1 closed by remote host.
Connection to 172.31.0.1 closed

Post Upgrade Check

What happened to SSH?

If you like me, loaded the Layer 3 firmware onto the switch, you will notice that you can no longer SSH to the device.  Remember that IP addresses will be assigned per interface on Layer 3 devices. Loading the Layer 3 firmware wipes out the global IP address settings held by the Layer 2 device.  We will fix that later!

Thats all for now!

Categories
Ruckus ICX Switches

Ruckus ICX7150-C12P – Initial Configuration

This post covers the initial steps required to configure a Ruckus ICX 7150 switch.  Topics covered here include:

  • Console Access
  • Setting the switch hostname
  • Assigning an IP address
  • Enabling SSH access
  • Setting a username and password

Further configuration will be covered in later posts.

Console Access

All initial configuration tasks must be completed via the console interface on the front of the switch.  The Ruckus ICX7150-C12P has two console interfaces.  The first you will notice is the standard RJ-45 interface and the second is the more modern USB-C interface placed in the top left corner of the front of the switch.  You can use either of these interfaces with a terminal emulator program of your choice.

RJ-45 Console access

The switch ships with an RJ-45 to DB-9 Serial  console cable in the box, I imagine because it is more compatible with all the other switches out there!  To use this you will need  a USB to RS-232 DB9 Male serial cable with the relevant drivers to make it work.

USB-C Console Access

To use the USB-C port you simply need a USB data cable with a USB-C connection on one end and a compatible connection for your laptop on the other.  If your laptop uses the regular USB ports, you will need a USB Type-A to USB-C data cable.  On newer laptops like the MacBook Pros that come only with USB-C ports, you will need a USB-C to USB-C data cable.  Some notes here:

  • Most common operating systems (Windows, macOS etc) already have the necessary FTDI drivers for this USB connection, so you shouldn’t need to do anything additional to get this to work.
  • If the connection doesn’t work at first, check that you are in fact using a data cable and not a charging cable.  I have made this mistake before and wasted quite some time fidgeting with drivers etc before realizing my cable was a charging cable and not a data cable, and therefore unable to actually move any serial data.
  • If you are aware that you don’t have the FTDI drivers, or the connection doesn’t load even after you’ve double checked the cable type, you can get them from the support site or here.  You should download the VCP drivers.

Serial Port Settings

The serial port settings are detailed in the table below:

Parameter Value
Baud Rate 9600
Data Bits 8
Parity None
Stop Bits 1
Flow Control None

 

Configuration Tasks

Setting the Switch Hostname

First thing to do now is set the switch hostname, so we can always know which switch it is we are looking at.

ICX7150-C12 Switch>enable
No password has been assigned yet...
ICX7150-C12 Switch#conf t
ICX7150-C12 Switch(config)#hostname RobLab_7150_C12P_1
RobLab_7150_C12P_1(config)#

Assigning an IP Address

We need to give our switch an IP address so we can manage it via something a little more convenient than the console cable.

RobLab_7150_C12P_1(config)#ip address 172.31.0.1/24
RobLab_7150_C12P_1(config)#

Enabling SSH Access

Now that we have a hostname and an IP address, we want to enable SSH access to the switch.  First we need to tell the switch to generate a set of keys to be used for SSH access:

RobLab_7150_C12P_1(config)#crypto key generate rsa modulus 2048
RobLab_7150_C12P_1(config)#
Creating RSA key pair, please wait...
RSA Key pair is successfully created
RobLab_7150_C12P_1(config)# 

Note: DSA keys have been deprecated by openSSH as they are no longer considered secure. I believe the original reason for this is a weakness in some Debian linux systems with a flawed pseudo random number generator.  The main takeaway is that if your DSA key gets used in a compromised system, your private key is at risk.  That is why we are using RSA keys with the longest supported modulus, giving good security and the best compatibility across systems.

Setting the Diffie-Hellman Key Exchange Algorithm Group

The default key exchange algorithm used by the Ruckus ICX Switches is Diffie-Hellman Group-1, SHA-1 with a modulus of 768 bits.  If you are using macOS Sierra 10.12 or later, or are using OpenSSH 7, you may find that when you try to connect to the switch you get an error that states: “Unable to negotiate with xxx.xxx.xxx.xxx port 22: no matching key exchange method found. Their offer: diffie-hellman-group1-sha1”

This is because the Diffie-Hellman Key Exchange Algorithm using shorter modulus lengths (less than or equal to 1024 bits) is considered to be insecure.  These legacy key exchange algorithms are no longer enabled by default in openSSH 7.  The minimum modulus length considered sufficient for secure communications is 2048-bits supported by Diffie-Hellman Group-14.

To fix this problem you have a few options: The first (and worst) option is to alter your system settings (another link here) to re-enable the weak Diffie-Hellman groups.  This may be the only workable option for compatibility whilst moving your network entities to a more secure key exchange algorithm.  The other, less terrible option is to allow weak Diffie-Hellman key exchange algorithms on an as needed basis when opening the connections.

The best option for your new Ruckus ICX switching environment however, is to enforce Diffie-Hellman Group 14 key exchange, which uses a 2048 bit modulus and won’t require you to weaken your system’s security.

RobLab_7150_C12P_1(config)#ip ssh key-exchange-method dh-group14-sha1
Warning: This operation would close all existing SSH connection.
RobLab_7150_C12P_1(config)#

Setting a Username and Password

We need to configure a username and password on the switch.  For now we are going to focus on using the local AAA feature on the switch.  Ruckus ICX Switches allow you to specify the privilege level of a new user as follows:

RobLab_7150_C12P_1(config)#username <user> privilege 
  DECIMAL   <0 READ-WRITE, 4 PORT-CONFIG, 5 READ-ONLY> User privilege level
RobLab_7150_C12P_1(config)#

We are going to go ahead and create an administrator account with read-write privileges, note that if you do not specify the privilege level, it defaults to 0: Read-Write:

RobLab_7150_C12P_1(config)#username <user> password <password>
RobLab_7150_C12P_1(config)#

Now we need to configure local user accounts in the default list to be able to enter privileged exec mode:

RobLab_7150_C12P_1(config)#aaa authentication enable default local
RobLab_7150_C12P_1(config)#

And we also need to enable local user accounts in the default list to be able to login to the switch

RobLab_7150_C12P_1(config)#aaa authentication login default local
RobLab_7150_C12P_1(config)#

A final neat trick useful for laboratory environments (NOT RECOMMENDED IN A PRODUCTION SYSTEM) is to enable users to enter privileged exec mode directly after login:

RobLab_7150_C12P_1(config)#aaa authentication login privilege-mode 
RobLab_7150_C12P_1(config)#

Save your configuration!

RobLab_7150_C12P_1(config)#write memory            
Flash Memory Write (8192 bytes per dot) 
.
Write startup-config done.
Copy Done.
RobLab_7150_C12P_1(config)#

Testing SSH Access

You should now be at a point where you can test SSH access to the switch.  Plug an ethernet cable into your laptop and set an IP on your laptop in the same subnet as you set on the switch.

host:~ user$ ssh <user>@172.31.0.1
The authenticity of host '172.31.0.1 (172.31.0.1)' can't be established.
RSA key fingerprint is SHA256:XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '172.31.0.1' (RSA) to the list of known hosts.
Password:
SSH@RobLab_7150_C12P_1#

Congratulations, you are all setup and can now access your switch securely via SSH using a locally stored username and password.  You should still easily be able get into the switch via direct console connection, just in case things go bad!

Summary:

ICX7150-C12 Switch>enable
  No password has been assigned yet... 
ICX7150-C12 Switch#configure terminal
ICX7150-C12 Switch(config)#hostname RobLab_7150_C12P_1 
RobLab_7150_C12P_1(config)#ip address 172.31.0.1/24 
RobLab_7150_C12P_1(config)#
RobLab_7150_C12P_1(config)#crypto key generate rsa modulus 2048 
RobLab_7150_C12P_1(config)# 
Creating RSA key pair, please wait... 
RSA Key pair is successfully created 
RobLab_7150_C12P_1(config)#ip ssh key-exchange-method dh-group14-sha1 
Warning: This operation would close all existing SSH connection. 
RobLab_7150_C12P_1(config)#username <user> password <password>
RobLab_7150_C12P_1(config)#aaa authentication enable default local
RobLab_7150_C12P_1(config)#aaa authentication login default local
RobLab_7150_C12P_1(config)#aaa authentication login privilege-mode
RobLab_7150_C12P_1(config)#write memory            
Flash Memory Write (8192 bytes per dot)
.
Write startup-config done.
Copy Done.
RobLab_7150_C12P_1(config)#

Thats all for now!

 

Categories
Ruckus ICX Switches Ruckus Wi-Fi

Building a Ruckus Home/Office Laboratory on a Budget – Part 2

In the previous post I covered the basic motivation for needing to build a laboratory for working with the growing range of Ruckus Wireless products and touched lightly on the use of NFV in the laboratory as a method of saving money.  In this post I will give a basic overview of the hardware requirements of the laboratory.

Laboratory Components

The laboratory will consist of the following key entities:

  • Physical network connectivity
  • Virtual Machines
  • x86 Server/s
  • Hypervisor
  • Virtual network connectivity

Physical Network Connectivity

NAT Router

The first and most obvious item you will need is a NAT router to get your Lab network out to the Internet and to get remote access back to your lab.  I am not really going to be too prescriptive here, but I trust you can choose something that meets your needs!  If you are looking for tips, keep reading my blog, as I will be documenting how I built my network!

L2 / L3 Switch

You’re going to need something to connect your x86 servers to the physical network and you’re also going to need something to connect / power your APs.   Physical network connectivity also gives you quick and easy access to the hypervisor host without having to worry about the state of the virtual environment.  Enter the Ruckus ICX 7150-C12P.

The Ruckus ICX 7150-C12P is a 12 port switch that packs a punch.  It can provide PoE+ (802.3at / 30 Watts) on any of its 12 ports (total power budget of 124 Watts) using a fan-less design for silent operation – a useful feature in a home lab!

It has two dedicated 10/100/1000 RJ-45 Ethernet ports for uplink connections and two additional 1/10 GbE  SFP/SFP+ ports for uplinks or stacking.   The 1/10 GbE ports allow you to stack up to 12 of the 7150 family switches together over distances of up to 10km.  You can also stack different switch variants from the same family.  Stacking two switches together can be accomplished using only a single 10 Gb/s link in a linear stack topology, leaving two 10 Gb/s links in the stack free for other connections.

If using the L3 firmware image you can use features like static routes and Routing Information Protocol (RIP).  An additional license provides more advanced features including OSPF routing, Virtual Router Redundancy Protocol (VRRP), Equal Cost Multi-Path (ECMP) routing, Policy Based Routes (PBR) and Protocol Independent Multicast (PIM).

If you are planning on working with Ruckus ICX switches more often, this will be the right switch to start getting used to their basic features!  Check out the Ruckus ICX 7150 product family brochure here.

High-End 802.11ac AP Power Requirements

Some of the latest generation 802.11ac APs available in the market today like the Ruckus R720 boast multiple Ethernet ports, onboard USB ports and support NBASE-T compatible 2.5Gb Ethernet connectivity.  These APs and others like them can require more than even 802.3at PoE+ can deliver in order to use all of their peripheral hardware.  Most AP products like the R720 are capable of operating at 802.3at or even 802.3af power levels, but disable some of their peripherals when operating in this mode.

If you are desperate to use the peripheral interfaces/features on your AP in the laboratory, hate power injectors, and/or absolutely need 2.5 Gb Ethernet connectivity, then it would be a good idea to look at using a more capable switch such as the Ruckus ICX 7150-48ZP which provides 16 x 2.5Gb Ethernet ports with full PoH power (100 Watts) per port.  This in my opinion is overkill, but hey, some of you out there may need it!

Virtual Machines

The first thing we need to determine is the amount of resources we need!  The laboratory should be able to host the following Ruckus products:

  • Two virtual SmartZone (vSZ) Controllers
  • Two virtual SmartZone Data Planes (vSZ-D)
  • One Smart Cell Insight instance
  • One Cloudpath Enrollment Server.
  • One SPoT Location Based Services instance

The laboratory should also have sufficient processing power and memory to host additional servers and virtual machines including:

  • One / Two virtual routers
  • LDAP / RADIUS
  • TACACS/TACACS+ server
  • NMS / Analytics
  • Other virtual instances of products you wish to test

Hardware Requirements

In order to avoid any copyright / confidentiality infringements, I can only provide the overall hardware requirements that I have calculated for the laboratory.  Specific data about the hardware requirements of each virtual appliance are available on the Ruckus Support site which you can access using your own support credentials.  Adding up the minimum requirements for each Ruckus product, and factoring in a ±30% creep in processing requirements,  memory footprint and storage over time (we want this to last!), gives the following totals:

  • CPU: 24 vCPUs / 12 Cores
  • RAM: 96 GB
  • Storage: 800 GB

We should also add in in some extra resources for any other VMs and products we may want to play with err, I mean, “test”.   The final hardware requirements that I have defined for my laboratory are:

  • CPU: 32 vCPUs / 16 Cores
  • RAM: 128 GB
  • Storage: 1 TB

CPU Performance

Selecting the right CPUs for your virtual environment is crucially important.  I strongly recommend using the Intel Core i7 or the Intel Xeon E5-2XXX series chipsets or newer.  According to what I have found in the Ruckus deployment guides, CPUs must be Intel Xeon E55XX series or above, which I believe is part of a requirement to support the Intel DPDK and Intel Virtualization Technology for Direct I/O.  Here is a list of Intel CPUs that support Intel Virtualization Technology, Virtualization Technology for Direct I/O, and Hyper-Threading Technology.  When I installed VMware ESXi 6.5.0 I received a prompt warning me that the Intel Xeon X5650 CPUs may not be supported in future versions of the ESXi.  So try to get yourself something with the E5-26XX chipsets or newer!

Networking Interfaces

It is useful to note that you don’t need a huge number of network interfaces for this laboratory.  Each physical machine should obviously have at least 1 Gb Ethernet interface.  Testing out a 10Gb/s link on the vSZ-D may sound cool, but really it just makes the whole lab more expensive and doesn’t actually do anything except let you go “Ooooh!”.  That said, if you can pick something up with 10 Gb/s interfaces, and want to use them in anger the 7150 switch will handle it just fine!

x86 Server/s

Intel NUC – Skull Canyon

The Intel NUC Skull Canyon is a brilliant small machine and highly suited to this kind of work.  It contains an Intel i7-6770 quad-core processor with up to 32GB of RAM and can use very quick SSD storage.  A unit with 32GB RAM and 500GB of SSD storage would set you back about $1000 on Amazon.  If you simply want a lab that hosts a single virtual SmartZone Controller, virtual SmartZone Data Plane and a virtual router with some other peripheral software, then this would be a great bet!  It also makes for a fantastic option if you are a road warrior and find yourself needing to take your lab equipment with you on your customer visits.  However, to provide the CPU and memory resources for all of the products described above, you would need about three or four of these machines and it quickly becomes expensive and unwieldy to manage in comparison to other options.

Home Servers

I found a list of ten good home servers for 2017 on techradar.  But after investigation (feel free to do your own) I found that the sufficiently powerful contenders cost about $4000.00 or more for a server that contains the required CPU Cores and RAM.  If you’re happy to spend the money, this could be a path for you, but if you’re going to spend that much… why not just buy the Intel NUCs and repurpose them for a fun LAN gaming weekend every now and then?

Quiet Servers

If silence is a key requirement of your lab, then the right place to look is at the products available on EndPCNoise.com.  They have a good selection of servers that are specifically built to be quiet, but like the home servers above, are quite expensive for our use case.

Refurbished Servers

If you are not worried about buying refurbished servers (this is a home lab), don’t mind a little noise, don’t care about moving your lab around with you and can accommodate a rack mount solution, then a refurbished server could be the way to go!  (EDIT: – July 25th 2017 – As the folks over at CBT Nuggets have noted the Dell R710 is a great server to grow into!)

Deep Discount Servers (DDS)

DDS purchases decommissioned servers in large volumes allowing them to sell the refurbished equipment at surprisingly low cost.  All equipment comes from qualified sources and is thoroughly tested.  Most importantly: DDS equipment ships globally and has a solid returns policy.  If you buy from the DDS website directly, you can customize your order by adding CPUs, RAM and storage and other peripherals.  If you opt to purchase via the Deep Discount Servers’ eBay store, you could get a much better deal on a pre-built server that you can customize later.  Having had a look around I am confident you will find a server with the necessary resources for approximately $1500 to $2000.

Aventis Systems

Aventis Systems is another company that sells refurbished systems and should be worth a comparative look when shopping for refurbished products.  Aventis offer a wide array of customizations and additions enabling you to basically build your server from the ground up as if it was a new system.

My Lab Hardware (Updated – July 25th 2017)

In my own lab I am using a refurbished Dell R610 from Deep Discount Servers (DDS) with the following specs:

Make Dell
Model PowerEdge R610
CPU 2 x Intel Xeon X5650, 6 Core, 2.67 GHz
(12 Cores /24 vCPU Total)
Memory 128 GB, DDR3-1333MHz  (8 x 16GB)
Storage 2 x Seagate 2TB, 2.5″, 7200RPM, 12GB/s, SAS HDD
(ST2000NX0273)
Networking 4 x 1 Gb/s RJ45 Interfaces
Power Dual Redundant Power Supplies

Hypervisor

Since we are building a Ruckus Laboratory, the hypervisor can be either VMWare ESXi 5.5 or later or KVM on CentOS 7.0 64-bit.  Both of these hypervisors are available free of charge.  I am running the free version of ESXi 6.5 (6.5.0a available here) on my hardware as I know my way around this product better.

Containers…

I have had a look at things like Docker, Canonical’s LXD and the like and it makes a lot of sense to learn about this technology.  If you do decide to use containers in this environment, it will most likely be Docker inside a Linux VM on top of the ESXi hypervisor.   This will give you the ability to spin up a multitude of small containers quickly and easily inside a single Linux OS at a much higher density than ESXi can do it.  That could be a real game changer when you’re trying to replicate scenarios or spin up VMs quickly and easily in a constrained environment.  It will also simplify a lot of your networking efforts inside the hypervisor layer as containers are hidden behind a NAT into their Linux OS Host.

Virtual Network Connectivity

The Virtual Router

You may be asking yourself: “Why do I need a virtual router if the Ruckus ICX 7150 is already performing layer 3 services?”

Here are 5 good reasons why having the virtual router (or even more than one) is a good idea.

Flexible Network Topologies

In this laboratory inside the hypervisor, many of the entities you are testing and learning about can be placed into multiple different Layer 2 or Layer 3 network configurations in the real world.  For instance, the vSZ can have a single interface and IP address for AP Control, Clustering and Management or it can have 3 separate interfaces on 3 separate subnets.  The vSZ-D can communicate with the vSZ controller via a NAT or directly over a Layer 3 network.  The APs too can be placed behind a NAT, or not.  The other entities in the network may also need to be placed into separate network segments.  Running a flat network will be simple, but isn’g going to give you the flexibility you need to implement, experiment with or learn about supported network topologies.

Minimizing Physical Link Utilization

Some of the virtual appliances require Layer 3 connectivity.  You may only have a single physical NIC entering your server.  Do you really want all that ethernet traffic between layer 3 entities going back and forth to the L3 switch on the ONLY ethernet link?

Compatibility with Other Network Environments

You may need to NAT out of the LAB to get onto your home network, or into a customer’s network for the purpose of a trial or proof of concept.  You can’t always change the network you have to plug into, NAT is a good way of taking all that pain away.

Network Separation

Separating the virtual and physical network environments.  You can use the 7150 switch to provide layer 3 services to locally connected APs and to the hypervisor hosts on separate subnets.  The virtual routers in the virtual environment can manage connectivity to the virtual entities.  This configuration allows you to keep the hypervisor host network out of scope in testing and customer trials.

Remote Access

Remote Access – The Layer 3 switch is not going to give you the ability to gain remote access to your lab environment.  You also want to be able to completely limit remote access to the virtual environment only.  This is useful when allowing someone else to work and play in the virtual lab.  Something gone wrong? No worries, they can’t have touched the hypervisor or physical network – simply reset everything to the snapshot you took and carry on.

vRouter Firmware Options

Here are a couple of the options I am presently aware of for implementing a virtual router.  If you have other options feel free to investigate those!

Mikrotik RouterOS

Mikrotik RouterOS is a well proven platform that can run inside an x86 server environment on top of the VMWare ESXi hypervisor.  It comes with a plethora of features and the ability to scale to very large networks.  It also has a decent Web UI that you can use via a broser if thats your thing.  The routerOS software also supports an API that closely mimics the CLI commands.  For the purposes of this laboratory, the Level 4 license will prove more than sufficient.  Each license costs only $45.00 which is great value considering the capabilities it gives you.

VyOS

If any of you out there have used the older Vyatta Core routers and were sad to see them meet their demise, the VyOS router is for you!  VyOS is an open source project that continued from where the Vyatta Core project ended.  This is a very capable router without the frills.  If you haven’t had a peek at this, you really should.

That’s all for now!

Categories
Ruckus Ruckus ICX Switches Ruckus Wi-Fi

Building a Ruckus Home/Office Laboratory on a Budget – Part 1

A Growing Product Portfolio

If you work with Ruckus Wireless equipment and have been keeping up with the growth of the company’s product portfolio, you may have realized that they don’t just sell Wi-Fi Access Points and WLAN Controllers anymore.   Several short years ago, you would have been forgiven for having just a ZoneDirector and some Access Points lying around that allowed you to test the latest code release in your environment for any specific bugs pertinent to your customers.  Today, however,  you may require a somewhat more capable environment to fully embrace what Ruckus has to offer.   The Ruckus product portfolio has now grown to include:

If you want to work with the comprehensive set of products that Ruckus has to offer, it makes sense to be able to work with them all in a laboratory environment.

Network Function Virtualization to the Rescue

Thankfully, building such a laboratory today (circa 2017) is actually relatively cheap due to the benefits of NFV and the ability to place some network functions in the cloud if needs be.  If this was 2012 or 2013, you’d probably catch yourself buying a whole bunch of second hand networking appliances and stringing them together whilst cajoling your friends with close ties to networking vendors into giving you free code upgrades.  Shh, it doesn’t need to be that way.

Nowadays, you can simply get yourself some capable x86 hardware or an Amazon / Google Cloud / Microsoft Azure account along with some virtual appliances and you are good to go!  The lower cost of x86 hardware, availability of free hypervisors like ESXi / KVM and cheap cloud services means that you can now run an extremely capable laboratory environment for a fraction of what it would cost for a pure hardware appliance based environment.

NFV & Cloud

Ruckus have developed ALL of their new software products to run entirely in virtualized or cloud environments.  The SmartZone controller has been designed to use a single platform whether deployed as a physical or virtual appliance.  This means that running a virtual instance of the SmartZone controller will allow you to test and understand just about every feature and facet of a SmartZone deployment the same as if you were using the hardware appliance.  All other Ruckus software products are available as virtual machines capable of running on either VMWare or KVM and are also available on several cloud providers (check the specific product release notes and installation guides).

Ready to begin?