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 126.96.36.199
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 188.8.131.52 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 184.108.40.206 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 * 220.127.116.11/9 18.104.22.168 0 7018 3356 i * 22.214.171.124 0 7018 3356 i * 126.96.36.199 0 7018 3356 i * 188.8.131.52 0 7018 3356 i * 184.108.40.206 0 7018 3356 i * 220.127.116.11 0 7018 3356 i * 18.104.22.168 0 7018 3356 i * 22.214.171.124 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!
Network engineer currently servicing the enterprise data center market. I started working on networks in the ’90s and still feel like that was just a few years ago. Jack of all trades, master of none; I love to learn about everything. Feel free to ask me about photography, woodworking, nhra, watches, or even networking! — For feedback, please leave a comment on the article in question, and I’ll gladly moderate it several weeks later. For everything else including fan mail or death threats, contact me via twitter.