I’ve tried to upgrade a number of my lab devices using DNAC today. Generally speaking, it works perfectly fine, when everything is compatible (remember my note about Greenfield deployments in the last blog post?). I’ve managed to upgrade three Catalyst 3850 switches without any issues. All switches were running IOS-XE version 16.6.4 prior to upgrade and were upgraded to 16.6.4a.
The following SWIM methods have been tried:
Distribution, followed by instant Activation
Distribution, followed by delayed Activation
Distribution only, followed by Activation as a separate task
We’ve just finished Cisco DNA Assurance PoV… what can I say about it? Not much… It feels like a right product, but way too young for mass adoption. We only deployed the appliance itself with the aim to try DNA Assurance. However, we faced a number of issues from Day 1 even though it was a mentored install. I just thought I will share some information and maybe it will make someone’s life easier 🙂
Have you ever heard about two new PoE enhancements that are available on some Catalyst 3850 and all Catalyst 9K platforms? If not, you’re not alone. I only found out about these few months back by accident when I was troubleshooting some issues. There are two great features available for you to configure on PoE-enabled switches:
Perpetual PoE: preserves power during warm reload
Fast PoE: provides power to the port after cold start at pre-outage levels
I always knew that Duration/ID field is used by CSMA/CA to predict when wireless medium becomes free. However, I was confused by some publications which stated this field is set to the amount of time (in microseconds), required to transmit current frame, wait SIFS and then receive ACK. CWNA Sybex book has finally helped to understand this better.
Even though Duration/ID field tells STA how much time it has to wait before medium becomes free, it is set to the duration of SIFS + ACK. It doesn’t include the time required to transmit current frame. It kind of makes sense – to read the value from the field, STA needs to receive the frame in full and check its FCS before it can set the NAV with legitimate value.
Also, didn’t know ACK/Block ACK frames always have their Duration/ID field set to 0.
Again, makes sense. Transmission completed, all NAVs have to be reset to 0 – medium is ready for the next transmission.
Good to know: Historically this field was defined to identify STA’s association ID within PS-Poll frame (legacy power management) or Duration in any other frame. In reality, legacy power management is not being used and this field is mostly used as a Duration ONLY nowadays. However, name of the field is still Duration/ID.
When our company decided to deploy local Internet breakouts in every single office (cloud readiness) there was a design concern around high availability. Even though our firewalls are being deployed using HA pair, a decision has been made not to overdesign service provider (SP) edge sublayer. In particular, we decided not to deploy more than one external switch. Even if we did, 99% of branches would have only one circuit deployed using single physical media. If switch and/or ISP fail, then manual intervention would be required (recabling, or routing adjustments)… In presence of regional Internet breakouts it was an obvious choice to include these into design as failover component. The question was… how to make users experience as seamless as possible if local Internet breakout fails? EEM was there to help! Read more …
Even though I always had a solid high level understanding of DHCP Snooping feature, I had no idea what happens ‘under the hood’. Until now. We’ve never been using this security enhancement (for whatever reason), but things are changing now. You’ll be surprised to find out that we’re deploying DHCP Snooping primarily to improve Cisco ISE Profiling. If you want to know more, read about Cisco IBNS 2.0 and Profiling Design Guide, specifically profiling using Device Sensor and Radius accounting. I might be able to cover this topic in detail sometime later (let me know if it’s of interest). Today, however, I’d like to concentrate on DHCP Snooping. Read more …
It’s going to be a short note. I’ve finally started to explore the world of automation (EEM) and coding (Python) and I love both! I used to code long time ago using Perl and PHP, and now I regret I’ve ignored these skills for the last decade (at least). I will be publishing some EEM and Python snippets here from now on. So, today I’d like to share a small piece of EEM script that, in short, waits until a specific time, then starts packet capture of all packets destined to CPU on the router, waits for X seconds, then terminates capture, exports it to the FTP server and removes 95% of its traces from the running config. This can be simplified or made more sophisticated for as much as your imagination allows… Read more …
Hi chaps. Fisrt of all, I would like to apologize for lack of activity on this blog. The company where I work was hit by NotPetya ransomware last summer. As a result, we worked absolutely crazy hours for many months to recover all our services and secure our network. I simply had no spare time to contribute to this blog. Anyway, things are much more stable and steady now, so I will try to get back to my hobbies.
Today I would like to give you a brief overview of StackWise Virtual technology, which Cisco has introduced in Denali 16.3.3 IOS-XE.
Originally, only Catalyst 3850 48XS switching platform supported this feature. At the moment of writing of these notes, Cisco announced support of the feature across all Catalyst 9500 series.
If you have ever worked with Cisco ISR4K platform, you probably know that these routers have plenty of horsepower. That is, you will probably hit the licensed throughput limit before you even get to 50% on CPU. This can be very frustrating when you troubleshoot, because you need to know (a) platform’s throughput (b) current load. What I always hated is the fact that Cisco doesn’t make required information available to public. For example, the only document about ISR4K performance I found was classified as ‘Cisco Confidential’ and even that one lacked any information about troubleshooting guidelines. Anyway, I’ll keep this post short. Here’s the troubleshooting methodology I use (inc hidden commands I got from Cisco TAC). Read more …
Have just finished Ekahau Site Survey course in Oxford and here are my takeaways from it:
Move away from 2.4GHz completely (inc. BYOD and Guest networks if possible) – don’t use it in modern world
Avoid using multiple SSIDs – beacons make the air dirty (have captured 60MB of beacons on one channel in 15m as a test)
Don’t install APs in corridors or hallways – signal from omni antennas propagates on hundreds of meters in free space
Make sure signal strength from 2nd strongest APs meet the main requirements if voice roaming is of concern. This is an equivalent of Cisco’s channel overlap of 10-20-30% requirement, which is hard to measure or prove.
If APs are installed in rooms/offices, put them away from windows to avoid waste of RF energy sent towards the street.
Mirrors do not significantly affect 2.4GHz (and 5GHz) – waves are still lengthy enough to penetrate through mirrors (?).
Adjacent channels interference is more destructive than co-channel interference, because devices on adjacent channels do not play nicely when they access the media (do not contend)
Radio Tap header information is added by the client. RSSI and noise levels reported by clients are virtual and vendor specific. NICs do not see RF shapes to measure noise and RSSI, but spectrum analyzers do.
Ch144 on 5GHz was introduced with 802.11ac
Don’t use small objects to define scale, such as doors, desks and so on. This increases error level.
Use distance between objects to define scale on one floor, then use alignment points to define scale on all others.
Use coverage and coverage exclusion areas to make ESS reporting more accurate (coverage percentage)
If floors are more or less identical, draw one and duplicate the rest (using image swap trick). This will help to save a lot of time as this trick copies all objects, including alignment points and scales.
Buffalo WMR-433: Very tiny WiFi router which can reach out on tens of meters
Theodolite: iOS app to measure azimuth, elevation, GPS coordinates – helps with outdoor deployments
NetScout Link Sprinter 300: A link tester. Checks all layers of TCP/IP protocols suite (physical/data link, network, transport and application). Capable to send results by email.
HORST: linux-based lightweight 802.11 analyzer with text interface