cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1691
Views
0
Helpful
6
Replies

QOS on 1841 with access lists?

syncrotechnology
Beginner
Beginner

I have new DIA Internet service coming in and unlike the last vendor who provided a router, I am configuring my own.  This is my first full Cisco config and I would appreciate any advice - I've been looking at this for 3 days now.  I have SIP signalling, rtp and default traffic on a (3) t1 multilink (4.5mb).   My lan and firewall uses dscp tags and passes them to the 1841 for outbound.  The ISP only prioritizes by destination address so I just need the 1841 to respect the tags internally.  Inbound, I have only port numbers to go by to differentiate voice traffic and I want to tag EF and CS3 accordingly for use by the 1841 and the rest of my network.  Below is part of my proposed config.   I have read tons of Cisco docs and looked at all the queuing methods and this one I understand the best.  I am getting the error: "CBWFQ : Can be enabled as an output feature only", so I presume that something is wrong on an input definition somewhere.  For now all the firewall functions are done at the actual firewall (Sonicwall NSA) so other than limiting ports to the PBX everything else is just pass-through.  Please suggest any changes. IOS is 12.4(4)T1.

Thank you!

Questions:

What is causing the CBWFQ error?

Do the access lists make sense?  Do they need to be stated reflexively like I have them or is that a default? Am I missing any?

Do I need to put the bandwidth statements on Serial and Multilink and are they correct?

Percentages make sense?  I only have 6 call paths x 80k = 480k voice so 15% for rtp seems like enough

How do the Multilink and Serial configs look?

FastEthernet need a bandwidth statement?

Anything else look like trouble about to happen?

!

! incoming SIP

!

class-map match-all ISP-SIP

  match access-group 110

!

! incoming RTP

!

class-map match-all ISP-RTP

  match access-group 112

!

! outgoing is already tagged by firewall

!

class-map match-any CS3

  match dscp cs3

class-map match-any EF

  match dscp ef

!

! voice in comes from ISP with no tags

! we only know port numbers but we tag em

!

policy-map VOICE-IN

  class ISP-RTP

  set ip dscp ef

  priority percent 15 ! amount allocated to rtp

  class ISP-SIP

  set ip dscp cs3

  bandwidth percent 10 !  allocated to SIP

  class class-default

  fair-queue

!

! voice from the SNWL is tagged so we use the tags

! to prioritize

!

policy-map VOICE-OUT

  class CS3

  priority percent 10 ! amount allocated to SIP

  class EF

  bandwidth percent 15 !  allocated to RTP

  class class-default

  fair-queue

!

!

!

interface FastEthernet0/1

description to SNWL

service-policy input VOICE-IN

! inside address of router

ip address x.x.x.x y.y.y.y

duplex auto

speed auto

no mop enabled

!

interface Multilink1

bandwidth 4632  !needed?

description connected to ISP

ip address x.x.x.x y.y.y.y !outside address of router

service-policy output VOICE-OUT

ppp multilink

ppp multilink fragment disable

ppp multilink group 1

!

interface Serial0/0/0:0

  bandwidth 1544

  description multilink 1 interface

  no ip address

  encapsulation ppp

  no keepalive

  no fair-queue

  ppp multilink

  ppp multilink group 1

!

interface Serial0/0/1:0

  bandwidth 1544

  description multilink 1 interface

  no ip address

  encapsulation ppp

  no keepalive

  no fair-queue

  ppp multilink

  ppp multilink group 1

!

interface Serial0/1/0:0

  bandwidth 1544

  description multilink 1 interface

  no ip address

  encapsulation ppp

  no keepalive

  no fair-queue

  ppp multilink

  ppp multilink group 1

!

!-- deny all other traffic to PBX

!

access-list 113 deny ip any <PBX outside IP>

!

!-- access-list 112 matches VoIP traffic based on the UDP port range for RTP.

!

access-list 112 permit udp <PBX IP> range 10000 20000 <SBC IP>

access-list 112 permit udp <SBC IP> range 10000 20000 <PBX IP>

!

!-- access-list 110 is used to match VoIP SIP

!

access-list 110 permit udp <PBX IP> range 5060 5061 <SBC IP>

access-list 110 permit udp <SBC IP> range 5060 5061 <PBX IP>

!

! -- permit default traffic to IP range other than PBX

!

access-list 114 permit ip any any <network>

!

!

6 Replies 6

Joseph W. Doherty
Hall of Fame Master Hall of Fame Master
Hall of Fame Master

Disclaimer

The  Author of this posting offers the information contained within this  posting without consideration and with the reader's understanding that  there's no implied or expressed suitability or fitness for any purpose.  Information provided is for informational purposes only and should not  be construed as rendering professional advice of any kind. Usage of this  posting's information is solely at reader's own risk.

Liability Disclaimer

In  no event shall Author be liable for any damages whatsoever (including,  without limitation, damages for loss of use, data or profit) arising out  of the use or inability to use the posting's information even if Author  has been advised of the possibility of such damage.

Posting

What's causing your error is ingress service policies don't support queuing.  You can mark and police for ingress, but not queue.

As for other trouble, for egress you normally place VoIP bearer (the EF) traffic into a LLQ.  "By the book", signally is placed into a different queue, generally with some resource guarantees to support it.

Your 1841 might support NBAR, which if it does, might simplify your inbound packet matching.

I might have a few more suggestions, tomorrow . . .

Joseph--

Many thanks for your comments.  I changed the IN policy to police rather than queue - makes sense now.  I do have nbar but I am not live yet - just working on a starting config so I can give that a try next week when the circuit is up.  Do I need a class-default statement or will the remainder be available anyway?

policy-map VOICE-IN

  class ISP-RTP

  set ip dscp ef

  police cir percent 15  ! allocated to RTP

  class ISP-SIP

  set ip dscp cs3

  police cir percent 10 !  allocated to SIP

! class class-default

! police cir percent 75  ! is this needed or will the default happen ?

Also, I re-thought this and I think I really need both the IN and OUT policies on the multilink interface only since that is the relatively slow one.  I think the FE should be fine as is.  Sound ok?

interface Multilink1

bandwidth 4632  !needed?

description connected to ISP

ip address

service-policy input VOICE-IN

service-policy output VOICE-OUT

ppp multilink

ppp multilink fragment disable

ppp multilink group 1

One other question about the access lists and precedence.  Are they read top down?  Right now I have the below which needs to deny any traffic to the pbx or sbc that is not rtp or sip (113, 112, 110) but still permit any other traffic in/out to the rest of the IP range excluding the PBX IP.  Is my order correct?  Thank you again. --Dale

access-list 113 deny ip any

access-list 113 deny ip any

!

!-- access-list 112 matches VoIP traffic based on the UDP port range for RTP.

!

access-list 112 permit udp range 10000 20000

access-list 112 permit udp range 10000 20000

!

!-- access-list 110 is used to match VoIP SIP

!

access-list 110 permit udp range 5060 5061

access-list 110 permit udp range 5060 5061

!

! -- permit default traffic to IP range other than PBX

!

access-list 114 permit ip any any

!

!

Disclaimer

The   Author of this posting offers the information contained within this   posting without consideration and with the reader's understanding that   there's no implied or expressed suitability or fitness for any purpose.   Information provided is for informational purposes only and should not   be construed as rendering professional advice of any kind. Usage of  this  posting's information is solely at reader's own risk.

Liability Disclaimer

In   no event shall Author be liable for any damages whatsoever (including,   without limitation, damages for loss of use, data or profit) arising  out  of the use or inability to use the posting's information even if  Author  has been advised of the possibility of such damage.

Posting

"Do I need a class-default statement or will the remainder be available anyway?"

Actually there's always a class-default. You only need to explicitly define it when you want to change its default parameters.  Remainder bandwidth, doesn't really apply to in policies.  It may to egress policies, but how much depends on policy configuration.

You probably shouldn't police your two VoIP traffic streams (marking can make sense).

It may make sense to police non-VoIP traffic, upon ingress, to guarantee bandwidth for your VoIP, but remember you're doing this downstream of the actual bandwidth of the bottleneck (the link).  To be effective, it only makes sense to target ingress traffic that will slow when it encounters the policed drops, and often you need to set the rate (much) lower as even traffic that will slow, may burst (well) above your configured policed rate (i.e. depriving your VoIP the bandwidth it needs).

Believe your multilink should default to aggregate bandwidth of all the subordinate links.  (This might vary per IOS version.)

ACLs, policy classes and class-map entries are all read/processed top down.

I would have to think about your security requirement.  It might be done as part of your ingress policy but perhaps better would be devoting a typical interface ACL to control ingress packets.  (Note: interface ACL might also be used by your ingress policy.)

Joseph-

Thanks you again for your terrific guidance. 

I evidently misunderstood police.  From your comment it means "no more than" rather than "at least".    More like this:

policy-map VOICE-IN

  class ISP-RTP

  set ip dscp ef

  class ISP-SIP

  set ip dscp cs3

  class class-default

  police cir percent 75

I am not sure that default traffic will ever get to Multilink since the classes are bound to the ACLs which only allow voice.   Will it work with the current ACLs or will default traffic be excluded?  I have since realized that I do not need the reflexive statements in the acls since I don't care about controlling outbound traffic to the SBC.  My firewall will insure that only legit traffic goes out destined for the SBC.

I don't follow your last comments about an ACL for ingress.  What would be the purpose of adding another ACL? Sorry, not getting it.

Thanks again - your help has been invalueable.  --Dale

Disclaimer

The   Author of this posting offers the information contained within this   posting without consideration and with the reader's understanding that   there's no implied or expressed suitability or fitness for any purpose.   Information provided is for informational purposes only and should not   be construed as rendering professional advice of any kind. Usage of  this  posting's information is solely at reader's own risk.

Liability Disclaimer

In   no event shall Author be liable for any damages whatsoever (including,   without limitation, damages for loss of use, data or profit) arising  out  of the use or inability to use the posting's information even if  Author  has been advised of the possibility of such damage.

Posting

I don't follow your last comments about an ACL for ingress.  What would be the purpose of adding another ACL? Sorry, not getting it.

Basically, I'm referring to using a "normal" interface ACL for ingress filtering.  Yes, you can filter packets, for security purposes, in a CBWFQ policy too, but I think that might be a little confusing.

I evidently misunderstood police.  From your comment it means "no more than" rather than "at least".    

Correct, a policer sets a hard maximum.

Okay, if your firewall is going to block all traffic but the VoIP related traffic, you would only need to insure that traffic is marked correctly.

e.g.

policy-map VOICE-IN

  class ISP-RTP

  set ip dscp ef

  class ISP-SIP

  set ip dscp cs3

If there might be some other VoIP traffic you'll allow in, then you can set its markings as desired, perhaps such as:

policy-map VOICE-IN

  class ISP-RTP

  set ip dscp ef

  class ISP-SIP

  set ip dscp cs3

  class class-default

  set ip dscp 0

Thank you Joseph.  I have what I think is a working config.  2 of the 3 T1's in the multilink are up and I am passing data traffic ok.  Have not tried voice yet, waiting for ISP to get things configured.

Available bandwidth of the Multilink is only 50% of the max bandwidth statement ( = bw of the 3 T1s combined) which is odd to me but I really can't assess that until all three are up.  I will reply back. --Dale

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community:

Recognize Your Peers