Blog, Blogger, Computer, Data Transmissions, Internet, Life, Linux, Linux Software, Live Blogging, Malaysia, Money, My Life, Unifi

Unifi Update DNS on TRG212M router

23 Comments

Unifi Update DNS on TRG212M router

To all the Unifi user, by default your router is not allowed user to update the DNS setting. and its not visible by admin account.

Here is the step you can follow to change your DNS setting

1. Login to the router using below credentials

  • Username:  operator
  • Password (default unifi password ):  h566UniFi

2. Go to Setup Tab
3. Click on the WAN at the left

Unifi Update DNS on TRG212M router

4. On the 1_INTERNET_R Click on the edit button in red circle (as per picture) – edit – Credit DE SOPHEA

5.  On the DNS setting tick on Manual radio button and configure your DNS to Google DNS

  • Primary: 8.8.8.8
  • Secondary: 8.8.4.4

6. Apply the setting

Uneeetitled

Data Transmissions

Controlling Broadcasts and Multicasts

104 Comments

Controlling Broadcasts and Multicasts

Introduction

The first step in controlling broadcast and multicast traffic is to identify which devices are involved in a broadcast or multicast storm. The following protocols can send broadcast or multicast packets:

  • Address Resolution Protocol (ARP)
  • Open Shortest Path First (OSPF)
  • IP Routing Information Protocol Version 1 (RIP1)
  • Service Advertising Protocol (SAP)
  • IPX Routing Information Protocol (RIP)
  • NetWare Link Services Protocol (NLSP)
  • AppleTalk Address Resolution Protocol (AARP)

After identifying the source of the broadcast or multicast storm, you must examine the packets to find out which protocol or application triggered the broadcast or multicast storm. For example, if a single device is responsible for a broadcast storm, you can examine the device’s broadcast traffic to determine exactly what the device was doing. For example, you can find out what the device was looking for or what the device was announcing.

Broadcast or multicast storms are often caused by a fault that occurs during the device discovery process. For example, if an IPX-based printing environment has been misconfigured, a print driver client may continually send SAP packets to locate a specific print server. Unanswered broadcast or multicast requests usually indicate that a device is missing or has been misconfigured.

Examine the broadcast traffic on your company’s network. Do you see numerous unanswered, repeat queries? Do you see protocols (such as IP RIP1, SAP, and IPX RIP) that just “blab” all day even when no other devices may be listening?

Or, is the majority of the broadcast and multicast traffic on your company’s network purposeful? That is, does the broadcast and multicast traffic have a request-reply communication pattern? For example, are broadcast lookups answered?

Do broadcast packets contain meaningful information? For example, if a network has numerous routers, do broadcast packets contain routing update information?

Is the broadcast rate acceptable? Does your company’s network need RIP updates every 30 seconds, or can you increase the interval to one minute?

BROADCAST/MULTICAST DOMAINS

If your company’s network is experiencing excessive broadcast or multicast traffic, you should also check the scope of the broadcast or multicast domain. (A broadcast or multicast domain is the range of devices that are affected by a broadcast or a multicast packet.) Understanding broadcast and multicast domains can help you determine how harmful a broadcast storm can be from any point on the network.

The scope of a broadcast and multicast domain depends, to some degree, on the network design. For example, the picture below shows two networks, a switched network and a routed network:

On a switched network, Device 1 sends a broadcast or multicast packet that is propagated to all ports of the switch. (A typical layer-2 switch does not filter either broadcast or multicast traffic.)

On a routed network, however, a router does not forward broadcast traffic. If Device 1 sends a broadcast packet, only Device 2 and the router see the broadcast packet. If appropriate, the router processes the broadcast packet and sends a reply. Because the broadcast packet is not forwarded, it does not affect Devices 3 or 4.

Source & Credit to : http://www.firewall.cx/

Data Transmissions

Data Transmission – Broadcast

8 Comments

Data Transmission – Broadcast

Introduction

The term “Broadcast” is used very frequently in the networking world . You will see it in most networking books and articles, or see it happening on your hub/switch when all the LED’s start flashing at the same time !

If you have been into networking for a while you most probably have come across the terms “broadcast” and “subnet broadcast” . When I first dived into the networking world, I was constantly confused between the two, because they both carried the “broadcast” term in them. We will analyse both of them here, to help you understand exactly what they are and how they are used !

Broadcast

A Broadcast means that the network delivers one copy of a packet to each destination. On bus technologies like Ethernet, broadcast delivery can be accomplished with a single packet transmission. On networks composed of switches with point-to-point connections, software must implement broadcasting by forwarding copies of the packet across individual connections until all switches have received a copy. We will be focusing only on Ethernet broadcasts.

The picture below illustrates a router which has sent a broadcast to all devices on its network:

Normally, when the computers on the network receive a packet, they will first try to match the MAC address of the packet with their own and if that is successful, they process the packet and hand it to the OSI layer above (Network Layer), if the MAC address is not matched, then the packet is discarded and not processed. However, when they see a MAC address of FF:FF:FF:FF:FF:FF, they will process this packet because they recognise it as a broadcast.

But what does a “broadcast” look like ?

Check out the image below, which is taken from my packet sniffer:

Let’s now have a closer look at the above packet:
The image above shows a broadcast packet. You can clearly see that the “MAC destination address” is set to FF:FF:FF:FF:FF:FF. The “Address IP destination” is set to 255.255.255.255, this is the IP broadcast address and ensures that no matter what IP address the receiving computer(s) have, they will not reject the data but process it.

Now you might ask yourself “Why would a workstation want to create a broadcast packet ?”

The answer to that lies within the various protocols used on our networks !

Let’s take for example Address Resolution Protocol, or ARP. ARP is used to find out which MAC address (effectively , which network card or computer) has a particular IP address bound to it. You will find a detailed example of the whole process in the IP Routing section.

For a network device such as a router to ask “Who has IP address 192.168.0.100 ? “, it must “shout” it out so it can grab everyone’s attention, which is why it will use a broadcast to make sure everyone listens and processes the packet on the network.

In the example image above, the particular machine was looking for a DHCP server (notice the “bootps” protocol under the UDP Header – Layer 4, which is basically DHCP).

Subnet Broadcast or Direct Broadcast

A Subnet or Direct broadcast is targetted not to all hosts on a network, but to all hosts on a subnet. Since a physical network can contain different subnets/networks e.g 192.168.0.0 and 200.200.200.0, the purpose of this special broadcast is to send a message to all the hosts in a particular subnet.

In the example below, Router A sends a subnet broadcast onto the network. Hosts A,B,C and the Server are configured to be part of the 192.168.0.0 network so they will receive and process the data, but Host D is configured with a different IP Adress, so it’s part of a different network, it will accept the packet cause of its broadcast MAC address, but will drop the packet when it reaches its Network Layer, where it will see that this packet was for a different IP network.

It is very similar to the network broadcast we just talked about but varies slightly in the sense that its IP broadcast is not set to 255.255.255.255 , but is set to the subnet broadcast address. For example, my home network is a Class C network : 192.168.0.0 with a subnetmask of 255.255.255.0 or, if you like to keep it simple, : 192.168.0.0/24.

This means that the available valid hosts for this network are from 192.168.0.1 to 192.168.0.254. In this Class C network, as in every other network, there are 2 addresses which I can’t use. The first one is preserved to identify the network (192.168.0.0) and the second one for the subnet broadcast (192.168.0.255).

The above packet, captured from my packet sniffer, shows my workstation broadcasting to the subnet 192.168.0.0. From the broadcast address you can tell that I am using a full Class C network range, otherwise the Destination IP wouldn’t be 192.168.0.255.

The Packet decoder on the right shows you the contents of each header from the above packet.

Looking at the MAC Header (Datalink Layer), the destination MAC address is set to FF:FF:FF:FF:FF:FF and the IP Header (Network Layer) has the Destination IP set to 192.168.0.255 which is, as I said, the Subnet Broadcast Address. Again, all computers on the network which are part of the 192.168.0.0 subnet will process this packet, the rest will drop the packet once they see it’s for a network to which they do not belong.

In this example, I double clicked at my “Network Places” and was searching for a computer, this forced my workstation to send out a Subnet Broadcast on the network asking if a particular computer existed on the network.

And that just about does it for the broadcasting section !

Source & Credit to : http://www.firewall.cx/

Data Transmissions

Multicast IP List

62 Comments

Multicast IP List

Introduction

This page contains all the Multicast IP Addresses and shows what protocol they are mapped to. Should you ever use a packet sniffer to try and see what’s on the network and you capture a packet with a destination IP Address of 224.X.X.X, then simply look up this list and you will know what the purpose of that packet was 🙂

Internet Multicast Addressess

Host Extensions for IP Multicasting [RFC1112] specifies the extensions required of a host implementation of the Internet Protocol (IP) to support multicasting. Current addresses are listed below.

The range of addresses between 224.0.0.0 and 224.0.0.255, inclusive, is reserved for the use of routing protocols and other low-level topology discovery or maintenance protocols, such as gateway discovery and group membership reporting. Multicast routers should not forward
any multicast datagram with destination addresses in this range, regardless of its TTL.

224.0.0.0 Base Address (Reserved) [RFC1112,JBP]
224.0.0.1 All Systems on this Subnet [RFC1112,JBP]
224.0.0.2 All Routers on this Subnet [JBP]
224.0.0.3 Unassigned [JBP]
224.0.0.4 DVMRP Routers [RFC1075,JBP]
224.0.0.5 OSPFIGP OSPFIGP All Routers [RFC1583,JXM1]
224.0.0.6 OSPFIGP OSPFIGP Designated Routers [RFC1583,JXM1]
224.0.0.7 ST Routers [RFC1190,KS14]
224.0.0.8 ST Hosts [RFC1190,KS14]
224.0.0.9 RIP2 Routers [RFC1723,GSM11]
224.0.0.10 IGRP Routers [Dino Farinacci]
224.0.0.11 Mobile-Agents [Bill Simpson]
224.0.0.12 DHCP Server / Relay Agent [RFC1884]

224.0.0.12 – 224.0.0.255 Unassigned [JBP]

224.0.1.0 VMTP Managers Group [RFC1045,DRC3]
224.0.1.1 NTP Network Time Protocol [RFC1119,DLM1]
224.0.1.2 SGI-Dogfight [AXC]
224.0.1.3 Rwhod [SXD]
224.0.1.4 VNP [DRC3]
224.0.1.5 Artificial Horizons – Aviator [BXF]
224.0.1.6 NSS – Name Service Server [BXS2]
224.0.1.7 AUDIONEWS – Audio News Multicast [MXF2]
224.0.1.8 SUN NIS+ Information Service [CXM3]
224.0.1.9 MTP Multicast Transport Protocol [SXA]
224.0.1.10 IETF-1-LOW-AUDIO [SC3]
224.0.1.11 IETF-1-AUDIO [SC3]
224.0.1.12 IETF-1-VIDEO [SC3]
224.0.1.13 IETF-2-LOW-AUDIO [SC3]
224.0.1.14 IETF-2-AUDIO [SC3]
224.0.1.15 IETF-2-VIDEO [SC3]
224.0.1.16 MUSIC-SERVICE [Guido van Rossum]
224.0.1.17 SEANET-TELEMETRY [Andrew Maffei]
224.0.1.18 SEANET-IMAGE [Andrew Maffei]
224.0.1.19 MLOADD [Braden]
224.0.1.20 any private experiment [JBP]
224.0.1.21 DVMRP on MOSPF [John Moy]
224.0.1.22 SVRLOC [Veizades]
224.0.1.23 XINGTV
224.0.1.24 microsoft-ds
224.0.1.25 nbc-pro
224.0.1.26 nbc-pfn
224.0.1.27 lmsc-calren-1 [Uang]
224.0.1.28 lmsc-calren-2 [Uang]
224.0.1.29 lmsc-calren-3 [Uang]
224.0.1.30 lmsc-calren-4 [Uang]
224.0.1.31 ampr-info [Janssen]
224.0.1.32 mtrace [Casner]
224.0.1.33 RSVP-encap-1 [Braden]
224.0.1.34 RSVP-encap-2 [Braden]
224.0.1.35 SVRLOC-DA [Veizades]
224.0.1.36 rln-server [Kean]
224.0.1.37 proshare-mc [Lewis]
224.0.1.38 – 224.0.1.255 Unassigned [JBP]

224.0.2.1 “rwho” Group (BSD) (unofficial) [JBP]
224.0.2.2 SUN RPC PMAPPROC_CALLIT [BXE1]

224.0.3.000-224.0.3.255 RFE Generic Service [DXS3]
224.0.4.000-224.0.4.255 RFE Individual Conferences [DXS3]
224.0.5.000-224.0.5.127 CDPD Groups [Bob Brenner]
224.0.5.128-224.0.5.255 Unassigned [IANA]
224.0.6.000-224.0.6.127 Cornell ISIS Project [Tim Clark]
224.0.6.128-224.0.6.255 Unassigned [IANA]
224.0.7.000-224.0.7.255 Where-Are-You [Simpson]
224.0.8.000-224.0.8.255 INTV [Tynan]
224.0.9.000-224.0.9.255 Internet Railroad [Malamud]

224.1.0.0-224.1.255.255 ST Multicast Groups [RFC1190,KS14]
224.2.0.0-224.2.255.255 Multimedia Conference Calls [SC3]

224.252.0.0-224.255.255.255 DIS transient groups [Joel Snyder]

232.0.0.0-232.255.255.255 VMTP transient groups [RFC1045,DRC3]

These addresses are listed in the Domain Name Service under MCAST.NET
and 224.IN-ADDR.ARPA.

Note that when used on an Ethernet or IEEE 802 network, the 23
low-order bits of the IP Multicast address are placed in the low-order
23 bits of the Ethernet or IEEE 802 net multicast address
1.0.94.0.0.0. See the section on “IANA ETHERNET ADDRESS BLOCK”.

REFERENCES

[RFC1045] Cheriton, D., “VMTP: Versatile Message Transaction
Protocol Specification”, RFC 1045, Stanford University,
February 1988.

[RFC1075] Waitzman, D., C. Partridge, and S. Deering “Distance Vector
Multicast Routing Protocol”, RFC-1075, BBN STC, Stanford
University, November 1988.

[RFC1112] Deering, S., “Host Extensions for IP Multicasting”,
STD 5, RFC 1112, Stanford University, August 1989.

[RFC1119] Mills, D., “Network Time Protocol (Version 1), Specification
and Implementation”, STD 12, RFC 1119, University of
Delaware, July 1988.

[RFC1190] Topolcic, C., Editor, “Experimental Internet Stream
Protocol, Version 2 (ST-II)”, RFC 1190, CIP Working Group,
October 1990.

[RFC1583] Moy, J., “The OSPF Specification”, RFC 1583, Proteon,
March 1994.

[RFC1723] Malkin, G., “RIP Version 2: Carying Additional Information”,
RFC 1723, Xylogics, November 1994.

[RFC1884] Hinden, R., and S. Deering, “IP Version 6 Addressing
Architecture”, RFC 1884, Ipsilon Networks, Xerox PARC,
December 1995.

Source & Credit to : http://www.firewall.cx/

Data Transmissions

Introduction To Multicast

No Comments

Introduction To Multicast

Introduction

To understand what we are going to talk about, you must be familiar with how MAC addresses are structured and how they work. The MAC Addresses page is available to help you learn more about them..

A multicast is similar to a broadcast in the sense that its target is a number of machines on a network, but not all. Where a broadcast is directed to all hosts on the network, a multicast is directed to a group of hosts. The hosts can choose whether they wish to participate in the multicast group (often done with the Internet Group Management Protocol), whereas in a broadcast, all hosts are part of the broadcast group whether they like it or not :).

As you are aware, each host on an Ethernet network has a unique MAC address, so here’s the million dollar question: How do you talk to a group of hosts (our multicast group), where each host has a different MAC address, and at the same time ensure that the other hosts, which are not part of the multicast group, don’t process the information ? You will soon know exactly how all this works.

To keep things in perspective and make it easy to understand, we are going to concentrate only on an Ethernet network using the IP protocol, which is what 80-90 % of home networks and offices use.

Breaking things down…

In order to explain Multicasting the best I can and to make it easier for you understand, I decided to break it down into 3 sections:

1) Hardware/Ethernet Multicasting

2) IP Multicasting

3) Mapping IP Multicast to Ethernet Multicast

A typical multicast on an Ethernet network, using the TCP/IP protocol, consists of two parts: Hardware/Ethernet multicast and IP Multicast. Later on I will talk about Mapping IP Multicast to Ethernet Multicast which is really what happens with multicasting on our Ethernet network using the TCP/IP protocol.

The brief diagram below shows you the relationship between the 3 and how they complete the multicasting model:

Hardware/Ethernet Multicasting

When a computer joins a multicast group, it needs to be able to distinguish between normal unicasts (which are packets directed to one computer or one MAC address) and multicasts. With hardware multicasting, the network card is configured, via its drivers, to watch out for particular MAC addresses (in this case, multicast MAC addresses) apart from its own. When the network card picks up a packet which has a destination MAC that matches any of the multicast MAC addresses, it will pass it to the upper layers for further processing.

And this is how they do it :

Ethernet uses the low-order bit of the high-order octet to distinguish conventional unicast addresses from multicast addresses. A unicast would have this bit set to ZERO (0), whereas a multicast would be set to ONE (1)

To understand this, we need to analyse the destination MAC address of a unicast and multicast packet, so you can see what we are talking about:

When a normal (unicast) packet is put on the network by a computer, it contains the Source and Destination MAC address, found in the 2nd Layer of the OSI model. The following picture is an example of my workstation (192.168.0.6) sending a packet to my network’s gateway (192.168.0.5):

Now let’s analyse the destination MAC address:

When my gateway receives the packet, it knows it’s a unicast packet as explained in the above picture.

Let’s now have a look at the MAC address of a multicast packet. Keep in mind, a multicast packet is not directed to one host but a number of hosts, so the destination MAC address will not match the unique MAC address of any computer, but the computers which are part of the multicast group will recognise the destination MAC address and accept it for processing.

The following multicast packet was sent from my NetWare server. Notice the destination MAC address (it’s a multicast):

Analysis of a multicast destination MAC address:

So now you should be able to understand how computers can differentiate between a normal or unicast packet and a multicast packet. Again, the destination MAC address 01-00-5E-00-00-05 is not the MAC address of a particular host-computer but the MAC address that can be recognised by computers that are part of the multicast group. I should also note that you will never find a source address that is a multicast MAC address, the source address will always be a real one, to identify which computer the packet came from.

The IEEE group used a special Rule to determine the various MAC addresses that will be considered for multicasting. This Rule is covered in the last section of this page, but you don’t need to know it now in order to understand Hardware multicasting. Using this special rule it was determined that MAC address 01:00:5E:00:00:05 will be used for the OSP
F protocol, which happens to be a routing protocol, and then this MAC address also maps to an IP address which is analysed in IP Multicast.

IP Multicast

The IP Multicast is the second part of multicasting which, combined with the hardware multicasting, gives us a multicasting model that works for our Ethernet network. If hardware multicasting fails to work, then the packet will never arrive at the network layer upon which IP multicasting is based, so the whole model fails.

With IP multicasting the hardware multicasting MAC address is mapped to an IP Address. Once Layer 2 (Datalink) picks the multicast packet from the network (because it recognises it, as the destination MAC address is a multicast) it will strip the MAC addresses off and send the rest to the above layer, which is the Network Layer. At that point, the Network Layer needs to be able to understand it’s dealing with a multicast, so the IP address is set in a way that allows the computer to see it as a multicast datagram. A host may send multicast datagrams to a multicast group without being a member.

Multicasts are used a lot between routers so they can discover each other on an IP network. For example, an Open Shortest Path First (OSPF) router sends a “hello” packet to other OSPF routers on the network. The OSPF router must send this “hello” packet to an assigned multicast address, which is 224.0.0.5, and the other routers will respond.

IP Multicast uses Class D IP Adresses:

Let’s have a look at an example so we can understand that a bit better:

The picture below is a screenshot from my packet sniffer, it shows a multicast packet which was sent from my NetWare server, notice the destination IP address:

The screenshot above shows the packet which was captured, it’s simply displaying a quick summary of what was caught. But, when we look on the left we see the above packet in much more detail.

You can clearly see the markings I have put at the bottom which show you that the destination IP for this packet is IP Address 224.0.0.5. This corresponds to a multicast IP and therefore is a multicast packet.

The MAC header also shows a destination MAC address of 01-00-5E-00-00-05 which we analysed in the previous section to show you how this is identified as a multicast packet at Layer 2 (Datalink Layer).

Some examples of IP multicast addresses:

224.0.0.0 Base Address (Reserved) [RFC1112,JBP]
224.0.0.1 All Systems on this Subnet [RFC1112,JBP]
224.0.0.2 All Routers on this Subnet [JBP]
224.0.0.3 Unassigned [JBP]
224.0.0.4 DVMRP Routers [RFC1075,JBP]
224.0.0.5 OSPFIGP OSPFIGP All Routers [RFC2328,JXM1]

Remember that these IP Addresses have been assigned by the IEEE !

Now all that’s left is to explain how the IP multicast and MAC multicast map between each other…

Mapping IP Multicast to Ethernet Multicast

The last part of multicast which combines the Hardware Multicasting and IP Multicasting is the Mapping between them. There is a rule for the mapping, and this is it:

To map an IP Multicast address to the corresponding Hardward/Ethernet multicast address, place the low-order 23 bits of the IP multicast address into the low-order 23 bits of the special Ethernet multicast address. The rest of the high-order bits are defined by the IEEE (yellow colour in the example)

The above rule basically determines the Hardware MAC address. Let’s have a look at a real example to understand this.

We are going to use Multicast IP Address 224.0.0.5 – a multicast for the OSPF routing protocol. The picture below shows us the analysis of the IP address in binary so we can clearly see all the bits:

It might seem a bit confusing at first, but let’s break it down:

We have an IP Address of 224.0.0.5, this is then converted into binary so we can clearly see the mapping of the 23 bits to the MAC address of the computer. The MAC Address part which is in yellow has been defined by the IEEE group. So the yellow and pink line make the one MAC Address as shown in binary mode, then we convert it from binary to hex and that’s about it !

NOTE

You should keep in mind that multicast routers should not forward any multicast datagram with destination addresses in the following 224.0.0.0 and 224.0.0.255. The next page (multicasting list) gives a bit more information on this.

This just about does it for multicasting !

Source & Credit to : http://www.firewall.cx/

Data Transmissions

Unicast

16 Comments

Unicast

Introduction

Compaired to broadcasts and Multicasts, a Unicast is very simple and one of the most common data transmissions in a network.

The Reason for Unicast

Well it’s pretty obvious why they came up with Unicasts, imagine trying to send data between 2 computers on a network, using broadcasts ! All you would get would be a very slow transfer and possibly a conjested network with low bandwidth availability.

Data transfers are almost all of the times, unicasts. You have the sender e.g a webserver and the receiver e.g a workstation. Data is transfered between these two hosts only, where as a broadcast or a multicast is destined either everyone or just a group of computers.

In example above, my workstation sends a request to the Windows 2000 Server. The request is a simple Unicast because it’s directed to one machine (the server) and nothing else. You just need to keep in mind that because we are talking about a Ethernet network, the traffic, hence the packets, are seen by all machines (in this case the Linux Server aswell) but they will not process them once they see that the destination MAC address in the packets do not match their own and are also not set to FF:FF:FF:FF:FF:FF which would indicate that the packet is a broadcast.

There really isn’t much more to say for Unicasts… so I guess i’ll stop right here 🙂

Source & Credit to : http://www.firewall.cx/

Data Transmissions

Media Access Control – MAC Addresse

4 Comments

Media Access Control – MAC Addresses

Introduction

Media Access Control (MAC) addresses are talked about in various sections on the site, such as the OSI-Layer 2, Multicast, Broadcast and Unicast. We are going to analyse them in depth here so we can get a firm understanding of them since they are part of the fundamentals of networking.

MAC addresses are physical addresses, unlike IP addresses which are logical addresses. Logical addresses require you to load special drivers and protocols in order to be able to configure your network card/computer with an IP Address, whereas a MAC address doesn’t require any drivers whatsoever. The reason for this is that the MAC address is actually “burnt-in” into your network card’s memory chipset.

The Reason for MAC

Each computer on a network needs to be identified in some way. If you’re thinking of IP addresses, then you’re correct to some extent, because an IP address does identify one unique machine on a network, but that is not enough. Got you mixed up?

Check the diagram and explanation below to see why :

You see, the IP address of a machine exists on the 3rd Layer of the OSI model and, when a packet reaches the computer, it will travel from Layer 1 upwards, so we need to be able to identify the computer before Layer 3.

This is where the MAC address – Layer 2 comes into the picture. All machines on a network will listen for packets that have their MAC address in the destination field of the packet (they also listen for broadcasts and other stuff, but that’s analysed in other sections). The Physical Layer understands the electrical signals on the network and creates the frame which gets passed to the Datalink layer. If the packet is destined for the computer then the MAC address in the destination field of the packet will match, so it will accept it and pass it onto the Layer above (3) which, in turn, will check the network address of the packet (IP Address), to make sure it matches with the network address to which the computer has been configured.

Looking at a MAC

Let’s now have a look at a MAC address and see what it looks like! I have taken my workstations MAC address as an example:

When looking at a MAC address, you will always see it in HEX format. It is very rare that a MAC address is represented in Binary format because it is simply tooooo long as we will see futher on.

When a vendor, e.g Intel, creates network cards, they don’t just give them any MAC address they like, this would create a big confusion in identifying who created this network card and could possibly result in clashing with another MAC address from another vendor e.g D-link, who happened to choose the same MAC address for one of their network cards !

To make sure problems like this are not experienced, the IEEE group split the MAC address in half, and used the first half to identify the vendor, and the second half is for the vendor to allocate as serial numbers:

The Vendor code is specified by RFC – 1700. You might find a particular vendor having more than just one code; this is because of the wide range of products they might have. They just apply for more, as they need !

Keep in mind that even tho the MAC address is “burnt-in” to the network card’s memory, some vendors will allow you to download special programs to change the second half of the MAC address on the card. This is because the vendors actually reuse the same MAC addresses for their network cards because they create so many that they run out of numbers ! But at the same time, the chances of you buying two network cards which have the same MAC address are so small that it’s almost impossible !

Let’s start talking bits and bytes!

Now that we know what a MAC address looks like, we need to start analysing it. A MAC address of any network card is always the same length, that is, 6 Bytes long or 48 Bits long. If you’re scratching your head wondering where these figures came from, then just have a look at the picture below which makes it a bit easier to understand:

So that completes the discussion regarding MAC Addresses! I hope you have understood it all because it’s very important so you can expand your knowledge and truly understand what happens in a network !

Source & Credit to : http://www.firewall.cx/

Data Transmissions

Data Transmissions

41 Comments

Introduction To Data Transmission

Introduction

Routable protocols enable the transmission of data between computers in different segments of a network. However, high volumes of certain kinds of network traffic can affect network efficiency because they slow down transmission speed. The amount of network traffic generated varies with the 3 types of data transmissions:

  • Broadcast
  • Multicast
  • Unicast

We are going to have a look at each one of these data transmissions because it’s very important to know the type of traffic they generate, what they are used for and why they exist on the network.

Source & Credit to : http://www.firewall.cx/

Before we proceed, please note that understanding the OSI Model (especially Layer 2 and 3), Ethernet and the way a packet is structured is fundamental to understanding a broadcast, multicast or unicast.

Close Menu