Skip to content

Network Ninja

The Long Road to Cisco

  • Home
  • About
  • Legal Disclaimer
  • Archives

Less
More
Trim
Untrim
« Older
Home
Loading
Newer »

Tag Archive for 'Brand'

Linksys Brand to Disapear

Published
by
Deon Botha
on August 28, 2008
in Asides, Cisco Systems and Vine
. 0 Comments

Cisco acquired Linksys back in 2003 and the Linksys brand has been around in some way or form since then, kind of, I haven’t had problems with the product myself but have had logistics problems with the brand and this comes from up-channel from various distributors where they can’t promise due dates and shipping from Linksys.

This is a problem for the Linksys brand because although the brand as a whole has a great price point for Home, Home Office (SOHO) and Small, Medium Business (SMB) Market segments the availability sucks and not being able to promise delivery or give an indication of delivery makes using the brand as a plausible solution pointless. While an Enterprise customer might be willing to understand and “deal” that no stock is kept in a Emerging market of their class of products and that the lead time to delivery is longer that understanding is lacking with SMB customers where deals are lost on cents and the ability to start installation tomorrow.

There was talk about a year back from the channel and some of my networking buddies that the Linksys brand would be integrated into the Cisco “stable” for good, meaning that the Linksys brand would phase out totally and only one would emerge. There were obviously two views to this; while one said “Great Cisco all the way” and the other said “Linksys is a strong brand on its own, why kill it?”.

Be that as it may the first steps of the brand integration process has started. How this whole change management process will work is that soon the “Linksys a division of Cisco” will become “Linksys by Cisco” with Linksys and Cisco sharing as much product space and font size and finally only “Cisco” will be on the packaging and product. This process happens over years to get customers use to the idea and “new” packaging and branding and is the eventual process after the companies have assimilated into each other and adopted each others cultures and views.

Wasn’t around back in the day but I suppose the Catalyst Switching platform followed the same routine as this. I know that the IBM and Lexmark Printing and Imaging System did this back in the day.

Booked For Networkers at Cisco Live!

Published
by
Deon Botha
on August 19, 2008
in Cisco Systems and Vine
. 0 Comments

So I just booked for Networkers at Cisco Live! if you haven’t followed I posted about it back in June and have been looking forward to it since then. This is going to be the first time that Networkers is going to be held outside the USA and the chosen location is Johannesburg, South Africa.

Its great that Networkers is going to be in my back yard like one city over and all but DAAAAMN!!!! this better be the best conference ever because I feel raped after booking, with the invoice coming in at just under $ 1,000 USD.

To break that down its entrance for Networkers at Cisco Live with an $80 USD discount, the Techtorial session, and cause you spending so much money anyway the Social Pass (it better be open bar) to ease the pain and suffering of a long day. I’m still going to commute between cities and skip on the hotel don’t think thats going to fly over well including the ticket price.

So in short Im still majorly stoked to go but this better be the BEST conference EVER for the insane ticket price. I also somehow need to recoup the ticket price in either Keynotes, Super Sessions, Technical Breakout Sessions, Case Studies, Technical Solutions Clinic, Meet the Engineer, Techtorial Session and or Business contacts else I am going to go crazy and pocket my way through branded conference freebies that I can use for marketing/PR/advertising customer give-aways till sometime after 2010.

If you considering going book now, the $80 discout is only valid for a short period of time.

Certguard and a Blog

Published
by
Deon Botha
on June 16, 2008
in Off-Topic
. 2 Comments

Since late last week there has been some waves in the online networking community about a post by Robert Williams from CertGuard. Since that post many things have happened, I am however not going to talk about the specific situation, how it is probably affecting the mentioned CCIE etc. Some notable comment can be read from members of the networking community like Colin McNamara, Arden Packeer and Greg Ferro

I have been following the situation and reading responses and trying to figure this out for myself. I am however finding myself with more questions than answers as I try and get information to make an educated decision as to the this whole story. My main questions are around Certguard.

To kick off why this whole thing is upsetting me and probably many other people. I practice what I do on my good name, If it calls for it I spend extra non-billing hours (working days without sleep) keeping my good name in tact with clients who are not happy with a product or service either I or a competitor placed because my good name and the good name of my vendor of choice is important to me. This extends into daily life where dressing appropriately for functions, being on time for meetings (early ussually) and being affable and amiable in company goes to preserving my good name. I have spent time, been careful and made sure my name is not sullied and not dragged through any mud or tarnished by schoolboy playground antics because people buy products and services from people. Basic marketing theory says that word of mouth is the best and worst marketing where one good experience brings maybe one extra customer; one bad experience sends 10 customers away forever. In the end of the day my good name is very important to me because it is my brand and my image. This situation is upsetting because it has to do directly with this concept and the sullying of someone’s good name in a disgraceful very underhanded way.

CertGuard seems to be a self appointed Information Technology (IT) Watchdog where it concerns test taking and certifications. How this is done around the back-end isn’t so clear to me at this point. I have read that they have no affiliation with Cisco or Pearson Vue (I only care about their links with Cisco I don’t much care whether Microsoft or another vendor uses their products/services). Their website isn’t exactly transparent as to all their specifics but I will outline my thoughts and findings below.

I want to know WHAT they do, they say they keep the industry clean by focusing on braindumps websites. For those who don’t know what braindumps are these are basically compiled documents of test questions that may or may not appear in the exams. A braindump is not certified study material according to the agreement you sign every time you take a Cisco exam. The fact remains to me that they aren’t affiliated with Cisco and they make a leap somewhere from “braindumps websites” to “decertifying individuals” that is a bit far fetched and I don’t know how that happens. This leap is more than just bothering me, its annoying me, I have looked through the CertGuard website, done Google Searches and tried asking others but no one knows WHAT they do other than selling a product type service.

Personally I learnt in grade school that cheating was wrong, I received a degree without trying to write crib notes on various body parts to get them into exams (a girl wrote half the theory on her breasts in one exam thinking it was the only place the invigilator wouldn’t look) and I certainly know that unless I know something outright I am not going to pass any exam (sometime down the line I am going to look stupid if I don’t know how to do something I have written an exam on). The company doesn’t seem to be closing down braindump websites but monitoring them, they dont seem affiliated with Cisco to take away a certifications from individuals and they seem to be selling information based products to end-users and not vendors. This whole thing leaves me with more questions than answers.

What CertGuard is doing is great in theory (noble and almost altruistic) protecting the intrinsic value of something like a certification (which is not like a conferred degree) is in everyones interest that is working towards getting that certification. What is rubbing me raw though is what do they actually do? Are they working for a Vendor at a higher level or are they trying to create a new economy for validating online 3rd party course content information? Are they trying to become the de facto “trusted authority” for who you can use for content and who you cant? Or are they none of the above and I’m just to stupid to see what they really do and don’t do.

One of the links in the pecking order that’s also bothering me is how CertGuard can share/give/pass information as a “trusted authority” to Cisco/Vue (other) and as a trusted authority Cisco/Vue acts on the information by tripping someone of a certification (if at all). My concern here is that I have paid a small fortune to get learning material, certifications, hardware and training from Cisco and/or Cisco Partners, I have spent countless hours in front of books, PEC, and at training losing sleep, weekends and time I could have spent focusing on other activities. If a company who is not affiliated with Cisco, recognized by Cisco and was not given a mandate by Cisco starts to act “as-if” they are working on behalf of Cisco I am going to be a very unhappy camper and would hope Cisco Systems and the community at large cuts them down to size instead of siding with them because you may be next.

I am unsure of CertGuards place in the macro network environment and how they interact with the ecosystem at this point. Is this a fear based marketing and advertising ploy in very bad taste to drum up traffic and in the end sales for their products. Network World seems to rubber stamp them and if not endorse them fully by allowing them a place from which to gather an audience. Their website doesn’t clearly state anything substantial about them, I want specifics, facts and concrete information if they are so important to the industry. I want to know that my future as a small fish in a big pond in the network industry isn’t going to be jepordized by some unknown CEO from a company who you know but also dont know what they do (I don’t trust them nor know anything about nor care about them*) turns my world upside down one sunny day.

The modus operandi of using a highly visible public platform in the network industry to blackball a blogger without prior consultation or attempted mediation is uncouth to say the least. This is something that I don’t think I can agree was/is the correct method(s) or acceptable in the least. As a person who is active online, who writes (in my case notes from various sources) and posts them to a blog, my concern is am I going to be the next lamb to slaughter (probably not but the fear is there). As rational or irrational as that is who will be the next target for Mr Williams? If you note their services they offer Blog & Forum Monitoring (feels like big brother is watching).

I certainly don’t get paid for blogging I also don’t know anyone who does, I am certainly not going to jeopardize my future so that someone can take me out at the knees for something because they feel a need to scratch something that itches.

*An online business without a complete website explaining at least Who they are, What they do, How they do it, Where they come from, How they relate to me, Why I should care, Why they should be there and have a Telephone number and Physical address FOR THE REASON I VISITED THE SITE in plain view without the need to search for it or do a whois on the domain in my experience is trying to scam me in some way.

In this case Who is Certguard to me as a Cisco Networker? What does CertGaurd have to do with Cisco? How does Certguard do what they do with relation to Cisco and Cisco Certification and the mechanics of it? Where is their value proposition with relation to Cisco and Cisco Certification? How this relates to my studies and certification process with Cisco? Why this will and will not affect me and my life? Why CertGaurd should be there and exist at all and affect my life? and where can I call someone if they make my life hell and/or buy a plane ticket to come make someones life hell if need be?

Finally I have probably edited this thing a 100 times to get it to say what I want I am adding links to the Disclaimer and if you want to know about me and finally should anyone try and muck me around thus far all posts fall under the following notice:

This is a part of my personal BCMSN notes and research to assist myself in learning and understanding the concepts and theory for the BCMSN exam. I learn by making notes reading and writing things down and wish to file them where I can’t lose them. These notes are not to be seen, judged or mistaken for replacements to Cisco recognized and authorized training which I personally support and attend and suggest you undertake if you are going for the BCMSN Certification.

Followup: Ethan Banks is back in action, his blog post can be found here.

Followup: Robert Williams public apology to Ethan Banks and the Network Community.

VLAN Configuration Errors

Published
by
Deon Botha
on April 14, 2008
in BCMSN, Certification, Cisco Systems, Concepts and Constructs, Trunk, VLAN and VTP
. 1 Comment

Common VLAN configuration errors made when configuring VLANs are listed below.

802.1Q Native VLAN Problem

An 802.1Q trunk link doesn’t encapsulate frames but adds a tag and re-calculates the frame-check sequence (FCS) of the frame. The 802.1Q trunk also allows for untagged frames to pass through the trunk on the NATIVE VLAN. A common configuration error is when there is a trunk link and the NATIVE VLAN is not the same on both sides of the trunk causing connectivity issues.

802.1Q Native VLAN Resolution

  • NATIVE VLANs must coincide on both ends of the trunk link otherwise a trunk link may not form.
  • Cisco NATIVE VLAN is default VLAN 1, for security purposes make the NATIVE VLAN something that is not used for normal purposes.switch(config-if)#switchport trunk native vlan 1-4094
  • If there is a NATIVE VLAN mismatch CDP (if used and active) will issue a “native VLAN mismatch” error.
  • On select versions of IOS CDP may not be transmitted if VLAN 1 is not working or automatically be disabled on the trunk.
  • If there is a NATIVE VLAN mismatch on either side of an 802.1Q trunk, layer-2 loops may occur because VLAN 1 STP bridge protocol data units (BPDUs) are sent to the IEEE STP MAC untagged.
  • When troubleshooting VLANs note that a link can have one NATIVE VLAN association when in access mode and another when in trunk mode.

Trunk Link Problems

There are certain elements that determine whether a trunk link is formed or not, the elements that determine this are the trunking mode, the encapsulation type, the VTP domain, and the hardware capabilities of the connected ports.

Trunks can be configured to either statically or autonegotiate trunks with the use of Dynamic Trunking Protocol (DTP), for autonegotiation the switches must be in the same VTP Domain. There are however certain other small things to take note of about the configuration with trunk links.

Through the use of the switchport command trunks can be autonegotiated. There are certain variations of the command that will not setup a successful trunk through; the command is below and there are some of the options available: swtich(config-if)#switchport mode dynamic / auto / desirable / trunk We wish to config a trunk link the following options will not create a trunk. swtich1(config-if)#switchport mode auto
swtich2(config-if)#switchport mode auto
This shows both interfaces in switchport mode auto and will not config a trunk.swtich1(config-if)#switchport mode dynamic
swtich2(config-if)#switchport mode access
This shows one interface switchport mode dynamic desirable and the other static access and will not config a trunk.swtich1(config-if)#switchport mode trunk
swtich2(config-if)#switchport mode auto

This shows one interface switchport mode trunk and the other interface switchport interface auto. This config will not create a trunk because the interface set to trunk will not send DTP frames and then the auto interface will switch to being an access port.

This topic is something I can feel in my bones will come up in tests you either have this topic down or don’t have a clue and guestimate. I think I am going to try and know it because it’s easy enough to make a table and just learn; check out CCIE Pursuit for a table on the 3550/3560 routers and bitmindframes for more info on each DTP config state.

DTP Requirements

The reason a Network Administrator would deploy DTP is to automate to a degree the trunking process. To give you more of an explanation if a port can become a trunk (switch-switch not supported on routers), it may also be able to trunk automatically, and in some cases even negotiate the type of trunk (ISL/802.1Q). This is where DTP comes in to provide the negotiation of the trunking method with the neighbour device.

There are however requirements for DTP the main one being support for ISL or 802.1Q on both ends of the trunk (Switch A and Switch B must support and be configured with one or the other) so that DTP can do its job.

This can be expanded slightly where the switch platform does or doesn’t provide support for ISL but does support 802.1Q trunking and supports DTP like the Catalyst 4500/4000 (CatOS), which includes 2948G/2980G/4912G also the Catalyst 2950/2955/2940 series. This simply means all trunking will be done using 802.1Q.

Lastly where both ISL and 802.1Q is supported but DTP is not like the Catalyst 2900XL/3500XL/2948G-L3/4908G-L3/4840G/8500 Series.

Trunk Link Resolution

Trunk Negotiation is managed by DTP, which is Cisco proprietary, and is a point-to-point protocol (see any problems with this yet) when using DTP make sure that both ends of the link are in the same VTP Domain otherwise it wont work. Secondly because it is Cisco proprietary certain network devices wont support DTP which could cause misconfiguration cross-brands (when configuring on an interface that is connected so something non-cisco turn off DTP). Find some more information here that’s doesn’t assume you know something about DTP before jumping right in and also covers some other topics in the same post.

The correct way then to configure a port to either trunk or not would be for access ports swtich(config-if)#switchport mode access for trunking without DTP swtich(config-if)#switchport mode trunk
swtich(config-if)#switchport mode nonegotiate
then finally for encapsulation type on the trunk port swtich(config-if)#switchport trunk encapsulation dot1q
swtich(config-if)#switchport trunk encapsulation isl
. Keeping in mind that dot1q is cross-vendor and isl is also Cisco proprietary.

VTP Problems

Problem Possible Causes
Updates not received as expected
  • VTP Domain name and password must match with the server. (case
    sensitive)
  • VTP version must be compatible with the other switches on the
    domain.
  • Ensure that there is at least one server in the VTP Domain.
  • check that a trunk link exists to the VTP Server
Missing VLANs
  • Upon initial configuration, the VTP Server may have been a
    partial VLAN database, and it overwrote the existing, more complete,
    database on the existing switch.
  • VLANs were deleted individually at the VTP server, and those
    deletions will be propagated in the domain.
  • Not all Cisco switches support extended VLANs.
Too many VLANs
  • The VTP Server has a VLAN list that is more complete than the
    list needed by other switches in the domain.

The VTP Resolution and best practices are dealt with in a previous post

Trunk and VLAN Specific

Sometimes it is needed to only carry specific/certain VLANs accross trunk links. You will remember from the CCNA that by default all VLANs are allowed across a trunk link when it is created unless specifically told otherwise. This will mean that VLAN 1 through x will traverse a trunk unless you as Admin say otherwise. In some situations having all vlans moving across trunks is not the desired sitatuation.

As an example if you have VLAN 1 through 10, assume 1,3,6, and 9 is actively used on one Switch 1 and  2,4,6,8 and 10 on Switch 2.

There is no “active” users for VLANs 2,4,6,8, and 10 on Switch 1 and no active users for VLaN 1,3,6, and 9 on Switch 2 why then send these VLANs all over the place when this will be wasteful?  To change this situation one can use any one of these commands:

Switch(config-if)switchport trunk allowed vlan remove/except/add x,x,x

Using either the remove 2,4,6,8 and 10, except 2,4,6,8,10 or add 1,3,6,9 command will have the same end result of allowing only 1,3,6, and 9 across the trunk link.

Notes and Notices:

This is a part of my personal BCMSN notes and research to assist myself in learning and understanding the concepts and theory for the BCMSN exam. I learn by making notes reading and writing things down and wish to file them where I can’t lose them. These notes are not to be seen, judged or mistaken for replacements to Cisco recognized and authorized training which I personally support and attend and suggest you undertake if you are going for the BCMSN Certification.

VTP Configuration

Published
by
Deon Botha
on April 10, 2008
in BCMSN, Certification, Cisco Systems, Concepts and Constructs, VLAN and VTP
. 2 Comments

Configuring VTP is as easy as one two three, literary :-)

  1. VTP Domain
  2. VTP mode
  3. VTP password

All switches in the same VTP domain will share the VTP domain and VTP password (if a password is configured for use). It is good practice to set the VTP mode to client if switches are being added to an existing switched network that uses VTP (use it don’t use it, for more look at the next section below the configuration for the steps involved) this is unless you want all your VLAN information going missing which means you have to re-load all your VLANs for large enterprise networks this could take many hours.

Configuration
switch>enable
switch#show vlan brief
Displays a list of VLANS Configured on Switch this list will replace all other VLAN information on the network if this is to be VTP Server
switch#configure terminal
switch(config)#vtp password my_password
switch(config)#vtp domain my_domain
switch(config)#vtp version 1/2
switch(config)#vtp mode client/server/transparent
switch(config)#exit
switch#show vlan brief
Now either you will see the same VLANs or other VLANs that were advertised from the VTP Server if this is a VTP Client

Verification:
In this output, Configuration last modified by specifies the IP address of the switch that last updated the VLAN database of this switch.
switch#show vtp status
In the next output this verifies if VTP updates are being sent and received.
switch#show vtp counters

Things to keep in mind

VTP has small nuances that make it a pain to work with, the most obvious and the one I stress overly much is that VTP can create lots of work for you by deleting the entire enterprise VLAN database in a matter of seconds if you aren’t careful. This is something that you have to respect about VTP as it is a great time safer with respect to admin intense vlan creation but can also cause you headache.

Other small things being that there are 2 mainstream versions of VTP available and they are not interoperable (There is a version 3 available on big switch platforms). The default setting for VTP is Version 1 even if the switch platform supports Version 2, this is because of the interoperability issue. To use Version 2  explicitly set the server mode to Version 2 and the change will be propagated. Changes between Version 1 and Version 2 include

  • Version-dependant transparent mode where Version 1 matches VTP version and domain name before forwarding information to other switches. Version 2 forwards without checing the version number.
  • Consistency Checks are performed on VTP and VLAN parameters entered in the command line interface (CLI) or by simple network management protocol (SNMP). This prevents errors in vlan numbers and names from being propagated to other switches.
  • Token Ring support
  • Unrecognized Type-Lenght-Value (TLV) support will propagate received configuation changes even if the switch supervisor engine cannot parese of understand the message.

The VTP Domain name is case sensitive this is important and can only contain a maximum of 32 characters. If there is connectivity between two switches, there is no VTP password set and VTP is not propagating check that the CaSe is identical in the domain. For more in setting up VTP

The other final small thing is that VTP uses the configuration revision number to determine in the VTP domain whether it will accept or reject VTP advertisements. If the domain name is the same of the client or server then it checks the configuration revision number to see if it is going to update the vlan database. If the revision number of an update received on a client or server VTP switch is higher than the previous revision, then the new configuration is applied. Otherwise, the configuration is ignored. This comes back to being very careful as to the switches you just simply add to the network.

Adding a switch to VTP Network

Adding a new switch to an existing network can create a lot of work for you if you are not careful, follow these steps to make sure you aren’t shooting yourself in the foot.

This assumes that there is a “NEW” switch and an existing network to which the NEW switch is to be connected. The term “NEW” can either be right out the box brand spanking “NEW” from Cisco or “NEW” from ebay.

  1. Make 110% sure that there is no network connectivity with the NEW switch and the existing network; then power on the switch.
  2. Change the switch VTP mode to transparent on the NEW switch.
  3. Delete vlan.dat on the NEW Switch.
  4. Change the VTP domain name to something unconventional that is not in use on the network, and change the mode to client on the NEW Switch.
  5. Reload or power cycle the switch NEW Switch.
  6. Verify the switch VTP mode, VTP domain name, and vlan.dat configuration.
  7. Configure the switch with the existing network settings and a valid VTP domain name and password.
  8. Connect the NEW switch to the network.
  9. Verify the VLAN database has propagated.

There are furthermore some other best practices concerning VTP Configuration when it comes to the ECNM:

  1. The ECNM gives boundaries for VTP Domains. Not all switches need information on all VLANs (end-to-end). In the ECNM VTP Domains should be restricted to redundant distribution layer switches and access layer switches.
  2. Have only one or two switches configured as VTP Servers and the remainder as clients.
  3. Configure a password for the VTP Domain to increase security and not make more work for yourself should someone try and add a VTP switch (in sever mode) to the domain without your knowledge.

    I know of a network where a a lab switch (old network switch) used during training added to the lab network deleted the VLAN database of the enterprise network. *shrug*

  4. Manually configure the VTP domain name on all switches that are installed in the network so that the mode can be specified and the default mode of the server on all switches can be overwritten (see above for why)
  5. When you are setting up a new domain configure VTP clients switches first so that they participate passively; then configure servers to update client devices after the fact.
  6. In an existing domain, when performing clean-up, configure passwords on the servers first. clients may need to maintain current LAN information until the server contains a complete VLAN database. After the VLAN database on the server is verified as complete, client passwords can be configured to the server passwords to propagate the VLAN Database.

Some Asides that I wondered about

Doing some final revision and asking the Google about some weird questions CCIE Pursuit came up with the asnwers, this one has happened to me IRL where the switch came back up as Server. Also a question about the MD5 and VTP was neatly answered all in one visit.

Notes and Notices:

This is a part of my personal BCMSN notes and research to assist myself in learning and understanding the concepts and theory for the BCMSN exam. I learn by making notes reading and writing things down and wish to file them where I can’t lose them. These notes are not to be seen, judged or mistaken for replacements to Cisco recognized and authorized training which I personally support and attend and suggest you undertake if you are going for the BCMSN Certification.

VLAN Trunks

Published
by
Deon Botha
on April 9, 2008
in 802.1Q, BCMSN, Certification, Cisco Systems, Concepts and Constructs, ISL and Trunk
. 2 Comments

An example VLAN configured through the use of global config mode on a single switch. To support multiple VLANs that span multiple switches one uses trunks. A trunk carries the traffic of multiple VLANs over links (multiplexing) and enable the extension of a single layer-2 VLAN between switches.

A trunk can exist between two switches, a switch and a router, a switch and a trunk-capable NIC (server). If a physical link carries multiple VLANs (trunk) then each frame going onto the link must be market with a VLAN ID (VID) which is added when entering into the link and removed when forwarded to a access port. This is accomplished through the use of trunking protocols. The two trunking protocols are ISL or Cisco ISL (proprietary) and 802.1Q which is IEEE standard trunking protocol.

ISL 802.1Q
  • Proprietary
  • Non-proprietary
  • Encapsulated
  • Tagged
  • Protocol Independent
  • Protocol Dependant
  • Encapsulates the old frame in a new frame
  • Adds a field to the frame header

Depending on the trunking protocol as shown above the data sent across a trunk link is either proprietary to cisco, cross platform (dont you know thats going to be an exam question, encapsulated or tagged, and protocol independant or protocol dependant another exam question.

In short the purpose of a trunking protocol is to provide the receiving switch with a method to identify the VLAN from which the frame originated by giving it a VID as reference by which to insert the frames into the right VLAN.

ISL in Detail

Inter-Switch Link (ISL) is a Cisco Proprietary trunking protocol used to configure layer-2 trunk links. It is the original standard for trunking and pre-dates the IEEE 802.1Q standard. ISL takes the original frame and encapsulates them with a new ISL header and trailer (frame check sequence), cyclic redundancy check (CRC) before sending them on the trunk link.

Because an entirely new header is appended to the original frame, the header offers some features not found in 802.1Q like:

  • Multiple protocol support (Ethernet, Token Ring, FDDI, and ATM)
  • Supports Per VLAN Spanning Tree (PVST) Protocol
  • Does not use native VLAN, so it encapsulates every frame
  • The encapsulation process leaves the original frame unmodified

ISL Encapsulation Mechanics

When a switch port is configured as ISL the original frame, including header and frame check sequence is encapsulated before it enters the trunk. Encapsulation (CCNA) is the process of adding a additional header and trailer at the end of the original layer-2 frame. At the receiving end the new header and trailer is read and removed.

Getting more technical ISL adds a 26-byte header and a 4-byte trailer to a frame. The source VLAN-ID (VID) that comprises of a 15-bit VID field in the header. The trailer contains a Cyclic redundancy check (CRC) value to ensure data integrity. ISL adds a total of 30 bytes to a frame.

802.1Q in Detail

Like ISL the 802.1Q trunking protocol allows a single physical link to carry multiple VLANs communication. This is the non-proprietary version by the IEEE meaning that other brand kit will support it (note that other players in the market have more or less ability in following the standards even if they are open). This version rather than encapsulate the frame simply insets a tag into the original header and recalculates the frame check sequence (FCS) then retransmits the frame over the trunk link.

  • Suppport for Ethernet and Token Ring.
  • Support for 4096 VLANs (big networks, lots of VLANs)
  • Support for Common Spanning Tree (CST), Multiple Tree Protocol (MSTP), and Rapid Spanning Tree Protocol (RSTP).
  • Point-to-Multipoint topology support.
  • Support for untagged traffic over the trunk link via native VLAN.
  • Extended quality of service (QoS) support.
  • Growing standard for IP telephony links.

802.1Q Tagging Mechanics

In Ethernet, 802.1Q adds a 4 byte tag just after the source address field. The first two bytes are used as Tag Protocol Identifier (TPID) and always have a value of 0×8100 to signify an 802.1Q tag. The remaining two bytes are used as Tag Control Information (TCI) that contains a three bit field for Class-of-Service (COS); One bit of TCI is a Canonical Format Indicator (CFI) flagging whether the MAC Address are in Ethernet or Token Ring. The last 12 bits are used as VLAN ID (VID) to indicate source VLAN. These values can be 0 to 4095. VLANs 0,1 and 4095 are reserved. 802.1Q adds a total of 4 bytes to a frame.

Ethernet Frames cannot (generally) exceed 1518-bytes, known as baby giant frames (if the frame size is near or at that size) adding the 802.1Q header to a baby giant frame makes the frame oversized at 1522-bytes and could cause errors and the frame may be dropped. This shouldn’t be a problem as Cisco Catalyst are compliant with IEEE 802.3ac that extends frame size to 1522-bytes.

802.1Q and ISL

As 802.1Q is an open standard (that favours compatibility inter-vendor) and technically does the same thing (tagging vlans which may be the reason I’ve read in places that Cisco no longer supports ISL on all Switch Platforms). One of the big-ish problems with the use of ISL is that frames that are already big (frames with more than 1518 bytes of payload (MTU) a.k.a jumbo frames or baby giant frames) when encapsulated using ISL (30 bytes) get even bigger. Cisco uses propriotary hardware to deal with this encapsulation method so this shouldn’t be a problem Cisco to Cisco (it’s just so you know).

The problem with trunking Cisco to Cisco may be when one Catalyst Switch Platform supports ISL and another (Catalyst or Non-Cisco) Switch platform doesn’t (apart from the fact that a trunk won’t form). The non-ISL Catalyst switch may report baby “giant” frames and drop the frame. To solve this simply use 802.1Q as Cisco hardware is compliant with 802.3ac.

Similar to the above problem Cisco to Non-Cisco the option to use ISL is eliminated because ISL is propriotary but the Non-Cisco compliance to standards (802.3ac) means that baby giant frames may still be dropped if they exceed the 1518 payload (not actively dissing other vendors, you just don’t want to sit at a clients offices and look clueless when this may be the problem).

Native VLANs

When configuring an 802.1Q trunk, a matching native VLAN must be defined (usually default VLAN 1) on each end of the trunk link. A trunk link is inherently associated with tagging each frame with a VID. The native VLAN is to allow untagged frames across the trunk. If both ends have non-matching Native VLANs problems will arise this is a common configuration error.

Native VLANs have these attributes:

  • The VLAN that a port is associated with when not in trunking operational mode
  • The VLAN that is associated with untagged frames that are received on a switch port
  • The VLAN to which layer-2 frames will be forwarded if received untagged on an 802.1Q trunk port

Comparing this to ISL where no frames will be transported across the trunk unless tagged (encapsulated), and any un-encapsulated frames are dropped.

Notes and Notices:

This is a part of my personal BCMSN notes and research to assist myself in learning and understanding the concepts and theory for the BCMSN exam. I learn by making notes reading and writing things down and wish to file them where I can’t lose them. These notes are not to be seen, judged or mistaken for replacements to Cisco recognized and authorized training which I personally support and attend and suggest you undertake if you are going for the BCMSN Certification.


Search

About

You are currently browsing the Network Ninja weblog archives for 'brand' tag.

Latest

RSS
  • Digital Growth with your Job
  • Open Shortest Path First – OSPF Fundamentals – Scenario
  • Open Shortest Path First – OSPF Fundamentals – Questions and Answers – Question 13
  • Open Shortest Path First – OSPF Fundamentals – Questions and Answers – Question 12
  • Open Shortest Path First – OSPF Fundamentals – Questions and Answers – Question 11
  • Open Shortest Path First – OSPF Fundamentals – Questions and Answers – Question 10
  • Open Shortest Path First – OSPF Fundamentals – Questions and Answers – Question 9
  • Open Shortest Path First – OSPF Fundamentals – Questions and Answers – Question 8
  • Open Shortest Path First – OSPF Fundamentals – Questions and Answers – Question 7
  • Open Shortest Path First – OSPF Fundamentals – Questions and Answers – Question 6

Archives

  • June 2009
  • April 2009
  • March 2009
  • February 2009
  • November 2008
  • October 2008
  • September 2008
  • August 2008
  • July 2008
  • June 2008
  • May 2008
  • April 2008

Categories

  • 802.11 (7)
  • 802.1Q (1)
  • 802.1X (1)
  • AAA (1)
  • Access Point (7)
  • ACL (4)
  • Addressing (3)
  • Asides (31)
  • auto-summary (3)
  • AutoQoS (1)
  • Bandwidth (2)
  • BCMSN (55)
  • BDR (2)
  • BGP (1)
  • BPDU Filtering (1)
  • BPDU Guard (2)
  • BPDU Root Guard (1)
  • BSCI (67)
  • BSCI Notes (18)
  • BSCI Questions (48)
  • Business (1)
  • Cabling and Equiptment (3)
  • CAM (1)
  • CCDA (1)
  • CDP (1)
  • CEF (1)
  • Certification (123)
  • CIDR (2)
  • CIR (2)
  • Cisco Systems (144)
  • Concepts and Constructs (76)
  • CoS (1)
  • Cost (3)
  • DAI (1)
  • DDNS (1)
  • Debug (2)
  • DHCP Snooping (1)
  • DHCP Spoofing (1)
  • DR (3)
  • DUAL (1)
  • Dynamic ARP Inspection (1)
  • ECNM (5)
  • EIGRP (5)
  • Enterprise Architecture (7)
  • EtherChannel (1)
  • GLBP (1)
  • Hello Timer (2)
  • Hold Timer (2)
  • Hot Standby Router Protocol (1)
  • HSRP (1)
  • IGRP (1)
  • IIN (2)
  • Inter-Vlan Routing (1)
  • Interconnection Technologies (2)
  • IP Source Guard (1)
  • IS-IS (1)
  • ISL (1)
  • LACP (1)
  • Link State Advertisements (2)
  • Load Balancing (2)
  • Loop Guard (1)
  • MAC Address Flooding (1)
  • MLS (1)
  • MSTP (1)
  • NBAR (1)
  • NBMA (1)
  • Off-Topic (12)
  • OSPF (18)
  • PAgP (1)
  • passive-interface (1)
  • PoE (1)
  • Port Security (1)
  • Priority (2)
  • Proxy ARP (1)
  • PVC (1)
  • QoS (2)
  • RIP (1)
  • RIPv2 (1)
  • Root Guard (1)
  • RSTP (1)
  • Show (6)
  • Software (1)
  • SONA (2)
  • SSH (2)
  • STP (5)
  • Stub Router (3)
  • summary-address (1)
  • Support (4)
  • Switch Spoofing (1)
  • TCAM (1)
  • Telnet (2)
  • Troubleshooting (1)
  • Trunk (6)
  • Unidirectional Link Detection (1)
  • VACL (3)
  • VC (1)
  • Vine (20)
  • VLAN (11)
  • VLAN Hopping (1)
  • VLSM (1)
  • VoIP (1)
  • VRRP (1)
  • VTP (4)
  • VTY (1)
  • Wireless (7)


Styled with Sawchuk

Powered by WordPressabc and K21.0-RC7

Entries Feed and Comments Feed

52 queries. 3.3560 seconds.