[c-nsp] QoS not working - VPN acl conflicting???

false jctx09 at yahoo.com
Fri Apr 5 10:28:09 EDT 2013 

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