A few comments inline below in RED...
On Tue, Oct 1, 2013 at 11:00 AM, virajith <vir...@rediffmail.com> wrote:
> Hi Justin,
>
> Thanks for your reply.
>
> After taking out and reapplying the config it appears that the HQ to SC
> issue for calls work. The calls between SB , HQ , SC also work.
>
> However when inbound calls come from pstn to the H323 gateway leading to
> the PSTN I notice that it gives a fast busy. Upon removing QOS the calls
> work fine.
>
Justin: look at the response below for question 3 on LAN QoS...if I
come up with something in particular I'll let you know. Take a close look
at your singling path between the gateway/CUCM and the phone/CUCM in the
example as both are crossing the WAN (unless this is your HQ site), while
the media gateway/phone should be local (unless somehow you are using an
MTP at a different site?). One-way cRTP over WAN will cause issues, but
this *should* only apply to calling over WAN and not to a gateway talking
to a local phone (ie, not crossing wan - unless you have a home lab where
using HQ switch to power SB/SC phones across WAN).
> Questions:
> =================
>
> 1) Would you recommend applying wan qos manually? is it the same
> procedure ? Also how is it different from the auto qos option?
>
Justin: I always use auto qos when the question asks for MLP. It can
be done manually but there are a lot of commands to build the
virtual-template and I cannot do these faster than auto qos. For FRTS I
sometimes use auto qos and sometimes don't (use SRDN) to be familiar with
both. If the question asks for "class based" then I just use the SRND
reference config and do it manually.
> 2) What would be a safe approach to take ?
>
Justin: To avoid issues I save the running config just before and just
after auto qos, then use "show archive config diff flash:before
flash:after" to see what auto qos actually did. (I do this on the switch
too.) After auto qos I edit as needed, and if it doesn't work after a few
minutes of troubleshooting I reload the router and revert to the "before"
config. After it comes back up you can either retry auto qos (faster if it
works, but if it doesn't you'll lose more time to reload again) or apply it
manually (because you already have the cli from the first time and your
tweaks).
>
>
> 3) My LAN QOS has not been setup on the switch ? Do you think that this
> could cause an issue on the WAN?
Justin: I don't think the lack of LAN QoS would affect much on the
WAN, although without reviewing a specific scenario I don't want to suggest
its not possible under a unique circumstance (I can't think of one at the
moment). However, you need to consider the end-to-end QoS from
phones/servers/gateways marking traffic and the switch and/or router
re-marking/shaping/policing. For example, if your WAN QoS polices
signaling at CS3 to 5% there are differences between the "trusted" and
"untrusted" versions of auto-qos. The untrusted methods will build
ACL/NBAR to mark your traffic, but the trusted method relies on a correct
marking already. Phones and servers should mark signaling CS3, but this
old version of IOS uses AF31. You will need to set
your generated singling to CS3 for mgcp (mgcp ip qos dscp cs3 sig),
dial-peers (under dial-peer voip: ip qos dscp cs3 sig), and sccp (sccp
ip precedence 3). Router generated media usually defaults to EF.
>
> Regards,
> Vir
>
>
>
>
> From: Justin Carney <justin.s.car...@gmail.com>
> Sent: Tue, 24 Sep 2013 04:04:57
> To: virajith <vir...@rediffmail.com>
> Cc: "ccie_voice@onlinestudylist.com" <ccie_voice@onlinestudylist.com>
> Subject: Re: [OSL | CCIE_Voice] QOS WAN
> For Site A - it looks like your serial sub interface 102 references DLCI
> 103, then suf-if 103 references DLCI 102...is that a typo or is that
> correct? Shut down one and verify that you can still get to the other
> (correct) site.
>
> For Site B - I noticed an interesting line in your R2 output on physical
> s0/1/0 it looks like it is set to 56K. I recently had this same issue but
> didn't have time to continue to troubleshoot. Whatever is causing that to
> show up may be part of your issue with your site B.
>
> The way I got myself in that situation was by configuring under the wrong
> subinterface (and creating one) and then "no" sub-if without removing the
> map-class. When I get time to lab I plan to recreate this and then try
> putting the wrong sub-if back, remove the map class, then delete the sub-if.
>
> I don't see anything that jumps out for your site C but will compare that
> to my results next time I lab (probably tomorrow)
>
>
> On Mon, Sep 23, 2013 at 11:46 AM, virajith <vir...@rediffmail.com> wrote:
>
>> Hello Justin,
>>
>> Thanks for your reply.
>>
>>
>> Please find the necessary outputs below...
>>
>> At R1 :
>> =============
>>
>> interface Serial0/0/0.102 point-to-point ----> connected to R3 *<<<<<<<
>> sub-IF is .102 *
>> ip address X..X.X.1
>> 255.255.255.0<http://www.rediffmail.com/cgi-bin/red.cgi?account_type=1&red=http://255.255.255.0&isImage=0&BlockImage=0&rediffng=0>
>> ip ospf network point-to-point
>> frame-relay interface-dlci 103 *<<<<<<< dlci is 103...is
>> that intentional to not match sub-if or a typo?*
>> class 2MBPS
>> ip rsvp bandwidth 112
>> !
>> interface Serial0/0/0.103 point-to-point ----> connected to R2 *<<<<<<<
>> sub-IF is .103*
>> bandwidth 384
>> ip address X..X.X.1
>> 255.255.255.0<http://www.rediffmail.com/cgi-bin/red.cgi?account_type=1&red=http://255.255.255.0&isImage=0&BlockImage=0&rediffng=0>
>> ip ospf network point-to-point
>> frame-relay interface-dlci 102
>> class AutoQoS-FR-Se0/0/0-102 *<<<<<<< dlci is 102*
>> auto qos voip trust
>>
>>
>>
>> R1#show interfaces serial 0/0/0.102
>> Serial0/0/0.102 is up, line protocol is up
>> Hardware is GT96K Serial
>> Internet address is X..X.X.1/24
>> MTU 1500 bytes, BW 1544 Kbit/sec, DLY 20000 usec,
>> reliability 255/255, txload 4/255, rxload 1/255
>> Encapsulation FRAME-RELAY
>> CRC checking enabled
>> Last clearing of "show interface" counters never
>> R1#show interfaces serial 0/0/0.103
>> Serial0/0/0.103 is up, line protocol is up
>> Hardware is GT96K Serial
>> Internet address is X..X.X.1/24
>> MTU 1500 bytes, BW 384 Kbit/sec, DLY 20000 usec,
>> reliability 255/255, txload 4/255, rxload 1/255
>> Encapsulation FRAME-RELAY
>> CRC checking enabled
>> Last clearing of "show interface" counters never
>>
>>
>> At R2 :
>> ============
>>
>> interface Serial0/2/0.103 point-to-point ----> connected to R1
>> bandwidth 384
>> ip address X..X.X.2
>> 255.255.255.0<http://www.rediffmail.com/cgi-bin/red.cgi?account_type=1&red=http://255.255.255.0&isImage=0&BlockImage=0&rediffng=0>
>> ip ospf network point-to-point
>> frame-relay interface-dlci 201
>> class AutoQoS-FR-Se0/2/0-201
>> auto qos voip trust
>>
>>
>> AT R3 :
>> =================
>>
>> interface Serial0/3/0.3 point-to-point -----> connected to R1
>> ip address X.X.X.3
>> 255.255.255.0<http://www.rediffmail.com/cgi-bin/red.cgi?account_type=1&red=http://255.255.255.0&isImage=0&BlockImage=0&rediffng=0>
>> ip ospf network point-to-point
>> frame-relay interface-dlci 301
>> class 2MBPS
>> ip rsvp bandwidth 112
>>
>>
>> **To check traffic shape & show frame-r pvc**
>> ==============================================
>>
>>
>> 1) For R1
>>
>>
>> R1#sh traffic-shape
>>
>> Interface Se0/0/0.102
>> Access Target Byte Sustain Excess Interval Increment Adapt
>> VC List Rate Limit bits/int bits/int (ms) (bytes) Active
>> 103 2048000 2560 20480 0 10 2560 -
>>
>> Interface Se0/0/0.103
>> Access Target Byte Sustain Excess Interval Increment Adapt
>> VC List Rate Limit bits/int bits/int (ms) (bytes) Active
>> 102 364800 456 3648 0 10 456 -
>>
>>
>>
>>
>> R1#sh frame-relay pvc
>>
>> PVC Statistics for interface Serial0/0/0 (Frame Relay DTE)
>>
>> Active Inactive Deleted Static
>> Local 2 0 0 0
>> Switched 0 0 0 0
>> Unused 0 0 0 0
>>
>> DLCI = 102, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE =
>> Serial0/0/0.103
>>
>> input pkts 215336 output pkts 186772 in bytes 11708216
>> out bytes 65850084 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 3306 out bcast bytes 401511
>> 5 minute input rate 4000 bits/sec, 10 packets/sec
>> 5 minute output rate 15000 bits/sec, 9 packets/sec
>> pvc create time 06:57:12, last time pvc status changed 00:57:39
>>
>> DLCI = 103, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE =
>> Serial0/0/0.102
>>
>> input pkts 34516 output pkts 33480 in bytes 2683832
>> out bytes 21201718 dropped pkts 13 in pkts dropped 0
>> out pkts dropped 13 out bytes dropped 12610
>> late-dropped out pkts 13 late-dropped out bytes 12610
>> 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 3248 out bcast bytes 396343
>> 5 minute input rate 0 bits/sec, 1 packets/sec
>> 5 minute output rate 21000 bits/sec, 0 packets/sec
>> pvc create time 06:57:21, last time pvc status changed 00:57:48
>>
>>
>>
>> 2) For R2
>> ---------------------
>>
>>
>> R2#show traffic-shape
>>
>> Interface Se0/2/0
>> Access Target Byte Sustain Excess Interval Increment
>> Adapt
>> VC List Rate Limit bits/int bits/int (ms) (bytes)
>> Active
>> 301 56000 875 7000 0 125 875 -
>> *<<<<<<< THIS 56K may be an issue*
>>
>> Interface Se0/2/0.103
>> Access Target Byte Sustain Excess Interval Increment
>> Adapt
>> VC List Rate Limit bits/int bits/int (ms) (bytes)
>> Active
>> 201 364800 456 3648 0 10 456 -
>> R2#sh fram
>> R2#sh frame-relay pvc
>>
>> PVC Statistics for interface Serial0/2/0 (Frame Relay DTE)
>>
>> Active Inactive Deleted Static
>> Local 1 0 0 0
>> Switched 0 0 0 0
>> Unused 1 0 0 0
>>
>> DLCI = 201, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE =
>> Serial0/2/0.103
>>
>> input pkts 188478 output pkts 216759 in bytes 66282296
>> out bytes 11785898 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 3327 out bcast bytes 400955
>> 5 minute input rate 26000 bits/sec, 9 packets/sec
>> 5 minute output rate 4000 bits/sec, 10 packets/sec
>> pvc create time 06:59:50, last time pvc status changed 00:59:30
>>
>> DLCI = 301, DLCI USAGE = UNUSED, PVC STATUS = ACTIVE, INTERFACE =
>> Serial0/2/0
>>
>> input pkts 0 output pkts 0 in bytes 0
>> out bytes 0 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 0 out bcast bytes 0
>> 5 minute input rate 0 bits/sec, 0 packets/sec
>> 5 minute output rate 0 bits/sec, 0 packets/sec
>> pvc create time 00:59:52, last time pvc status changed 00:59:32
>> R2#
>>
>>
>> 3) For R3
>> --------------------
>>
>> R3#sh traffic-shape
>>
>> R3#sh fram
>> R3#sh frame-relay pv
>>
>> PVC Statistics for interface Serial0/3/0 (Frame Relay DTE)
>>
>> Active Inactive Deleted Static
>> Local 1 0 0 0
>> Switched 0 0 0 0
>> Unused 0 1 0 0
>>
>> DLCI = 201, DLCI USAGE = UNUSED, PVC STATUS = INACTIVE, INTERFACE =
>> Serial0/3/0
>>
>> input pkts 0 output pkts 0 in bytes 0
>> out bytes 0 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 0 out bcast bytes 0
>> 5 minute input rate 0 bits/sec, 0 packets/sec
>> 5 minute output rate 0 bits/sec, 0 packets/sec
>> pvc create time 07:03:41, last time pvc status changed 07:03:41
>>
>> DLCI = 301, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE =
>> Serial0/3/0.3
>>
>> input pkts 33687 output pkts 35031 in bytes 21243954
>> out bytes 2728102 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 3311 out bcast bytes 401031
>> 5 minute input rate 0 bits/sec, 0 packets/sec
>> 5 minute output rate 0 bits/sec, 1 packets/sec
>> pvc create time 07:03:53, last time pvc status changed 01:02:23
>> R3#
>>
>> Thanks once again for your reply.
>>
>> -Vir
>>
>>
>>
>>
>>
>>
>> From: Justin Carney <justin.s.car...@gmail.com>
>> Sent: Mon, 23 Sep 2013 19:39:31
>> To: virajith <vir...@rediffmail.com>
>> Cc: "ccie_voice@onlinestudylist.com" <ccie_voice@onlinestudylist.com>
>> Subject: Re: [OSL | CCIE_Voice] QOS WAN
>>
>> At first glance those steps look ok. What do you see from "show traffic"
>> and "show frame-r pvc #" on all three site routers?
>>
>> For odd audio issues I would look at LAN QoS (make sure you're not
>> policing too low) and ensure you don't have one-way LFI or cRTP (which
>> looks like you moved crtp to policy-map already). For SC phones not
>> registering double check to ensure your frts is keeping that PVC at 2M and
>> its not at the default 56k once frts was enabled on physical interface.
>>
>> Worst case you could back out the configuration, reload, and reapply the
>> config either using auto qos or use your current config as a template and
>> apply manually.
>>
>> You could also post you full cli configs for review.
>>
>> -Justin
>>
>>
>>
>> On Sun, Sep 22, 2013 at 10:30 AM, virajith <vir...@rediffmail.com> wrote:
>>
>>
>> Hello All,
>>
>> Any update? I am still waiting for a reply.
>>
>> Please assist guys.
>>
>>
>>
>>
>>
>>
>> From: "virajith "<vir...@rediffmail.com>
>> Sent: Sat, 21 Sep 2013 07:18:00
>> To: "ccie_voice@onlinestudylist.com"<ccie_voice@onlinestudylist.com>
>> Subject: QOS WAN
>>
>> hi All,
>>
>> I am trying to connect HQ and SB with a 384 k frame relay PVC.Enable
>> FRF.12 link fragmentation and interleave on the Frame Relay connections to
>> fragment large data packets and interleave voice packets to minimize
>> delays. Max delay between fragments should be
>> set at 10 ms . Also provision RTP header compression.
>>
>> Configure LLQ between HQ and SB to ensure voice bearer traffic gets
>> priority queue treatment & voice signalling
>> is guaranteed for 16kbps. Configure the priority queue accomodates
>> up to 4 G729 calls between HQ and SB.
>>
>> Lastly, assume all bearer voice traffic has been marked with
>> traffic CS3.
>>
>>
>> Here are the steps I am following ...
>> -------------------------------------------------------------
>>
>> 1) Going to serial interface connecting from HQ to SB on the HQ router
>> and changing the BW to 384
>>
>> R1(conf)#int ser0/1/0.X
>> R1(config-subif)#bandwidth 384
>>
>>
>> 2) Then apply "auto qos voip trust" under the interface
>>
>> R1(conf)#int ser0/1/0.X point-to-point
>> #frame-relay interface-dlci 201
>> #auto qos voip trust
>>
>>
>> 3) Then after the auto qos trust is applied . I remove
>> no match ip dscp af31
>>
>>
>> 4) add ...priority 47
>> and bandwidth 16
>>
>> 5) Then remove "no frame-relay ip rtp header-compression"
>>
>>
>> 6) Add the following...
>>
>>
>> map-class frame-relay AutoQoS-FR-Se0/1/0-201
>> frame-relay cir 364800
>> frame-relay bc 3648
>> frame-relay be 0
>> frame-relay mincir 364800
>> frame-relay fragment 480
>> service-policy output AutoQoS-Policy-Trust
>>
>>
>>
>> 7) add "compress ip header rtp"
>>
>>
>>
>> 8) I then move to SB router and do the same steps ( 1-7) on the interface
>> connecting to HQ
>>
>>
>>
>> 9) After this I create a class map on HQ router with Site C
>>
>>
>> map-class frame-relay 2MBPS
>> frame-relay cir 2048000
>> frame-relay bc 20480
>> frame-relay be 0
>> frame-relay mincir 2048000
>>
>>
>> interface Serial0/1/0.2 point-to-point
>> description *** FR Connected to BR2 ***
>> frame-relay interface-dlci 202
>> class 2MBPS
>>
>>
>> Problem:
>> -------------------------
>>
>> 1) My phones in Site C unregister and don't register back after the above
>> configuration. Looks like QOS breaks phone registration
>>
>>
>> 2) The calls between sites appear to be slightly delayed.
>>
>> 3) Audio on the phones seems to be watery.
>>
>>
>>
>> Questions :
>> ------------------------
>>
>> 1) What is wrong with the above config?
>>
>> 2) Is there an easier and safer way for achieving the task?
>>
>> 3) How can the above task be achieved without causing problems?
>>
>>
>> Regards,
>> Vir
>>
>> <http://sigads.rediff.com/RealMedia/ads/click_nx.ads/www.rediffmail.com/signatureline.htm@Middle?>
>> *Ganesha offers* Company email & website (*FREE*) at your own domain (*
>> FREE*) - *KNOW MORE
>> >*<http://track.rediff.com/click?url=___http://businessemail.rediff.com/company-email-hosting-services?sc_cid=sign-060913___&cmp=host&lnk=sign-060913&nsrv1=host>
>>
>>
>>
>>
>>
>>
>> <http://sigads.rediff.com/RealMedia/ads/click_nx.ads/www.rediffmail.com/signatureline.htm@Middle?>
>> *Ganesha offers* Company email & website (*FREE*) at your own domain (*
>> FREE*) - *KNOW MORE
>> >*<http://track.rediff.com/click?url=___http://businessemail.rediff.com/company-email-hosting-services?sc_cid=sign-060913___&cmp=host&lnk=sign-060913&nsrv1=host>
>>
>>
>>
>>
>>
>> _______________________________________________
>> For more information regarding industry leading CCIE Lab training, please
>> visit www.ipexpert.com
>>
>> Are you a CCNP or CCIE and looking for a job? Check out
>> www.PlatinumPlacement.com
>>
>>
>>
>>
>> <http://sigads.rediff.com/RealMedia/ads/click_nx.ads/www.rediffmail.com/signatureline.htm@Middle?>
>> *Ganesha offers* Company email & website (*FREE*) at your own domain (*
>> FREE*) - *KNOW MORE
>> >*<http://track.rediff.com/click?url=___http://businessemail.rediff.com/company-email-hosting-services?sc_cid=sign-060913___&cmp=host&lnk=sign-060913&nsrv1=host>
>>
>>
>>
>>
>>
>
>
> <http://sigads.rediff.com/RealMedia/ads/click_nx.ads/www.rediffmail.com/signatureline.htm@Middle?>
> *Ganesha offers* Company email & website (*FREE*) at your own domain (*
> FREE*) - *KNOW MORE
> >*<http://track.rediff.com/click?url=___http://businessemail.rediff.com/company-email-hosting-services?sc_cid=sign-060913___&cmp=host&lnk=sign-060913&nsrv1=host>
>
>
>
>
>
_______________________________________________
For more information regarding industry leading CCIE Lab training, please visit
www.ipexpert.com
Are you a CCNP or CCIE and looking for a job? Check out
www.PlatinumPlacement.com
