Ccnp enterprise workbook v1.0 eigrp

TRAINER: SAGAR | www.NetworkJourney.com | www.youtube.com/c/NetworkJourney | CCNP Enterprise
CCNP ENTERPRISE 2020 LAB WORKBOOK|| TRAINER: SAGAR || WWW.YOUTUBE.COM/C/NETWORKJOURNEY
1April 24, 2020
CCNP ENTERPRISE 2020
ENCOR 350-401
ENARSI 300-410
WORKBOOK
For enrolling in Online “CCNP Enterprise” batch
• Whatsapp me: https://wa.me/919739521088 (Mr. Sagar, Core Trainer)
Whatsapp me: https://wa.me/919049852904 (Mr. Abdul Azeem, Lab Support)
• Email me: networkjourneydotcom@gmail.com
• Class#1: https://youtu.be/SKHYLoXnggE
• Class# 2: https://youtu.be/TzJHkwt5EqM

2April 24, 2020
Table of Contents
Device Initial Configuration -Switches 7
CCNP LAB TOPOLOGY {FULL} 8
LAB #1 CREATE - VLAN, MANAGEMENT INTERFACE, TELNET & SSH 9
Configuration: 10
Verifications: 11
LAB #2 CONFIGURE - TRUNK and VTP version 2 13
Configuration: 13
Verifications: 16
LAB #3 CONFIGURE – VTP version 3 19
Configuration: 20
VERIFICATIONS: 21
LAB #4 CONFIGURE – STP, MANIPULATE PRIMARY ROOT SWITCH, PATH COST 23
CONFIGURATION FOR TASK#1: 24
Verifications: 29
LAB #5 CONFIGURE – RSTP, PORTFAST, BPDUGUARD, BPDUFILTER, ROOTGUARD,
LOOPGUARD 30
Enable RSTP on all switches: 31
Manipulating Root Bridge Switches: 33
CONFIGURATION FOR TASK#2: To configure & verify Portfast 35
TASK#2: To configure & verify BPDUGuard 38
TASK#3: To configure & verify BPDUFilter 41
TASK#4: To configure & verify RootGuard 44
LAB #6 CONFIGURE – MSTP 46
CONFIGURATION TASK#1,2 & 3: To configure & verify MST Region 1, Region 2 and
Interoperability 47
VERIFICATION TASK#1: To configure & verify MST Region 1 47
CONFIGURATION TASK#4: To manipulate “instance priority” in SCOTSW01, SCOTSW02 52
VERIFICATION TASK#4: To manipulate “instance priority” in SCOTSW01, SCOTSW02 52

3April 24, 2020
CONFIGURATION TASK#5: To manipulate “port cost” between SCOTSW02_Gi0/2-3 <->
SCOTSW04_Gi0/2-3 53
CONFIGURATIONS: 53
VERIFICATION TASK#5 53
CONFIGURATION TASK#6: To manipulate “port priority” between SCOTSW02_Gi0/2-3 <->
SCOTSW04_Gi0/2-3 54
CONFIGURATION TASK#7: To manipulate “hello timer” in MST switch SCOTSW02 54
VERIFICATION TASK#7: 54
CONFIGURATION TASK#8: To manipulate “forward timer” in MST switch SCOTSW02 54
CONFIGURATION TASK#9: To manipulate “max age timer” in MST switch SCOTSW02 55
IMPORTANT FACT!!! 55
LAB #7 CONFIGURE – DTP (DYNAMIC TRUNKING PROTOCOL) 56
CONFIGURATION TASK#1: Configure “DTP desirable-desirable” between SCOTSW01 <->
SCOTSW02 57
CONFIGURATION TASK#2: Configure “DTP auto-desirable” between SCOTSW01 <-> SCOTSW0358
CONFIGURATION TASK#3: Configure “DTP auto-auto” between SCOTSW03 <-> SCOTSW04 58
CONFIGURATION TASK#4: Configure DTP between SCOTSW02_Trunk Dot1Q <->
SCOTSW04_auto 59
SCOTSW04_desirable 60
LAB #8 CONFIGURE – ETHERCHANNEL 61
CONFIGURATION TASK#1: Configure “PAgP” between SCOTSW01 <-> SCOTSW03 62
CONFIGURATION TASK#2: “LACP” between SCOTSW01 <-> SCOTSW02 66
CONFIGURATION TASK#3: “ON” between SCOTSW02 <-> SCOTSW04 70
Advanced LACP Configuration Options 73

4April 24, 2020
CONFIGURATION TASK#4: Configure “LACP Fast” 73
CONFIGURATION TASK#5: Minimum Number of Port-Channel Member Interfaces 74
CONFIGURATION TASK#6: Maximum Number of Port-Channel Member Interfaces 75
CONFIGURATION TASK#7: LACP System Priority 76
CONFIGURATION TASK#8: LACP Interface Priority 76
CONFIGURATION TASK#9: EtherChannel Misconfiguration Guard 77
LAB #9 CONFIGURE – HSRPv1 78
CONFIGURATION TASK#1: Configure “Initial config” on MOSCOWR19, MOSCOWR20,
MOSCOWSW01, MOSCOWSW02, PC10, PC19, PC11, PC12 79
VERIFICATIONS TASK#1: Configure “Initial config” on MOSCOWR19, MOSCOWR20,
MOSCOWSW01, MOSCOWSW02 81
CONFIGURATION TASK #2: Configure “HSRPv1” for “Vlan 1”, observe the behaviour. 84
VERIFICATION TASK #2: 84
CONFIGURATION TASK #3: Configure ”Priority 110” on MOSCOWR20 86
CONFIGURATION TASK #4: Configure “Load Sharing”. Vlan1 Active on MOSCOWR19 and Vlan40
Active on MOSCOWR20 86
CONFIGURATION TASK #5: Object-tracking (WAN side facing) 87
LAB #10 CONFIGURE – HSRPv2 90
Task#2 Configure “HSRPv2” for only Ethernet0/1.1 (Note: HSRPv1 still running on
Ethernet0/1.40) 91
VERIFICATION TASK #3: Validate Packet structure using Wireshark for HSRPv2 92
Task#4 Configure “HSRPv2” for Ethernet0/1.40 as well 93
Verification Task#4 Configure “HSRPv2” for Ethernet0/1.40 as well 93
LAB #11 CONFIGURE – VRRPv2 and VRRPv3 95
Task#2 Configure “VRRPv2” on Ethernet0/1.1 and Ethernet0/1.40 96
Verification Task#2: 96
Verification Task#3: Wireshark Captures 97
Task#4 Use real interface IP for “VRRPv2” on Ethernet0/1.1 and Ethernet0/1.40 so as to avoid
usage of need for third IP for VIP. 97
Verifications#4 98

5April 24, 2020
Task#5 Upgrade VRRPv2 to VRRPv3 on Ethernet0/1.1 and Ethernet0/1.40 and observe the
Wireshark captures 98
Verifications#5 99
LAB #12 CONFIGURE – GLBP 101
Task#2 Configure “GLBP” on Ethernet0/1.1 and Ethernet0/1.40 using new VIP IP (172.16.10.254)
102
Verification Task#2 102
Task#3 Change AVP role by changing Priority and Prompt configurations 104
Task#4 Configure MD5 Authentication for Group 1 105
Task#5 Configure Tracking (object) on MOSCOWR20 Eth0/2 107
Task#6 Change Load-balancing Method to “Weighted” 109
LAB #14 CONFIGURE – OSPFv2 Error! Bookmark not defined.
CONFIGURATION TASK #1: Initial Configs Error! Bookmark not defined.
CONFIGURATION TASK #2: Configure OSPF (single-area) Error! Bookmark not defined.
VERIFICATION TASKS#2 Error! Bookmark not defined.
CONFIGURATION TASK #3: MANIPULATE DR/BDR ELECTION Error! Bookmark not defined.
VERIFICATION TASK #3: Error! Bookmark not defined.
CONFIGURATION TASK #4: MANIPULATE ROUTER-ID ELECTION Error! Bookmark not defined.
CONFIGURATION TASK #5: MANIPULATE HELLO/HOLD TIMER Error! Bookmark not defined.
CONFIGURATION TASK #6: CHANGE AREA ID Error! Bookmark not defined.
CONFIGURATION TASK #7: OSPF AUTHENTICATIION Error! Bookmark not defined.
CONFIGURATION TASK #8: OSPF AREA TYPE Error! Bookmark not defined.
CONFIGURATION TASK #9: OSPF MTU MISMATCH Error! Bookmark not defined.
VERIFICATION TASK #9: OSPF MTU MISMATCH Error! Bookmark not defined.
CONFIGURATION TASK #10: VERIFY OSPF MUTLICAST ADDRESS 224.0.0.6 and 224.0.0.5 Error!
Bookmark not defined.
VERIFICATIONS TASK#10 Error! Bookmark not defined.
LAB #15 CONFIGURE – OSPFv2 ADVANCE TOPICS Error! Bookmark not defined.

6April 24, 2020
CONFIGURATION TASK #1: INITIAL CONFIGS Error! Bookmark not defined.
CONFIGURATION TASK #2: CONFIGURE OSPF (Multi-area) VIA “INTERFACE” METHOD Error!
Bookmark not defined.
VERIFICATION TASK #2: Error! Bookmark not defined.

7April 24, 2020
Device Initial Configuration -Switches
To make switches usable for new/next labs.
If incase there are vlans or configs already present in the switches, clear all the configurations to
have brand new switch for your new/next lab.
Switch#erase /all nvram:
Erasing the nvram filesystem will remove all files! Continue? [confirm]
[OK]
Erase of nvram: complete
Switch#
Switch#reload
Proceed with reload? [confirm]
This will clear all the previous configs on the switch.

8April 24, 2020
CCNP LAB TOPOLOGY {FULL}
Version 2.0 (Last updated August)
Version 1.0 (Last updated April)

9April 24, 2020
LAB #1 CREATE - VLAN, MANAGEMENT INTERFACE, TELNET & SSH
Objectives: Configure SCOTSW01, SCOTSW02, SCOTSW03, SCOTSW04,
SCOTSW05, SCOTSW06, SCOTSW07, SCOTSW08 with the following:
1. Define Hostname accordingly as per the above topology section
2. Create VLANs as below:
!
vlan 99
name MANAGEMENT
!

10April 24, 2020
vlan 100
name SERVERS
!
vlan 110
name GUEST
!
vlan 120
name OFFICE
!
vlan 999
name PARKING_LOT
state suspend
!
vlan 666
name NATIVE_DO_NOT_USE
exit
3. Create Management Interface on Vlan 99
4. Enable Telnet and SSH for Remote connection for user id “admin” with privilege level
“15” with password “cisco”
Configuration:
SCOTSW01
Switch#configure terminal
Switch(config)#hostname SCOTSW01
SCOTSW01(config)#vlan 99
SCOTSW01(config-vlan)#name MANAGEMENT
SCOTSW01(config-vlan)#!
SCOTSW01(config-vlan)#vlan 100
SCOTSW01(config-vlan)#name SERVERS
SCOTSW01(config-vlan)#name GUEST
SCOTSW01(config-vlan)#name OFFICE
SCOTSW01(config-vlan)#name PARKING_LOT
SCOTSW01(config-vlan)#state suspend
SCOTSW01(config-vlan)#name NATIVE_DO_NOT_USE
SCOTSW01(config-vlan)#exit
NOTE: The VLANs will not appear in the VLAN database until the exit command is issued

11April 24, 2020
To globally suspend a VLAN, use the state suspend command in the VLAN configuration mode.
This state is propagated by VTP to all other switches in the VTP domain if VTP is in use.
To locally shut down a VLAN, use the shutdown command in the VLAN configuration mode. This
setting is not propagated through VTP
SCOTSW01(config)#interface vlan 99
SCOTSW01(config-if)#ip address 192.168.99.101 255.255.255.0
SCOTSW01(config-if)#no shutdown
SCOTSW01(config-if)#exit
NOTE: Interface Vlan 99 will be initially Down as the Vlan 99 (broadcast) is not mapped with any
interface.
Wait for some time. We will make Trunking between inter-switch’s and allow Vlan 99
Create Telnet for remote connection:
SCOTSW01(config)#line vty 0 15
SCOTSW01(config-line)#login local
SCOTSW01(config-line)#transport input all
SCOTSW01(config)#username admin privilege 15 password cisco
NOTE: We are creating user “admin” with highest privilege of 15 level. Hence, no need to creating
“enable secret “ or “enable password “
Create SSH for remote connections:
SCOTSW01(config)#ip domain-name networkjourney.com
SCOTSW01(config)# crypto key zeroize
SCOTSW01(config)#crypto key generate rsa modulus 1024
Do not forget to configure above configurations on other Switches - SCOTSW02, SCOTSW03,
SCOTSW04, SCOTSW05, SCOTSW06, SCOTSW07, SCOTSW08 accordingly.
The Hostname, Management IP address will differ for each switch. So please refer the topology
for the right hostname and management IP address.
Verifications:
After configuring the VLANs, issue the show vtp status command and you will see that the all-
important configuration revision number has increased based on these changes to the VLAN
database. Note that the revision number you have when performing this lab may be different.
SCOTSW01#sh vtp status | i Revision
Configuration Revision : 6
SCOTSW01#show vlan brief

12April 24, 2020
VLAN Name Status Ports
---- -------------------------------- --------- -------------------------------
1 default active Gi0/0, Gi0/2, Gi0/3, Gi1/0
Gi1/1, Gi1/2, Gi1/3, Gi2/0
Gi2/1, Gi2/2, Gi2/3, Gi3/0
Gi3/1, Gi3/2, Gi3/3
99 MANAGEMENT active
100 SERVERS active
110 GUEST active
120 OFFICE active
666 NATIVE_DO_NOT_USE active
999 PARKING_LOT suspended
Management IP is configured on Interface Vlan 99
SCOTSW01#sh run interface vlan 99
interface Vlan99
ip address 192.168.99.101 255.255.255.0
end
You can test if telnet and ssh are configured rightly or not by doing self-connection test
To self-test telnet:
SCOTSW01#telnet 192.168.99.101
Trying 192.168.99.101 ... Open
To self-test SSH:
SCOTSW01#ssh -l admin 192.168.99.101
**************************************************************************
* IOSv is strictly limited to use for evaluation, demonstration and IOS *
* education. IOSv is provided as-is and is not supported by Cisco's *
* Technical Advisory Center. Any use or disclosure, in whole or in part, *
* of the IOSv Software or Documentation to any third party for any *
* purposes is expressly prohibited except as otherwise authorized by *
* Cisco in writing. *
**************************************************************************
Password:
Do not forget to configure above configurations on other Switches - SCOTSW02, SCOTSW03,
SCOTSW04, SCOTSW05, SCOTSW06, SCOTSW07, SCOTSW08 accordingly.
The Hostname, Management IP address will differ for each switch. So please refer the topology
for the right hostname and management IP address.
Verify the configured commands with the help of above “show ….” Commands accordingly.

13April 24, 2020
LAB #2 CONFIGURE - TRUNK and VTP version 2
Objectives: Configure SCOTSW01, SCOTSW02, SCOTSW03, SCOTSW04,
SCOTSW05, SCOTSW06, SCOTSW07, SCOTSW08 as following:
1. The VTP domain should be configured to “CCNP_ENTERPRISE” (without the quotes)
2. Ensure that VTP traffic is MD5 secured using a password of “cisco” (without quotes)
3. Use VTP version 2
“Server” mode on SCOTSW01 and SCOTSW02.
“Transparent” mode on SCOTSW03 and SCOTSW04
“Client” mode on SCOTSW05 and SCOTSW06
“Transparent” mode on SCOTSW07 and SCOTSW08
4. Configure 802.1q trunk links between the switches according to the Layer 2 Diagram show
above
5. Only active VLANs should be allowed on trunk links
6. VLAN 811 MTU(Maximum Transmission Unit) should be set to 1400
7. Ensure that VLAN 666 traffic is not tagged when sent over the trunk links
SCOTSW01#
int range gi0/0-1
no switchport trunk native vlan 666
SCOTSW02#
int range gi0/0-1
no sw trunk native vlan 666
8. After synchronization both switches must not propagate VLAN configuration changes to
each other
Configuration:
SCOTW01
hostname SCOTSW01
vtp domain CCNP_ENTERPRISE
vtp version 2
vtp password cisco
vtp mode server
vlan 811
mtu 1400
interface range gi0/0-3
switchport trunk enc dot1q
sw tr native vlan 666
sw tr all vlan 99,100,110,120,666,999
sw mo trunk
vtp mode transparent (task#8)
SCOTSW02
hostname SCOTSW02

14April 24, 2020
vtp version 2
vtp password cisco
vtp mode server
sw tr all vlan 99,100,110,120,666,999
sw mo trunk
vtp mode transparent (task#8)
SCOTSW03
hostname SCOTSW03
vtp version 2
vtp password cisco
vtp mode transparent
interface range gi0/0-3, gi1/0
sw tr all vlan 99,100,110,120,666,999
sw mo trunk
SCOTSW04
hostname SCOTSW04
vtp version 2
vtp password cisco
sw tr all vlan 99,100,110,120,666,999
sw mo trunk
SCOTSW05
hostname SCOTSW05
vtp version 2
vtp password cisco
vtp mode client

15April 24, 2020
sw tr all vlan 99,100,110,120,666,999
sw mo trunk
SCOTSW06
hostname SCOTSW06
vtp version 2
vtp password cisco
vtp mode client
sw tr all vlan 99,100,110,120,666,999
sw mo trunk
SCOTSW07
hostname SCOTSW07
vtp version 2
vtp password cisco
sw tr all vlan 99,100,110,120,666,999
sw mo trunk
SCOTSW08
hostname SCOTSW08
vtp version 2
vtp password cisco
sw tr all vlan 99,100,110,120,666,999
sw mo trunk
NOTE: The VTP will only start working once “trunking” is configured and activated.
VTP is functional only on over Trunking interface.

16April 24, 2020
Verifications:
**GNS3 and EVE-NG both failed at task 3. This might be due to IOS version used inside Emulators
**I got successful output with Packet-Tracer.
**As a turnover fix on GNS/Eveng, make SCOTSW03 SCOTSW04 as “client mode”
VERIFICATION TASK 1: To verify the VTP DOMAIN name
SCOTSW01#show vtp status
VTP Version capable : 1 to 3
VTP version running : 2
VTP Domain Name : CCNP_ENTERPRISE
VTP Pruning Mode : Disabled
VTP Traps Generation : Disabled
Device ID : 0c67.916e.8000
Configuration last modified by 0.0.0.0 at 4-12-20 19:49:46
Local updater ID is 0.0.0.0 (no valid interface found)
Feature VLAN:
--------------
VTP Operating Mode : Server
Maximum VLANs supported locally : 1005
Number of existing VLANs : 27
MD5 digest : 0x25 0xB6 0x82 0xAA 0x89 0xE6 0xBE 0x33
0xD7 0x6E 0xA6 0x03 0x19 0x4D 0xE5 0xAD
Note: MD5 digest changes everytime because the configuration revision number is used to calculate the
hash and as it is different after creating the vlan then the md5 will be different.
VERIFICATION TASK 2: Verify VTP password
SCOTSW01#show vtp password
VTP Password: cisco
VERIFICATION TASK 3: Verify VTP mode
SCOTSW01#show vtp status | i Operating
VTP Operating Mode : Server
VERIFICATION TASK 4 & 5: VERIFY TRUNK ALLOWED ON INTERFACE
SCOTSW01#show running-config interface gigabitEthernet 0/3
!
interface GigabitEthernet0/3
switchport trunk allowed vlan 99,100,110,120,666,999
switchport trunk encapsulation dot1q
switchport trunk native vlan 666

17April 24, 2020
switchport mode trunk
media-type rj45
negotiation auto
end
Second way to check if the Trunking vlans allowed in switches
SCOTSW01#show interfaces trunk
Port Mode Encapsulation Status Native vlan
Gi0/0 on 802.1q trunking 666
Port Vlans allowed on trunk
Gi0/0 99-100,110,120,666,999
Gi0/1 99-100,110,120,666,999
Gi0/2 99-100,110,120,666,999
Gi0/3 99-100,110,120,666,999
VERIFICATION TASK 6: Verify MTU size for VLAN 811
SCOTSW01#show vlan id 811
VLAN Name Status Ports
---- -------------------------------- --------- -------------------------------
811 VLAN0811 active
VLAN Type SAID MTU Parent RingNo BridgeNo Stp BrdgMode Trans1 Trans2
---- ----- ---------- ----- ------ ------ -------- ---- -------- ------ ------
811 enet 100811 1400 - - - - - 0 0
Remote SPAN VLAN
----------------
Disabled
Primary Secondary Type Ports
------- --------- ----------------- ------------------------------------------
VERIFICATION TASK 7: Verify Native VLAN behavior
Tagged traffic on Wireshak for TRUNK interface:

18April 24, 2020
Native VLAN = untagged traffic
Untagged traffic capture on Wireshark for NATIVE VLAN:
VERIFICATION TASK 8:
Config:
SCOTSW01(config)#vtp mode transparent
Verifications:
SCOTSW01#sh vtp status | i Operating
VTP Operating Mode : Transparent
SCOTSW02#sh vtp status | i Operating

19April 24, 2020
LAB #3 CONFIGURE – VTP version 3
VTP version 3 is backwards compatible with VTP version 2; at the boundary of the two protocols, a
VTP version 3 switch will send out both version 3 and version 2-compatible messages. Version 2
messages received by a version 3 switch are discarded.
Objectives: Configure SCOTSW01, SCOTSW03, SCOTSW05, SCOTSW07 as
following:
VTP version 3 cannot be enabled unless a VTP domain name has been set, so for this step, setting
the domain name is not needed as we are using the Lab#2 and upgrading some of the Switches to
VTP 3 as per the diagram shown.
Switch(config)#vtp version 3
Cannot set the version to 3 because domain name is not configured
1. The VTP domain should be configured to “CCNP_ENTERPRISE” (without the quotes) since it
is already done in Lab#2, goto Task#2.
2. Configure VTP version 3 on SCOTSW01, SCOTSW03, SCOTSW05, SCOTSW07.

20April 24, 2020
3. Configure VTP version 3 on below switches
“Primary Server” mode on SCOTSW01
“Transparent” mode on SCOTSW03
"Server" mode on SCOTSW05
"Client" mode on SCOTSW07
4. Configure 802.1q trunk links between the switches according to the Layer 2 Diagram show
above, this is already done from Lab#2, goto next Task#5
5. Create new Vlan 444 and see the VTP 3 and VTP 2 advertisements on the borders.
Configuration:
SCOTW01
vtp version 3
SCOTSW01#vtp primary vlan [to be configured on user privilege mode]
This system is becoming primary server for feature vlan
No conflicting VTP3 devices found.
Do you want to continue? [confirm]
!
Vlan 444
exit
!
SCOTW03
SCOTSW03(config)#vtp version 3
SCOTW05
SCOTSW05(config)#vtp mode server
SCOTW07
SCOTSW07(config)#vtp mode client
Answer for #4
SCOTW01
!
Vlan 444
exit
!

21April 24, 2020
VERIFICATIONS:
Verify VTPv3 status on SCOTSW01
SCOTSW01#show vtp status
VTP Version capable : 1 to 3
VTP version running : 3
VTP Domain Name : CCNP_ENTERPRISE
VTP Pruning Mode : Disabled
VTP Traps Generation : Disabled
Device ID : 0c67.916e.8000
Feature VLAN:
--------------
VTP Operating Mode : Primary Server
Number of existing VLANs : 5
Number of existing extended VLANs : 0
Maximum VLANs supported locally : 4096
Primary ID : 0c67.916e.8000
Primary Description : SCOTSW01
MD5 digest : 0x74 0xEB 0x87 0xFF 0xA2 0x91 0x60 0x2D
0xFD 0x82 0x67 0x93 0xC4 0x6C 0x2B 0xB4
Feature MST:
--------------
Feature UNKNOWN:
--------------
Verify VTP packet versions getting by VTPv3 switch to another VTPv3 and also VTPv3 switch to VTPv2
using Wiresharks:
Wireshark capture between SCOTSW01 and SCOTSW03 (VTPv3 <-> VTPv3)

22April 24, 2020
VTPv3 Primary Server Switch will advertise advertisement of version 3 to Switch running on VTPv3
mode.
Wireshark capture between SCOTSW01 and SCOTSW02 (VTPv3 <-> VTPv2)
VTPv3 Primary Server Switch will advertise advertisement of version 2 to Switch running on VTPv2
mode.
All other Switches are pointing to SCOTSW01 which is VTPv3 Primary Server.
SCOTSW01#show vtp status | i ID
Device ID : 0c67.916e.8000
Primary ID : 0c67.916e.8000
Device ID : 0c67.9159.8000
Device ID : 0c67.912e.8000

23April 24, 2020
LAB #4 CONFIGURE – STP, MANIPULATE PRIMARY ROOT SWITCH, PATH COST
Objectives: Observe on SCOTSW01, SCOTSW02, SCOTSW03, SCOTSW04,
1. Identify and modify the Root bridge
2. Manipulate port and path costs
3. Examine Re-convergence Time

24April 24, 2020
CONFIGURATION FOR TASK#1:
Use the show spanning-tree root command on all of the switches to find the root switch for all of the VLANs.
Note: Your results may vary from the examples.
SCOTTSW06#show spanning-tree root {currently acting as Root Bridge}
Root Hello Max Fwd
Vlan Root ID Cost Time Age Dly Root Port
---------------- -------------------- --------- ----- --- --- ------------
VLAN0001 32769 0c67.9114.be00 0 2 20 15
SCOTTSW01#show spanning-tree root
Root Hello Max Fwd
---------------- -------------------- --------- ----- --- --- ------------
VLAN0001 32769 0c67.9114.be00 8 2 20 15 Gi0/2
SCOTTSW05#show spanning-tree root
Root Hello Max Fwd
---------------- -------------------- --------- ----- --- --- ------------
VLAN0001 32769 0c67.9114.be00 4 2 20 15 Gi0/0
The current root bridge was elected based on the lowest Bridge ID (consisting of the Priority,
extended system ID equal to the VLAN ID, and base MAC address values). In the output above, the
root’s MAC is 0c67.9114.be00
BRIDGE ID = PRIORITY (Base Priority + Sys-ext-ID) + MAC ADDRESS
There are two basic ways to manipulate the configuration to control the location of the root bridge.
• The spanning-tree vlan vlan-id priority value command can be used to manually set a
priority value
• The spanning-tree vlan vlan-id root { primary | secondary } command can be
used to automatically set a priority value.
The difference between the two is the priority command will set a specific number (multiple of
4096) as the priority, while the root primary command will set the local bridge's priority to 24,576 (if
the local bridge MAC is lower than the current root bridge's MAC) or 4096 lower than the current
root's priority (if the local bridge MAC is higher than the current root bridge's MAC).
The logic behind this operation is straight-forward. The root primary command tries to lower the
priority only as much as is needed to win the root election, while leaving priorities between 24576
and the default 32768 for use by secondary bridges. The command always takes the entire Bridge ID
into account when computing the resulting priority value.

25April 24, 2020
SCOTTSW01# conf t
Enter configuration commands, one per line. End with CNTL/Z.
SCOTTSW01(config)# spanning-tree vlan 1 root primary
SCOTTSW02(config)# exit
SCOTTSW02# conf t
SCOTTSW02(config)# spanning-tree vlan 1 root secondary
SCOTTSW02(config)# exit
The Priority is lowered to 24,576 on Primary Root (Calculation: 32768-8192 for primary root)
SCOTTSW01# sh spanning-tree
VLAN0001
Spanning tree enabled protocol ieee
Root ID Priority 24577
Address 0c67.916e.7e00
This bridge is the root
Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec
Bridge ID Priority 24577 (priority 24576 sys-id-ext 1)
Aging Time 300 sec
The Priority is lowered by 28,672 on Secondary Root (Calculation: 32768-4096 for secondary root)
SCOTTSW02# sh spanning-tree
VLAN0001
Cost 4
Port 1 (GigabitEthernet0/0)
Address 0c67.9159.b100
Aging Time 15 sec
The show spanning-tree bridge command also provides detailed information about the current
configuration of the local bridge:
SCOTTSW01# show spanning-tree bridge
Hello Max Fwd
Vlan Bridge ID Time Age Dly Protocol
---------------- --------------------------------- ----- --- --- --------
VLAN0001 24577 (24576, 1) 0c67.916e.7e00 2 20 15 ieee

26April 24, 2020
SCOTTSW02# show spanning-tree bridge
Hello Max Fwd
Vlan Bridge ID Time Age Dly Protocol
---------------- --------------------------------- ----- --- --- --------
VLAN0001 28673 (28672, 1) 0c67.9159.b100 2 20 15 ieee
MANIPULATE PORT and PATH COSTS
As the network is implemented right now, there are two paths between each directly connected
switch. As the Root Port is elected, path and port costs are evaluated to determine the shortest path
to the root bridge.
In the case where there are multiple equal cost paths to the root bridge, additional attributes must
be evaluated. In our case, the lower interface number (for example, Gi0/1) is chosen as the Root
Port, and the higher interface number (for example, Gi0/2) is put into a spanning tree Blocking state.
You can see which ports are blocked with the show spanning-tree vlan-id command or the show
spanning-tree blockedports command. For now, examine VLAN 1 on SCOTTSW02, SCOTTSW03,
SCOTTSW04.
SCOTTSW02#show spanning-tree blockedports
Name Blocked Interfaces List
-------------------- ------------------------------------
VLAN0001 Gi0/1
Number of blocked ports (segments) in the system : 1
SCOTTSW02#show spanning-tree
VLAN0001
Cost 4
Aging Time 300 sec
Interface Role Sts Cost Prio.Nbr Type
------------------- ---- --- --------- -------- --------------------------------
Gi0/0 Root FWD 4 128.1 P2p
Gi0/1 Altn BLK 4 128.2 P2p
Gi0/2 Desg FWD 4 128.3 P2p

27April 24, 2020
TIME TO MANIPULATE USING STP COST:
It is possible to manipulate which port becomes the Root Port on non-root bridges by manipulating
the port cost value, or by changing the port priority value. Remember that this change could have an
impact on downstream switches as well. For this example, we will examine both options.
Note: The changes you are about to implement are considered topology changes and could have a
significant impact on the overall structure of the spanning tree in your switch network. Do not
make these changes in a production network without careful planning and prior coordination.
Goto SCOTTSW03 and Manipulate the Cost for Gi0/3 (currently STP blocked port)
SCOTTSW03#show spanning-tree blockedports
-------------------- ------------------------------------
VLAN0001 Gi0/3
SCOTTSW03#sh spanning-tree
VLAN0001
Cost 4
Address 0c67.912e.9400
Aging Time 15 sec
------------------- ---- --- --------- -------- --------------------------------
SCOTTSW03# conf t
SCOTTSW03(config)#int ran gi0/2-3
SCOTTSW03(config-if-range)#shut
SCOTTSW03(config-if-range)#exit
SCOTTSW03(config)#interface gi0/3
SCOTTSW03(config-if)#spanning-tree cost 2

28April 24, 2020
SCOTTSW03(config-if)#exit
SCOTTSW03(config-if-range)#no shut
SCOTTSW03(config-if-range)#end
SCOTTSW03#sh spanning-tree blockedports
-------------------- ------------------------------------
VLAN0001 Gi0/2
SCOTTSW03#show spanning-tree
VLAN0001
Cost 2
Aging Time 300 sec
------------------- ---- --- --------- -------- --------------------------------
Alternatively, you can modify this behaviour with manipulating Port-Priority as well:
SCOTTSW03 (config)#int gi0/0
SCOTTSW03 (config-if)#spanning-tree port-priority ?
<0-224> port priority in increments of 32

29April 24, 2020
Verifications:
Examine Re-convergence Time:
Enable Debug STP command to see the convergence timers
SCOTTSW03#debug spanning-tree events
SCOTTSW03#
*Apr 20 13:13:57.732: STP: VLAN0001 Gi0/2 -> listening
*Apr 20 13:13:58.090: STP: VLAN0001 heard root 24577-0c67.916e.7e00 on Gi0/2
*Apr 20 13:13:58.091: supersedes 32769-0c67.9114.be00
*Apr 20 13:14:12.731: STP: VLAN0001 Gi0/2 -> learning
*Apr 20 13:14:27.738: STP[1]: Generating TC trap for port GigabitEthernet0/2
*Apr 20 13:14:27.740: STP: VLAN0001 sent Topology Change Notice on Gi0/2
*Apr 20 13:14:27.740: STP: VLAN0001 Gi0/2 -> forwarding
*Apr 20 13:14:29.156: STP: VLAN0001 Topology Change rcvd on Gi0/0
*Apr 20 13:14:29.158: STP: VLAN0001 sent Topology Change Notice on Gi0/2

30April 24, 2020
LAB #5 CONFIGURE – RSTP, PORTFAST, BPDUGUARD, BPDUFILTER, ROOTGUARD, LOOPGUARD
Objectives: Observe on SCOTSW01, SCOTSW02, SCOTSW03, SCOTSW04,
1. Configure Rapid-STP and verify its behaviour
2. Configure and Verify Portfast
3. Configure and Verify BPDUGuard
4. Configure and Verify BPDUFilter
5. Configure and Verify RootGuard
6. Configure and Verify LoopGuard

31April 24, 2020
RSTP is backward compatible with legacy STP 802.1D
Enable RSTP on all switches:
SCOTSW01(config)#spanning-tree mode rapid-pvst
SCOTSW01(config)#end
Upon activating RSTP on every switch, you can see “proposal” and “agreements”
To enable debug for rstp
SCOTSW01#debug spanning-tree events
Debug Packets for RSTP on Root Bridge Switch
*Apr 21 20:46:00.427: RSTP(1): Gi2/2 fdwhile Expired
*Apr 21 20:46:00.505: RSTP(1): transmitting a proposal on Gi2/3
*Apr 21 20:46:00.506: RSTP(1): Gi2/3 fdwhile Expired
Debug Packets for RSTP on Non Root-bridge switch
*Apr 21 20:49:38.033: RSTP(1): Gi0/2 rcvd info expired
*Apr 21 20:49:38.033: RSTP(1): Gi0/2 is now designated

32April 24, 2020
*Apr 21 20:49:38.054: RSTP(1): updt roles, received superior bpdu on Gi0/2
*Apr 21 20:49:38.055: RSTP(1): Gi0/2 is now alternate
SCOTSW05#sh spanning-tree
VLAN0001
Spanning tree enabled protocol rstp
Address 0c67.9114.be00
Aging Time 300 sec
------------------- ---- --- --------- -------- --------------------------------
Gi0/0 Desg FWD 4 128.1 P2p Peer(STP)
P2p Peer(STP) is for interoperability.
It is seen between RSTP and legacy STP running on interface.
RSTP will fallback to legacy STP behaviour of 50 sec of transition period on such interoperability
interfaces.
In addition to above output, we can see additional two features “ALT BLK” port and “BACKUP BLK”
port in RSTP.
SCOTSW01#sh spanning-tree
VLAN0001
Address 0c67.91c0.f900
Cost 12
Aging Time 300 sec
------------------- ---- --- --------- -------- --------------------------------

33April 24, 2020
<!output omitted>
Gi0/3 Altn BLK 4 128.4 P2p Altn BLK = Uplinkfast (Alternate port)
SCOTSW08#show spanning-tree
VLAN0001
Cost 4
Address 0c67.911c.e000
Aging Time 300 sec
------------------- ---- --- --------- -------- --------------------------------
<!output omitted>
Gi0/3 Back BLK 4 128.4 P2p Back BLK = Backbonefast (Backup port)
Manipulating Root Bridge Switches:
Make SCOTSW01 to be Root Bridge:
This can be done as similar as done on legacy STP.
Manipulate the priority or set keyword “primary” on SCOTSW01 as shown below:
SCOTSW01(config)#spanning-tree vlan 1 priority 4096
Or
SCOTSW01(config)#spanning-tree vlan 1 root primary
Make SCOTSW03_Gi0/3 to be DSG FWD:
By default, due to STP calculations:
SCOTSW03_Gi0/2 = DSG FWD
SCOTSW03_Gi0/3 = ALT BLK
However, I want to make SCOTSW03_Gi0/3 as DSG FWD
Method 1: Manipulate using STP Path Cost:
SCOTTSW03(config-if-range)#shut
SCOTTSW03(config-if-range)#exit
SCOTTSW03(config)#interface gi0/3

34April 24, 2020
SCOTTSW03(config-if)#spanning-tree cost 2
SCOTTSW03(config-if)#exit
SCOTTSW03(config-if-range)#no shut
SCOTTSW03(config-if-range)#end
Method 2: Alternatively, you can modify this behaviour with manipulating Port-Priority as well:
Switch(config)#int gi0/0
Switch(config-if)#spanning-tree port-priority ?
<0-224> port priority in increments of 32

35April 24, 2020
CONFIGURATION FOR TASK#2: To configure & verify Portfast
Initial Config PC1, PC2 and SCOTSW07:
PC1:
#
#
# This is a sample network config uncomment lines to configure the network
#
# Static config for eth0
auto eth0
iface eth0 inet static
address 192.168.99.1
netmask 255.255.255.0
gateway 192.168.99.100
up echo nameserver 192.168.0.1 > /etc/resolv.conf
# DHCP config for eth0
# auto eth0
# iface eth0 inet dhcp
PC2:
#
# This is a sample network config uncomment lines to configure the network
#
# Static config for eth0
auto eth0
iface eth0 inet static
address 192.168.99.2
netmask 255.255.255.0
gateway 192.168.99.100
up echo nameserver 192.168.0.1 > /etc/resolv.conf

36April 24, 2020
# DHCP config for eth0
# auto eth0
# iface eth0 inet dhcp
SCOTSW07:
interface vlan 99
ip address 192.168.99.107 255.255.255.0
no shut
exit
int gi0/0
switchport mode access
switchport access vlan 99
no shut
int gi0/3
no shut
Now ping from PC1 to PC2 over RSTP, it would take 1 second to switchport transit from “Learning”
to “Forwarding”
SCOTSW07#sh span int gi0/3
Vlan Role Sts Cost Prio.Nbr Type
------------------- ---- --- --------- -------- --------------------------------
VLAN0099 Desg LRN 4 128.4 P2p
Switch#sh span int gi0/3
------------------- ---- --- --------- -------- --------------------------------
------------------- ---- --- --------- -------- --------------------------------
------------------- ---- --- --------- -------- --------------------------------
VLAN0099 Desg FWD 4 128.4 P2p
Let us see by enabling the “Portfast” features on Egde port, SCOTSW07_Gi0/0 and Gi0/3
SCOTSW07(config)#int gi0/0
SCOTSW07(config-if)#spanning-tree portfast
SCOTSW07(config)#int gi0/3
SCOTSW07(config-if)#spanning-tree portfast

37April 24, 2020
%Warning: portfast should only be enabled on ports connected to a single
host. Connecting hubs, concentrators, switches, bridges, etc... to this
interface when portfast is enabled, can cause temporary bridging loops.
Use with CAUTION
%Portfast has been configured on GigabitEthernet0/0 but will only
have effect when the interface is in a non-trunking mode.
To test the “portfast” behaviour, shut/no shutdown SCOTSW07_Gi0/0 and observe the time it takes
to allow PING reachability between PC1 and PC2
SCOTSW07(config-if)#int gi0/0
SCOTSW07(config-if)#shut
SCOTSW07(config-if)#no shut
SCOTSW07# show spanning interface gi0/0
------------------- ---- --- --------- -------- --------------------------------
VLAN0099 Desg FWD 4 128.1 P2p Edge
*Apr 21 21:30:29.503: RSTP(99): initializing port Gi0/0
*Apr 21 21:30:29.504: RSTP(99): Gi0/0 is now designated
*Apr 21 21:30:29.686: %LINK-3-UPDOWN: Interface GigabitEthernet0/0, changed state to down
*Apr 21 21:30:32.568: %LINK-3-UPDOWN: Interface GigabitEthernet0/0, changed state to up
It was instantaneous without any delay.
Portfast is enabled between Switch and Non-BPDU end host only.
Do not enable between two BPDU switches will result in looping and layer 2 security attacks.

38April 24, 2020
TASK#2: To configure & verify BPDUGuard
BPDU Guard feature can be enabled globally at Global configuration mode or per interface
at Interface configuration mode.
When a BPDU Guard enabled port receive BPDU from the connected device, BPDU Guard
disables the port and the port state is changed to Errdisable state.
Global and Interface config has the same impact on receiving any BPDU, they would put the
switchport in “err-disabled” state.
**Initial Config PC1, PC2 and SCOTSW07 as above done for “portfast” lab
Considering the fact, you have already configured “portfast” on SCOTSW07_Gi0/0 in the previous
Task.
Now let us enable “BPDUGuard” on SCOTSW07_Gi0/0
SCOTSW07(config)#interface gigabitEthernet 0/0
SCOTSW07(config-if)#spanning-tree bpduguard enable
Remove the cable between SCOTSW07 and PC1, plug the same cable between SCOTSW07 <-> BAD-
SWITCH

39April 24, 2020
SCOTSW07(config-if)#
*Apr 21 21:42:19.264: %SPANTREE-2-BLOCK_BPDUGUARD: Received BPDU on port Gi0/0 with BPDU
Guard enabled. Disabling port.
*Apr 21 21:42:19.264: %PM-4-ERR_DISABLE: bpduguard error detected on Gi0/0, putting Gi0/0 in
err-disable state
*Apr 21 21:42:20.264: %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet0/0,
changed state to down
*Apr 21 21:42:21.265: %LINK-3-UPDOWN: Interface GigabitEthernet0/0, changed state to down
Interface is down due to bpduguard impact:
SCOTSW07#sh ip int br | i 0/0
GigabitEthernet0/0 unassigned YES unset down down
SCOTSW07#show inter gi0/0
GigabitEthernet0/0 is down, line protocol is down (err-disabled)
<output omitted>
The reason for detection and going into errdisable state is because by default “bpduguard”
detection is enabled on all switches as shown below:
SCOTSW07#show errdisable detect | i bpdu
bpduguard Enabled port

40April 24, 2020
As of now the automatic recovery is set to “disabled”
SCOTSW07#show errdisable recovery | i bpdu
bpduguard Disabled
We can set the automatic recovery for “bpduguard” for every “30” seconds
SCOTSW07(config)#errdisable recovery interval 30
SCOTSW07(config)#errdisable recovery cause bpduguard
SCOTSW07#sh errdisable recovery
ErrDisable Reason Timer Status
----------------- --------------
arp-inspection Disabled
bpduguard Enabled
The interface is back to “connected” mode:
SCOTSW07#
SCOTSW07#sh int gi0/0
GigabitEthernet0/0 is up, line protocol is up (connected)

41April 24, 2020
TASK#3: To configure & verify BPDUFilter
• BPDU Filtering at the global level will work with Portfast interfaces, and simply kick them
out of portfast if a BPDU is received.
• BPDU Filtering configured on the interface level will COMPLETELY stop send/receive
BPDU, and if you plug in two switches then you may have a loop because they don't 'see'
each other as a problem.
BPDUFILTER AT INTERFACE LEVEL:
SCOTSW07(config-if)#int e0/0
SCOTSW07(config-if)# spanning-tree portfast edge
SCOTSW07(config-if)# spanning-tree bpdufilter enable
Let’s verify the output of BPDUFilter at Interface level
BPDUs are stopped now as we configured the BPDUFilter interface level
SW01#sh spanning-tree interface gi0/0 detail
Port 1 (Ethernet0/0) of VLAN0001 is designated forwarding
Port path cost 100, Port priority 128, Port Identifier 128.1.
Designated root has priority 32769, address aabb.cc00.0300
Designated bridge has priority 32769, address aabb.cc00.0300
Designated port id is 128.1, designated path cost 0
Timers: message age 0, forward delay 0, hold 0
Number of transitions to forwarding state: 1
Link type is shared by default
Bpdu filter is enabled
BPDU: sent 3576, received 3 (do not increment)

42April 24, 2020
Now let us assume someone disconnected the PC1 and connected that cable to another BPDU
switch “BAD-SWITCH” as show in diagram below:
Also, both Switch SCOTSW07 <-> BAD-SWITCH becomes Root Bridge for Vlan 1 because BPDU are
not sent/received
SCOTSW07(config)#show spanning vlan 1
VLAN0001
Address aabb.cc00.0300
BAD-SWITCH# show spanning-tree vlan 1
VLAN0001
Address aabb.cc00.0400

43April 24, 2020
BPDUFILTER AT GLOBAL LEVEL:
SW01(config-if)# spanning-tree portfast bpdufilter default (upon receiving any BPDUs, it kicks the
switchport out of portfast mode)
SCOTSW07 (config)#spanning-tree portfast bpdufilter default
SCOTSW07# show spanning-tree int gi0/0 detail
<<output truncated >>
The port is in the portfast mode
Bpdu filter is enabled by default
BPDU: sent 9, received 0
Let’s connect the cable to BAD-SWITCH_Eth0/0 and watch the changes:
The BPDU FILTER mode is removed in Global mode once BPDU is rcvd
SCOTSW07 #show spanning-tree int gi0/0 det
<<output truncated >>
The port is in the portfast mode
BPDU: sent 12, received 18

44April 24, 2020
TASK#4: To configure & verify RootGuard
If a root-guard-enabled port receives BPDUs that are superior to those that the current root
bridge is sending, then that port is moved to a root-inconsistent state, which is effectively equal to
an STP listening state, and no data traffic is forwarded across that port.
I want SCOTSW01 to be my Root Switch always.
BEFORE ROOTGUARD:
SCOTSW01(config)#do sh span
VLAN0001
Cost 4
AFTER ROOTGUARD:
Let us make SCOTSW01 as ROOT SWITCH.
If SCOTSW01 received any superior BPDU it will put that switchport into “root-inconsistent state”.
SCOTSW01 (config)#int range gi0/0-3
SCOTSW01 (config-if-range)#spanning-tree guard root

45April 24, 2020
*Apr 22 15:46:36.056: %SPANTREE-2-ROOTGUARD_CONFIG_CHANGE: Root guard enabled on port
GigabitEthernet0/0.
GigabitEthernet0/1.
GigabitEthernet0/2.
GigabitEthernet0/3.
*Apr 22 15:46:36.408: %SPANTREE-2-ROOTGUARD_BLOCK: Root guard blocking port
GigabitEthernet0/2 on VLAN0001.
Detected Superior BPDU receiving from the neighbouring switch.
SCOTSW01#show spanning-tree inconsistentports
Name Interface Inconsistency
-------------------- ------------------------ ------------------
VLAN0001 GigabitEthernet0/2 Root Inconsistent
VLAN0001 GigabitEthernet0/3 Root Inconsistent
Number of inconsistent ports (segments) in the system : 2
SCOTSW01#show spanning-tree
<!output omitted>
Gi0/2 Desg BKN*4 128.3 P2p Peer(STP) *ROOT_Inc
Gi0/3 Desg BKN*4 128.4 P2p Peer(STP) *ROOT_Inc
Remove that Switch which is sending Superior BPDU to SCOTSW01, you can remove the switch or
shutdown that interface.
Bounce the switchport (Shut/No Shutdown) on SCOTSW01 to rectify the “Inconsistency” mode:
SCOTSW01 (config)#int range gi0/0-3
SCOTSW01 (config-if-range)# shutdown
SCOTSW01 (config-if-range)# no shutdown
*April 7 16:49:36.362: %SPANTREE-2-ROOTGUARD_UNBLOCK: Root guard unblocking port Gi0/2 on
VLAN0001.
SCOTSW01# show spanning inconsistentports
Name Interface Inconsistency
-------------------- ------------------------ -----------------
Number of inconsistent ports (segments) in the system : 0

46April 24, 2020
LAB #6 CONFIGURE – MSTP
Objectives: Observe on SCOTSW01, SCOTSW02, SCOTSW03, SCOTSW04 as
following:
1. Configure MSTP Region 1 on SCOTSW01, SCOTSW02 and verify its behaviour
2. Configure MSTP Region 1 on SCOTSW01, SCOTSW02 and MSTP Region 2 on SCOTSW04 and
verify its behaviour
3. Configure MSTP Region 1 on SCOTSW01, SCOTSW02 and RSTP on SCOTSW03 and verify its
behaviour
4. To manipulate “instance priority” between SCOTSW01 <-> SCOTSW02
5. To manipulate “port cost” between SCOTSW02_Gi0/2-3 <-> SCOTSW04_Gi0/2-3
6. To manipulate “port priority” between SCOTSW02_Gi0/2-3 <-> SCOTSW04_Gi0/2-3
7. To manipulate “hello timer” in MST switch SCOTSW02
8. To manipulate “forward timer” in MST switch SCOTSW02
9. To manipulate “max age timer” in MST switch SCOTSW02

47April 24, 2020
CONFIGURATION TASK#1,2 & 3: To configure & verify MST Region 1, Region 2 and
Interoperability
SCOTSW01 (config)#
spanning-tree mode mst
spanning-tree mst configuration
name region1
revision 1
instance 1 vlan 99,100
spanning-tree mst 1 priority 0
SCOTSW02 (config)#
name region1
revision 1
SCOTSW03 (config)#
spanning-tree mode rapid-pvst
SCOTSW04 (config)#
name region2
revision 1
VERIFICATION TASK#1: To configure & verify MST Region 1
SCOTSW01 switching running MST ROOT for VLAN 99,100
SCOTSW01#sh spanning-tree mst 0
##### MST0 vlans mapped: 1-98,101-109,111-119,121-4094
Bridge address 0c67.916e.7e00 priority 32768 (32768 sysid 0)
Root address 0c67.9159.b100 priority 32768 (32768 sysid 0)
port Gi0/0 path cost 0
Regional Root address 0c67.9159.b100 priority 32768 (32768 sysid 0)
internal cost 20000 rem hops 19
Operational hello time 2 , forward delay 15, max age 20, txholdcount 6
Configured hello time 2 , forward delay 15, max age 20, max hops 20

48April 24, 2020
---------------- ---- --- --------- -------- --------------------------------
Gi0/0 Root FWD 20000 128.1 P2p
Gi0/1 Altn BLK 20000 128.2 P2p
Gi0/2 Desg FWD 20000 128.3 P2p Bound(PVST)
##### MST1 vlans mapped: 99-100
Root this switch for MST1
---------------- ---- --- --------- -------- --------------------------------
Gi0/0 Desg FWD 20000 128.1 P2p
Gi0/1 Desg FWD 20000 128.2 P2p
##### MST2 vlans mapped: 110,120
port Gi0/0 cost 20000 rem hops 19
---------------- ---- --- --------- -------- --------------------------------
Gi0/0 Root FWD 20000 128.1 P2p
Gi0/1 Altn BLK 20000 128.2 P2p
SCOTSW02 running MST ROOT for VLAN 110, 120
SCOTSW02 elected AS IST MASTER = CIST due to superior BPDU [Bridge ID = PRI+MAC ADD]
SCOTSW02#show spanning-tree mst 0
##### MST0 vlans mapped: 1-98,101-109,111-119,121-4094
Bridge address 0c67.9159.b100 priority 32768 (32768 sysid 0)
Root this switch for the CIST
---------------- ---- --- --------- -------- --------------------------------
Gi0/0 Desg FWD 20000 128.1 P2p
Gi0/1 Desg FWD 20000 128.2 P2p
Gi0/2 Desg FWD 20000 128.3 P2p
Gi0/3 Desg FWD 20000 128.4 P2p

49April 24, 2020
Root address 0c67.916e.7e00 priority 1 (0 sysid 1)
port Gi0/0 cost 20000 rem hops 19
---------------- ---- --- --------- -------- --------------------------------
Gi0/0 Root FWD 20000 128.1 P2p
Gi0/1 Altn BLK 20000 128.2 P2p
Gi0/2 Desg FWD 20000 128.3 P2p
Gi0/3 Desg FWD 20000 128.4 P2p
---------------- ---- --- --------- -------- --------------------------------
Gi0/0 Desg FWD 20000 128.1 P2p
Gi0/1 Desg FWD 20000 128.2 P2p
Gi0/2 Desg FWD 20000 128.3 P2p
Gi0/3 Desg FWD 20000 128.4 P2p
SCOTSW03 running on RSTP (non-mst switch)
We can see RSTP running per VLAN basis (multiple instance of RSTP running)
VLAN0099
Cost 4
Aging Time 300 sec
------------------- ---- --- --------- -------- --------------------------------
Gi0/2 Root FWD 4 128.3 P2p Peer(STP)
Gi0/3 Altn BLK 4 128.4 P2p Peer(STP)
VLAN0100

50April 24, 2020
Cost 4
Aging Time 300 sec
------------------- ---- --- --------- -------- --------------------------------
VLAN0110
Cost 4
Aging Time 300 sec
------------------- ---- --- --------- -------- --------------------------------
VLAN0120
Cost 4
Aging Time 300 sec

51April 24, 2020
------------------- ---- --- --------- -------- --------------------------------
SCOTSW04 running MST on REGION2
Since there are no other Switch in MST Region 2, SCOTSW04 will declare itself as Root bridge for
both Instance 1 and 2
##### MST0 vlans mapped: 1-98,101-109,111-119,121-4094
Bridge address 0c67.91d3.c500 priority 32768 (32768 sysid 0)
port Gi0/2 path cost 20000
Regional Root this switch
---------------- ---- --- --------- -------- --------------------------------
Gi0/0 Desg BKN*20000 128.1 P2p Bound(PVST) *PVST_Inc
Gi0/2 Root FWD 20000 128.3 P2p Bound(RSTP)
Gi0/3 Altn BLK 20000 128.4 P2p Bound(RSTP)
Gi1/0 Desg FWD 20000 128.5 P2p
---------------- ---- --- --------- -------- --------------------------------
Gi0/2 Mstr FWD 20000 128.3 P2p Bound(RSTP)
---------------- ---- --- --------- -------- --------------------------------

52April 24, 2020
Gi0/2 Mstr FWD 20000 128.3 P2p Bound(RSTP)
CONFIGURATION TASK#4: To manipulate “instance priority” in SCOTSW01, SCOTSW02
Configuring the MST1 as Root in SCOTSW01 and MST2 as Root in SCOTSW02:
SCOTSW01(config)#
**********or***************
SCOTSW01(config)#
spanning-tree mst 1 root primary
spanning-tree mst 2 root secondary
SCOTSW02(config)
**********or***************
SCOTSW02(config)
spanning-tree mst 1 root secondary
spanning-tree mst 2 root primary
VERIFICATION TASK#4: To manipulate “instance priority” in SCOTSW01, SCOTSW02
---------------- ---- --- --------- -------- --------------------------------
Gi0/0 Desg FWD 20000 128.1 P2p
Gi0/1 Desg FWD 20000 128.2 P2p
---------------- ---- --- --------- -------- --------------------------------
Gi0/0 Desg FWD 20000 128.1 P2p
Gi0/1 Desg FWD 20000 128.2 P2p
Gi0/2 Desg FWD 20000 128.3 P2p
Gi0/3 Desg FWD 20000 128.4 P2p

53April 24, 2020
CONFIGURATION TASK#5: To manipulate “port cost” between SCOTSW02_Gi0/2-3 <->
SCOTSW04_Gi0/2-3
Before Change:
SCOTSW02#show spanning-tree mst interface gi0/2
<!output omitted>
1 Desg FWD 20000 128.3 99-100
2 Desg FWD 20000 128.3 110,120
SCOTSW02#show spanning-tree mst interface gi0/3
<!output omitted>
1 Desg FWD 20000 128.4 99-100
2 Desg FWD 20000 128.4 110,120
SCOTSW04#show spanning mst interface gi0/2
<!output omitted>
1 Mstr FWD 20000 128.3 99-100
2 Mstr FWD 20000 128.3 110,120
SCOTSW04#show spanning mst interface gi0/3
<!output omitted>
1 Altn BLK 20000 128.4 99-100
2 Altn BLK 20000 128.4 110,120
Now change this behaviour by manipulating Port-cost of SCOTSW04_Gi0/3
CONFIGURATIONS:
SCOTSW04(config)# interface gi0/3
SCOTSW04(config-if)#spanning-tree mst 0 cost 2000
SCOTSW04(config-if)#shutdown
VERIFICATION TASK#5
SCOTSW04#show spanning int gi0/3
Mst Instance Role Sts Cost Prio.Nbr Type
------------------- ---- --- --------- -------- --------------------------------
MST0 Root FWD 2000 128.4 P2p Bound(RSTP)
MST1 Mstr FWD 20000 128.4 P2p Bound(RSTP)
------------------- ---- --- --------- -------- --------------------------------
MST0 Altn BLK 20000 128.3 P2p Bound(RSTP)

54April 24, 2020
CONFIGURATION TASK#6: To manipulate “port priority” between SCOTSW02_Gi0/2-3 <->
SCOTSW04_Gi0/2-3
Configuring Port Priority:
SCOTSW04(config-if)# spanning-tree mst 1 port-priority 32
SCOTSW04(config-if)#shutdown
VERIFICATION TASK#6
------------------- ---- --- --------- -------- --------------------------------
MST0 Root FWD 20000 64.4 P2p Bound(RSTP)
------------------- ---- --- --------- -------- --------------------------------
CONFIGURATION TASK#7: To manipulate “hello timer” in MST switch SCOTSW02
Manipulate the Hello Time
SCOTSW02(config)#spanning-tree mst hello-time 5 ###default = 2 seconds
VERIFICATION TASK#7:
SCOTSW02# show spanning-tree mst
##### MST0 vlans mapped: 1-98,101-109,111-119,121-4094
CONFIGURATION TASK#8: To manipulate “forward timer” in MST switch SCOTSW02
Manipulate the Forwarding-Delay Time
SCOTSW02(config)# spanning-tree mst forward-time 10 ###default = 15 seconds

55April 24, 2020
The forward delay is the number of seconds a port waits before changing from its spanning-tree
learning and listening states to the forwarding state.
SCOTSW02# show spanning-tree mst
##### MST0 vlans mapped: 1-98,101-109,111-119,121-4094
CONFIGURATION TASK#9: To manipulate “max age timer” in MST switch SCOTSW02
Manipulating the Maximum-Aging Time
SCOTSW02(config)#spanning-tree mst max-age 30 ###default = 20 seconds
The maximum-aging time is the number of seconds a switch waits without receiving spanning-tree
configuration messages before attempting a reconfiguration.
SCOTSW02#show spanning-tree mst
##### MST0 vlans mapped: 1-98,101-109,111-119,121-4094
IMPORTANT FACT!!!
To restart the protocol migration process (force the renegotiation with neighboring switches) on
the switch, use the below command under privileged EXEC command.:
clear spanning-tree detected-protocols

56April 24, 2020
LAB #7 CONFIGURE – DTP (DYNAMIC TRUNKING PROTOCOL)
following:
1. Configure “DTP desirable-desirable” between SCOTSW01 <-> SCOTSW02
2. Configure “DTP auto-desriable” between SCOTSW01 <-> SCOTSW03
3. Configure “DTP auto-auto” between SCOTSW03 <-> SCOTSW04
4. Configure “DTP” between SCOTSW02_Trunk_Dot1Q <-> SCOTSW04_Auto
5. Configure DTP between SCOTSW02_Trunk Dot1Q <-> SCOTSW04_desirable

57April 24, 2020
CONFIGURATION TASK#1: Configure “DTP desirable-desirable” between SCOTSW01 <-> SCOTSW02
SCOTSW01(config)#default interface range gi0/0-1
SCOTSW01(config)#interface range gigabitEthernet 0/0-1
SCOTSW01(config-if-range)#switchport mode dynamic desirable
SCOTSW02(config)#interface range gigabitEthernet 0/0-1
Gi0/0 desirable n-isl trunking 1
<!—output omitted>
SCOTSW01#sh interfaces gi0/0 swi
Name: Gi0/0
Switchport: Enabled
Administrative Mode: dynamic desirable
Operational Mode: trunk
Administrative Trunking Encapsulation: negotiate
Operational Trunking Encapsulation: isl
Negotiation of Trunking: On
Access Mode VLAN: 1 (default)
Trunking Native Mode VLAN: 1 (default)
<!output omitted>
SCOTSW02#show interface trunk
SCOTSW02#show interfaces gi0/0 switchport
Name: Gi0/0
Switchport: Enabled
Administrative Mode: dynamic desirable
Operational Mode: trunk
Operational Trunking Encapsulation: isl
Administrative Native VLAN tagging: enabled
<!output omitted>

58April 24, 2020
DTP is cisco proprietary
DTP negotiation by default negotiate over “n-isl”
As we know ISL header carries “26 bytes” which is a drawback of DTP negotiations. The payload
(data) gets shrinked (or reduced) to accumulate extra ISL header size.
CONFIGURATION TASK#2: Configure “DTP auto-desirable” between SCOTSW01 <-> SCOTSW03
SCOTSW01(config)#interface range gi0/2-3
SCOTSW01(config-if-range)#switchport mode dynamic auto
Gi0/2 auto n-isl trunking 1
CONFIGURATION TASK#3: Configure “DTP auto-auto” between SCOTSW03 <-> SCOTSW04
SCOTSW03(config-if-range)#sw mo dynamic auto
SCOTSW04(config-if-range)#sw mo dynamic auto
SCOTSW03#show inter gi0/1 trunk
Gi0/1 auto negotiate not-trunking 1

59April 24, 2020
Gi0/1 1
Port Vlans allowed and active in management domain
Gi0/1 1
Port Vlans in spanning tree forwarding state and not pruned
Gi0/1 1
SCOTSW03#show inter gi0/1 sw
SCOTSW03#show inter gi0/1 switchport
Name: Gi0/1
Switchport: Enabled
Administrative Mode: dynamic auto
Operational Mode: static access
Operational Trunking Encapsulation: native
Administrative Native VLAN tagging: enabled
<!output omitted>
Dynamic AUTO on both sides will not bring up “n-Trunking”as shown here SCOTSW03_gi0/0-1 <->
SCOTSW04_gi0/0-1.
It is recommended statically make it “Trunking” and do not keep DTP auto negotiations.
Some IOS software comes by default with “Auto” enabled on switchports.
CONFIGURATION TASK#4: Configure DTP between SCOTSW02_Trunk Dot1Q <-> SCOTSW04_auto
SCOTSW02(config-if-range)#sw trunk encapsulation dot1q
SCOTSW02(config-if-range)#sw mode trunk
SCOTSW04(config)#default inter range gi0/2-3
SCOTSW04(config-if-range)#sw mode dynamic auto
SCOTSW02#sh inter trunk

60April 24, 2020
SCOTSW04_desirable
SCOTSW02(config-if-range)#sw trunk encapsulation dot1q
SCOTSW02(config-if-range)#sw mo trunk
SCOTSW04(config)#default inter range gi0/2-3
SCOTSW04(config-if-range)#sw mode dynamic desirable

61April 24, 2020
LAB #8 CONFIGURE – ETHERCHANNEL
following:
1. Configure “PAgP” between SCOTSW01_gi0/2-3 <-> SCOTSW03_gi0/2-3
2. Configure “LACP” between SCOTSW01_gi0/0-1 <-> SCOTSW02_gi0/0-1
3. Configure “ON” between SCOTSW02 <-> SCOTSW04
4. Configure “LACP Fast”
5. Configure Minimum Number of Port-Channel Member Interfaces
6. Configure Maximum Number of Port-Channel Member Interfaces
7. Configure LACP System Priority
8. Configure LACP Interface Priority
9. Configure EtherChannel Misconfiguration Guard

62April 24, 2020
CONFIGURATION TASK#1: Configure “PAgP” between SCOTSW01 <-> SCOTSW03
SCOTSW01 PAgP Configuration
SCOTSW01 (config)#no interface port-channel 12
SCOTSW01 (config)#interface range gi0/2-3
SCOTSW01 (config-if-range)#switchport trunk encapsulation dot1q
SCOTSW01 (config-if-range)#switchport mode trunk
SCOTSW01 (config-if-range)#switchport trunk allowed vlan 99,100,110,120,666,999
SCOTSW01 (config-if-range)#channel-protocol pagp (optional)
SCOTSW01 (config-if-range)#channel-group 12 mode auto
SCOTSW03 PAgP Configuration
SCOTSW03(config)#no interface port-channel 12
SCOTSW03(config-if-range)#switchport trunk encapsulation dot1q
SCOTSW03(config-if-range)#switchport mode trunk
SCOTSW03(config-if-range)#switchport trunk allowed vlan 99,100,110,120,666,999
SCOTSW03(config-if-range)#channel-protocol pagp (optional)
SCOTSW03(config-if-range)#channel-group 12 mode desirable
VERIFICATION TASK#1
• show etherchannel summary
• show etherchannel detail
• show etherchannel port-channel
• show pagp counter
• show pagp neighbor
SCOTSW03# show etherchannel summary
Flags: D - down P - bundled in port-channel
I - stand-alone s - suspended
H - Hot-standby (LACP only)
R - Layer3 S - Layer2
U - in use N - not in use, no aggregation
f - failed to allocate aggregator
M - not in use, minimum links not met
m - not in use, port not aggregated due to minimum links not met
u - unsuitable for bundling
w - waiting to be aggregated
d - default port
A - formed by Auto LAG

63April 24, 2020
Number of channel-groups in use: 1
Number of aggregators: 1
Group Port-channel Protocol Ports
------+-------------+-----------+-----------------------------------------------
12 Po12(SU) PAgP Gi0/2(P) Gi0/3(P)
SCOTSW03#show etherchannel detail
Channel-group listing:
----------------------
! This is the header that indicates all the ports that are for the first
! EtherChannel interface. Every member link interface will be listed
Group: 12
----------
Group state = L2
Ports: 2 Maxports = 4
Port-channels: 1 Max Port-channels = 1
Protocol: PAgP
Minimum Links: 0
! This is the first member interface for interface Po12. This interface
! is configured for PAgP active
Ports in the group:
-------------------
Port: Gi0/2
------------
Port state = Up Mstr In-Bndl
Channel group = 12 Mode = Automatic-Sl Gcchange = 0
Port-channel = Po12 GC = 0x000C0001 Pseudo port-channel = Po12
Port index = 0 Load = 0x00 Protocol = PAgP
Flags: S - Device is sending Slow hello. C - Device is in Consistent state.
A - Device is in Auto mode. P - Device learns on physical port.
d - PAgP is down.
Timers: H - Hello timer is running. Q - Quit timer is running.
S - Switching timer is running. I - Interface timer is running.
Local information:
Hello Partner PAgP Learning Group
Port Flags State Timers Interval Count Priority Method Ifindex
Gi0/2 SAC U6/S7 HQ 30s 1 128 Any 19
! This interface's partner is configured with PAgP Slow packets, has a system-id
! of 0c67.916e.8000 , a port priority of 128 , and is desirable in the bundle
! for 0d:01h:27m:31s.
Partner's information:
Partner Partner Partner Partner Group
Port Name Device ID Port Age Flags Cap.
Gi0/2 SCOTSW01.networkjour 0c67.916e.8000 Gi0/2 26s SC C0001

64April 24, 2020
Age of the port in the current state: 0d:01h:27m:31s
Port: Gi0/3
------------
Channel group = 12 Mode = Automatic-Sl Gcchange = 0
Port-channel = Po12 GC = 0x000C0001 Pseudo port-channel = Po12
Port index = 0 Load = 0x00 Protocol = PAgP
d - PAgP is down.
Timers: H - Hello timer is running. Q - Quit timer is running.
S - Switching timer is running. I - Interface timer is running.
Local information:
Hello Partner PAgP Learning Group
Port Flags State Timers Interval Count Priority Method Ifindex
Gi0/3 SAC U6/S7 HQ 30s 1 128 Any 19
Port-channels in the group:
---------------------------
Port-channel: Po12
------------
Age of the Port-channel = 0d:01h:27m:43s
Logical slot/port = 16/0 Number of ports = 2
GC = 0x000C0001 HotStandBy port = null
Port state = Port-channel Ag-Inuse
Protocol = PAgP
Port security = Disabled
Ports in the Port-channel:
Index Load Port EC state No of bits
------+------+------+------------------+-----------
0 00 Gi0/2 Automatic-Sl 0
Time since last port bundled: 0d:01h:27m:31s Gi0/3

65April 24, 2020
SCOTSW03#show etherchannel port-channel
----------------------
Group: 12
----------
---------------------------
Port-channel: Po12
------------
GC = 0x000C0001 HotStandBy port = null
Protocol = PAgP
------+------+------+------------------+-----------
SCOTSW03# show pagp counters
Information Flush PAgP
Port Sent Recv Sent Recv Err Pkts
---------------------------------------------------
Channel group: 12
Gi0/2 198 200 0 0 0
Gi0/3 198 201 0 0 0
SCOTSW03#show pagp neighbor
Channel group 12 neighbors
SCOTSW03#

66April 24, 2020
When viewing the output of the show etherchannel summary command, the first thing that
should be checked is the EtherChannel status, which is listed in the Port-channel column. The
status should be SU
CONFIGURATION TASK#2: “LACP” between SCOTSW01 <-> SCOTSW02
SCOTSW01 LACP Configuration
SCOTSW01(config-if-range)#channel-protocol lacp (optional)
SCOTSW01(config-if-range)#channel-group 11 mode active
SCOTSW02 LACP Configuration
SCOTSW02(config-if-range)#channel-protocol lacp (optional)
SCOTSW02(config-if-range)#channel-group 11 mode passive
VERIFICATION TASK#2
• show etherchannel summary
• show etherchannel detail
• show etherchannel port-channel
• show spanning-tree vlan 1
• show lacp counters
• show lacp neighbor
SCOTSW02#show etherchannel summary
d - default port

67April 24, 2020
------+-------------+-----------+-----------------------------------------------
11 Po11(SU) LACP Gi0/0(P) Gi0/1(P)
----------------------
Group: 11
----------
Group state = L2
Protocol: LACP
Minimum Links: 0
Ports in the group:
-------------------
Port: Gi0/0
------------
Port state = Up Mstr Assoc In-Bndl
Channel group = 11 Mode = Passive Gcchange = -
Port-channel = Po11 GC = - Pseudo port-channel = Po11
Port index = 0 Load = 0x00 Protocol = LACP
Flags: S - Device is sending Slow LACPDUs F - Device is sending fast LACPDUs.
A - Device is in active mode. P - Device is in passive mode.
Local information:
LACP port Admin Oper Port Port
Port Flags State Priority Key Key Number State
Gi0/0 SP bndl 32768 0xB 0xB 0x1 0x3C
Port Flags Priority Dev ID Age key Key Number State
Gi0/0 SA 32768 0c67.916e.8000 13s 0x0 0xB 0x1 0x3D
Port: Gi0/1
------------

68April 24, 2020
Port state = Up Mstr Assoc In-Bndl
Channel group = 11 Mode = Passive Gcchange = -
Port index = 0 Load = 0x00 Protocol = LACP
Flags: S - Device is sending Slow LACPDUs F - Device is sending fast LACPDUs.
A - Device is in active mode. P - Device is in passive mode.
Local information:
Gi0/1 SP bndl 32768 0xB 0xB 0x2 0x3C
Gi0/1 SA 32768 0c67.916e.8000 5s 0x0 0xB 0x2 0x3D
---------------------------
Port-channel: Po11 (Primary Aggregator)
------------
HotStandBy port = null
Protocol = LACP
------+------+------+------------------+-----------
0 00 Gi0/0 Passive 0
0 00 Gi0/1 Passive 0
Time since last port Un-bundled: 0d:01h:15m:35s Gi0/1
SCOTSW02#sh spanning-tree vlan 99
VLAN0099

69April 24, 2020
Cost 6
Port 65 (Port-channel11)
Aging Time 300 sec
------------------- ---- --- --------- -------- --------------------------------
Po11 Root FWD 3 128.65 P2p
SCOTSW02#show lacp counters
LACPDUs Marker Marker Response LACPDUs
Port Sent Recv Sent Recv Sent Recv Pkts Err
---------------------------------------------------------------------
Channel group: 11
Gi0/0 246 245 0 0 0 0 0
Gi0/1 256 256 0 0 0 0 0
SCOTSW02#show lacp neighbor
Flags: S - Device is requesting Slow LACPDUs
F - Device is requesting Fast LACPDUs
A - Device is in Active mode P - Device is in Passive mode
Channel group 11 neighbors
Gi0/0 SA 32768 0c67.916e.8000 25s 0x0 0xB 0x1 0x3D
Gi0/1 SA 32768 0c67.916e.8000 13s 0x0 0xB 0x2 0x3D
SCOTSW02#
The LACP counters can be cleared with the command clear lacp counters.

70April 24, 2020
CONFIGURATION TASK#3: “ON” between SCOTSW02 <-> SCOTSW04
SCOTSW02 Etherchannel “On” Configuration
SCOTSW02(config)#interface range gi 0/2-3
SCOTSW02(config-if-range)#channel-group 22 mode on
SCOTSW04 Etherchannel “On” Configuration
SCOTSW04(config-if-range)#channel-group 22 mode on
VERIFICATION TASK#3
show etherchannel summary
show etherchannel detail
show etherchannel port-channel
show spanning-tree vlan 99
SCOTSW04#show etherchannel summary

71April 24, 2020
d - default port
------+-------------+-----------+-----------------------------------------------
22 Po22(SU) - Gi0/2(P) Gi0/3(P)
----------------------
Group: 22
----------
Group state = L2
Protocol: -
Minimum Links: 0
Ports in the group:
-------------------
Port: Gi0/2
------------
Channel group = 22 Mode = On Gcchange = -
Port index = 0 Load = 0x00 Protocol = -
Port: Gi0/3
------------
Channel group = 22 Mode = On Gcchange = -

72April 24, 2020
Port index = 0 Load = 0x00 Protocol = -
---------------------------
Port-channel: Po22
------------
GC = 0x00000000 HotStandBy port = null
Protocol = -
------+------+------+------------------+-----------
0 00 Gi0/2 On 0
0 00 Gi0/3 On 0
Time since last port Un-bundled: 0d:01h:50m:25s Gi0/3
SCOTSW04#show spanning-tree vlan 99
VLAN0099
Cost 4
Address 0c67.91d3.c500
Aging Time 300 sec
------------------- ---- --- --------- -------- --------------------------------
Po22 Desg FWD 3 128.65 P2p

73April 24, 2020
Advanced LACP Configuration Options
CONFIGURATION TASK#4: Configure “LACP Fast”
LACP provides some additional tuning that is not available with PAgP.
LACP Fast:
The original LACP standards sent out LACP packets every 30 seconds. A link is deemed unusable if an
LACP packet is not received after three intervals, which results in a potential 90 seconds of packet
loss for a link before that member interface is removed from a port channel.
An amendment to the standards was made so that LACP packets are advertised every 1 second.
This is known as LACP fast because a link can be identified and removed in 3 seconds compared to
the 90 seconds specified in the initial LACP standard.
LACP fast is enabled on the member interfaces with the interface configuration command lacp rate
fast.
All the interfaces on both switches need to be configured the same—either using LACP fast or
LACP slow—for the EtherChannel to successfully come up.
SCOTSW01(config)# interface range gi0/1-2
SCOTSW01(config-if-range)# lacp rate fast
Remember: Best practice is to configure “lacp fast” on every Switch interface.
SCOTSW01# show lacp internal
Flags: S - Device is requesting Slow LACPDUs
F - Device is requesting Fast LACPDUs
A - Device is in Active mode P - Device is in Passive mode
Channel group 1
Gi1/0/1 FA bndl 32768 0x1 0x1 0x102 0x3F
Gi1/0/2 FA bndl 32768 0x1 0x1 0x103 0xF

74April 24, 2020
CONFIGURATION TASK#5: Minimum Number of Port-Channel Member Interfaces
An EtherChannel interface becomes active and up when only one member interface successfully
forms an adjacency with a remote device.
In some design scenarios using LACP, a minimum number of adjacencies is required before a port-
channel interface becomes active. This option can be configured with the port-channel interface
command port-channel min-links min-links.
SCOTSW01(config)# interface port-channel 1
SCOTSW01(config-if)# port-channel min-links 2
Test the behaviour by shutting one of the physical member manually “shutdown”
SCOTSW01(config-if)# interface gi1/0/1
SCOTSW01(config-if)# shutdown
10:44:46.516: %ETC-5-MINLINKS_NOTMET: Port-channel Po1 is down bundled ports (1)
doesn't meet min-links
10:44:47.506: %LINEPROTO-5-UPDOWN: Line protocol on Interface Gigabit
Ethernet1/0/2, changed state to down
10:44:47.508: %LINEPROTO-5-UPDOWN: Line protocol on Interface Port-channel1,
10:44:48.499: %LINK-5-CHANGED: Interface GigabitEthernet1/0/1, changed state to
administratively down
10:44:48.515: %LINK-3-UPDOWN: Interface Port-channel1, changed state to down
! Output Ommitted for Brevity
U - in use f - failed to allocate aggregator
------+-------------+-----------+-----------------------------------------------
1 Po1(SM) LACP Gi1/0/1(D) Gi1/0/2(P)
By default having only 1 active member interface will bring up “Etherchannel”.
Best practice is enable “min-links” and set to 2 so that unless we have 2 active physical member
the “Etherchannel” wouldn’t come up.

75April 24, 2020
CONFIGURATION TASK#6: Maximum Number of Port-Channel Member Interfaces
An EtherChannel can be configured to have a specific maximum number of member interfaces in a
port channel.
This may be done to ensure that the active member interface count proceeds with powers of two
(for example, 2, 4, 8) to accommodate load-balancing hashes.
The maximum number of member interfaces in a port channel can be configured with the port-
channel interface command lacp max-bundle max-links.
SCOTSW01(config)# interface port-channel1
SCOTSW01(config-if)# lacp max-bundle 1
Ethernet1/0/1, changed state to up
changed state to up
! Output omitted for brevity
U - in use f - failed to allocate aggregator
d - default port
------+-------------+-----------+-----------------------------------------------
1 Po1(SU) LACP Gi1/0/1(P) Gi1/0/2(H)
The maximum number of port-channel member interfaces needs to be configured only on the
master switch for that port channel; however, configuring it on both switches is recommended to
accelerate troubleshooting and assist operational staff.

76April 24, 2020
The port-channel master switch controls which member interfaces (and associated links) are active
by examining the LACP port priority. A lower port priority is preferred. If the port priority is the
same, then the lower interface number is preferred.
CONFIGURATION TASK#7: LACP System Priority
This identifies which switch is the master switch for a port channel.
The master switch on a port channel is responsible for choosing which member interfaces are
active in a port channel when there are more member interfaces than the maximum number of
member interfaces associated with a port-channel interface.
The switch with the lower system priority is preferred.
The LACP system priority can be changed with the command lacp system-priority priority.
PRE_CHECKS:
SCOTSW01# show lacp sys-id
32768, 0062.ec9d.c500
CONFIG:
SCOTSW01# configure terminal
SW1(config)# lacp system-priority 1
POST_CHECKS:
SCOTSW01# show lacp sys-id
1, 0062.ec9d.c50
CONFIGURATION TASK#8: LACP Interface Priority
LACP interface priority enables the master switch to choose which member interfaces are active in
a port channel when there are more member interfaces than the maximum number of member
interfaces for a port channel.
A port with a lower port priority is preferred.
The interface configuration command lacp port-priority priority sets the interface priority.
SCOTSW01 is the master switch for port channel 11, the Gi0/1 interface becomes active, and port
Gi0/1 becomes Hot-standby.
PRE_CHECKS:
SCOTSW01# show etherchannel summary | b Group

77April 24, 2020
------+-------------+-----------+-----------------------------------------------
11 Po1(SU) LACP Gi0/0(P) Gi0/1(H)
CONFIGS:
SCOTSW01(config-if)# lacp port-priority 1
POST_CHECKS:
SCOTSW01# show etherchannel summary | b Group
------+-------------+-----------+-----------------------------------------------
11 Po1(SU) LACP Gi0/0(H) Gi0/1(P)
CONFIGURATION TASK#9: EtherChannel Misconfiguration Guard
• EtherChannel Guard is a way of finding out error in the etherchannel port channel.
• Etherchannel guard finding if one end of the EtherChannel is not configured properly.
• This could be that there are some parameters not matching up such as duplex a speed.
SCOTSW01(config)#spanning-tree etherchannel guard misconfig
SCOTSW02(config)#spanning-tree etherchannel guard misconfig
SCOTSW01#show spanning-tree summary
SCOTSW02#show spanning-tree summary
SCOTSW01# show interfaces status err-disabled
SCOTSW01=2# show interfaces status err-disabled

78April 24, 2020
LAB #9 CONFIGURE – HSRPv1
Objectives: Consider MOSCOWR19, MOSCOWR20, MOSCOWSW01, MOSCOWSW02, PC10, PC19,
PC11, PC12 as following:
1. Configure “Initial config” on MOSCOWR19, MOSCOWR20, MOSCOWSW01, MOSCOWSW02,
PC10, PC19, PC11, PC12
2. Configure “HSRPv1”, Preempt for “Vlan 1 and Vlan 40”, observe the behaviour (do not
configure the priority as of now)
3. From step#2, configure Priority110 on MOSCOWR20 and observe the behaviour
4. Try loadsharing, by making Vlan 1 “ACTIVE” on MOSCOWR19 and Vlan 40 “ACTIVE” on
MOSCOWR20, verify the patch adopted by ping/traceroute from PC10 (vlan1) and
PC9(vlan40) towards 8.8.8.8
5. Configure Tracking Object and verify the WAN link switchport failures.

79April 24, 2020
CONFIGURATION TASK#1: Configure “Initial config” on MOSCOWR19, MOSCOWR20,
MOSCOWSW01, MOSCOWSW02, PC10, PC19, PC11, PC12
MOSCOWR19
interface e0/1
no shutdown
interface e0/1.1
encap dot 1
ip address 172.16.10.1 255.255.255.0
interface e0/1.40
encap dot 40
ip address 172.16.40.1 255.255.255.0
interface Ethernet0/2
ip address dhcp
end
MOSCOWR20
interface e0/1
no shut
interface e0/1.1
encap dot 1
ip address 172.16.10.2 255.255.255.0
interface e0/1.40
encap dot 40
ip address 172.16.40.2 255.255.255.0
ip address dhcp
end
MOSCOWSW01
interface gi0/3
no shutdown
interface gi0/2
no shutdown
switchport tr enc dot1
switchport trunk allowed vlan 1,40
MOSCOWSW02
interface gi0/3
no shutdown
interface gi0/2
no shutdown
switchport tr enc dot1

80April 24, 2020
switchport trunk allowed vlan 1,40
PC10
PC9

81April 24, 2020
PC11
PC12
By default, all PC’s are pointing to their respective Gateway Ips
Once we have HSRP (standby) successfully configured, we shall change the gateway to HSRP
Virtual IP (VIP) for redundancy purpose.
VERIFICATIONS TASK#1: Configure “Initial config” on MOSCOWR19, MOSCOWR20,
MOSCOWSW01, MOSCOWSW02
MOSCOWR19#show ip int br | exclude unass

82April 24, 2020
Interface IP-Address OK? Method Status Protocol
Ethernet0/1.1 172.16.10.1 YES NVRAM up up
Ethernet0/2 192.168.32.228 YES DHCP up up
MOSCOWR19#ping 8.8.8.8
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 8.8.8.8, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 47/72/91 ms
MOSCOWR19#
MOSCOWR20#show ip int brief | ex unass
Interface IP-Address OK? Method Status Protocol
Ethernet0/2 192.168.32.229 YES DHCP up up
MOSCOWR20#ping 8.8.8.8
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 8.8.8.8, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 44/61/85 ms
MOSCOWR20#
MOSCOWSW01#show interfaces trunk
Gi0/0 1,40
Gi0/1 1,40
Gi0/0 1,40
Gi0/1 1,40
Gi0/0 1,40
Gi0/1 1,40
MOSCOWSW01#show run int gi0/2
media-type rj45
negotiation auto
end
MOSCOWSW01#show run int gi0/3
media-type rj45
negotiation auto

83April 24, 2020
end
MOSCOWSW02#show interfaces trunk
Gi0/0 1,40
Gi0/1 1,40
Gi0/0 1,40
Gi0/1 1,40
Gi0/0 1,40
Gi0/1 1,40
Ping initiated to internet from PC10
PC10 console is now available... Press RETURN to get started.
/ # ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8): 56 data bytes
64 bytes from 8.8.8.8: seq=0 ttl=127 time=150.310 ms
64 bytes from 8.8.8.8: seq=1 ttl=127 time=170.947 ms
^C
--- 8.8.8.8 ping statistics ---
2 packets transmitted, 2 packets received, 0% packet loss
round-trip min/avg/max = 150.310/160.628/170.947 ms
/ # traceroute 8.8.8.8
traceroute to 8.8.8.8 (8.8.8.8), 30 hops max, 46 byte packets
1 172.16.10.1 (172.16.10.1) 4.968 ms 3.694 ms 4.079 ms →packet going via MOSCOWR19
2 192.168.32.2 (192.168.32.2) 5.946 ms 5.493 ms 6.467 ms

84April 24, 2020
CONFIGURATION TASK #2: Configure “HSRPv1” for “Vlan 1”, observe the behaviour.
Configure HSRPv1
MOSCOWR19(router)
interface e0/1.1
standby 1 ip 172.16.10.254
standby 1 preempt
interface e0/1.40
standby 40 ip 172.16.40.254
MOSCOWR20(router)
interface e0/1.1
standby 1 ip 172.16.10.254
interface e0/1.40
standby 40 ip 172.16.40.254
standby 40 preempt
VERIFICATION TASK #2:
MOSCOWR19#sh stand br
P indicates configured to preempt.
|
Interface Grp Pri P State Active Standby Virtual IP
Et0/1.1 1 100 P Active local 172.16.10.2 172.16.10.254
Et0/1.40 40 100 Active local 172.16.40.2 172.16.40.254
MOSCOWR20#sh standby br
|
Et0/1.1 1 100 Standby 172.16.10.1 local 172.16.10.254
Et0/1.40 40 100 P Standby 172.16.40.1 local 172.16.40.254
Observation:
1. By default, whenever there is no priority set on HSRP, the highest IP address wins the
election and takes up “ACTIVE” role so that way MOSCOWR20 should have been the
“ACTIVE” as it has highest IP on its interface.
2. However, here in our scenario, MOSCOWR19 is elected as “ACTIVE” because
“MOSCOWR19” was configured first and it declared itself as “ACTIVE” and when you
configure “MOSCOWR20” is it going to take “Standby” role.
3. Though we have “Preempt” configured under MOSCOWR20, it is not going to become
“ACTIVE” until “Priority” is set greater than 100 (default)
4. Please note, if you configure on both router at same time the HSRP election would pick
MOSCOWR20 to be “ACTIVE” being having highest interface IP address
MOSCOWR20# show stand brief
|
Et0/1.1 1 100 Active local unknown 172.16.10.254
Et0/1.40 40 100 P Active local unknown 172.16.40.254

85April 24, 2020
MOSCOWR19#show standby
Ethernet0/1.1 - Group 1
State is Standby
6 state changes, last state change 00:03:08
Virtual IP address is 172.16.10.254
Active virtual MAC address is 0000.0c07.ac01
Local virtual MAC address is 0000.0c07.ac01 (v1 default)
Hello time 3 sec, hold time 10 sec
Next hello sent in 1.296 secs
Preemption enabled
Active router is 172.16.10.2, priority 110 (expires in 9.456 sec)
Standby router is local
Priority 100 (default 100)
Group name is "hsrp-Et0/1.1-1" (default)
State is Standby
Preemption disabled
MOSCOWR19#
State is Active
Preemption disabled
Active router is local
Standby router is 172.16.10.1, priority 100 (expires in 11.008 sec)
Priority 110 (configured 110)
State is Active

86April 24, 2020
Preemption enabled
Priority 110 (configured 110)
MOSCOWR20#
CONFIGURATION TASK #3: Configure ”Priority 110” on MOSCOWR20
MOSCOWR20(config)#interface e0/1.1
MOSCOWR20(config-subif)#standby 1 priority 110
MOSCOWR20(config-subif)#standby 40 priority 110
MOSCOWR20#sh stand brief
|
Et0/1.1 1 110 Active local unknown 172.16.10.254
Et0/1.40 40 110 P Active local 172.16.40.1 172.16.40.254
|
Et0/1.40 40 100 Standby 172.16.40.2 local 172.16.40.254
Observation:
1. As soon as you configured the “priority 110” on MOSCOWR20, the “preempt” triggered
up the re-election, MOSCOWR20 is “ACTIVE” for both Vlan 1 and 40
CONFIGURATION TASK #4: Configure “Load Sharing”.
Vlan1 Active on MOSCOWR19 and Vlan40 Active on MOSCOWR20
MOSCOWR19(config)#
interface e0/1.1
standby 1 priority 120

87April 24, 2020
|
Et0/1.40 40 100 Standby 172.16.40.2 local 172.16.40.254
MOSCOWR20#sh stand brief
|
Et0/1.1 1 110 Standby 172.16.10.1 local 172.16.10.254
Et0/1.40 40 110 P Active local 172.16.40.1 172.16.40.254
Observation:
Nothing to be changed for Vlan40 as Vlan40 is already “Active” on MOSCOWR20.
CONFIGURATION TASK #5: Object-tracking (WAN side facing)
1. Let us assume MOSCOWR19_e0/2 goes Down.
Configure “HSRP Object-Tracking” so that the re-election takes place the traffic switchovers to
MOSCOWR20 router
Pre-checks
From PC10:
PC10/ # traceroute 8.8.8.8
1 172.16.10.1 (172.16.10.2) 7.521 ms 3.646 ms 7.701 ms →packet going via MOSCOWR19
2 192.168.32.2 (192.168.32.2) 5.977 ms 7.163 ms 6.677 ms
MOSCOWR19#show standby brief
Et0/1.40 40 100 Standby 172.16.40.2 local 172.16.40.254
#configure prempt as this was not configured earlier
MOSCOWR20(router)
interface e0/1.1
standby 1 preempt
#configure object-tracking on WAN facing interface
MOSCOWR19(config)#
track 1 interface ethernet 0/2 line-protocol
exit
interface e0/1.1
standby 1 track 1 decrement 30

88April 24, 2020
To verify the “object tracking” behaviour “shutdown” interface ethernet0/2 of MOSCOWR19
MOSCOWR19(config)#
interface e0/2
shut
*May 14 19:17:52.042: %TRACK-6-STATE: 1 interface Et0/2 line-protocol Up -> Down
*May 14 19:20:25.463: %HSRP-5-STATECHANGE: Ethernet0/1.1 Grp 1 state Active -> Speak
*May 14 19:20:36.203: %HSRP-5-STATECHANGE: Ethernet0/1.1 Grp 1 state Speak -> Standby
Post-checks:
Et0/1.40 40 100 Standby 172.16.40.2 local 172.16.40.254
Observations:
Priority decreased by “30” as per the object-tracking command
We have set decrement of “30” incase of MOSCOWR19_Eth0/2 Line-protocol going “Down”
/ # traceroute 8.8.8.8
1 172.16.10.2 (172.16.10.2) 7.146 ms 4.018 ms 3.937 ms →now traffic goes over MOSCOWR20
2 192.168.32.2 (192.168.32.2) 7.994 ms 7.780 ms 7.122 ms
Gratuitous ARP:
The Gratuitous ARP is sent as a broadcast, as a way for a node to announce or update its IP to MAC mapping to
the entire network.

89April 24, 2020
HSRPv1 HSRP Packet {Default Config}

90April 24, 2020
LAB #10 CONFIGURE – HSRPv2
Objectives: Consider MOSCOWR19, MOSCOWR20, MOSCOWSW01, MOSCOWSW02, PC10, PC19,
PC11, PC12 as following:
PC10, PC19, PC11, PC12 (compltd in Lab#9)
2. Configure “HSRPv2” for only Ethernet0/1.1 (Note:HSRPv1 still running on Ethernet0/1.40)
3. Validate Packet structure using Wireshark for HSRPv2
4. Configure “HSRPv2” for Ethernet0/1.40 as well

91April 24, 2020
Task#2 Configure “HSRPv2” for only Ethernet0/1.1 (Note: HSRPv1 still running on
Ethernet0/1.40)
MOSCOWR19(router)
interface e0/1.1
standby 1 ip 172.16.10.254
standby 1 preempt
standby version 2
interface e0/1.40
standby 40 ip 172.16.40.254
MOSCOWR20(router)
interface e0/1.1
standby 1 ip 172.16.10.254
standby version 2
interface e0/1.40
standby 40 ip 172.16.40.254
standby 40 preempt
MOSCOWR19#sh standby
Ethernet0/1.1 - Group 1 (version 2)
State is Active
Active virtual MAC address is 0000.0c9f.f001
Local virtual MAC address is 0000.0c9f.f001 (v2 default)
Preemption enabled
State is Active
Preemption disabled
Note:
We are successfully running

92April 24, 2020
HSRPv2 between MOSCOWR19_Eth0/1.1 <-> MOSCOWR20_Eth0/1.1
HSRPv1 between MOSCOWR19_Eth0/1.40 <-> MOSCOWR20_Eth0/1.40
It proves we can run two instances of HSRP versions on single physical interfaces over two
different sub-interfaces.
Wireshark Captures:
MOSCOWR19#show standby br
|
Et0/1.1 1 100 P Active local 172.16.10.2 172.16.10.254 → running on HSRPv2
Et0/1.40 40 100 Active local 172.16.40.2 172.16.40.254 → running on HSRPv1
VERIFICATION TASK #3: Validate Packet structure using Wireshark for HSRPv2

93April 24, 2020
Task#4 Configure “HSRPv2” for Ethernet0/1.40 as well
MOSCOWR19(router)
interface e0/1.1
standby 1 ip 172.16.10.254
standby 1 preempt
standby version 2
interface e0/1.40
standby 40 ip 172.16.40.254
standby version 2
MOSCOWR20(router)
interface e0/1.1
standby 1 ip 172.16.10.254
standby version 2
interface e0/1.40
standby 40 ip 172.16.40.254
standby 40 preempt
standby version 2
standby 40 priority 110
Verification Task#4 Configure “HSRPv2” for Ethernet0/1.40 as well
Et0/1.1 1 100 P Active local 172.16.10.2 172.16.10.254
Et0/1.40 40 100 Standby 172.16.40.2 local 172.16.40.254
Et0/1.1 1 100 Standby 172.16.10.1 local 172.16.10.254
Et0/1.40 40 110 P Active local 172.16.40.1 172.16.40.254
Observation:
MOSCOWR19 is Active HSRP for Vlan 1
MOSCOWR20 is Active HSRP for Vlan 40
This helps is load sharing.
Both are now running over HSRP version2.
State is Active

94April 24, 2020
Preemption enabled
State is Standby
Preemption disabled
MAC address is aabb.cc00.1110

95April 24, 2020
LAB #11 CONFIGURE – VRRPv2 and VRRPv3
2. Configure “VRRPv2” on Ethernet0/1.1 and Ethernet0/1.40 using new VIP IP
3. Validate Packet structure using Wireshark for VRRPv2
4. Use real interface IP for “VRRPv2” on Ethernet0/1.1 and Ethernet0/1.40 so as to avoid usage of
need for third IP for VIP.
5. Upgrade VRRPv2 to VRRPv3 on Ethernet0/1.1 and Ethernet0/1.40 and observe the Wireshark
captures

96April 24, 2020
Task#2 Configure “VRRPv2” on Ethernet0/1.1 and Ethernet0/1.40
MOSCOWR19(router)
interface e0/1.1
vrrp 1 ip 172.16.10.254
interface e0/1.40
vrrp 40 ip 172.16.40.254
MOSCOWR20(router)
interface e0/1.1
vrrp 1 ip 172.16.10.254
interface e0/1.40
vrrp 40 ip 172.16.40.254
Verification Task#2:
MOSCOWR19#show vrrp brief
Interface Grp Pri Time Own Pre State Master addr Group addr
Et0/1.1 1 100 3609 Y Backup 172.16.10.2 172.16.10.254
Et0/1.40 40 100 3609 Y Backup 172.16.40.2 172.16.40.254
Et0/1.1 1 100 3609 Y Master 172.16.10.2 172.16.10.254
Et0/1.40 40 100 3609 Y Master 172.16.40.2 172.16.40.254
Note:
- By default Preempt are enabled in VRRP.
- MOSCOWR20 is Master for both instances Group 1 and 40, due to higher Physical IP address
on the interface.
- Own = Owner, The VRRP router that has the virtual router's IP address(es) as real interface
address(es). This is the router that, when up, will respond to packets addressed to one of
these IP addresses for ICMP pings, TCP connections, etc.
VRRP DEBUG PACKETS:
MOSCOWR20#
*Aug 14 09:35:07.650: %VRRP-6-STATECHANGE: Et0/1.1 Grp 1 state Master -> Disable
*Aug 14 09:35:07.651: %VRRP-6-STATECHANGE: Et0/1.1 Grp 1 state Init -> Backup
*Aug 14 09:35:08.157: %VRRP-6-STATECHANGE: Et0/1.40 Grp 40 state Master -> Disable
*Aug 14 09:35:08.157: %VRRP-6-STATECHANGE: Et0/1.40 Grp 40 state Init -> Master

97April 24, 2020
Verification Task#3: Wireshark Captures
Task#4 Use real interface IP for “VRRPv2” on Ethernet0/1.1 and Ethernet0/1.40 so as to avoid
usage of need for third IP for VIP.
MOSCOWR19(router)
interface e0/1.1
vrrp 1 ip 172.16.10.1
interface e0/1.40
vrrp 40 ip 172.16.40.2
MOSCOWR20(router)
interface e0/1.1
vrrp 1 ip 172.16.10.1
interface e0/1.40
vrrp 40 ip 172.16.40.2
172.16.10.1 → real physical IP address of MOSCOWR19_Eth0/1.1
172.16.40.2 → real physical IP address of MOSCOWR20_Eth0/1.40
We are now using Real IP.
This approach is used when there is no free IP left to be used as VIP.
HSRP needs three IP’s to work but in VRRP we can use one of Real IP of physical interface.
Watch Class Video to understand more about it.

98April 24, 2020
Verifications#4
MOSCOWR19#show vrrp br
Et0/1.1 1 255 3003 Y Y Master 172.16.10.1 172.16.10.1
Et0/1.40 40 100 3609 Y Backup 172.16.40.2 172.16.40.2
Et0/1.1 1 100 3609 Y Backup 172.16.10.1 172.16.10.1
Et0/1.40 40 255 3003 Y Y Master 172.16.40.2 172.16.40.2
Note:
- Y = Own = Owner, The VRRP router that has the virtual router's IP address(es) as real interface
address(es). This is the router that, when up, will respond to packets addressed to one of
these IP addresses for ICMP pings, TCP connections, etc.
- Default Priority = 255 for Interface using Real IP address (Owner)
- Default Priority = 100 for all other Interfaces (Backup)
- Preempt = Enabled by default
Task#5 Upgrade VRRPv2 to VRRPv3 on Ethernet0/1.1 and Ethernet0/1.40 and observe the
Wireshark captures
MOSCOWR19(router)
fhrp version vrrp v3
interface e0/1.1
vrrp 1 address-family ipv4
address 172.16.10.254
interface e0/1.40
address 172.16.40.254
MOSCOWR20(router)
fhrp version vrrp v3
interface e0/1.1
address 172.16.10.254
interface e0/1.40
address 172.16.40.254

99April 24, 2020
Verifications#5
Interface Grp A-F Pri Time Own Pre State Master addr/Group addr
Et0/1.1 1 IPv4 100 0 N Y MASTER 172.16.10.1(local) 172.16.10.254
Et0/1.40 40 IPv4 100 0 N Y MASTER 172.16.40.1(local) 172.16.40.254
Interface Grp A-F Pri Time Own Pre State Master addr/Group addr
Et0/1.1 1 IPv4 100 3609 N Y BACKUP 172.16.10.1 172.16.10.254
Et0/1.40 40 IPv4 100 3609 N Y BACKUP 172.16.40.1 172.16.40.254
Own = Owner = No (Y = Yes only when Real IP address is used in VRRP)
Preempt = Y (by default enabled)
A-F = Address Family IPv4
MOSCOWR19#show vrrp detail
Ethernet0/1.1 - Group 1 - Address-Family IPv4
State is MASTER
State duration 8 mins 17.992 secs
Virtual MAC address is 0000.5E00.0101
Advertisement interval is 1000 msec
Preemption enabled
Priority is 100
Master Router is 172.16.10.1 (local), priority is 100
Master Advertisement interval is 1000 msec (expires in 64 msec)
Master Down interval is unknown
VRRPv3 Advertisements: sent 548 (errors 0) - rcvd 0
Group Discarded Packets: 0
VRRPv2 incompatibility: 0
IP Address Owner conflicts: 0
Invalid address count: 0
IP address configuration mismatch : 0
Invalid Advert Interval: 0
Adverts received in Init state: 0
Invalid group other reason: 0
Group State transition:
Init to master: 0
Init to backup: 1 (Last change Fri Aug 14 09:53:09.437)
Backup to master: 1 (Last change Fri Aug 14 09:53:13.054)
Master to backup: 0
Master to init: 0
Backup to init: 0
State is MASTER

100April 24, 2020
Preemption enabled
Priority is 100
Group Discarded Packets: 0
VRRPv2 incompatibility: 0
IP Address Owner conflicts: 0
Invalid address count: 0
IP address configuration mismatch : 0
Invalid Advert Interval: 0
Adverts received in Init state: 0
Invalid group other reason: 0
Group State transition:
Init to master: 0
Init to backup: 1 (Last change Fri Aug 14 09:53:10.503)
Backup to master: 1 (Last change Fri Aug 14 09:53:14.113)
Master to backup: 0
Master to init: 0
Backup to init: 0
MOSCOWR19#show vrrp ipv4
State is MASTER
Preemption enabled
Priority is 100
State is MASTER
Preemption enabled
Priority is 100

101April 24, 2020
LAB #12 CONFIGURE – GLBP
2. Configure “GLBP” on Ethernet0/1.1 and Ethernet0/1.40 using new VIP IP (172.16.10.254)
3. Change AVP role by changing Priority and Prompt configurations
4. Configure MD5 Authentication for Group 1
5. Configure Tracking (object) on MOSCOWR20 Eth0/2
6. Change Load-balancing Method to “Weighted” for Group 1

102April 24, 2020
Task#2 Configure “GLBP” on Ethernet0/1.1 and Ethernet0/1.40 using new VIP IP (172.16.10.254)
MOSCOWR19(router)
interface e0/1.1
glbp 1 ip 172.16.10.254
interface e0/1.40
glbp 40 ip 172.16.40.254
MOSCOWR20(router)
interface e0/1.1
glbp 1 ip 172.16.10.254
interface e0/1.40
glbp 40 ip 172.16.40.254
Verification Task#2
MOSCOWR19#show glbp brief
Interface Grp Fwd Pri State Address Active router Standby router
Et0/1.1 1 - 100 Active 172.16.10.254 local 172.16.10.2
Et0/1.1 1 1 - Active 0007.b400.0101 local -
Et0/1.1 1 2 - Listen 0007.b400.0102 172.16.10.2 -
Et0/1.40 40 - 100 Active 172.16.40.254 local 172.16.40.2
Et0/1.40 40 1 - Active 0007.b400.2801 local -
Et0/1.40 40 2 - Listen 0007.b400.2802 172.16.40.2 -
Et0/1.1 1 - 100 Standby 172.16.10.254 172.16.10.1 local
Et0/1.1 1 1 - Listen 0007.b400.0101 172.16.10.1 -
Et0/1.1 1 2 - Active 0007.b400.0102 local -
Et0/1.40 40 - 100 Standby 172.16.40.254 172.16.40.1 local
Et0/1.40 40 1 - Listen 0007.b400.2801 172.16.40.1 -
Et0/1.40 40 2 - Active 0007.b400.2802 local -
AVG = MOSCOWR19 for both Group 1 and 40
For Group 1 (VLan 1)
AVF = 0007.b400.0101 (virtual MAC address) MOSCOWR19
For Group 40 (Vlan 40)
virtual MAC address that GLBP uses is 0007.b400.XXYY (where X = GLBP group
number and Y = AVF number)
Hexadecimal of 40 = 28 in our case topology
GLBP Syslog Messages:
*Aug 14 14:04:02.198: %GLBP-6-STATECHANGE: Ethernet0/1.1 Grp 1 state Speak -> Active

103April 24, 2020
*Aug 14 14:04:02.203: %GLBP-6-STATECHANGE: Ethernet0/1.40 Grp 40 state Speak -> Active
MOSCOWR19#
*Aug 14 14:04:12.262: %GLBP-6-FWDSTATECHANGE: Ethernet0/1.1 Grp 1 Fwd 1 state Listen ->
Active
MOSCOWR19#
Active
MOSCOWR19#
MOSCOWR19#show glbp
State is Active
1 state change, last state change 00:09:09
Redirect time 600 sec, forwarder timeout 14400 sec
Preemption disabled
Active is local
Standby is 172.16.10.2, priority 100 (expires in 8.736 sec)
Priority 100 (default)
Weighting 100 (default 100), thresholds: lower 1, upper 100
Load balancing: round-robin
Group members:
aabb.cc00.1010 (172.16.10.1) local
aabb.cc00.1110 (172.16.10.2)
There are 2 forwarders (1 active)
Forwarder 1
State is Active
MAC address is 0007.b400.0101 (default)
Owner ID is aabb.cc00.1010
Redirection enabled
Preemption enabled, min delay 30 sec
Active is local, weighting 100
Forwarder 2
State is Listen
MAC address is 0007.b400.0102 (learnt)
Redirection enabled, 598.752 sec remaining (maximum 600 sec)
Time to live: 14398.752 sec (maximum 14400 sec)
Active is 172.16.10.2 (primary), weighting 100 (expires in 9.856 sec)
State is Active

104April 24, 2020
Preemption disabled
Active is local
Group members:
aabb.cc00.1010 (172.16.40.1) local
aabb.cc00.1110 (172.16.40.2)
Forwarder 1
State is Active
Redirection enabled
Forwarder 2
State is Listen
MOSCOWR19#
Task#3 Change AVP role by changing Priority and Prompt configurations
MOSCOWR20(config-subif)#glbp 1 ip 172.16.10.254
MOSCOWR20(config-subif)#interface e0/1.40
MOSCOWR20(config-subif)#glbp 40 ip 172.16.40.254
MOSCOWR20(config-subif)#glbp 40 preempt
MOSCOWR20(config-subif)#glbp 40 priority 110
MOSCOWR20(config-subif)#end
*Aug 14 14:24:35.990: %GLBP-6-STATECHANGE: Ethernet0/1.40 Grp 40 state Standby -> Active
Verification Task#3
Et0/1.1 1 - 100 Active 172.16.10.254 local 172.16.10.2
Et0/1.1 1 1 - Active 0007.b400.0101 local -

105April 24, 2020
Et0/1.1 1 2 - Listen 0007.b400.0102 172.16.10.2 -
Et0/1.40 40 - 100 Standby 172.16.40.254 172.16.40.2 local
Et0/1.40 40 1 - Active 0007.b400.2801 local -
Et0/1.40 40 2 - Listen 0007.b400.2802 172.16.40.2 -
Et0/1.1 1 - 100 Standby 172.16.10.254 172.16.10.1 local
Et0/1.1 1 1 - Listen 0007.b400.0101 172.16.10.1 -
Et0/1.1 1 2 - Active 0007.b400.0102 local -
Et0/1.40 40 - 110 Active 172.16.40.254 local 172.16.40.1
Et0/1.40 40 1 - Listen 0007.b400.2801 172.16.40.1 -
Et0/1.40 40 2 - Active 0007.b400.2802 local -
AVG = MOSCOWR19 for Group 1
(new) AVG = MOSCOWR20 for Group 40
Task#4 Configure MD5 Authentication for Group 1
MOSCOWR19(router)
interface e0/1.1
glbp 1 ip 172.16.10.254
glbp 1 authentication md5 key-string networkjourney
interface e0/1.40
glbp 40 ip 172.16.40.254
MOSCOWR20(router)
interface e0/1.1
glbp 1 ip 172.16.10.254
interface e0/1.40
glbp 40 ip 172.16.40.254
glbp 40 preempt
glbp 40 priority 110
Verification Task#4
MOSCOWR20#show glbp
State is Active

106April 24, 2020
Authentication MD5, key-string
Preemption disabled
Active is local
Group members:
aabb.cc00.1010 (172.16.10.1) authenticated
aabb.cc00.1110 (172.16.10.2) local
Forwarder 1
State is Listen
Forwarder 2
State is Active
Redirection enabled
State is Active
Active is local
Priority 110 (configured)
Group members:
aabb.cc00.1010 (172.16.40.1)
aabb.cc00.1110 (172.16.40.2) local
Forwarder 1
State is Listen

107April 24, 2020
Forwarder 2
State is Active
Redirection enabled
MOSCOWR20#
Task#5 Configure Tracking (object) on MOSCOWR20 Eth0/2
Interface tracking works differently for GLBP compared to HSRP or VRRP. HSRP/VRRP use a single
threshold to determine which router is active/master. If your priority decreases and becomes lower
than another device, you’ll lose the active/master state and someone else takes over. GLBP works
differently and has a weighting mechanism. Weighting will be used to determine if a device can be
AVF or not.
Pre-checks:
MOSCOWR20#show glbp | include weighting
MOSCOWR20(router)
interface e0/1.1
glbp 1 ip 172.16.10.254
glbp 1 weighting track 2 decrement 40
glbp 1 weighting 100 lower 70 upper 90
interface e0/1.40
glbp 40 ip 172.16.40.254
glbp 40 preempt
glbp 40 priority 110
track 2 interface Eth 0/2 line-protocol
This is how we configure weighting; this is what it will do:
• The default weighting has a value of 100.
• Once we fall below a weighting value of 70 MOSCOWR20 will no longer be an AVF.
• Once the weighting gets above 90, we will become an AVF once again.

108April 24, 2020
Verification Task#5
Let’s see it in action! Here are the values I just configured:
Post-checks:
MOSCOWR20#show glbp | include Weighting
Weighting 100 (configured 100), thresholds: lower 70, upper 90
Let’s shut the Ethernet 0/2 interface:
MOSCOWR20 (config)#
interface Ethernet 0/2
shutdown
*Aug 14 14:52:21.271: %TRACK-6-STATE: 2 interface Et0/2 line-protocol Up -> Down
And check the new weighting value:
Weighting 60, low (configured 100), thresholds: lower 70, upper 90
This will decrement our weighting 40 which should get our weighting to a value of 60. A few seconds
later, you’ll see this on the console:
*Aug 14 14:55:11.027: %GLBP-6-FWDSTATECHANGE: Ethernet0/1.1 Grp 1 Fwd 2 state Active ->
Listen
MOSCOWR20#
Our weighting is now 60 which lower than the “lower” value that we configured at 70. MOSCOWR20
is no longer an AVF for Group 1.
Et0/1.1 1 - 100 Active 172.16.10.254 local 172.16.10.1
Et0/1.1 1 1 - Listen 0007.b400.0101 172.16.10.1 -
Et0/1.1 1 2 - Listen 0007.b400.0102 172.16.10.1 -
Et0/1.40 40 - 110 Active 172.16.40.254 local 172.16.40.1
Et0/1.40 40 1 - Listen 0007.b400.2801 172.16.40.1 -
Et0/1.40 40 2 - Active 0007.b400.2802 local -
Et0/1.1 1 - 100 Standby 172.16.10.254 172.16.10.2 local
Et0/1.1 1 1 - Active 0007.b400.0101 local -
Et0/1.1 1 2 - Active 0007.b400.0102 local -
Et0/1.40 40 - 100 Standby 172.16.40.254 172.16.40.2 local
Et0/1.40 40 1 - Active 0007.b400.2801 local -
Et0/1.40 40 2 - Listen 0007.b400.2802 172.16.40.2 -

109April 24, 2020
Let’s restore the Ethernet 0/2 interface:
MOSCOWR20(config)#int e0/2
MOSCOWR20(config-if)#no shutdown
*Aug 14 14:58:18.700: %TRACK-6-STATE: 2 interface Et0/2 line-protocol Down -> Up
Now our weighting is back to 100 and we exceeded the upper value of 90. We are back in the game!
MOSCOWR20#show glbp br
Et0/1.1 1 - 100 Active 172.16.10.254 local 172.16.10.1
Et0/1.1 1 1 - Listen 0007.b400.0101 172.16.10.1 -
Et0/1.1 1 2 - Active 0007.b400.0102 local -
Et0/1.40 40 - 110 Active 172.16.40.254 local 172.16.40.1
Et0/1.40 40 1 - Listen 0007.b400.2801 172.16.40.1 -
Et0/1.40 40 2 - Active 0007.b400.2802 local -
MOSCOWR20#
Active
Task#6 Change Load-balancing Method to “Weighted”
MOSCOWR19(config)#
interface e0/1.1
glbp 1 load-balancing weighted
glbp 1 weighting 20
MOSCOWR20(config)#
interface e0/1.1
glbp 1 load-balancing weighted
glbp 1 weighting 80
Note:
Default Load-balancing Method in GLBP is Round Robin
Verification Task#6
MOSCOWR19#show glbp
State is Standby

110April 24, 2020
Preemption disabled
Active is 172.16.10.2, priority 100 (expires in 11.648 sec)
Standby is local
Load balancing: weighted
<!--output omitted--!>
MOSCOWR20#show glbp
State is Active
Preemption disabled
Active is local
Track object 2 state Up decrement 40
Load balancing: weighted
<!—output omitted--!>

111April 24, 2020
LAB #12 CONFIGURE – EIGRP
Task#1 Configure EIGRP 64bit or named mode for IPv4
Task#2 Configure EIGRP classic mode for IPv4
Task#2 configure EIGRP Authentication
Task#3 Configure EIGRP Passive Interface
Task#4 Configure EIGRP Hold Time and Hello Packets
Task#5 Manipulate EIGRP Equal Cost Load Balancing
Task#5 Configure EIGRP Unequal Cost Load Balancing using Variance
Task#6 Configure EIGRP Manual Summarization
Task#7 Manipulate Path Selection using K-values

112April 24, 2020
Configure Task#1 Configure EIGRP 64bit or named mode for IPv4
The Enhanced Interior Gateway Routing Protocol can be configured using either the classic mode
or the named mode. The classic mode is the old way of configuring EIGRP. In classic mode, EIGRP
configurations are scattered across the router mode and the interface mode. The named
mode is the new way of configuring EIGRP; this mode allows EIGRP configurations to be entered
in a hierarchical manner under the router mode.
Each named mode configuration can have multiple address families and autonomous system
number combinations. In the named mode, you can have similar configurations across IPv4 and
IPv6.
Step#1 Configure IPs on all the EIGRP participating interfaces:
TOKYOR7(config)#
hostname TOKYOR7
ip address 192.168.10.1 255.255.255.0
no shut
ip address 192.168.40.1 255.255.255.0
no shut
ip address 192.168.20.1 255.255.255.0
no shut
interface Loopback1
ip address 1.1.1.1 255.255.255.0
no shut
TOKYOR10(config)#
hostname TOKYOR10
ip address 192.168.10.2 255.255.255.0
no shut
ip address 192.168.30.2 255.255.255.0
no shut
TOKYOR29(config)#
hostname TOKYOR29
ip address 192.168.40.2 255.255.255.0
no shut
!
ip address 192.168.50.2 255.255.255.0
no shut

113April 24, 2020
TOKYOR12(config)#
hostname TOKYOR12
ip address 192.168.20.2 255.255.255.0
no shut
!
ip address 192.168.60.2 255.255.255.0
no shut
TOKYOR30(config)#
hostname TOKYOR30
!
ip address 192.168.30.1 255.255.255.0
no shut
!
ip address 192.168.50.1 255.255.255.0
no shut
!
ip address 192.168.60.1 255.255.255.0
no shut
!
interface Loopback1
ip address 4.4.4.4 255.255.255.0
no shut
Step#2 Configure 64-bit Named EIGRP for name = “networkjourney” & AS = “150”
TOKYOR7(config)#
router eigrp networkjourney
address-family ipv4 unicast autonomous-system 150
network 192.168.10.0
network 192.168.40.0
network 192.168.20.0
exit-address-family
TOKYOR10(config)#
network 192.168.10.0
network 192.168.30.0
exit-address-family
TOKYOR29(config)#

114April 24, 2020
network 192.168.40.0
network 192.168.50.0
exit-address-family
TOKYOR12(config)#
network 192.168.20.0
network 192.168.60.0
exit-address-family
TOKYOR30(config)#
network 192.168.30.0
network 192.168.50.0
network 192.168.60.0
network 4.4.4.0
exit-address-family
Verification Task#1 EIGRP 64bit or named mode for IPv4
TOKYOR7#show ip eigrp neighbors
EIGRP-IPv4 VR(networkjourney) Address-Family Neighbors for AS(150)
H Address Interface Hold Uptime SRTT RTO Q Seq
(sec) (ms) Cnt Num
2 192.168.20.2 Et0/3 14 00:01:49 2 100 0 9
1 192.168.40.2 Et0/2 13 00:01:57 9 100 0 10
0 192.168.10.2 Et0/1 13 00:02:05 8 100 0 11
TOKYOR7#
• H (Handle): Here you will find the order when the neighbor adjacency was established.
Your first neighbor will have a value of 0 and then 1
• Hold: (sec): this is the holddown timer per EIGRP neighbor. Once this timer expires we
will drop the neighbor adjacency. The default holddown timer is 15 seconds.
• Uptime: How long the neighbor has been up.
• SRTT (Smooth round-trip time): The number of milliseconds it takes to send an EIGRP
packet to your neighbor and receive an acknowledgment packet back.
• RTO (Retransmission timeout): The amount of time in milliseconds that EIGRP will
wait before retransmitting a packet from the retransmission queue to this neighbor.
• Q Cnt (Q count): The number of EIGRP packets (Update, Query or Reply) in the queue
that are awaiting transmission. This count is usually be zero only as all the packet
exchange is within msec only.
• Seq Num (Sequence number): This will show you the sequence number of the last
update,query or reply packet that you received from your EIGRP neighbor.
TOKYOR7#show ip eigrp topology

115April 24, 2020
EIGRP-IPv4 VR(networkjourney) Topology Table for AS(150)/ID(1.1.1.1)
Codes: P - Passive, A - Active, U - Update, Q - Query, R - Reply,
r - reply Status, s - sia Status
P 192.168.10.0/24, 1 successors, FD is 131072000
via Connected, Ethernet0/1
via 192.168.10.2 (196608000/131072000), Ethernet0/1
via 192.168.40.2 (196608000/131072000), Ethernet0/2
via 192.168.20.2 (196608000/131072000), Ethernet0/3
via 192.168.10.2 (196689920/131153920), Ethernet0/1
via 192.168.20.2 (196689920/131153920), Ethernet0/3
via 192.168.40.2 (196689920/131153920), Ethernet0/2
• The topology table is used to store information about all known routes received from all neighbors.
If a neighbor is advertising a possible route, it must be using that route to forward packets to the
destination network.
• If the successor route goes away, DUAL will search the topology table for a backup route. The
topology table is where EIGRP stores the information for up to six alternate routes to a particular
network. The backup routes are called feasible successors.
• The feasible successors stored in the topology table are what makes it possible for EIGRP to
converge rapidly or even instantly. If there is no feasible successor in the table, a multicast is sent
out to find a new route
TOKYOR7#show ip route eigrp
Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
o - ODR, P - periodic downloaded static route, H - NHRP, l - LISP
a - application route
+ - replicated route, % - next hop override
Gateway of last resort is not set
4.0.0.0/24 is subnetted, 1 subnets
D 4.4.4.0 [90/1536640] via 192.168.40.2, 00:03:17, Ethernet0/2
[90/1536640] via 192.168.20.2, 00:03:17, Ethernet0/3
[90/1536640] via 192.168.10.2, 00:03:17, Ethernet0/1
D 192.168.30.0/24 [90/1536000] via 192.168.10.2, 00:04:11, Ethernet0/1

116April 24, 2020
D 192.168.50.0/24 [90/1536000] via 192.168.40.2, 00:04:11, Ethernet0/2
D 192.168.60.0/24 [90/1536000] via 192.168.20.2, 00:04:11, Ethernet0/3
TOKYOR7#
EIGRP AD value is 90 and EIGRP routes will be represented with ‘D’ and EIGRP also installs both the
paths in routing table with equal cost for achieving equal cost load balancing.
D Shows this is an EIGRP learnt route
4.0.0.0/24 Destination learn network and 24 is subnet mask.
90 90, is the Administrative Distance of EIGRP.
1536640 This is the metric, Total distance to get to the destination
192.168.40.2 The neighbor that advertised the route.
00:03:17 Time since the route was learnt.
Ethernet0/2 The outbound interface going towards the destination.
Best path is installed in Routing Table and Backup path is installed in topology table.

117April 24, 2020
Configure Task#2 Configure EIGRP classic mode for IPv4
TOKYOR7(config)#
hostname TOKYOR7
ip address 192.168.10.1 255.255.255.0
no shut
ip address 192.168.40.1 255.255.255.0
no shut
ip address 192.168.20.1 255.255.255.0
no shut
interface Loopback1
ip address 1.1.1.1 255.255.255.0
no shut
TOKYOR10(config)#
hostname TOKYOR10
ip address 192.168.10.2 255.255.255.0
no shut

118April 24, 2020
ip address 192.168.30.2 255.255.255.0
no shut
TOKYOR29(config)#
hostname TOKYOR29
ip address 192.168.40.2 255.255.255.0
no shut
!
ip address 192.168.50.2 255.255.255.0
no shut
TOKYOR12(config)#
hostname TOKYOR12
ip address 192.168.20.2 255.255.255.0
no shut
!
ip address 192.168.60.2 255.255.255.0
no shut
TOKYOR30(config)#
hostname TOKYOR30
!
ip address 192.168.30.1 255.255.255.0
no shut
!
ip address 192.168.50.1 255.255.255.0
no shut
!
ip address 192.168.60.1 255.255.255.0
no shut
!
interface Loopback1
ip address 4.4.4.4 255.255.255.0
no shut
Step#2 Configure classic mode EIGRP for AS = “1”
TOKYOR7(config)#
router eigrp 1
network 192.168.10.0
network 192.168.40.0

119April 24, 2020
network 192.168.20.0
exit
TOKYOR10(config)#
router eigrp 1
network 192.168.10.0
network 192.168.30.0
exit
TOKYOR29(config)#
router eigrp 1
network 192.168.40.0
network 192.168.50.0
exit
TOKYOR12(config)#
router eigrp 1
network 192.168.20.0
network 192.168.60.0
exit
TOKYOR30(config)#
router eigrp 1
network 192.168.30.0
network 192.168.50.0
network 192.168.60.0
network 4.4.4.0
exit
Verification Task#1 EIGRP classic mode for IPv4
TOKYOR7#sh ip eigrp neighbors
EIGRP-IPv4 VR(networkjourney) Address-Family Neighbors for AS(150)
(sec) (ms) Cnt Num
2 192.168.20.2 Et0/3 14 00:14:43 4 100 0 14
1 192.168.40.2 Et0/2 12 00:14:51 7 100 0 17
0 192.168.10.2 Et0/1 14 00:14:58 5 100 0 20
EIGRP-IPv4 Neighbors for AS(1)
(sec) (ms) Cnt Num
2 192.168.20.2 Et0/3 12 00:00:50 8 100 0 6
1 192.168.40.2 Et0/2 12 00:01:01 7 100 0 7
0 192.168.10.2 Et0/1 11 00:01:12 7 100 0 8
• You can exclude the EIGRP NAMED mode output here from our previous lab.
• Both Named mode and Classic mode Neighbors are shown in Topology table

120April 24, 2020
TOKYOR7#sh ip eigrp topology
EIGRP-IPv4 VR(networkjourney) Topology Table for AS(150)/ID(1.1.1.1)
P 192.168.30.0/24, 0 successors, FD is Infinity
via 192.168.10.2 (196608000/131072000), Ethernet0/1
via 192.168.40.2 (196608000/131072000), Ethernet0/2
via 192.168.20.2 (196608000/131072000), Ethernet0/3
via 192.168.10.2 (196689920/131153920), Ethernet0/1
via 192.168.20.2 (196689920/131153920), Ethernet0/3
via 192.168.40.2 (196689920/131153920), Ethernet0/2
EIGRP-IPv4 Topology Table for AS(1)/ID(1.1.1.1)
via 192.168.10.2 (307200/281600), Ethernet0/1
via 192.168.40.2 (307200/281600), Ethernet0/2
via 192.168.20.2 (307200/281600), Ethernet0/3
Note:
In EIGRP, reachability is limited to only one AS that means in EIGRP one AS cannot communicate
with another AS number.

121April 24, 2020
TOKYOR7#show ip route eigrp
Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
o - ODR, P - periodic downloaded static route, H - NHRP, l - LISP
a - application route
+ - replicated route, % - next hop override
D 4.4.4.0 [90/1536640] via 192.168.40.2, 00:17:52, Ethernet0/2
[90/1536640] via 192.168.20.2, 00:17:52, Ethernet0/3
[90/1536640] via 192.168.10.2, 00:17:52, Ethernet0/1
D 192.168.30.0/24 [90/307200] via 192.168.10.2, 00:04:56, Ethernet0/1
D 192.168.50.0/24 [90/307200] via 192.168.40.2, 00:04:56, Ethernet0/2
D 192.168.60.0/24 [90/307200] via 192.168.20.2, 00:04:56, Ethernet0/3
TOKYOR7#

122April 24, 2020
Configure Task#3 Configure EIGRP Authentication
More Tips:
Routing protocols can be configured to prevent receiving false routing updates and EIGRP is no
exception. If you don’t use authentication and you are running EIGRP someone could try to form
an EIGRP neighbor adjacency with one of your routers and try to mess with your network…we
don’t want that to happen right?
EIGRP supports MD5 authentication and (since IOS 15.x) SHA authentication, there is no
plaintext authentication.
What does authentication offer us?
• Your router will authenticate the source of each routing update packet that it will receive.
• Prevents false routing updates from sources that are not approved.
• Ignore malicious routing updates.
A potential hacker could be sitting on your network with a laptop running GNS3 / Dynamips, boot
up a Cisco router and try the following things:
• Try to establish a neighbor adjacency with one of your routers and advertise junk routes.
• Send malicious packets and see if you can drop the neighbor adjacency of one of your
authorized routers.
In order to configure EIGRP authentication we need to do the following:

123April 24, 2020
• Configure a key-chain
o Configure a key ID under the key-chain.
▪ Specify a password for the key ID.
▪ Optional: specify accept and expire lifetime for the key.
TOKYOR7(config)#
hostname TOKYOR7
ip address 192.168.10.1 255.255.255.0
no shut
ip address 192.168.40.1 255.255.255.0
no shut
ip address 192.168.20.1 255.255.255.0
no shut
interface Loopback1
ip address 1.1.1.1 255.255.255.0
no shut
TOKYOR10(config)#
hostname TOKYOR10
ip address 192.168.10.2 255.255.255.0
no shut
ip address 192.168.30.2 255.255.255.0
no shut
TOKYOR29(config)#
hostname TOKYOR29
ip address 192.168.40.2 255.255.255.0
no shut
!
ip address 192.168.50.2 255.255.255.0
no shut
TOKYOR12(config)#
hostname TOKYOR12

124April 24, 2020
ip address 192.168.20.2 255.255.255.0
no shut
!
ip address 192.168.60.2 255.255.255.0
no shut
TOKYOR30(config)#
hostname TOKYOR30
!
ip address 192.168.30.1 255.255.255.0
no shut
!
ip address 192.168.50.1 255.255.255.0
no shut
!
ip address 192.168.60.1 255.255.255.0
no shut
!
interface Loopback1
ip address 4.4.4.4 255.255.255.0
no shut
Step#2 Configure classic mode EIGRP for AS = “1”
TOKYOR7(config)#
router eigrp 1
network 192.168.10.0
network 192.168.40.0
network 192.168.20.0
exit
TOKYOR10(config)#
router eigrp 1
network 192.168.10.0
network 192.168.30.0
exit
TOKYOR29(config)#
router eigrp 1
network 192.168.40.0
network 192.168.50.0
exit
TOKYOR12(config)#
router eigrp 1

125April 24, 2020
network 192.168.20.0
network 192.168.60.0
exit
TOKYOR30(config)#
router eigrp 1
network 192.168.30.0
network 192.168.50.0
network 192.168.60.0
network 4.4.4.0
exit
Step#3 Configure MD5 Authentication
TOKYOR7(config)#
key chain AUTH_KEY_CHAIN
key 1
key-string AUTH_KEY_STRING
!
interface range e0/1-3
ip authentication mode eigrp 1 md5
ip authentication key-chain eigrp 1 AUTH_KEY_CHAIN
!
TOKYOR10(config)#
key 1
!
interface e0/1
!
interface e0/3
!
TOKYOR29(config)#
key 1
!
interface e0/2
!
interface e0/0

126April 24, 2020
!
TOKYOR12(config)#
key 1
!
interface e0/3
!
interface e0/2
!
TOKYOR30(config)#
key 1
!
interface e0/0
!
interface e0/2
!
interface e0/3
!
interface lo 1
!
NOTE:
1. We called “AUTH_KEY_CHAIN” but it can be different on every router, it doesn’t matter. The
Key ID is a value that has to match on every router and the key-string is the password which
has to match of course.
2. First you have to create the keychain and then you need to activate it on the interface. The
“1” is the AS number of EIGRP.

127April 24, 2020
Verification Task#3 Configure EIGRP Authentication
You can check if your configuration is correct by using debug eigrp packets. You can see that we
received a packet with MD5 authentication.
TOKYOR7#debug eigrp packet
*Aug 28 13:02:55.884: EIGRP: Sending HELLO on Et0/2 - paklen 60
*Aug 28 13:02:55.884: AS 1, Flags 0x0:(NULL), Seq 0/0 interfaceQ 0/0 iidbQ un/rely 0/0
*Aug 28 13:02:56.163: EIGRP: received packet with MD5 authentication, key id = 1
*Aug 28 13:02:56.163: EIGRP: Received HELLO on Et0/2 - paklen 60 nbr 192.168.40.2
*Aug 28 13:02:56.163: AS 1, Flags 0x0:(NULL), Seq 0/0 interfaceQ 0/0 iidbQ un/rely 0/0 peerQ
un/rely 0/0
NOTE:
If you want to spice it up a bit you can set an accept and expire lifetime on keys. The idea behind
this is that you can have keys that are only valid for a day, a week, a month or something else. Do
you want to use this in real life? It might enhance security but it also makes maintenance a bit
more complex…
Before you configure keys with a limited lifetime make sure you set the correct time and date. You
can do this manually on each router but it’s better to use a NTP (Network Time Protocol) server so
all the routers have the same time/date.

128April 24, 2020
Configure Task#4 Configure EIGRP Hold Time and Hello Packets
First, we will configure EIGRP on all routers, nothing special we just want to make sure we have a
neighbour adjacency. Refer Step#1 and Step#2 refer EIGRP TASK#2
Now we will increase the hold time so it doesn’t drop the neighbour adjacency so quickly. We’ll
set it to 1 hour:
TOKYOR7(config-if)#
interface range e0/1-3
ip hold-time eigrp 1 3600
!
When we take a look at TOKYOR10 you’ll see that it uses 3600 seconds as the hold time for EIGRP
routers:
TOKYOR10#show ip eigrp neighbors
EIGRP-IPv4 Neighbors for AS(1)
(sec) (ms) Cnt Num
1 192.168.30.1 Et0/3 14 00:29:16 1 100 0 7
0 192.168.10.1 Et0/1 3598 00:29:28 1023 5000 0 17

129April 24, 2020
We have 3598 seconds and counting…
There is a common misconception that the Hello and Hold-down timers must match between
routers to form an adjacency but in fact they do not need to match at all in the EIGRP routing
protocol.
Now we will set the hello timer and still no drop in the neighborship table
TOKYOR7(config)#
interface fastEthernet 0/0
ip hello-interval eigrp 12 300
!
MORE TIPS:
EIGRP uses two separate timers to ensure neighbor relationships remain established. These timers
are called the “Hello timer” and the “Hold Down Timer”. If you’re familiar with the operation of
RIP then you should be able to make a very good guess as to what these timers are responsible
for.
The hello timer is the interval at which a router will send “hello” messages to neighboring routers
to let them know that the originating router is still online and the hold-down timer is the interval
at which to consider a neighbor dead if a hello message is not received during that time window.
The default hello timer for a high-speed broadcast network link is 5 seconds and the hold-down
timer is 15 seconds whereas the default timers for slow-speed NBMA link are 60 seconds hello
and 180 seconds dead. A slow-speed NBMA link is classified as any NBMA link with speeds equal
to or less than 1544Kbps (A single T1)
There is a common misconception that the Hello and Hold-down timers must match between
routers to form an adjacency but in fact they do not need to match at all. When a router sends a
hello packet to a neighboring router the hello packet includes the hold down timer which
essentially tells the receiving router “If you do not hear from me in this amount of time consider
me dead and get on with your router life.”
However…… There is one exception to this rule. If you have multiple routers on a network that
form adjacencies then all of those routers must have matching hello/dead timers or the
adjacencies will flap. This is a common problem with EIGRP in a frame-relay hub and spoke
topology where a single T1 NBMA PVC does not support broadcast. In this case the broadcast
PVC’s will use the hello/dead timers of 5/15 whereas the non-broadcast PVC will use 60/180. This
will cause the hub to have adjacencies with neighbors with different timers on the same physical
network thus causing flapping adjacencies.

130April 24, 2020
Configure Task#5 Manipulate EIGRP Equal Cost Load Balancing
NOTE:
By default, EIGRP supports equal-cost load balancing over four links. Equal-cost means that
multiple routes must have the same metric to reach a destination, so that router can choose to
load balance across equal cost links.
o EIGRP take load balancing by default up-to 4 paths can configure up to 32.
From our previous Lab config, I see destination network 4.4.4.4 has three best paths to reach from
TOKYOR7, check below:
TOKYOR7#sh ip route eigrp
D 4.4.4.0 [90/435200] via 192.168.40.2, 00:47:50, Ethernet0/2
[90/435200] via 192.168.20.2, 00:47:50, Ethernet0/3
[90/435200] via 192.168.10.2, 00:47:50, Ethernet0/1
D 192.168.30.0/24 [90/307200] via 192.168.10.2, 00:47:50, Ethernet0/1
D 192.168.50.0/24 [90/307200] via 192.168.40.2, 00:47:50, Ethernet0/2
D 192.168.60.0/24 [90/307200] via 192.168.20.2, 00:47:51, Ethernet0/3

131April 24, 2020
Using maximum-path router configuration command, let us configure maximum paths to be only 2.
TOKYOR7(config)#
router eigrp 1
maximum-paths 2
Now load balancing is happening between 2 paths only:
TOKYOR7#show ip rout eigrp
D 4.4.4.0 [90/435200] via 192.168.20.2, 00:00:52, Ethernet0/3
[90/435200] via 192.168.10.2, 00:00:52, Ethernet0/1
D 192.168.30.0/24 [90/307200] via 192.168.10.2, 00:00:52, Ethernet0/1
D 192.168.50.0/24 [90/307200] via 192.168.40.2, 00:00:52, Ethernet0/2
D 192.168.60.0/24 [90/307200] via 192.168.20.2, 00:00:52, Ethernet0/3
TOKYOR7#show ip route 4.4.4.4
Routing entry for 4.4.4.0/24
Known via "eigrp 1", distance 90, metric 435200, type internal
Redistributing via eigrp 1
Last update from 192.168.20.2 on Ethernet0/3, 00:04:42 ago
Routing Descriptor Blocks:
192.168.20.2, from 192.168.20.2, 00:04:42 ago, via Ethernet0/3
Route metric is 435200, traffic share count is 1
Total delay is 7000 microseconds, minimum bandwidth is 10000 Kbit
Reliability 255/255, minimum MTU 1500 bytes
Loading 1/255, Hops 2
* 192.168.10.2, from 192.168.10.2, 00:04:42 ago, via Ethernet0/1
NOTE:
Set maximum-path to 1 to disable load balancing.

132April 24, 2020
Configure Task#6 EIGRP Unequal Cost Load Balancing using Variance
First let us remove the config for maximum-paths 2 from previous lab we configured:
TOKYOR7(config)#
router eigrp 1
no maximum-paths 2
Now, let us see the paths from TOKYOR7 towards destination network 4.4.4.4
TOKYOR7#show ip eigrp topology | sec 4.4.4.0
via 192.168.10.2 (435200/409600), Ethernet0/1
via 192.168.20.2 (435200/409600), Ethernet0/3
via 192.168.40.2 (435200/409600), Ethernet0/2
and Also, by default the Bandwidth of TOKYOR7_eth0/3 is:
TOKYOR7#show interface e0/3 | i BW
MTU 1500 bytes, BW 10000 Kbit/sec, DLY 1000 usec,

133April 24, 2020
Let us decrease the bandwidth of TOKYOR7_eth0/3 and set new BW = 5000
TOKYOR7(config)#
int e0/3
bandwidth 5000
!
We know that in EIGRP the path is influenced whenever the Metric for Outgoing interfaces gets
manipulated.
We see now only two best paths to reach destination 4.4.4.4
TOKYOR7#show ip route eigrp | sec 4.4.4.0
D 4.4.4.0 [90/435200] via 192.168.40.2, 00:00:40, Ethernet0/2
[90/435200] via 192.168.10.2, 00:00:40, Ethernet0/1
However, we see all three paths (including backup path) inside EIGRP’s Topology table to reach
destination 4.4.4.4
via 192.168.10.2 (435200/409600), Ethernet0/1
via 192.168.40.2 (435200/409600), Ethernet0/2
via 192.168.20.2 (691200/409600), Ethernet0/3
435200 → FD Feasible Distance (local router’s metric of the best route to reach a specific
network)
409600 → AD Advertised Distance (the metric advertised by the neighbouring router for a specific
route)
691200 →FS Feasible Successor (metric for backup route)
We’ll view this topology from TOKYOR7’s perspective. Let’s fill in the successor, feasible successor,
advertised and feasible distance in a table:
Advertised Distance Feasible distance
TOKYOR10 409600 435200 SUCCESSOR
TOKYOR29 409600 435200 SUCCESSOR
TOKYOR12 409600 691200 FEASIBLE
SUCCESSOR

134April 24, 2020
Now we are going to change things so we’ll see the feasible successor in the routing table as well so
it will load-balance.
So far so good, we found the TOKYOR10 & TOKYOR29 to be successor (435200) and we know that
TOKYOR12 is feasible successors (691200). If we want to enable load balancing, we have to use the
following formula:
FD of feasible successor < FD of successor * multiplier
You can make EIGRP to support unequal cost load-balancing by using the variance command. The
variance command works as a multiplier:
• Our successor has a feasible distance of 435200.
• Our feasible successor has a feasible distance of 691200
Variance = 691200 / 435200 = 1.588
This lab is to prove EIGRP supports unequal load-balancing.
We will configure the “variance” under EIGRP process:
TOKYOR7(config)#
router eigrp 1
variance 2
Let’s take a look at TOKYOR7 to see if this has any effect:
TOKYOR7# show ip route eigrp | sec 4.4.4.0
D 4.4.4.0 [90/435200] via 192.168.40.2, 00:00:10, Ethernet0/2
[90/691200] via 192.168.20.2, 00:00:10, Ethernet0/3
[90/435200] via 192.168.10.2, 00:00:10, Ethernet0/1
Above you can see that TOKYOR7 has installed the path through TOKYOR12 as well. EIGRP does
“unequal” cost load balancing and to see how it shares traffic among the interfaces we have to use
another command:
TOKYOR7#show ip route 4.4.4.4
Routing entry for 4.4.4.0/24
Known via "eigrp 1", distance 90, metric 435200, type internal
Redistributing via eigrp 1
Last update from 192.168.20.2 on Ethernet0/3, 00:01:20 ago
Routing Descriptor Blocks:
* 192.168.40.2, from 192.168.40.2, 00:01:20 ago, via Ethernet0/2

135April 24, 2020
As you can see EIGRP is sharing traffic in a 240:151:240 proportion as per Interface’s bandwidth.
Configure Task#7 EIGRP Manual Summarization
Auto Summarization is a feature, which allows Routing Protocols to summarize its routes to their
classful networks automatically. By default, EIGRP has auto summary feature enabled. Because of
this, routes are summarized to classful address at network boundaries in the routing updates.
This Lab is for testing Manual Summarization:
The manual summarization is a process of creating a summary route that will be used to represent
multiple routes and can be used to reduce the sizes of routing tables in a network.

136April 24, 2020
The cool thing about EIGRP and manual summarization is that it’s easy to do and can be done on the
interface-level.
Let us advertise a new network 4.5.5.0/24 in TOKYOR30 which we would consider later on for
performing manual summarization:
TOKYOR30(config)#
router eigrp 1
network 4.5.5.0
!
interface loopback 2
ip add 4.5.5.1 255.255.255.0
no shut
!
Now we see the new advertised network 4.5.5.0/24 on TOKYOR7
TOKYOR7#show ip route | sec 4.0.0.0
D 4.4.4.0 [90/435200] via 192.168.40.2, 00:10:11, Ethernet0/2
[90/691200] via 192.168.20.2, 00:10:11, Ethernet0/3
[90/435200] via 192.168.10.2, 00:10:11, Ethernet0/1
D 4.5.5.0 [90/435200] via 192.168.40.2, 00:00:57, Ethernet0/2
[90/691200] via 192.168.20.2, 00:00:57, Ethernet0/3
[90/435200] via 192.168.10.2, 00:00:57, Ethernet0/1
Let us manual summarize this:
In EIGRP we can summarize routes on every router that is participating in EIGRP network.
Manual summarization is configured on a per-interface basis on EIGRP.
TOKYOR7(config)#
interface e0/3
ip summary-address eigrp 1 4.0.0.0 255.0.0.0
*Aug 28 17:01:31.130: %DUAL-5-NBRCHANGE: EIGRP-IPv4 1: Neighbor 192.168.20.2
(Ethernet0/3) is resync: summary configured
Here is the summarized EIGRP routes:
4.0.0.0/8 is variably subnetted, 3 subnets, 2 masks
D 4.0.0.0/8 is a summary, 00:18:31, Null0
D 4.4.4.0/24 [90/435200] via 192.168.40.2, 01:19:33, Ethernet0/2
[90/691200] via 192.168.20.2, 01:19:33, Ethernet0/3
[90/435200] via 192.168.10.2, 01:19:33, Ethernet0/1
D 4.5.5.0/24 [90/435200] via 192.168.40.2, 01:10:19, Ethernet0/2
[90/691200] via 192.168.20.2, 01:10:19, Ethernet0/3
[90/435200] via 192.168.10.2, 01:10:19, Ethernet0/1

137April 24, 2020
TOKYOR7#show ip eigrp topology | i 4.4|4.0|4.5
via 192.168.10.2 (435200/409600), Ethernet0/1
via 192.168.40.2 (435200/409600), Ethernet0/2
via Summary (435200/0), Null0
via 192.168.10.2 (435200/409600), Ethernet0/1
via 192.168.40.2 (435200/409600), Ethernet0/2
via 192.168.40.2 (358400/332800), Ethernet0/2
via 192.168.10.2 (358400/332800), Ethernet0/1
Null0 is the interface where you send traffic that you want to black-hole. It’s called the Null
Adjacency.
Does this mean that all traffic to this network is lost? Nope. The null summary route is there to
prevent routing loops and wasting CPU cycles.
NOTE:
Null0 is the interface where you send traffic that you want to black-hole. It’s called the Null
Adjacency.
Does this mean that all traffic to this network is lost? Nope. The null summary route is there to
prevent routing loops and wasting CPU cycles.
Since we summarized the networks as 4.0.0.0/8 we are covering 4.6.x.x, 4.7.x.x and many more…
However, these networks don’t even exist! Instead of us forwarding traffic somewhere for these
networks, they go to the black-hole. If we were to route these somewhere and the packets return
to us, we would cause a routing loop (which would expire in transit but wastes cycles and
BW). Since the most exact route always wins, we know our packets for our real networks always
make it there. Routing traffic to NULL0 is very common, especially in BGP. If we somehow got
packets destined for e.g. 4.6.1.1, that traffic will be routed to us, and then sent to the Null
Adjacency, which drops it (This is done in hardware and doesn’t waste CPU cycles). If all of our
networks on the left somehow die or go away, the summary will still be alive assuming the
neighborship is. That is where the Null Adjacency can come in handy again.

138April 24, 2020
Configure Task#8 Manipulate Path Selection using K-values
NOTE:
EIGRP uses different K values to determine the best path to each destination:
K1
K2
K3
K4
K5
These K values are only numbers to scale numbers in the metric calculation. The formula we use
for the metric calculation looks like this:
Metric = [K1*bandwidth + ((K2*bandwidth)/(256-load))+K3*delay]
If K5 is not equal to 0:
Metric = Metric*[K5/(reliability+K4)]
If you look at the formula, you can see that the bandwidth, load, delay, and reliability influence
the metric. We can see what K values are enabled or disabled by default:
TOKYOR7#sh ip protocols | i K
Metric weight K1=1, K2=0, K3=1, K4=0, K5=0
In this example where we used the show ip protocols command, you can see which K-values are
enabled by default. Only K1 and K3 are enabled by default.

139April 24, 2020
Simplified EIGRP formula is:
Metric = [K1*bandwidth +K3*delay] * 256
Let’s walk through the different metric components to see what they are:
Bandwidth:
TOKYOR7#show interfaces e0/1 | i BW
If you use the show interface Ethernet 0/1 command you can see the interface information. The
example above only shows part of the output. You can see the bandwidth is 10000 Kbit which is a
10Mbit interface. We can change the bandwidth of an interface:
Router(config)#interface e0/0
Router(config-if)#bandwidth ?
<1-10000000> Bandwidth in kilobits
inherit Specify that bandwidth is inherited
receive Specify receive-side bandwidth
Router(config-if)#bandwidth 500
Load:
TOKYOR7#show interfaces e0/1 | i tx
reliability 255/255, txload 1/255, rxload 1/255
The load will show you how busy the interface is based on the packet rate and the bandwidth on
the interface. This is a value that can change over time so it’s a dynamic value.
Delay:
TOKYOR7#show interfaces e0/1 | i DLY
Delay reflects the time it will take for packets to cross the link and is a static value. Cisco IOS will
have default delay values for the different types of interface. An Ethernet interface has a default
delay of 1000 usec.
TOKYOR7(config)#
interface e0/1
delay 50

140April 24, 2020
Reliability:
TOKYOR7#show interfaces e0/1 | i rel
reliability 255/255, txload 1/255, rxload 1/255
Reliability at 255/255 is 100%. This means that you don’t have issues on the physical or data-link
layer. If you are having issues this value will decrease. Since this is something that can change it’s
a dynamic value.
MTU:
TOKYOR7#show interfaces e0/1 | i MTU
MTU or Maximum Transmission Unit is being exchanged between EIGRP neighbours but not used
for the metric calculation.
By default, only K1 and K3 are enabled and we don’t use K2 or K4. This means that only
bandwidth and delay are used in the formula.
Why not? Because loading and reliability are dynamic values and they can change over time. You
don’t want your EIGRP routers calculating 24/7 and sending updates to each other just because
the load or reliability of an interface has changed. We want routing protocols to be nice and quiet
and only base their routing decisions on static values like bandwidth and delay. If you only use
those two static values our EIGRP routers don’t have to do any recalculation unless an interface
goes down or a router died.
Since only K1 and K3 are enabled we can simplify the EIGRP formula:
Metric = bandwidth (slowest link) + delay (sum of delays)
• Bandwidth: [107
/ minimum bandwidth in the path] * 256.
• Delay: sums of delays in the path multiplied by 256 (in tens of microseconds).
So the formula looks like:
EIGRP Metric = [ (107
/ minimum bandwidth) + (sum of delays) ] * 256
The multiplication of 256 is done so EIGRP is compatible with IGRP (the predecessor of EIGRP).
Let us do some labbing now.

141April 24, 2020
From our Pre-checks we see:
TOKYOR7#show ip protocols | i K
From the above diagram, we are now lowering the Bandwidth of TOKYOR7_eth0/3
TOKYOR7(config)#
interface e0/3
bandwidth 5000
exit
!
This results to
D 4.4.4.0 [90/435200] via 192.168.40.2, 00:08:45, Ethernet0/2
[90/435200] via 192.168.10.2, 00:08:45, Ethernet0/1
Note: Path via 192.168.20.2 is taken out due to lower bandwidth set by us.
via 192.168.10.2 (435200/409600), Ethernet0/1
via 192.168.40.2 (435200/409600), Ethernet0/2
via 192.168.20.2 (691200/409600), Ethernet0/3

142April 24, 2020
Note: Path via 192.168.20.2 is Feasible Successor (backup path) now.
Also with the help of “variance” we can enable EIGRP’s unequal load-balancing.
However, let us change “K” values and make “bandwidth” to be ineffective for path calculation
and see what is the new result.
Let us manipulate the K values.
TOKYOR7(config)#
router eigrp 1
metric weights 0 0 0 1 0 0
(Ethernet0/3) is down: metric changed
(Ethernet0/3) is down: K-value mismatch
(Ethernet0/2) is down: K-value mismatch
NOTE:
The first value is for the TOS byte but as you can see it only supports a value of 0. The next values
are for the actual K values.
Let us enable the same K values on all the router and get them form “adjacencies”
TOKYOR10(config)#
router eigrp 1
TOKYOR29 (config)#
router eigrp 1
TOKYOR12(config)#
router eigrp 1
TOKYOR30(config)#
router eigrp 1
Let us check the routing table and topology table to understand how does K values influence the
path selection:

143April 24, 2020
D 4.4.4.0 [90/179200] via 192.168.40.2, 00:07:11, Ethernet0/2
[90/179200] via 192.168.20.2, 00:07:11, Ethernet0/3
[90/179200] via 192.168.10.2, 00:07:11, Ethernet0/1
via 192.168.10.2 (179200/153600), Ethernet0/1
via 192.168.20.2 (179200/153600), Ethernet0/3
via 192.168.40.2 (179200/153600), Ethernet0/2
TOKYOR7#show ip protocols | i K
NOTE:
So, you see on TOKYOR7, all three paths are preferred.
Even though we have TOKYOR7_eth0/3 configured to be 5000 kbps Bandwidth.
The reason for this path selection is we made K1 = 0 which makes bandwidth to be ineffective.
Wide EIGRP formula:
EIGRP METRIC = ([K1 * bandwidth + (K2 * bandwidth) / (256 - load) + K3 * delay] * [K5 / (reliability
+ K4)]) * 256
We made K1 = 0, so the metric formula simples to:
EIGRP METRIC = (K2 * bandwidth) * 256
Hence, we see all three paths to be best path inside routing table.
D 4.4.4.0 [90/179200] via 192.168.40.2, 00:07:11, Ethernet0/2
[90/179200] via 192.168.20.2, 00:07:11, Ethernet0/3
[90/179200] via 192.168.10.2, 00:07:11, Ethernet0/1
Note:
179200 = (updated!) FD as per considering just DLY on interfaces.
Bandwidth of interface is no more considered until we have K1 = 0.

Ccnp enterprise workbook v1.0 eigrp

More Related Content

What's hot (20)

Similar to Ccnp enterprise workbook v1.0 eigrp (20)

More from SagarR24 (20)

Recently uploaded (20)

Ccnp enterprise workbook v1.0 eigrp