Spanning Tree

Root Bridge : is the reference point of how the other switches need to build their topology. The root bridge itself does not make  any path selection decisions its only used as a reference point for the other switches to make their decisions.

Root Port – Forwarding upstream , Elected based on lowest Root Path Cost ( cumulative cost of all links to the root )

• if Tie in Cost
• Choose lowest upstream BID
• Choose lowest upstream port ID

Designated Port- Forwarding Downstream

• Lowest Root Path Cost
• Lowest  BID
• Lowest  port ID

Blocking Port – Dropping the traffic  , blocking means  i can not associate MAC addresses in the CAM table. Link in the blocking state can receive traffic inbound (BPDU , Broadcast )  but can not do MAC address learning.

Spanning timers are only adjusted on the Root Bridge , you adjust them on the non-root Switches but in wont change anything.

The show spanning Tree output does not show overall path cost to the root bridge only shows the link cost value , to get more detailed info use sh spanning-tree detail.

Normal STP (802.1d) uses four different port states.

Blocking – The port does not forward data frames.

Listening – The port does not forward frames, but it does listen to BPDUs so that it can participate in things like the election of the root bridge, root ports, and designated ports.  We saw earlier that a switch can learn info from BPDUs when not in a forwarding state

Learning – The port does not forward frames, but it does continue to listen to BPDUs and it does begin to learn MAC address information from frames that pass through the port.  If a port makes it to the learning state, the switch already knows that it will either be a designated port or a root port.  If it’s not one of those two ports types, the port will immediately go into blocking after listening and never reach the learning mode.

Forwarding – Once past the learning mode a port will move into the forwarding mode.  The port will now begin to send and receive data frames like a normal switch port and continue to learn MAC addresses on an ongoing basis.

A debug on a switch can shows us these states occurring…

*Mar  1 02:12:18.886: set portid: VLAN0001 Gi1/0/12: new port id 800C
*Mar  1 02:12:18.886: STP: VLAN0001 Gi1/0/12 -> listening
*Mar  1 02:12:20.890: %LINK-3-UPDOWN: Interface GigabitEthernet1/0/12, changed state to up
*Mar  1 02:12:21.897: %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet1/0/12, changed state to up
*Mar  1 02:12:33.893: STP: VLAN0001 Gi1/0/12 -> learning
*Mar  1 02:12:48.900: STP: VLAN0001 sent Topology Change Notice on Gi1/0/2
*Mar  1 02:12:48.900: STP: VLAN0001 Gi1/0/12 –> forwarding

Note the time difference between each event.  It takes the switch 15 seconds to transition a port between each state.  A total of 30 seconds to bring a port from blocking to forwarding.  The time between each state is referred to as the ‘forward delay’ value and in normal STP is 15 seconds by default.  There are two other times that are used.  The ‘hello’ timer is used to determine how often BPDUs are sent by switches.

REF: http://www.dasblinkenlichten.com/spanning-tree-802-1d-timers-and-misc/

The last timer is the ‘max age’ timer.  The max age timer is used to determine how long a switch should keep BPDU information heard from other switches.  That being said, once a BPDU is removed from a switches STP topology, the topology has to be recalculated.  So if a switch doesn’t see new BPDUs by the end of the max age timer, it knows that something has changed.  We can observe this behavior as well…

*Mar  1 02:24:30.557: STP: VLAN0001 heard root 32769-0012.0100.4d00 on Gi1/0/1
*Mar  1 02:24:32.402: STP: VLAN0001 heard root 32769-0012.0100.4d00 on Gi1/0/1
*Mar  1 02:24:34.407: STP: VLAN0001 heard root 32769-0012.0100.4d00 on Gi1/0/1
*Mar  1 02:24:36.412: STP: VLAN0001 heard root 32769-0012.0100.4d00 on Gi1/0/1
*Mar  1 02:24:38.417: STP: VLAN0001 heard root 32769-0012.0100.4d00 on Gi1/0/1
*Mar  1 02:24:40.422: STP: VLAN0001 heard root 32769-0012.0100.4d00 on Gi1/0/1
*Mar  1 02:24:42.427: STP: VLAN0001 heard root 32769-0012.0100.4d00 on Gi1/0/1
*Mar  1 02:24:44.440: STP: VLAN0001 heard root 32769-0012.0100.4d00 on Gi1/0/1
*Mar  1 02:24:46.436: STP: VLAN0001 heard root 32769-0012.0100.4d00 on Gi1/0/1
*Mar  1 02:24:48.441: STP: VLAN0001 heard root 32769-0012.0100.4d00 on Gi1/0/1
*Mar  1 02:24:48.550: STP: VLAN0001 Gi1/0/1 -> listening
*Mar  1 02:24:49.599: STP: VLAN0001 Topology Change rcvd on Gi1/0/1
*Mar  1 02:24:49.599: STP: VLAN0001 sent Topology Change Notice on Gi1/0/2
*Mar  1 02:25:03.558: STP: VLAN0001 Gi1/0/1 -> learning
*Mar  1 02:25:18.565: STP: VLAN0001 sent Topology Change Notice on Gi1/0/2
*Mar  1 02:25:18.565: STP: VLAN0001 Gi1/0/1 –> forwarding

The top blue section shows the 20 seconds it took for the switch to decide to do something.  In this case, I unplugged one of the links on the switch that had switch1 connected to the root switch3.  When I did this, the switch started hearing the root BPDUs on a different interface.  After the max age timer expired, it kicked the port into the normal listening, learning, forwarding process which took an additional 30 seconds (shown in green).  All told, this process took 50 seconds.

The timers in 802.1d can be adjusted, however you only need to adjust them on the root bridge.  The other MLS read the configuration information sent in the root’s BPDUs and adapt their own timers to match that of the roots.  We can see the timers present in the root bridge’s BPDUs…

UplinkFast
I talked about the uplinkfast sometime ago in this post where I talked about using it to migrate to a new port-channel.  Uplinkfast comes in handy when you have multiple paths between two switches that aren’t in a port-channel.  If they are two separate interfaces, one will always be in blocking mode.  If a link failure occurs, it will take spanning-tree anywhere from 30 to 50 seconds to move the previosuly blocked port into a forwarding state.

Uplinkfast fixes this problem by allowing a blocking port to move immediately into the forwarding state if the forwarding link fails.  As an interesting side-effect of configuring uplinkfast, the switch increase the bridge priority to 41952 and the port costs by 3000.  The rationale is that this will make the switch less likely to become the root switch as well as make it less likely to become a transit switch in the STP topology.  Uplinkfast can not be configured on the root switch and is configured globally.

BackboneFast
Backbonefast is a means for a switch to detect an indirect root failure.  Basically, backbonefast just allows a switch to use RLQs (Root Link Queries) to determine if the root is still accessible.  If it is, the switch can immediately bypass it’s max age timer, and start moving a port that was once blocking directly into the listening and learning state.  We can see this in action pretty easily…

*Mar  1 03:14:47.956: STP: VLAN0001 heard root 32769-000d.2818.a
*Mar  1 03:14:49.340: STP: VLAN0001 heard root 32769-000d.2818.a
*Mar  1 03:14:51.345: STP: VLAN0001 heard root 32769-000d.2818.a
*Mar  1 03:14:53.350: STP: VLAN0001 heard root 32769-000d.2818.a
*Mar  1 03:14:55.354: STP: VLAN0001 heard root 32769-000d.2818.a
*Mar  1 03:14:57.359: STP: VLAN0001 heard root 32769-000d.2818.a
*Mar  1 03:14:59.364: STP: VLAN0001 heard root 32769-000d.2818.a
*Mar  1 03:15:01.369: STP: VLAN0001 heard root 32769-000d.2818.a
*Mar  1 03:15:03.374: STP: VLAN0001 heard root 32769-000d.2818.a
*Mar  1 03:15:05.379: STP: VLAN0001 heard root 32769-000d.2818.a
*Mar  1 03:15:05.949: STP: VLAN0001 Fa1/0/2 -> listening
*Mar  1 03:15:07.006: STP: VLAN0001 Topology Change rcvd on Fa1/
*Mar  1 03:15:07.006: STP: VLAN0001 sent Topology Change Notice
*Mar  1 03:15:20.957: STP: VLAN0001 Fa1/0/2 -> learning
*Mar  1 03:15:35.964: STP: VLAN0001 sent Topology Change Notice on Fa1/0/40
*Mar  1 03:15:35.964: STP: VLAN0001 Fa1/0/2 -> forwarding

This is what we expect to see.  20 seconds for max age, and then 30 seconds from listening to forwarding.  If we enable backbonefast, we see something different…

*Mar  1 03:20:32.795: STP: VLAN0001 heard root 32769-000d.2818.af00 on Fa1/0/2
*Mar  1 03:20:32.795: STP: VLAN0001 Fa1/0/2 -> listening
*Mar  1 03:20:33.801: STP: VLAN0001 Topology Change rcvd on Fa1/0/2
*Mar  1 03:20:33.801: STP: VLAN0001 sent Topology Change Notice on Fa1/0/40
*Mar  1 03:20:47.802: STP: VLAN0001 Fa1/0/2 -> learning
*Mar  1 03:21:02.809: STP: VLAN0001 sent Topology Change Notice on Fa1/0/40
*Mar  1 03:21:02.809: STP: VLAN0001 Fa1/0/2 -> forwarding

It only took 30 seconds for the port to become forwarding.  Notice that the instant it heard the root on a different port it went to listening mode.  This completely got rid of the max age timer.

Spanning-Tree protection
Uplinkfast and backbone fast are Cisco proprietary means to optimize spanning-tree.  There are also a couple of options to protect spanning-tree that you should be aware of…

Root Guard
Root guard prevents a port from learning of a new ,superior, root bridge.  If the port with root guard enabled on it receives a superior BPDU, it will place the port into a ‘root insistent’ state.  This equates to the port being in the spanning-tree blocked state.  Once the port stops hearing the BPDUs, the port will automatically go back into formal forwarding mode.

BPDU Guard
Is a feature that should be enabled on any port that also has portfast enabled on it.  BPDU guard err-disables a port if it receives a BPDU.  This makes sense to enable on portfast enabled ports since they should be edge ports that never receive a BPDU.  If the port does become err-disabled you need to shut/no shut the interface to return it to normal operating state.

BPDU Filter
Prevents a port from sending or receiving BPDUs entirely

Loop Guard
Loop guard is usually talked about in conjunction with UDLD.  I’m not going to cover UDLD but suffice to say it allows you to detect unidirectional links.  Loop guard ran on top of UDLD allows a port to detect when it has stopped receiving BPDUs.  When that happens, it puts the link into ‘loop inconsistent’ state which prevents the port from moving into the forwarding state.

BGP Attribute

BGP attributes are a confusing array of information carried in a BGP update capable of indicating anything from path preference to various additional pieces of information about a route, either within an autonomous system or outside an autonomous system. There are four basic types of attributes:

• Well known mandatory attributes; these attributes must be recognized by all BGP speakers, and must be included in all update messages. Almost all of the attributes impacting the path decision process ( Origin Code , AS Path , Next Hop).
• Well known discretionary attributes; these attributes must be recognized by all BGP speakers, and may be carried in updates, but are not required in every update.
• Optional transitive attributes; these attributes may be recognized by some BGP speakers, but not all. They should be preserved and advertised to all peers whether or not they are recognized.
• Optional non-transitive attributes; these attributes may be recognized by some BGP speakers, but not all. If an update containing an optional transitive attribute is received, the update should be advertised to peers without the unrecognized attributes.

BGP Aggregation

Source INE 

Route aggregation is the key for information hiding. It is critical to BGP because of
the tremendous amount of routing information passed on the Internet. There are
three basic ways to do summarization in BGP:

• Create a summary prefix in IGP and advertise it into BGP using the network
  command. This is usually accomplished by creating a static route to Null0 in the
  routing table of the advertising router. This is a common way to advertise local
  prefixes into BGP. However, you cannot summarize external BGP prefixes using this
  method.

• Use auto-summarization. As discussed in another task, this method summarizes
  networks to their classful boundaries and only applies to redistributed prefixes or
  when using the classful network command. It is not used in modern networks.

• Summarize prefixes found in BGP tables by using the aggregate-address command.This is the most flexible way to do summarization, because it may be applied to any paths learned by the BGP speaker.

The syntax for the command is aggregate-address <prefix> <mask>

For the command to work, there must be a subnet in the BGP table that is encompassed by
the summarized prefix. For example, if you issue the command aggregate-address
192.168.0.0 255.255.0.0 , at least one subnet, such as 192.168.1.0/24, must be in the
BGP table (Loc-RIB), but it does not necessarily need to be in the router’s routing
table (RIB).

If you do not specify any additional options to the command, it will create a new
prefix in the BGP table with an empty AS_PATH. It will look like the new prefix was
originated in the local AS. The new prefix will automatically have the weight value of
32768 and have a special attribute called ATOMIC_AGGREGATE assigned. The
new attribute is informational and tells the other BGP speakers that this prefix is a
result of route aggregation, and some information (like AS_PATH or other attributes)
from the original prefixes may be missing. In addition to the ATOMIC_AGGREGATE
attribute, BGP attaches another attribute called AGGREGATOR to the summarized
prefix. This attribute specifies the AS number and the BGP router-ID of the
aggregating router. Just like the ATOMIC_AGGREGATE, the new attribute is also
informational.
For every aggregate, the BGP process will install an automatic static route to Null0
for the new prefix, to prevent routing loops. Remember that the original (specific)
prefixes are still advertised, unlike in IGP, where summarization automatically
suppresses more specific prefixes.

BGP Aggregation – Summary Only

router bgp ***
aggregate-address 10.1.0.0 255.255.252.0 summary-only

BGP summarization using the aggregate address command creates new prefixes in the BGP table but does not suppress the advertisement of the specific prefixes that make up the summary. To generate just the summary prefix, use the option summary-only after the aggregate-address command. The BGP process will automatically suppress advertisement of the
prefixes in the BGP table encompassed by the new summary address.

R#show ip bgp | include 10.0.
s> 10.0.0.0/24 0.0.0.0 0 32768 i
*> 10.0.0.0/22 0.0.0.0 32768 i
s> 10.0.1.0/24 0.0.0.0 0 32768 i
s> 10.0.2.0/24 0.0.0.0 0 32768 i
s> 10.0.3.0/24 0.0.0.0 0 32768 i

BGP Aggregation – Suppress Map

When you specify the summary-only keyword, all specific prefixes are suppressed. It
is possible to suppress prefixes selectively, using a route-map associated via the
parameter suppress-map . The prefixes permitted by this route-map are suppressed;
prefixes denied by this route-map are NOT suppressed when performing
summarization.

ip prefix-list NET_2 permit 10.0.2.0/24
!
route-map SUPPRESS_MAP deny 10
match ip address prefix-list NET_2
!
route-map SUPPRESS_MAP permit 100
!
router bgp 200
aggregate-address 10.0.0.0 255.255.252.0 suppress-map SUPPRESS_MAP

The above example  allows the 10.0.2.0/24 subnet to be leaked through the summary , the rest of the prefix’s are suppressed.Note the DENY Statement on the route-map.& Seq 100 blocks the rest.

BGP Aggregation – Unsuppress Map

It is often desirable to load-balance traffic ingress to the local AS, so that traffic to some subnets enters via one BGP peer and the other peer is used as the entry point for other subnets. Generally, to accomplish this, you need to advertise all specific prefixes on both uplinks and use AS_PATH prepending to modify prefixes’preference.  This scheme implements load balancing and provides backup in case of any uplink failures.However, it is possible to achieve the same goal using a different technique. It is based on the fact that classless routing always prefers the most specific prefix to reach the destinations. If there is a specific prefix in the routing table (for example, 10.0.1.0/24) and the summary one (for example, 10.0.0.0/22), the router will prefer /24 and use /22 only if the most specific prefix vanishes. Thus, by configuring the
border BGP peers for advertising both the summary and selected specific prefixes, you may achieve the same load-balancing with the necessary level of redundancy. To implement this technique, you may use the unsuppress-map BGP feature. This feature can only be configured on the router that performs prefix aggregation using the command aggregate-address with summary-only .

ip prefix-list NET_1 permit 10.0.1.0/24
!
route-map UNSUPPRESS_MAP permit 10
match ip address prefix-list NET_1
!
router bgp 200
aggregate-address 10.0.0.0 255.255.252.0 summary-only
neighbor 155.1.37.7 unsuppress-map UNSUPPRESS_MAP

BGP Aggregation – AS-Set

It is important to remember that aggregation hides information previously found in the specific prefixes. This includes all attributes, such as NEXT_HOP, AS_PATH, and so on. The new prefix appears to be originated from within the local AS where aggregation is perfpormed. This causes no problems if all specific prefixes belong to
the local AS. However, when you summarize prefixes learned from other ASs, information hiding may result in the following dangerous consequences:

• Suboptimal routing, caused by loss of path information, such as AS_PATH, MED and
  so on.
• Routing loops, because removing the AS_PATH attribute and replacing it with an
  empty list prevents the BGP loop-detection mechanism from working properly.
  The second issue is more dangerous.

To prevent it, it is possible to insert a special new member into the AS_PATH of the newly created summary prefix. This elementis called AS_SET and contains the AS numbers found in all AS_PATHs of the specific prefixes.This list of AS numbers is unordered, unlike the regular AS_SEQUENCE element. Its only use is for routing loop prevention; when BGP
receives a prefix, it scans the AS_PATH attribute. If the local AS number is found in any of the AS_SET or AS_SEQUENCE elements, the prefix is dropped. By default, the aggregated address in BGP will not include the AS-Set information.
To force the use of this information, specify the as-set option as follows: aggregate address <subnet> <mask> as-set

BGP Aggregation – Attribute-Map

When you use the as-set parameter to the aggregate-address command, the resulting prefix will inherit “additive” attributes of the specific prefixes. This includes the AS_PATH attributes, condensed into AS_SET and the community attributes, which are grouped together from all prefixes. We will explore community signaling in further detail, but for now remember that any prefix bearing the community attribute value of “no-export” is not advertised to the adjacent ASs.

route-map ATTR_MAP

set community none

router bgp 200
aggregate-address 112.0.0.0 248.0.0.0 summary-only as-set attribute-map ATTR_MAP

BGP Aggregation – Advertise Map

When using the as-set keyword with BGP aggregation, some of the specific prefix attributes got mixed together in the new prefix. Specifically, you should watch out for the resulting AS_SET and list of community attributes. In the previous task, you learned how to modify some of the aggregated prefix attributes. However, you cannot manipulate an important attribute such as AS_SET directly. Instead, you may specify the specific prefixes that will be used to make up the attribute list for the aggregate prefix. This is accomplished by using the advertise-map parameter to the aggregate-address command. The route-map used as advertise-map should permit specific prefixes to be used to compose the aggregate attributes, such as AS_SET. You can use only access-list, prefix-list, or as-path access-lists to match the specific
prefixes. Information from the prefixes denied by the route-map is not used when constructing the resulting summary-prefix. You may use this method to remove the prefixes with unwanted BGP community attributes as well.

ip prefix-list AS300_PREFIX permit 222.22.3.0/24

route-map ADVERTISE_MAP deny 10
match ip address prefix-list AS300_PREFIX

route-map ADVERTISE_MAP permit 100

router bgp 100
aggregate-address 222.22.0.0 255.255.252.0 summary-only as-set advertise-map ADVERTISE_MAP