this is a homework question.
I tried almost a week for finding a solution for this problem. The problem is as follows
Consider doing a multicast in an Extended Ethernet LAN (multiple Ethernet LAN segments connected via bridges). Assume that hosts do not send Ethernet membership reports (which we discussed in class). However, the bridges (not the hosts) can have their software configured as we please. Assume want to implement IPv4 multicasting on that LAN. How would you modify the bridges to allow efficient multicasting? I.e., bridges forward IP multicast packets only to the LAN segments where there are receivers, and it should involve the least amount of processing at the bridges.
Thanks in advance
Are you saying hosts do not send IGMP membership reports? As I've never heard Ethernet membership reports..
And I'm confused by the requirements. If the hosts cannot send membership reports (assume it's IGMP one), how could the bridges know whether there is any receiver in a LAN segment? IP multicast is receiver driven design, the receivers must indicate their interests in some multicast group.
Related
I am still trying to understand DDS and its concepts.
I have a configuration where 2 laptops run dds based application. My environment does not permit multicast so I decided to go for peer to peer connection(unicast). To bring both the laptops in the same network, I connected them using ethernet cable (Not sure if it was necessary or not).
Now I did not change anything in the QoS i.e. i did not do any settings for unicasting. But now my applications are communicating with each other.
Question :
How are the participants being discovered ? Multicasting ? as I did not do any settings for unicasting.
Was it necessary to bring them under one network i.e. connect with ethernet cable if I wanted to use unicasting ?
EDIT :
Configuration is as follows :
First laptop : Windows OS : Native DDS based application : Publisher : Multicast not allowed.
Second Laptop : Linux : ROS2 based subscriber : Multicast no problem
Out of the box, DDS is required to support Multicast and Unicast Discovery. Anonymous connections are handled through multicast. If you know the IP address of the recipient, you can manually configure those addresses into the unicast discovery list (each vendor will have their own way to name/process this list).
"Multicast is not permitted on our network", in most cases, means that your IT department has turned off multicast packet forwarding at the switch (or the switches) that define the fabric that is your network.
The as-shipped, standard-compliant DDS configuration, however, has no knowledge of this local policy (how could it?). If you haven't changed the configuration in line with your local policies, the DDS Participants are still going to try to connect via Multicast, because you haven't turned it off.
If the DDS-using machines are connected to the same hub, or to an unmanaged switch (defined here as one that your IT department doesn't care about, or is misconfigured), and the network topology does not cross a managed switch, and they are using the default configuration, and they find each other, then they are using Multicast anonymous discovery.
Figure out how to configure your DDS implementation, to add the unicast ip addresses of the machines that need to communicate. Because discovery is usually only needed in one direction (if A discovers B, then it is true that B has discovered A, assuming neither A nor B are configured to ignore the other[1]).
Once you have configured for unicast discovery, you can configure for no-multicast. If the machines are on IP hopping networks (WiFi, etc) it will be difficult unless the DDS implementation understands multipathing. Talk to the vendor to see if this is the case.
[1] DDS is nothing if not overly configurable.
How are the participants being discovered ? Multicasting ? as I did not do any settings for unicasting.
It is not possible for me to answer this question with complete certainty since you are using DDS as part of the ROS2 framework and I am not familiar with the exact details of how the two are set up to interact together. Having said that, from your description it does seem that the participants are indeed using multicast to discover each other.
The best way to get a conclusive answer is by sniffing the network -- assuming that you have the required privileges to do so. For example you can use Wireshark , which comes with an RTPS dissector that allows you to filter on RTPS messages. (RTPS is the name of the standardized DDS wire protocol.) Check out the destination address and see if you detect any addresses in the multicast range. You can do this while firing up a single DDS-based application. It will start announcing itself over the network immediately.
Was it necessary to bring them under one network i.e. connect with ethernet cable if I wanted to use unicasting ?
If you want to use unicasting, you will need to know IP addresses or host names of all peer nodes. As long as those peer nodes can reach each other over UDP, you are good to go. Often, but not always, ping will let you know whether this is the case. Firewalls are a typical cause of problems.
However, be aware that different types of network have their own specific properties that you might have to adjust your configuration to. Over WiFi for example, the likelihood of packets being dropped (especially with bursts of data) is much larger than when connecting nodes directly with a wire. DDS allows for tuning its protocol to deal with that.
We have developed a device that is connected to our clients network and we would like to be able to get its ip or set the ip without knowing its ip.
The device has a Linux OS.
We can save the device MAC Address before giving it to customers. We can program a service to broadcast the device IP and MAC Address to a certain IP or port/socket. We can listen to a certain port/socket for commands. Is this the right direction? Should we investigate in other network protocols other than TCP/IP?
We have seen this feature in hardware/device manufacturers provide a CD with a software that can locate their devices on a network even if they have been newly added to the network without network or ip configuration.
Best regards,
Hussam Kazah
Using propriety broadcasting protocol is a very common technique for detecting devices on network without knowing it's name.
However there's a better option:
UPNP, is an excellent protocol for achieving your goals.
libupnp can get you started in no time.
There's a standard protocol called DHCP which allows a network device to make a broadcast request for its IP address. This protocol is widely used by network appliances. On the other hand you may scan your local network for all connected devices using ARP (address resolution protocol) using for example arp-scan utility.
I've been playing around with an ethernet protocol (not IP) constructed using
socket(PF_PACKET, SOCK_RAW, ether_type)
I have a small problem. I've got a packet constructed that has the source and destination mac set to my local cards mac that I've also bound the socket to with bind.
I can receive packets fine from the network.
I'm able to send packets to the degree where I see them appear in wireshark.
However, my listening app doesn't see those packets. It is able to see packets from other sources on the network however.
I should point out that my mac addresses do appear to be being sent in the correct byte order.
Can you send packets to yourself?
Do network cards not loopback?
Does the linux kernel do something special at the IP level for loopback and because I'm below that, ignore me?
Yes, IP "loopback" packets, as you put it, are treated specially. They're looped back internally, not sent out through the interface. So ethernet-level loopback, in this sense, is a special case that doesn't normally need to be supported. Some old 10Mbit ethernet cards were even half-duplex, so it couldn't have worked on that hardware :).
On the other hand, you can buy/make loopback adaptor cables to test network cards. So it must be possible on (hopefully all) modern hardware. And people have used them under linux with AF_PACKET (evidence, though no more details, here).
I guess the next question would be whether your switch supports this. A dumb hub would have to support it, but there's room for a modern switch to get confused. Or maybe disallowing it in fear of an infinite loop of packets.
Is multicasting inherent to every ethernet system?
What I am trying to do is send codes via ethernet to many devices (without having to send the same 'message' to each device). I am not familiar with the design of multicast systems, so forgive me if this is a lame question. I do know there are IP ranges reserved for the use of multicasting, but does that mean if i set receiving devices to those IPs, they will all receive the same 'messages'?
The IGMP wikipedia page has a lot of good information. Your question is a bit out of scope for stackoverflow.
Multicast uses IP, but I wouldn't say it's inherent to every ethernet system because all network infrastructure needs to be properly configured to allow IGMP subscription.
You do not set a client to the multicast IP. Your client subscribes to the multicast ip, your router sees this subscription and passes it along to that device. The wikipedia page will point you in the right direction, but as I said earlier, it's a bit outside the scope of Stack overflow.
I've been experiencing an issue with my server software where if one thread joins a multicast, another thread may not receive an incoming datagram on a different multicast at that same instant. I'm not sure if this can be dismissed as an expected loss due to "unreliable nature" of UDP multicast, or if this is a serious driver/nic defect. Packet capture also shows a gap at that moment.
I've observed this problem on multiple nic models and manufacturers, including Intel and HP. The reason I feel this is a nic or driver issue is that the problem doesn't occur at all if I run a packet sniffer that puts the interface into promiscuous mode.
Is it possible that while IGMP join or leave is updating forwarding tables in the nic it simply stops forwarding all multicast traffic at that moment? Is this acceptable?