[ovs-discuss] Test OVS kernel module using only one machine
Ahmed Talha Khan
auny87 at gmail.com
Tue Dec 18 14:19:49 UTC 2012
I am not aware of the internal port functionality. Can you kindly elaborate
your answer a bit more. Also what do you mean by "add IP configuration on
your bridge port"? How will that help in sending traffic in?
On Tue, Dec 18, 2012 at 7:14 PM, Kyle Mestery (kmestery) <kmestery at cisco.com
> On Dec 18, 2012, at 7:58 AM, Ahmed Talha Khan <auny87 at gmail.com> wrote:
> > Hey Ben,Jesse,Kyle,ALL,
> > I made some changes in the kernel module and would like to test them.
> Ideally I would want to test it on a single machine that i am on without
> firing up other vms(eg kvm/qemu integration). I would like to know what is
> the preferred method used by the community for this.
> > I thought of using a combination of tcpreplay and TAP devices to achieve
> this. I only want send traffic into ovs-port 1, receive it in the kernel
> mod, and send it out to ovs-port 2 after doing my processing. Since I was
> trying to use tcpreplay,which is an out-bound utility(sends traffic out of
> the stack), I need to make some interface on which i replay this traffic. I
> made a TAP interface for this, since that can be used to inject packets
> into the network stack. The problem is that when i replay the traffic on
> this TAP device it is not received inside OVS obviously because the TAP
> device only sends up the traffic to kernel but ovs will not receive it
> since it is not coming form any OVS port.
> > Then there is a way to make 2 TAP devices, bridge them, play traffic on
> one of them and add the 2nd one to ovs. But that is not possible since OVS
> and linux bridge module cannot co-exist.
> > So the questions is how to input traffic into ports, in a
> non-programmatic way, without external vms.
> > Also, are there any tests in the /test directory to test the datapath
> functionality independent of the userland ovs code?
> I usually just use OVS internal ports for this. Either add IP
> configuration on your bridge port itself, or just create another internal
> port and use that for your tests.
> > --
> > Regards,
> > -Ahmed Talha Khan
> > _______________________________________________
> > discuss mailing list
> > discuss at openvswitch.org
> > http://openvswitch.org/mailman/listinfo/discuss
-Ahmed Talha Khan
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the discuss