It’s been a while since Cisco has announced Smart License to replace Traditional PAK-based licensing. Overall, this new system brings loads of benefits, such as ability to track license utilization, see all managed instances by hostname, transfer licenses and product instances between virtual accounts (i.e. sub-domains) and many other features. However, it also brings some challenges and surprises that everyone must be aware of.Read more …
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.
So, what is it then? Read more …
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 …