06-09-2010 01:17 PM - edited 03-15-2019 11:10 PM
Hello,
I am preparing to add syntax to a metro circuit that is being terminated on one side by a Cat65000 and a Juniper EX4200 on the other. Right now I am focusing on configuring the Cisco side. The purpose of the syntax is to
preserve call quality in rare instances of a bandwidth consumption spike. I am leaning toward using NBAR instead of ACLs, please let me know if this is not a good idea to you in this particular context;
Information -
Circuit bandwidth 3072 kb/sec (3mb circuit)
GLOBAL CONFIGURATION on Cat65000
mls qos
ip cef
INTERFACE CONFIGURATION
interface GigabitEthernetx/x
bandwidth 3072
ip address x.x.x.x x.x.x.x
load-interval 30
ip nbar protocol-discovery
service-policy output Data-Circuit
end
POLICY MAP CONFIGURATION
policy-map Data-Circuit
class voip-rtp
set dscp ef
priority percent 50 ! CONFIGURES LLQ FOR RTP TRAFFIC (LLQ IS ALSO CALLED "PRIORITY QUEUING")
class voip-control
set dscp cs3
bandwidth percent 5 ! RESERVES 5 PERCENT OF BANDWIDTH FOR VOICE CALL CONTROL
class class-default
fair-queue
CLASS MAP CONFIGURATION
class-map match-any voip-rtp
match protocol rtp audio
class-map match-any voip-control
match protocol skinny
match protocol sip
match protocol h323
match protocol mgcp
So, a few questions;
1) Is the command "ip nbar protocol-discovery" necessary for the interface? This command does not appear available when I type it, but I don't know if that's because I have not applied the "ip cef" syntax or if this is a Cisco IOS
version issue
2) The purpose of this syntax is to control traffic in congestion situations. The QOS SRND supports this assumption, but I just want to make sure - in the absense of congestion, full bandwidth should be available to all applications,
correct?
3) I can't find information pertaining to the bandwidth requirements for SCCP. The configuration examples that I have found imply that it is 32kb/s, is this correct?
Anyway, I'd appreciate any feedback or clarification.
Solved! Go to Solution.
06-10-2010 12:12 PM
As long as CEF is enabled NBAR is running by default on any newer IOS. You only need to use the discovery command to log what is traversing the interface for your review. Without the discovery command NBAR will still match your protocols, you just won't be able to use the show ip nbar protocol-discovery command to review what NBAR has been seeing.
You can certainly use your ACL to match rather than matching the protocol. I think that is all NBAR is doing anyway - matching the ports that the protocol you specify uses.
06-10-2010 05:56 AM
You shouldn't need to enable nbar to match protocols with your class maps. If you want to learn some statistics about what protocols are traversing the interface though this command would apply.
Right - QoS policies do not apply unless there is congestion.
You can find layer 3 bandwidth requirements for SCCP in table 3-12 on this link:
http://www.cisco.com/en/US/docs/voice_ip_comm/cucm/srnd/7x/netstruc.html#wp1045375
06-10-2010 08:57 AM
Joel,
The NBAR statements would be needed if I don't happen to trust the markings that are already on the packets, no? In that situation, the two ways to remark the packets would be to use NBAR or ACLs?
06-10-2010 11:40 AM
Leave NBAR on the interface, do a "clear counters" make a call, then do a "show policy-map interface x/x" to see if your voip maps are matching any packets or if their all matching under the default map. If you are matching packets correctly then you can remove NBAR and try it again to see if it makes a difference. I would just leave it on though.
06-10-2010 11:50 AM
My question had less to do with NBAR and more to do with a reality check - does this syntax look like it does I think it does. As it turns out, I'm not going to be using NBAR but rather ACLs, which will look like this;
ip access-list extended voip-control
permit tcp any any eq 2000
permit tcp any eq 2000 any
ip access-list extended voip-rtp
permit tcp any any udp 16384 32767
This only covers SCCP, but I can add the rest.
06-10-2010 12:12 PM
As long as CEF is enabled NBAR is running by default on any newer IOS. You only need to use the discovery command to log what is traversing the interface for your review. Without the discovery command NBAR will still match your protocols, you just won't be able to use the show ip nbar protocol-discovery command to review what NBAR has been seeing.
You can certainly use your ACL to match rather than matching the protocol. I think that is all NBAR is doing anyway - matching the ports that the protocol you specify uses.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide