Hi i am on creating streaming application. in that i am using IP Multicasting.
Tell me how to validate the client before adding it in the group.
is that anything i have to do with IGMP?
You don't do it with your application.
IGMP is an internet layer protocol, it may not even reach your application.
Whenever a unit wants to receive multicast to a certain address, it sends an IGMP request to join a group. A router receives the request and remembers that this user wants to belong to this group.
Whenever the router receives a multicast packed destined for that address, it routes it to all the group members, possibly taking some access control restrictions into account.
All group manupulation is performed by routers. You just send your UDP packets to a multicast address (that is 224/4), and the routers decide whether to route it to a subscriber.
If you want to limit destinations where your multicast packets go, you do it on routers.
You should understand though, that the word "routes" above means that the router emits the packet into appripriate interface with a multicast destination address in Ethernet header and multicast destination address in IP header. An Ethernet switch attached to the interface, if any, will distribute the packet over all active ports. Since it knows nothing about internet routing, it will just see the broadcast/multicast bit set in the Ethernet header and act accordingly.
There are, though, some link layer devices (Ethernet switches) who peek into network layer headers and limit multicast to the subscribed units. That is called IGMP snooping. Some of them can also be capable to control access.
OK, there is a legitimate need to control who can join a multicast group. The only way I can see that being done is by filtering IGMP packets inbound on the router interfaces. This would work if the list of "allowed subscribers" is sufficiently static, but if there's a lot of changes, it would rapidly become untenable.
If (and only if) there's administrative control all the way down to a "customer-placed" router, I suspect something could be done there, to limit the groups that device has visibility of, but that is heavily dependent of environment (in a "broadband and multicast video from a single provider" scenario, a contractual requirement for using a provider-managed DSL router would be possible).
In addition to Quassnoi's comments on how multicast works, I have to wonder... Why do you want to restrict multicast membership and/or validate the recipient before having it added to the group?
Related
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.
How is a packet received by a wireless devices with thousands of users/devices connected to the same network?
If we are using UDP, will it send the packets to all the devices such that only the authenticated devices will accept the packets and others would reject?
How does the situation change if we use TCP instead of UDP?
UDP and TCP are the same as they are higher layer protocols.
Majorly simplified, but the device opens a tunnel to a GSN (Gateway Serving Node) which is a server installed at the carrier. Which GSN to use is based on the APN (Access Point Name) supplied when the tunnel (PDP context) is requested. The tunnel is assigned an IP address at the GSN and that is the address used for IP communication. Packets will be filtered at the GSN and routed to the specific device. Traffic is tunneled between the GSN and the device using telecom specific protocols. Packets are not broadcast out to all devices and then filtered there.
Ps. I phrased the answer using GPRS terms. Other 2.5/3/4G protocols use the same structure but sometimes have different names.
what you mean by authenticated user?
are you concentrating in application level ? or at lower layers of the n/w?
even it is UDP , it should be thought of sending it to specific IP.even in complex n/w each s/m is an unique entity
Rohith Gowda , actually if you are concentrating on udp packets at Application level (either java, c# ...) u creates the packets for specific ip and sends to an IP,( which is the recivers ip) and the reciver have to grab it , i think you actually want this right? and no need to fear about others with different ip than what you are sending to, because you are in abstracted APP Layer, your doubt will be look after by lower layers.if you want an additional snooping proof just encode the data that you want to send
one Example is (in java)
DatagramPacket (UDP) can be created by invoking a new instance of
DatagramPacket(packet data [],offset ,length ,address* ,port* )
look at the last 2 params they specify the SeverAddress and the Port of transmit to the server
i think you are now clear that the destination server with the ip (Sever-address) listening at the particular port can grab it.
If you have a switch with at least one subscriber to a multicast address, how much additional load would each additional subscriber add?
Example:
You have a 10G switch (with IGMP) with 10 servers and no other activity.
When Server1 subscribers to a 1G multicast feed, the switch will have 1G of load.
What would the load be after Server2 and Server3 subscribed?
Obviously traffic to the switch would not increase, but what about the switch's internal load?
Houw would the answer be different without IGMP?
The whole idea of multicast is that it is efficient. The presence of one subscriber downstream causes the switch to send an IGMP join request of its own upstream and pass incoming multicasts downstream, without duplication. The addition of further downstream subscribers has no effect at all except to increment an internal subscriber count for that group. When that goes back to zero it sends an IGMP leave request of its own upstream.
I don't know what you mean by 'without IGMP'. There is no such thing as UDP multicast without IGMP. It is a contradiction in terms.
Firstly, some background information for you.
The traditional definition of routers and switches are along the lines of:
Router: a device capable of routing a packet form one IP subnet to a different IP subnet
Switch: a device capable of switching a packet within the same IP subnet
However, this traditional definition no longer holds these days because we have switches that can route traffic from one IP subnet to another IP subnet and even perform complex operations such as QoS at wire speed.
Therefore it is often easier to redefine Routers and Switches as follows:
Router: a device that uses the CPU to route packets, often inspects parts of packets that are higher up the OSI layer.
Switch: a device with ASIC(s) (a.k.a switching chips) that switches/routes traffic at full wire speed. What this means is that if the switch has 24 1Gbps ports, it will be able to switch 24Gbps bi-directional traffic without dropping any packets.
Now, to answer your question, it is important to determine whether the ASIC in your switch is capable of handling multicast traffic or not. If so, adding "load" really isn't an issue, as long as you ensure that each switch port is not congested (e.g. 2Gbps of traffic trying to egress out of 1Gbps port). If the ASIC in your switch is NOT capable of handling multicast traffic, it is highly likely that the switch will simply send all multicast traffic up to the CPU. Then it would be up to the software to determine where each packet goes. CPUs on switches are not powerful, because their primary role isn't to route/switch packets, but to manage the switch (e.g. configure the ASIC so that packets get switched properly). Therefore, if your switch is sending packets up to the CPU, the switch will struggle. You won't get anywhere near 1Gbps of multicast via the CPU.
Without IGMP, switches, by default, will flood out the traffic on all ports. Again, this is not a problem for the switch itself because it can handle this at wirespeed. It may cause problems for other parts of the network because traffic is needlessly being duplicated.
The reason for this long answer is because the phrase "10G switch" in your example is quite misleading, and it led me to believe that you maybe thinking that a powerful CPU sits at the center of the switch that is capable of performing 10Gbps bi-directional switching. This is simply not the case, and talking about "load" on a switch therefore often makes little sense.
I hope this helps.
I was reading a paper related to network security and they have mentioned something called local per flow state maintained by routers. I didn't get what this means. I googled for a while but couldn't get a decent answer. Any suggestions?
A flow is a sequence of packets from a source to a certain destination (it can be a unicast, multicast or broadcast destination, if the network protocol supports it) at a certain point in time. Details depend on the context, particularly on the network and transport protocol. For TCP and IP, for example, a particular packet flow is identified by the protocol (TCP), the source and destination port numbers and the source and destination IP addresses. If security is applied (e.g. IPSec), then it might make things more complicated since it may introduce e.g. tunnels, which basically create flows inside a flow.
What you mention, per flow state on a router, means that the router stores these data (usually for a certain time) to be able to identify packet flows. A router typically does this for e.g. connection tracking or to be able to make filtering decisions (e.g. rejecting incoming packets not belonging to a flow established by a computer on the internal network).
So for instance, when I open a new browser window and type www.google.com in it, this will create a new flow with the following parameters:
transport protocol: TCP
source port: the source TCP port allocated to the web browser, e.g. 12345
destination port: 80
source IP: my computer's IP address, e.g. 1.2.3.4
destination IP: the IP address www.google.com was resolved to, e.g. 173.194.44.17
for example a voice call consists of many consecutive packets all part of the same communication.
We call this sequence of packets a flow. More specifically:
Flow: A collection of datagrams belonging to the same end-to-end communication, e.g.
a TCP connection.
per flow state is not maintained by routers/switches they just route packets individually. they treat each packet unique though they might be going to same destination hence, no per flow state is maintained
2 computers are in different subnets.
Both are Windows machines.
There are 2-5 IGMP-ready routers between them.
They can connect each other over multicast protocol (they have joined the same multicast group and they know about each other's existance).
How to establish a reliable TCP connection between them without any public server?
Programming language: C++, WinAPI
(I need a TCP connection to send some big critical data, which I can not entrust to UDP)
You haven't specified a programming language, so this whole question may be off-topic.
Subnets are not the problem. Routability is the problem. Either there is routing set up or there isn't. If they are, for example, both behind NAT boxes, then you're at the mercy of the configuration of the nat boxes. If they are merely on two different subnets of a routed network, it's the job of the network admin to have set up routing. So, each has an IP address, and either can address the other.
On one machine, you are going to create a socket, bind it to some port of your choice, and listen. On the other, you will connect to the first machine's IP + the selected port.
edit
I'm going to try again, but I feel like there's a giant conceptual gap here.
Once upon a time, the TCP/IP was invented. In the original conception, every item on the network has an IPV4 address, and every machine could reach every other machine, via routing, except for machines in the 'private' address space (10.x, etc).
In the very early days, the only 'subnets' were 'class A, class B, class C'. Later the idea of subdividing a network via bitmasks was added. The concept of 'subnet' is just a way of describing a piece of network in which all the hosts can deliver packets to each other by one hop over some transport or another. In a properly configured network, this is only of concern to operating system drivers. Ordinary programs just address packets over the network and they arrive.
The implementation of this connectivity was always via routing protocol. If you have a (physical) ethernet A over here, and a (physical) ethernet B over there, connected by some sort of point-to-point link, the machines on A need to know where to send packets for B. Or, to be exact, they need to know where to send 'not-A' packets, and whatever they send them needs to know where to send 'B' packets. In simple cases, this is arranged via explicit configuration: routing rules stuffed into router boxes or even computers with multiple physical interfaces. In more complex cases, routing boxes intercommunicate via protocols like EGP or BGP or IGMP to learn the network topology.
If you use the Windows 'route' command, you will see the 'default route' that the system uses to send packets that need to leave the local subnet. It is generally the address of the router box responsible for moving information from the local subnet to everywhere else.
The whole goal of this routing is to arrange that a packet sent from a.b.c.d to e.f.g.h will get there. TCP is no different than UDP, except that you can't get there by multicast or broadcast: you need to know the exact address of your correspondent.
DNS was invented to allow hosts to learn each other's IP addresses without having human being send them around in email messages.
All this stops working when people start using NAT and firewalls to turn off routing. The whole idea of NAT is that the computers behind the NAT box are not addressable at all. They all appear to have one IP address. They can send stuff out, but they can only receive stuff if the NAT box has gone to extra trouble to map them a port.
From your original message, I sort of doubt that NAT is in use here. I just don't understand your comment 'I don't have access to the network.' You say that you've sent UDP packets here and there. So how did you do that? What addresses did you use?