The former. If you want to control the rate going into the switch from the VM,
you'd need to use a policer.
--Justin
On Jul 2, 2012, at 11:35 PM, selen jia wrote:
> Hi Justin,
>
> Is that mean to verify HTB and HFSC on VM interfaces , I have to create
> queues on VM interface with particul
Hi Justin,
Is that mean to verify HTB and HFSC on VM interfaces , I have to create
queues on VM interface with particular bandwidth/rate and have to send
traffic from switch to VM and then check rate .
this is ingress to VM, right?
OR
after creating queue on VM , I will send traffic from VM and w
On Jul 2, 2012, at 10:30 PM, selen jia wrote:
> It means HTB, HFSC and policing all would work on VM interfaces ?
Yes, they should. We just leverage the tc's mechanisms in the kernel.
> Is this implementation opposite to policing because policing act as ingress
> for switch perspective and eg
Thanks Justin!
It means HTB, HFSC and policing all would work on VM interfaces ?
Is this implementation opposite to policing because policing act as ingress
for switch perspective and egress for VM interface?
Regards,
Selen
On Tue, Jul 3, 2012 at 10:50 AM, Justin Pettit wrote:
> Yes. They're
Yes. They're on egress from the switch's perspective, though, which means
they're ingress into the VM (and egress onto the wire).
--Justin
On Jul 2, 2012, at 10:16 PM, selen jia wrote:
> Hi,
>
> Are HTB and HFSC queueing disciplines supported on OVS virtual port (VM
> interfaces) also?
>
Hi,
Are HTB and HFSC queueing disciplines supported on OVS virtual port (VM
interfaces) also?
regards,
Selen
___
discuss mailing list
discuss@openvswitch.org
http://openvswitch.org/mailman/listinfo/discuss
OpenFlow uses the OFPT_HELLO message in the first message exchange of a
given OpenFlow session to negotiate a particular version, and after that
every message on the channel should use that version. Any controller
that depends on other behavior is buggy.
Nevertheless, I don't have a particular re
Hi Ben,
My intention is just if any different version is coming on switch then
it should have handle capability (as per openflow spec 1.0 also) .
I think the version in switch's "error" packet should be the one which
switch is using so that other (controller) would come to know the
right version.
Hi Ben,
Thanks for the quick response.
But really sorry that I didn't get you fully.
Is that mean this default behavior works for any switch except OVS or if my
understanding is wrong then please clarify how I can check the default
behavior of access port in OVS.
1. For me " Bridge should
It seemed reasonable to send the error with the same version as the
request. I can't see how it really matters since no controller should
send a request with the wrong version anyway. So, why does it matter
to you?
On Fri, Jun 29, 2012 at 11:45:17PM +0530, sonny sonny wrote:
> hi ,
> Please help
On Fri, Jun 29, 2012 at 04:18:26PM +0200, Hans van Kranenburg wrote:
> On 06/29/2012 04:06 PM, Hans van Kranenburg wrote:
> >Package: xen-hypervisor-4.0-amd64
> >Version: 4.0.1-5.2
>
> Whoops, accidentally mailed ovs-discuss again, when submitting the
> issue to debian, please ignore, sorry.
>
>
On Mon, Jul 02, 2012 at 01:32:55PM +0530, edward wilson wrote:
> I need to understand access port functionality in OVS and matching with
> flow entry created on switch
> As mentioned in man-page :-
>
> "Any packet with an 802.1Q header that ingresses on an access port is
> dropped, regardless of w
> Now I'm going through it. I've compiled and installed the latest
> stable kernel, 3.4.4, with no success. I'm
> getting the same behaviour (response frames having it's VLAN tag stripped).
I forgot to mention that I've compiled and installed the 3.4.4 kernel
on the VM, the CentOS 6.2 one.
Regard
Hi Ben:
>> I'm trying to setup a trunk port to send VLAN's tagged frames from
>> OVS to a VM, so inside the VM I gonna use
>> VLAN Linux support (8021q kernel module along with vconfig tool).
>
> Did you read the FAQ? It has an extensive section about VLANs:
> http://openvswitch.org/faq/
Hi,
I need to understand access port functionality in OVS and matching with
flow entry created on switch
As mentioned in man-page :-
"Any packet with an 802.1Q header that ingresses on an access port is
dropped, regardless of whether the VLAN ID in the header is the access
port’s VLAN ID."
But
15 matches
Mail list logo
