Aut inveniam viam aut faciam

Regular Expressions For SecureCRT Keyword Highlighting – Update

This is an update to my previous post on syntax highlighting in SecureCRT.  I’ve focused on highlighting the output of show commands, but not “show run”.  I don’t specifically try to match the configuration.  I find that doing so causes the output of “show logging” to be over highlighted with different colors making it hard to read.  It’s easy to over highlight and ruin the entire point of it.  I have temporarily added entries to look for configuration problems in the past, such as allowing telnet, using password 7 hashes, or SNMPv1 read/write strings.  But I’ve found it’s easier and quicker to search through the backed up device configurations and address the issue all at once.
I’ve updated the regular expressions to include:
– Works with with IOS, IOS-XE, and NXOS.
– Works fairly well with XR.  Matching the output of “show logging” needs more work.
– Works fairly well with ASAs.  The ASAs use a time format of 0:00:00.  They end up partially matching the RT / RD regular expression.  If you are not working with L3VPNs, you can delete that regular expression and modify the Time regular expression to match the ASA’s format.  Otherwise, the fix would be to use a separate .ini file with the ASAs.
– Match Hundred, Forty, TwentyFive, and Ten GigabitEthernet interfaces.
– Match switch stack switch/slot/port interfaces, router slot/subslot/port interfaces, FEX chassis_id/slot/port interfaces, breakout cable chassis_id/slot/port/breakout_port interfaces, and XR rack/slot/module/port interfaces.
– Reduced the interface regular expressions to two lines (my personal list had grown to 14 lines).
– Changed the Privileged EXEC prompt regular expression to match anything with A-Z, a-z, 0-9,a dash, underscore, forward slash, or colon.  If you use other characters in your hostname, you’ll have to make the appropriate changes.  The User EXEC prompt is not matched.
– Added MAC addresses to the Time regular expression line.  If I didn’t, one of the Time regular expressions would match part of the MAC address turning that part grey and one of the RT/RD regular expressions would match another part of the same MAC address turning that part blue.  While I was at it, I added VOIP phone and access point device IDs that are displayed in the output of “show cdp neighbors”.
– Changed the order of the lines.  This is to allow the global configuration prompt to display “config” in yellow.  It also allows me to override the greedy “(not(.*)?” regular expression.  I was tired of seeing “notconnect” and “notifications” in red.
– Added regular expressions to match unwanted, partial matches.  I thing turn these white or the default text color.
The regular expressions are based on syntax used with Python.
SecureCRT does not support using spaces in regular expressions.  Which sucks.  Matching spaces would be handy for matching within the OSPF database, EIGRP topology, or the BGP neighbor information.  I’ve found example configurations that try to use the hexcodes for a space, such as \x20.  That doesn’t work for me.  Using the hexcode for a dash works, \x2d.  *shrug*  There are many references in the VanDyke forums that the performance hit was too large.
As much as I complain about not being able to match across spaces and, I’ve tried to get my list of regular expressions to work with a SSH/terminal program that does allow syntax highlighting matches with spaces.  Wow.  Talk about greedy matches.  “Why is my entire screen blue?!?!”  It’d take some time to completely rethink, rewrite, and test what I’m matching.
With SecureCRT, the following are considered word delimiters:

Order matters.  Generally, match the more specific (longer) before the less specific (shorter).  Otherwise, you’ll get partial matches.  For example, match “errors” before “error” before “err”.  Unless, of course, you want to override more specific matches.  For example, match emergencies, alerts, and critical log messages with %\w*\-[012]\-\w*.
Python regular expressions are greedy.  This means that it will try to match as much as possible.  This allows “(errors|error|err)” to be shortened to “(err(ors|or)?” or “(err(or(s)?)?” or “(err(.*)?)”.
I’m still using the one line regular expressions for IPv6 and IPv4 addresses from the book Regular Expressions Cookbook, 2nd Edition by Steven Levithan, Jan Goyvaerts.
There are some false matches.  I use the “Case match” option to reduce them as much as possible.  Still, things such as “B”, “R”, and “DR” still show up in some odd places.  Meh.  NXOS gets a few weird matches as well.  With EIGRP on NXOS, “internal” and “external” are lowercase in the output of “show ip route”.  Matching them causes those words to appear green in some weird places.  The ASAs use a time format that doesn’t follow any of the other Cisco device families.
The colors I use are meant for a dark (black) background with white text.  Because of this, dark colors are avoided.  I’ve tried to group the output of some protocols together:  BGP – blue, RIP – red, OSPF – orange, EIGRP – evergreen (but evergreen is too dark, so a lighter shade of green).
Not listed below are some personal regular expressions.  It’s common for route-map names, named ACLs, and other user defined names to be partially matched.  I create regular expressions to match those and then color them depending on their purpose.
If you don’t want to configured the highlight keywords in SecureCRT, you can use this .ini file.  For OS X, copy the .ini file into the following directory:

For Windows, the directory is located in %APPDATA%, which should be:

In Linux, copy the .ini file into:

NOTE –  Information that will not age well:
– Linux syntax highlighting support is in pre-release for version 8.6.  If your license for SecureCRT is current, you can request access to a pre-release.  Information can be found in the VanDyke forums.  Or you can wait for 8.6 to be released.
– The regular expressions I’m using to get rid of unwanted, partial matches doesn’t work with the latest version of SecureCRT for OS X.  It works in the latest Windows and Linux versions.  From the SecureCRT_History.txt of the 8.6 pre-release, “Change the keyword highlighting regular expression algorithm to honor the order of the configured keywords.”  Hopefully, that fixes the issue.

SecureCRT Settings:
- Session Options -> Terminal -> Appearance
-> Current color scheme
-> White / Black
-> Highlight keywords
-> Name: feralpacket
-> Style: Color is checked
- Keyword List Properties
-> Match case is checked
- To set for the default session:
-> Global Options -> General -> Default Session
-> Edit Default Settings...










The Regular Expressions:

! Get rid of unwanted, partial matches. Turn them white.

! IPv4-mapped IPv6 Addresses and SAF Identifier Numbers

! VPNv6 Addresses

! VPNv4 Addresses

! IPv6 Addresses

! MAC Addresses and Time

! ASN:nn RD or RT

! IP-address:nn RD or RT

! IPv4 Addresses

! Interfaces

! Possible warning and other things that deserve attention

! Bad responses

! Good responses

! Bad - emergancies, alerts, and critical log messages


! OSPFv2 and OSPFv3





! Hostnames and prompt

! Routing table metrics

! EIGRP topology table metrics and ping responses


! IPv6 Neighbor Discovery

! Various log messages I turn green

! Various log messages I turn red

! Various log messages I turn yellow

! Catch-all for all other log messages

Comments are closed.

This entry was posted on Wednesday, July 24th, 2019 at 1:01 pm and is filed under CCIE. You can follow any responses to this entry through the RSS 2.0 feed. Responses are currently closed, but you can trackback from your own site.