112 Results Found
In 1998, the Internet Engineering Task Force (IETF) released RFC 2460, outlining the technical specifications of IPv6, which addressed the shortcomings of the aging IPv4 protocol. As with any evolution of technology, new elements exist in the protocol that may seem strange and unfamiliar. This certainly includes address representation, space, and so forth, but also includes a number of different types of addresses as well. A subset of these new addressing types has corresponding types in IPv4, but many will seem significantly different. The purpose of this white paper is to examine addressing classifications in detail and outline their functions within the context of the protocol.
Depending on the switch vendor, the exact steps will vary on how to set up and configure VLANs on a switch. For the network design shown, the general process for setting up VLANs on the switch is:
Now that the network is installed, each switch has a bridge ID number, and the root switch has been elected, the next step is for each switch to perform a calculation to determine the best link to the root switch. Each switch will do this by comparing the path cost for each link based on the speed. For paths that go through one or more other switches, the link costs are added. The switch compares this aggregate value to the other link costs to determine the best path to the root switch.
That depends on their configurations. For example: While it makes very good sense to include redundant physical links in a network, connecting switches in loops, without taking the appropriate measures, will cause havoc on a network. Without the correct measures, a switch floods broadcast frames out all of its ports, causing serious problems for the network devices. The main problem is a broadcast storm where broadcast frames are flooded through every switch until all available bandwidth is used and all network devices have more inbound frames than they can process.
I recently responded to a message on LinkedIn from a regular reader of this blog. He asked several questions which I will answer over the course of several posts. As part of his first question, he described a strategy report that his group is producing. The audience for this strategy report considers ITIL important to the future of their business, and so he must describe which ITIL processes his data center operations group works most closely with.
As we discussed previously, Cisco created the Nexus Operating System (NX-OS) to power its next-generation data-center switching platform. While this new OS shares many similarities to the original IOS, there are some definite differences that you need to be aware of as you begin using it.
The most obvious difference is that hubs operate at Layer 1 of the OSI model while bridges and switches work with MAC addresses at Layer 2 of the OSI model. Hubs are really just multi-port repeaters. They ignore the content of an Ethernet frame and simply resend every frame they receive out every interface on the hub. The challenge is that the Ethernet frames will show up at every device attached to a hub instead of just the intended destination (a security gap), and inbound frames often collide with outbound frames (a performance issue).
The biggest difference between Ethernet II and 802.3 is the fields of their Ethernet headers. Ethernet II is much more popular - find out why in this post.
“Twisted Pair” is another way to identify a network cabling solution that’s also called Unshielded Twisted Pair (UTP) and was invented by Alexander Graham Bell in 1881. Indoor business telephone applications use them in 25-pair bundles. In homes, they were down to four wires, but in networking we use them in 8-wire cables. By twisting the pairs at different rates (twists per foot), cable manufacturers can reduce the electromagnetic pulses coming from the cable while improving the cable’s ability to reject common electronic noise from the environment.
Here are some secrets, tips, and tricks for virtualizing your datacenter. We want to introduce some best practices for virtualization, while not being too biased towards one virtualization vendor or another. We'll use some common examples of products and tools that work with VMware's vSphere and Microsoft's Hyper-V, but with an eye toward virtualization in general, and not the specifics of any of the capable platforms that could be used). We will assume, however, that bare metal hypervisors, in other words virtualization platforms where the hyper visor is the OS, will be used as opposed to running a hypervisor on top of an existing general-purpose operating system (which is great in a lab, but terrible for data center projects).