As an old-time Unix/Linux guy, I’ve been wanting the IOS equivalent of the “wc -l” command for oh, about a million years now. Juniper has had this in JunOS for quite some time, via their “count” command. In Unix/Linux shell environments, “wc -l” counts the number of lines in the input. This is very useful for things like counting the number of unused ports on a switch. Until recently, I was stuck with using SSH one-liners to pipe IOS commands through a shell filter, like this:
$ ssh 10.1.1.2 'sh int status | i not|disa' | wc -l
Password:
19
In English: this executes the command “show interface status | include not|disa” via SSH on the remote device, which returns all the lines that are in either the “notconnected” or “disabled” status. Then it feeds those lines to the “wc -l” command, which counts the lines.
A couple of months ago, however, I noticed that recent versions of IOS for the Catalyst access switches (3560/3750, and probably the 2960--I haven’t tested the latter) have a “count” filter:
Switch#sh int status | count ?
LINE Regular Expression
Switch#sh int status | count not|disa
Number of lines which match regexp = 19
Anyway, nothing particularly groundbreaking here, just a nice feature that’s long overdue--I hope it gets ported into other IOS images as well.
Monday, September 27, 2010
Friday, July 2, 2010
Cisco Live 2010
This was my 6th consecutive year at CiscoLive (formerly known as Networkers), and as always I had a great time. I thought I'd write down a few brief thoughts on my sessions and other experiences this year.
802.1x 8-Hour Techtorial
This was the first time I've done a "techtorial" (Cisco's term for a 4 or 8 hour expanded seminar that costs extra) since 2006, and it was probably the best one I've done. All of the presenters were excellent, and they did a great job of keeping the class engaged by switching frequently between lecture and live demonstrations by three different instructors. They also included a real-world case study, presented by the actual customer involved (a large Canadian university). Cisco has a tendency to make up artificial case studies (or anonymize them to the point of making them pointless), so it was great to see a live customer on stage, presenting the entire implementation process, warts and all.
LISP - A Next Generation Networking Architecture
I have read a fair bit about LISP over the last couple of years, but this was the first time I've gone to a session on it. Basically, Dino and company are trying to solve three or four of the biggest problems in networking in one fell swoop: 1) global routing table size, 2) certain types of IPv4/IPv6 transport issues, 3) virtual machine mobility, and possibly 4) other mobility problems. I really don't have the background to evaluate a protocol that's designed to solve extremely difficult problems at a global scale, but it was fascinating to see the thought process and design issues involved.
Routed Fast Convergence and High Availability
I have been hearing about this session for years, and it didn't disappoint. I was already familiar with most of the tools discussed, but the devil is in the details, and I came away with a much better understanding of many techniques used to achieve fast convergence in routed networks.
Smart Grid: Developing a Communications Architecture for the Utility of the Future
I didn't intend to visit this session initially, but the speaker was late for my scheduled session, and I had no interest in sitting around waiting for him to show up. This session was happening nearby, and I knew that Bill Parkhurst is something of a network architecture guru, so it was an easy pick. Even though I have absolutely no background in the electrical utility world, this was a very useful session from a general professional development perspective.
Unified HA Network Design: The Evolution of the Next Generation Network
If I could recommend only one session on large-scale network design, this would be it. These guys are working on the largest, most failure-sensitive networks on the planet, and they're giving away what they've learned. What more needs to be said?
Advanced Security Management & Incident Response
This was my second time attending this session (the last time was in 2007), and it was definitely worth attending a second time. I really like operationally-focused sessions (as opposed to product-focused ones), and that's what this one is all about. The presenters are front-line senior incident responders in Cisco's internal security organization, and it's great to see how they deploy Cisco tools and even (gasp) non-Cisco tools to respond to actual security incidents. I really hope they can convince the powers-that-be to let them run this as an expanded, 8-hour techtorial on security operations.
Those are the highlights of my sessions. I didn't attend a single session this year that was actually bad, but those were the ones that stood out the most.
Other thoughts: the meals were above average compared to previous years, except for breakfast. I hate getting to a breakfast and seeing nothing but bread products and some random, lonely looking fruit. The CCIE party was great; probably the best one I've attended. The CCIE NetVet reception with John Chambers was also excellent. My biggest complaint continues to be the ominous warnings about a $100 fee to replace a lost conference badge. I've never lost mine, but this just seems patently ridiculous.
As always, though, simply meeting other networking-focused professionals and renewing friendships with people I've known from previous years was the best part of the show.
Hoping to be back next year!
802.1x 8-Hour Techtorial
This was the first time I've done a "techtorial" (Cisco's term for a 4 or 8 hour expanded seminar that costs extra) since 2006, and it was probably the best one I've done. All of the presenters were excellent, and they did a great job of keeping the class engaged by switching frequently between lecture and live demonstrations by three different instructors. They also included a real-world case study, presented by the actual customer involved (a large Canadian university). Cisco has a tendency to make up artificial case studies (or anonymize them to the point of making them pointless), so it was great to see a live customer on stage, presenting the entire implementation process, warts and all.
LISP - A Next Generation Networking Architecture
I have read a fair bit about LISP over the last couple of years, but this was the first time I've gone to a session on it. Basically, Dino and company are trying to solve three or four of the biggest problems in networking in one fell swoop: 1) global routing table size, 2) certain types of IPv4/IPv6 transport issues, 3) virtual machine mobility, and possibly 4) other mobility problems. I really don't have the background to evaluate a protocol that's designed to solve extremely difficult problems at a global scale, but it was fascinating to see the thought process and design issues involved.
Routed Fast Convergence and High Availability
I have been hearing about this session for years, and it didn't disappoint. I was already familiar with most of the tools discussed, but the devil is in the details, and I came away with a much better understanding of many techniques used to achieve fast convergence in routed networks.
Smart Grid: Developing a Communications Architecture for the Utility of the Future
I didn't intend to visit this session initially, but the speaker was late for my scheduled session, and I had no interest in sitting around waiting for him to show up. This session was happening nearby, and I knew that Bill Parkhurst is something of a network architecture guru, so it was an easy pick. Even though I have absolutely no background in the electrical utility world, this was a very useful session from a general professional development perspective.
Unified HA Network Design: The Evolution of the Next Generation Network
If I could recommend only one session on large-scale network design, this would be it. These guys are working on the largest, most failure-sensitive networks on the planet, and they're giving away what they've learned. What more needs to be said?
Advanced Security Management & Incident Response
This was my second time attending this session (the last time was in 2007), and it was definitely worth attending a second time. I really like operationally-focused sessions (as opposed to product-focused ones), and that's what this one is all about. The presenters are front-line senior incident responders in Cisco's internal security organization, and it's great to see how they deploy Cisco tools and even (gasp) non-Cisco tools to respond to actual security incidents. I really hope they can convince the powers-that-be to let them run this as an expanded, 8-hour techtorial on security operations.
Those are the highlights of my sessions. I didn't attend a single session this year that was actually bad, but those were the ones that stood out the most.
Other thoughts: the meals were above average compared to previous years, except for breakfast. I hate getting to a breakfast and seeing nothing but bread products and some random, lonely looking fruit. The CCIE party was great; probably the best one I've attended. The CCIE NetVet reception with John Chambers was also excellent. My biggest complaint continues to be the ominous warnings about a $100 fee to replace a lost conference badge. I've never lost mine, but this just seems patently ridiculous.
As always, though, simply meeting other networking-focused professionals and renewing friendships with people I've known from previous years was the best part of the show.
Hoping to be back next year!
Wednesday, May 5, 2010
Friday, April 16, 2010
Friday, April 9, 2010
Wireshark Network Analysis
For the last week I've been reading Laura Chappell's new book, Wireshark Network Analysis. I pre-ordered the book and was looking forward to it eagerly.
Overall, it's a superb book. First and foremost, I appreciate the fact that the writing has some personality to it. I've really enjoyed the author's footnotes, anecdotes, and humor.
Second, I like the fact that it's exhaustively thorough with both features and examples. There are relatively few cases where the Chappell simply describes a feature without offering an example of how it might be used in practice. Where she does so, the example is obvious enough to be unnecessary.
Particularly good are the examples of practical Wireshark tips and tricks in the protocol-specific sections. As an advanced Wireshark user with a thorough background in the internals of common network protocol operations, I was worried that this would be just another set of explanations of how various protocols work. Those explanations are there, but they are interspersed with many great tips and tricks about how to analyze the protocols more quickly and efficiently with Wireshark. I kept thinking, "why didn't I ever think of using that trick before?"
There is a lot here for both beginning and advanced Wireshark users.
I don't have a lot of criticisms to make: I thought the security sections were interesting, but a little dated. Exotic network and transport layer attacks just aren't all that common anymore; it would have been cool to have seen some analysis of a modern application-layer attack in action.
The other thing I would have liked is a discussion of the Lua scripting-language extensions to Wireshark. There is very little out there on the Internet about this so far, and most of what exists is oriented toward expert-level programmers. I was a bit disappointed to not even find Lua in the index. Still, the book is already huge, and adding a section on scripting might have made it unreasonably long. Maybe a volume 2?
Summary: if you use Wireshark, just buy it. This is an amazingly practical, hands-on book that will make you faster and more productive when analyzing network captures.
Blogging disclaimer: I paid full retail price for the book (and managed to somehow miss all the promo coupons) and am not being compensated in any way for this review.
Overall, it's a superb book. First and foremost, I appreciate the fact that the writing has some personality to it. I've really enjoyed the author's footnotes, anecdotes, and humor.
Second, I like the fact that it's exhaustively thorough with both features and examples. There are relatively few cases where the Chappell simply describes a feature without offering an example of how it might be used in practice. Where she does so, the example is obvious enough to be unnecessary.
Particularly good are the examples of practical Wireshark tips and tricks in the protocol-specific sections. As an advanced Wireshark user with a thorough background in the internals of common network protocol operations, I was worried that this would be just another set of explanations of how various protocols work. Those explanations are there, but they are interspersed with many great tips and tricks about how to analyze the protocols more quickly and efficiently with Wireshark. I kept thinking, "why didn't I ever think of using that trick before?"
There is a lot here for both beginning and advanced Wireshark users.
I don't have a lot of criticisms to make: I thought the security sections were interesting, but a little dated. Exotic network and transport layer attacks just aren't all that common anymore; it would have been cool to have seen some analysis of a modern application-layer attack in action.
The other thing I would have liked is a discussion of the Lua scripting-language extensions to Wireshark. There is very little out there on the Internet about this so far, and most of what exists is oriented toward expert-level programmers. I was a bit disappointed to not even find Lua in the index. Still, the book is already huge, and adding a section on scripting might have made it unreasonably long. Maybe a volume 2?
Summary: if you use Wireshark, just buy it. This is an amazingly practical, hands-on book that will make you faster and more productive when analyzing network captures.
Blogging disclaimer: I paid full retail price for the book (and managed to somehow miss all the promo coupons) and am not being compensated in any way for this review.
Monday, January 4, 2010
computer crime and the small/medium business
Good post on the little-known computer crime wave targeting small/medium businesses:
http://www.krebsonsecurity.com/2010/01/buried-warning-signs-2/
http://www.krebsonsecurity.com/2010/01/buried-warning-signs-2/
Thursday, December 31, 2009
predicting reload times on Catalyst 3560/3750
During a recent IOS upgrade on a Catalyst 3560, I was connected to the console and noticed that the reload was taking much longer than usual due to some operations by the "Front End Microcode IMG Mgr". The output looked like this:
I opened a TAC case to find out what this is, since if you are relying on highly predictable reload times during a maintenance window, this could throw a wrench into your plans.
It turns out that the Catalyst switches have a special-purpose microcontroller that rarely needs to be upgraded. When it does need upgrading, however, the upgrade happens as a normal part of a new IOS image load. This upgrade makes the first reload to the new IOS take much longer than usual--I didn't time it, but I would guess 3-4 times longer than normal.
Microcontroller upgrades are not typically listed in the image release notes, so the only way to know for sure how long a particular upgrade is going to take is to test it in a lab, using the exact same before/after images that you will use in production.
POST: PortASIC RingLoopback Tests : Begin
POST: PortASIC RingLoopback Tests : End, Status Passed
front_end/ (directory)
extracting front_end/fe_type_1 (34760 bytes)
extracting front_end/front_end_ucode_info (86 bytes)
extracting front_end/fe_type_2 (73104 bytes)
extracting ucode_info (76 bytes)
Front-end Microcode IMG MGR: Installed 3 image(s) in cache:
Front-end Microcode IMG MGR: found microcode images for 3 devices.
Image for front-end 0: flash:/front_end_ucode_cache/ucode.1
Image for front-end 7: flash:/front_end_ucode_cache/ucode.1
Image for front-end 14: flash:/front_end_ucode_cache/ucode.1
Front-end Microcode IMG MGR: Preparing to program device microcode...
Front-end Microcode IMG MGR: Preparing to program device[0]...26580 bytes.
Front-end Microcode IMG MGR: Programming device 0...rwRrrrrrrwsssspsssspsssspsss
spsssspsssspsssspsssspsssspsssspsssspsssspsssspsssspsssspsssspsssspsssspsssspsss
[output truncated]I opened a TAC case to find out what this is, since if you are relying on highly predictable reload times during a maintenance window, this could throw a wrench into your plans.
It turns out that the Catalyst switches have a special-purpose microcontroller that rarely needs to be upgraded. When it does need upgrading, however, the upgrade happens as a normal part of a new IOS image load. This upgrade makes the first reload to the new IOS take much longer than usual--I didn't time it, but I would guess 3-4 times longer than normal.
Microcontroller upgrades are not typically listed in the image release notes, so the only way to know for sure how long a particular upgrade is going to take is to test it in a lab, using the exact same before/after images that you will use in production.
Monday, December 21, 2009
ACLs and TCAMs in Catalyst Switches
One of the things you need to look at when designing networks with Catalyst switches is the potential for TCAM exhaustion due to ACL and QoS configuration. Here are a couple of documents that explain the issue:
Catalyst 6500
http://www.cisco.com/en/US/products/hw/switches/ps708/products_white_paper09186a00800c9470.shtml
Catalyst 4500 and 4900 Series
http://www.cisco.com/en/US/products/hw/switches/ps663/products_tech_note09186a008054a499.shtml
Catalyst 6500
http://www.cisco.com/en/US/products/hw/switches/ps708/products_white_paper09186a00800c9470.shtml
Catalyst 4500 and 4900 Series
http://www.cisco.com/en/US/products/hw/switches/ps663/products_tech_note09186a008054a499.shtml
Tuesday, December 15, 2009
ten steps of small LAN design
A few days ago I posted an amusing comment on Ivan Pepelnjak's always excellent Cisco IOS Hints and Tricks blog, and he found it funny enough to create a separate post. I'll repeat my ten step program here for future reference:
- Build everything at layer 2 because "it's simpler".
- Scale a little.
- Things start breaking mysteriously. Run around in circles. Learn about packet sniffers and STP.
- Learn about layer 3 features in switches you already own. Start routing.
- Scale more.
- Things start breaking mysteriously. Learn about TCAMs. Start wishing for NetFlow.
- Redesign. Buy stuff.
- Scale more.
- VMWare jockeys start asking about bridging across the WAN.
- Enroll in hair loss program.
incoming dial-peers
I had an interesting troubleshooting experience that showed me that I didn't fully understand how incoming dial-peers work with POTS lines.
I had a simple H.323 config that hands off a call arriving on an FXO port to CallManager:
When a call was placed to the line connected to the FXO port on 1/0/2, the call would be sent to the IP phone with the wrong caller ID.
I ran a "debug voip ccapi" and discovered that the incoming dial-peer was not the default dial-peer 0, but another dial-peer (numbers sanitized):
This dial-peer had accidentally been left active from a prior configuration, and its "clid network-number" command was thus overwriting the correct caller ID.
I didn't know this previously, but it turns out that an incoming POTS dial peer is matched if it has a "port" statement equal to the inbound voice-port, AND any one of the following three commands is present:
incoming called-number
answer-address
destination-pattern
Removing the destination-pattern command or removing the dial-peer entirely corrects the problem and causes dial-peer 0 to be matched inbound.
I had a simple H.323 config that hands off a call arriving on an FXO port to CallManager:
voice-port 1/0/2
connection plar 7001
description POTS line
caller-id enable
dial-peer voice 7001 voip
destination-pattern 700.
session target ipv4:10.1.1.100
dtmf-relay h245-alphanumeric
When a call was placed to the line connected to the FXO port on 1/0/2, the call would be sent to the IP phone with the wrong caller ID.
I ran a "debug voip ccapi" and discovered that the incoming dial-peer was not the default dial-peer 0, but another dial-peer (numbers sanitized):
dial-peer voice 1000 pots
description 555-1212
destination-pattern 1212
clid network-number 9705551212
port 1/0/2
This dial-peer had accidentally been left active from a prior configuration, and its "clid network-number" command was thus overwriting the correct caller ID.
I didn't know this previously, but it turns out that an incoming POTS dial peer is matched if it has a "port" statement equal to the inbound voice-port, AND any one of the following three commands is present:
incoming called-number
answer-address
destination-pattern
Removing the destination-pattern command or removing the dial-peer entirely corrects the problem and causes dial-peer 0 to be matched inbound.
Tuesday, December 8, 2009
simple exclusion filters
I use these constantly (and many others, but these come first to mind):
display only interfaces with assigned IP addresses:
sh ip int b | e una
display only active switch interfaces:
sh int status | e not
display CDP neighbors, except phones:
sh cdp n | e SEP
display only interfaces with assigned IP addresses:
sh ip int b | e una
display only active switch interfaces:
sh int status | e not
display CDP neighbors, except phones:
sh cdp n | e SEP
Tuesday, June 23, 2009
RIP database and administrative distance
I was helping a friend study for CCNA the other day and saw a RIP behavior I'd never noticed before. I knew that RIP keeps a local route database that is displayed with the show ip rip database command. If another route to the same prefix with a better administrative distance is preferred in the global routing table, however, the RIP database doesn't show the route. This is different than more sophisticated routing protocols in which a prefix is kept in the protocol-specific topology table even if a route from another protocol with a better AD is in the global routing table.
Wednesday, June 10, 2009
Cisco IPS Manager Express
I've been doing Cisco IDS/IPS stuff recently for the first time in a long while. If you haven't tried Cisco's new free IPS Manager Express application, check it out. It makes IDS/IPS event monitoring and management reasonably useful and almost pain-free. The interface is much more intuitive that other Cisco IDS/IPS GUI products. The only problem is that the current version supports only 5 sensors; supposedly this will increase in a future release.
Added 12/15/09:
The latest version of IME supports 10 sensors.
Added 12/15/09:
The latest version of IME supports 10 sensors.
open ports on IOS router
Haven't posted here in ages. Interesting trivia: the old "show ip sockets" command doesn't work in new 12.4T images. It's been replaced by "show control-plane host open-ports":
#sh control-plane host open-ports
Active internet connections (servers and established)
Prot Local Address Foreign Address Service State
tcp *:22 *:0 SSH-Server LISTEN
tcp *:23 *:0 Telnet LISTEN
tcp *:15904 x.x.x.x:179 IOS host service ESTABLIS
tcp *:179 x.x.x.x:38441 BGP ESTABLIS
tcp *:179 *:0 BGP LISTEN
tcp *:179 *:0 BGP LISTEN
tcp *:179 *:0 BGP LISTEN
udp *:49 x.x.x.x:0 TACACS service LISTEN
udp *:161 *:0 IP SNMP LISTEN
udp *:162 *:0 IP SNMP LISTEN
udp *:57421 *:0 IP SNMP LISTEN
udp *:1985 *:0 cisco HSRP LISTEN
#sh control-plane host open-ports
Active internet connections (servers and established)
Prot Local Address Foreign Address Service State
tcp *:22 *:0 SSH-Server LISTEN
tcp *:23 *:0 Telnet LISTEN
tcp *:15904 x.x.x.x:179 IOS host service ESTABLIS
tcp *:179 x.x.x.x:38441 BGP ESTABLIS
tcp *:179 *:0 BGP LISTEN
tcp *:179 *:0 BGP LISTEN
tcp *:179 *:0 BGP LISTEN
udp *:49 x.x.x.x:0 TACACS service LISTEN
udp *:161 *:0 IP SNMP LISTEN
udp *:162 *:0 IP SNMP LISTEN
udp *:57421 *:0 IP SNMP LISTEN
udp *:1985 *:0 cisco HSRP LISTEN
Subscribe to:
Posts (Atom)