As a followup to my previous post on Regular Expression Basics, I wanted to give a few examples on using them on Cisco IOS. Obviously, with a topic as large as regular expressions, there are a limited number of examples I can give. You imagination and of course necessity are the best tools you have for exploring them on your own.

Our first examples use Regular Expressions (regexes) on the CLI. Every engineer should know that you can pipe output from the cli and run it through filters, including exclude, include, section, and begin. These can be very handy when you’re looking for specific information.

router#sh ip int br | ex un
Interface                      IP-Address      OK? Method   Status                Protocol
FastEthernet0/0          192.168.8.9     YES NVRAM   up                      up
FastEthernet0/0.2       10.1.8.1           YES NVRAM   up                      up

But what if this device had hundreds of ports with assigned IP address, and you were only interested in a specific block of IPs? Thankfully, regex can help! The following will match lines containing IPs within 192.168.8.0/22 — very handy indeed.

router#sh ip int br | i 192\.168\.[8-11]\.
FastEthernet1/0/2          192.168.8.9     YES NVRAM   up                      up

Another example could be looking specific configuration entires. In this example, we’re looking for any lines that start with ‘ip ‘ notice the space which we will match using the _ character. (Ensure you don’t include a space after the _ character, or you will return 0 matches!)

router#sh run | i ^ip_
ip cef
ip domain name mattke.net
ip name-server 4.2.2.2

Notice that no ip addresses were matched in this output since they’re part of the interface config, they’re indented using whitespace. To include them in the matches, I’d normally use ^_*ip_ which states, match beginning of the line, followed by whitespace, or not, followed by ip and a space. But.. IOS doesn’t like that. So you have to use the following…

router#sh run | i ^ *ip_
ip cef
ip domain name mattke.net
ip name-server 4.2.2.2
 ip address 192.168.8.9 255.255.255.0
 ip address 10.1.8.1 255.255.255.0

Now that we have the general idea, lets get to the point. Most of you will at some point, run across a config that uses regexes as an as-path access-list. So lets start with some scenarios. You only want to accept routes from this particular peer, if and only if they’ve traveled through ASN 3356 ( Level3 ).

ip as-path access-list 1 permit _3356_

Ok, now, lets specificly deny those routes if they were originated from TWTC (Time Warner AS 4323)..

ip as-path access-list 1 deny ^4323_
ip as-path access-list 1 permit _3356_

You can see how quickly this can get real fun! So, what if we wanted to ensure that our upstream peers ASN (lets say, AT&T… aka as 7018) is the next hop for any routes we were accepting…

ip as-path access-list 1 permit ^7018_[0-9]*$
ip as-path access-list 1 deny .*

One of the methods I use for extreme route balancing in data centers is checking AS Path… Obviously this is done in the path selection algorithm but can be overridden by local preference. So in cases, I’ll set local preference based on AS Path!

ip as-path access-list 1 permit ^([0-9]+)$
ip as-path access-list 2 permit ^([0-9]+)_([0-9]+)$
!
route-map foo permit 10
 match as-path 1
 set local-preference 150
!
route-map foo permit 20
 match as-path 2
 set local-preference 140
!

One last trick I’d like to show you is testing your regex’s before applying them in a route-map. Cisco has actually made this quite simple for you to test applying these against your current BGP table. Lets go ahead and test this on the AT&T route server.

route-server>show ip bgp regexp ^([0-9]+)_([0-9]+)$
BGP table version is 32693826, local router ID is 12.0.1.28
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
              r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete

   Network          Next Hop            Metric LocPrf Weight Path
*  4.0.0.0/9        12.123.37.250                          0 7018 3356 i
*                   12.123.134.124                         0 7018 3356 i
*                   12.123.29.249                          0 7018 3356 i
*                   12.123.142.124                         0 7018 3356 i
*                   12.123.137.124                         0 7018 3356 i
*                   12.123.25.245                          0 7018 3356 i
*                   12.123.17.244                          0 7018 3356 i
*                   12.123.41.250                          0 7018 3356 i
( and so on...... )

I hope this has given you some ideas of your own, or at least cleared up any confusion you have about regular expressions. As always, if you have any suggestions, comments, or questions please feel free to leave a comment below. I always appreciate the feedback. Thanks!

Who writes this crap?

Tony Mattke is a network engineer for a financial institution in Indiana. In the past he has worked for ISPs, data centers, networking manufactures, and the occasional enterprise. For feedback, please leave a comment on the article in question. For everything else including fan mail or death threats, contact him via twitter.

Tagged as: regex