Hi Purnendu, Thank you for the response.
I d like to apologize for the mistake that I made in the diagram. I mixed up the ip addresses in my init diagram. The configuration actually is: 10.0.0.1(SOURCE) ---- 10.0.0.3(OVS) ------- 10.0.0.2(SINK) @10.0.0.1 ip route 10.0.0.2 gw 10.0.0.3 @10.0.0.3 ip_forwarding=on 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= On Apr 1, 2017 23:05, "Purnendu" <[email protected]> wrote: Hi Advith,Darrel, With SR-IOV configured the packet flow among the VMs would traverse through the PHY. I put a diagram. BR, Purnendu On Sat, Apr 1, 2017 at 1:38 PM, Advith Nagappa <[email protected]> wrote: > 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/maste >> r/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 >> >> > > _______________________________________________ > discuss mailing list > [email protected] > https://mail.openvswitch.org/mailman/listinfo/ovs-discuss > > -- with regards, Purnendu Ghosh
Topo (1)
Description: Binary data
_______________________________________________ discuss mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
