Unicast Addresses: Unique-Local. Before we talk about Unique-Local Addresses (ULA), let me tell you about Site-Local addresses; it was deprecated in favor of the ULA back in 2004 because the term “site” was too ambiguous, no body agreed upon a clear definition of the term “site”; what was considered a “Site”? Also, the provability of Site-Local address being globally unique were no that high, as opposed to ULAs. ULAs are meant to be routed within an organization's LAN or even WAN, but they are not routable over the public network (Internet), hence, you can think of ULAs very much as IPv4's Private addresses. A ULA is identified by the first 7 bits of the address which are 1 1 1 1 1 1 0 and that is FC00 in hex. The 8 th bit, called the “L” bit, is set to 1 if the Global ID was Locally assigned, meaning that is was generated by the organization. As we will see just ahead, the Global ID is always generated by the organization, so the “L” bit will always be set to 1 and the “L” bit set to 0 is reserved for future usage, hence, the address we will see is 1 1 1 1 1 1 0 1 (FD00::/8). Notice that after the 8 th bit, there is another 40bits field called the Global ID, and this field is randomly generated by the organization to assure high probabilities of a unique Network Prefix, even globally. Section 3.2–Global ID of the RFC 4193–Unique-Local IPv6 Address, recommends that this field NOT be generated in a sequential fashion to prevent any allocation relationship between Global IDs, instead, it should be randomly generated following the steps described in section 3.2.2 of the RFC. Let's see an example of a ULA Prefix: Special IPv6 Addresses. Unspecified Address . This address is represented as 0:0:0:0:0:0:0:0 or just :: and it is very similar to the unspecified IPv4 address 0.0.0.0. It is used as a “place holder” if you will; for example, as you know, when an interface gets IPv6 enabled, it gets an auto-assigned Link-Local address, but first, it needs to make sure that this address has not been assigned to another interface already. So to do this, it uses a process called Duplicate Address Detection (DAD) as part of the Auto-configuration process, and during this process, the interface sends out a packet called Neighbor Solicitation (NS) message to the All-Nodes multicast address of FF20::1 “asking” if this particular address is being used by another interface already on the network, the source address on this packet will be all zeroes or :: which is the unspecified address (more details on auto-configuration and DAD later). Loopback Address. The Loopback address is very similar to and used for the same purpose as the 127.0.0.1 Loopback address in IPv4, but it is represented in IPv6 by all zeroes and a 1, like this; 0:0:0:0:0:0:0:1 or just ::1. An example of its usage will be when there is an issue on the network and we want to make sure that a particular interface is working properly, we can send a PING packet to the interface's Loopback address of ::1 (pinging itself) and if we get a reply, it means that the TCP/IP stack in this interface is working properly... the issue is somewhere else.. :O) The picture below shows that this interface is ready to exchange packets in a TCP/IP network. The ping packets went through the TCI/IP stack, (Application down to Physical), looped around and went through the TCP/IP stack again (Physical up to Application): Multicast Addresses. Every type of IPv6 addresses we've discussed so far, have been Unicast addresses, let's move on now to the Multicast address. Let me get this important aspect of a Multicast address out of the way; The Multicast address type replaces IPv4's Broadcast , but the way it works makes it much more efficient then a Broadcast . There, let's continue now. A Multicast address represent s a Multicast Group and interfaces that need to recieve this traffic, will be automatically joined into these Multicast Groups. It is   one-to-many  communication, so a packet sent to a Multicast address will be received by all the interfaces that have been automatically joined into the Multicast group, which this Multicast address represents. These Multicast addresses are predefined and well-known (I'll show you a table in just a bit), and an interface is automatically joined to different, well-known multicast groups as needed. For example, as we already know, when we enable an interface for IPv6, a Link-Local address is assigned to it, but also, the interface will join a couple of well-known multicast groups; FF02::1 (All-Nodes) and FF02::2 (All-Routers). These well-known and predefined Multicast addresses represent a Multicast Group; FF02::1 represents all IPv6 enable devices on the network and FF02::2 represents all the IPv6 routers on the network. This means that when an interface sends out a packet to the multicast address FF02::1, every single device will receive and process the packet, and if the packet is sent to FF02::2, every router will receive and process the packet. As you can see, the All-Nodes FF02::1 Multicast address works much like a Broadcast, but remember, in order for a device to receive this packet it must be joined into the All-Nodes Multicast Group and the interface will be joined into the Multicast group if needed. If it is not joined, then it will not receive the packet at all. This is the main difference between the All-Nodes Multicast address and a Broadcast from IPv4. Note: There is a third well-known multicast group that the interface gets joined into, that is the Solicited-Node multicast group and we'll talk about this just ahead. The predefined, well-known address groups are: Let's see how an interface is joined into a multicast group: https://youtu.be/HcTVHE13zV8 Multicast Address Format . An IPv6 Multicast address is very easy to recognize; it is represented by the first 8 most significant bits set to 1111 1111, that's FF in hex so, any address that starts with FF is a multicast address. Further more, the next 8 bits (8 th through 15 th ) are divided into two fields; Flag and Scope, respectively: Picture from http://www.cisco.com/c/en/us/td/docs/security/fwsm/fwsm40/configuration/guide/fwsm_cfg/ports_f.html#wp1045362 Without going into much detail about the Flag and Scope fields because it is not a CCNA topic, you should know that the Flag field is 4 bits long and it represents the 3 rd hex digit of the address. If the Flag field is a 0 (in hex of course), it means that the address is permanently assigned (a predefined, well-known multicast address), and if it is a 1, it is a temporary or transient address. This indicated that a well-known multicast address will always start with FF0, and that is true. The Scope field, also 4 bits long, provides for 15 different possibilities, the most important are 1, 2, 4, 5, 8 and E, they indicate; Node, Link, Admin, Site, Organization or Global scope, respectively. Now, let's pay attention to the well-known multicast addresses table above. Notice that the 4 th hex digit on all the addresses (except the last one) is a 2, this indicates (look at the picture above), that the scope for these addresses is link-local, that is, within the link/segment. In contrast, look at the last well-known address, its 4 th hex digit is a 5, indicating that the scope is site -local , the LAN, and it makes sense because, in this case, an NTP server controls the time settings for all network devices that use its services, not just the ones directly connected, on the same link. Solicited-Node Address . Before we get into how the Solicited-Node address is used, let's find out about its format and where it comes from. The Solicited-Node address is constructed by combining a predefined 104 bit prefix; FF02::1:FF and the 24 least significant bits from the interface's Unicast address (or address es ) . For example, let's say that the Unicast address in this case is a Link-Local address of FE80::AAAA:BBBB:123A:A321; the process will take the last 6 hex digits of the address, 3A:A321 (that's 24 bits) and append them to the predefined FF02::1:FF/ 104 prefix, so the interface's complete Solicited-Node address will be FF02::1:FF3A:A321. The picture below demonstrates this: Now, I will ask you a question and give you the answer on the following video, but try to answer the question before watching the video, so you can check your understanding. ;O) Question : If the Link-Local address assigned to an interface is FE80::3B:ED49:CA22:1, what will be the Solicited-Node address linked to this Link-Local address? https://youtu.be/ojaad_Nhp3E What is a Solicited-Node address used for? We said that when a host's gets its Link-Local address (or any other Unicast address) it is automatically joined into the All-Nodes, All-Routers and the Solicited-Node multicast groups, this means that the host's interface will specifically listen for traffic sent to this multicast groups. This is a very important point, the whole purpose for an interface to join a multicast group is because it needs to participate in this particular group activities according to what its configuration dictates, hence, it will actively listen for traffic from this group. OK, right now we are going to talk specifically about the Solicited-Node multicast address. There are two address resolution processes in which the Solicited-Node address is used; these are MAC address ( Layer 2 ) mapping and Duplicate Address Detection ( DAD ) which are part of the IPv6 Neighbor Discovery process. If we think about IPv4 for a moment, it too has a process to map IP s to unknowns MAC s, that process is called ARP and it is handle at L2 , L3 is not involved at all. Whenever a host needs to map an IP to an unknown MAC , an ARP Request message is sent to the broadcast MAC address FFFF:FFFF:FFFF and so every single node on the network receives and process this ARP Request , but only the intended target responds with an ARP Reply which includes the L2 info that the host that sent the ARP Request needs. Now, with IPv6, there is no more L2 broadcast and there is no more ARP , the IPv6 process to map IP s to MAC s is part of a process called Neighbor Discovery and it uses the L3 Solicited-Node address to accomplish this, L2 is not involved. In other words, the IPv6 process to map MAC s was moved to from Layer 2 ( Ethernet ) to Layer 3 ( IPv6 ). I will explain the process in both scenarios ( MAC address mapping and DAD ) and this will give you a good understanding of how the Solicited-Node address is used: Note : Both this processes use the messages Neighbor Solicitation ( NS ) and Neighbor Advertisement ( NA ). These messages are defined in the Neighbor Discovery Protocol ( NDP ) which we will talk about next. MAC address mapping : The scenario is as follows; Host A and Host B are in the same network segment. Host A wants to communicate with Host B but it only knows Host B 's L3 , IPv6 address. So, to get Host B 's L2 MAC address, Host A figures out Host B 's Solicited-Node address (as it was explained before) and sends a Neighbor Solicitation ( NS ) message (similar to the ARP Request message on IPv4) to this address. Host B receives this NS message and replies with a Neighbor Advertisement ( NA ) (similar to the ARP Reply message in IPv4) which contains its L2 info. Host A receives the NA , adds Host B 's L2 info into its Neighbor table (similar to the ARP table in IPv4) and it can, from now on, communicate directly with Host B on L2 . Duplicate Address Detection (DAD) : To check if an IPv6 address is being used on the network, DAD will put together a Solicited-Node address using the predefined prefix of FF02::1:FF and the last six digits (24bits) of the IPv6 address it wants to use. It will then send a NS message to this address. If it receives an NA message as a reply, it means that this particular address is already being used. Let's do a packet capture using Wireshark to see if we can catch some of this concepts in action: https://youtu.be/DOkAXpt1UJ8 Neighbor Discovery Protocol. We've already talked about some of the Neighbor Discovery processes such as DAD and MAC mapping. Let's dig a bit deeper into the NDP, see what we find. We've mentioned that in IPv4, ARP was used whenever a host needed to learn or match an unknown MAC address to a known IP address. Well, not only IPv6 no longer uses L2 broadcast messeges, it does not use ARP either, instead, it uses the Neighbor Discovery Protocol (NDP) which is part of the Internet Control Messege Protocol Version 6 (ICMPv6). To accomplish the discovery of neighbors, NDP implements 5 messege types: Router Solicitation (RS), Router Advertisment (RA), Neighbor Solicitation (NS) and Neighbor Advertisment (NA) and a Redirect Messege. Let me get the Redirect Message out of the way as it is very simple; when a router receives a message requesting information on how to get to a certain network, for example, and this router knows how to get there but there is another router that is directly connected to this particular network (or closer), it will reply with a Redirect Message saying, “hey, I know how to get to where you're going, but here is a better gateway for you to use as well or from now on”. Thas it. OK, on to the other message types. I will show you which types of Neighbor Discovery messages are used, where, and when, this will give you a good understanding of what they do: During SLAAC: When a host is trying to come up with its IPv6 address through Stateless Address AutoConfiguration, it uses the NDP messeges RS and RA to learn the IPv6 address' prefix and prefix length (the Network ID) and also Default Router information. During DAD: Once a host learns or is assigned its IPv6 address, it needs to make sure that this address is not being used on the network by another host. This is accomplished through DAD, making use of the NS and NA messeges. I've explained the process before, refer to “What is a Solicited-Node address used for?” During MAC discovery: After DAD, the host has an IPv6 assigned and, as we explained before, when it needs to learn other host's MAC, it uses the NS and NA messeges. This process was also explained before, refer to “What is a Solicited-Node address used for?” During Router Discovery: RS and RA messeges are sent by routers to discover other routers attached to the same link/segment. This is mostly used to get IPv6 addresing information for autoconfiguration. StateLess Address AutoConfiguration - SLAAC . So we've mentioned SLAAC many times before, let's see what it is about. So let's take, for example, the NIC in your PC (or IPv6 device), when it comes on, the first thing that It needs to accomplish is getting an IP address, right? In this case it is going to be a Link-Local address, and to do this, this is what happens: SLAAC uses the RS and RA message types defined in the Router Discovery process to learn the address prefix and prefix length , to construct the IPv6 address for an interface. Look at the picture below. PC1 just turned on and it is connected to the same subnet as R1. To construct, in this case an IPv6 Global Unicat address, PC1 send out an RS message to the All-Routers multicast address of FF02::2 saying “Hey there, if there is a router out here, can you send me what I need to configure my IP address?” R1 will receive this RS and reply with an RA to the All-Nodes multicast address of FF02::1. This RA contains the info that PC1 needs to configure itself, mainly the prefix and its length (usualy /64), which in this case is 2001:DB8:1111:1::/64, and Default Router info. When PC1 receives the RA, it puts together a GUA using the prefix information received in the RA and comes up with its own modified EUI-64 format Interface ID or, it can be manually configured... it is now ready to go out to play. Picture taken from the book “Cisco CCNA R&S 200-120, OCG” by Wendell Odom. Router Discovery. A host can send an RS messege to the all-routers multicast address of FF02::2 to request information about the routers attached to the same link/segment. In turn, the routers respond to the RS with an RA of their own, either to the Unicast address of the host that sent the RS, or to the all-nodes multicast address FF02::1, either way, the host that originated the RS will recieve the RA. If the RA is not sent in response to an RS (because periodically, routers send RAs on their own), it was unsolicited, the RA is sent only to the all-nodes address directly. Picture taken from the book “Cisco CCNA R&S 200-120, OCG” by Wendell Odom. Anycast Address. Hey there... Let me ask you a question; what was one of the most unique characteristics of an IPv4 address?... Can you think of any unique answer?... no?... OK, I'll tell you, the answer is that they have to be... yes, that's right, unique! Well then, let me give you this definitions of an IPv6 Anycast address: “An IPv6 Anycast address is any , Global or Unique-Local address, that has been assigned to more than one interface...” I can almost see you scratching your heads now, and the funny part is that this is a true statement! You are provably screaming at this moment, “How can this be, it is not possible. Surely there will be some sort of catastrophic event if we use the same Global or Unique-Local IPv6 address on more than one interface, Gerald lost his marbles”.. right? Well, no I have not, assigning an IPv6 more than once is what you need to do to create an IPv6 Anycast address. See, because an Anycast address is used as a fail-over address, fault tolerance they call it. Let me give you an example. Say you want to add an FTP server in your IPv6 network and this FTP server is very import, it feeds files that your employees use daily. So you think to yourself, “Wouldn't be a good idea if I can have two FTP servers using the same IPv6 address, and traffic to this address could be routed to the nearest server?”... Think no more, if you are running IPv6 in your network, just assign the same Global or Unique-Local address to the DNS servers, and let the routing protocol control the traffic flow to them. Here is a very important point regarding the fact that Anycast addresses are used for fault tolerance; While this is true, it doesn't mean that ALL traffic is going to be flowing to just one of the servers in our example. Depending on where you are on the network, traffic is going to flow to either one server or the other. A “Fault tolerance” system is not the same as a “backup” system, on a backup system, “something” waits for the other “something” to fail and then it kicks in. This is not the case here, both our servers are going to receive traffic, how much and from where is controlled by the routing protocol. If one server fails, traffic will be re-routed to the other server. https://youtu.be/ohFbC6VyJAo END OF PART II References: Members of the Cisco Learning Network at https://learningnetwork.cisco.com/welcome -Thank you guys! CCNP R&S, ROUTE 300-101 OCG by Kevin Wallace, CCIE 7945 https://tools.ietf.org/html/rfc4291 https://docs.oracle.com/cd/E19683-01/817-0573/chapter1-26/index.html https://technet.microsoft.com/en-us/library/bb726995.aspx#EDAA http://www.iana.org/assignments/ipv6-unicast-address-assignments/ipv6-unicast-address-assignments.xhtml http://ipv6.com https://technet.microsoft.com/en-us/library/cc757359(v=ws.10).aspx http://www.firewall.cx/networking-topics/protocols/877-ipv6-subnetting-how-to-subnet-ipv6.html ... View more

In our IPv6 for future CCNAs – Part I, we ended the article talking, very lightly, about IPv6 address types. Let´s go ahead and dig deeper into the concepts. To recap, the IPv6 address types are: Unicast. One-to-one communication. Unique address assigned to an interface, a packet sent to a Unicast address will be received by one single interface . There are several types of Unicast addresses: Global Unicast. Link Local. Unique Local. (in place of Site-Local which was deprecated in 2004). Special Addresses Unspecified. Loopback. Multicast. One-to-many communication. A Multicast address identifies a group of interfaces . A packets sent to a Multicast address are received by a group of interfaces that may be in different hosts. Anycast. One-to-one of many communication. An Anycast address represents a group of interfaces , but the packet sent to this address will be delivered only to the interface which is closest , in terms of the routing protocol cost value . Also, since Anycast addresses are allocated from the Unicast address space , they are syntactically indistinguishable from each other. So, an Anycast address is a Unicast address that was assigned to more than one interface. Unicast Addresses: Global Unicast . This address uniquely identifies an interface on a network, it is globally routable and it has a hierarchical structure. You can think of a Global Unicast address as the Public address on IPv4. Configuration. A Global Unicast addresses can be configured either automatically (stateless) using Stateless Address Auto-Configuration - SLACC or manually (state-full) through the CLI. Please note that when I say that a Global Unicast address can be "automatically" configured, it does not mean that its configuration will be 100% automatic, it means that you can either configure a specific value for the Interface ID manually using the command "ipv6 address xxxx::x/64" on the CLI or, you might prefer letting the SLAAC come up with the Interface ID, by using the command "ipv6 address 2001::/64 eui-64". But, as you can see, in both cases you will need to go through the CLI and enter commands to configure either option. (More on SLAAC and EUI-64 later) Here is a short video on Global Unicast address configuration: https://youtu.be/NTlWaNBnk4U Global Unicast address structure. When the IANA allocates an IPv6 address to you, you get an address that looks like this: Let´s examine that structure in details: The first 48 bits are referred to as the Global Routing Prefix and it is further divided into 4 fields: 001 : First 3 bits are fixed and they identify a Global Unicast address, so the available range goes from 2000::/3 to 3FFF::/3. (The IANA is still assigning Global Unicast addresses in the 2001::/3 range so you might not see anything other than 2001::/3 for a while). TLA ID : As you can see on the picture above, a Global Unicast address has a hierarchical structure and this Top Level Aggregation ID (13bits) represents the highest level of the routing hierchy. It is allocated by the IANA to RIR s and in turn to the local ISP s and finally to the organizations. NLA ID : The Next Level Aggregation ID (24bits) , identifies the second highest level of routing hierarchy which is the organization that has been allocated this block of address. SLA ID : Also referred to as Subnet ID, the Site Level Aggregation ID, i dentifies a subnet within the Organization's Topology . It is used for subnetting , and since it is 16 bits long, there are a total of 65,536 possible subnets ( 2 16 ). Interface ID : Identifies a single interface in a subnet within the organization`s topology. Hierarchical Structure. Let´s take a closer look at the hierarchical structure: Let´s see it in a topology: Unicast Addresses: Link-Local. The most important concept that you need to understand about a Link-Local address is the following; Now, let´s see the details; an IPv6 interface is required to have a Link-Local address, it may not have any other address type assigned, but it must have a Link-Local address. Hence, the Link-Local address is assigned automatically just by enabling the interface for IPv6 (This behavior is a lot like the APIPA address in IPv4). The Link-Local address is, as its name implies, a local address used only inside a network link/segment, it will not be routed outside the broadcast domain in which it was originated. The following picture will help you visualize where a Link-Local address is used: Personal thought : In many places you will find the term “ segment ” referring to a “ link ” (a cable from device A to device B), and that is correct , technically it is a segment of the network. However, that really confused me a lot, so I (just me, I think...) started differentiating a link from a segment by calling the cable from R1 to R2 (in the picture above for example), a “ link ” and calling it a “ segment ” when ever there's something else in between devices, such as SW1 between R2 and R3 in our picture. So, learning where a Link-Local address is used was fairly easy, but what about its purpose?... One of the best ways, I think, to understand what something is or what it does, is to know what it is used for, so here is a list of Link-Local address uses: Router's communication on the same link/segment. Address Auto-Configuration (SLAAC). Neighbor Discovery Protocol (NDP). Routing protocol advertisements and next-hop address. Host-to-Host connection (crossover cable). “Host-Switch-Host” connection (no router). Notice that a even though a Link-Local address is not routed, it can still be used to send user data (the last two uses listed above), in other words; if you have a Host-to-Host connection (using a crossover cable) or you have a bunch of hosts connecting through a switch, it is all just one segment, hence Link-Local addresses will be used to send user data because packets are NOT being routed outside the local segment. Configuration. Just like with a Global Unicast address, a Link-Local address can be configured either automatically (stateless) through SLACC and EUI-64 , or manually (stateful) using the “ ipv6 address FE80::x link-local” command, where “ x” is the unique value (including 0) you want to use for the Interface ID . However, the Link-Local address auto-configuration, as opposed to the Global Unicast auto-configuration, is 100% automatic, you do not need to enter any commands to configure it, it is auto-configured either when you use the command “ipv6 enable” on an interface or, when you assign a Global Unicast address to an interface. Address Structure . The address block FE80::/10 has been reserved for Link Local addresses. This means that a Link Local address has the 10 (/10) most significant bits set to 1111 1110 10 so, according to this, a Link Local address will start with either FE8, FE9, FEA or FEB because of bits 11 th and 12 th can still be either a 1 or a 0, providing for other possible values for hex 8. However, if you take a look at RFC 4291 – IPv6 Addressing Architecture Sec. 2.5.6, you will see this: The picture above shows the first 10 bits set to 1111 1110 10 as it should, that is the rule, but it also says that the following 54bits should also be set to 0s, it does not leave any other possibility but zeroes, thus, eliminating the FE9, FEA and FEB possibilities. (This is because bits 11 th and 12 th will always be set 0, according to the graph above). Yet, when you manually configure a Link-Local address on an interface, either FE9, FEA or FEB will be accepted as a valid Link-Local address! OK, I want to give you a fair warning about the statement above; it does not work in Packet Tracer! If you want to try assigning a Link-Local address to an interface, other than FE80::, like FEA0:: for example, Packet Tracer does not accept it: However, if you do the same on a real router: Please note that when Link-Local addresses are configured with SLAAC, the RFC statement coincides perfectly. In other words; when assigning a Link-Local address automatically, the address will always start with FE8 followed by 54 zeroes (FE80::)... hmm, maybe the statement is referring to this scenario only?... Well, I guess we can summarize this by saying that if a Link-Local address was configured automatically (which is 99% of the time), it will always be FE80::, but if you come across an FE9, FEA or FEB, you know that it was configured manually. Quick video to check your understanding: https://youtu.be/oAvcUn976As   Subnetting. Subnetting... SUBNETTING... it was a big word on IPv4, lots of math involved... not so much on IPv6 though. Even though at a CCNA level there is not much math in IPv6 subnetting, it can get pretty complicated, especially from an structural point a view (search for multi-level IPv6 subnetting and you'll see what I mean), but thankfully, we do not need to go that deep. Here is what you need to know about IPv6 Subnetting for CCNAs; The scope for subnetting hasn't changed, it's 1 subnet per All subnetting occurs in the Subnet ID field and it's as easy as assigning each subnet needed, a unique hex value between 0000 and FFFF. That's a total of 65,536 possibilities! Yes, that's right, with a /64 IPv6 address, we can have 65,536 subnets... if you think that is wasteful for most, wait until we talk about the Interface ID next! Now, there is no need at all for subnetting the interface bits, let´s see why that is; The Interface ID it´s 64bits , this means that each subnet can have 2 64 unique addresses...and that is... wait for it... 18,446,774,073,709,551,616 unique host... sorry again... I mean interface addresses ! Now you're thinking; Wait a minute, there are 4,294,967,296 TOTAL IPv4 addresses, and with IPv6 we can have 18,446,... - the big number we just mentioned- for each subnet!... man... IPv6 is big!... Yeah... it is! That's it; change the Subnet ID to uniquely represent each of your subnets and go home... or Moe's Tavern if it's Friday! :O) And before you ask, yes, it is possible to “borrow” interface bits to create more subnets, but there are a couple of very good reasons why you shouldn't; first and foremost, because you will never need more than 65,536 subnets, and second; because for IPv6 auto-configuration to work, it needs a 64bit Interface ID . For example, a very common IPv6 configuration method is Stateless Address Auto-Configuration - SLAAC, and this method uses the Extended Unique Identifier - EUI-64 address, which takes the interface's 48bit MAC, sticks FFFE right in the middle and then flips the 7 th bit, so it'll end up with a unique 64bit Interface ID -we will talk about IPv6 auto-configuration and the EUI-64 address in more detail, later on in our discussion. Here is a couple of pictures, to help you visualize where subnetting takes place for IPv4 and IPv6: IPv4 Address: IPv6 Address: END OF PART II --------------------------------------------------------------------------------------------------------------------------- References: Members of the Cisco Learning Network at https://learningnetwork.cisco.com/welcome -Thank you guys! https://tools.ietf.org/html/rfc4291 https://docs.oracle.com/cd/E19683-01/817-0573/chapter1-26/index.html https://technet.microsoft.com/en-us/library/bb726995.aspx#EDAA http://www.iana.org/assignments/ipv6-unicast-address-assignments/ipv6-unicast-address-assignments.xhtml http://ipv6.com https://technet.microsoft.com/en-us/library/cc757359(v=ws.10).aspx http://www.firewall.cx/networking-topics/protocols/877-ipv6-subnetting-how-to-subnet-ipv6.html ... View more

The History. So we are running out (have ran out?) of IPv4 addresses. They have been with us since the very beginning, they were there during the 1980`s when everything was calm, and they stuck by us during the chaotic growth of the Internet during the 1990`s. There were some rumors, during the 2000`s, that they were going to run out soon, but something called Classless Inter-Domain Routing (CIDR) and Network Address Translation/Port Address Translation (NAT/PAT) saved our butts... for a while. These 4 little sets of numbers, called Octets, separated by dots were very mysterious, we used to look at them from the corner of our eyes asking our selves; What are they for?... What do they do?... How do they do it? We were intimidated just by looking at them, and they were just 4 little sets of decimal numbers, numbers that we recognize, that we use every day in our daily lives. And then, we found out that they were hiding something, they were just expressed in a decimal format (called dotted-decimal), when in reality they were written in something called Binary, and that they were not 4 little sets of decimal numbers but 4 octets with 8bits each for a total of 32 binary 1 s and 0 s!... and that´s not all, there were 2^32 of them, which is 4,294,967,296. Oh my God! What is going on?...   But time went by and we, the “network guys”, in the long run became accustom to these little guys. We learned that they uniquely identify a device on the network. That they have a friend, called the Sub-net Mask that indicates to what network they belong to, we've even learned to break them in small chunks according to the size of our network, using sub-netting, so we wouldn't waste them... we were taking care of them. Regardless, no matter what we do to preserve them, we were going to run out soon enough. Something had to be done... Introducing, Internet Protocol Version 6... and get this, it is NOT a string of 32 but 128 binary 1s and 0s! It is NOT 4 little fields separated by dots, it´s 8 16bits fields called Hextets, separated by colons ( : )! It is NOT expressed in decimal format but in Hexadecimal format!.. and there are not 2^32 but 2^128 of them, which is... are you ready?... 340,282,366,920,938,463,463,374,607,431,464,133,816 (for those of you who are just starting out and don´t know, the number is 340 undecillion... plus change) I mean, I understand that the world cannot continue in its current form without the Internet, but come on!! What are they trying to do to us? Advantages Over IPv4 . As you know, the migration over to IPv6 has already started, but you haven't noticed it maybe, because IPv4 is still around and it will still be around for a long time. There are many reasons why IPv4 is still around; NAT/PAT, CIDR and also, it works fine and we know how it works. But, we also know that there are no more IPv4 addresses to give out and this is the main reason why we have to migrate to IPv6. But what about the people that already have IPv4 addresses assigned, I mean they have them for good right, so what makes them want to migrate to IPv6? The answer is because not only there is an almost infinite amount of addresses available in IPv6 (and we will NEVER ran into the same shortage problem again... right?), but also because IPv6 has some pretty good advantages over IPv4. Let´s see a few: Better End-to-End Connectivity: One of the features that allowed IPv4 to exist beyond what was expected, is NAT. However, NAT is not a very good point-to-point communicator. Host A thought it was talking directly with Host B when in fact, it wasn't. Well, IPv6, because of its vast address space size, no longer needs the use of NAT. It allows for direct end-to-end communication from Host A to Host B... no middle man. Better Auto-configuration. For a host to get the info needed to join a network, IPv4 uses DHCP (Dynamic Host Config Protocol) which is a stateful method, meaning the host receives all the info from a server. IPv6 has both a stateful (DHCPv6) and stateless methods where hosts are able to auto-configure themselves with the info needed to join the network (no server). More Efficient Header: There is a significant improvement on processing time because many rarely used fields from the IPv4 header have been either removed, or moved to an optional header called “ extension Header ”. This extension header is only implemented by intermediate routers if a packet needs special handling. One of the fields that have been removed is the Checksum field. Routers no longer have to compute a checksum every time they receive a packet. With IPv6, checksum and error control is handled by upper-layer protocols. Better Security. IPv6 has support for IPSec which provides for Data Confidentiality, Integrity and Authentication at layer 3. With IPv4, end devices provided this level of security. Better QoS Support. This is accomplished through the use of a field in the header called Flow Label. Routers are able to use this field to mark specific flows of packets such as packets that require QoS treatment. Built-in Mobility Support: IPv6 hosts have the ability to move around the network and maintain its IP address. Transition Tools. Tunneling NAT64 6to4 SIIT DNS64 etc. IPv6 address format. An IPv6 address consists of 32 hexadecimal numbers, separated by colons ( : ) into 8 hextets of 4 hex numbers each. Each hex number represents 4 bits, that is 16bits per hextet for a total of 128bits ( 4 bits x 4 hex digits per hextet x 8 hextets= 128bits ). Here is an example: 2001:0AC8:1234:0000:0000:0000:0000:0678 Let´s break it down into binary. We are not going to do the whole number, but lets do the 1 st and 2 nd hextets at least: Remember, to figure out binary, you need to use the place values, and they are; 8 4 2 1 for a 4 bit value like in this case (each hex digit). So, for example, hex number A on the second hextet (which is 10 in decimal), there is a 0 on place value 1, a 1 on place value 2, a 0 on place value 4 and another 1 on place value 8. Now just add the values that have 1s, 2+8=10. IPv6 Short Notation. As you can see, an IPv6 address is very long, right? Let´s imagine this scenario: You arrive at work and there´s an email from your boss, asking you very nice and politely... sort of, that all 100 PCs for the upcoming event are in Show Room C, and that you need to configure these PCs, for some odd reason, with IPv6 addresses... manually. Well... your next step should be texting (texting, is that an obsolete word now?) your wife to let her know that you are not going to get home on time this evening, am I correct? Fortunately, some genius people already thought about (or went through!) this scenario, and they came up with a way to be able to write an IPv6 address in a much shorter way. Let´s see it. First, you need to understand the rules, they are very simple: Leading zeroes on each hextet can be omitted. Leading zeroes only . So: 2001:0AC8:1234:0000:0000:0000:0000:0678 can be written as: 2001:AC8:1234:0:0:0:0:678 Contiguous hextets of zeroes, can be represented with the use of double colons (: :). This can only be implemented one time per address. So: 2001:0AC8:1234:0000:0000:0000:0000:0678 can be written as: 2001:0AC8:1234::0678 And finaly, we can combine rules 1 and 2. So: 2001:0AC8:1234:0000:0000:0000:0000:0678 can be written as: 2001:AC8:1234::678 Also, we can still use “Slash Notation” or “CIDR Notation” as we did with IPv4. For example, if the first 64 most signifficant bits indicate the network bits or Network ID, we can notate it with a slah ( / ) and the number of bits i the network ID, like this /64. So, we can write the whole address as follows: 2001:AC8:1234::678 /64 On this particular example, we ended up with a shorter IPV6 address, only 14 hex digits as opossed to 32 in a full address. However, depending on the original, full address, we can end up with an address that is only 10 characters long, and that is very good if you need to enter these addresses manually. Lets see: Original: 2001:0000:0000:0000:0000:0000:0000:0001/64 Let`s remove the leading zeroes: 2001:0:0:0:0:0:0:1/64 Or, we can us the double colon: 2001::1/64 IPv6 Address Types. In IPv4 we have 3 types of addresses; Unicast, Multicast and Broadcast. For IPv6, even though there is no more Broadcast address, there are several types of addresses and they are assified within 3 main types. They are: Unicas t One-to-one communication. Unique address assigned to an interface, a packet sent to a Unicast address will be received by one single interface. There are several types of Unicast addresses: Global Unicast. Link Local. Unique Local. (in place of Site-Local which was deprecated in 2004) Unspecified. Loopback. Multicast One-to-many communication. A Multicast address identifies a group of interfaces. A packets sent to a Multicast address are received by a group of interfaces that may be in different hosts. Anycast Special one-to-one communication. An Anycast address represents a group of interfaces, but the packet sent to this address will be deliver only to the interface which is closest, in terms of the routing protocol cost value. Also, since Anycast addresses are allocated from the Unicast address space , they are syntactically indistinguishable from each other. So, an Anycast address is a Unicast address that was assigned to more than one interface. END OF PART I References: Members of The Cisco Learning Network at https://learningnetwork.cisco.com/welcome IPv6 Fundamentals: A Straightforward Approach by Rick Graziani https://docs.oracle.com/cd/E19683-01/817-0573/chapter1-26/index.html https://technet.microsoft.com/en-us/library/bb726995.aspx#EDAA http://www.iana.org/assignments/ipv6-unicast-address-assignments/ipv6-unicast-address-assignments.xhtml http://ipv6.com ... View more

We are going to start, slowly but surely, building a theoretical network in our minds. In order to do this, we are going to start from the beginning; recognizing all the components of a modern network as well as some not so modern devices. For now, it is going to be a basic description of each device's function, but we will elaborate on each concept as we move forward. Let's begin. SWITCH: The Switch is the star of the network, it is the most active device, in charge of making sure that frames go where they need to go  These frames are units of data at Layer 2 (the Data-Link layer), of the 7 layers OSI reference model, and this is why switches are refer to as “Layer 2 devices”. A frame comes into one of the ports, and the switch “switches” the frame out of another port that points to the frame's final destination. This is possible because switches actively learn MAC addresses (a MAC address is the physical address of a device) and they keep a table, called the “MAC Table”, with entries matching MAC - to - port, so switches know off of which port, devices are reachable. You should also know about how a Switch communicates. There are two communication methods; Half-Duplex and Full-Duplex and Switches communicate at Full-Duplex. This means that each one of its ports is able to send and receive data at the same time and this is because in Full-Duplex communication, two wires (inside the network cable) are used, one for transmitting and the other for receiving. This communication type makes it impossible for Collision to occur. Here is an example of  a “MAC Table”: This is the table a switch builds with MAC address information taken from the frames that it receives on its ports. To look at this table, you issue the command “show mac-address-table” on a switch and you'll get the output above. Let's break it down: Vlan: The frame received belongs to Vlan 10. Vlans is a topic for future discussions and it is not needed to understand the function and inner workings of a Switch. MAC Address: The frame received has a source MAC address of 0060.2fcc.9102. In other words, the switch received a frame on port Fa0/1 and the device (PC, Router, another Switch, etc.) that sent this frame has this MAC address, so the Switch says; “Hey! A networked device that has the physical address of 0060.2fcc.9102 is connected to me and I can get to it from one of my ports” and adds that entry to its MAC table. Type: How this MAC address was learned. There two ways a Switch can learn MAC information; DYNAMIC, the Switch learns through frames received on its ports or, STATIC, the entry was manually configured. Ports: On which port the frame came into the Switch. This is the final piece of information needed. Now the Switch knows that a device with MAC address 0060.2fcc.9102 lives off of port Fa0/1. So, from now on, when the Switch receives a frame destined for 0060.2fcc.9102, it will immediately forward that frame out of port Fa0/1. Switches are used to connect network devices, like this: Now, notice that the Switch is connected to a Router. The Router, if needed, is used to get out of the local network (LAN) and access a different network. This may be another company's network or, most commonly, the Internet. Let's examine the Router next. ROUTER: Just like switches are used to connect devices, Routers are used to connect networks. Routers process packets, which are units of data at Layer 3, the Network layer, this is why Routers are refer to as “Layer 3 devices”. A Router receives a packet and examines the destination IP address information to determine what network the packet needs to reach, and then sends the packet out of the corresponding interface. In the picture above, we have two different networks, that is Network A and Network B. In order for these two networks to be able to communicate with each other, a Router is needed to connect both networks. For example, if PC1 wants to communicate with PC0, PC1 will send the data to the IP address of its Default-router, which in this case, is F0/0 on Router. When Router receives the packet, it examines the destination IP address contained in the packet and looks at its Routing Table to see if it knows where the destination network is located. In this case, it finds an entry in its Routing Table that says that network 192.168.10.0 is directly connected to interface F0/1, and so it sends the packet out of that interface. Here is an example of a “Routing Table”: By issuing the command “show ip route” on a Cisco Router, we get the above output, let's see what it means; this particular Router knows about 4 networks, that is the 192.168.10.0, 192.168.20.0, 192.168.30.0 and the 192.168.40.0 networks ( 1 ). It happens to be that all 4 networks are directly connected to the Router as indicated ( 2 ) and also by the letter “C” ( 3 ). If the network was learned through a Routing Protocol (NOT directly connected), these lines will start with a different code ( 4 ). Finally, it shows to what interfaces are these networks connected ( 5 ). So for example, the first lines reads; Network 192.168.10.0 is directly connected to interface FastEthernet0/0 and whenever the Router receives a packet destined for network 192.168.10.0, it knows to send it out of interface F0/0. HUB: A Hub, like a Switch, is used to connect multiple devices on a network, the difference is that Hubs are unintelligent devices, all they are able to do is replicate any frames they receive in one port, out of all the other ports. Hubs do not have the ability to learn MACs and make forwarding decisions as Switches do. The Hub works at Layer 1, the Physical layer, hence, it just deals with signals, it does not do any sort of processing on the signals it receives. In one port, out of the others. The other big difference between a Hub and a Switch is the way it communicates. We said that a Switch communicates using the Full-Duplex method, the Hub on the other hand, uses the Half-Duplex method. This method uses only one wire inside the network cable to both transmit and receive, hence, the possibility of Collisions are much more greater on a Hub then on a Switch. In fact, Collisions are very common when a Hub is used, specially on large networks. You will not see a Hub used in today's networks very often, but because Hubs are very cheap compared to Switches, you might come across a Hub in certain situation. A good scenario for implementing a Hub is, for example, a cubicle with a few end devices that need to connect to the network but there is only one network connector. You can just connect the Hub to the existing network jack and then the devices to the Hub, instead of having to run cabling from the Switch to the cubicle. Note: if this is done unsupervised, it can potentially cause network disruptions, please seek the help of you IT department. BRIDGE: The Bridge, like a Switch, works at layer 2, the Data-Link layer. Bridges are even rarer than Hubs, almost obsolete we could say, but they were very popular during the early years due to the necessity to interconnect mixed network types such as Ethernet and Token-Ring and also, as networks started getting larger, it became necessary to break up Collision domains. A Collision happens when more than one device transmits data at the same time, and this can significantly slow a large network down. This is why Collision becomes an issue on large networks, the more devices trying to communicate, the greater the chances of Collisions. * For more info on Collision Domains, read “Broadcast and Collision Domains”, in my blog @https://broadcaststormblog.wordpress.com/ However, on today's networks, Switches have made Bridges obsolete, let's see a few reasons: Ethernet became the most popular standard by far, so it is not very often that we need to connect different network types. Switch breaks up Collision domains. Switch has superior performance. Switch has lower per-port cost. Switch has higher port density. Most common Switches have 24 or 48 ports as opposed to 2 or 4 ports on a Bridge. OK, we've talked about all the basic devices needed to build a basic network, let's go ahead a build one: https://youtu.be/nvPvs0Nub3s ... View more

A little bit of history. Before we talk about Spanning Tree Protocol, let's organize the different variants of STP. The original STP was developed by Radia Perlman while working for DCE back in 1990. At this time there were no switches yet, only bridges, but because bridges and switches technically do the same job -only switches do it more efficiently and have more features- they suffer from the same issues. Also, because STP was developed during a time when there were only bridges, the terminology used in STP, even today, makes reference to bridges a lot (Root Bridge, Bridge-ID, etc.). So, when you read about STP from different sources, remember that the terms Switch and Bridge might be used interchangeably.  The original STP, developed by Mrs. Perlman, was later standardized by the IEEE as the 802.1D standard. This two variants, Perlman´s STP and 802.1D, implemented only one STP instance for the whole network (This was sometimes referred to as Common Spanning Tree-CST), because Vlans had not been invented yet, so one instance of STP was enough. When Vlans were introduced, Cisco made some improvement on the 802.1D standard to accommodate Vlans and called it Per-Vlan ST Plus (PVST+) or sometimes PVSTP. This  improvements allowed for multiple STP instances (one for each Vlan on the network). This means that each Vlan could have its own STP topology. With this Cisco improvement, a few other extension were also introduce such as PortFast. Later, the IEEE made its own improvement on its standard 802.1D, which was considered to have a very slow convergence time, it was called Rapid STP (RSTP) and its standard is 802.1W and, as the first part of the name indicates, it was much faster (rapid) to converge than its predecessor. Then Cisco took the 802.1W standard and made some proprietary changes as well and called it Rapid Per-Vlan ST+ or RPVST+.   Note: Cisco switches support PVST+, RPVST+ and MST and because by default cisco switches use PVST+, we are going to talk about that STP variant on this paper.      What STP does and why.   STP was developed to prevent loops (aka, Switching loops or layer 2 loops) at layer 2 in a switched network with parallel links between switches, thus creating more than one path to a single destination. These loops, in turn, will create a much worst condition called a Broadcast Storm which is a result of broadcast, multi-cast and/or unknown-destination frames looping endlessly around the network, and this happens because of two main reasons; First, because switches will forward these frames out of every port except the receiving port (This is called Flooding) every single time they receive them. Second, at layer 2 (as opposed to layer 3) there is no Time To Live (TTL) field in the frames header, so frames will not “expire”. They will go around and around in a network until the network is shutdown or it fails. So, when broadcast storms happen, frames will start crowding the network´s bandwidth leaving very little room for "good" frames, so the network will start slowing down. Also, PCs will need to process an enormous amount of broadcasts, so their performance will be negatively impacted as well. Even though these loops happen when there are multiple paths between switches, having multiple paths to a single destination, called Redundancy, is not such a bad thing to have in a network. In fact, redundancy is convenient, very often essential for a network, because it provides alternative paths in case one path fails. In fact, STP was developed so that we can have redundancy in our networks. STP also prevents another switching issue called MAC table corruption , which happens when a switch learns about the same destination MAC address from duplicate frames received on more than one of its ports. Here is a video I made about why is STP needed. https://youtu.be/eJ1ufrEgBVU   Protocol Operation. Before we talk about the specifics of STP operations, I want you think of an STP topology as an INVERTED tree (look at the image bellow) with its roots being the Root Bridge (for now, let´s say it is the main switch ) on top, and the branches reaching downstream and spanning towards the non-root bridge switches. In turn, these other switches will reach upstream, towards the Root Bridge (RB). I can hear you guys saying “Root what, non-root what?!... We´ll get to the good stuff soon enough, for now just know that on STP, there´s a “boss” switch that is called the Rood Bridge and the other switches will find the best path to get to it. STP CONVERGENCE STP prevents issues created by parallel links on switched networks and allow us to have redundant networks, by selecting the best path to a destination and blocking the remaining paths until the best path originally selected, for some reason becomes unavailable. To do this, STP uses what is called the Spanning Tree Algorithm (STA), this algorithm will come up with a loop free STP topology by selecting first, a switch that will act as a "central point of reference" called a Root Bridge (RB) and then it will calculate best paths to this switch from all other switches in the STP domain. This is accomplished by selectively putting some ports in a forwarding state and other ports on a blocking state, following specific rules from a process call the Election Process, we´ll see this process in detail soon. The process just described (very briefly) is referred to as Convergence and we say that something has converged once it has finished its initiation process an it is ready to do what it´s supposed to do. Port States. In order for STP to converge and do what it is supposed to do (which is to create a loop free topology), among other things, it has to systematically control the ports and elect which port will forward data and which one will block data, as we stated before. Ports start at the Blocking state and then they start transitioning through the different states until they get to the Forwarding state. Before we learn about how STP does this, let´s learn about the port states and their roles: Blocking: The port does not learn MAC addresses nor participate in the switching of data frames, it will discard these frames when received. But it does receive and process STP frames (called B ridge P rotocol D ata U nits or BPDU s). Listening: In this state the port does not learn MAC addresses nor participates in the switching of data frames but it does process BPDU s. Also, it removes old unused MAC table entries. Learning: During this state, the port still does not forward data frames, but it does forward BPDU s and re-populates its MAC table. In other words, it learns MAC address from data frames received. Forwarding: This is the “normal” port state on a switch. When a port is forwarding, it is fully participating in the switching of every frame accordingly. Disabled: When a port is disabled, it does not participate on any frame switching, it is shutdown , either administratively (Manually) or because of failure. Here´s a table that summarizes port states and shows you the LED color on the switch port during on each state: Timers.  These timers play a big role as they control how often or for how long STP performs its chores. The values, which are configurable, are carried inside BPDUs sent only by the Root Bridge, and have a direct impact on convergence time, as we´ll see just ahead. For now, these are the default values:    Convergence Times. Convergence time is defined by the total time it takes for a port to transition from either, Listening to Forwarding or Blocking to Forwarding. We can think about this as Convergence Time = Listening to Forwarding transitions and Re-Convergence Time= Blocking to Forwarding transitions.    Convergence Time: When the switch first comes online (turns on):   Listening state – Transitional state. (15secs by default or Forward Delay) Learning state – Transitional state (15secs by default or Forward Delay) Forwarding state - Stable state.   As you can see takes a total of 30 seconds (15 on Listening + 15 on Learning). This is because the ports were not Blocking to start with so it saves 20 seconds (default value). In other words, it did not have to go through the Max Age timer.   Re-Convergence: If a process needs to re-converge, it means that it had already converged at least once before, and the most common reason for STP to have to re-converge is a topology change (i.e. a link failure). Even though a failure is a failure, when it comes to STP, this same failure will have different effects on STP Convergence time, depending on where, in the STP topology, the failure occurred. However, it´s not a matter of physical location, it is a matter of perspective. STP refers to this as Direct Failure or Indirect Failure. Let´s elaborate; say we have SW1 (RB), SW2 and SW3 connected to each other, and the link between SW1 and SW2 fails. From SW1 and SW2´s perspective, this will be a Direct Failure causing a 30 seconds re-convergence, because as soon as the link goes down, SW2´s port will move to the Listening state (15secs Forward delay) and start sending BPDUs advertising itself as RB. Then, it´ll move to the Learning state (again, 15secs Forward delay) and start learning MAC address and then, after 30 seconds, it transitions to the forwarding state. Meanwhile, for SW3 this will be an Indirect Failure (it did not happen on any of its links) and this will cause a 50 seconds re-convergence because as soon as SW3 receives the BPDU from SW2 advertising itself as RB, SW3 will start its Max Age timer (20 secs). After Max Age, if it doesn't receive any BPDUs from SW1, it will erase SW1´s as RB and enter SW2 in its place. However, in this case, this will not happen because SW3 will still receive a better BPDUs from SW1 so it´ll send BPDUs out to SW2 saying, “hey I have a better RB than you and I can get to in with a cost of 19”. Direct Failure: Failure occurred on one of the switch´s links: No Blocking State, directly to Listening. Listening - Transitional state. (15secs by default or Forward Delay) Learning - Transitional state. (15secs by default  or Forward Delay) Forward - Stable state.   Indirect Failure: Failure did not occurred on one of the switch´s links: Blocking - Stable state. (20secs by default or 10 x Hello Timer) Listening - Transitional state. (15secs by default or Forward Delay) Learning - Transitional state. (15secs by default  or Forward Delay) Forward - Stable state.   Port Roles. We are going to get into the details of the Election Process just ahead, for now let´s just say that during this process, 1 st the RB is elected and then the ports that are going to participate on the STP topology, are elected as one of three STP Port Roles, these are the Root Port (RP), Designated Port (DP) or non-Designated Port (non-DP). Here they are: Root Bridge. The RB is the center of the universe as far as STP is concerned. The RB sends out a BPDU called the Configuration BPDU or CBPDUs and also controls the various STP timers. Root Port. Root Ports (RP) are the ports on non-RB switches (1 per switch) that have the best path to the RB itself. Think of the RPs as the upstream ports reaching up towards the RB. These ports will be in the forwarding state. Designated Ports. A Designated Port (DP) is the port on each network segment that connects its segment to best segment to the RB. Think of DPs as downstream ports forwarding CBPDUs from the RB. These ports will be in the forwarding state . Non-Designated Ports.  Any remaining port that was not elected RP nor DP will be a non-DP. These ports will be Blocking. They will only receive and process STP BPDUs but will discard any other type of frames.   In the picture below, the Election Process has ended and all ports are functioning as either, Root Ports (RP), Designated Ports (DP) or non-Designated Ports (non-DP). Notice that RPs and DPs are Forwarding data and non-DPs are Blocking, as stated before. Check your understanding, compare the picture above with the information in the following table: Port Cost. Every link In an STP topology has a cost, and this cost is associated with each link´s speed. After the Root Bridge has been elected, which is the 1st step in the Election Process, the process needs to determine which are going to be the RPs and DPs respectively. This is done by adding the link´s cost (aka Port Cost) values along every individual link from non-RBs to the RB, and the path with the lowest path-cost wins the election.   The STP Ports cost is a configurable value, but its default values are shown below. Port costs is provably the most easy to understand concept in STP because it is pretty straight forward, but here is a picture that makes it easier: Election Process. Ok, so after mentioning the infamous “Election Process” several times now, let´s see what it is about. I remember when I started reading about the election process, I was really confused about the values the STA uses to make each election. Well, it wasn't the values exactly, those are pretty straight forward, it was the tiebreakers I couldn't find a place for and I think it was because of the way it was explained in the literature I was reading that time. So before we get into the details about the process itself, let me show you what those values are and when they are used. The values listed below are the only 4 values that STA considers for RB election and for RPs / DPs election: Now, the 1st entry, Lowest Bridge ID, is the only value the STA uses to elect the Root Bridge and it is called Bridge-ID or just BID. We will see how and what the Bridge-ID is in just a second, for now remember that the Bridge-ID is the value used to choose the RB. The 2nd entry is the Lowest Path-Cost to RB and it is used when the STA elects RP s and also DP s. The 3 rd and 4 th entries are ONLY used for RP/DP if and ONLY if there is a tie , specifically, a path-cost tie for RP and DP election . So, summarizing: Let´s elaborate; if, and only if, there is a tie for RP or DP election (the path-costs are equal), the process will examine the next value looking for a tie breaker, and this value is Lowest Sender´s BID, which is the Bridge ID of the switch that sent the BPDU. If the tie persists, the process moves on to the second and final tiebreaker; the Lowest Sender´s Port ID, which is the lowest port number on the switch that sent the BPDU. Let´s examine the topology below: As you can see, the STP topology above has already converged and we can see that the RB elected is SW1 and it´s easy to see why, it´s because its BID, 327690007.xxxx.xxxx.xxxx is lower than SW2´s BID. Remember the first value on our list a minute ago? It was Lowest Bridge-ID and SW1 has the lowest BID . I´ll explain why a little bit ahead. . We can also see that SW2 has already elected its RP which is Fa0/1, but let´s see why; The STA will look for Lowest Path-Cost to RB, but this was not possible because both paths to the RB have a path-cost of 19. The 1 st tiebreaker calls for Lowest Sender´s BID, again this is not possible because there is only one neighbor (the RB) and the BPDUs received by SW2 from SW1 will have the same BID, so tied again. So we come to the 2 nd tiebreaker, Lowest Sender´s Port ID, the lowest port on the RB is F0/1, so this is the port that will be elected RP or DP, depending on what was being elected. The process for RP or DP election uses the same value, lowest path-cost, the difference is that for RP the STA looks for lowest cost to RB from the non-RB switch to the RB and for DP it´s from the network segment to the RB... it is just about perspective. Bridge Protocol Data Unit - BPDU .   We've also mentioned through out this document that switches, in an STP domain, use a special frame to exchange STP data between them, so let´s talk about the BPDU. There are 2 types of Bridge Protocol Data Unit - BPDUs; Configuration BPDUs (CBPDU) and Topology Change Notification BPDUs (TCN). The CBPDUs, which is sent out ONLY by the RB, carries the necessary information downstream for switches to make their decisions during the Election Process for Root Bridge (RB), Root Port (RP), Designated Port (DP) and Non-Designated Port (non-DP) among other things. It also holds the timers mentioned earlier as the RB sets all the different timers as well.   Every non-RB switch will receive every 2 seconds by default (or Hello Timer ), a CBPDU from the RB on its Root Port (RP), notice that this is downstream. The non-RB switch will only send a BPDU, the TCN BPDU out of its RP (upstream) when it has to inform about a topology change (i.e. a link went down). When the other switches receive the TCN, they will forward the TCN upstream and reply with a TCAck downstream to the switch that sent the TCN, and the process will repeat until the RB is reached. Note: Think of RPs and DPs like this: RPs send BPDUs UPSTREAM towards the Root Bridge (hence the name, Root Port) and DPs send BPDUs DOWNSTREAM towards non-RB switches.   The picture below (from http://www.cisco.com/c/en/us/support/docs/lan-switching/spanning-tree-protocol/12013-17.html#topic2 ) demonstrates this. When the RB finally receives the TCN, it will reply with CBPDU that has its Configuration Change (TC) bit set to 1 and NON-RBs will forward this BPDU downstream so every switch knows about the topology change event (switches receive and process this BPDU, even on blocking ports) and they can start the re-convergence process to accommodate the topology change. The picture below (from http://www.cisco.com/c/en/us/support/docs/lan-switching/spanning-tree-protocol/12013-17.html#topic2 ) demonstrates this. BRIDGE ID - BID . As I said before, the CBPDU is the BPDUs used during convergence, it contains, among other fields, the Bridge-ID or BID which is used for RB election.  Let´s see how STP come up with the Bridge Id. It consists of the switch Priority value, this value is configurable (in multiples of 4069, we´ll see why later) and by default is 32768, plus the System ID Extension, which is the Vlan number and finally the MAC address. Notice that the priority went up from 32768 to 32868, as a result of adding the default priority + sys-id-ext. Again, the sys-id-ext. Is the Vlan value, in this case 100.   With STP 802.1D, the BID consisted of 8 bytes divided in two, as follows: the first 2 bytes (16bits) corresponds to the Bridge Priority and the remaining 6 bytes corresponds to the MAC address.   As the following picture from http://www.firewall.cx/networking-topics/protocols/spanning-tree-protocol/1054-spanning-tree-protocol-root-bridge-election.html demonstrates. As I stated before, STP 802.1D ran a single instance of STP for the entire network, but as networks started getting bigger, more complex and then Vlans were introduced, it was necessary to run multiple instances of STP, and so it was necessary to include Vlan information in the BID. This was accomplished by using 12 out of the 16bits from the Priority field in the 802.1D BID to include the Vlan number.  This subfield was called System ID Extension and notice that 2 to the 12th (12 is the number of bits borrowed) is 4096, exactly the maximum number of Vlans allowed. As the following picture from http://www.firewall.cx/networking-topics/protocols/spanning-tree-protocol/1054-spanning-tree-protocol-root-bridge-election.html indicates. So, from the 2 bytes Priority field, the first 12 least significant bits (the first 12 bits on the right) were borrowed to accommodate the Vlan number. This means, obviously, that the Priority field has been reduce to only 4bits. This is why, where before (on 802.1D) it was possible to have any Priority value from 0 - 65,536 (2 to 16th), now (on any Per Vlan variant) we can only get from 0 - 61440 but in multiples of 4096 only, this gives us a total of 16 possibilities. But this is not a limitation because there are no scenarios (not that I can think of, at least) where more than 16 different Priority values would be needed. If you look at the picture below, specifically the place values on the Bridge Priority field, you´ll see that the least significant bit has a place value of 4096. This means that the Bridge Priority field cannot use the place values 1, 2, 4, 8, 16, 32, … and so on. It only has 4096, 8192, 16384 and 32768 to work with and therefor we can only have bridge priority values from 0  to  61440, expressed in multiples of 4069. Picture from http://www.firewall.cx/networking-topics/protocols/spanning-tree-protocol/1054-spanning-tree-protocol-root-bridge-election.html ROOT BRIDGE. OK, so now that you've read about what is needed for the Election process, let´s talk about it in detail. The Root Bridge is the main switch in the topology and every non-RB will have a port called a Root Port pointing upstream through the lowest path-cost to the RB.   RBs have a couple of very specifics tasks: It is the only switch that sends CBPDUs. Imposes all the STP timers   Root Bridge Election Process. When switches come online, they do not know yet if they are the only switch on the network or if there are hundreds of switches, and so they will start flooding the network with their own CBPDUs advertising their Bridge-ID and themselves as Root Bridge. In other words, in the CBPDUs that they are flooding onto the network, the Root BID, which is the BID of the switch that switches believe is the RB and the Bridge ID, which is the BID of the switch sending the CBPDU, will have identical values. As soon as they receive a CBPDU from another switch, they realize that they are not alone, and at that moment the election process will begin.   Election process: The first part of the BID , the priority field , will be compared. If one of the priority value in the CBPDUs is the lowest, the corresponding switch will be elected RB and the RB election process will stop. If two or more priority values are tied for RB (their Priority values are identical), the MAC address will be compared (the MAC address is considered only in case a tie). The switch that has the BID with the lowest MAC among the switches that are tied for Priority, will be elected RB. ROOT PORTS. A Root Port is a port on a non-root bridge switch (only 1 per non-RB switch and there is NO RP on the Root Bridge, only DPs remember) that has the lowest path-cost to the Root Bridge. Remember, on the inverted tree analogy, the RP sends BPDUs upstream towards the RB.   Root Port Election Process. The RB floods its CBPDU advertising a Cost to RB value of 0, because it is the RB so there is no cost to get to the RB, of course. The other switches will receive this CBPDU and add the cost of the port it received the CBPDU on, to the advertised Cost to RB value on the CBPDU received, which is 0. For example, if the CBPDU comes in Fa0/1, the switch will ad 19 to 0 (if you look at the Port Costs table you can see that the cost for a 100Mbps link is 19) so, 19 + 0=19. So this switch will forward a copy of the CBPDU received advertising a Cost to RB value of 19. The next switch will receive this BPDU and again add the cost value of the port it received it in (let´s say that it is a 1Gbps link)  to the Cost to RB value advertised in the BPDU received, which is 19, so 4 + 19=23. When this switch send its own BPDU, it will advertise a Cost to RB value of 23. This same process will repeat until the port with the lowest -cumulative- path-cost on each non-RB switch is elected Root Port.   Let´s follow this same example step by step: RB floods a CBPDU advertising a Cost to RB of 0 (zero). This makes sense because there is a cost of 0 for the RB to get to itslef. Non-RBs receive this CBPDU and they add the cost of its port to the advertised Cost to RB in the CBPDU. So Cost to RB(0) + cost of 100Mbps(19) = 19. The non-RB sends its own copy of the CBPDU advertising a Cost to RB of 19 The next non-RB downstream receives the BPDU advertising a Cost to RB of 19. The port in which this BPDU came into is a 1Gbps port, which has a cost of 4. The switch adds 19 + 4 = 23 and sends out a BPDU with an advertised Cost to RB of 23. The process repeats until all the RPs have been elected. DESIGNAED PORTS.   A Designated Port is the port forwarding BPDUs to non-RB switches downstream. These BPDUs will be coming into the non-RBs RP s OR non-DP s (Remember, non-DP are blocking ports but they receive and process BPDUs still). There is 1 DP per network segment, for example, if there are 7 network segments in total, there will be 7 DP total. You can also think of a DP as the port that connects the segment it belongs to, to the lowest patch-cost segment to the RB. Also, the switch that contains the DP for a particular segment, is referred to as the designated switch for that segment. Designated Port Election Process. The process to elect Designated Ports starts where the RP process ends and, just like the RP process, looks for the lowest path-cost to the RB. During the DP election process we need to look at it in a “per segment basis”.   Let´s look at the process from the beginning and you´ll see what I mean:  Root Bridge: The process looks at the whole topology to find a Root Bridge: Lowest Priority value or lowest BID if there is a  Priority tie , wins.  Root Port: Now that everyone knows who is the RB, the STP process looks at each non-RB switch for the 1 port that has the lowest cost to get to the RB.  Designated Port: In this step, the process looks at each network segments and elects the 1 port that has the lowest path cost to the RB .   The process no longer has to calculate anything. Every port remaining that hasn't been elected RP nor DP, become non-DP. You might get a bit confused on RP and DP election process because both look for the l owest path-cost to the bridge. It seems that the process is looking for two different things considering the same value... and that´s correct!. The exact same value is considered, what makes the difference is the point of reference; For RP, is the lowest path-cost from the switch and for DP, is the lowest path-cost from the network segment. Additional STP Features. Being that this technology has been around for a long time, different updates were introduced over the years. Among these updates, there are a few features that we need to talk about, and those features are Etherchannel, PortFast and BPDU Guard. Etherchannel. Please observe the picture bellow for a moment. As you can see, they are the same topology but something is different about the ports states, isn't it? STP is running on both these topologies yet some ports on the top topology are blocked and some are not. But this is OK, STP does this in order to prevent loops, right? So, if STP is running on both topologies, how come the one on the bottom has all of its ports in the Forwarding state? Here is the answer; the topology at the bottom has EtherChannel configured. Each pair of links from switch to switch (in our example) are logically bundle together and are treated as one single link called Port-Channel and since the links are treated as a single interface, all the ports are forwarding. With EtherChannel (aka Link Aggregation) we can bundle up to eight, same speed, parallel links together, and this is beneficial in many ways; it provides a higher bandwidth between the switches, it can load-balance traffic across the links involved and it provides redundancy still because even though the Port-Channel is treated as a single interface, the links inside can still work independently. Because of the fact that the links can still work independently, EtherChannel eliminates the necessity for STP to re-converge in case of a failure. This is because, if one of the links inside the Port-Channel goes down, STP will not re-converge and it will continue working as long as one of the links is still up. EtherChannel´s Load-balancing. Let´s talk a little bit about load-balancing; when we hear that traffic is going to load-balanced, we imagine bits being distributed evenly through all the links involved, right? Well, that might not be the case here, this is because EtherChannel´s load-balancing has a few methods to distribute the load, that we can pick from and configure on our switch using the port-channel load-balance (method value) command. Without going too deep into the details (not a CCNA topic), here´s a table from https://ls-a.org/doku.php?id=school:ccnp_1a_chapter6_cert showing these methods: Link Aggregation Protocols. There are two different protocols for Link Aggregation supported by Cisco switches; these are PAgP (Port Aggregation Protocol, Cisco proprietary) and LACP (Link Aggregation Control Protocol) and this is the industry standard, IEEE 802.3AD. PAgP and LACP Port Negotiation. When we configure EtherChannel on the switches, all ports on each side of the links need to have the same values on; speed, duplex and Vlan assignments. If that is the case, the ports will be able to negotiate a Port-Channel between them if, the negotiation options (referred to as channel modes), are correct at each end. Depending on the channel mode the ports are in, they will either send out negotiation requests, wait for a negotiation request, both or neither. If a port on one side is waiting for a request, and the port on the other side is sending out requests, a Port-Channel will be formed. Since there are two Port Aggregation protocols supported by Cisco, PAgP and LACP, there are also two similar sets of channel modes for each of them. PAgP: The channel modes for PAgP are ON, AUTO and DESIRABLE. ON: does not send requests nor does it listens for them . AUTO: does not send requests but it listens for them. DESIREBLE: sends and listens for requests. LACP: The only difference between PAgP and LACP are the modes names, but they work the same way as PAgP. The channel modes for LACP are ON, PASSIVE and ACTIVE. ON: does not send requests nor does it listens for them . PASSIVE: does not send requests but it listens for them. ACTIVE: sends and listens for requests. PortFast and BPDU Guard. As you already know, when a port is participating in STP, before it is ready to forward data, it needs to go through the Listening and Learning states and this will take 30 seconds by default. What if there is an end device, such as a PC, connected to this port? Well... some of the more modern PCs are able to boot up in less then 30 seconds. If this is the case, the PC might not be able to get an IP address through DHCP, or it´ll simply be siting there waiting to be able to communicate, wasting time. There is a way we can go around this, there is a feature introduced by Cisco called PortFast and the way it works is very simple; by configuring PortFast on a port, we are telling it that no BPDUs will be coming through it, so it should become active and ready to forward frames right away. In other words, the port will NOT go through the 30 seconds delay from the STP´s Forward Delay timer. Now, imagine that PortFast is configured on a port that runs to an office cubicle. What if someone comes along and plugs in a switch into this port? If that happens, BPDUs will start going through this port (because PortFast does not block any frames), so something is wrong, correct?... well, we can do something about that also. By also configuring the feature BPDU Guard on the same port that we´ve configured PortFast , we are telling the port that IF it receives a BPDU , intermediately put the port in a error disabled state. A port that is in an error disabled state, will not process any frames until the commands shutdown / no shutdown are issued on the port. -------------------------------------------------------------------------------------------------------------------- References. Users of The Cisco Learning Network - https://learningnetwork.cisco.com/welcome Cisco CCNA R&S 200-120 Official Cert Guide by Wendell Odom Cisco CCNA R&S ICND2 200-101 Official Cert Guide by Wendell Odom Cisco CCNP SWITCH Simplified Vol.1 by Paul Browning ... View more

Hi guys, My name is Gerald C. Paciello, but people call me Gary - long story :O) -. I am currently preparing to take my certification exam here in Argentina and as part of my study plan, I decided to do two things; 1st, start participating on networking forums -what better forum to start in than the Cisco Support Community- and 2nd, I created a Youtube channel called Broadcast Storm to which I started uploading videos. The reason I did this is because I believe that if you truly understand something, you should be able to explain it. But what good is it if you explain it, but people cannot understand you, right? :Ob  So this is where you guys come in -whoever wants to help out of course-. All I need is feed back regarding the technical explanation. I want to know if what I am explaining is clear enough, understandable. First thing you are going to notice, if you visit the channel, is that 1st, it is brand new and there are only 3 videos regarding STP so far and 2nd, the production quality of the videos suck big time. I have a cousin that is more into video creation and is far more creative than me on that aspect who is going to help me out but he is unavailable at the moment. So I´ll worry about the look and feel of the channel later. I do not care about the cosmetics right now, I just want to know if what I am explaining on the video is clear enough. Thanks guys, all of you. ... View more