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

David Prall dcp at dcptech.com
Fri Apr 5 12:21:14 EDT 2013 

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