How a device will identify control and data packet? - networking

I think at L2 it will be ether type and destination MAC address.
at L3 it can be protocol field and Destination IP Address.
I want to know what are the other fields by which we can differentiate between control and data packet.

#Anupam Thakur: In pure L2 infrastructure, on receiving frame, node does the bridge-table/l2-table/cam lookup based on destination mac address. For different BPDUs (almost always reserved multicast mac dst addresses, few exceptions beyond the scope of this question) wherever required cam table is programmed with punt path to control-plane module (/also). Note, punt path doesn't distinguish between different protocols. It's job is to just push the packet in Q towards control-plane module. When cp module receives such packet, based on ethertype or LLC content it determines the further protocol processing of the packet.

"Router Alert Option" in IP header can also force packet to be punted to Control Plane, even though it is not destined for recipient device. (i.e. transit node)

Related

what is the real difference between the version field on the ip header and the type field in the ethernet header?

the version field in the IP header contains the version of the IP protocol used (IPv4/IPv6).
the type field in the Ethernet header contains which layer 3 protocol to forward the De-encapsulated packet to (IPv4, IPv6).
Why is it so important that the IP header have a field called "Version", what is it used for?
Networking protocols are designed in layered manner to reduce complexities and improve generalities. The IP layer is designed in such a way that each of system can have a suitable IP layer software to process the packets without worrying about how the packets are transferred. This way IP packets can be transported by ethernet layer or any other layer (e.g. FC or ATM) independent of the knowledge of layer below it. The IP processing software needs to know the version of IP and hence IP packets have that version.
The same layering concept applies to ethernet layer which can help in transporting not only IP packets but other type of packets (e.g. IPX) without knowing details about protocol that it is transporting. But the ethernet layer processing at each end should know what type of packets they are carrying, so that they can hand-over the packet to appropriate layer for further processing.
Because IP can be encapsulated in another (non-Ethernet) layer 2 protocol. The IP protocol does not mandate a specific lower layer protocol so it can not make assumption on information that is available at this layer (e.g. the upper layer protocol version number). So if the layer 2 protocol only specifies 'IP' as the next layer, you need the IP protocol version from the IP header to correctly process it.

Error in the tcp segment area inside a IP packet?

Inside an IP network IPv4 protocol is being used. When a datagram is being transported through the network (TTL=2), an error occurs inside the field which contains TCP-segment with the address of a web page. What will be the reaction of the router when reading such datagram?
I'm battling with this question for two days now.
What I know:
the router only reads the header of the datagram and if the checksum fails the datagram is being discarded by the router,
TTL is always decremented by one by the router if the header checksum is OK, after the -1, the datagram is being forwarded to the next router in the network
Based on this two points I conclude that the datagram will go further and TTL will be 1 and new checksum will be calculated by the router.
However there are three other possible answers to the questions:
The router sends ICMP to source with the error
the router repairs the mistake based on the header checksum and then forward the datagram
the router sends the datagram out of the network (discards the datagram)
Any help with clearing this problem?
The exact algorithms that must be implemented by IPv4 routers is described in RFC 1812 - Requirements for IP Version 4 Routers. According to the IETF RFC Index it still applies ("Status: BEST CURRENT PRACTICE").
The forwarding algorithm can be found in Section 5.2.1. The constraints determining the dependencies between the steps are (quoting):
(1) A router MUST verify the IP header, as described in section
[5.2.2], before performing any actions based on the contents of
the header. This allows the router to detect and discard bad
packets before the expenditure of other resources.
(2) Processing of certain IP options requires that the router
insert
its IP address into the option. [...]
(3) The router cannot check and decrement the TTL before checking
whether the packet should be delivered to the router itself, for
reasons mentioned in Section [4.2.2.9].
(4) More generally, when a packet is delivered locally to the
router,
its IP header MUST NOT be modified in any way [...].
The actual steps performed when receiving a packet are (quoting):
(1) The router receives the IP packet (plus additional information
about it, as described in Section [3.1]) from the Link Layer.
(2) The router validates the IP header, as described in Section
[5.2.2]. Note that IP reassembly is not done, except on IP
fragments to be queued for local delivery in step (4).
(3) The router performs most of the processing of any IP options.
As
described in Section [5.2.4], some IP options require additional
processing after the routing decision has been made.
(4) The router examines the destination IP address of the IP
datagram, as described in Section [5.2.3], to determine how it
should continue to process the IP datagram. There are three
possibilities:
o The IP datagram is destined for the router, and should be
queued for local delivery, doing reassembly if needed.
o The IP datagram is not destined for the router, and should be
queued for forwarding.
o The IP datagram should be queued for forwarding, but (a copy)
must also be queued for local delivery.
So it is clear that checksum verification of the IPv4 header is performed first. The exact steps are described in Section 5.2.2 IP Header Validation, but they are not important here. What matters is that only the IP header is checked, not the content. Therefore the router cannot detect the error.
Based on this two points I conclude that the datagram will go further and TTL will be 1 and new checksum will be calculated by the router.
Correct.
As for the other options:
The router sends ICMP to source with the error
No, there is no Time Exceeded error. As for other ICMP errors, there are none that signal to the sender packet corruption. So even if the router could detect packet corruption (say if the corrupted bit was in the IP header), it would still not send an ICMP message.
The router repairs the mistake based on the header checksum and then forward the datagram
No, the checksumming performed in IPv4 and TCP only allows error detection, not correction.
The router sends the datagram out of the network (discards the datagram)
It does not discard it because it does not detect the error.
Regarding what I said in the comment about link layer error detection, there are usually two sources of errors in transit: (1) from the transmission medium (interference, damaged cable, improperly connected plug etc.) and (2) from forwarding devices themselves (defective memory chips, firmware bugs, cosmic rays hitting a chip etc.). The link layer can usually detect and may even correct errors from (1), but obviously not from (2). So the scenario described in the question is indeed possible if a device malfunction corrupted the packet contents.

Packet switching vs fragmentation at ip layer

packet switching is a protocol, where a message received from tcp layer is divided into packets only at sender machine ip layer and each packet is sent individually on different routes with an identification field set in ip header to help use re-assemble at destination machine.
Where as
fragmentation at ip layer is done on sender machine or any of the, on the way layer 3 device ip layer and fragmentation field is set in ip header to help use re-assemble at destination machine only.
My question:
is my understanding correct?
In packet switching, If message could not be re-assembled due to missing packet at destination, based on identification field, that message is discarded at ip layer of destination machine and tcp layer of sender machine will take care of retransmission of that message, am i correct?
packet switching is a protocol
No. Packet switching is an alternative to circuit switching at the physical layer.
where a message received from tcp layer is divided into packets only at sender machine ip layer and each packet is sent individually on different routes with an identification field set in ip header to help use re-assemble at destination machine.
None of this is correct as a description of packet switching. Packet switching implies the existence of packets, period. It doesn't impose any of these constraints.
Whereas fragmentation at ip layer is done on sender machine or any of the
... intermediate nodes
on the way layer 3 device ip layer
Layer 2
and fragmentation field is set in ip header to help use re-assemble at destination machine only.
My question:
is my understanding correct?
No. You seem to think that packet switching and fragmentation are in some kind of opposition. They aren't. Fragmentation is an extension of packet switching if anything, not an alternative to it.
In packet switching, If message could not be re-assembled due to missing packet at destination, based on identification field, that message is discarded at ip layer of destination machine and tcp layer of sender machine will take care of retransmission of that message, am i correct?
No. Again you're confused about what packet switching is. Your remark applies pretty well to TCP, but that's because of the semantics of TCP, not because of packet switching.

How does a packet travel from one computer to another over the Internet based on OSI model

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.

What is local per flow state

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

Resources