Hi Lazaros, you are correct!!!
I enabled both telnet and SSH, and now NBAR classifies the traffic.
R2#show ip nbar protocol-discovery
GigabitEthernet0/0
Last clearing of "show ip nbar protocol-discovery" counters 00:07:49
Input Output
----- ------
Protocol Packet Count Packet Count
Byte Count Byte Count
5min Bit Rate (bps) 5min Bit Rate (bps)
5min Max Bit Rate (bps) 5min Max Bit Rate (bps)
------------------------ ------------------------ ------------------------
ssh 27 32
3927 2976
0 0
1000 1000
telnet 16 19
1629 1146
0 0
0 0
icmp 5 5
570 570
0 0
0 0
Total 48 56
6126 4692
0 0
1000 1000
It totally makes sense. BEFORE the 3-way handshake, the telnet or SSH protocols are not even being used (we didn’t send any packet with telnet/SSH information at the application layer), so NBAR doesn’t classify the traffic. In my previous test, it was just a TCP SYN followed by a ICMP “connection refused” message, by no application-level message was being sent at any moment.
NBAR is used to classify packets based on application layer, while extended ACLs can be used to classify based on just layer-4 protocol and port. Let’s take the SSH example. This is why I was able to classify the traffic using extended ACLs (matches TCP at port 22) but not using NBAR (no SSH layer-7 message was sent at any time, because the TCP connection wasn’t even opened).