01-16-2013 12:55 PM - edited 03-04-2019 06:43 PM
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>
!
!
01-16-2013 07:05 PM
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 . . .
01-17-2013 06:47 AM
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
access-list 112 permit udp
!
!-- access-list 110 is used to match VoIP SIP
!
access-list 110 permit udp
access-list 110 permit udp
!
! -- permit default traffic to IP range other than PBX
!
access-list 114 permit ip any any
!
!
01-17-2013 07:37 PM
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.)
01-18-2013 07:00 AM
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
01-21-2013 05:30 AM
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
01-27-2013 12:33 PM
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
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: