R1#sh int fa0/0
FastEthernet0/0 is up, line protocol is up 
 Hardware is Gt96k FE, address is c400.6413.0000 (bia c400.6413.0000)
 Internet address is 10.1.1.1/24
 MTU 1500 bytes, BW 10000 Kbit/sec, DLY 1000 usec, 
 reliability 255/255, txload 1/255, rxload 1/255
 Encapsulation ARPA, loopback not set
 Keepalive set (10 sec)
 Half-duplex, 10Mb/s, 100BaseTX/FX
R2#sh int f0/0
FastEthernet0/0 is up, line protocol is up 
 Hardware is Gt96k FE, address is c401.6413.0000 (bia c401.6413.0000)
 Internet address is 10.1.1.2/24
 MTU 1500 bytes, BW 100000 Kbit/sec, DLY 1000 usec, 
 reliability 255/255, txload 1/255, rxload 1/255
 Encapsulation ARPA, loopback not set
 Keepalive set (10 sec)
 Half-duplex, 10Mb/s, 100BaseTX/FX

Answer

The trick here is even though the bandwidth on R2′s Fa0/0 is 100000 it still bases the calculation on 10000 because EIGRP uses minimum bandwidth, not sender bandwidth value.

Bandwidth setting on R1: 10000

Delay setting on R1: 1000

((10,000,000 / 10,000) + 100) * 256
(1,000 + 100) * 256
1,100 * 256 = 281,600

R1#sh ip eigrp topology 10.1.1.0 255.255.255.0 
IP-EIGRP (AS 1): Topology entry for 10.1.1.0/24
 State is Passive, Query origin flag is 1, 1 Successor(s), FD is 281600
 Routing Descriptor Blocks:
 0.0.0.0 (FastEthernet0/0), from Connected, Send flag is 0x0
 Composite metric is (281600/0), Route is Internal

R1#sh int f0/0
FastEthernet0/0 is up, line protocol is up 
 Hardware is Gt96k FE, address is c400.6413.0000 (bia c400.6413.0000)
 Internet address is 10.1.1.1/24
 MTU 1500 bytes, BW 10000 Kbit/sec, DLY 1000 usec, 
 reliability 255/255, txload 1/255, rxload 1/255
 Encapsulation ARPA, loopback not set
 Keepalive set (10 sec)
 Half-duplex, 10Mb/s, 100BaseTX/FX

R2#sh int f0/0
FastEthernet0/0 is up, line protocol is up 
 Hardware is Gt96k FE, address is c401.6413.0000 (bia c401.6413.0000)
 Internet address is 10.1.1.2/24
 MTU 1500 bytes, BW 10000 Kbit/sec, DLY 1000 usec, 
 reliability 255/255, txload 1/255, rxload 1/255
 Encapsulation ARPA, loopback not set
 Keepalive set (10 sec) Half-duplex, 10Mb/s, 100BaseTX/FX

Answer

Bandwidth setting on R1: 10000

Delay setting on R1: 1000

((10,000,000 / 10,000) + 100) * 256
(1,000 + 100) * 256
1,100 * 256 = 281,600

R1#sh ip eigrp topology 10.1.1.0 255.255.255.0 
IP-EIGRP (AS 1): Topology entry for 10.1.1.0/24
 State is Passive, Query origin flag is 1, 1 Successor(s), FD is 281600
 Routing Descriptor Blocks:
 0.0.0.0 (FastEthernet0/0), from Connected, Send flag is 0x0
 Composite metric is (281600/0), Route is Internal

1. Filter the following routes:
* 10.1.5.1/24
* 10.2.2.1/24
* 10.5.7.1/24

2. Filter the following routes:
* 10.1.1.1/24
* 10.2.1.1/25
* 10.2.1.128/25
* 10.100.1.1/30

3. Filter all but the last route and allow no others
* 172.16.2.1/24
* 172.16.3.1/25
* 172.16.3.128/25
* 172.16.4.1/26
* 172.16.4.64/26
* 172.16.10.1/30

4. Filter all routes using one command
* 10.1.1.1/16
* 10.2.1.1/17
* 10.2.128.1/17
* 10.10.10.5/30

5. Filter all /30 routes
* 192.168.1.0/24
* 192.168.2.1/25
* 192.168.2.128/30
* 192.168.3.1/30

Answers are below so don’t scroll down too far!

Answers

1.

ip prefix-list 1 deny 10.0.0.0/13 ge 24 le 24
ip prefix-list 1 permit 0.0.0.0/0 le 32

2.

ip prefix-list 2 deny 10.1.0.0/9 ge 24 le 30
ip prefix-list 2 permit 0.0.0.0/0 le 32

3.

ip prefix-list 3 deny 172.16.1.0/20 ge 24 le 26
ip prefix-list 3 permit 172.16.10.0/30

4.

ip prefix-list 4 deny 10.0.0.0/11 ge 16 le 30
ip prefix-list 4 permit 0.0.0.0/0 le 32

5.

ip prefix-list 5 deny 192.168.1.0/21 ge 30 le 30
ip prefix-list 5 permit 0.0.0.0/0 le 32

SW1 (config-if)# spanning-tree [vlan vlan-id] cost cost

A third term exists which causes a little confusion: path cost. The path cost is the same thing as the port cost, just a different name for it.

I hope these are helpful.

Download: STP Exercises 1.1

Update: Version 1.1 fixes an error in the last answer. Thanks to adammw111 for letting me know.

• Spanning Tree
• Rapid Spanning Tree
• HSRP
• VRRP
• GLBP
• UDLD
• DTP
• VTP
• PAgP

Download: CCNP Timers

Update: I have updated the timer worksheet to include another UDLD timer and Errdisable defaults.

VTP is a technology which assists in VLAN configuration and assignment in a layer 2 domain. Without VTP, proper VLANs must be assigned to each trunk port. If a network has 10 switches and a single VLAN is added, it has to be configured on each switch and each trunk port. Not too hard, but a little error prone and tedious. This is where VTP steps in. A VLAN configuration change is made on a switch the VLAN information is sent to all switches in that VTP domain.

A VTP domain defines which VTP enabled switches are allowed to send VLAN information to each other. VTP domains could be created for a data center, another for the first floor, and another for the second floor. A VTP domain is specified with the vtp domain VTPDomain command.

One or more switches in a VTP domain need to be the VTP Server. Switches are assigned the VTP server role by issuing the vtp mode server command. VTP servers can have VLANs configured on them and will push the configuration out to all VTP servers and clients on the VTP domain.

A VTP client is a switch which accepts configurations but doesn’t allow for manual VLAN configuration through its CLI. Any VLAN configuration needs to be done on the VTP server. Immediately after the vlan.dat file is updated on the server, VTP packets are sent through the layer 2 network and clients update their vlan.dat file.

In addition to server and client modes, a third type exists. Transport mode effectively disables VTP on the switch without completely turning it off. VTP packets will be sent through a transparent switch but the packets won’t be processed by the transparent switch.

VTP servers and clients have a “VTP configuration revision number”. When a switch enters VTP server mode, the revision number is set at zero. When a client or server receives a VTP packet, it compares the domain, passwords, and revision numbers. If the domain and passwords match, it accepts the new configuration if the received revision number is higher than the current revision number.

Lets say a brand new switch network is brought up. Four switches are configured as clients while one is a server. A VLAN is created on the server. The VTP server increments the revision number by one and sends the update out. Any switches on the network in that VTP domain receive the update request and accept it because their revision numbers were zero and the new number is one.

The beginning of this article mentioned dangers around VTP. When a switch in server or client mode joins a network it broadcasts its VTP information including its revision number. Pretend there is a stable network with the VTP domain “VTPDomain” and a revision number of 176. An office closed so one of the switches in the office is brought into the active office to add a new floor of employees. The closed office also used the “VTPDomain” name but had a revision of 216. The switch is configured to be a client and is plugged into the network. Immediately it broadcasts its VTP information. All properly configured switches see the higher revision number and replace their VLAN configurations with the VLAN configuration from the closed office. Support calls ensue (that is unless they’re using VoIP on these same switches).

There are a few steps which can be taken to prevent this from happening.

1. Make sure unique VTP domain names are used for each domain.
2. Each VTP domain should have a unique password. If unique passwords are set, even if there is a VTP domain conflict, it won’t accept the bad configuration because the password won’t be accepted.
3. Before plugging any new switches into the network, set the switch to transparent mode and then to client or server mode. This action resets the VTP revision number to 0, guaranteeing it won’t broadcast bad VLAN information.

Configuring VTP is pretty straight forward so I won’t go into what each command does. Here is a basic configuration on a VTP server.

SW1(config)# vtp domain VTPDomain
Setting VTP domain name to VTPDomain.
SW1(config)# vtp mode server
Setting device to VTP Server mode for VLANS.
SW1(config)# vtp version 2
Setting device to VTP version 2.
SW1(config)# vtp password passw0rd
Setting device VLAN database password to passw0rd.

To verify configuration of VTP, run the show vtp status command.

VTP Version : 2
Configuration Revision : 0
Maximum VLANs supported locally : 1005
Number of existing VLANs : 1
VTP Operating Mode : Server
VTP Domain Name : VTPDomain
VTP Pruning Mode : Disabled
VTP V2 Mode : Disabled
VTP Traps Generation : Disabled
MD5 digest : 0x46 0x61 0xA6 0xC8 0x1F 0x9B 0x64 0x6A
Configuration last modified by 0.0.0.0 at 3-1-93 01:34:49
Local updater ID is 10.10.0.2 on interface Vl55 (lowest numbered VLAN interface found)

When two switches on a single network aren’t running VTP properly, compare the MD5 digest on the switches. If they do not match, review the VTP version, the domain, password, and revision numbers.

Required link: HSRP and ARP packet capture

When looking at its packets, HSRP is a relatively straight forward protocol. Each router announces its priority and come to an agreement on the active and standby routers. Every second each router sends a Hello UDP packet which declares its state. Notice the active router (192.168.10.2) sends state code 16 (active) while the standby router (192.168.10.3) sends state code 8 (standby). Alongside the state code is also each router’s priority. As long as the standby router’s priority is lower than the active router’s priority, the pattern goes on until a change occurs.

You will notice there are periodic advertisements sent out by the passive (standby) router. These announcements enable HSRP routers on the network to determine the HSRP state without being a member. These advertisements are also sent when a router is entering or leaving the passive state. Keep this in mind for later.

Packet 13

Pay attention to packet 13. The active router sends out a Hello packet with a priority of 75 instead of 100. When the standby router recognizes it has the highest priority, HSRP goes into action. First the standby router sends an advertise packet announcing it has an active interface (packet 14). Packet 15 then shows a Coup packet. Coup packets are sent when a standby router wants to become the active router. It sends its current state as well as the priority. Another advertisement packet is sent followed by a normal Hello packet, assuming it is the active router.

All this communication has happened between HSRP enables routers, blissfully ignored by downstream routers and hosts. At packet 17, no other devices are aware the HSRP active router has changed. However, the ARP tables and Spanning Tree topologies need to be updated with the path to the new active router. As far as the other devices on the network are concerned, the router was unplugged from one port and plugged into another port. The active router’s HSRP virtual MAC address (in this case 00:00:0c:07:ac:01) is broadcast in packet 18.

Packet 18

Packet 30, 31, and 32 show the HSRP topology stabilizing. The standby router goes through its Speak phase. Each time a Speak packet is sent the active router replies with a Hello packet preventing the Speaking router from becoming active. ARP packets are broadcast after 2 and 4 seconds. After the router goes from Speak to Standby, the topology is stable.

Packets 28 through 39

Packet 43 starts the process of the first router becoming active again because its tracked interface was plugged in bringing its priority back to 100. This is allowed to happen since the routers are configured with preempt, but it is not reflected in packet contents.

I set up two zones on my router named Lab and Home. Both were assigned to zone pairs while class-maps and policy-maps were properly applied. Or so I thought. When I tried to SSH into lab devices behind the 2801, SSH would work but RADIUS authentication would hang. After analyzing my setup using show run, I decided more troubleshooting was required.

First step was to make sure RADIUS traffic was indeed being blocked by the firewall with debug policy-map type inspect detail. When RADIUS traffic passed, I saw it was indeed dropping packets to or from the standard RADIUS authentication port, 1645. The line to match RADIUS was match protocol radius. My mistake was on relying upon the router to properly detect RADIUS traffic.

RADIUS uses port 1645 for authentication. For reasons I don’t understand, Cisco devices sometimes use 1812. I looked far and wide for a list of applications zone-based firewalls detect and the properties they use for detection, but couldn’t find anything. It became apparent I wasn’t going to defeat this using their built in rules and had to define my own.

I could have created an ACL and applied it to the class-map but wanted to find a cleaner, more ZBF-like way. Cisco includes the ip port-map command which creates custom applications. I defined user-radius (note: user defined applications must begin with user-) which matches to UDP packets from port 1645 to 1646:

Router1(config)# ip port-map user-radius port udp from 1645 to 1646 description Standard RADIUS ports

In very un-Cisco like fashion, my user-radius application even showed in auto-completion when defining my matching protocol. Once the custom protocol was assigned, RADIUS authentication immediately began working.

The lesson for me is not to trust the application definition profiles provided by Cisco in zone-based firewalls.

If you know of a list of zone-based firewall application profiles, please let me know in a comment.

Answer

This was pretty straight forward.  SW1 becomes the root bridge because it has the lowest root bridge ID (16384.0200.0000.1111). Not only is its MAC address lower, but its priority is lower as well.

Immediately both ports on the root bridge become designated ports since all ports on root bridges are designated. Default settings indicate a Fast Ethernet link has a STP cost of 19. Fa 0/2 has a SW2->SW1 cost of 19 (0 incoming, 19 added at Fa 0/2). Fa 0/1 on SW3 also has the same value because its SW3->SW1 has the same Fast Ethernet link settings back to SW1. This leaves two ports, SW2′s Fa 0/1 and SW3′s  Fa0/2 to find out which is blocking and which is designated.

STP uses four criteria to determine links:

1. Lowest root bridge ID

2. Lowest root path cost to root bridge

3. Lowest sender bridge ID

4. Lowest sender port ID

1 and 2 both are ties so we’ll have to go to the third item to break the tie. In this case, SW2 has a lower bridge ID than SW3 so SW2′s Fa0/1 becomes the designated port leaving SW3′s Fa 0/3 to go into blocking mode.

STP should now be fully converged.