From: Nick Griffin (ngriffin@sio.midco.net)
Date: Mon Jan 23 2006 - 22:17:52 GMT-3
Marvin, thanks for the reply, I do have a nearly identical configuration
outbound on the serial link to the central site as well. Similar
problems are experienced in both directions.
On Mon, 2006-01-23 at 16:53 -0800, Marvin Wu wrote:
> Hi Nick,
>
> The config looks okay to me, couple of questions, Do you have LLQ on
> BOTH central site and remote site ? As QoS is apply to outgoing traffic only
> , the voice quality/delay could cause by the return traffic jam up the link
> from central to remote, not the other way around.
>
> Do you see the same problem if central site make a FTP request to
> remote ?
>
> Thanks,
>
> Marvin
>
>
>
>
> On 1/22/06, Nick Griffin <ngriffin@sio.midco.net> wrote:
> >
> > Anyone have any thoughts on the configuration below? Thanks
> >
> > On Sat, 2006-01-21 at 11:43 -0600, Nick Griffin wrote:
> > > Here's a real world one, that I think probably applies to qos in the
> > > lab. I'm looking to get some second opinions on the configuration listed
> > > below.
> > >
> > > Basically the Setup is a central site and a remote site connected my an
> > > MPLS cloud. There is EBGP peering between the customer edge, and the
> > > provider. The provider is offering a qos packages that states the
> > > CDR/CIR will be 512K, with 80% of the 512K reserved for real time
> > > traffic, traffic leaving the Customer router must have the appropriate
> > > DSCP/Precedence values intact when traffic enters the mpls cloud. The
> > > problem that I am experiencing is unacceptable rtp/call quality when a
> > > couple larger file transfers are initiated from the remote site, pulling
> > > data from the central to the remote location. The physical access rate
> > > of both circuits is a T1. Things that I am noticing are high levels of
> > > jitter reported on the phones, in addition to what appears to be some
> > > packet loss.
> > >
> > > Question 1: the problem appears to begin when there gets to be around
> > > 900K of traffic on the serial interface. The show policy map on the
> > > interface doesn't show any drops in the priority queue, packets are
> > > being matched, and there is an offered rate. Is the delay being
> > > experienced being caused by large data packets in the output queue, and
> > > I should work with the provider to enable MLPPP with LFI? If so, how
> > > should be interleaving be set in this type of service, should I be
> > > basing my fragmentation size off of the lowest CIR in the cloud, or off
> > > of the physical access rate. I guess based on everything I read I
> > > wouldn't think that LFI on this interface would be required, since
> > > serialization delay shouldn't be an major concern under above 768.
> > >
> > > Question 2: it appears that 28XX platform defaults with a tx-ring-limit
> > > value of 128, I have tried changing it to 3, but I didn't see much of a
> > > difference, any recommendations in regards to how this should be set.
> > > Ideally a smaller tx queue should reduce delay, but at the increase tail
> > > drops.
> > >
> > > Question 3: When I first started doing some research on FRTS and FRF.12,
> > > there was talk of a DUAL FIFO queue being enabled, which you could see
> > > from a show interface ser0/blah, however some reseach documentation I
> > > found on Cisco says that this is no longer the case. Can anyone confirm?
> > >
> > > Sorry for the long email, and any thoughts/recommendations are greatly
> > > appreciated!
> > >
> > >
> > >
> > > class-map match-any bearer
> > > match access-group name VoIP
> > > class-map match-any control
> > > match access-group name Control
> > > class-map match-all default
> > > !
> > > !
> > > policy-map MPLS-Voice
> > > class bearer
> > > set dscp ef
> > > priority 392
> > > class control
> > > set dscp af31
> > > bandwidth 8
> > > queue-limit 512
> > > class class-default
> > > set dscp default
> > > !
> > > interface Serial1/0:0
> > > no ip address
> > > ip nbar protocol-discovery
> > > encapsulation frame-relay
> > > ip route-cache flow
> > > load-interval 30
> > > no fair-queue
> > > frame-relay traffic-shaping
> > > !
> > > interface Serial1/0:0.912 point-to-point
> > > description DLCI 912 for EPVC Circuit ID: DHEC980474
> > > ip address 192.168.249.9 255.255.255.252
> > > frame-relay interface-dlci 912 IETF
> > > class MPLS-Shaping
> > > !
> > > ip access-list extended Control
> > > permit tcp any range 2000 2002 any
> > > remark SCCP
> > > permit tcp any any range 2000 2002
> > > remark H323 Slow Start
> > > permit tcp any any range 11000 11999
> > > remark H323 MGCP
> > > permit udp any any eq 2427
> > > permit tcp any eq 1720 any
> > > permit tcp any eq 1719 any
> > > permit tcp any any eq 1720
> > > permit tcp any any eq 1719
> > > ip access-list extended VoIP
> > > permit ip host 10.34.0.15 any dscp ef
> > > permit udp host 10.34.0.15 any range 16384 32767
> > > permit ip any any dscp ef
> > > permit udp any any range 16384 32767
> > > permit udp any range 16384 32767 any
> > > permit ip any any precedence critical
> > > permit icmp any host 172.30.70.240
> > > !
> > > !
> > > map-class frame-relay MPLS-Shaping
> > > frame-relay cir 1536000
> > > frame-relay bc 15360
> > > frame-relay be 0
> > > frame-relay mincir 1536000
> > > service-policy output MPLS-Voice
> > >
> > >
> > >
> > >
> > > wc-br1#sh frame-relay pvc 912
> > >
> > > PVC Statistics for interface Serial1/0:0 (Frame Relay DTE)
> > >
> > > DLCI = 912, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE =
> > > Serial1/0:0.912
> > >
> > > input pkts 191249262 output pkts 240144955 in bytes 2818077992
> > > out bytes 1483472553 dropped pkts 0 in pkts dropped 0
> > > out pkts dropped 0 out bytes dropped 0
> > > in FECN pkts 0 in BECN pkts 0 out FECN pkts 0
> > > out BECN pkts 0 in DE pkts 0 out DE pkts 0
> > > out bcast pkts 50195 out bcast bytes 17332184
> > > 5 minute input rate 244000 bits/sec, 105 packets/sec
> > > 5 minute output rate 287000 bits/sec, 102 packets/sec
> > > pvc create time 4w6d, last time pvc status changed 4d10h
> > > cir 1460000 bc 14600 be 0 byte limit 1825 interval 10
> > > mincir 1460000 byte increment 1825 Adaptive Shaping none
> > > pkts 120186 bytes 19556954 pkts delayed 62 bytes delayed
> > > 24062
> > > shaping inactive
> > > traffic shaping drops 0
> > > service policy MPLS-Voice
> > > Serial1/0:0.912: DLCI 912 -
> > >
> > > Service-policy output: MPLS-Voice
> > >
> > > Class-map: bearer (match-any)
> > > 116964273 packets, 7673643044 bytes
> > > 30 second offered rate 9000 bps, drop rate 0 bps
> > > Match: access-group name VoIP
> > > 9379664 packets, 614783560 bytes
> > > 30 second rate 9000 bps
> > > QoS Set
> > > dscp ef
> > > Packets marked 116964276
> > > Queueing
> > > Strict Priority
> > > Output Queue: Conversation 72
> > > Bandwidth 392 (kbps) Burst 9800 (Bytes)
> > > (pkts matched/bytes matched) 0/0
> > > (total drops/bytes drops) 0/0
> > >
> > > Class-map: control (match-any)
> > > 3431603 packets, 218501882 bytes
> > > 30 second offered rate 2000 bps, drop rate 0 bps
> > > Match: access-group name Control
> > > 3431603 packets, 218501882 bytes
> > > 30 second rate 2000 bps
> > > QoS Set
> > > dscp af31
> > > Packets marked 3431612
> > > Queueing
> > > Output Queue: Conversation 73
> > > Bandwidth 8 (kbps) Max Threshold 512 (packets)
> > > (pkts matched/bytes matched) 0/0
> > > (depth/total drops/no-buffer drops) 0/0/0
> > >
> > > Class-map: class-default (match-any)
> > > 119749082 packets, 36541003385 bytes
> > > 30 second offered rate 115000 bps, drop rate 0 bps
> > > Match: any
> > > QoS Set
> > > dscp default
> > > Packets marked 119699145
> > > Output queue size 0/max total 600/drops 0
> > >
> > >
> > >
> > >
> > >
> > > * Serial1/0:0.912 - - - - - - - - -
> > > NOTE:No separate counters are maintained for subinterfaces
> > > Hence Details of subinterface are not shown
> > > r28yanSD01wc-br1#sh int ser 1/0:0 summary
> > >
> > > *: interface is up
> > > IHQ: pkts in input hold queue IQD: pkts dropped from input queue
> > > OHQ: pkts in output hold queue OQD: pkts dropped from output queue
> > > RXBS: rx rate (bits/sec) RXPS: rx rate (pkts/sec)
> > > TXBS: tx rate (bits/sec) TXPS: tx rate (pkts/sec)
> > > TRTL: throttle count
> > >
> > > Interface IHQ IQD OHQ OQD RXBS RXPS TXBS TXPS TRTL
> > > ------------------------------------------------------------------------
> > > * Serial1/0:0 0 0 26 14578 225000 131 937000 157
> > > 0
> > > * Serial1/0:0.912 - - - - - - - - -
> > > NOTE:No separate counters are maintained for subinterfaces
> > > Hence Details of subinterface are not shown
> > > r28yanSD01wc-br1#sh int ser 1/0:0 summary
> > >
> > > *: interface is up
> > > IHQ: pkts in input hold queue IQD: pkts dropped from input queue
> > > OHQ: pkts in output hold queue OQD: pkts dropped from output queue
> > > RXBS: rx rate (bits/sec) RXPS: rx rate (pkts/sec)
> > > TXBS: tx rate (bits/sec) TXPS: tx rate (pkts/sec)
> > > TRTL: throttle count
> > >
> > > Interface IHQ IQD OHQ OQD RXBS RXPS TXBS TXPS TRTL
> > > ------------------------------------------------------------------------
> > > * Serial1/0:0 0 0 13 14587 225000 131 937000 157
> > > 0
> > > * Serial1/0:0.912 - - - - - - - - -
> > > NOTE:No separate counters are maintained for subinterfaces
> > > Hence Details of subinterface are not shown
> > >
> > > _______________________________________________________________________
> > > Subscription information may be found at:
> > > http://www.groupstudy.com/list/CCIELab.html
> >
> > _______________________________________________________________________
> > Subscription information may be found at:
> > http://www.groupstudy.com/list/CCIELab.html
>
> _______________________________________________________________________
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html
This archive was generated by hypermail 2.1.4 : Wed Feb 01 2006 - 07:45:50 GMT-3