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...
Search insearchofthecert
Showing posts with label ccie. Show all posts
Showing posts with label ccie. Show all posts
Thursday, February 14, 2013
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...
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:
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 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.
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.
Sunday, February 10, 2013
quote of the day, ospf design guide...
i never tire of rereading this... this is atrophy remover...
http://www.cisco.com/en/US/tech/tk365/technologies_white_paper09186a0080094e9e.shtml
http://www.cisco.com/en/US/tech/tk365/technologies_white_paper09186a0080094e9e.shtml
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...
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...
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...
Labels:
ccie,
eigrp,
ospf,
passive-interface
trace and ttl...
http://www.cisco.com/en/US/products/sw/iosswrel/ps1831/products_tech_note09186a00800a6057.shtml
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
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.
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...
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...
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
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...
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...
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.
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...
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...
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)
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
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...
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...
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
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-if)#do sh spann vlan 50 | b Int
Interface Role Sts Cost Prio.Nbr Type
------------------- ---- --- --------- -------- --------------------------------
Po10 Desg FWD 12 128.128 P2p
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)#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
Interface Role Sts Cost Prio.Nbr Type
------------------- ---- --- --------- -------- --------------------------------
Po10 Desg FWD 12 128.128 P2p
Subscribe to:
Posts (Atom)







