Yea, that's a fair question. I have been working remotely so I haven't had a chance to take an actual capture yet but the provider has assured me that everything is on 5060. Let’s see.
sh ip inspect session | inc sip Session 683E7AE0 (66.x.x.x:5060)=>(192.168.2.123:5060) sip SIS_OPEN Session 683E1F18 (192.168.2.147:5060)=>(66.x.x.x:5060) sip SIS_OPEN Session 683DED08 (192.168.2.158:5060)=>(66.x.x.x:5060) sip SIS_OPEN Session 683E1988 (192.168.2.159:5060)=>(66.x.x.x:5060) sip SIS_OPEN Session 683E9978 (192.168.2.127:5060)=>(66.x.x.x:5060) sip SIS_OPEN Session 683E9C40 (192.168.2.122:5060)=>(66.x.x.x:5060) sip SIS_OPEN Session 683EC8C0 (192.168.2.161:5060)=>(66.x.x.x:5060) sip SIS_OPEN Session 683E96B0 (66.x.x.x:24980)=>(192.168.2.165:2230) sip-RTP-data SIS_OPEN Session 683E53F0 (192.168.2.160:5060)=>(66.x.x.x:5060) sip SIS_OPEN Session 683E2A38 (66.x.x.x:24981)=>(192.168.2.165:2231) sip-RTCP-data SIS_OPEN Session 683EB548 (192.168.2.102:5060)=>(66.x.x.x:5060) sip SIS_OPEN Session 683E9F08 (66.x.x.x:5060)=>(192.168.2.165:5060) sip SIS_OPEN Session 683E4078 (66.x.x.x:5060)=>(192.168.2.151:5060) sip SIS_OPEN Session 683E3AE8 (192.168.2.146:5060)=>(66.x.x.x:5060) sip SIS_OPEN Pre-gen session 683E4B98 66.x.x.x[1024:65535]=>x.x.92.122[1108:1108] sip Pre-gen session 683ED3E0 66.x.x.x[1024:65535]=>x.x.92.122[1092:1092] sip Pre-gen session 683E0610 66.x.x.x[1024:65535]=>x.x.92.122[1107:1107] sip Pre-gen session 683DE1E8 66.x.x.x[1024:65535]=>x.x.92.122[1112:1112] sip Pre-gen session 683E5C48 66.x.x.x[1024:65535]=>x.x.92.122[1110:1110] sip Pre-gen session 683EAA28 66.x.x.x[1024:65535]=>x.x.92.122[1113:1113] sip Pre-gen session 683E61D8 66.x.x.x[1024:65535]=>x.x.92.122[1106:1106] sip Pre-gen session 683E8338 66.x.x.x[1024:65535]=>x.x.92.122[1098:1098] sip Pre-gen session 683EB280 66.x.x.x[1024:65535]=>192.168.2.165[5060:5060] sip Pre-gen session 683E7550 66.x.x.x[1024:65535]=>x.x.92.122[1100:1100] sip Pre-gen session 683E3820 192.168.2.165[1024:65535]=>66.x.x.x[5060:5060] sip Pre-gen session 683EBAD8 66.x.x.x[1024:65535]=>x.x.92.122[1118:1118] sip --- On Fri, 4/5/13, David Prall <[email protected]> wrote: > From: David Prall <[email protected]> > Subject: RE: [c-nsp] QoS not working - VPN acl conflicting??? > To: "'false'" <[email protected]>, "'cisco mailing list'" > <[email protected]> > Date: Friday, April 5, 2013, 11:21 AM > So all your voice traffic is destined > to a single address? > > access-list 156 permit ip any host 66.x.x.x.x > > Certain that isn't just the control, and that a different > address isn't > being used for the gateway? > > I'd configure load-interval 30 on the outside interface so > everything gets > updated faster. Where does "show ip inspect sessions" tell > you that things > are going. > > David > > -- > http://dcp.dcptech.com > > > -----Original Message----- > > From: false [mailto:[email protected]] > > Sent: Friday, April 05, 2013 10:28 AM > > To: 'cisco mailing list'; David Prall > > Subject: RE: [c-nsp] QoS not working - VPN acl > conflicting??? > > > > Our voice solution is outsourced. The voip traffic goes > straight to the > > Internet to our provider's voip server using the same > T-1 that is used for > our > > site to site VPNs. ??? > > > > --- On Fri, 4/5/13, David Prall <[email protected]> > wrote: > > > > > From: David Prall <[email protected]> > > > Subject: RE: [c-nsp] QoS not working - VPN acl > conflicting??? > > > To: "'false'" <[email protected]>, > "'cisco mailing list'" <cisco- > > [email protected]> > > > Date: Friday, April 5, 2013, 9:18 AM > > > Only want the pre-classify configured > > > on the crypto map. Then you can match > > > on the original source/destination addresses and > protocol. > > > > > > You are only encrypting GRE traffic per the crypto > map. Is > > > the voice traffic > > > flowing through the tunnel or via the physical > interface. > > > All the service > > > policy is seeing is GRE with pre-classify if the > traffic is > > > through the > > > tunnel. Modify the service-policy to match on dscp > ef. Then > > > place another > > > service policy to match on an acl ingress on the > inside > > > interface and set > > > dscp ef. Then the gre header will be marked ef for > voice > > > traffic, the ipsec > > > will be marked ef, and your egress policy will > then > > > prioritize ef. > > > > > > David > > > > > > -- > > > http://dcp.dcptech.com > > > > > > > > > > -----Original Message----- > > > > From: false [mailto:[email protected]] > > > > Sent: Friday, April 05, 2013 10:05 AM > > > > To: 'cisco mailing list'; David Prall > > > > Subject: RE: [c-nsp] QoS not working - VPN > acl > > > conflicting??? > > > > > > > > Still stuck. Keep in mind that I am trying to > make the > > > QoS policy work on > > > > traffic that is NOT going over the tunnel. > This is voip > > > traffic going to > > > my > > > > provider. I tried using the qos-preclassify > command at > > > the crypto map > > > level > > > > and the tunnel interface and then did huge > transfers > > > from branch to branch > > > > just to saturate my T-1 and it did, but the > policy > > > never > > > reserved/prioritized > > > > my voip traffic. > > > > > > > > Serial0/1/0 is up, line protocol is up > > > > Hardware is GT96K with integrated T1 > > > CSU/DSU > > > > Internet address is x.x.x.x/30 > > > > MTU 1500 bytes, BW 1544 Kbit/sec, DLY > > > 20000 usec, > > > > reliability 255/255, txload 231/255, > > > rxload 16/255 > > > > > > > > Service-policy output: VOIPpm > > > > queue stats for all priority > > > classes: > > > > queue limit 64 packets > > > > (queue depth/total > > > drops/no-buffer drops) 0/0/0 > > > > (pkts output/bytes > > > output) 0/0 > > > > > > > > Class-map: VOIPcm (match-all) > > > > 0 packets, 0 bytes > > > > 5 minute offered rate 0 > > > bps, drop rate 0 bps > > > > Match: access-group 156 > > > > Priority: 33% (509 > > > kbps), burst bytes 12700, b/w exceed drops: 0 > > > > > > > > Class-map: class-default > > > (match-any) > > > > 1437759 packets, > > > 848687414 bytes > > > > > > > > >From my research, it looks like the > > > qos-preclassify command only affects > > > > traffic going over the tunnel. Any help would > be very > > > much appreciated. > > > > > > > > > > > > --- On Thu, 4/4/13, David Prall <[email protected]> > > > wrote: > > > > > > > > > From: David Prall <[email protected]> > > > > > Subject: RE: [c-nsp] QoS not working - > VPN acl > > > conflicting??? > > > > > To: "'false'" <[email protected]>, > > > "'cisco mailing list'" <cisco- > > > > [email protected]> > > > > > Date: Thursday, April 4, 2013, 12:11 PM > > > > > Need to turn on Pre-Classify in the > > > > > ipsec crypto map. Otherwise all you are > > > > > seeing is the ipsec traffic. > > > > > > > > > > David > > > > > > > > > > -- > > > > > http://dcp.dcptech.com > > > > > > > > > > > -----Original Message----- > > > > > > From: [email protected] > > > > > [mailto:cisco-nsp- > > > > > > [email protected]] > > > > > On Behalf Of false > > > > > > Sent: Thursday, April 04, 2013 > 12:49 PM > > > > > > To: cisco mailing list > > > > > > Subject: [c-nsp] QoS not working - > VPN acl > > > > > conflicting??? > > > > > > > > > > > > > > > > > > Hello, > > > > > > I have a QoS policy in place that > is set > > > to > > > > > reserve/prioritize traffic > > > > > for my > > > > > > outgoing VoIP traffic. We outsource > our voip > > > solution. > > > > > > > > > > > > I am trying to test my QoS policy > by > > > performing > > > > > multiple file transfers > > > > > > outbound to our remote site over > vpn which > > > uses the > > > > > same interface. You > > > > > > can see by the txload stats below > that it > > > should have > > > > > been high enough to > > > > > > make the voip policy kick in bit it > didn't. > > > There were > > > > > about six phones > > > > > > connected but not being used. They > are just > > > doing > > > > > keepalives for > > > > > > regisration, etc to the main > server, which is > > > indicated > > > > > in the access list > > > > > > below. Any ideas? Thank you, > > > > > > > > > > > > Serial0/1/0 is up, line protocol is > up > > > > > > Hardware is GT96K with integrated > T1 CSU/DSU > > > > > > Internet address is x.x.x.x/30 > > > > > > MTU 1500 bytes, BW 1544 Kbit/sec, > DLY 20000 > > > usec, > > > > > > reliability 255/255, txload > 218/255, rxload > > > 19/255 > > > > > > > > > > > > router#sh policy-map interface > serial 0/1/0 > > > > > > Serial0/1/0 > > > > > > > > > > > > Service-policy output: VOIPpm > > > > > > queue stats for all priority > classes: > > > > > > queue limit 64 packets > > > > > > (queue depth/total drops/no-buffer > drops) > > > 0/0/0 > > > > > > (pkts output/bytes output) 0/0 > > > > > > > > > > > > Class-map: VOIPcm (match-all) > > > > > > 0 packets, 0 bytes > > > > > > 5 minute offered rate 0 bps, drop > rate 0 bps > > > > > > Match: access-group 156 > > > > > > Priority: 33% (509 kbps), burst > bytes 12700, > > > b/w exceed > > > > > drops: 0 > > > > > > > > > > > > > > > > > > Class-map: class-default > (match-any) > > > > > > 898811 packets, 199817314 bytes > > > > > > 5 minute offered rate 23000 bps, > drop rate > > > 3000 bps > > > > > > Match: any > > > > > > Queueing > > > > > > queue limit 64 packets > > > > > > (queue depth/total drops/no-buffer > > > drops/flowdrops) > > > > > 0/81175/0/81175 > > > > > > (pkts output/bytes output) > 824273/184794616 > > > > > > Fair-queue: per-flow queue limit > 16 > > > > > > router# > > > > > > > > > > > > > > > > > > CONFIG: > > > > > > access-list 156 permit ip any host > > > 66.x.x.x.x > > > > > > > > > > > > class-map match-all VOIPcm > > > > > > match access-group 156 > > > > > > > > > > > > policy-map VOIPpm > > > > > > class VOIPcm > > > > > > priority percent 33 > > > > > > class class-default > > > > > > fair-queue > > > > > > > > > > > > interface Serial0/1/0 > > > > > > ip address 150.150.150.150 > 255.255.255.252 > > > > > > ip access-group 101 in > > > > > > ip flow ingress > > > > > > ip flow egress > > > > > > ip nat outside > > > > > > ip inspect ISP2-cbac out > > > > > > ip virtual-reassembly > > > > > > encapsulation ppp > > > > > > crypto map vpnmap > > > > > > service-policy output VOIPpm > > > > > > end > > > > > > > > > > > > crypto map vpnmap 21 ipsec-isakmp > > > > > > set peer x.x.x.x > > > > > > set transform-set vpn_set > > > > > > match address 121 > > > > > > crypto map vpnmap 32 ipsec-isakmp > > > > > > set peer x.x.x.x > > > > > > set transform-set vpn_set > > > > > > match address 132 > > > > > > > > > > > > access-list 121 permit gre host > > > 150.150.150.150 host > > > > > 67.x.x.x. > > > > > > access-list 132 permit gre host > > > 150.150.150.150 host > > > > > 57.x.x.x.x > > > > > > > > > > > > > > > _______________________________________________ > > > > > > cisco-nsp mailing list [email protected] > > > > > > https://puck.nether.net/mailman/listinfo/cisco-nsp > > > > > > archive at http://puck.nether.net/pipermail/cisco-nsp/ > > > > > > > > > > > > > > > > > > _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
