dslreports logo
site
 
    All Forums Hot Topics Gallery
spc

spacer




how-to block ads


Search Topic:
uniqs
5107
share rss forum feed


PSWired

join:2006-03-26
Annapolis, MD

nbar missing some RTP traffic?

Click for full size
downloadset.pdf 9,227 bytes
Packet correctly classified
Click for full size
downloadunset.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.


rolande
Certifiable
Premium,Mod
join:2002-05-24
Dallas, TX
kudos:5
Reviews:
·AT&T U-Verse
·ViaTalk

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.
--
Ignorance is temporary...stupidity lasts forever!

»www.thewaystation.com/
»blog.thewaystation.com/



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?



rolande
Certifiable
Premium,Mod
join:2002-05-24
Dallas, TX
kudos:5
Reviews:
·AT&T U-Verse
·ViaTalk

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
--
Ignorance is temporary...stupidity lasts forever!

»www.thewaystation.com/
»blog.thewaystation.com/



PSWired

join:2006-03-26
Annapolis, MD
reply to PSWired

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/products/ps6···40.shtml

I 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

join:2006-03-26
Annapolis, MD
reply to 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
Premium,MVM
join:2002-08-22
kudos:4

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
reply to PSWired

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

join:2006-03-26
Annapolis, MD
reply to 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.



Da Geek Kid

join:2003-10-11
::1
kudos:1
Reviews:
·Callcentric

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.