I have attached a sketch of the topology. I send 14 packets from Source(10.0.0.1), I receive 14 at Sink.(10.0.0.2)
I also see 14 packets hitting the rule at OVS(drop rule at 10.0.0.3) cookie=0x0, duration=123.175s, table=0, *n_packets=14*, n_bytes=60, idle_age=2, priority=1111*,udp,nw_src=10.0.0.1,nw_dst=10.0.0.2* *actions=drop* And I can say with confidence that there are no other UDP packets in the system. On Fri, Mar 31, 2017 at 10:45 PM, Darrell Ball <[email protected]> wrote: > > > > > *From: *Advith Nagappa <[email protected]> > *Date: *Friday, March 31, 2017 at 1:14 PM > *To: *Darrell Ball <[email protected]> > *Cc: *discuss <[email protected]> > *Subject: *Re: [ovs-discuss] SR-IOV with Open vSwitch > > > > Darrell, > > > > Thank you for the resources and the response. > > > > I am not using a Linux bridge at host. Just SR-IOV to pass through the > hypervisor. > > > > My guess here is that the although the three guests are assigned one > virtual functions(VF) each, since all three VFs are sliced out of the same > underlying Physical function (and this they are.), the rules at the OVS are > somehow overridden. I don't know if this guess is anywhere close to being > accurate.. > > > > The overriding hypothesis seems unlikely, at least by what I understand by > the term. > > It would be helpful to have a diagram of packet sourcing and sinking; i.e. > where are the packets sent from and > > where is the counting of the received ones - “but the packet is not > dropped:” > > > > Also, are the “received packets” the UDP packets you are tracking or some > other ones. > > > > > > > > On Mar 31, 2017 01:16, "Darrell Ball" <[email protected]> wrote: > > > > > > *From: *<[email protected]> on behalf of Advith Nagappa > <[email protected]> > *Date: *Wednesday, March 29, 2017 at 9:39 PM > *To: *discuss <[email protected]> > *Subject: *[ovs-discuss] SR-IOV with Open vSwitch > > > > Hello All, > > > > > > Has anyone used SR-IOV with Open vSwitch(in a guest)? > > > > My understanding is that SR-IOV is hypervisor(host) by/pass, Hence using > OVS at that level would not make sense.. > > > > So I tried deploying OVS in an SR-IOV enabled guest, and here is what I > observed.. > > > > I have one virtual function within my guest, called ens7. > > > > I have added that to by OVS-bridge.. > > > > > > > > d5f266fc-a6f1-448e-91c5-e6db8748f73f > > Bridge "br0" > > Port "*ens7*" > > Interface "ens7" > > Port "br0" > > Interface "br0" > > type: internal > > > > I also, added the following rule: > > > > ovs-ofctl add-flow br0 priority=1111,dl_type=0x0800*,nw_proto=17* > ,nw_src=10.0.0.1,nw_dst=10.0.0.2,actions= > > > > > > However every time I send a UDP datagram, I see that this rule is hit!, > but the packet is not dropped: > > > > cookie=0x0, duration=123.175s, table=0, *n_packets=14*, n_bytes=60, > idle_age=2, priority=1111*,udp,nw_src=10.0.0.1,nw_dst=10.0.0.2* > *actions=drop* > > > > The thing here is 10.0.0.1 and 10.0.0.2 share a physical function,.. and, > despite the rule hit, the datagram is forwarded, I wonder what may be > causing this? I am guessing some kind of L2 switching at the NIC level, > which overrides OVS? Does anyone have an experience with this.. > > > > > > You are running OVS in the VM(s), not the host. > > I assume you are sending packets in one direction only and are constantly > hitting an L2 broadcast case in the Linux bridge in the host > > (this is also an assumption, since you don’t delineate all your config. > and topology). > > So, I guess one copy of the packet is bypassing OVS in the VM and another > copy is sent to OVS in the VM to be dropped. > > > > Below link has more information and child links from there. > > > > https://github.com/intel/SDN-NFV-Hands-on-Samples/blob/ > master/SR-IOV_DPDK_Hands-on_Lab/docs/SR-IOV-HandsOn-IEEE.pdf > <https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_intel_SDN-2DNFV-2DHands-2Don-2DSamples_blob_master_SR-2DIOV-5FDPDK-5FHands-2Don-5FLab_docs_SR-2DIOV-2DHandsOn-2DIEEE.pdf&d=DwMFaQ&c=uilaK90D4TOVoH58JNXRgQ&r=BVhFA09CGX7JQ5Ih-uZnsw&m=YxFaqFip6Yx8m_S1rRQJOt69mM8X50oOAA7F1TpEwNc&s=utBGEpRDhujM_F5GBaXHebC6S9K9UA0kf-o18GeeV8M&e=> > > > > > > > > Best Regards > > Advith Nagappa > >
Topology.pdf
Description: Adobe PDF document
_______________________________________________ discuss mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
