WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-users

RE: [Xen-users] Xen & TC & Asterisk

       I?m late to this thread, as I don?t know enough about it to be more
than dangerous, but I have two questions:
1) If tc is set up on the Xen bridge, shouldn?t all traffic be outbound on
it after entering the same way bridging two interfaces would be, or does it
have to be outbound on a physical interface (and if so, wouldn?t outbound on
vif0.0 be toward the physical network the same way outbound on eth0 would?)
2) What good is outbound tc going to do if the inbound interface is getting
clogged up?  I mean, if the destination is the domU for the high priority
traffic as mentioned earlier, then other equipment on the network can be
flooding the physical interface on the dom0 host before the virtual bridge
drops the traffic.  I guess this probably doesn't matter unless you have
malicious activity or a misbehaving app, though, as the dropped traffic
should still cause the data flow to slow down, allowing the high priority
traffic through.
        Question one may have already been considered and/or tested by
someone else, and question two may be moot, but I thought I'd throw my 2¢
out there.
        Dustin

From: xen-users-bounces@xxxxxxxxxxxxxxxxxxx
[mailto:xen-users-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of drew einhorn
Sent: Thursday, August 21, 2008 21:45
To: xen-users@xxxxxxxxxxxxxxxxxxx
Subject: Re: [Xen-users] Xen & TC & Asterisk


On Thu, Aug 21, 2008 at 9:27 AM, drew einhorn <drew.einhorn@xxxxxxxxx>
wrote:
If you set up a vm with two ethernet ports, and 
bridge the traffic between them, 
the inbound traffic on one, is the outbound traffic on the other.  
Shape the outbound traffic on both ports.


Ooops, thought I sent this reply to the list

And I've looking a little closer at xen networking.
Looks like you may not have to set up another vm to handle the shaping and
get it inserted into your virtual network in the right place to make it
work.

I think if you can do it all on dom0 shaping outbound traffic on both eth0
and vif0.0
Will require some experiments to verify that this approach works as
expected.

I've got other fish to fry first.  (putting some iptables rules on these
interfaces, to isolate a couple dhcp servers).  Traffic shaping is a ways
down on my priority list.

 

On Thu, Aug 21, 2008 at 8:49 AM, --[ UxBoD ]-- <uxbod@xxxxxxxxxxxx> wrote:
Hmmmm ... Looks like it is not quite correct then.  What I am after is the
ability to control both inbound and outbound VoIP traffic so it has
priority.  Any advice please ?

Regards,

--
--[ UxBoD ]--
// PGP Key: "curl -s http://www.splatnix.net/uxbod.asc | gpg --import"
// Fingerprint: F57A 0CBD DD19 79E9 1FCC A612 CB36 D89D 2C5A 3A84
// Keyserver: www.keyserver.net Key-ID: 0x2C5A3A84
// Phone: +44 845 869 2749 SIP Phone: uxbod@xxxxxxxxxxxxxxxx
----- "Anna Fischer" <anna.fischer@xxxxxx> wrote:

> Note that the qdisc configuration you have posted regulates *outbound*
> traffic going onto the network. Is that what you want, because you
> talk about DomU being the destination? In general it is correct to
> attach qdiscs to peth0 for traffic to/from the network and eth0 only
> specific for Dom0 rate controlling.
>
>
>
> _______________________________________________
>
> Xen-users mailing list
>
> Xen-users@xxxxxxxxxxxxxxxxxxx
>
> http://lists.xensource.com/xen-users
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.


_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-users



-- 
Drew Einhorn



-- 
Drew Einhorn



_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-users

<Prev in Thread] Current Thread [Next in Thread>