Pardon my limited knowledge in networks.
I am trying to setup two small programs as client and server, which join to a particular multicast group. The servers sends some arbitrary data to the group and the client receives the data as it listens to the group.
This of course is possible with UDP programs which I have already done. However I need to work with MAC addresses instead of IPs. And I have a few questions regarding this:
Is it possible to fix a range of MAC addresses for my multicast application ? As I understand, the least significant bit of the first octet in the MAC address signifies if it is multicast or not. So the multicast MAC should look like 01:*:*:*:*:* . So I guess, there should be some way to use a wide range of MAC addresses (except for those reserved).
Many places it is written as All multicast MAC addresses begin with: 0100.5e . Is it always true? AFAIK this prefix is fixed in the MAC address which leaves space for the rest of the IP address bits to be mapped here. But what if my application doesn't care about IP addresses and listens to multicast groups based on MAC addresses (if it is possible) ?.
Can't I keep the first octet as 01 and use a wide range for my multicast addressing ?
How to send packets to a multicast group and listen to a multicast group only based on MAC addresses and irrespective of IP ? i.e. the multicast group addresses are defined based on MACs.
I hope my questions made sense.
If you are not using IP (or UDP on top of that) then the default way of mapping IP addresses to mac addresses have probably no added value for you. These mappings are specified for example in:
http://en.wikipedia.org/wiki/IP_multicast#Layer_2_delivery
rfc1112 https://www.rfc-editor.org/rfc/rfc1112 paragraph 6.4
If you insist on using layer2 and multicasting it will probably be sufficient to send out frames with the LSB of the first octet set (the multicast bit, ref: http://en.wikipedia.org/wiki/File:MAC-48_Address.svg ). And put your own mapping on top of that. But you should take into account that:
you probably need to force your NIC to pass the data, often NIC's filter out frames they are interested in hardware. And these filters are typically set when joining a group or e.g. when setting the ALLMULTI flag).
There is probably networking equipment in the middle and some pseudo-intelligent switches may refuse to forward data unless they have seen IGMP joins (ref igmp snooping).
And you code will obviously need to deal with raw layer 2 sockets to read out the data.
Considering the ease of just using UDP this may be a lot of work.
Related
I'm testing how windows handle IPv4 ID. I need to generate 10,000 TCP or UDP packets per second with different source IPs(my netmask is 255.255.0.0, so there are 2^16 IPs available. But it's not the case here since I can do IP spoofing). I know that I can change the count parameter in scapy.sendrecv.send to generate a large number of packets at the same time but the configuration of the packets is all the same. Moreover, I also want occasionally to pick out some responses to check the status.
I'm currently thinking about using multithreaded but I'm not sure how to do that. Can anyone give me a structure to start with?
I found that it is possible to do so by MAC spoofing. Apart from spoofing, is it possible? If so, in what instances is this possible?
A switch learns unicast MAC addresses into its source address table or CAM table by inspecting each frame's source address. A MAC address association already present on another switch port is moved to the current frame's ingress port.
In no case does a properly working switch associate multiple ports with the same MAC. Accordingly, a frame addressed to a specific MAC address is always forwarded out of the last switch port that has received a frame from that address. If the associated port changes rapidly it's somewhat random where a frame destined for that MAC address ends up.
Some managed switches track the learning behavior and report flapping/duplicate MACs when they change port association repeatedly in a short time period. There may also be some contingency scheme for where to forward frames to such an address.
I understand that it's different than a hub in that instead of packets being broadcasted to all devices connected to the device, it knows exactly who requested the packet by looking at the MAC layer.
However, is it still possible to use a packet sniffer like Wireshark to intercept packets meant for other users of the switch? Or is this only a problem with ethernet hubs that doesn't affect switches due to the nature of how a switch works?
On a slightly off topic side note, what exactly is classified as a LAN? For example, imagine two separate ethernet switches are hooked up to a router. Would each switch be considered a separate LAN? What is the significance of having multiple LAN's within the same network?
it knows exactly who requested the packet by looking at the MAC layer.
More exactly, the switch uses the MAC destination address to forward a frame to the port associated with that address. Addresses are automatically learned by looking at the MAC source address on received frames.
A switch is stateless, ie. is has no memory who requested which data. A layer-2 switch also has no understanding of IP packets, addresses or protocols. All a basic switch does is learn source addresses and forward by destination address.
is it still possible to use a packet sniffer like Wireshark to intercept packets meant for other users of the switch?
Yes. You'll need a managed switch supporting port mirroring or SPANning. This doesn't intercept frames, it just copies them to the mirror port. If you need to actually intercept frames you have to put your interceptor in between the nodes (physically or logically).
With a repeater hub, every bit is repeated to every node in the collision domain, making monitoring effortless.
what exactly is classified as a LAN?
This depends on who you ask and on the context. A LAN can be a layer-1 segment/bus aka collision domain (obsolete), a layer-2 segment (broadcast domain), a layer-3 subnet (mostly identical with an L2 segment) or a complete local network installation (when contrasted with SAN or WAN).
Adding to #Zac67:
Regarding this question:
is it still possible to use a packet sniffer like Wireshark to
intercept packets meant for other users of the switch?
There are also active ways in which you can trick the Switch into sending you data that is meant for other machines. By exploiting the Switch's mechanism, one can send a frame with a spoofed source MAC, and then the Switch will transfer frames destined to this MAC - to the sender's port (until someone else sends a frame with that MAC address).
This video discusses this in detail:
https://www.youtube.com/watch?v=YVcBShtWFmo&list=PL9lx0DXCC4BMS7dB7vsrKI5wzFyVIk2Kg&index=18
In general, I recommend the following video that explains this in detail and in a visual way:
https://www.youtube.com/watch?v=Youk8eUjkgQ&list=PL9lx0DXCC4BMS7dB7vsrKI5wzFyVIk2Kg&index=17
what exactly is classified as a LAN?
So indeed this is one of the least-well-defined terms in Computer Networks. With regards to the Data Link Layer, a LAN can be defined as a segment, that is - a broadcast domain. In this case, two devices are regarded as part of the same segment iff they are one hop away from one another - that is, they can switch frames in the second layer.
Hello Networking Gurus,
I have a question about IP duplication and how this impact the associated switches (layer 2). Sorry, I don't have any resources available to test this. It would be great if someone can shed some lights of their experience on this.
If I have two servers (Linux), say A & B, serving exactly same contents and for some reason they both are assigned same IP address. To be more specific, if A already has an address IP.100 and B has another address IP.200. Now at this point everything seems working and the switch has proper MAC addresses stored. If, later, B also gets the address IP.100, how would this affect the switch's ARP cache? When B gets the new address I assume it broadcasts ARP? to inform the associated switch.
So the question is, Does the switch stores both machines' entries? or overwrites the existing with new? Is there any standard behaviour or proprietary switches reacts differently?
If a client, with no ARP cache, tries to connect to IP.100, which machine would it be forwarded to? A or B or none? If A OR B, can I say from client point-of-view, that there's no outage? (Assume this is a static website, with no login sessions etc)
Feel free to point any relevant documentation.
Thank you in advance.
In theory, you shouldn’t have two hosts talking on the same IP, unless they are participating in routing. Eg any-cast. As things will break.
Each host will have its own MAC address. If the switch is only doing layer two forwarding, then the switch only keeps track of MAC addresses. It is the end hosts or routers that track ARP entries.
If you move IP 100 to B, then the hosts will update their own ARP table.
But if A and B have 100 at the same time, this will cause issues.
Switch will not see any IP's and do not have arp cache for forwarding packets , it will had only mac address table map macs to ports and macs in your case will be unique
I actually think this is how multicast works.
Hosts obtain a multicast address and all of the devices share that same multicast address.
A switch will gather collections of Mac addresses to that same multicast in it's mac table.
I could be wrong though....Still learning.
Why do we need an IP address when the MAC address is unique? Cant we communicate only with the MAC address?
You COULD communicate using only the MAC address, but only on your local network. IP addresses are routeable, without every system on the network needing to know about every other. You just need to know a range of addresses that are on your local network, and throw everything else up to your router. The same thing happens at the ISP level. "All 216.x.x.x traffic goes that way, all 105.x.x.x goes that way..."(Obviously a gross oversimplification, but that's the basic process).
If we tried to route everything by MAC address, every machine on the network would have to maintain a list of every other participant, and it just wouldn't scale.
No. MAC addresses are specific to Ethernet, IP is independent of the underlying hardware. You can connect machines that don't use Ethernet to the Internet, if you have the required bridges.
MAC addresses are not unique. MAC addresses are reused between media. This is why wireless (802.11) and wired (802.3) may not both be present on one collision domain (see 802.1D).
MAC addresses are not clustered -- meaning that devices which are nearby in network space do not have nearby MAC addresses. IP addresses do have this property of locality. Do you intend to route packets by having a universal list of MAC addresses copied to every computer on the Internet, or do you intend to route packets to their destinations through a hierarchy of localities?
On a single collision domain, MAC addresses can be the primary addressing mode (q.v. arp and rarp). However, extension to multiple collision domains is ineffective for the above reasons.
A great professor of mine named George Varghese, now at UCSD, made the following apt analogy: You want to send someone a letter. The analogy of sending to a device anywhere in the USA based on its MAC address is like sending someone a letter knowing only their Social Security Number. It does uniquely identify someone (OK, yes, SSN isn't guaranteed unique, but suppose it was for the sake of example), but it would be very hard to find them without some giant table of where everyone lived that you could look up indexed by their SSN.
An IP address (and the similar Open Systems Interconnect, or OSI, network addresses) are more like USA phone numbers with area codes and exchange numbers: (AAA) BBB-CCCC, where AAA is an area code, BBB is an exchange number, and CCCC identifies an individual line at that exchange. There is hierarchical information encoded in that number, so that when you are far away from the destination, you only need a small table indexed by area code to determine a good "next hop" to forward the call to, rather than a table of all phone numbers in the country.
Ethernet is a Medium Access Layer protocol. It was designed specifically to connect computers on the same network. If you want to connect computers remotely located, you certainly need to jump to destination by hopping through several routers. IP (Internet Protocol) was designed with this goal in mind, hence the need for it, while Ethernet protocol does not support routing. Only some forms of primitive bridging that would not scale for something huge like the Internet.
they are used for different protocol layer.
MAC address is your device specific address. It has no relation with the geographical location, etc. you are in currently.
Ex: You can buy a cellphone/laptop in US and use it in Japan,
Australia, etc. But MAC address would remain the same. But IP address
would change with respect to the network you are connected to.
So it is difficult to route packet in an internetwork of portable devices especially.
How would it be:
Consider you have a portable network-accessing device with you on which you are using the internet. If we use only the MAC address, how would any incoming packet find the location of your portable-device. Since MAC address gives you only a fixed 48-bit device address. (The worst case scenario is using a desktop computer and having a MAC address without the IP facility. Coupling it with the static table to find your predefined location based on the MAC address, but our life is incomplete without these portable devices right?)
Thus we need some addressing scheme that can help us with addressing in a big and portable environment like internet, and thus the role of IP comes into picture, where address is hierarchal to provide a more geographically exact location.