[c-nsp] QoS on ingress
Ben Steele
ben at bensteele.org
Fri Sep 10 15:03:16 EDT 2010
There isn't much you can do here if your provider isn't willing to play
ball.
What I would suggest is policing your ingress for all but your voip traffic
to about 10% less than your maximum throughput, assuming the majority of
your user traffic is tcp this should give you enough overhead for a voip
stream or 2 depending on your codec.
The last thing you want to do is try and run the T1 to capacity as you are
at the peril of your providers egress policy whether that be policing,
shaping or just tail drop, either one you don't want for your voip traffic.
On Fri, Sep 10, 2010 at 7:44 PM, Jay Nakamura <zeusdadog at gmail.com> wrote:
> I can't seem to figure out what to do with my situation, wondering if
> anyone had encountered this.
>
> Situation :
> Router : 1841 IOS 12.4T or 15.0M
> Internet T1, two eth Interfaces
> There are VoIP traffic (SIP & RTP) and general internet traffic
>
> VoIP provider does not tag SIP/RTP with any kind of QoS in IP header.
> (DSCP/IPP) Internet provider can do QoS based on IPP but since VoIP
> traffic is not marked, it's not useful.
>
> Problem to solve : how to not drop >ingress< VoIP traffic when
> internet traffic is high as much as possible without capping the
> non-VoIP traffic to less than T1 bandwidth.
>
> Caveat : I understand that since it's not getting policed at the
> egress from the provider, any solution is not going to be perfect
>
> I can't limit the traffic on the Eth interface egress because traffic
> can go to either eth interface.
>
> Any thoughts?
> _______________________________________________
> 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