Yes, that is correct.
*Vasu Dasari*
On Wed, Mar 9, 2022 at 5:06 PM Ashish Varma
wrote:
> Thanks for the reply Vasu.
>
> So to clarify, if the rule gets hit, the action would send the packet out
> of port number 1 (since reg0 holds the value 1)?
>
> On Wed, Mar 9, 2022 at 10
*Vasu Dasari*
On Tue, Mar 8, 2022 at 4:58 PM Ashish Varma
wrote:
> I am trying to find the meaning of the following statement in the
> ovs-actions man page:
>
> "Output to a register is an OpenFlow extension introduced in Open vSwitch
> 1.3."
>
> Does this mea
OpenFlow 1.2 and later do not, so Open vSwitch
translates them to appropriate *OFPAT_SET_FIELD *actions for those
versions.
-----
*Vasu Dasari*
On Mon, Jul 12, 2021 at 3:13 AM LIU Yulong wrote:
> Hi there,
>
> Recently, I tested OpenStack Neutron with DSCP marking f
Oops. Sorry about copy/paste.
Thanks for your comments. Will respond over the ovs-dev thread.
*Vasu Dasari*
On Mon, May 10, 2021 at 2:58 PM Ben Pfaff wrote:
> On Sat, May 08, 2021 at 01:56:05PM -0400, Vasu Dasari wrote:
> > I created a patch for supporting flow monitoring on any
com/>
Thanks
-Vasu
*Vasu Dasari*
On Tue, Dec 8, 2020 at 8:39 PM Vasu Dasari wrote:
> Sure Ben. I will be on it.
>
> Meanwhile, not to hijack this thread, can you please comment on my other
> question, [ovs-discuss] MAC Learning event to Controller
> <https://mail.openv
Ok. I agree.
On Wed, Dec 9, 2020 at 12:35 PM Ben Pfaff wrote:
> I respect the desire for symmetry, but it might not justify the effort
> of adding the new feature.
>
> On Wed, Dec 09, 2020 at 11:52:32AM -0500, Vasu Dasari wrote:
> > There is no reason for duplication, oth
There is no reason for duplication, other than the reason for symmetricity
of APIs, "send_flow_rem"(which already exists) and "send_flow_add"(could be
added).
-Vasu
*Vasu Dasari*
On Wed, Dec 9, 2020 at 11:41 AM Ben Pfaff wrote:
> On Wed, Dec 09, 2020 at 10:37:42AM -
which tells the
controller when a flow is added. Maybe this could be an enhancement to
"learn" action. What do you think?
Thanks
-Vasu
*Vasu Dasari*
On Tue, Dec 8, 2020 at 11:29 PM Ben Pfaff wrote:
> On Sun, Dec 06, 2020 at 08:22:43AM -0500, Vasu Dasari wrote:
> > Hi,
> >
could achieve MAC
learning event propagation to controllers. If you have any other thoughts
please let me know.
Thanks
-Vasu
<https://mail.openvswitch.org/pipermail/ovs-discuss/2020-December/050819.html>
*Vasu Dasari*
On Tue, Dec 8, 2020 at 12:01 AM Ben Pfaff wrote:
> On Mon, Dec 07
support negotiated
OpenFlow versions(whatever version it may be)? If no one is working on
this, I do not mind taking this up.
Please advise.
Thanks
-Vasu
*Vasu Dasari*
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman
ning entry) into table 10.
My application requires that the controller should be notified of new MAC
entry when it is being learnt. In summary when a new flow is added to table
10, (not modified) the controller should be notified of the event.
Can someone please help me how to achieve this
Thank you Ben. I should have gone through the definition.
Vasu
> On Jun 26, 2020, at 7:52 PM, Ben Pfaff wrote:
>
> On Fri, Jun 26, 2020 at 06:10:09PM -0400, Vasu Dasari wrote:
>> Hi,
>>
>> I am seeing a strange error. Can someone see if this ia bug or I am usin
"},\"table\":\"Interface\",\"uuid-name\":\"133f0e9e60105b9d8f8c15797107f29c\"}"}]
root@ovs1:~#
The only difference in above commands is the uuid-name string.
a33f0e9e60105b9d8f8c15797107f29c. << Successful one
133f0e9e60105b9d8f8c15797107f29c
Thanks Ben. Should have noticed that.
*Vasu Dasari*
On Thu, Jun 11, 2020 at 6:01 PM Ben Pfaff wrote:
> On Thu, Jun 11, 2020 at 05:27:01PM -0400, Vasu Dasari wrote:
> > 19665ac0-ba46-4bcf-83b6-ce5b93c23987
> > Manager "tcp:172.26.0.2:6653"
> > Bridge &q
Interface "br0"
type: internal
ovs_version: "2.9.7"
Thanks
-Vasu
*Vasu Dasari*
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
I think author of example you referred to in userspace-tunnel.rst tried to
show a scenario where underlay and overlay networks are separated on two
different bridges. OVS does not need to have two separate bridges for
userspace-tunnel to work.
*Vasu Dasari*
On Wed, Jul 17, 2019 at 5:05 AM
ot;$ovs_base/cleanup"
+}
+
# With no parameter or an empty parameter, sets the OVS_*DIR
# environment variables to point to $ovs_base, the base directory in
# which the test is running.
If you think that this would be helpful I can raise a patch with this
change.
-Vasu
*Vasu Dasari*
On Fri,
is. So probably I might
be missing some steps here.
Port "p2-0"
Interface "p2-0"
error: "could not open network device p2-0 (No such device)"
Thanks
-Vasu
*Vasu Dasari*
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
Flavio, Submitted patch link
<https://mail.openvswitch.org/pipermail/ovs-dev/2019-June/359914.html>.
Regarding, fdb/set, thanks for your inputs, will think more about that.
Probably initiate a separate email thread later.
-Vasu
*Vasu Dasari*
On Wed, Jun 19, 2019 at 9:53 AM Flavio L
Thank you Aaron. Your suggestion did the trick. Now the testcase passes too.
*Vasu Dasari*
On Wed, Jun 19, 2019 at 11:10 AM Aaron Conole wrote:
> Vasu Dasari writes:
>
> > Hi,
> >
> > The following test case is not successful on a Ubuntu 18.04 based VM.
> >
&g
On Tue, Jun 18, 2019 at 12:21 PM Flavio Leitner wrote:
> On Tue, Jun 18, 2019 at 10:41:16AM -0400, Vasu Dasari wrote:
> > Flavio,
> >
> > The device(could be a regular interface) should have been added to OVS
> with
> > "add-port" and when it is r
rformed to check ARP entry
existence, like for example, "tunnel_push_pop - underlay bridge match" in
tunnel-push-pop.at. I hope that is fine, or should I be writing a separate
unit test case?
-Vasu
*Vasu Dasari*
On Fri, Jun 14, 2019 at 9:15 AM Flavio Leitner wrote:
> On Thu, Jun
xlate_xbridge_remove() is a right place to do the job.
What do you think?
-Vasu
On Thu, Jun 13, 2019 at 7:27 PM Vasu Dasari wrote:
> Yes Flavio. Looking at code to fix this. Will send fix for review soon.
>
> Vasu
>
> > On Jun 13, 2019, at 7:15 PM, Flavio Leitner wrote:
>
Yes Flavio. Looking at code to fix this. Will send fix for review soon.
Vasu
> On Jun 13, 2019, at 7:15 PM, Flavio Leitner wrote:
>
>> On Wed, Jun 12, 2019 at 07:18:27PM -0400, Vasu Dasari wrote:
>> Thanks Ben. Meanwhile I think I found an bug in OVS 2.9.0 with stale ARP
uot;
ip addr add 1.1.1.1/24 dev s1
ip link set s1 up
ip addr flush dev eth1 2>/dev/null
ip link set eth1 up
ovs-appctl tnl/arp/set s1 1.1.1.2 00:00:01:00:00:02
*Vasu Dasari*
On Tue, Jun 11, 2019 at 6:22 PM Ben Pfaff wrote:
> On Tue, Jun 11, 2019 at 03:17:24PM -0400, Vasu Dasari wrote:
if the switch were
to use userspace datapath? Or what I am seeing is a bug?
If I do the same configuration on kernel datapath mode(everything except
the step which changes bridge datapath type), I see VxLAN packets on
s1-eth3.
Thanks
*Vasu Dasari*
___
d
Sure Ben. Let me see what I can do.
-Vasu
*Vasu Dasari*
On Tue, Jun 4, 2019 at 2:02 PM Ben Pfaff wrote:
> One could add support to OVS for this model of VXLAN and other
> protocols. I do not see how tun_metadataXX is relevant to VXLAN,
> because it does not have Geneve- or NSH
Ben,
Do you think, is there a way I can use "tun_metadataXX" infrastructure with
"push" and "pop" actions to achieve adding and remove headers? Or these
operations are quite centric to ash/geneveve, etc??
-Vasu
*Vasu Dasari*
On Tue, Jun 4, 2019 at 1:13 PM Ben P
d:5->tun_id, \
set_field:1.1.1.1->tun_src, \
set_field:2.2.2.2->tun_dst, \
output:1 \
"
Can someone please help me with this?
Thanks
-Vasu
*Vasu Dasari*
___
discuss mailing list
disc...@openvswitch.org
https://mai
Thanks for the clarification.
*Vasu Dasari*
On Thu, May 23, 2019 at 11:39 PM Ben Pfaff wrote:
> On Thu, May 23, 2019 at 10:46:40PM -0400, Vasu Dasari wrote:
> > Thanks for digging into this. My comments inline. I am sorry that I had
> to
> > differ from your analysis.
>
Thanks for digging into this. My comments inline. I am sorry that I had to
differ from your analysis.
*Vasu Dasari*
On Thu, May 23, 2019 at 5:54 PM Ben Pfaff wrote:
> On Thu, May 23, 2019 at 04:37:41PM -0400, Vasu Dasari wrote:
> > There are two "flags" fields in tcpd
cations. And these are 2nd two bytes in row 0050.
Can you tell which bytes do you think are representing "flags" field in
above bytes output?
You can open the pcap file in Wireshark to see my analysis.
Also, is there a specification for nicera extensions? Can you please point
it to me?
-V
nd: 8,
match_and_padding
The place where the flags is being extracted
ofputil_decode_flow_monitor_request(),
I see that flags is extracted first. This could be an issue.
I have't tried out my assumption yet. Does it make sense??
Could this be a software bug?
Thanks,
-Vasu
*Vasu Da
ff ff ff ff 00 01
0060 00 00 00 01 00 04 00 00 00 00..
Also attaching pcap file.
Thanks
-Vasu
*Vasu Dasari*
On Wed, May 22, 2019 at 12:45 PM Ben Pfaff wrote:
> On Wed, May 22, 2019 at 10:31:13AM -0400, Vasu Dasari wrote:
> > Hi,
> >
y (xid=0x0):
event=DELETED reason=delete table=1 cookie=0xa in_port="s1-eth1"
actions=resubmit(,2)
Thanks
-Vasu
*Vasu Dasari*
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
35 matches
Mail list logo
