Is there some trick so that I can multicast a Ghost image across subnets? I've tried -TTL7 on the server and -JS=7 on the clients (# of hops).
Related
I want to build an overlay network through VXLAN multicast to achieve communication between virtual machines, but I found that multicast packets can only be transmitted on the same subnet. In order to allow virtual machines on hosts that are not on the same subnet to communicate, I am thinking whether "capture and forward packets" would work. That is, grab a UDP packet with a destination address of 239.1.1.1 and a port of 4789 on hostA on network1, and send it to hostB on network2, and let hostB send the multicast packet. Then I found that the hosts on network2 all can catch this packet with wireshark, but no host corresponds to it. I wonder if Linux has a mechanism to discard fake multicast packets? If this is the case, how should this mechanism be prevented?
Unhandled, multicast is essentially broadcast. For IPv4 multicast that broadcast effect can be mitigated with IGMP. On switched networks with semi-intelligent switches there may be IGMP snooping functionality to further aid in this. Provided this exists, an end-device must subscribe to a multicast group by sending an IGMP join for the given group to "unfilter" that traffic towards itself. Routing multicast between subnets can be done with PIM or DVRMP implementations, or even static multicast routing daemons.
Only exception to this filtering is the 224.0.0.x range, which is reserved for link-local communication, usually IETF protocols. Traffic to these groups must never be filtered in any way.
Hence, to prevent filtering, either the end devices join the group (recommended!), or you send traffic to a group in the reserved range, e.g. on 224.0.0.1 the all-hosts group. (It's ugly and you may trigger ugly bugs on devices in the LAN, but it works.)
If I understood correctly, in multicast scenario, packets send to a multicast group are received only by the clients who joined the group(essentially the router forwards the packets ONLY to intended recipients). Then how is wireshark able to capture the multicast traffic(even in non promiscuous mode)?
Please help me understand if I am missing something. In the below sample capture, 192.168.1.1 is the server sending the multicast packets to group 239.0.0.222 and the current machine/wireshark did not join the group but still be able to capture the packets.
Topology:
I have 3 VMs, 1 Server, 1 Client and 1 WireShark VM. All of these three VMs are behind a Hyper-V Private switch(in the same subnet).
It's true that routers will only forward multicast traffic if there are clients on the other side that are expecting that traffic. But in your case all 3 VMs are in the same subnet so there's no router involved, only a switch.
The switch that the 3 VMs are connected to probably doesn't perform any special handing of multicast messages. This means that any multicast message it receives is being sent out on all ports, which includes the VM running Wireshark. And because the packets are physically arriving on that port, Wireshark sees them and displays them.
I have a dual port ethernet NIC and let's say I have connected 2 ports in a loop and assigned the following IPs to the 2 ethernet interfaces:
eth2 -> 192.168.2.1
eth3 -> 192.168.3.1
I want to send traffic from 1 port to another over the physical network, e.g. ping 192.168.3.1 from 192.168.2.1. However, the TCP/IP stack in the Linux kernel recognizes that these two addresses are local and instead sends the traffic to the loopback adapter, so the traffic never hits the physical network.
The closest I have to a solution is Anastasov's send-to-self patch, which unfortunately, has been discontinued since kernel 3.6 so it won't work on Ubuntu 13.10 (kernel 3.11) for me. I've tried finding rewriting the patch for 3.11, but I can't seem to locate these in the Ubuntu distro:
include/linux/inetdevice.h
net/ipv4/devinet.c
net/ipv4/fib_frontend.c
net/ipv4/route.c
Documentation/networking/ip-sysctl.txt
Is there a way I can get the send-to-self patch to work, or an alternative?
You can use network namespaces for this purpose.
As ip-netns's manpage says:
A network namespace is logically another copy of the network stack,
with its own routes, firewall rules, and network devices.
Following is just a copy of this answer:
Create a network namespace and move one of interfaces into it:
ip netns add test
ip link set eth1 netns test
Start a shell in the new namespace:
ip netns exec test bash
Then proceed as if you had two machines. When finished exit the shell and delete the namespace:
ip netns del test
you can try configuring route table, by running "ip" command:
ip route add to unicast 192.168.3.1 dev eth2
ip route add to unicast 192.168.2.1 dev eth3
new route would be added into route table, and it should be able to take effect before egress routing lookup hit the host-local route between "192.168.3.1" and "192.168.2.1", therefore, the traffic should be sent through physical interface "eth2" and "eth3", instead of loopback "lo"
Never tried myself, but should work.
I am facing an problem that is i have 2 nic in same machine named NIC-1 and NIC-2.
Both to them have static IP like 192.168.10.12 (NIC-1) and 172.16.10.12(NIC-2).
Both of them are on same machine and they are not connected by any wire.
I want to send packets between the two but the mail problem is i am not able to ping them.
Will the "brctrl" command help me in sending packets between them?
IPv4 addresses starting with 10.x.x.x, 172.x.x.x, and 192.168.x.x are private IP addresses. They are for private networks and not publicly routable.
To be able to ping between those two NICs, you would have to have IP addresses that are on the same subnet (they can be on the same private network), or that have routing masks that enable them to see each other on the net, and be connected via some physical medium.
There are 2 things in your Problem :
Both network should be in same subnet to ping .
there should be some cable mechanism to transfer packets or use loopback address for particular NIC .
I have several programs listening to the same multicast stream, I'm wondering will this doubling the traffic compared with only one program listening or the traffic/bandwidth usage are the same? thanks!
The short answer is no, the amount of traffic is the same. I'll caveat that with "in most cases". Multicast packets are written to the wire using a MAC address constructed from the multicast group address. Joining a multicast group is essentially telling the NIC to listen to the appropriate MAC address. This makes each listener receive the same ethernet frame. The caveat has to do with how multicast routing may or may not work. If you have a multicast aware router then multicast traffic may traverse the router onto other networks if someone has joined the group on another subnet.
I recommend reading "TCP/IP Illustrated, Volume 1" if you plan on doing a lot of network programming. This is the best way to really understand how all of the protocols fit together.
Are the clients on the same network?
For wireless 802.11 multicast, it depends on the implementation of Multicast at the wireless access point.
Some wireless access points do multicast to unicast conversion at the datalink layer and thus send a data separately to EACH client that has joined the multicast group.
If the AP is not doing unicast conversion, generally, your network utilization does not increase.