So I am sure to many people the common frustration when using NCM is that in your reporting when you do a MUST match "blah" in an entire config, you get a match but what you are really trying to accomplish is making sure you ONLY have that entry and not something else.
Today I would like to cover how to do this. So get some coffee and put your thinking caps on, it's about to get deep (regex).
So say we have an extended ACL, ie this portion of a config.
ip access-list extended ncmisawesome
permit tcp host 10.0.0.1 192.168.1.0 255.255.255.0
permit tcp host 10.0.0.2 192.168.1.0 255.255.255.0
permit udp any any eq netbios-ns
permit udp any any eq netbios-dgm
ip access-list extended ncmisntsoawesome
So you want it to show that line 123 is in violation and not just this whole pattern doesn't exist? It is possible, but I warn you it is painful.
So create an advance config search and make it report if NOT found and then we will create MUST NOT CONTAIN regexs.
First you need to group your ACL to where the ambiguity has an end point. IE, foo and foo-foo end their ambiguity after foo. This is key to understand when going forward above we have permit tcp host 10.0.0.x so lets conquer this regex first.
\spermit tcp < this is where we will start our regex because we have both tcp and udp and if we start negating earlier in the text we will break our own rule.
\spermit tcp ([^h] <--- match anything BUT, and this is where we continue our logic
\spermit tcp ([^h]|h[^o]|**[^s]|hos[^t]|host [^1]|host 1[^0]|host 10[^\.]|host 10\.[^0]|host 10\.0[^\.]|host 10\.0\.[^0]|host 10\.0\.0[^\.]|host 10\.0\.0\.[^12]|host 10\.0\.0\.[12][^\s]|host 10\.0\.0\.[12]\s[^1]|host 10\.0\.0\.[12] 1[^9]|host 10\.0\.0\.[12] 1[^9]|host 10\.0\.0\.[12] 19[^2]|host 10\.0\.0\.[12] 192\.[^1]|host 10\.0\.0\.[12] 192\.1[^6]|host 10\.0\.0\.[12] 192\.16[^8]|host 10\.0\.0\.[12] 192\.168\.[^1]|host 10\.0\.0\.[12] 192\.168\.1[^\.]|host 10\.0\.0\.[12] 192\.168\.1\.[^0]|host 10\.0\.0\.[12] 192\.168\.1\.0[^\s]|host 10\.0\.0\.[12] 192\.168\.1\.0 [^2]|host 10\.0\.0\.[12] 192\.168\.1\.0 2[^5]|host 10\.0\.0\.[12] 192\.168\.1\.0 25[^5]|host 10\.0\.0\.[12] 192\.168\.1\.0 255\.[^2]|host 10\.0\.0\.[12] 192\.168\.1\.0 255\.2[^5]|host 10\.0\.0\.[12] 192\.168\.1\.0 255\.25[^5]|host 10\.0\.0\.[12] 192\.168\.1\.0 255\.255\.[^2]|host 10\.0\.0\.[12] 192\.168\.1\.0 255\.255\.2[^5]|host 10\.0\.0\.[12] 192\.168\.1\.0 255\.255\.25[^5]|host 10\.0\.0\.[12] 192\.168\.1\.0 255\.255\.255\.[^0])
And viola, there you have it, a regex that does what you were looking for... I agree it's painful but it does work. (I skipped the beginning lin
Luckily the netbios rule is much easier:
permit udp any any eq ([^n]|n[^e]|ne[^t]|net[^b]|netb[^i]|netbi[^o]|netbio[^s])
Here, I need to clarify, anything typed after netbios will not violate the rule, this is intentional. There are things you need to take into account, like after 3 digits in the first three octets, IOS requires a dot, so you do not have to account for it in your regex. As well as accounting for what is required, you must account for what is NOT required and anticipate it with your regex.
The above would be placed with in a block search if you wish but then you have to ALLOW the regex of the start of the block (end of block doesn't seem to be checked but ALWAYS test your regex against text you paste in and an ACTUAL config). I build test rules before and document my regex per rule before putting it into NCM. This is a good habit to form until you are a master of regex, so you understand where you came up with the rule and how it works if you have to revisit it later.
In closing, the above will match any line that is not accounted for, hence your report will show the line number in violation and you do not have to search config blocks or configs painfully for the human error.