Archive for December, 2014
We know that for switches to cooperate inside each region the following must be configured the same:
- Name – Case Sensitive
- Revision – Any number, but should be the same
- Instance mappings and their respective VLANs
Now, what about the VLANs themselves? What about switches and security? I looked all over for this answer and it was vague at best and each vendors documentation said something a little different from each others. However, this is just my preliminary testing, I added multiple instances to my spanning-tree setup on my Cisco Catalyst 3750. My scenario was as follows along with the outputs:
- Two instances
- Instance 1 had all the real VLANs that were actual VLANs on the switch
- Instance 2 had 2 VLANs mapped
- The first test of MIST2 was with both VLANs not being defined on the switch
- The second test of MIST2 was with one VLAN defined and the other not
- The third test of MIST2 was with both the VLANs defined
Because MST instances themselves do not communicate the actual VLANs or VLAN mappings, and IST/CIST does not actually communicate the actual VLAN-to-Instance mapping either. Instead, we rely on IST0 to transmit the BPDUs that contain our information like: name, revision, checksum/Config digest/hash and the actual configuration digest/checkum/hash is the value to which each switch will calculate to determine if they’re operating in the exact same region or in different regions. The digest/hash/checksum is calculated based on parameters present in the MST configuration table. Want to know more about the hashing? Here is a link: 802.1s explained.
The information is long and boring, but do a search for “digest” and you’ll find yourself deep into figuring out how this all works. The test results are soon to come, I am working on both Catalyst and Nexus outputs to benefit not just enterprise and branch, but for those in the data center who’re having to work in vPC hybrid environments with STP attached devices. More to come…
So, most of you probably got here because you’re probably on your CCIE track and you’re hearing a ton about the 32-bit words in the IPv4 headers and looking for an answer to the topic. It is without question that most may never know exactly what they’re talking about when they say “word” and this can lead to some confusion. First, the definition of a word from Wikipedia is:
“A word is basically a fixed-sized group of digits (binary or decimal) that are handled as a unit by the instruction set or the hardware of the processor. The number of digits in a word (the word size, word width, or word length) is an important characteristic of any specific processor design or computer architecture.”
Essentially, this means each 32 bits, 32 different positions where the values can be 0 or 1 in binary, is a “WORD”. Thus, when they’re referencing the IPv4 header length in a packet capture, you’ll see the size of the header. That header size is calculated by looking at the raw header, generally the next position after the Type, and you’ll find a hexadecimal value, lets say D, which is 13. Thus, you have 13 different 32-bit words.
Now, 13*32=416. Take the 416/8=52 bytes in the IPv4 header. Why 8? There are 8 bits in each byte. So, the next time you hear someone mention there are X number of 32-bit words in an IPv4 header, you now have some idea of what they’re talking about.
Providing you’re either: 1. Using a hostname of the device or 2. You’re positive it will receive the same IP, if you’re using an IP address to connect to your machine using RDP that obtains its IP parameters using DHCP:
ipconfig /release && ipconfig /renew
As simple as that. In fact, you can use the same operation “&&” on a Linux box with a BASH shell using whatever interface configuration commands you’re using, if you don’t have a script which already does it for you.