[c-nsp] QoS not working - VPN acl conflicting???
false
jctx09 at yahoo.com
Fri Apr 5 14:09:35 EDT 2013
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 <dcp at dcptech.com> wrote:
> From: David Prall <dcp at dcptech.com>
> Subject: RE: [c-nsp] QoS not working - VPN acl conflicting???
> To: "'false'" <jctx09 at yahoo.com>, "'cisco mailing list'" <cisco-nsp at puck.nether.net>
> 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:jctx09 at yahoo.com]
> > 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 <dcp at dcptech.com>
> wrote:
> >
> > > From: David Prall <dcp at dcptech.com>
> > > Subject: RE: [c-nsp] QoS not working - VPN acl
> conflicting???
> > > To: "'false'" <jctx09 at yahoo.com>,
> "'cisco mailing list'" <cisco-
> > nsp at puck.nether.net>
> > > 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:jctx09 at yahoo.com]
> > > > 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 <dcp at dcptech.com>
> > > wrote:
> > > >
> > > > > From: David Prall <dcp at dcptech.com>
> > > > > Subject: RE: [c-nsp] QoS not working -
> VPN acl
> > > conflicting???
> > > > > To: "'false'" <jctx09 at yahoo.com>,
> > > "'cisco mailing list'" <cisco-
> > > > nsp at puck.nether.net>
> > > > > 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: cisco-nsp-bounces at puck.nether.net
> > > > > [mailto:cisco-nsp-
> > > > > > bounces at puck.nether.net]
> > > > > 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 cisco-nsp at puck.nether.net
> > > > > > https://puck.nether.net/mailman/listinfo/cisco-nsp
> > > > > > archive at http://puck.nether.net/pipermail/cisco-nsp/
> > > > >
> > > > >
> > >
> > >
>
>
More information about the cisco-nsp
mailing list