I have one or more virtual machines on Debian host and two physical eth interfaces. I want to split bandwidth between eths (both for downlink and one for uplink). Is it possible with openvswitch and openflow?
The short answer is that it should be possible with OVS and OpenFlow. With OVS you can connect your VM's virtual ports and the server's physical interfaces.
Without thinking too much, you can load balancing the traffic by:
Installing a flow to direct any VM packet to your uplink port. This flow should rewrite the src IP and MAC as the ones from the downlink interface, so that it will look like it is being sent through that port.
Keep in mind that you might take your virtual ports configuration into account, and that you need some kind of mapping (something like NAT), to get the packets correctly returned to its respective VM. You can take a look in a NAT implementation, for the Ryu controller, to get some inspiration.
Related
I am facing a problem with IBM Datapower XG45.7.0.0.0.
When I am connecting to an external service using DP, the source IP of DP is being picked up randomly among the 3 available eth interfaces. I know this has performance and stability benefits. However, this is causing great deal of pain in the firewall config. As a tactical solution, is there a way to ensure that the traffic is send from any one fixed eth interface?
Sure, normally you should make sure only one NIC has a default gateway (and that would in most cases be the NIC facing the Internet).
The two other NIC's should only have static routes and set for the various subnets they should serve.
If you don't have a need for different IP addresses for outbound (egress) traffic you might want to use only one NIC and set two additional Secondary IP addresses instead.
That way you have three working IP address for ingress (inbound) traffic but only one IP will be used for egress.
I'm looking to build a bittorrent client in Ruby (although language is not important over here).
I read a BEP specification which says querying at /announce (without DHT support) to tracker would give a list of peers currently connected for a given info-hash.
To examine this. I created a torrent file and I found that tracker return the IP of my machine along with the port (which i confirmed is the running port of Bittorrent client on my machine i.e Utorrent)
But here is the problem the Peers info returned the IP of my ISP i.e 111.125.209.41 (the public facing IP since I'm behind the NAT).
Now I cant connect (via TCP) to the Process running on my machine with the public facing IP of my ISP.
Can anyone suggest how does bitorrent work on this and what should I do to solve this.
It could that over UDP Bittorrent would be using UDP hold punching not sure what happen on TCP.
There are two separate concerns.
How do peers on the internet (aka 99.99999% of the world) connect to your NATed node
How do peers inside your network connect to a node on the same network.
The first is achieved by various nat traversal methods, including negotiating with the nat device or manually configuring it.
The second issue either requires a router capable of hairpin routing in combination with a forwarded port or local peers discovering the internal address through other means, such as LSD.
I have DPDK set up, with two NICs taken over by DPDK, i.e. the interfaces
are not visible to userspace applications.
Now, I need to run netperf/iperf to measure throughput performance of port-to-port
configuration of DPDK, as described here https://github.com/01org/dpdk-ovs/blob/development/docs/04_Sample_Configurations/00_Phy-Phy.md
However netperf server requires to be bound to the network interface, and netperf client
has to know the netserver's IP address. But since the interfaces were taken
by DPDK, and netperf can't see their IP addresses any longer, how could I
run tests? Is there a way to redirect netperf right in network port,
regardless of IP addressess.
iptables, ebtables.. ?
Thanks.
If you're going by that diagram, your netperf and netserver should both be on the traffic generator. On the DPDK host, traffic coming in one interface is simply routed out the other interface by OVS, and back to your generator. There are a variety of tricks to get your generator to send traffic out on the wire rather than short circuiting over loopback, but they have been addressed here already.
If what you really want to do is have netserver running on the DPDK host, then you simply need to create a virtual interface, attach it to OVS, give it an IP, and direct your netperf traffic to it.
I am developing a networked application that runs on a few different computers on a LAN. One of the core needs is for the app to maintain a list of peers on the LAN with which it has communicated in the past, so that it can restore previous sessions. The naive solution would be to just remember the IP and store it in a table, but what happens when the IP of a peer changes?
Instead, I thought I'd store the hostname of the peers so even if the IP changes they will still be reachable via their hostname. (I know hostnames can change as well but that is good enough).
So my question is what exactly is needed to make hostname resolution work on a LAN with mixed Windows/Mac/Linux clients?
Without the use of a central authority the only reliable way to achieve this is through the use of zerconfiguration name resolution. This means that without a multicast router you will only be able to dynamically resolve peers on the same subnet as the resolving host. You could use something like bonjour for mac, netbios or ssdp for windows or avahi for linux but you can't assume that these are enabled. I may be overlooking some more popular protocols that perform this function well but I would personally throw together a quick udp broadcast name resolution protocol for your application. Take a look at these for some more ideas:
Zeroconf Name resolution
Universal local network name resolution method without DNS?
http://en.wikipedia.org/wiki/Zero_configuration_networking#Name_resolution
http://en.wikipedia.org/wiki/Broadcast_address#IP_networking
I would pick a specific udp port to listen on (lets say 12000) and then when you're ready to resolve hosts send a "hello" udp packet out to 255.255.255.255 on port 12000 and all of the other hosts on your network running your app should reply with a packet containing their hostname, possibly other information.
... say for CentOS?
From what I understand a virtul IP can let you abstract the address from the physical interface(s) the traffic actually goes through. If your server has two network cards it can have a single virtual IP and have the traffic go through either network physical interface. If hardware failure occurs on one of the two network cards, the traffic can keep going with the second one as a backup. I assume that this is more relevant on servers where such parts can be hotswapped.
A Virtual IP address is a secondary IP set on a host, it's just another IP bound to an adapter (adapters if bonded). This IP is useful for many things but most commonly used for webservers to run multiple SSL certificates for multiple sites.
In CentOS you pretty much copy the /etc/sysconfig/network-scripts/ifcfg-eth0 (whichever for the adapter you want) to /etc/sysconfig/network-scripts/ifcfg-eth0:1, In there change the devicename=eth0 to devicename=eth0:1 and change the IP for the new "virtual IP" you want.
Check out this article on Virtual IP address. As indicated it usually floats between machines, and is sometimes used to fail-over a service from one device to another. Are you thinking of a virtual interface instead perhaps?
/Allan