I can create a bridge on the OVS through ODL and ovsdb, but OpenFlow switch is not same as OVS, so I got a problem. When I send the configure through POSTMAN, I just get an echo packet with Wireshark. Does anybody know how to deal with this problem? My ODL version is Lithium sr2.
Which OpenFlow switch are you using? Does it support OVSDB? The switch needs to support some configuration protocol (OVSDB or NetConf) in order to configure bridges on the switch. As OpenFlow is used to program flows on the switches, we cannot create bridges using OpenFlow protocol.
Related
I have captured network traffic on a router and I wanted to replay these packets on an OpenFlow simulator to understand flows behaviors. Is there any simulators/tools that will help me to achieve this?.
You can use mininet. It can create virtual openflow switches. construct virtual topologies. so you can simulate your tasks there.
I'm playing with ovs-dpdk package https://github.com/01org/dpdk-ovs and one thing I don't clearly understand is how can I have OVS bridge and VMs connected to it get access to outside, ie. to the network. On a regular openvswitch the bridge device created by vswitch is 'visible' from linux and can be configured by regular tools (ifconfig, ethtool etc.), so I could create TAP interface and add it to vswitch bridge interface and assign the bridge interface IP address. However with ovs-dpdk this is not the case: any bridge created with ovs-vsctl is not avaialble in userspace linux, at least I don't see it with ifconfig or "ip link show".
Is there another method OVS-DPDK does this? Hopefully someone can shed some light for this problem. Thanks.
ovs-dpdk when it is using DPDK to access the NIC will take over the nic and not allow regular kernel drivers to do their thing.
This means that you will not see the interface any more from the linux host if you bind the hardware with the dpdk io driver. But you can bridge/tap/mirror inside ovs these raw dpdk interfaces in dpdk-ovs to your vm's or to another interface which is visible to the kernel's regular drivers. You just can't do it on the dpdk owned interfaces.
The whole point of integrating dpdk into ovs is to bypass all the kernel drivers and get packets to/from the vswitch as fast as possible so it can route them natively through to your VM's and other local interfaces as you set in your bridge configuration.
I want to know is the OpenFlow implementation dependent on the platform or the CPU architecture? In other words can we run the same OpenFlow package on the windows and Linux? I saw that we can download the OpenFlow package and install it on the Linux but I want to know can I install that package on the windows platform too?
Your question: "Can we run OpenFlow on both Windows and Linux?"
Is the same as asking: "Can we run HTTP on both Windows and Linux?"
And the simple asnwer is: "Yes you can"
OpenFlow is the specification of an device-to-controller communication protocol used in the SDN paradigm. OpenFlow is one example of a "South-bound" protocol between an SDN Controller, and an OpenFlow enabled network device.
So, when you ask if you can install the OpenFlow package on a windows platform, it depends. It depends on the implementation of the SDN controller. The SDN controller will probably have a south bound module which implements OpenFlow so that you can communicate with OpenFlow enabled devices. This south bound module with OpenFlow support is what you are asking for.
So, if the "OpenFlow package" you found were for Linux, you probably couldn't install that on windows.
That being said. There are several SDN controllers with OpenFlow support that can run on Windows. Including the massive, and highly functional, OpenDaylight controller. OpenDaylight is implemented in Java, and can therefore run on both Linux, Windows, OS X etc..
Once you let another server(here we call it controller) to determine the packet forwarding behavior of your local machine (here it is your PC), it turns into so-called SDN mechanism. So it's not relevant what kind of CPU or hardware you are choosing, basically, you can consider SDN as a software solution.
However, it does not mean it has no any dependence on the platform, especially when we talk about windows. The problem is that when you delegate the forwarding behavior to the controller, do you have the privilege to do this? Basically it means it needs to program on the kernel level which you cannot obtain in windows platform.
So please forget to do this on Windows unless the Richmond company implements this by themselves.
We are using Twin Oaks DDS for windows. Can anyone help me in understanding how to use twin oaks DDS for iOS app to communicate with a non-iOS device??
Thanks,
Ravi Kumar
In general there are no special requirements for using CoreDX DDS from Twin Oaks to communicate between an iOS device and a non-iOS device. CoreDX DDS (as with most other DDS implementations) provides for platform independence.
You will need to link in the CoreDX DDS library (specific for the target hardware) into your iOS app, and use the DDS programming API to create publishers and/or subscribers as desired - just like on any other run-time platform.
The default transport mechanism of CoreDX DDS [the Real-Time Publish Subscribe (RTPS) protocol -- a combination of UDP unicast and multicast] is designed to support typical LAN environments, and will work well over WiFi. If you intend to communicate over cellular networks, be aware that the carrier may be using NAT or Firewall configurations that conflict with the standard UDP transport. In this case, you may consider using the TCP based transport.
I am creating an iPad app, which has to communicate with a WiFi enable device using TCP/IP protocol. I have the API sets of the device for communication. Now what i want is i would like to see whether the device is responding to the requests send via TCP/IP. Please suggest a good tool for MAC OS, where i can simulate the WiFi communication and get the response messages from the device.
Thanking you guys in advance
I have just started to use MAC OSX recently and I also have the same question as yours.
Luckily I have found a good tool that you can try:
https://packetsender.com/
It's multiplatform, support both TCP and UDP client/server.
If I get your question you may use telnet. With telnet you can establish a TCP connection with the device and communicate with it, sending and receiving messages.