PSWired join:2006-03-26 Annapolis, MD |
nbar missing some RTP traffic? set.pdf 9,227 bytes Packet correctly classified | unset.pdf 9,405 bytes Packet "missed" |
Hello, I have a Cisco 3640 at the edge of my network that should be detecting all RTP traffic entering the network from the "greater Internet" in order to tag it with the appropriate DSCP for QoS within my network. Here are the relevant parts of the config: class-map match-all sip match protocol sip class-map match-all voice match protocol rtp audio policy-map input-mark class voice set ip dscp ef class sip set ip dscp af31 interface FastEthernet0/0.300 service-policy input input-mark This seems to work perfectly, and all VoIP RTP packets have their DSCP field set to expedited forwarding. However, every now and then I will get an RTP traffic flow inside my network that is not classified correctly (its DSCP value is left at 0). Attached are PDFs showing the packet contents of a packet that was correctly tagged, and one that was "missed". I can't find any difference in the traffic that would cause NBAR to misclassify the packet and not set its DSCP appropriately. Is this likely a problem with NBAR misclassifying the packet or should I be looking elsewhere for the source of the problem? I should also note that the SIP traffic is always correctly handled, it's only the RTP traffic that is sometimes missed. Thanks in advance. |
|
rolandeCertifiable MVM, join:2002-05-24 Dallas, TX ARRIS BGW210-700 Cisco Meraki MR42
|
You are matching for 'rtp audio' which looks at specific UDP port ranges (16535-32767). It doesn't detect that the packets "actually are" audio packets. If you are using a provider who uses ports outside that range for certain RTP sessions, then this could be a reason for the missed marking of streams. What port was the particular RTP session running on that wasn't marked?
You are probably better off just matching for RTP and skipping the specific 'audio' qualifier statement. |
|
PSWired join:2006-03-26 Annapolis, MD |
The "missed" packet had source port 60164 and destination 13460. The correctly tagged packet had source 60250 and destination 13456. I'd rather not catch all RTP because I don't want any video apps hogging up bandwidth in the high priority queues in some of my microwave point-to-point links.
I've compared the two packets side to side and the only differences I see (besides the obvious things like payload data) are the source IP address, IP Identification field, the DSCP (obviously) and the source/destination ports. Plus the SDP setup frame.
Any ideas? |
|
rolandeCertifiable MVM, join:2002-05-24 Dallas, TX ARRIS BGW210-700 Cisco Meraki MR42
|
That is very interesting and puzzling. Based on my understanding of the NBAR 'match protocol rtp audio' function neither of those packets should get marked. RTP Audio ports are even numbered from 16384 to 32767. But it can use anything from 5000 up to 65535 technically. It is possible that those are silence or white noise packets and NBAR is actually looking for PCM bit patterns within the payload? It might not be a major issue if it is just silence packets |
|
PSWired join:2006-03-26 Annapolis, MD |
Puzzling- you got that right! Here's a Cisco document- it leads me to believe it uses the RTP payload type field to distinguish between audio and video types. All of the traffic is type 18 (g.729). » www.cisco.com/en/US/prod ··· 40.shtmlI changed the class-map to "match protocol rtp" instead of "match protocol rtp audio" and have the same results. It's not just silence packets- the audio stream is definitely experiencing QoS issues when this happens according to users. Makes it hard to troubleshoot since this only happens intermittently, presumably only from a few specific call origination points. Next I'm going to replace that "match protocol rtp audio" with an access list that matches the ATA IP addresses for troublehsooting. That will tell me if it's a guaranteed nbar problem or if there is something else fishy going on here. Any other ideas welcome. |
|
PSWired |
It's been a few hours with production traffic flowing through this router. The test configuration with an ACL used as the match criteria for VoIP traffic instead of "match protocol rtp audio" has worked great and not missed any packets. Unfortunately this isn't a scalable solution.
Does anyone have access to documentation of the exact criteria the nbar engine uses to determine if a packet is an RTP packet? |
|
|
aryoba
MVM
2008-Apr-15 11:03 am
said by PSWired:It's been a few hours with production traffic flowing through this router. The test configuration with an ACL used as the match criteria for VoIP traffic instead of "match protocol rtp audio" has worked great and not missed any packets. Unfortunately this isn't a scalable solution. Scalable, no. Works great, yes. At least with ACL, you could have deeper control of which UDP ports to manage. This is not the 1st time there are "glitches" on NBAR behavior. |
|
PSWired join:2006-03-26 Annapolis, MD |
Okay, here's my solution to this problem. Please let me know if you see any glaring errors here.
A little more background- this is being applied to a router at the edge of an ISP network. Packets originating within the ISP network are tagged correctly with the appropriate DSCP value for QoS within the network, but packets entering from the "greater internet" are not tagged and need to be tagged at the edge for correct treatment within the ISP network.
I'm planning to use reflexive ACLs to identify traffic exiting the ISP network that is tagged with DSCPs af31 or ef, and then appropriately tag all incoming traffic that's part of the stream identified by the outgoing ACL.
Here's the config:
ip access-list extended detect-dscp-ef permit ip any any dscp ef reflect found-dscp-ef permit ip any any ip access-list extended detect-dscp-af31 permit ip any any dscp af31 reflect found-dscp-af31 permit ip any any ip access-list extended needs-dscp-ef evaluate found-dscp-ef ip access-list extended needs-dscp-af31 evaluate found-dscp-af31
class-map sip match protocol sip class-map dscp-ef match access-group needs-dscp-ef class-map dscp-af31 match access-group needs-dscp-af31
policy-map input-mark class dscp-ef set ip dscp ef class dscp-af31 set ip dscp af31 class sip set ip dscp af31
interface FastEthernet0/0.300 service-policy input input-mark access-group output detect-dscp-ef access-group output detect-dscp-af31
Look good? |
|
PSWired |
Big DUH! here...
No guarantee the voice traffic associated with a particular stream is going to exit through the particular edge router that's accepting the incoming packets. That breaks the above method.
Back to the drawing board. Ideas? Surely I'm not the first one to run into this problem. |
|
|
you might want to check your buffers... I believe you are dropping packets... when you can use the ACL without issues and have trouble with Class-maps this maybe due to buffer in the router...
check the sh buffers and look for the misses... The tuning of the buffers may solve your issue. |
|