"bypass from the WAN interface to the DSP that would make it not hit on a CoPP ACL?"
...Yes. typically, there is an interface that represents the DSPs or DSP card. on a WS-CMM-ACT module the RTP traffic never even entered the voice gateway's switching path =) . In an ISR platform, there's going to be an IDB of some form for the router to switch the packet to. if you look hard enough in an ISR you may come across an interface named voip-null0. I think this is a cosmetic name for that IDB. This is an interesting question =) maybe someone else will pipe up and elaborate =) voice packets are not process switched to the DSPs. (unless you've done somethign very wrong) Typically, I _believe_ CEF handles getting the RTP packet to the DSPs in something like an ISR or anything else with single data/control plane. slownet-brdr1#sh cef interface internal | begin ull VoIP-Null0 is up (if_number 4) Corresponding hwidb fast_if_number 4 Corresponding hwidb firstsw->if_number 4 Internet Protocol processing disabled Suppressed input features: MCI Check Output features: Post-Ingress-NetFlow Hardware idb is VoIP-Null0 Fast switching type 13, interface type 222 IP CEF switching enabled IP CEF switching turbo vector IP prefix lookup IPv4 mtrie 8-8-8-8 optimized Flags 0x6080, hardware flags 0x1 Input fast flags 0x0, Output fast flags 0x0 ifindex 4(4) Slot Slot unit -1 VC -1 IP MTU 0 Status flags: hwidb status 100800 status2 8000050 status3 0 status4 0 fibhwidb status 100800 status2 8000050 status3 0 status4 0 Subblocks: No subblocks present -Pete On Thu, Jul 31, 2014 at 1:20 PM, randal k <[email protected]> wrote: > Good morning - > > I have a bunch of Cisco IAD24xx models out in the field all running SIP > talking to our softswitch, and I thought I'd get the collectives input on > the best method to secure them. > > Up until a few weeks ago we have custom-written ACLs on the WAN interface of > these routers to allow/deny SIP and other stuff. Well, a broken ACL allowed > access to the wide-open by default H323 service and cost us some $TOLL_FRAUD > -- nothing too bad, but enough for us review how we're doing things. > > So, we have deployed a demo control-plane based policer/dropper to make sure > that the WAN interface ACL doesn't have to be perfect (or even be there, > which is the goal). An example: > > policy-map cpp-policy > class cppclass-reporting > class cppclass-monitoring > class cppclass-management > class cppclass-services > class cppclass-voip > class cppclass-undesirable > police rate 10 pps > conform-action drop > exceed-action drop > class cppclass-everything > class class-default > police rate 1000 pps > conform-action transmit > exceed-action drop > ! > Class Map match-all cppclass-voip (id 3) > Match access-group name cpp-voip > ! > Extended IP access list cpp-voip > 10 permit udp host SIPPROXY any eq 5060 > 11 permit udp host SIPPROXY eq 5060 any (2159250 matches) > 20 permit udp host SIPPROXY2 any eq 5060 > 21 permit udp host SIPPROXY2 eq 5060 any > 30 permit udp host AUDIO1 range 10000 20000 any (657129 matches) > 40 permit udp host AUDIO2 range 10000 20000 any > 50 permit udp host T381 range 4000 5999 any > 60 permit udp host T382 range 4000 5999 any > 510 permit udp host LEGACY1 any eq 5060 > 520 permit udp host LEGACY2 any eq 5060 > 530 permit ip CATCHALL 0.0.0.31 any > 540 permit ip CATCHALL 0.0.0.31 any > > > My question is that my cppclass-voip, and its associated Audio-related ACL > (#30) is NOT matching all the RTP packets. There should be orders of > magnitude more packets hitting that line than there are. > > Anybody have any insight into how RTP is processed on these or on CUBEs in > general? Does it create some sort of CPU-bypass from the WAN interface to > the DSP that would make it not hit on a CoPP ACL? > > Thanks! > Randal > > _______________________________________________ > cisco-voip mailing list > [email protected] > https://puck.nether.net/mailman/listinfo/cisco-voip > _______________________________________________ cisco-voip mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-voip
