Pages

network cisco ccna gns3 certification arteq

network cisco ccna gns3 certification arteq
a network runs through it

Search insearchofthecert

Showing posts with label ccie. Show all posts
Showing posts with label ccie. Show all posts

Thursday, February 14, 2013

again with the beginning...

ccieordie.com is the new beginning... 

when i first launched this thing it was dedicated to the struggles in the trenches... that's where it hurts the most... i do not envy those starting the journey, but i do envy the excitement of discovery...

this place is about the pain of adversity...

ccieordie.com will be about the new pain... i thought all along if i ever survived CCNA, and God willing CCNP, that i would launch a new site...

that has happened...

i'm going after CCIE like i always knew i would and i don't care who gives a shit...

this place isn't going away, but my sorry ass ruminations will mostly be chronicled there...

remember that none of it matters until CCNA...

gre instead of virtual link...

http://www.cisco.com/en/US/tech/tk365/technologies_configuration_example09186a00801ec9ee.shtml#using

this is borderline trivia, and i think bad design, however... a very good reason to not use a vl is due to the DNA (do not age) or no dead timer...


where am i...

as you might imagine, i am currently lost... i went through a bout of decompression yesterday after finally consolidating CCNP... this has been a dream of mine for a long time and now that it is here it will take some getting used to... but i'm sure i will get used to it...

the fact is there is no celebration going on here...  there is only the work, more consolidation, going back to the beginning to move forward again...

there is some relief that there is no test in the coming months... i plan to wait until the first of next year before sitting the CCIE written... and that was always the plan; yesterday has not changed that... 

pucker time is over and i am happy about the loneliness of the long distance run ahead... there is no immediate fight; there is no rush; there is only the battle with me now... and for that i am grateful...

back to squares...

but i do like having this to keep me company:


Wednesday, February 13, 2013

Monday, February 11, 2013

area 0...

that old ospf design guide is great...

http://www.cisco.com/en/US/tech/tk365/technologies_white_paper09186a0080094e9e.shtml#t6

The Backbone and Area 0

OSPF has special restrictions when multiple areas are involved. If more than one area is configured, one of these areas has be to be area 0. This is called the backbone. When designing networks it is good practice to start with area 0 and then expand into other areas later on.

The backbone has to be at the center of all other areas, i.e. all areas have to be physically connected to the backbone. The reasoning behind this is that OSPF expects all areas to inject routing information into the backbone and in turn the backbone will disseminate that information into other areas.

 contrast this with what jeff doyle wrote...

Why does OSPF require all traffic between non-backbone areas to pass through a backbone area (area 0)?

Because inter-area OSPF is distance vector, it is vulnerable to routing loops. It avoids loops by mandating a loop-free inter-area topology, in which traffic from one area can only reach another area through area 0. 


Saturday, February 9, 2013

ospf multiple area, summarization, stubs...

i've been saying this for a long time... all of this is over-engineering... it's easily relegated to network trivia, or a "we do it because we can" philosophy... but nobody wants to hear me say it... listen to these guys then...

it is no wonder my mind glazes over when these discussions come up...

http://packetpushers.net/show-134-ospf-design-part-1-debunking-the-multiple-area-myth/

and we'll have an area here and here and here, and this will be a stub, and we'll summarize there, and that needs to be nssa because it sounds cool and we get to use it in a sentence... gimme a break...

passive interface, eigrp and ospf...

this command can certainly be a pain in the ass...

ospf gives you a decent way to detect it with:

R1#sh ip ospf int s1/0.12
Serial1/0.12 is up, line protocol is up
  Internet Address 10.1.1.1/30, Area 12, Attached via Network Statement
  Process ID 1, Router ID 1.1.1.1, Network Type POINT_TO_POINT, Cost: 64
  Topology-MTID    Cost    Disabled    Shutdown      Topology Name
        0           64        no          no            Base
  Transmit Delay is 1 sec, State POINT_TO_POINT
  Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5
    oob-resync timeout 40
    No Hellos (Passive interface)
  Supports Link-local Signaling (LLS)
  Cisco NSF helper support enabled
  IETF NSF helper support enabled
  Index 2/2, flood queue length 0
  Next 0x0(0)/0x0(0)
  Last flood scan length is 1, maximum is 2
  Last flood scan time is 0 msec, maximum is 12 msec
  Neighbor Count is 0, Adjacent neighbor count is 0
  Suppress hello for 0 neighbor(s)
  Message digest authentication enabled
    Youngest key id is 1

although you have to look; it doesn't jump out at you...

eigrp isn't as friendly...

R4#sh ip eigrp int
EIGRP-IPv4 Interfaces for AS(10)
                              Xmit Queue   PeerQ        Mean   Pacing Time   Multicast    Pending
Interface              Peers  Un/Reliable  Un/Reliable  SRTT   Un/Reliable   Flow Timer   Routes
Fa0/1                    1        0/0       0/0          19       0/0           84           0
R4#config t
Enter configuration commands, one per line.  End with CNTL/Z.
R4(config)#router eigrp 10
R4(config-router)#no passive-int f0/0
R4(config-router)#
*Feb  9 09:45:59.609: %DUAL-5-NBRCHANGE: EIGRP-IPv4 10: Neighbor 10.1.4.6 (FastEthernet0/0) is up: new adjacency
R4(config-router)#do sh ip eigrp int
EIGRP-IPv4 Interfaces for AS(10)
                              Xmit Queue   PeerQ        Mean   Pacing Time   Multicast    Pending
Interface              Peers  Un/Reliable  Un/Reliable  SRTT   Un/Reliable   Flow Timer   Routes
Fa0/1                    1        0/0       0/0          19       0/0           76           0
Fa0/0                    1        0/0       0/0          19       0/0           76           0
R4(config-router)#do sh ip eigrp neigh
EIGRP-IPv4 Neighbors for AS(10)
H   Address                 Interface              Hold Uptime   SRTT   RTO  Q  Seq
                                                   (sec)         (ms)       Cnt Num
0   10.1.4.6                Fa0/0                    11 00:01:17   19   114  0  814
1   10.1.4.10               Fa0/1                    14 00:28:05   19   114  0  788
R4(config-router)#router eigrp 10
R4(config-router)#passive-int f0/0
R4(config-router)#
*Feb  9 09:47:35.717: %DUAL-5-NBRCHANGE: EIGRP-IPv4 10: Neighbor 10.1.4.6 (FastEthernet0/0) is down: interface passive
R4(config-router)#do sh ip eigrp neigh
EIGRP-IPv4 Neighbors for AS(10)
H   Address                 Interface              Hold Uptime   SRTT   RTO  Q  Seq
                                                   (sec)         (ms)       Cnt Num
1   10.1.4.10               Fa0/1                    11 00:28:32   18   108  0  788

the eigrp commands just show you that it's NOT there... debug doesn't help either...

trace and ttl...

http://www.cisco.com/en/US/products/sw/iosswrel/ps1831/products_tech_note09186a00800a6057.shtml


The Traceroute Command

The traceroute command is used to discover the routes that packets actually take when traveling to their destination. The device (for example, a router or a PC) sends out a sequence of User Datagram Protocol (UDP) datagrams to an invalid port address at the remote host.

Three datagrams are sent, each with a Time-To-Live (TTL) field value set to one. The TTL value of 1 causes the datagram to "timeout" as soon as it hits the first router in the path; this router then responds with an ICMP Time Exceeded Message (TEM) indicating that the datagram has expired.

Another three UDP messages are now sent, each with the TTL value set to 2, which causes the second router to return ICMP TEMs. This process continues until the packets actually reach the other destination. Since these datagrams are trying to access an invalid port at the destination host, ICMP Port Unreachable Messages are returned, indicating an unreachable port; this event signals the Traceroute program that it is finished.

The purpose behind this is to record the source of each ICMP Time Exceeded Message to provide a trace of the path the packet took to reach the destination. For all the options about this command, see Trace (privileged).

R1#trace 10.2.1.4
Type escape sequence to abort.
Tracing the route to 10.2.1.4
VRF info: (vrf in name/id, vrf out name/id)
  1 10.1.1.2 16 msec 20 msec 20 msec
  2 10.1.1.6 28 msec 28 msec 16 msec
  3 10.1.1.10 64 msec 64 msec 60 msec
  4 10.1.4.6 60 msec 68 msec 64 msec
  5 10.2.1.4 64 msec 64 msec 72 msec
R1#
*Feb  9 09:22:22.349: ICMP: time exceeded rcvd from 10.1.1.2
*Feb  9 09:22:22.369: ICMP: time exceeded rcvd from 10.1.1.2
*Feb  9 09:22:22.389: ICMP: time exceeded rcvd from 10.1.1.2
*Feb  9 09:22:22.413: ICMP: time exceeded rcvd from 10.1.1.6
*Feb  9 09:22:22.453: ICMP: time exceeded rcvd from 10.1.1.6
*Feb  9 09:22:22.489: ICMP: time exceeded rcvd from 10.1.1.6
*Feb  9 09:22:22.569: ICMP: time exceeded rcvd from 10.1.1.10
*Feb  9 09:22:22.633: ICMP: time exceeded rcvd from 10.1.1.10
*Feb  9 09:22:22.693: ICMP: time exceeded rcvd from 10.1.1.10
*Feb  9 09:22:22.753: ICMP: time exceeded rcvd from 10.1.4.6
*Feb  9 09:22:22.829: ICMP: time exceeded rcvd from 10.1.4.6
R1#
*Feb  9 09:22:22.893: ICMP: time exceeded rcvd from 10.1.4.6
*Feb  9 09:22:22.965: ICMP: dst (10.1.1.1) port unreachable rcv from 10.2.1.4
*Feb  9 09:22:23.037: ICMP: dst (10.1.1.1) port unreachable rcv from 10.2.1.4
*Feb  9 09:22:23.117: ICMP: dst (10.1.1.1) port unreachable rcv from 10.2.1.4
 


Friday, February 8, 2013

quote of the day; jeff doyle on ospf...

jeff speaks...

Why does OSPF require all traffic between non-backbone areas to pass through a backbone area (area 0)?

Because inter-area OSPF is distance vector, it is vulnerable to routing loops. It avoids loops by mandating a loop-free inter-area topology, in which traffic from one area can only reach another area through area 0.


Every link state router floods information about itself, its links, and its neighbors to every other router. From this flooded information each router builds an identical link state database. Each router then independently runs a shortest-path-first calculation on its database – a local calculation using distributed information – to derive a shortest-path tree. This tree is a sort of map of the shortest path to every other router.

One of the advantages of link state protocols is that the link state database provides a “view” of the entire network, preventing most routing loops. This is in contrast to distance vector protocols, in which route information is passed hop-by-hop through the network and a calculation is performed at each hop – a distributed calculation using local information. Each router along a route is dependent on the router before it to perform its calculations correctly and then correctly pass along the results. When a  router advertises the prefixes it learns to its neighbors it’s basically saying, “I know how to reach these destinations.” And because each distance vector router knows only what its neighbors tell it, and has no “view” of the network beyond the neighbors, the protocol is vulnerable to loops.

The second concept is this:

When link state domains grow large, the flooding and the resulting size of the link state database becomes a scaling problem. The problem is remedied by breaking the routing domain into areas: That first concept is modified so that flooding occurs only within the boundaries of an area, and the resulting link state database contains only information from the routers in the area.  This, in turn, means that each router’s calculated shortest-path tree only describes the path to other routers within the area.

The third concept is this:

OSPF areas are connected by one or more Area Border Routers (the other main link state protocol, IS-IS, connects areas somewhat differently) which maintain a separate link state database and calculate a separate shortest-path tree for each of their connected areas. So an ABR by definition is a member of two or more areas. It advertises the prefixes it learns in one area to its other areas by flooding Type 3 LSAs into the areas that basically say, “I know how to reach these destinations.”

Wait a minute – what that last concept described is not link state, it’s distance vector. The routers in an area cannot “see” past the ABR, and rely on the ABR to correctly tell them what prefixes it can reach. The SPF calculation within an area derives a shortest-path tree that depicts all prefixes beyond the ABR as leaf subnets connected to the ABR at some specified cost.

And that leads us to the answer to the question:

Because inter-area OSPF is distance vector, it is vulnerable to routing loops. It avoids loops by mandating a loop-free inter-area topology, in which traffic from one area can only reach another area through area 0.

arp...


resolving a known l3 address to an unknown l2 address...

i suggest you spend some time here, and with rfc 826... it is not enough to have familiarity...

from: http://www.tcpipguide.com/free/t_ARPMessageFormat.htm

Address resolution using ARP is accomplished through the exchange of messages between the source device seeking to perform the resolution, and the destination device that responds to it. As with other protocols, a special message format is used containing the information required for each step of the resolution process.
ARP messages use a relatively simple format. It includes a field describing the type of message (its operational code or opcode) and information on both layer two and layer three addresses. In order to support addresses that may be of varying length, the format specifies the type of protocol used at both layer two and layer three and the length of addresses used at each of these layers.


The ARP message format is designed to accommodate layer two and layer three addresses of various sizes. This diagram shows the most common implementation, which uses 32 bits for the layer three (“Protocol”) addresses, and 48 bits for the layer two hardware addresses. These numbers of course correspond to the address sizes of the Internet Protocol version 4 and IEEE 802 MAC addresses, used by Ethernet.

ccna to ccie...

i have always thought in the past without fully understanding why, that  ccie is  essentially turbo ccna...  i still believe that...

ccnp is  terribly important as it fills in the advanced technologies between... those who choose to make the leap directly from ccna to ccie are brave souls indeed...  ultimately they end up doing ccnp, without calling it exactly that... it is not possible to get there from here in any equation...

however, ccie is ccna without the creamy center of ccnp...

while i wouldn't say that any of them are fun, i will say that ccnp has been an adagio...

i see the entire thing as a play in three acts...

ccna is the first act of course, laying the foundation for the drama through exposition, character establishment and relationships...

ccnp is the rising action; the attempt to learn new things, character development and confrontation along the way...

ccie is the climax, the second turning point; the resolution of the problems set forth...


Thursday, February 7, 2013

stp root switch...

from cisco's 3560/3750 guide which of course you can download...

If all switches in a network are enabled with default spanning-tree settings, (and when they come out of the box they are wearing their birthday suits) the switch with the lowest MAC address becomes the root switch.


that is gospel...

priority is default at 32768...

that is gospel...

this is the BID of this switch on vlan 10...

dsw1#sh spann                                                                 
                                                                              
VLAN0010                                                                      
  Spanning tree enabled protocol rstp                                         
  Root ID    Priority    32778        

32768 + 10 is 32778...

the priority can change all that ONLY if it has been configured to do so... and if it has been configured to do so, the mac doesn't matter...

again, that is if it has been configured to do so...

which means the priority is an afterthought, although we all know you want to be deterministic about the placement of the root switch...

out of the box, MAC is king...

your witness, counselor...

why ospf area's and other sundries...

these kinds of basic questions are tough on the spot...

why ospf areas? ospf areas are like, like life... yeah...



http://www.cisco.com/en/US/tech/tk365/technologies_tech_note09186a0080094aaa.shtml

Areas limit the scope of route information distribution. It is not possible to do route update filtering within an area. The link-state database (LSDB) of routers within the same area must be synchronized and be exactly the same; however, route summarization and filtering is possible between different areas. The main benefit of creating areas is a reduction in the number of routes to propagate—by the filtering and the summarization of routes.

which really came in handy back when routers had shitty processors and 1k of ram...

An autonomous system boundary router (ASBR) advertises external destinations throughout the OSPF autonomous system. External routes are the routes redistributed into OSPF from any other protocol. In many cases, external link states make up a large percentage of the link states in the databases of every router. A stub area is an area in which you don't allow advertisements of external routes, thus reducing the size of the database even more. Instead, a default summary route (0.0.0.0) is inserted into the stub area in order to reach these external routes. If you have no external routes in your network, then you have no need to define stub areas. 

no external routes equals no redistribution equals no stubs...

All areas in an OSPF autonomous system must be physically connected to the backbone area (area 0). In some cases where this physical connection is not possible, you can use a virtual link to connect to the backbone through a non-backbone area. As mentioned above, you can also use virtual links to connect two parts of a partitioned backbone through a non-backbone area. The area through which you configure the virtual link, known as a transit area, must have full routing information. The transit area cannot be a stub area.

good... and you use the area id virtual-link  command to accomplish this... then what ospf type is a virtual link... would someone please make up my mind...

doyle calls it a network type...

OSPF defines five network types:

Point-to-point networks
Broadcast networks
Nonbroadcast Multiaccess (NBMA) networks
Point-to-multipoint networks
Virtual links

reason number 65,535...

that you should be on cln...


if you don't know who terry slattery is, put yourself in a time out immediately...

like he says above, if you want to be a ccie because of money, there is no hope for you... your cause is lost out the gate...

joshua, at cln...

there is a new idea at cln... learn about it here:

https://learningnetwork.cisco.com/docs/DOC-16300#comment-34483

joshua has already done 2 and has another in the works...i suggest you watch them and make an honest assessment of yourself... you will see that something like this is the standard by which you will be measured...

if you think you have have the fundamentals cold, then you don't need this, however the question you must ask yourself, and you must keep asking yourself time and again, all throughout this experience is:

But do I really...

two steps forward, five steps back...



what is inalienable...

through the fog of time what one thought once inalienable, becomes muted...

back to the beginning again...

recent events have me reevaluating...

what is a trunk and what makes an etherchannel so very different...

from: http://www.ciscopress.com/articles/article.asp?p=29803&seqNum=3

A trunk port is by default a member of all the VLANs that exist on the switch and carry traffic for all those VLANs between the switches. To distinguish between the traffic flows, a trunk port must mark the frames with special tags as they pass between the switches. Trunking is a function that must be enabled on both sides of a link. If two switches are connected together, for example, both switch ports must be configured for trunking, and they must both be configured with the same tagging mechanism (ISL or 802.1Q).

good... an etherchannel does the same thing only it allows for the aggregation of ports into a bundle, thus increasing the total bandwidth available by a factor of the included ports...

from: http://en.wikipedia.org/wiki/EtherChannel

EtherChannel is a port link aggregation technology or port-channel architecture used primarily on Cisco switches. It allows grouping of several physical Ethernet links to create one logical Ethernet link for the purpose of providing fault-tolerance and high-speed links between switches, routers and servers. An EtherChannel can be created from between two and eight active Fast, Gigabit or 10-Gigabit Ethernet ports, with an additional one to eight inactive (failover) ports which become active as the other active ports fail. EtherChannel is primarily used in the backbone network, but can also be used to connect end user machines.

Monday, February 4, 2013

native vlan and control traffic...

i got involved in a thread on cln here:

https://learningnetwork.cisco.com/message/279101#279101

on that link you can download a packet capture that i attached...

i've read recently some conflicting ideas about the tagging of control traffic when vlan 1 is not present... my original thought sided with marko that l2 control traffic belonged to the switch.. here is marko's post:

http://blog.ipexpert.com/2011/01/19/old-ccie-myths-vlan-1/

he explores this idea at length, but this idea is incorrect...

this idea is refuted here:

http://www.fragmentationneeded.net/2011/01/revisiting-vlan-1-myth-again.html

and from the horse's mouth here:

(from Cisco Lan Switching Fundamentals)

It is important to understand the significance of VLAN 1. By default, all switch ports are part of VLAN 1. VLAN 1 contains control plane traffic and can contain user traffic. It is recommended that user traffic be configured on VLANs other than VLAN 1, primarily to prevent unnecessary user broadcast and multicast traffic from being processed by the Network Management Processor (NMP) of the supervisor. Although VLAN 1 user traffic can be pruned from a trunk, it is not the case with control plane traffic. In fact, in older Cisco Catalyst Software versions (5.4 or earlier), VLAN 1 could not be removed at all from a trunk. Control plane traffic such as VTP, CDP, and PAgP protocols are tagged with VLAN 1 information and are forwarded on a trunk regardless if the trunk has pruned VLAN 1.


naturally, i wanted to do my own testing, but my caps never showed tagging... i was using a dhcp windows client for monitoring and in the back of my mind my thought was that i'd never see dot1q tags because my windows nic simply didn't support tagging, therefore wouldn't show in the cap...  well, breaking my current working topology was an annoying idea simply to prove that so i moved on with what i was currently working at the time...

this morning, of course, it was nagging me so i had to be sure... turns out that is correct... dot1q tags don't show up in my windows box caps, but they do with the linux caps...

note on dsw1 in the below output that vlan 1 is not included in trunking...

dsw1#sh int trunk                                                              
                                                                               
Port        Mode             Encapsulation  Status        Native vlan          
Po1         on               802.1q         trunking      200                  
Po2         on               802.1q         trunking      200                  
                                                                               
Port        Vlans allowed on trunk                                             
Po1         10,20,200                                                          
Po2         10,20,200                                                          
                                                                               
Port        Vlans allowed and active in management domain                      
Po1         10,20,200                                                          
Po2         10,20,200                                                          
                                                                               
Port        Vlans in spanning tree forwarding state and not pruned             
Po1         10,20,200                                                          
Po2         10,20,200               

in the cap below note that the control traffic is tagged with vlan 1...


in fact all of the control traffic in the cap is tagged 1... but see for yourself, download the cap from the link and draw your own conclusions... also note that the cap is from the tshoot topology, which means that all supported protocols are represented as they would appear in cisco's topology...  naturally it is my representation of that topology; it is not gospel...

have fun...

note about topology: vlan's 4 and 8 support the gns3 environment onto the switched network... so don't let those qinq's confuse you...

Sunday, February 3, 2013

trap receiver...

is a free program that, guess what, receives snmp traps... this can be exciting for about 9 seconds...

you can download it here...

http://www.trapreceiver.com/

setting up snmp is easy...

dsw1#sh run | b snmp                                             
snmp-server community ccie RO                                    
snmp-server enable traps vlancreate                              
snmp-server host 10.2.1.3 snmp  vlancreate    

you can enable all traps or some, then send them to the collector...


dsw1(config)#snmp-server enable traps ?                          
  auth-framework    Enable SNMP CISCO-AUTH-FRAMEWORK-MIB traps   
  bgp               Enable BGP traps                             
  bridge            Enable SNMP STP Bridge MIB traps             
  cef               Enable SNMP CEF traps                        
  cluster           Enable Cluster traps                         
  config            Enable SNMP config traps                     
  config-copy       Enable SNMP config-copy traps                
  config-ctid       Enable SNMP config-ctid traps                
  copy-config       Enable SNMP config-copy traps                
  cpu               Allow cpu related traps                      
  dot1x             Enable SNMP dot1x traps                      
  eigrp             Enable SNMP EIGRP traps                      
  energywise        Enable SNMP ENERGYWISE traps                 
  entity            Enable SNMP entity traps                     
  envmon            Enable SNMP environmental monitor traps      
  errdisable        Enable SNMP errdisable notifications         
  event-manager     Enable SNMP Embedded Event Manager traps     
  flash             Enable SNMP FLASH notifications              
  hsrp              Enable SNMP HSRP traps                       
  ipmulticast       Enable SNMP ipmulticast traps 
  etc...

then look at your butterfly collector...


this is a real over simplification, and you already know this... nothing earth shattering here... go watch the superbowl or something...

Saturday, February 2, 2013

forwarding, not pruned...

you love show interface trunk, because i said you do...

DLS2#sh int trunk                                                              
                                                                               
Port        Mode             Encapsulation  Status        Native vlan          
Po2         on               802.1q         trunking      900                  
Po10        on               802.1q         trunking      900                  
                                                                               
Port        Vlans allowed on trunk                                             
Po2         10,20,30,100                                                       
Po10        10,20,30,50,100                                                    
                                                                               
Port        Vlans allowed and active in management domain                      
Po2         10,20,30,100                                                       
Po10        10,20,30,50,100                                                    
                                                                               
Port        Vlans in spanning tree forwarding state and not pruned             
Po2         10,20,30,100                                                       
Po10        10,20,30,50,100                   

note vlan 50 is not forwarding on po2...

DLS2#sh run int po2                                                            
Building configuration...                                                      
                                                                               
Current configuration : 223 bytes                                              
!                                                                              
interface Port-channel2                                                        
 description Channel to ALS1                                                   
 switchport trunk encapsulation dot1q                                          
 switchport trunk native vlan 900                                              
 switchport trunk allowed vlan 10,20,30,100                                    
 switchport mode trunk                                                         
 switchport nonegotiate             

as you can see that's by design... however it is forwarding on po10 although it is down...

DLS2#sh int vlan 50                                                            
Vlan50 is administratively down, line protocol is down                         
  Hardware is EtherSVI, address is 0016.479e.5fc6 (bia 0016.479e.5fc6)         
  Internet address is 10.1.50.253/24        

DLS2#sh spann vlan 50 | b Interface
Interface           Role Sts Cost      Prio.Nbr Type
------------------- ---- --- --------- -------- --------------------------------
Po10                Desg FWD 12        128.128  P2p

spanning tree believes it is still forwarding simply because it's allowed on the trunk regardless of it's operational state...

DLS2#sh run int po10
Building configuration...

Current configuration : 227 bytes
!
interface Port-channel10
 description Channel to DLS1
 switchport trunk encapsulation dot1q
 switchport trunk native vlan 900
 switchport trunk allowed vlan 10,20,30,50,100
 switchport mode trunk
 switchport nonegotiate

of course dls1 can't ping it and it's getting no hsrp love...

DLS1>ping 10.1.50.253                                                           
                                                                                
Type escape sequence to abort.                                                  
Sending 5, 100-byte ICMP Echos to 10.1.50.253, timeout is 2 seconds:            
.....                                                                           
Success rate is 0 percent (0/5)                                                 
DLS1>sh stand brie                                                              
                     P indicates configured to preempt.                         
                     |                                                          
Interface   Grp  Pri P State   Active          Standby         Virtual IP       
Vl10        10   110 P Active  local           10.1.10.253     10.1.10.254      
Vl20        20   100 P Standby 10.1.20.253     local           10.1.20.254      
Vl30        30   110 P Active  local           10.1.30.253     10.1.30.254      
Vl50        50   100 P Active  local           unknown         10.1.50.254      
Vl100       100  110 P Active  local           10.1.100.253    10.1.100.254 

hsrp was nice enough to take over on dls1, however...

DLS2#sh stand brie                                                              
                     P indicates configured to preempt.                         
                     |                                                          
Interface   Grp  Pri P State   Active          Standby         Virtual IP       
Vl10        10   100 P Standby 10.1.10.252     local           10.1.10.254      
Vl20        20   110 P Active  local           10.1.20.252     10.1.20.254      
Vl30        30   100 P Standby 10.1.30.252     local           10.1.30.254      
Vl50        50   110 P Init    unknown         unknown         10.1.50.254      
Vl100       100  100 P Standby 10.1.100.252    local           10.1.100.254

once i disallow it on the trunk:

DLS2#sh spann vlan 50                                                           
                                                                                
Spanning tree instance(s) for vlan 50 does not exist.

it stops showing up in forwarding state...

DLS2#sh int trunk                                                               
                                                                                
Port        Mode             Encapsulation  Status        Native vlan           
Po2         on               802.1q         trunking      900                   
Po10        on               802.1q         trunking      900                   
                                                                                
Port        Vlans allowed on trunk                                              
Po2         10,20,30,100                                                        
Po10        10,20,30,100                                                        
                                                                                
Port        Vlans allowed and active in management domain                       
Po2         10,20,30,100                                                        
Po10        10,20,30,100                                                        
                                                                                
Port        Vlans in spanning tree forwarding state and not pruned              
Po2         10,20,30,100                                                        
Po10        10,20,30,100     

and until it is added to the trunk, although it is no longer shut, it is up, down because it is not an active member of any port...

DLS2#sh int vlan 50                                                             
Vlan50 is up, line protocol is down                                             
  Hardware is EtherSVI, address is 0016.479e.5fc6 (bia 0016.479e.5fc6)          
  Internet address is 10.1.50.253/24                                 

the point is it doesn't get pruned from the trunk, until it is taken out of allowed manually... allowed prevents dynamic pruning... makes sense...

DLS2(config)#int po10                                                           
DLS2(config-if)#sw trunk allowed vlan 10,20,30,50,100                           
DLS2(config-if)#                                                                
Jan 22 23:59:11: %LINEPROTO-5-UPDOWN: Line protocol on Interface Vlan50, changedp
Jan 22 23:59:13: %HSRP-5-STATECHANGE: Vlan50 Grp 50 state Listen -> Active      
DLS2(config-if)#do sh int trunk                                                 
                                                                                
Port        Mode             Encapsulation  Status        Native vlan           
Po2         on               802.1q         trunking      900                   
Po10        on               802.1q         trunking      900                   
                                                                                
Port        Vlans allowed on trunk                                              
Po2         10,20,30,100                                                        
Po10        10,20,30,50,100                                                     
                                                                                
Port        Vlans allowed and active in management domain                       
Po2         10,20,30,100                                                        
Po10        10,20,30,50,100                                                     
                                                                                
Port        Vlans in spanning tree forwarding state and not pruned              
Po2         10,20,30,100                                                        
Po10        10,20,30,50,100               

DLS2(config-if)#do sh spann vlan 50 | b Int                                     
Interface           Role Sts Cost      Prio.Nbr Type                            
------------------- ---- --- --------- -------- --------------------------------
Po10                Desg FWD 12        128.128  P2p