Showing posts with label Cisco. Show all posts
Showing posts with label Cisco. Show all posts

Sunday, September 2, 2018

Meraki Layer 3 Firewall Rules

Meraki has traditionally been known as a niche player in the networking world since its inception.  Their wireless access points and switches broke into the market in K-12 school system networks, gained a market share of higher ed networks, and slowly started chipping away in the private sector network space.  Their niche was that they made it easy to manage a wireless and switch network without the need for a highly skilled, trained, and costly Cisco engineer or contracting out the work to a business that provided the same.  Meraki provides a fully capable GUI to make life easier for those who don't like a command line, or have enough time to spend in Cisco's CLI to make it second nature for the admin skills.

That niche market started to change for Meraki when Cisco aquired them to augment their traditional network technologies.  It's still hard to figure out completely where Cisco is taking Meraki while holding onto its traditional portfolio of networking technologies, but that is not the point of this post.  What we do know is that we are seeing more and more Meraki networks replacing traditional Cisco (or other Cisco-esque brand of networks) and you are now seeing Meraki gear in the enterprise space.

As I have played with meraki in my lab and deployed Meraki in a few networks, I have found that there is lacking information out there for best practices in configuring the layer 3 firewall rules.  For someone like me who came from a Cisco background and was used to how the ASA layer 3 rules worked, it was sort of shocking to me to see that the default Meraki layer 3 rule on all their MX appliances are a wide open "ANY-ANY-ANY-ANY" rule.  As I was trying to learn the Meraki interface of how to configure Layer 3, I ran into a couple snags.  I was looking high and low to find some assistance in the Meraki KB's but came up empty, and google-fu proved no luck either.  I just wanted a simple example of how to configure the rules needed out of the box to make it work without leaving all ports on all vLAN's wide open to the world.  You know, like the ASA.  The default rule should be a deny "ANY-ANY-ANY-ANY" then let me build my list of rules in Layer 3 from there for 80,443,22,, etc...

So here you go.  Below is a level set footing to start you on configuring some out of the box layer 3 firewall rules on a Meraki MX Security appliance.  


This will get your MX secure after you bring it online as well as provide you the most basic functionality for the basics of your L3 network.

I love the Meraki MX appliances overall.  They truly are easy to setup and configure compared to a ASA from Cisco.  For folks like me who don't work in firewalls every day anymore it saves a ton of time in trying to remember commands at the CLI when the networking logic is still in our heads.  There are two big features that I constantly bug Meraki to add.  The first is a simple way to take the layer 3 rule list from an MX appliance (like the one pictured), and have the ability to download/upload via a .CSV file.  The second is to give us an easy & visual way to view live traffic without using packet capturing so we can visibly see a network connection's source IP, destination IP, source port, and destination port.  The ASA's have this built into their monitoring tools and its awesome to use when troubleshooting connectivity problems.

Happy Networking!

Cheers!


Wednesday, July 27, 2016

Cisco Wireless AP's move from away from "A" domain

In 2014, the FCC instilled some new rules regarding frequencies in the atmosphere.  This regulation change directly effected Cisco AP's.  For so long, we have been able to get the "A" domain AP's, but if you have tried to order a new AP recently, you may have noticed you received a "B" domain AP.  This has caused some Network Admins headaches as it can mean for a disruptive upgrade in their wireless network should they be using their Cisco wireless Access Points in conjunction with a wireless controller.  You have to update your wireless controller to accept the latest iOS versions of the -B Regulatory domain APs if it is not currently ready.  I ran into two customer's networks where this was the case already.  The "A" APs are still order-able by Cisco, but Cisco is no longer shipping the "A" APs, they are shipping the "B" APs.  So it comes as a little bit of a shock to some Network Admins when they put their newly ordered APs into the network only to find that its not working, they are not the right regulatory domain they ordered, and that they have to do a controller upgrade.

Here is an explanation of why Cisco switched to no longer shipping the "A" regulatory domain APs.

Why did Cisco move from “A” Reg Domain to “B” Reg Domain?

  1. In 2014 the FCC Announced a Rule Change that affected the U-NII Bands ( 5 GHz).
  2. In 2012, the FCC open up Channel 144 for use in 802.11. (However, not many manufactures of endpoints or APs updated their equipment to support this channel at the time).

I.                   The new “-B” regulatory domain:

  • Adds channels 120, 124, and 128 in response to the 2014 rule Change. 
  • Adds channel 144 in response to the 2012 rule change.
  • Allows the use of U-NII-1 band for indoor and outdoor use (previously only indoor only)
  • The change in U-NII-1 band also allowed for increased power usage in this band.
(from 50 mW à 250 mW for client device; 1 W for AP)

Ø  These changes require actual changes in the hardware to be able to broadcast on these frequencies and at this power rating.
Ø  I fully expect all APs moving forward that support 5Ghz to operate in the “B” regulatory domain if deployed in the US.
II.                 Primer on UNII Bands
  1. Currently 4 sets of UNII Bands:
·       UNII 1 (Channel 36-48) (5.180 to 5.240 GHz, 4 channels)
·       UNII 2 (Channel 52-64) (5.260 to 5.320 GHz, 4 channels)
·       UNII 2e (Channel 100-144) (5.500 to 5.720 GHz; 12 channels)
·       UNII 3 (Channel 149-165) (5.745 to 5.825 GHz; 5 channels)
  1. Each Band is a set of frequencies, and each band has a different set of requirements for Tx (Transmit) Power and EIRP (total radiated output from AP).











  1. The Increase in the number of channels means that we can use more 40 MHz, 80 MHz, and MHz wide channels that do not overlap.
  2. The wider channels are how 802.11ac Wave 2 can achieve such a high data rate compared against 802.11ac Wave 1.  (Wave 2 supports 80 Mhz and 160 MHz channels).
III.              Channel Width Primer 
  1. Wider channel means a higher potential data rate (the connection between the wireless devices and the APs).  (Think about a two lane road vs. a massive interstate). 
  2. Non-overlapping channels mean that the same devices are not contending for the same airspace. 
  3. A single RF channel represents a contention space.  Any device broadcasting on that channel (even if it is a neighboring AP on a totally different network) all content for that same airspace. 
  4. 5 Ghz channels are separated by 20 MHz channel width.  (So combining channel 36 and channel 40 gives you a 40 MHz wide channel).
  5. Channels must be contiguous (in a row) in order to channel-bond to a wider channel.
IV.              Non-Overlapping Channels
  1. The new FCC regulations have allowed more channel availability for the 5 GHz spectrum.  This was done to alleviate the overcrowding that is already occurring (similar to the way 2.4 GHz band already has overcrowding).
  2. This, by proxy, also allows for high potential data rates.  Higher data rates means that the medium (the RF space) is available more often than unavailable.  (Only a single device can talk on a single channel at a time.  It’s physics 101: two devices cannot occupy the same space at the same time).
  3. Higher availability of the medium is the true metric of a wireless network, not data rate, throughput, or bandwidth. 
V.                Channel Count by Width (See Picture Above)
  1. 20 MHz Wide Channels
25 available
  1. 40 MHz Wide Channels
12 available
  1. 80 MHz Wide Channels
6 available
  1. 160 MHz Wide Channels
2 available
  1. If the FCC rules had not changed:
1.      1x - 160 MHz Wide Channel
2.      5x – 80 MHz Wide Channel
3.      This would make Wave 2 almost impossible to deploy at full data rates
4.      New channels are being proposed which are indicated in RED.
VI.              Data Rate vs. Throughput
  1. Wireless is half duplex.  A device can Rx (receive) or Tx (transmit), but not at the same time.  It can also not send and listen at the same time.  It can do a single action at any given moment. 
  2. Data Rate – The “wire” (connection speed) between the device and the AP.  For instance, my average data rate at home is somewhere around 300 Mbps between my iPhone and my AP).
  3. Throughput – The actual speed of the data going over the wire.
(In a wired, full duplex network, throughput and data rate usually are equal).
  1. Aggregate Throughput – How much actual data the AP is bridging from the wireless connection to the wired one.  (An AP is essentially a device that bridges these two mediums.  Multiple devices can be connected to an AP at any given moment). 
VII.           Actual Speeds (Throughput)
  1. 802.11 a/g has a max data rate of 54 Mbps.
1.      Due to overhead and media access methods, actual throughput is no greater than ½ the max data rate. 
2.      This means that with a perfect wireless connection, your max throughput is about 23 Mbps. 
  1. 802.11 n has a max data rate of 450 Mbps. 
1.      Due to overhead and media access methods, actual throughput is not greater than 60-70% of max data rate.
2.      This means with a perfect wireless connection, your max throughput is closer to 270 Mbps).
  1. 802.11 ac Wave 1 has a max data rate of 1.3 Gbps.
1.      Due to overhead and media access methods, actual throughput is not greater than 60-70% of max data rate.
2.      This means with a perfect wireless connection, your max throughput is closer to 780 Mbps.
  1. 802.11 ac Wave 2 has a max data rate of 3.5 Gbps (the official spec actually calls for nearly 7 Gpbs, but we simply cannot shove any more radio chains into current devices.  The maximum we have seen is 4x4:4 where the spec calls for 8x8:8).
1.      Due to overhead and media access methods, actual throughput is not greater than 60-70% of max data rate.
2.      This means with a perfect wireless connection, your max throughput is closer to 2. Gbps
3.      This data rate is only achievable:
a.       with a 160 MHz wide channel (of which there are only 2 currently that don’t overlap)
b.      An extremely strong RSSI (signal from AP) of around -40 dBm (which essentially requires you to be around 10 feet away from the AP)
c.       A low ceiling or highly directional antenna to stop multi-path (reflections of the RF signal that, depending on phase, can give you worse signal quality).
d.      A very high SNR (signal to noise ratio) which requires an environment with very little interference from all the various things that can cause interference on that channel.  

Monday, August 10, 2015

Cisco ASA5505 Config from ASDM (Start to finish)

I have been known in my 15 years of the IT industry among my friends as a "GUI Girl".  This is something that never bothers me, even though I have gotten extremely comfortable in the CLI of Cisco routers and switches of the last 5 years.  However, if you are not in the CLI of a Cisco Security appliance daily, it can still be tough to setup the likes of an ASA appliance from start to finish.  I have administered and configured lots of ASA devices in my career, but mostly from the ASDM and have not found much help online on how to do so.  I took the opportunity on my last configuration to document the process for others to use if they so choose!  This process assumes you know the basic ins & outs of the ASDM interface.  This process is also for a basic configuration and for access to manage from the WAN.  DO THIS AT YOUR OWN RISK!!!  I am not suggesting someone leaves management access from the WAN on, but when your deploying a new appliance, its nice to be able to quickly access it after deployment to clean up and configurations or issues that come up.

Steps to Setup Appliance from ASDM

- Change management interface to allow from all networks (0.0.0.0)
- Change inside IP for device. (Will need to set static IP on laptop for that subnet to reconnect).
- Change DHCP server range to match subnet if necessary.  Set lease time to: 432000 (5 days)
- Change outside IP for ISP
- Change management interfaces for networks you want to allow and remove previous 0.0.0.0
- Set static route for next hop to ISP:
   
- Set device name and password
- Set system time
- Set NTP servers
- add users (admin) with passwords.  Access level 15
- configure the dns client for the asa if its doing dhcp
- Make sure under file access SCP is enabled
- Set default NAT

- For SSH & Telnet access, under AAA authentication set the following:

- Send the following command for the RSA: #crypto key gen rsa gen mod 1024

Update iOS and ASDM

- copy the new ASA iOS and ASDM files to the local storage.  Current versions: ASA922-4-k8.bin & asdm-732.bin  (I like to use WinSCP to copy files to the appliance).
- run the following command: #boot system flash:asa922-4-k8.bin
- run the following command: #asdm image flash:/asdm-732.bin
- The following are basic services and rules to setup for the trust network:





Cheers!



Wednesday, October 16, 2013

Cisco Switch err-disable port status

I ran into an interesting problem today in my young Networking & Cisco career.  I got a call about a switch port on one of our stacks having a status of err-disabled.



This is most likely because we run BDU on our network and something at some point got plugged into that port that the switch did not like and put it in this status.  There are a number reasons that a switch could put a port into this status.  I found a great article that explains thoroughly the reasons and how to discover why the switch port got put into the err-disabled status.  Read it here: http://www.cisco.com/en/US/tech/tk389/tk621/technologies_tech_note09186a00806cd87b.shtml

The quick way to get the port back to normal mode is to get to the configuration of the disabled interface and issue the shutdown command and then issue the no shutdown command.  So your essentially power cycling that switchport in the eyes of the OS on the switch.  Now you can see a happy switchport!



Cheers!