Satellite QOS

Unanswered Question
Apr 14th, 2012

I have a satellite connection that is shared with 12 people. Now, I don't want to chop up the bandwidth by 12 people and call it a day because not everyone is on at the same time (day shift, night shift, etc.). So, I've devised a QOS policy that I put on the WAN interface and the one facing the LAN. I've posted below what I am running. Anyone have any suggestions/comments?

class-map match-any WEB_BROWSERS

match protocol dns

match protocol secure-http

match protocol http

class-map match-all TORRENTS

match protocol bittorrent

match protocol edonkey

match protocol directconnect

match protocol fasttrack

match protocol gnutella

match protocol kazaa2

class-map match-any packet-40

match packet length min 40 max 89

class-map match-any packet-90

match packet length min 90 max 159

class-map match-any VOIP_PHONES

match protocol rtp

match  dscp ef

match ip dscp ef

class-map match-any VOIP_SOFTWARE

match protocol skype

class-map match-any DOWNLOADERS

match protocol ftp

match protocol secure-ftp

!

!

policy-map PRIORITIZE_PROTOCOLS

class VOIP_PHONES

    bandwidth percent 28

class VOIP_SOFTWARE

    bandwidth percent 20

class WEB_BROWSERS

    bandwidth percent 50

class DOWNLOADERS

    shape average 50000 55000

  set dscp cs1

class TORRENTS

   drop

class class-default

    fair-queue

policy-map POLICE

class class-default

    shape average 200000 220000 0

  service-policy PRIORITIZE_PROTOCOLS

!

!

!

!

!

interface FastEthernet0/0

description Link to SAT Modem

bandwidth 240

bandwidth receive 900

ip address 109.235.XX 255.255.X.X

ip nbar protocol-discovery

ip flow ingress

ip flow egress

ip nat outside

no ip virtual-reassembly

load-interval 30

duplex auto

speed auto

crypto map ipsec-maps

service-policy output POLICE

!

interface FastEthernet0/1

ip address 192.168.10.1 255.255.255.0

ip nat inside

ip virtual-reassembly

duplex auto

speed auto

service-policy output PRIORITIZE_PROTOCOLS

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Average Rating: 0 (0 ratings)
JosephDoherty Sat, 04/14/2012 - 18:50

Disclaimer

The Author of this posting offers the information contained within this posting without consideration and with the reader's understanding that there's no implied or expressed suitability or fitness for any purpose. Information provided is for informational purposes only and should not be construed as rendering professional advice of any kind. Usage of this posting's information is solely at reader's own risk.

Liability Disclaimer

In no event shall Author be liable for any damages whatsoever (including, without limitation, damages for loss of use, data or profit) arising out of the use or inability to use the posting's information even if Author has been advised of the possibility of such damage.

Posting

If you LAN egress will only ever receive from the satellite, and if that's only at 200 Kbps, you never have congestion to trigger the policy.

Don't recall rules for combining crypto maps and QoS, but you're policy wouldn't be really effective if the QoS policy only "sees" crypto traffic.

When dealing with VoIP traffic, you normally place it into LLQ.  (This applies to your two VoIP traffic classes, which you could define as two LLQ classes, although there's actually only one LLQ, or logically combine.)

When working with multiple classes, rarely should you need to police or shape class traffic, just set it's bandwidth guarantee lower.  I.e., if you're worried about downloaders class, don't shape it, set it's priority (much) lower.  This precludes it from being adverse to other traffic (likely your reason for its shaper) but allows it to otherwise use available bandwidth.

With FQ in class default, I've found you often don't need "special" classes except for special cases, such as VoIP LLQ, your torrents class (to drop all) and perhaps your downloaders to minimize bandwidth guarantee.  I.e. leaving web_browsers in FQ might be fine.

PS:

What version of IOS are you using?

rcraig114 Sat, 04/14/2012 - 19:37

Joseph,

     Thanks for replying so quickly. I am running version flash:c2800nm-adventerprisek9_ivs-mz.124-24.T7.bin. Some of what you said is a bit over my head. Can you elaborate or give me an example of some of the things you mentioned? From the sound of it, my policies aren't too far off, but any help is appreciated. My main priorities is to make sure VOIP is untouched when either going across the VPN tunnel or out to a SIP provider (testing both methods right now), web users can browse with no problems, torrents are dropped, and downloaders get the bottom of the barrel. My satellite plan is 1024/256 and i usually see aroudn 600-900 down and 150-200 up.

JosephDoherty Sun, 04/15/2012 - 05:20

Disclaimer

The  Author of this posting offers the information contained within this  posting without consideration and with the reader's understanding that  there's no implied or expressed suitability or fitness for any purpose.  Information provided is for informational purposes only and should not  be construed as rendering professional advice of any kind. Usage of this  posting's information is solely at reader's own risk.

Liability Disclaimer

In  no event shall Author be liable for any damages whatsoever (including,  without limitation, damages for loss of use, data or profit) arising out  of the use or inability to use the posting's information even if Author  has been advised of the possibility of such damage.

Posting

Sure I can - and you're in luck as your IOS supports HQF QoS.

Again, placing "queuing" policy on your LAN interface egress won't trigger unless the traffic volume can exceed interface capacity (or you shape slower - which you were, correctly, doing for Ethernet to the Satellite).  Ideally, you would like to define QoS for the other side's egress.  If this link is supporting Internet from an ISP, they normally won't support this.  You can "do things" to influence inbound traffic, but they are inexact, especially when trying to support VoIP.

First we want to shape for available egress bandwitdh, which you had about right although you might want to rename as shaping is different from policing (which is a technique that might be used to influcence inbound usage).

interface FastEthernet0/0

description Link to SAT Modem

service-policy output Shape4SAT

policy-map Shape4Sat

class class-default

    shape average 200000

  service-policy TREAT_PROTOCOLS

Two notes, first I've also changed the name of your subordinate child policy as it does more than prioritize and second although I'm using the default parameter for 200 Kbps, we might need either reduce the overall shaping slightly for L2 overhead and/or adjust Tc (via 2nd parameter) although I believe your IOS will default to a Tc of 4 ms which should be fine.

policy-map TREAT_PROTOCOLS

class VOIP

    priority percent 35

class DOWNLOADERS

    fair-queue

    bandwidth remaining percent 1

class TORRENTS

   drop

class class-default

    fair-queue

    bandwidth remaining percent 99

class-map match-any VOIP

match protocol rtp

match ip dscp ef

match protocol skype

In the above, I've combined both your two VoIP traffic classes into one with up to 35% bandwidth.  You might need more, but if you do, doing VoIP across 200 Kbps is tough as a single G.911 uses about 100 Kbps.

Also working with such tight bandwidth for VoIP, you might need to reduce tx-ring on your outgoing Ethernet interface to its minimum, i.e. tx-ring-limit # (1 or 2?).

You might also need to reduce your packet sizes; again because of your VoIP on such a low bandwidth link.  (Normal recommendation is for LFI for bandwidths under 768 Kbps.)  On PPP links we could enable LFI, but as yours is Etherent, we can, sort of, emulate this by reducing MTU.

On your Satelitte facing Etherent interface, commands (similar to):

ip tcp adjust-mss 200

ip mtu 240

The above allows for 10 ms per packet.

jpvh12345 Sun, 04/15/2012 - 06:22

I will throw in 2 cents and say you probably need "qos pre-classify" on the link fAcing the satellite. This forces packet priority before encryption.

Sent from Cisco Technical Support iPad App

rcraig114 Sun, 04/15/2012 - 06:43

OK, so I understand everything. However, I can apply the "ip mtu 240", but when I try to apply "ip tcp adjust-mss 200", the lowest number I can choose is 500. Now, in regards to the incoming (or egress to the LAN), are you saying that it isn't really possible to control that because of the SAT provider? Also, I am going to add the "qos pre-classify" command. Hopefully that will clear up the audio going from sat site to state side CUCM. Comments have been kind of choppy/missed words for the audio received at the state side CUCM.

JosephDoherty Sun, 04/15/2012 - 15:40

Disclaimer

The   Author of this posting offers the information contained within this   posting without consideration and with the reader's understanding that   there's no implied or expressed suitability or fitness for any purpose.   Information provided is for informational purposes only and should not   be construed as rendering professional advice of any kind. Usage of  this  posting's information is solely at reader's own risk.

Liability Disclaimer

In   no event shall Author be liable for any damages whatsoever (including,   without limitation, damages for loss of use, data or profit) arising  out  of the use or inability to use the posting's information even if  Author  has been advised of the possibility of such damage.

Posting

Hmm, well then you could use 500 for adjust-mss and 540 for IP mtu.  This will permit bigger packets to delay your VoIP packets, but it might be the best you have to work with.

Yup, difficult to control inbound bandwidth utilization as it's after the link has already been congested.  Best you can hope for is to drop packets such that sender slows its transmission rate (although even then, sender will might lag a bit before it reduces its rate).  (NB: this is only effective against rate adaptive traffic, such as your FTP in downloaders.)

(Also note, your torrents class should be effective, in either directions, as it drops all such traffic.  I.e. sender and receiver won't be able to communicate.)

The way you tell your qos pre-classify is working or not is whether you're getting match stats on the different parts of your CBWFQ policy.

VoIP is going to be difficult both because of you low bandwidth, and if you cannot control QoS in both directions.

rcraig114 Sun, 04/15/2012 - 16:03

OK, so the original policy I had is good enough for the LAN interface? Also, do I apply the mtu and mss changes on the SAT interface or both?

rcraig114 Sun, 04/15/2012 - 18:35

I don't get it. Whenever I apply those commands, I break devices behind my router. Some laptops get out, some phones can't, or back and forth. If I take those commands out, everything is fine. Ironically, when I have those commands in, my VOIP across the VPN isn't choppy anymore.

JosephDoherty Mon, 04/16/2012 - 02:53

Disclaimer

The  Author of this posting offers the information contained within this  posting without consideration and with the reader's understanding that  there's no implied or expressed suitability or fitness for any purpose.  Information provided is for informational purposes only and should not  be construed as rendering professional advice of any kind. Usage of this  posting's information is solely at reader's own risk.

Liability Disclaimer

In  no event shall Author be liable for any damages whatsoever (including,  without limitation, damages for loss of use, data or profit) arising out  of the use or inability to use the posting's information even if Author  has been advised of the possibility of such damage.

Posting

No, it shouldn't be.  This because you want to police, not shape, to try to most effectively influence inbound bandwidth usage.

MTU and adjust-mss commands (should) need only be applied on SAT facing interface.  (I'll qualify that with the should until I better understand what exactly you're doing.)

The issue you're having with broken devices when you enable these commands might be MTU related.  Just as I wonder about what the QoS policy "sees" with regard to encrypted traffic, when you reduce your MTU hosts might not be informed that MTU has reduced.  Also, I haven't ever needed to use this approach with such little bandwidth and as you found you could not adjust lower then 500, there might also be a problem going lower than 576.

How do things work (or not) if you don't change MTU or use adjust-mss?

As another poster mentioned, normally p2p crypto is done as part of a GRE tunnel, you're not using one?  If you are, there's other methods to apply QoS.  Also, if doing GRE/IPSec you might switch to VTI tunnel (if supported on both sides).

If you do have a tunnel interface, there's a command to add to the tunnel interface to make it aware of MTU changes.  Also we would want to apply adjust-mss there (or if all in/out traffic is flowing through the LAN interface, especially if there's not LAN only traffic, we might apply the MTU and adjust-mss commands there).

I also notice your doing NAT.  If you're sharing Internet access for both the secured traffic and "raw" Internet traffic, the latter disrupts being able to effectively do QoS as then we often don't know what bandwidth we're working with.  (In other words, all traffic needs to be under QoS management - it's not generally effective to have some managed by QoS and some not on a shared interface/link.)  Also, if you have just your secured traffic, you shouldn't need NAT.

In your case, all traffic should be passing through your policy, as its on physical interfaces, but haven't received confirmation whether the policy "sees" shadow headers for your encrypted traffic.

Unfortunately, this might now appear to be getting complex, but that's the case when you start mixing QoS and NAT and encrypted traffic, without even concerning ourselves with the issue of working with only 200 Kbps.

rcraig114 Mon, 04/16/2012 - 04:21

My setup I would think could be worse but here is the scenario. 12 users behind router need internet access. Plain on internet, nothing more. However, a few of them either have a phone or use the CIPC and I extend services from my CUCM in Arizona over to them. What I mean by extend is the ability to make outgoing calls to family. My CME locally handles registrations and stuff, but I send the outgoing calls across an H323 trunk across that VPN. Now, I have been advised several ways of doing this VPN (VTI, EZVPN, the current method). My entire goal of the MTU change is to get rid of the choppy audio the state side caller hears from me. When I put those commands on the SAT interface last night, the audio wasn't choppy anymore, but again, it broke half the machines. So, I'm trying to solve the choppy outgoing audio, but keep the internet users happy. I am using G729, but can't figure out why the outgoing audio is choppy. Now, you are correct, there are two interfaces, one for the SAT traffic and one for the LAN traffic (actually subinterface). So, maybe apply ip mtu and adjust commands on both?

JosephDoherty Tue, 04/17/2012 - 02:38

Disclaimer

The   Author of this posting offers the information contained within this   posting without consideration and with the reader's understanding that   there's no implied or expressed suitability or fitness for any purpose.   Information provided is for informational purposes only and should not   be construed as rendering professional advice of any kind. Usage of  this  posting's information is solely at reader's own risk.

Liability Disclaimer

In   no event shall Author be liable for any damages whatsoever (including,   without limitation, damages for loss of use, data or profit) arising  out  of the use or inability to use the posting's information even if  Author  has been advised of the possibility of such damage.

Posting

VoIP will be choppy if the VoIP doesn't packets don't get the timings they desire.  Normally other non-VoIP traffic will be adverse to VoIP.  The likely reason it works when other traffic is broken is because then the other traffic isn't concurrently using the link as then by not being present it's not adverse to your VoIP.  With QoS we're trying to protect VoIP while allowing the other concurrent VoIP traffic.

Normally we apply MTU changes to just the restricted bandwidth interface, i.e. the interface with low available bandwidth that your VoIP must cross, but it should work (more or less) anywhere along the path.  So, applying to internal LAN interface, alone or also on SAT interface, should be fine too.  (Again, we would normally avoid doing this in the LAN interface incase it was also used for any other traffic not going to/from Satellite.  Also shouldn't need it on both interfaces.)

I've been thinking more about this, and we might not need to reduce your MTU at all.  The reason this is done on links with less than 768 Kbps, is because serialization delay of larger packets is adverse to VoIP.  However, in your case, we're shaping to 200 Kbps and serialization is at port speed.

If you're using a VTI tunnel, I wouldn't expect to see cypto-map statements on the physical interface.  It might be helpful if you posted more of your config.

rcraig114 Tue, 04/17/2012 - 09:23

OK, I am not currently using a VTI for my IPSEC tunnel. I think I will try doing it. I am thinking that if I have the tunnel up using a VTI, I can apply the ip mtu and mss-adjust commands on that interface. After all, those commands cleaned up VOIP going across that tunnel. Or, I could see how it goes without adjusting mtu on it. Regardless, I think VTI is the way forward in regards to my IPSEC tunnel. I just pinged my provider to see what he reccommended for mtu for routers connecting to iDirect modems. I don't have access to my router remotely right now, but at the end of my shift I will post a copy of my config.

rcraig114 Sun, 04/15/2012 - 06:48

Ironically, the "qos pre-classify" command is not available. Huhh?

Update:  Nevermind, that is available in my crypto map and it is already there.

jpvh12345 Sun, 04/15/2012 - 06:52

Sorry about that. I've used that on gre tunnels within IPSec, but not on an IPSec tunnel by itself. I have an order of operations link somewhere I will look at.

Sent from Cisco Technical Support iPad App

jpvh12345 Sun, 04/15/2012 - 06:58

Assuming fa0/1 is pointed towards your internal LAN, there's no reason to prioritize that traffic. Your sat won't be able to overrun that interface because the bottleneck is fa0/0.

You could do service policy input on the internal interface if you wanted to drop torrents "earlier" in the traffic flow.

Sent from Cisco Technical Support iPad App

rcraig114 Sun, 04/15/2012 - 07:02

OK, I was hoping to slow down downloads as far as incoming. The way I look at it, the downloads will consume as much bandwidth as possible because the policy I just implemented only applied for upload traffic. Or am I looking at this wrong?

jpvh12345 Sun, 04/15/2012 - 07:13

Check out the diagram on this page for an order of operations review.

http://etherealmind.com/cisco-ios-order-of-operation/

Sent from Cisco Technical Support iPad App

rcraig114 Sun, 04/15/2012 - 07:31

OK, so it looks like unless the QOS takes place in the ingress of the LAN interface, the VOIP traffic destined for the VPN tunnel won't get the correct priority because it's already encrypted by the time it is inspected for QOS.

Actions

Login or Register to take actions

This Discussion

Posted April 14, 2012 at 1:18 PM
Stats:
Replies:18 Avg. Rating:
Views:723 Votes:0
Shares:0
Tags: No tags.

Discussions Leaderboard