10 Replies Latest reply on Mar 11, 2015 1:01 PM by 3l3mn8r

    QoS for Host and Branch sites using GRE/VPN tunnels

    3l3mn8r New Member

      I have a customer that is using a central PRI at host site and delivers calls to and from branch sites over GRE/VPN tunnels.  Branch sites are complaining of poor voice quality.  Branch states they can hear incoming caller fine but caller cannot hear all of their conversation, "cuts in and out".  They also indicated this happens intermittently and was not an issue during my 30 minute call with them this morning, latency tests were stable in the 70ms range across tunnel. I have done some RTP monitoring and noticed some delay and loss so I am assuming it is a carrier issue but I want to put some LLQ QoS in place for all sites to ensure the voip traffic receives priority.  I am not sure how to set this up for this type of network, I have read the QoS for AOS document but not sure about some things.  I have attached a jpg file which shows the topology for this network.  I suppose my issue is that I do not know where to begin, do I assign QoS maps OUT from Host or In or Out from Branches and on what interfaces, tunnels, eth 0/0, etc.  Any help or advice is greatly appreciated.  We advise our customers to use PPP or other private connection but they always want the cheaper circuit.  Cable for all three sites.

       

      Paul

        • Re: QoS for Host and Branch sites using GRE/VPN tunnels
          Employee

          Paul,

           

          Thanks for your question.  Unfortunately when the Internet is used instead of a private leased circuit voice quality cannot be guaranteed between sites.  That being said hopefully implementing QoS will help the situation.

           

          To answer your questions you would need to assign QoS Maps outbound on the WAN interfaces connecting to the Internet at each site.  This should be the same interface that your crypto-maps are applied to for the VPN tunnels.  Inbound QoS Maps are used to tag packets so they can be prioritized in the outbound direction, but will likely not be needed unless the VoIP equipment does not tag by default.  Based on the equipment used in your network diagram that should not be an issue.  Set up your QoS Maps to match traffic on DSCP 46 and set the priority to equal the number of concurrent calls you expect x 100kbps to allow for the call plus overhead (assuming G711 codec).  For example if at one site you expect a max of 2 calls at the same time you would configure for 200kbps of priority.  The Type of Service field of the IP header (containing DSCP and IP Precedence) is preserved through encryption in AOS routers so when the packet is encrypted to go over the VPN tunnel it will stay the same and the QoS map will take care of giving that packet priority over others not meeting the match criteria (DSCP 46).  If you are using an Ethernet WAN as implied by cable modems being used in your diagram, you will need to take the additional step of configuring traffic shaping on the Ethernet WAN interface connecting to the cable modem to match the upload speed of the circuit.  Here is an example that should tie everything together. This was taken from the concepts in Example 1 and Example 2 starting on page 37 of the Configuring QoS in AOS guide:

          Example - Low-Latency Queue VoIP Matching DSCP with an Ethernet WAN


          In this example, a customer has IP phones on their network using VoIP that connect over a VPN to the main site. The phones tag RTP VoIP packets with a DSCP value of 46 and use the G.711 CODEC. The phones also use SIP and tag call control packets with a DSCP of 26. A maximum of two concurrent calls is expected to be up at one time.  A low-latency queue is created to allocate 200 kbps (100kbps for each expected call) for the VoIP traffic to ensure quality is preserved during a congested state on the WAN. This is accomplished by creating a QoS map named VOIP that matches packets tagged with a DSCP of 26 or 46. The priority 200 command is issued to allocate a low-latency queue of 200 kbps for that traffic. The QoS map is applied to the ETH 0/1 WAN interface (with the qos-policy out VOIP command) that connects to the cable modem. A cable modem facilitates Internet access with an upload speed of 384 kbps.  The maximum upload speed for the connection is defined by applying traffic shaping (using the traffic-shape rate 384000 command) to the ETH 0/1 WAN interface so QoS can be enforced.

           

          NOTE: Only the QoS configuration is shown in this example.

           

           

          !

          qos map VOIP 10

            match dscp 46 26

            priority 200

          !

          !

          interface eth 0/1

            ip address 65.162.109.202 255.255.255.252

            traffic-shape rate 384000

            qos-policy out VOIP

            no shutdown

          !

          !

          ip route 0.0.0.0 0.0.0.0 65.162.109.201

          !

          !

          I hope this helps.


          Thanks,
          Matt

            • Re: QoS for Host and Branch sites using GRE/VPN tunnels
              3l3mn8r New Member

              Matt, sounds great.  I am going to configure now.  One question about the traffic shape rate.  All three locations have different upload speeds, 30mbps, 2Mbps and 1Mbps, should the traffic shape rate match the upoload speeds at each site or should we just make sure we give it enough to process traffic, i.e.  768000 across all eth interfaces?

                • Re: QoS for Host and Branch sites using GRE/VPN tunnels
                  3l3mn8r New Member

                  Matt, I applied 384000 for traffic-shape and priority 200 at one remote site and received a message only 192 available>inactive.  I then switched priority to 192, this is a 10mbps/1Mbps upload speed connection, should I be concerned or should I try someithing else?

                  At another site I have a 30/30Mbps connection and it said I only have 288K available.  Not quite sure why this is?

                    • Re: QoS for Host and Branch sites using GRE/VPN tunnels
                      Employee

                      Paul,

                       

                      To answer your questions:

                       

                      1 – You should match the upload speed at each site.

                       

                      2 – Depending on your configuration the available bandwidth reported for use with QoS can change.  The value of the max-reserved-bandwidth command (75% by default) is multiplied by 1 of three things to calculate the amount of bandwidth available to QoS:

                      • the corresponding reported Layer 1 interface rate (ex: 100 Mbps)
                      • the value configured from the traffic-shape rate command on the WAN Ethernet or VLAN interface this qos map is applied to
                      • the value configured with the bandwidth command on the ip interface this qos map is applied to (NOTE: This is not recommended)

                       

                      From the upload speeds you listed above you would not need to shape down to 384k.  It sounds like one of the three scenarios above is what was triggering the problem where you did not have enough available bandwidth for the value specified in the priority commands.

                       

                      Thanks,

                      Matt

                      1 of 1 people found this helpful
                        • Re: QoS for Host and Branch sites using GRE/VPN tunnels
                          3l3mn8r New Member

                          Thanks Matt, I have no bandwidth specified on eth 0/0 interfaces, I cannot see a max-reserved bandwidth in my config and the layer 1 eth ports are 100Mbps.  Here is a typical interface config for my sites.  Not sure where my upload bandwidth is gone to.

                           

                           

                          interface eth 0/0

                            description WAN connection

                            ip address xxx.xxx.xxx.41  255.255.255.0

                            ip ffe

                            access-policy Public

                            crypto map VPN

                            traffic-shape rate 288000

                            qos-policy out VOIP

                            media-gateway ip primary

                            no shutdown

                            no lldp send-and-receive

                            • Re: QoS for Host and Branch sites using GRE/VPN tunnels
                              Employee

                              The culprit is the traffic-shape rate 288000 command from the output you provided  Unless there is another reason for it being set to that particular value you should set it to match the upload speed of the circuit so QoS can be engaged.  For example at your site with a 2 Mbps upload it should be set to traffic-shape rate 2000000.  The max-reserved-bandwidth command can be seen with a show run verbose or show run interface eth 0/0 verbose.  If you change it from the default value of 75 then it will be visible with a normal show run or show run interface eth 0/0.

                              1 of 1 people found this helpful
                                • Re: QoS for Host and Branch sites using GRE/VPN tunnels
                                  Employee

                                  I went ahead and flagged this post as “Assumed Answered.”  If any of the responses on this thread assisted you, please mark them as either Correct or Helpful answers with the applicable buttons.  This will make them visible and help other members of the community find solutions more easily.  If you still need assistance, I would be more than happy to continue working with you on this - just let me know in a reply.


                                  Thanks,

                                  Matt

                                  • Re: QoS for Host and Branch sites using GRE/VPN tunnels
                                    3l3mn8r New Member

                                    So Matt, what if the upload speed is inconsistent from the ISP.  I have run several speed tests and it varies.  Their current allotment is 10Mbps but I see from 8.x to 10.x returned from speed tests.  So should I set the traffic-shaping to 10000000 or 8000000 or maybe 9000000.  Should we set to actual or average or set to what they are supposed to be getting?  Thanks Matt.

                          • Re: QoS for Host and Branch sites using GRE/VPN tunnels
                            3l3mn8r New Member

                            Thanks for all your help Matt, Any reason I should not use priority unlimited for qos map?  I changed my traffic-shape to match upload speeds and have adjusted priority but thought why not use priority unlimited since I dont care about data quality only voice for this customer.  And when would you ever specify a policy - IN qos map?

                             

                            Also, why do I see this message when looking at the GUI qos-map shaping statistics "There are no policy/interfaces available with shaping enabled" ?

                              • Re: QoS for Host and Branch sites using GRE/VPN tunnels
                                Employee

                                You should use the priority unlimited command with caution as it could prevent vital Layer 2 traffic from being processed.  This is typically more risky with PPP connections.  A network outage could occur when excessive priority traffic is present and consumes all of the available bandwidth on the interface.  If your total voice traffic will never come close to saturating your WAN connection upload speed than you can use unlimited. 

                                 

                                Inbound QoS maps are used to tag packets for outbound prioritization. For example if you have some VoIP equipment that does not tag packets with a DSCP or IP Precedence value, you could configure an inbound QoS map on the interface that traffic will be received on to set one based on the IP address of the VoIP equipment.  Then as that traffic is routed through the unit to the WAN interface, another separate outbound QoS map could match the newly set DSCP value and give it priority over other traffic leaving the WAN interface.

                                 

                                The shaping message you see is due to the fact that your QoS maps are not using the shape average function.  You can read more about it in the Configuring QoS in AOS guide starting on page 22.  The shape average command cannot be specified in conjunction with the priority command in a QoS entry.

                                 

                                Thanks,
                                Matt