Author Archives: Tim Dmitrenko

Cisco DNAC Journey Part 2 – SWIM

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

Read more …

Cisco DNAC Journey Part 1 – Expectations and Reality

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 🙂

Read more …

Perpetual and Fast PoE are friends, m’kay?

PoE icon was borrowed from LightwareHave 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

Read more …

802.11 Duration/ID Field

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.

EEM Tricks: Automatic Failover (Internet)

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 …

DHCP Snooping and Option-82

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 …

EEM Tricks: Scheduled Packet Capture

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 …

Catalyst 9500 and StackWise Virtual

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 …

Cisco ISR4K Throughput related hidden command

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 …

ECSE Takeaways

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
  • ESS cheats
    • 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.
  • Useful Tools
    • 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
    • Kismet: linux-based wireless sniffer/packet capture software

That was a great week in Oxford. Hopefully I haven’t misinterpreted the information above 🙂