Blog Archives %%page%% - 2008 April | Network Ninja

« Older Entries

Newer Entries »

Monthly Archive for April, 2008

802.1D Spanning Tree Protocol

Published

Deon Botha

on April 16, 2008

in BCMSN, Certification, Cisco Systems, Concepts and Constructs and STP

. 3 Comments

If anyone was wondering I have mixed switch and bridge in this post several times please see/read the terms as ambiguous, it was intentional and I know about it.

Before reading this post check this out and you will have a quick overview on what you are going to be doing.

The 802.1D STP provides the mechanism for switches to reconfigure paths over which they forward (or block) frames. This makes for a loop-free network topology when there are redundant paths through the network in-case of failure. STP prevents loops in the following ways:

STP is implemented through the exchange of bridge protocol data unit (BPDU) messages between adjacent switches.
A single root bridge is elected to serve as the reference point from which STP creates a loop-free topology for all switches exchanging BPDUs.
Each switch, except for the root bridge, determines a root-port that provides the best path to the root bridge.
In a triangular designs the ports linking between two non-root switches make like so; one port on one switch will become a designated port and the other will become a blocking port. Thus eliminating all loops. The designated port will be on the switch with the best path to the root bridge.
Any state changes to ports (up/down) on any switch will be considered topology changing, then the Spanning Tree Algorithm (STA) must me run on all switches to adapt to the new topology.

Describing the Root Bridge:

The Root Bridge, Root Ports, and Designated Ports are used in STP to make for a loop-free network. The main information in the BPDU that the Root Bridge is concerned with is the Root ID, Bridge ID (BID) and Cost of Path. the STP topology is considered converged after a root bridge is elected and each bridge has selected its root port, designated bridge and the ports that will participate in the STP topology.

Describing the Port Roles:

On a non-root bridge there are 4 port roles

Root Port:This port exists on non-root bridges and is the port with the best path to the root bridge. Root ports forward traffic to the root bridge. The source MAC addresses received on this port will populate the MAC table. Only ONE of these ports per switch.
Designated Port:This port exists on non-root and root switches/bridges.
- For root bridges/switches all switch ports are designated ports.
- For non-root switches/bridges this is the switch port that will receive and forward frames in the direction towards the root bridge. If more than one switch exists on a segment they have an election process. Designated ports are allowed to populate the MAC table.
Non designated Port is the port that is blocking frames and is not allowed to populate MAC tables.
Disabled Port: A port on the switch that is shut down.

Port States:

Added to the port roles there are 5 port states which STP uses at different times:

Blocking: The layer-2 port is a non-designated port and does not participate in forwarding. The port receives the BPDU to determine the Root ID and which port roles each switch port assumes in the STP topology. (default 20 seconds in state) *defined by MAX AGE
Listening: this port can participate in frame forwarding according to BPDUs. The switch is receiving and sending BPDUs informing adjacent neighbours of its intention of participation in the active topology (default 15 seconds in state) *defined by FORWARD DELAY
Learning: A Layer-2 port that is preparing to participate in frame forwarding and is beginning to populating CAM table. (default 15 seconds in state) *defined by FORWARD DELAY
Forwarding: The port is considered part of the active layer-2 topology
Disabled: The port does not participate in the topology and does not participate in STP.

Port Costs:

STP port costs are calculated by the use of the media (port/interface) speed connecting the two swithes. STP path cost is a value advertised in the BPDU by each bridge. This is the total “value” of links from the root bridge to that switch in sending the BPDUs. It is used to determine the “best path” to the Root Bridge, the switch with the lowest path cost wins.

What is the BPDU:

BPDU

STP sends BPDU out every port on the switch which are configuration messages to adjacent switches. The graphic above shows the size and field information of a BPDU.

Root ID: The lowest Bridge ID (BID) in the topology
Cost of Path: cost of all links from the transmitting switch to the root bridge
BID: BID of the transmitting switch
Port ID: Transmitting switch port ID
STP Timer Values: Max age, hello-time, forward delay

The first use of the BPDU in electing a root bridge which is done through a combination of the BID which consists of a 2-byte field (also called the priority) and it’s MAC address. The root bridge is normally (by default) elected on the lowest MAC Address in the topology (because the priority is default 32768) another method to force a root bridge election to a specific switch is to manually configure the priority value field to a lower number (default is 32768).

The Command to force a switch into the root bridge primary role:
switch(config)#spanning-tree vlan 1 root primary
The Command to force a switch into the root bridge secondary role (backup):
switch(config)#spanning-tree vlan 1 root secondary
The Command to set the priority in increments of 4096:
switch(config)#spanning-tree vlan 1 priority priority

As discussed above the switch with the lowest combination of Root ID and Bridge ID will become the Root Bridge.

BPDU-Root-Bridge

The BID and Root ID are both 8 byte fields and are carried in BPDUs sent between adjacent switches. These fields are used to determine the Root Bridge in the election process. The switch with the lowest BID will assume the Root Bridge role. This process starts with a switch not knowing anything (Root ID = BID) then it sends BPDUs and Receives BPDUs; once it receives a BPDU with lower than its own BID it will place that into the Root ID field.

A root bridge maintains the stability of the forwarding paths between all switches for a single STP instance. A spanning tree instance is a configuration in which all switches exchanging BPDUs and participating in the tree negotiation are associated with a single root bridge. When this is done for all VLANs, it is called Common Spanning Tree (CST); there is also an implementation called Per VLAN spanning tree (PVST) which gives one instance, and one root bridge, for each VLAN.

BID

STP requires each switch to have a unique BID. With Per VLAN Spanning Tree (PVST) requires separate instances of spanning tree per VLAN, the BID must carry VLAN ID (VID) information. Because a MAC Address is always unique (kind of) when priority and extended system ID is appended each STP instance for each VLAN will have a unique BID.

When topology changes happen on the network, the root bridge will send messages throughout the “tree” regarding the change. This allows the content addressable memory (CAM) tables to adjust and provide for the new paths to end-host devices. This process is that a TCN BPDU (0×80 field type) is forwarded towards the root bridge after a topology change (link failure, bridge failure, port transition) the upstream bridge acknowledges with a topology change acknowledgement (TCA). This bridge then forwards to the designated bridge (closest neighbour to the root of a particular bridge). The designated bridge acknowledges with a TCA then forwards to the root bridge. This process repeats until the root bridge learns about topology changes in the network.

Load Sharing/Balancing

Load sharing or balancing is when you divide the bandwidth supplied by parallel links (think 2 connections of any sort that can give you the same end result be they internet connections, Ethernet connections, or fibre connections). In reference to STP; normally STP would block all but one parallel link to stop a loop while load sharing would want to divide the traffic between active links (in this case according to which VLAN the traffic belongs).

You can configure load sharing on trunk ports by using STP port priorities or STP path costs. For load sharing using STP ports priorities, both load-sharing links must be connected to the same switch. For load sharing using STP path costs, each load-sharing link can be connected to the same switch or to two different switches. Here is a link to a Cisco how-to document for the Catalyst 3550.

Load Sharing using Priorities

Using the STP port priority setting, this setting determines which port is enabled and which port is in the blocking state. The trunk port with the higher priority (low value) for a specific VLAN will forward trafffic for that VLAN conversely a trunk port with lower priority (high value) for the same VLAN will block.

In this way you can setup that a network with 20 VLANS in use will use 2 parrallel trunk links sending VLAN 1-10 on trunk 1, and VLAN 11-20 on trunk 2. If one link should fail the other link will send all VLAN information.

Load sharing using Path Costs

Using the above example of 20 VLANS on a network one can setup path costs on a trunk and associate these path costs to individual sets of VLANs. The VLANs keep traffic separate. Because no loop exists, STP will no disable ports and redundancy is maintained in the event of a lost link.

Enhancements

The 802.1D STP standard has been around many moons longer than VLANs. The 802.1D standard though has inherit limitations which can be overcome by using the Cisco Proprietary PVST which allows for separate instances of STP per VLAN, and other features like PortFast and UplinkFast which provide faster convergence.

There are advantages and disadvantages to PVST. An advantage is that it allows switches to be simpler in design and places a lighter load on the CPU. A disadvantage is that single spanning tree precludes load balancing and can lead to incomplete connectivity in VLANs.

There are two IEEE open standards Rapid Spanning Tree Protocol (RSTP) (802.1w) and Multiple Spanning Tree Protocol (MSTP) (802.1s) that improve on the original 802.1D STP standards. The per VLAN Rapid Spanning Tree Protocol (PVRST) allows Rapid Spanning Tree (RST) to be implemented while using the Cisco proprietary Per VLAN Spanning Tree (PVST).

Enhancements Explained PortFast

Spanning Tree PortFast causes an interface configured as a layer-2 access port to transition between blocking and forwarding without hold timers (best practice is to use PortFast on workstations and servers). If an interface receives a BPDU with PortFast configured, then spanning tree can put the port into the blocking state through the use of a feature called BPDU Gaurd.

Configuration for PortFast on a layer-2 access port forcing the port to enter forwarding immediately.
switch(config-if)#spanning-tree portfast
Configuration for PortFast globally so all layer-2 access ports are forced into the forwarding state.
switch(config)#spanning-tree portfast default
Test the configuration through the use of the following command.
switch#show running-config interface fastethernet 0/1

Resources:
Get the IEEE standards documents mentioned from their website.

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.

Transparent Bridges

Published

Deon Botha

on April 14, 2008

in BCMSN, Cabling and Equiptment, Certification, Cisco Systems, Concepts and Constructs and STP

. 0 Comments

Transparent Bridges were first developed in the 1980s by Digital Equipment Corporation which handed their work to the IEEE which incorporated the work into the IEEE 802.1 standard. When one looks at the operation of transparent bridges the basic operation reminds one of a switch because the basic operation is identical on a per-VLAN basis.

By definition end-devices don’t know that they aren’t directly connected to a server or other resources. This would mean that end-devices require no additional configuration to make them work with transparent bridges. The problem with transparent bridges is that they lack the capability to dynamically discover network topology and ensure only one path through the network.

The characteristics of a transparent bridge is that:

Transparent Bridges don’t modify frames that it forwards
Transparent Bridges learns addresses by listening and analyzing on ports for source MAC addresses. It uses these MAC addresses like a return-to-sender system where if a source MAC address for Host A is found on Port 1 when Host A sends something the Transparent Bridge assumes that by sending frames back out Port 1 for Host A it will reach Host A. The bridge then builds a table of MAC source addresses and Ports which is updated constantly.
Transparent Bridges forwards all broadcasts out all ports except the port the port that the broadcast came in on.
When a destination is unknown it forwards out all ports except the port that the unknown frame came in on (unicast flooding).

This all having been said STP provides the missing link in that it gives Ethernet and other protocol transparent bridges what it lacks. STP provides a way by which Ethernet transparent bridges can dynamically discover network topologies and ensure only one path is active through a network; thus eliminating loops.

Without STP there is no fool proof way to make a transparent bridge environment redundant. STP also protects against idiots accidental cabling things incorrectly because it prevents bridging loops.

I have been called in on a problem like this where someone decided a network cable looked untidy and plugged both ends of a RJ-45 cable into a access switch. Expert opinion said the switches in the rack server room had blown, the server was crashing, there was a virus on the network. Walking around the office and unplugging the looped network cable sorted out all problems.

Identifying Traffic Loops

Traffic loops are observed when a frame is forwarded continually and redundantly; this happens when there is no dynamic mechanism to manage multiple paths to the same destination. When a loop occurs firewalls think they are in WW3 and shut down access, switches start forwarding out all ports except the port it came in on (the LEDs look like X-Mas lights on steroids with activity), the load and activity on the network means no one is going to be doing anything until it is sorted out. Examples of this can be found in the above document or another Cisco document.

I made some pictures (I was bored) we have a sample network

Common Loop Network

That wants to send a frame from Work-Station-01 on Segment 1 to to Work-Station-02 on Segment 2 and so it begins. Work-Station-01 sends and both the bridges on Segment A see the frame making annotations in their tables that Work-Station-01 is in Segment A.

The Loop Begins

Our Packet Reaches its destination with Work-Station-02 but other things also happen like both bridges see a frame from Work-Station-01 from Port 2/2 and Port 1/2 and they make the adjustments in their tables that Work-Station-01 is in Segment B.

The Loop Reply

Work-Station-02 having received the frame wants to reply / acknowledge receipt to get the rest and sends a frame. Both bridges receive the frame and give Work-Station-02 the Access Denied sign and drop the frame because Work-Station-01 according to them is in Segment 2.

Loop Reasons

Now this all gets more interesting when anyone broadcasts something on the network. In this Work-Station-01 is going to broadcast something on the network and the fun begins. The Frame sent from Work-Station-01 is received by both bridges and forwarded out all ports except the received port like they should. The frame is received on Segment 2 by Work-Station-02 but also by both bridges (port 1/2 and port 2/2) and the bridges follow the rules and forward the frame again out all except the one it came in on. Repeat this about 100 times or until someone switches off one of the bridges or one of them just cant take the load anymore.

Looping Disaster

VLAN Configuration Errors

Published

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 autoThis shows both interfaces in switchport mode auto and will not config a trunk.swtich1(config-if)#switchport mode dynamic swtich2(config-if)#switchport mode accessThis 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.

Me: Yes, that’s the best price…

Published

Deon Botha

on April 11, 2008

in Asides

. 0 Comments

Me: Yes, that’s the best price for xxxx. Cust: I can get yyy for less. Me: Its not the same product. Cust: oh Me: Ya! yyy is half the price.

VTP Configuration

Published

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

VTP Domain
VTP mode
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.

Make 110% sure that there is no network connectivity with the NEW switch and the existing network; then power on the switch.
Change the switch VTP mode to transparent on the NEW switch.
Delete vlan.dat on the NEW Switch.
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.
Reload or power cycle the switch NEW Switch.
Verify the switch VTP mode, VTP domain name, and vlan.dat configuration.
Configure the switch with the existing network settings and a valid VTP domain name and password.
Connect the NEW switch to the network.
Verify the VLAN database has propagated.

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

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.
Have only one or two switches configured as VTP Servers and the remainder as clients.
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*
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)
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.
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.

VLAN Trunk Protocol

Published

Deon Botha

on April 10, 2008

in BCMSN, Certification, Cisco Systems, VLAN and VTP

. 1 Comment

VLAN Trunk Protocol (VTP) is what manages a consistent list of VLANs between switches on the enterprise network. All switches that share common information are grouped in VTP management domains. The “global” VLAN information shared between switches are VLAN number, name and description thereby keeping the same VLAN information shared between enterprise switches; more particular information like port assignments is kept local to each switch.

What this means is that you will have VLAN informaiton consistent on all switches of the enterprise but port assignment will have to be done manually on each switch.

Switches within a VTP Domain synchronize their VLAN databases by sending and receiving VTP advertisements over trunk links. VTP advertisements are flooded throughout a VTP domain by switches (every 5 minutes or when a change happens) over VLAN 1 (Cisco default NATIVE VLAN) using layer-2 multicast frame.

Describing the VTP:

VTP is a layer-2 messaging protocol that maintains VLAN configuration consistency between switches by managing the additions, deletions, and name changes of VLANs on all switches in a VTP domain. VTP runs over trunk links allowing interconnected switches to exchange layer-2 frames, synchronizing a single list of configured VLANS.

These are the attributes of VTP:

VTP is a Cisco Proprietary protocol.
VTP will advertise VLANs 1-1005 only.
VTP updates are exchanges only across trunk links.
Each switch operates in a given VTP mode (server, client, transparent) which determines how VTP updates re sent from and received by that switch.

These are the attributes of a VTP Domain:

A switch can only belong to one one VTP Domain.
A VTP Domain may be as small as only one switch.
VTP Updates will be exchanged only with other switches in the same domain.
The way VLAN information is exchanged between switches in the same domain depends upon the VTP mode on the switch (server, client, transparent).
By default, a Cisco Catalyst switch is in the no-management-domain state until it receives an advertisement for a domain over a trunk link, or until a management domain is configured.

These are the attributes of a VTP Modes:

VTP Mode	Feature
Server	Creates, Modifies, and deletes VLANs at the CLI Generate and forwards VTP advertisements from other switches in the same management domain. May update its own VLAN database with information received from other serves in the management domain Saves VLAN configuration information in “vlan.dat” file in Flash memory
Client	Cannot create, modify, or delete VLANs at the CLI Forwards VTP advertisements received Synchronizes its own VLAN database with latest information received from VTP server in the management domain VLAN information in RAM only, not stored in NVRAM or FLASH; must be repopulated from VTP Server if switch powered down
Transparent	Creates, modifies, and deletes VLANs for the VLAN database on the local switch only Does not generate VTP advertisements Does not update its VLAN database information received from VTP servers in the same management domain Forwards VTP advertisements received from VTP servers in the same VTP domain Always has configuration revision number of 0 Saves VLAN configuration to NVRAM

VTP Versions:

Version 2:

Supports Token Ring Switches.
Consistency checks on new VTP and VLAN configuration parameters.
Propagation of VTP updates that have an unrecognized type, length, or value.
Forwarding of VTP updates from transparent mode switches without checking the version number.

Version 3:

Support for extended VLANs.
Support for the creation and advertisement of private VLANs.
Support for VLAN instances and Multiple Spanning Tree (MSTP) mapping propagation instances.
Improved server authentication.
Protection from the wrong database accidentally being inserted into a VTP domain
Interaction with VTP Version 1 and VTP Version 2.
Ability to be configured on a per-port basis.

VTP Pruning

By default a trunk link carries all traffic for all VLANs in a VTP management domain. It is common however that all switches in the enterprise does not have all VLANs configured on all ports. VTP Pruning increases availability of bandwidth by decreasing traffic on trunk links through restriction of flooded traffic by network devices.

VTP Confiruation Revision Number

When VTP is initially configured the VTP configuration revision number is 0 (zero). Each time a VTP server modifies its VLAN information the configuration revision number is incremented by one. This new revision number is then sent out with the new VTP information and all switches with a lower configuration revision number are updated.

ECNM

There are some guidlines to using VTP in the Campus Infrastructure Model:

VTP Domain is restricted to the building Switch blocks.
VTP keeps VLAN information consistent between building distribution layer and building access layer switches.
VTP configuration errors or failures will be confined to the distribution and access layer switches.
Knowledge of all VLANs does not need to exist on all switches within the Campus infrastructure model.

VLAN Ranges

Published

Deon Botha

on April 10, 2008

in BCMSN, Certification, Cisco Systems, Concepts and Constructs and VLAN

. 1 Comment

This topic is interlinked to VLANs and as such an understanding of that topic is important. On a network each VLAN must have a unique VLAN ID (VID). The valid range depends on the trunking protocol used. This depends on how VTP Advertisements will be handled in the end accross switches in the enterprise.

ISL supports VIDs from 1 to 1023
802.1Q supports VIDs from 1 to 2094

VLAN RANGE	RANGE	USE	VTP PROPOGATED
0, 4095	Reserved	System use only	-
1	Normal	Cisco Default (Admin). Can be used; Cannot be modified or deleted.	Yes
2-1001	Normal	VLANs can be used, created and deleted.	Yes
1002-1005	Normal	Cisco Default for FDDI and Token Ring. Cannot be deleted.	Yes
1006-4096	Extended	Ethernet Only.Layer 3 ports and some software require internal VLANs. Internal VLANs in this range cannot be used if it has been allocated for this function. To display show vlan internal usage Switches running CatOS do not support this feature Best practice begin at 4094 and work downwards when using this range.	No

Network Ninja at work

Published

Deon Botha

on April 10, 2008

in Asides

. 0 Comments

Network Ninja at work

VLAN Trunks

Published

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.

VLAN Configuration

Published

Deon Botha

on April 9, 2008

in BCMSN, Certification, Cisco Systems and Concepts and Constructs

. Closed

This is a basic configuration guide on VLANs and how to get them working on Catalyst Switches. This is not in detail but should get you up and running and able to start doing what needs doing (This got me up and running just fine with my 3560’s and 2800’s).

VLAN Configuration in Global Mode
When a VLAN is created, deleted, or named the change occurs as soon as the Enter key is pressed on the keyboard.
Switch>enable Switch#configure terminal Switch(config)#vlan 3 name Vlan3 Switch(config)#end Switch#
Implementation
Step 1 Create the VLAN
Switch>enable Switch#configure terminal Switch(config)#vlan 3 name Vlan3 Switch(config)#
Step 2 Associate the VLAN with an Interface
Switch(config)#interface fastethernet 0/1 Switch(config-if)#switchport mode access Switch(config-if)#switchport access vlan 3 Switch(config-if)#exit Switch(config)#end Switch#show vlan ----output cut----
Step 3 Verify Interface
Switch#show interface fastethernet 0/1 switchport Name: Fa0/1 Switchport: Enabled Administrative mode: dynamic desirable Operational mode: static access Administrative Trunking Encapsulation: dot1q Access Mode VLAN: 3 (vlan3) Trunking native mode VLAN: 1 (default) Trunking VLANs Enabled: ALL Pruning VLANs Enabled: 2-1001 Protected: false Voice vlan: none (Inactive) Appliance trust: none
Switch#show running-config interface fastethernet 0/1 Building Configuration... ! Current Configuration :33 bytes Interface FastEthernet 0/1 switchport access vlan 3 switchport mode access end
See one of the above sections for this one Switch#show vlan

Trunking Configuration
Found below in the blurb is the example to make a link between switches / switch to router / switch to end device a trunk. It is important to note that firt off you need to have created a VLAN optionally named the VLAN. This example will show putting a interface (fastethernet 0/1) into dot1q trunking and only allowing vlan 3 and 1002-1005 over the link (default is all VLANs). We will also configure the Native VLAN to 1.
Switch>enable Switch#configure terminal Switch(config)#interface fastethernet 0/1 Switch(config-if)#shutdown Switch(config-if)#switchport trunk encapsulation dot1q Switch(config-if)#switchport trunk allowed 3, 1002-1005 Switch(config-if)#switchport mode trunk Switch(config-if)#switchport trunk native vlan 1 Switch(config-if)#switchport nonegotiate Switch(config-if)#no shutdown Switch(config-if)#end Switch(config)#exit
Now the same configuration just for ISL
Switch>enable Switch#configure terminal Switch(config)#interface fastethernet 0/1 Switch(config-if)#shutdown Switch(config-if)#switchport trunk encapsulation ISL Switch(config-if)#switchport trunk allowed 3, 1002-1005 Switch(config-if)#switchport mode trunk Switch(config-if)#switchport nonegotiate Switch(config-if)#no shutdown Switch(config-if)#end Switch(config)#exit
Supplementary Alternative Method VLAN Configuration in Database Mode
VLAN Database mode is session orientated and creation, deletion and changes are only saved when the apply or exit command is issued; there is also the option to abort and not save changes to the database.
Switch>enable Switch#configure terminal Switch(config)#vlan database Switch(vlan)#vlan 3 VLAN 3 added: Name: VLAN0003 Switch(vlan)#exit APPLY completed. Exiting.... Switch(config)#
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.

Network Ninja

Monthly Archive for April, 2008

802.1D Spanning Tree Protocol

Transparent Bridges

VLAN Configuration Errors

Me: Yes, that’s the best price…

VTP Configuration

VLAN Trunk Protocol

VLAN Ranges

Network Ninja at work

VLAN Trunks

VLAN Configuration

Search

About

Latest

Archives

Categories