currently i am trying to send some multicast data from my docker's application throughout my host's eth2 host interface. i did use --net=host option in docker and this was working perfectly, and unfortunately since i need to open multiple instances that uses same port, its impossible for me to use net=host anymore. i have to go through the bridged mode of docker0
in my docker's interface i have eth0 which is linked to my docker0 as
10.101.131.60.
therefore i did : route add -net 225.1.1.0/28 dev eth0 to pass all multicast packets that my app send to 225.1.1.0/28 to my eth0, which is connected to host as docker0.
therefore, i used wireshark to listen whether my application really throws the message packet to my eth0 inside container, and it really does sending multicasts when i use wireshark inside container.
now throughout i also used wireshark to listen to my docker0 and the packets were there. Now how do i "Forward all my multicast packets" throughout docker0 to my eth2? i used several iptables approach, but none of them seemed to be useful, perhaps that its being ignored?
any help would be appreciated... thanks!
You can use an IGMP proxy like this: https://sourceforge.net/projects/igmpproxy/
Good luck
Related
I have a Linux machine with two interfaces eth0 and eth1.
eth0 has 192.168.2.30 and eth1 has 172.16.30.20. eth0 is connected to a router which is the gateway too for the WAN. eth1 is connected to LAN. All is working well until I had to connect a
set of devices with IP rage 192.168.2.5 - 192.168.2.15 to the LAN to which eth1 is also connected.
I want to send a multicast packet to these devices. Since the multicast works on the same subnet, I created an IP alias using following.
system("ifconfig eth1:1 192.168.2.100 netmask 255.255.255.0 up");
Despite adding the above, the packets are not going through eth1. This is found to be because eth0 is also having the same subnet as that of eth1: 1.
I tried calling ip route add <multicast ip> dev eth1. But, no success.
Appreciate if anyone could offer suggestions.
From the looks of it you have at least two problems here and depending on the solution you choose other issues may arise.
Problem one, Overlapping subnets: The absolute 100% correct way to resolve this is to change the subnets so they don't overlap. I can't stress enough how important this is in your situation. If these computer on 192.168.2.5 - 192.168.2.15 are suppose to be connected to the same network as eth0 then you need to reconsider your setup as this would never work because you will create a networking loop or bad routes.
In the first situation where 192.168.2.5 - 192.168.2.15 and 192.168.2.15 aren't physically connected in any way and if someone above you says you can't do this you can try creating a NAT on eth1 so that your system sees the subnet on a different network. But this can make understanding the routes confusing and may interfere with multicast traffic.
After this is done run a tracerroute to ensure traffic is passing correctly. If not please provide the output and the route you expect it to take along with the current setup.
If multicasting doesn't work still then I recommend to create another question for it.
I have an application that sends messages over UDP multicast that I've been attempting to put under docker. I've been running into much headwind trying to send multicast packets from a docker container.
I have been able to send messages through the --net=host option on running the docker container. I would, however, like to stick with a bridge configuration.
I would like to get some insight in what needs to be done in order to publish messages through the standard docker bridge configuration. I'm attempting to publish messages on 239.9.60.250 with port 16000. I have tried publishing udp port 16000 through the following argument on docker run.
-P 0.0.0.0:16000:16000/udp
This doesn't give me any change in behavior and my host doesn't see any multicast traffic.
Docker network drivers have no IGMP/PIM support, so you should really establish a direct Layer 2 connection from the container to the physical switch/router.
As you have found out yourself, docker's default bridge network will not help you here.
I haven't tested it with multicast, but you should be able to achieve that with Pipework.
macvlan driver should help you with your problem, but is currently experimental as of Docker Engine 1.11
I'm currently trying to automate our beaglebone flashing - therefore we have to manually change the ip address.
I created a script which basically adds sth. like:
# The primary network interface
auto eth0
iface eth0 inet static
address theip
netmask 255.255.255.0
gateway gateway
to /etc/network/interfaces
After adding this I restart networking via:
service networking restart
Which returns "ok", but ifconfig doesn't return "theip" it seems like it just ignores the changes and still uses dhcp.
When rebooting the system, the ip is changed and everything works as expected, but I don't want to restart the system. So how do I correctly restart the networking?
Thanks in advance,
Lukas
Do ip addr flush dev eth0 first and then restart the networking service.
Explanation
The /etc/network/interfaces file is used by the ifupdown system. This is different than the graphical NetworkManager system that manages the network by default.
When you add lines to control eth0 in the /etc/network/interfaces file, most graphical network managers assume you are now using the ifupdown service for that interface and drops the option to manage it.
The ifupdown system is less complicated and less sophisticated. Since eth0 is new to the ifupdown system, it assumes that it is unconfigured and tries to "add" the specified address using the ip command. Since the interface already has an ip address assigned by dhclient for that network, I suspect it is erroring out. You then need to put the interface in a known state for ifupdown to be able to start managing it. That is without an address assigned to the interface via the ip command.
I am testing an application using multicast for the discovery. I created a Swarm cluster and a network create -d overlay swarm-net so the containers share the same LAN across the several Swarm agents hosts.
The discovery seemed to not be working, so I installed tshark. tshark shows the IP address node within which tshark is running and the multicast address for the packet being sent though tshark does not show any incoming multicast packet.
Note that, as I don't know a better way to do so, the container is run with --privileged to enable tshark.
Note also that containers can communicate with each other.
Is the multicast blocked because of Docker iptable?
How to enable multicast in an overlay network?
Overlay-driver network does not support multicast as it uses vxlan unicast, according to chanwit (and my experience so far).
Note that the plugin weave net (an overlay network driver) does support multicast!
How do I set an IP address for a TUN interface on OSX? I cannot figure out how to set up an ip address for my interface without specifying a destination IP. I don't want to do that- I'm want to more or less build a tunnel to an arbitrary address at a later point in time. Prior questions which are unhelpful:
There's a question that has an unclear answer, so I tried following the reference.
This question sets a point to point ip address for a tun device, so it has a destination, which is exactly what I don't want.
On the page for osxtuntap it says:
ifconfig tap0 10.1.2.3 up
I cannot make this work on OSX 10.6 for a TUN interface:
$ sudo ifconfig tun0 10.1.2.3 up
ifconfig: ioctl (SIOCAIFADDR): Destination address required
Adding a netmask doesn't help- OSX seems to demand a destination address:
$ ifconfig tun0 10.0.0.1/24 netmask 255.255.255.0
ifconfig: ioctl (SIOCAIFADDR): Destination address required
For linux, I get how it works. According to this page, you open() the interface, and use the ip command, and do this, and I've done this before with zero issues:
$ ip link set tun0 up
$ ip addr add 10.0.0.1/24 dev tun0
All I want to do is the same thing that I can do in linux.
EDIT:
I'm writing a little UDP tunnel app. Like so:
tun1 -> udp app #1 -> udp tunnel -> udp app #2 -> tun2
If the udp apps are on different computers (let's say local and remote), I'd like to associate their respective tun devices with an ip address, so I can send a packet from local to remote via the tunnel by sending the packet to the ip address of the tun device on the remove machine.
To borrow more from the linux tutorial, the author sets up a tun device on local and remote, associates ips, and runs a simple tunneling app, and then pings the other end of the tunnel:
[remote]# ip link set tun3 up
[remote]# ip addr add 192.168.0.2/24 dev tun3
[remote]$ ./simpletun -i tun3 -s
# server blocks waiting for the client to connect
[local]# ip link set tun11 up
[local]# ip addr add 192.168.0.1/24 dev tun11
[local]$ ./simpletun -i tun11 -c 10.2.3.4
# nothing happens, but the peers are now connected
[local]$ ping 192.168.0.2
By default, tun devices operate in the layer 3 mode, aka point to point. You're asking for layer 2 mode which more closely resembles a generic Ethernet device. Linux calls these tap devices. In OpenBSD you can switch a tun device into layer 2 mode with "ifconfig tun0 link0". The Macintosh tuntaposx driver mimics Linux' device schism; open a tap device instead.
You might want to review https://community.openvpn.net/openvpn/wiki/BridgingAndRouting to determine if you really want tap devices. They add a little overhead. If you just need two boxes to pass IP packets between each other and no bridging or broadcasting to a larger subnet, point to point should be sufficient.
For example, if you have two machines, one we label "local" with a LAN IP address like 192.168.0.12 and another we label "remote" with a LAN IP address like 192.168.1.14, you can assign tunnel IP addresses thusly:
ifconfig tun0 inet 10.0.0.1 10.0.0.2 up
on the local system, and:
ifconfig tun0 inet 10.0.0.2 10.0.0.1 up
on the remote system. Note the reversed perspective on the remote machine. Do not set your point to point addresses to anything on an existing subnet; it will not route properly.
I can't stress this enough: read and re-read the manual pages ("man ifconfig" and "man tun", probably others) until they make sense. My ifconfig examples above may differ slightly from your operating system.
And for another perspective you might look into GRE tunnels as their functionality mirrors what you describe for your program. However, GRE is likely not viable in today's TCP-centric networks nor is it a good idea due to major security issues.
If your goal is to circumvent an overbearing firewall, be aware that many such firewalls block UDP (and especially GRE) packets. In such a case, try SSH interface tunneling to set up tun/tap interfaces and forward packets. You get encryption and optionally compression as well. :)