Network disconnect issue happens in a system of my company.
Here is the network topolgy:
PC1: two NICs, both static IP address. Data: 10.10.22.11, Control: 10.10.22.10
PC2: two NICs, both static IP address. Data: 10.10.22.101, Control: 10.10.22.100
Default Gateway 10.10.22.11 is set on both side. However I don't think this is necessary, as there is no router or gateway between the two PCs, there directly linked.
A consultant point out, since all the IPs are set in same segment 10.10.22, there could be broadcast storm, which might be the cause of network disconnect.
Is this true? Can broadcast storm happen in directly linked two PCs?
No it shouldn't be.
Broadcast storms happen when there is a loop in a network.
A packet is forwarded to all ports in a switch and if there is a loop the packets are again sent to the same switch on all ports, amplifying the storm, if there is no network loop there shouldn't be any storm.
I don't see any loop in your configuration so this shouldn't be any broadcast storm.
Identifying broadcast storm is not so hard, just sniff on an interface on the network, and if you see millions of times the same broadcast packet, it should be a broadcast storm.
Related
Hi I've been learning networks for a while now and I can't seem to find a solution for this doubt online.
I learnt that if you are sending a packet to a class B network's destination 141.49.255.255, it means you are broadcasting the packet to the whole class B network of 141.49.0.0; I also learnt that if you are sending a packet to a class A network's destination address like 10.255.255.255, you are again broadcasting the packet in the network ID 10.0.0.0
My question is, what am I doing when I'm sending a packet to class B 141.255.255.255 ? Am I sending it to a single host or a network?
Forget classes. Everything is being done in CIDR for the last two decades.
Sending to 141.255.255.255/16 is a subnet broadcast to 141.255.0.0/16. The same address may also be
141.255.255.255/8 - subnet broadcast to 141.0.0.0/8
141.255.255.255/6 - unicast(!) to the node 141.255.255.255
Most often, broadcasts are sent to 255.255.255.255. Routers (usually) don't forward broadcasts, so it's limited to the segment anyway.
However, there are some subtle differences: running e.g. 192.168.1.0/24 and 10.1.0.0/16 inside the very same Ethernet segment, a broadcast to 192.168.1.255/24 is physically sent to all nodes (Ethernet broadcast), even the ones with a 10.1.0.0/16 address. These however will the drop and ignore the packet since it doesn't address them.
In contrast, a broadcast to 255.255.255.255 will be sent to all nodes and processed by all nodes.
I am familiar with the basic OSI model but I always get confused how does a packet travel from one machine to another over the Internet and what OSI layers do come into picture? For example, for the following topology:
Machine A<----->Switch<---->Router<---->Router<---->Router<---->Switch<---->Machine B
where the multiple routers are shown to represent the Internet, what happens at the OSI layer level, when Machine A send a packet (say a simple "ls" command over FTP) to Machine B.
The above is just a suggested example, but if any one can explain with any other network topology, that is fine too. All I am looking a very basic explanation of how the packet gets transformed to different OSI layers at each nodes (Machine, Switch, Router, etc.).
Routers use the IP layer (layer 3) and switches use the data-link layer (layer 2). Layer 1 is the physical 1s and 0s that go over a wire, Layer 2 is the data-link layer, which is protocols like Ethernet and Point-To-Point Protocol (PPP), which carries information between adjacent nodes about MAC address from and to and allows for error detection and retransmission. Layer 3 is the IP layer, which carries information about where in the whole network the packet is from and to, not just the current hop.
The transmission would go like this:
Machine A wants to send a packet to Machine B. Machine A knows Machine B's IP address, so it places that in the layer 3 packet. Machine A needs to place the MAC Address of the next hop in the layer 2 packet, however. If it does not know, then it will send something called an ARP request (Address Resolution Protocol, read here: http://www.tildefrugal.net/tech/arp.php ) to the network, with the destination IP. One of a few things will happen here:
The IP is local. The machine with that IP will reply back to the sender with its MAC address.
The IP is non-local. The gateway router will detect this and send its MAC address.
The IP is non-local and Machine A's default gateway and subnet mask are set. Using this information Machine A can determine the non-locality of the IP address and send it to the router's MAC address (ARPing if not known yet).
(If Machine A found this out earlier, it will be in the ARP cache and Machine A will just use that.) Now that the MAC address is sent, the packet can be transferred (the physical layer 1 performing the actual transfer of data on the wire). The next stop will be the switch. The switch knows which outbound port the MAC address listed as the layer 2 destination is on, because it tracks every MAC address it's seen a packet come from and which port it came on - if it does not know, then it will flood it out every single port, guaranteeing it'll arrive.
As such, the packet arrives at the router. The cool thing about the IP model is that it divides every single IP address in the network/world into a hierarchy - Subnets by definition cannot overlap subnets partially, they either wholly contain them or are wholly contained by them. So as long as subnets follow this hierarchy, the router can unambiguously determine where each of the 4 billion possible IP addresses are on the network just by looking at what subnet the IP will fall under in its table! The packet is then sent out that port.
As the packet travels through interconnected ISPs' routers, backbone infrastructure and so on, it arrives at Machine B's router, where the opposite process happens - router B sees that its destined for Machine B and sends it inbound. (Similarly, Router B will have to use a process like ARP to find Machine B's MAC address if not known.) The rest should be trivial from here.
good references:
https://web.archive.org/web/20120129120350/http://www.tildefrugal.net/tech/arp.php
http://en.wikipedia.org/wiki/Data_link_layer
http://en.wikipedia.org/wiki/Network_switch
http://en.wikipedia.org/wiki/Network_layer
http://en.wikipedia.org/wiki/Routing
http://en.wikipedia.org/wiki/Router_(computing)
http://en.wikipedia.org/wiki/Address_Resolution_Protocol
The only thing that can travel over a copper wire are pulses of electricity.
The binary number 1 is represented by a pulse of electricity or no pulse of electricity for 0.
Just keep in mind that real data of any kind cannot be sent over copper wire, fibre optic, or through the air ...only a representation of the data which has previously been converted to a 1 or a 0 and then is reconverted back at the receiving end.
Network layer protocol supervises the transmission of packets from a source machine to a destination. Data is broken down into packets, or datagrams, up to 64 kb long before it is transmitted, with a stamp of destination IP address, and forwarded to the network gateway. A gateway can be router to interconnect networks.
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?
Say, for example, that I'm part of a multicast group on 239.255.10.10. I'm also connected to two separate networks, one that has a 192.168.0.* and the other 192.168.1.* addressing. Both networks have a clients that is listening for incoming connections and are part of the above mentioned multicast group (because my client has it hardcoded).
When My computer sends out some data to that multicast group, will it be sent out on both networks or will there be some sort of error?
As long as those clients have registered interest in the group via IGMP, they should both receive the data. However, if there is a router between those networks that the multicast data must traverse, it needs to be configured to pass the data. If your computer is the one connected to both networks, it should just work.
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?