Tag Archives: Spanning Tree Protocol

CCNP: Switch – Part 7

Advanced Spanning Tree Protocol

We have looked at STP, but now it is time to dive a little deeper into this. Lets look at some basic definitions, and these are grouped into two groups;

  • the fasts – port, uplink and backbone
  • the guards – root, bpdu and loop


Portfast allows an access port to go directly from blocking to forwarding mode, without going through the whole discovery / listen / learn phase. This makes for bringing host links up faster, but should only be used with host (access) ports.

For switches that have the majority of ports configured as access ports, we can globally configure portfast as follows:

conf t
spanning-tree portfast default

and then go in and change each port that you do not need portfast on by issuing:

no spanning-tree portfast

Best practice however would dictate that ports be configured on a per port basis, or by using the port range command. The other thing to remember is that these ports do not broadcast TCN BPDUs.


Both uplinkfast and backbonefast get around the long delay inherent in the transition from blocking to forwarding.  This is a bit like portfast, but where portfast disables STP on an access port, and does not transmit TCN BPDUs, uplink fast does. This enables a rapid transition from blocking to forwarding on redundant trunk ports.

The problem solved here is that using STP; if a primary link goes down, it can take up to 50 seconds for a backup link to come up. That is too long in todays networks.

We can create what is termed and uplink group. These are a group of links that can be used for inter switch communication, and need to come up fast if one goes down. Essentially when one goes down, STP immediately brings up a backup link without going through the learning and listening phases.

  • Best practice is to use this on the access layer only.
  • Uplinkfast can only be enabled globally, on all VLANs.
  • Uplinkfast cannot be enabled on a root switch

So what happens when if a root port goes down, a backup port comes up and then the root port comes back up again. STP will attempt to make the root port the primary link again, however it does wait a little while as determined by the following:

(2 x fdw delay ) + 5 seconds = 2 x 20 seconds + 5 = 45.

When uplinkfast is enabled on a switch, to ensure that the switch does not become the root switch, the switch priority is set to 49152. This is well above the default of 32768.

The STP port cost is also increased by 3000, making it unlikely that downstream switches will use this link as a root link.

The command to enable this is the global command Spanning-tree uplinkfast

So how does Uplinkfast work?
From Cisco: The UplinkFast feature is designed to run in a switched environment when the switch has at least one alternate/backup root port (port in blocking state), that is why Cisco recommends that UplinkFast be enabled only for switches with blocked ports, typically at the access-layer.

I read this mean that Uplinkfast will not be enabled on a root switch as it has no blocked ports.


Backbone fast is a Cisco proprietary system for recovering from an indirect link failure. So what on earth is an indirect link failure?

An indirect link failure is one that occurs on another switch, but affects the switch in question.

An indirect link failure is detected when an inferior BPDU is received by the switch. In essence, the switch receives two BPDUs from different switches, both claiming to be root; one might even be itself. The switch decides which has the better priority and forwards that BPDU to the other ‘root’ switch.

So how does all of this work. The protocol at work here is RLQ or Root Link Query. The RLQ is transmitted by the port that would normally receive BPDUs.

The command to turn on Backbonefast is spanning-tree backbonefast, and show spanning-tree backbonefast will give its status.

We are unlikely to come across backbonefast in the CCNP but we should be aware of it, as it can still be found in production networks; remember though, that it is Cisco proprietary so it will only be found on Cisco devices.


Root guard is configured at the port level, and prevents downstream switches from becoming the primary or secondary root switch. In essence, we use this to prevent edge switches from becoming the root, in the event of some sort of root failure.

When a superior BPDU is received on this port, the port drops the BPDU and puts the port into Root Inconsistent state.

It will stay in root-inconsistent until it stops receiving superior BPDUs, then it transitions via the normal STP listen and learn process to forwarding packets again.

The command is per interface; spanning guard root , and should be placed on all ports where there are downstream (edge) switches.

BPDU guard

Disables a port by putting it into error disable mode, when portfast is enabled (ie; it is an access port) and it starts to receive BPDUs (in other words, has another switch or network device connected to it rather than a host.)

This prevents switching loops by preventing topology changes caused by BPDUs coming from a device that should not be connected.

Per interface command is spanning-tree bpduguard enable (or disable) and the global version of the command is spanning-tree portfast bpduguard default.  This command is used on access ports and access switches to prevent rouge switches changing the switch topology, where the portfast command is used.

For instance, on my own home LAN switch, I have:

spanning-tree mode pvst
no spanning-tree optimize bpdu transmission
spanning-tree extend system-id
interface FastEthernet0/1
 spanning-tree portfast
 spanning-tree bpduguard enable
interface FastEthernet0/2
 spanning-tree portfast
 spanning-tree bpduguard enable
interface FastEthernet0/3
 spanning-tree portfast
 spanning-tree bpduguard enable
interface FastEthernet0/4
 spanning-tree portfast
 spanning-tree bpduguard enable

BPDU Filtering.

It is also possible to filter BPDUs. You might do this if you do not want your ports to go into error-disable.

The operation of BPDU filter is different depending on weather the config is global or per port.

  • In global configuration, enabling PBDU filtering will enable this on all ports running portfast, and portfast will stop running on that port, if that port recieves a BPDU.
  • In per port config, portfast continues to run and will drop (or not respond) to any BPDUs received.


Loopguard guards against switching loops. Say what? Isn’t that what spanning tree and all that stuff I wrote above, does? Well yes but;

Ports in blocking mode block data traffic, but are still able to receive BPDUs

If in a mesh of switches, one link becomes unidirectional, it is possible that a loop can occur. How does this happen? Well if a switch stops receiving BPDUs, it might start (after the max age time, default 20 seconds) to look at other BPDUs and decide to change its topology or even become the root.

If this happens, this can disrupt switch operation. Loopguard prevents this from happening by putting the unidirectional port into loop inconsistent state. It way stay in this state until the link becomes bidirectional again, when it will come out of loop inconsistent state automatically.

By default, LoopGuard is disabled but it can be enabled on a port by port, or global basis:

  •  Per port : spanning-tree guard loop
  • Global : spanning-tree loopguard default

Loop guard operates on a per VLAN basis only.which makes sense when you think about it because  spanning tree works on a per VLAN basis.

BDPU Skew Detection.

Sometimes when BPDUs are sent out from the root, in a large switch network, we might loose or delay a BPDU packet. If that delay is over 2 seconds the downstream switches might (under some circumstances) start to transition to a new topology. We don’t want this to happen.

When the switch detects this situation, it sends a syslog message, every 60 seconds, until the situation has cleared. This might be caused by heavy CPU usage or a similar transient situation, or it might be something more permanent like a broadcast storm.

In the case of the skew reaching max age time / 2 (i.e. 10 seconds) the switch will start transmitting syslog error messages immediately, as this is a critical situation.


UDLD (Uni Directional Link Detection)

This is primarily intended for fiber optic communication and troubleshooting. One of the issues with fiber connections, is that a fiber connection consists of a pair of fibers – one for each direction. In essence, fiber connections are unidirectional. If one fiber goes down, we still might have either receive or transmit capability.

To detect the status of the fiber link, UDLD transmits a frame, and:

  • if it receives a frame in return, the link is good
  • If no frame is returned, the link is considered unidirectional

UDLD operates in two modes: normal and aggressive. UDLD sends 8 packets (a sort of L2 ping) and if they are not received, it does the following:

  • Normal – generates a syslog error message only
  • Aggressive – puts the port into error disable after 8 UDLD messages.

UDLD sends one packet per second.

Can be enabled on a per port basis or globally, but however it is enabled, it only runs on fiber optic port. UDLD enable in global config mode.

It is important to note that UDLD must be running on both ends of the link in order for the UDLD link status to work.


To check the status of the above configurations, we can use show spanning-tree summary totals. This will give us the output of the spanning tree command and configurations thus:

s2940#sh spanning-tree summary totals
Switch is in pvst mode
Root bridge for: VLAN0001
EtherChannel misconfig guard is enabled
Extended system ID is enabled
Portfast Default is disabled
PortFast BPDU Guard Default is disabled
Portfast BPDU Filter Default is disabled
Loopguard Default is disabled
UplinkFast is disabled
BackboneFast is disabled
Pathcost method used is short

… or you can drill down on a per port basis by issuing the spanning-tree interface detail command.

s2940#sho spanning-tree int fa0/1 det
 Port 1 (FastEthernet0/1) of VLAN0001 is forwarding 
 Port path cost 19, Port priority 128, Port Identifier 128.1.
 Designated root has priority 32769, address 0021.1ce8.a5c0
 Designated bridge has priority 32769, address 0021.1ce8.a5c0
 Designated port id is 128.1, designated path cost 0
 Timers: message age 0, forward delay 0, hold 0
 Number of transitions to forwarding state: 1
 The port is in the portfast mode
 Link type is point-to-point by default
 Bpdu guard is enabled
 BPDU: sent 1378620, received 0
Tweet about this on TwitterShare on Google+Share on LinkedInShare on FacebookShare on RedditShare on StumbleUponEmail this to someone

Spanning Tree Protocol

I was playing with my switches and had the following set up:


Obviously STP comes into play here and 3550-24 port 14 and 2950-12 port 2 are in blocking mode. The interesting thing is that the 2950 shows it’s port in blocking mode by making the port orange rather than green, but the 3550 can’t do that. The only way you can see which port is blocking on the 3550 is to run show spanning-tree vlan


The interesting thing is that with the 2950, using the mode button on the front panel, I can switch the display mode and see the changes (speed etc), but with the 3550 not so much.

Tweet about this on TwitterShare on Google+Share on LinkedInShare on FacebookShare on RedditShare on StumbleUponEmail this to someone

CCNP: Switch – Part 4

VLANS and Trunking

1.  Virtual Local Area Networks (refresh)

From our CCNA studies, we know that VLANS are used to limit broadcast scope, but they also limit network traffic. If we want hosts on different VLANs to be able to talk to each other, we have to use one of three methods:

Note that the best practice for VLANs is one VLAN per IP subnet

2.  SwitchPort Refresh

Cisco switch ports can are by default in dynamic desirable trunking mode which means that the ports will take the configuration of what ever is connected to it. If we connect a trunk, the port will trunk, if we connect a host, it will become an access port. Trunk ports are essentially transparent to VLANs and are used to allow all traffic between switches and switches, or switches and routers. Access ports can ONLY exist in one VLAN, which also means a host can ONLY exist in one VLAN. Port VLAN membership depends on two factors:

  • Static VLAN: the port is assigned to the VLAN and therefore any host connected to that port will be in that VLAN.
  • Dynamic VLAN: the VLAN is keyed to the host mac address, and thus the port is in what ever VLAN is keyed to the mac address of the host connected to the port.

Dynamic VLANs are not a part of the NP studies, but a brief run down on Dynamic VLAN can be found here.

A quick note about VLAN membership. When a packet enters a switch, via a port, the packet is tagged with the VLAN information pertaining to the VLAN membership of that port. It is this tag, that enables ports to filter VLAN traffic.

However, to get a switch port to perform this function, we have to tell it that it is a switchport and it belongs to a specific VLAN. We do this using the switchport command:

switchport mode access
switchport access vlan n

We do this because, by default, Cisco switchports are in Dynamic Desirable mode, meaning they are looking to trunk, and want to trunk. This can be a security risk.

3.  Trunk Ports

To get traffic across a trunk, the packets have to be encapsulated, so that the VLAN information is sent with the traffic. VLANs often span multiple switches and so we tag (or encapsulate) each packet with its corresponding VLAN ID. There are a number of ways to do this:

  • Inter Switch Link Protocol (ISL) – Cisco proprietary, not really used any more.
  • IEEE 802.1q (dot1q) – industry standard, used everywhere.
  • Dynamic Trunking Protocol (DTP) – Cisco proprietary, negotiates trunks.

ISL encapsulates the frame with a 26 byte header and 4 byte (CRC) trailer packet, for all VLANs. This adds overhead. It also does not understand the concept of native VLAN. Dot1q does not add any encapsulation to the native VLAN, and a 4 byte header for other VLANs, BUT the ‘header’ information is embedded within the frame, so the frame size remains the same. This is important because a frame is 1518 bytes. Add the ISL overhead and that makes it 1548 bytes … making it a giant frame.  With Dot1q adding the 4 byte header within the frame, it just reduces the payload by 4 bytes.

So, we have:

  • Runt frame <64 bytes
  • IEEE 802.3u frames up to 1518 bytes
  • IEEE 802.3ac allows for a frame up to 1522 bytes
    • (this allows a standard frame plus 4 bytes for Dot1q)
  • Frames >1518 bytes are giants
  • some Cisco devices have hardware to handle giant frames

All of this is great but how do we turn off a trunk port and stop it from trunking?  There is no trunk port off command, we simply make it an access port.

One command we should get used to using is show vlan id n. This gives a very nice run down on the VLAN and its ports.

4.  VMPS

Dynamic VLANs, as mentioned above are out of the scope of the CCNP, but we should know a little of the basics.  Dynamic VLANs are based on the VMPS or VLAN Membership Policy Server.

With VMPS, the VLAN is assigned to a host mac address, rather than the port. In order to facilitate this, the MAC address and VLAN assignment is stored in a database, on a TFTP server.

The VMPS data base is read every time the VMPS server is power cycles. The transfer format is UDP so we must make sure we do not block UDP using ACLs.

There are a few things to remember, when using VMPS:

  • portfast is enabled when for each access port by default
  • configure the data base, before configuring the ports
  • turn off port security when using VMPS
  • do not use VMPS when using trunks


Tweet about this on TwitterShare on Google+Share on LinkedInShare on FacebookShare on RedditShare on StumbleUponEmail this to someone

CCNP: Switch – Part 3

Continuing on with more about Spanning Tree Protocol from our last post.

How do we make our switch superior?

I mentioned above how we can influence the root bridge election by changing the spanning tree priority number. Its default is 32768, but we can change that (in increments of 4096) by using the spanning-tree vlan priority command.

By reducing the priority number, we can make our switch the root.

This is all great but what if I want to change the blocking ports on a per VLAN basis?

Well we can do that. Remember that traffic cannot span vlans without a router, so:


… this is a good representation of a per vlan stp scheme. We can change the blocked port by changing the port cost on a per VLAN basis as follows:

conf t
int fa0/n
spanning-tree vlan 9 cost 5

The cost is the new route cost is 5 and that makes (in this example) the STP recalculate for VLAN 9 only, a new route to the root bridge.

Using this technique, we can do some very primitive load balancing because vlan 1 traffic will use one port, and vlan 9 traffic will use another, but will still prevent switching loops.

In addition to this, we can peg the switch as the root by issuing the command spanning-tree vlan 1 root and that will make the switch the root bridge.

About these root bridges …

We can set a primary switch or root bridge (often a core switch in a larger network), but we can also specify a secondary root switch. This is handy in the case of a large network because it defines which switch will take over in the event of the primary switch failing. This might be important for smooth (but redundant) operation

The command for this would be spanning-tree vlan 1 root primary and spanning-tree vlan1 root secondary.


In this case it would be prudent to have the core switch as the primary root bridge, with the second core switch as the secondary root bridge. To have one of the access switches as the root in the event of a failure of the primary, would not be good for the smooth running of the network.

This is all very interesting, but how fast does all this STP stuff switch?

This is a great question and is sure to be an exam question. Lets say we have an stable STP set up and a cable goes bad, we loose connection and another port must come out of blocking to keep the traffic flowing. Well it isn’t instant. if it was, we would have the potential for more switching loops. What has to happen is that potential root ports must go through a number of states to determine which port becomes the new root port.

Those states are:

  • Disabled – this is a port that is administratively down. Cisco recognizes this as a valid STP state.
  • Blocking – no frame forwarding or receiving, and can only receive BPDUs
  • Listening – receives BPDUs, and can send BPDUs, allowing the port to participate in  root bridge election
  • Learning – Learning MAC addresses, but not forwarding frames yet.
  • Forwarding – send and receive frames and so on.

We can use show spanning-tree interface to have a look at individual interfaces and their STP status. The time spent in each of these states is dictated by the STP timers.

STP Timers

The STP algorithm is controlled by a number of timers – Beware – do not mess with these without good reason; they work well just they way they are. With that said, lets go poke them a bit and see what happens.

If you need to change a timer value, you MUST change it on the root bridge. The root will then inform the rest of the switch network of the change in timer value via BPDUs.

What timers do we have to play with?

There are three timers that control the STP algorithm. They are:

  •  Hello Time (default = 2 Seconds) – sets the frequency with which the root bridge sends out configuration BPDUs.
  • Forward Delay (default = 15 seconds) – this is the timer for each of the listening and learning phases
  • Maximum Age (default = 20 seconds) – this is the amount of time a switch retains the superior BPDU info before releasing it.

The command to change the timers is the same as the command above – spanning-tree vlan x ….. because the timers are set on a per VLAN basis.

With that said, if you change the timers for what ever reason and you have a secondary root bridge set up, you should change the timers there too.

What is the significance of the Root ID Priority?

Those numbers look familiar don’t they? Especially, if like me, you have spent a lot of time working with digital systems; 32768 is a nice round number for a default!

These numbers are calculated by the STP algorithm. For instance, when the spanning-tree vlan 1 root primary and secondary commands are issued, the STP algorithm lowers the priority ID number to ensure the election of the root bridge. Also remember that the increment for this priority number is steps of 4096.

  • Primary = 24596  —  (32768 – (2 x 4096))
  • Secondary =  28692  — (32768 – (1 x 4096))

So what the command does is decrements the Priority figure by 2 x 4096 for the root, and 1 x 4096 for the secondary.  Simple right? Well its not quite like that, there is a little more detail to it.

  • If the current Root Priority >24576
    • then new root Priority = 24576 (which is 24596 – 20)
  • If the current Root Priority <24576
    • then the new priority is that number -4096
Topology Change Notifications

These were the other BPDUs I mentioned at the beginning of this (rather long) blog post. So what do TCN BPDUs do?

TCN BPDUs are transmitted from any switch when it either:

  • puts a port into forwarding mode
  • put a port into blocking mode from forwarding or learning mode

That TCN BPDU is forwarded from the originator switch to the root switch.

Each switch that received the TCN, will forward it, and send an ACK back to the originator switch.

The root switch then sends a ACK as a configuration BPDU to the rest of the switch network. That BPDU has the topology change bit set, which tells the switches to change the Mac address table Ageing time from the default 300 seconds, to  the forward delay value (15 seconds).

This allows the switches to flush their MAC address tables of invalid entries. The switch does this for a total of:

forward delay (15 seconds) + max age (20 seconds) = 35 seconds

before reverting the ageing time back to the default value of 300 seconds again.

What About Portfast?

Portfast enabled ports cannot generate TCNs (because the are connected directly to hosts only)

Switch Load Sharing

We have looked a couple of ways of load sharing or primitive load balancing with:

  • per VLAN root assignments
  • adjusting port costs on a per vlan basis
  • but we can also adjust the vlan priority on a per port basis.

In interface config mode we can use the spanning-tree command to adjust the vlan priority for a single or range of vlans. The port priority value is 0-240, with 128 being the default.


You can see the effect of the port priority here in this screen shot. I have adjusted some of the ports to have a priority of 64 in some vlans.

Of course, the best way to load balance a group of trunks is to bundle them and create an Etherchannel, but sometimes, its good to mix things up!

Tweet about this on TwitterShare on Google+Share on LinkedInShare on FacebookShare on RedditShare on StumbleUponEmail this to someone

CCNP: Switch – Part 2

The Basics

As we move deeper into switching, we will move from dealing with concepts (as we did in the CCNA), to dealing with standards as our level of detail increases. At first glance, there are a lot of standards to become familiar with so to cut down on some of the confusion, I thought I would list them here in one place so that we can see what we are dealing with:
(I pulled this list from the data sheet of a 2960 – layer three switch)

Essentially all of these standards fall into two groups:

  • Switch Operation
  • Switch interfaces

It is switch operation where most of our focus will be for this course:

802.1d  Spanning Tree Protocol
802.1p  Class of Service
802.1q  VLAN
802.1s  Rapid Spanning Tree Protocol
802.1w  Multiple Spanning Tree Protocol
802.1x  Port based access control
802.1ax Link Aggregation Control Protocol (lacp)
802.1ab Link Layer Discovery Protocol (lldp)

… but it is worth remembering switch interface specifications as well:

802.3ad  moved to IEEE 802.1AX
802.3ah  100BASE-X single- and multimode fiber only
802.3x   full duplex 10BASE-T, 100BASE-TX, 1000BASE-T ports
802.3   10BASE-T specification
802.3u  100BASE-TX specification
802.3ab 1000BASE-T specification
802.3z  1000BASE-X specification

If you would like to read these specifications, Wikipedia has all of these and more listed with links to the source documents. Enjoy!

Spanning Tree Protocol (802.1d)

We have gone back over the CCNA material, so now it is time to take a closer look at STP and its operation.

So what is STP for?

We use it to control/prevent switching loops. We like to build redundant links into our networks, because having a single point of failure is bad. However, multiple links can cause switching loops which is also bad, so we have this STP thing that prevents the switching loops, but keeps the redundant links available.

Why are switching loops bad?
  • Frames don’t/can’t get to their destination
  • unnecessary loading of the CPU
  • broadcast storms eat switch bandwidth
So how does STP fix this?

STP is controlled via BPDUs (Bridge Protocol Data Units). BPDUs are used to determine which switch is the root bridge, and thus which inter-switch links should be closed.

STP is a layer 2 protocol, so the BPDUs are transmitted to the well known Multicast MAC Address of 01-80-c2-00-00-00, every two seconds. In fact, we transmit two different types of BPDUs:

  • Topology Change Notifications (TCN)
  • Configuration

Once the root bridge is elected, ONLY the root bridge will originate configuration BPDUs, non root bridges forward copies of it.

So how is the root bridge decided?

Each switch has a BID (Bridge ID Priority Value) which comprises a two byte priority value (default value 32768) and the 6 byte MAC address; hence a BID might look like this:

32768 : aa-bb-cc-dd-ee-ff

Each switch sends out its BID, but if it receives a BID with a superior (lower) value then it will forward that BID. If not, it drops the incoming BID and keeps sending its own BID. This way, BIDs propagate the switch network, until the root is decided.

We can change the priority value to effect the outcome of this process because; if all switches have the same (default) priority value, then the lowest MAC address value wins. This may not be what we want. If you think about the Cisco switch architecture model (core, distribution, access) you probably don’t want the access switch being your root – most likely you want a core switch in that position.

Since BPDUs are sent every two seconds, the process runs quite quickly, and in a matter of a few seconds (even for a large network) the root will be decided.

We can see the status of each switch’s STP, by using the command : show spanning-tree vlan x, which will give you something that looks like this:

vlan and you can see, this switch is not the root bridge, and some of its ports are in blocking mode.

Other good commands to know for debugging this are:

  • show interface vlan (brief)
  • show interface trunk

Remember that trunk ports will not appear in the output of the show vlan command, as trunk ports are in all vlans.

So now we know what to look for, how do we know which switch is the root bridge?

There are 4 ways to tell if the switch is or is not the root:

Perform a show spanning-tree vlan 1:


  • It tells you it is root (This Bridge is root). If it is not root, that statement will not be present
  • The root does not have blocked ports; all root ports are in fwd mode.
  • The root ID address will show the mac address of the root switch. In this case, the bride ID address and root ID address are the same indicating that this switch is the root.
  • There are NO root ports: Root ports point TO the root and the root does not point to itself.

Here it is again as a non root switch. You can see the Root ID is not the same as the Bridge ID, and once of the ports is a root port.


And how does the switch decide which ports to block and which ports to forward?

This is decided by path cost. As we saw from our CCNA studies, each port has a path cost determined by its speed. (remember this?)


The path cost is locally significant only. What is more important is the root path cost. This is a cumulative number that is transmitted via BPDUs as the BPDUs are forwarded across the network. The lowest cumulative value is going to be the root path, and other lesser paths will be blocked thusly:



Bear in mind that the root bridge is the only switch that sends out BPDUs (once the root bridge election is complete). When transmitted, the route cost is zero, so the cumulative root cost is not added when the BPDU is transmitted, rather when it is received and forwarded.

What does that mean?

Simply put, in the example above:

  1. when the BPDU leaves the 3550 G0/1, the root cost is 0 but when the BPDU is received by G0/1 the root cost is incremented to 4.
  2. When the BPDU leaves fa0/1 on 2950-24, the root path cost is still 4.
  3. When the BPDU is received on Fa0/1 2950-12, the root path cost is incremented by 19 to 22.

But what if there is a tie?

In this case we use the port number and port priority:


In the case of equal priority (as in this case – 128) we use the lower port number.

But there is another method we can use just in case we have a situation where the route cost is equal  – as in the example above; if the GE link was an Fast Ethernet link. The route path cost would be the same so how do we tie break that? We use the switch with the superior BPDU to be in designated forward mode and the inferior switch will go into blocking mode.

Tweet about this on TwitterShare on Google+Share on LinkedInShare on FacebookShare on RedditShare on StumbleUponEmail this to someone