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 …
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 🙂
I’ve been reading about directed broadcasts recently. According to RFC2644, directed broadcasts should not be forwarded by routers to the end hosts on the destination subnet. It wasn’t very clear if routers should drop directed broadcasts. If so, should these be dropped by intermediate router, or the one at the final destination? So, I decided to build a small lab and capture few packets. Read more …
We all know about very useful IOS command show inventory, which displays asset’s detailed information, including installed SFPs and their serial numbers. However, in case of AireOS, show inventory supplies very limited information – only chassis model and serial number, there’s no information about SFPs. Well, is there a way to find SFPs models and serial numbers? Yes, with the help of the following hidden AireOS command:
debug fastpath cfgtool --dump.sfp
Here’s an example output from one of ours WLCs:
(Cisco Controller)>FP0. Port SFP Vendor Transceiver Type OUI PartNumber Rev SerialNumber DateCode Auth 1 CISCO-METHODE (0x08)1000BaseTX SP7041-R MTC201XXXXX 16030701 ok 2 CISCO-METHODE (0x08)1000BaseTX SP7041-R MTC201XXXXX 16030701 ok FP0.
The model, the part and serial numbers are all there.
I hope you find this helpful.
There are a number of ways to convert Lightweight AP into Autonomous. I personally prefer two.
First method is to use Console connection. It works very well, but of course requires a console, which in some cases can be troublesome – i.e. someone will have to arrange a PC connected to the network and console connection to the AP, which also has to be reachable from the PC once IP address is configured (i.e. L3 reachability). It also requires to press and hold Mode button before powering up an access point, which then has to be held up to 30 seconds until LED turns red. After that Mode button can be released and AP falls into rommon. Now, it’s just a matter of few commands:
set IP_ADDR 192.168.1.100 set DEFAULT_ROUTER 192.168.1.1 set NETMASK 255.255.255.0 tftp_init tar -xtract tftp://192.168.1.10/c1140-k9w7-tar.153-3.JC2.tar flash:
These commands assign IP address, netmask and default gateway to AP, initialize TFTP service and then download .tar archive with the image from TFTP server (192.168.1.10) and extract its contents into flash. After this step is completed, AP can be either power cycled, or forced to boot with new image (using “boot” command). Also, I recommend to format flash before extracting new image using “format flash:“.
Works like a charm, but as I previously stated, requires a direct console connection.
Second method allows to downgrade Lightweight AP with Autonomous IOS without console access, but it requires AP to be accessible via SSH or Telnet. Once in AP’s CLI execute the following:
debug capwap console cli
This command enables full range of CLI commands, like config terminal, archive, or format flash (which by default are not available in LAP’s CLI). Therefore, it is now possible to do the following
archive download-sw /overwrite tftp://192.168.1.10/c1140-k9w7-tar.153-3.JC2.tar
Reboot and you’re on IOS code now.
Hope this helps.
It’s been a while since I’ve posted anything on my website. I had a crazy year, had a lot of work that ruined all my plans to study a lot. Hopefully it’s now sorted with my management and next year is promised to be much better from the work/life/study balance perspective. I know I wasn’t a best webmaster and didn’t respond to many of your comments – I promise I will improve and reply to all comments in the coming weeks. I am going for WISECURE exam in less than two weeks from now, so wish me luck.
In the meanwhile, I’d like to share an undocumented feature of Cisco Prime (well, at least I wasn’t able to find any guidelines on that in Cisco Prime documentation). I have recently configured Prime for images archiving, but few days later realized that it fails to copy images from Catalyst 3850 switches. All transfer modes have been failing – FTP, SFTP, SCP and TFTP. There are no settings in Prime that relate to SCP and SFTP (you can only enable/disable FTP and TFTP servers). I’ve done some research and found that for SCP downloads Prime is acting as a client. Therefore, Catalyst 3850/3650 switches must be SCP servers.
To enable SCP server on Catalyst 3850/3650 execute the following global configuration command:
ip scp server enable
Once applied, Prime will be able to archive IOS-XE images from Catalyst 3850/3650s. However, there is restriction. Cisco Prime cannot archive an image from Catalyst 3850 if it was installed using INSTALL mode. That is, when BIN package is unpacked into few separate files. Only BUNDLE mode is supported for archiving. Not great huh? Cisco does not recommend to use BUNDLE mode for image distribution on Catalyst 3850s, but at the same time Cisco Prime can’t archive image if it was distributed using recommended INSTALL mode.
Cisco is so Cisco…
This is probably the best explanation of 802.11ac beamforming I’ve seen so far. Shame on you Cisco!