){kind=link}
Physical Topology
Objectives
- Establish an experimental baseline with support for IPv4 and IPv6 in first hop redundancy.
- Establish a second baseline with support for DHCP redundancy and stronger authentication, as well as a consolidated and integrated FHRP solution for IPv4 and IPv6.
Background
Technologies are emerging and changing as rapidly as ever. Network administrators and network architects have difficult decisions regarding the implementation of technology upgrades while maintaining security, availability, reliability, and scalability. FHRP support for IPv6 is as important as it is for IPv4: HSRP and GLBP both have IPv6 implementations. GLBP has the advantage of built-in load balancing functionality. Finally, current Cisco IOS releases support HMAC-SHA-256 routing protocol authentication.
Less cutting-edge, but very practical solutions are also recommended for a network upgrade. Redundant DHCP servers improve reliability and availability for network users. MD5 authentication is supported for routing protocols on multilayer switches, as well as for first hop redundancy protocols on distribution and core layer devices.
To implement these technologies and solutions, two additional baselines, “Experimental BASE” and “Second BASE”, are recommended. These baselines are developed beginning with the original baseline.
In the end, the Second BASE network baseline will be well-positioned for the implementation of additional technologies to optimize network performance. GLBP supports weighted load balancing for active forwarding routers. Object tracking with IP SLAs extends FHRP redundancy options, compared to the more traditional solutions involving HSRP with interface tracking. And Cisco IPv6 implementations support options to improve performance in a redundant DHCP server environment.
For each task, the updated baseline specifications are described. Any troubleshooting that is required will stem from issues naturally arising during the implementation of the new technologies. As always, problems and solutions that present during network upgrades should be documented.
Physical and Logical Topology Diagrams
The new physical topology reflects a change to trunk links between the distribution and core devices. The Experimental BASE and Second BASE logical topologies presented at the beginning of each task include references and labeling to reflect updates with addressing, DHCP, FHRP, and protocol authentication.
The Experimental BASE logical topology describes the topology that results after completing Task 1. The Second BASE logical topology describes the topology that results after completing Task 2.
Note: This lab uses Cisco ISR G2 routers running Cisco IOS 15.4(3) images with IP Base and Security packages enabled, and Cisco Catalyst 3560 and 2960 switches running Cisco IOS 15.0(2) IP Services and LAN Base images, respectively. The 3560 and 2960 switches are configured with the SDM templates dual-ipv4-and-ipv6 routing and lanbase-routing, respectively. Depending on the router or switch model and Cisco IOS Software version, the commands available and output produced might vary from what is shown in this lab. Any changes made to the baseline configurations or topology (other than errors introduced) are noted in the trouble ticket so that you are aware of them prior to beginning the troubleshooting process.
Required Resources
- 3 routers (Cisco IOS Release 15.4 or comparable)
- 2 multilayer switches and 1 access layer switch (Cisco IOS Release 15.0(2) or comparable with Fast Ethernet interfaces)
- SRV1 (PC with static IP address): Windows 7 with RADIUS, TFTP, and syslog servers, plus an SSH client, SNMP monitor, and WireShark software
- PC-B (DHCP client): Windows 7 with SSH client and WireShark software
- PC-C (DHCP client): Windows 7 with SSH client and WireShark software
- Serial and Ethernet cables, as shown in the topology
Task 1: Network Baseline Upgrade Lab 5-1 TT-A
Logical Topology (Experimental Base)
Step 1: Review requirements ticket Lab 5-1 TT-A.
Your company network is already running a dual stack environment. But there is currently no FHRP support for IPv6. The directive to you is to implement a two-stage migration plan with several objectives. In this first stage, the distribution-to-core layer links change to trunks, as indicated in the logical topology. HSRP for IPv6 is to be implemented at the distribution layer and GLBP for IPv4 is to be implemented at the core layer – FHRP VLAN priorities defined by the BASE configuration are maintained. Additional IPv4 excluded addresses are necessary to accommodate the addressing changes.
You have the following tasks:
- Remove the HSRPv1 for IPv4 configurations.
- Configure HSRP for IPv6 on DLS1 and DLS2 SVIs 99, 100, 110, 120, and 200.
- Exclude additional IPv4 addresses for DHCP to accommodate the addressing changes specified in the logical topology.
- Change the routed links between the distribution and core layers to trunk links, using the addressing specified in the logical topology.
- Configure GLBP on R1 and R3 for IPv4 on VLANs 99, 100, 110, 120, and 200.
- Verify the DHCP, FHRP, and EIGRP functionality.
Step 2: Load the pre-upgrade configuration files for TT-A.
Using the procedure described in the BASE Lab, verify that the lab configuration files are present in flash. Load the proper configuration files indicated in the Device Configuration File Table.
Device Configuration File Table (pre-upgrade)
| Device Name | File to Load | Notes |
|---|---|---|
| ALS1 | Lab51-ALS1-TT-A-Cfg.txt | |
| DLS1 | Lab51-DLS1-TT-A-Cfg.txt | |
| DLS2 | Lab51-DLS2-TT-A-Cfg.txt | |
| R1 | Lab51-R1-TT-A-Cfg.txt | |
| R2 | Lab51-R2-TT-A-Cfg.txt | |
| R3 | Lab51-R3-TT-A-Cfg.txt | |
| SRV1 | N/A | Static IP: 10.1.100.1 and 2001:DB8:CAFE:100::1 Default gateway: 10.1.100.254/24 and 2001:DB8:CAFE:100::D1/64 |
| PC-B | N/A | DHCPv4 and DHCPv6 |
| PC-C | N/A | DHCPv4 and DHCPv6 |
Step 3: Remove HSRP Version 1.
On DLS1 and DLS2, remove all configuration commands pertaining to HSRP. If any existing HSRP commands are present when implementing HSRP for IPv6, errors will result. To speed up the process, you can copy the SVI portions of the show run output into Notepad, delete the interface commands unrelated to HSRP, prepend each HSRP command with no, and paste the resulting configuration sequence back into global configuration mode; this same Notepad text can be edited in Step 4, if desired, to speed up the configuration of HSRP for IPv6 on the SVIs.
Step 4: Implement HSRP for IPv6.
a. HSRP for IPv6 requires HSRPv2 to be enabled on an interface. For SVI 99, 100, 110, 120, and 200, enter the interface configuration mode command standby version 2. Note that HSRPv2 is an IPv4-specific FHRP which serves as an upgraded version of HSRPv1.
b. On each SVI, enter the command standby x ipv6 autoconfig where x is the VLAN number. This command indicates that a virtual link-local IPv6 address will be generated automatically from the link-local prefix, FE80:/64, and a modified EUI-64 format interface identifier, where the EUI-64 interface identifier is created from the relevant HSRP for IPv6 virtual MAC address, which has the form 0005.73A0.0xyz (there are 163 = 4096 possible HSRP IPv6 groups). For example, 0005.73A0.0063 is the virtual MAC address for group 99 because 99 in hexadecimal is 63; the associated EUI-64 interface identifier is 0005.73FF.FEA0.0063 (the seventh bit in the EUI-64 address is not flipped because the interface identifier is locally administered); so the virtual link-local IPv6 address is FE80::0005:73FF:FEA0:0063.
The remaining SVI commands are configured exactly the same as in HSRPv1. For example, for SVI 99 on DLS1:
standby 99 priority 110 standby 99 preempt
c. Verify the configuration. DLS1 output shows the HSRP for IPv6 active routers:
DLS1# show standby brief
P indicates configured to preempt.
|
Interface Grp Pri P State Active Standby Virtual IP
Vl99 99 110 P Active local FE80::D2 FE80::5:73FF:FEA0:63
Vl100 100 100 P Standby FE80::D2 local FE80::5:73FF:FEA0:64
Vl110 110 110 P Active local FE80::D2 FE80::5:73FF:FEA0:6E
Vl120 120 110 P Active local FE80::D2 FE80::5:73FF:FEA0:78
Vl200 200 100 P Standby FE80::D2 local FE80::5:73FF:FEA0:C8
More detail is shown here for SVI 99 on DLS1:
DLS1# show standby vlan 99
Vlan99 - Group 99 (version 2)
State is Active
2 state changes, last state change 00:40:52
Link-Local Virtual IPv6 address is FE80::5:73FF:FEA0:63 (conf auto EUI64)
Active virtual MAC address is 0005.73a0.0063
Local virtual MAC address is 0005.73a0.0063 (v2 IPv6 default)
Hello time 3 sec, hold time 10 sec
Next hello sent in 1.632 secs
Preemption enabled
Active router is local
Standby router is FE80::D2, priority 100 (expires in 11.008 sec)
Priority 110 (configured 110)
Group name is "hsrp-Vl99-99" (default)
d. Change the IPv6 address on SRV1 to 2001:DB8:CAFE:100::5. Change the IPv6 default gateway on SRV1 to the virtual IPv6 address for VLAN 100: FE80::5:73FF:FEA0:64. Verify with an IPv6 ping to 2001:DB8:EFAC::2 (Lo1 on R2) that there is connectivity to the Internet from SRV1.
e. PC-B and PC-C lose IPv4 connectivity because their respective IPv4 default gateways are still the HSRPv1 virtual IP addresses for the associated VLANs.
f. Change the IPv6 default route on ALS1 to point to the virtual IP for VLAN 99, FE80::5:73FF:FEA0:63:
ALS1(config)# ipv6 route ::/0 VLAN99 FE80::5:73FF:FEA0:63
g. IPv6 connectivity for PC-B and PC-C should be functional (if necessary, perform a NIC reset).
h. Perform a continuous IPv6 ping from PC-B to the Internet (Lo1 on R2) and simulate a failure of the active router:
DLS1(config)# interface range f0/1-4 DLS1(config-if-range)# shutdown
Only a few ICMP request timeouts should occur during failover to DLS2.
Step 5: Exclude DHCPv4 addresses to be configured on the G0/1 subinterfaces of R1 and R3.
G0/1 on R1 and R3 requires subinterfaces corresponding to VLANs 99, 100, 110, 120, 200, and 666 (NATIVE). Each of the corresponding addresses ending in .1 and .3 must be excluded from use by DHCPv4 on DLS1. Extend the set of excluded addresses on DLS1 to include the first five addresses:
ip dhcp excluded-address 10.1.110.1 10.1.110.5 ip dhcp excluded-address 10.1.120.1 10.1.120.5 ip dhcp excluded-address 10.1.200.1 10.1.200.5
The SRV1 address 10.1.100.1 and configuration references to 10.1.100.1 will soon be replaced by 10.1.100.5.
Step 6: Change the routed links to trunk links between the core and distribution layers.
a. On DLS1 and DLS2 port F0/5, enter the command command switchport. The IPv4 and IPv6 configuration commands are automatically removed. Enter the trunk commands commands to complete the configuration on the multilayer switches:
switchport trunk encapsulation dot1q switchport trunk allowed vlan 99,100,110,120,200 switchport mode trunk switchport nonegotiate
b. On R1 and R3 interface G0/1, remove the IPv4 and IPv6 addressing.
c. On R1 and R3, create the the native VLAN subinterface. Here is the R1 configuration:
R1(config)# interface g0/1.666 R1(config-subif)# encapsulation dot1q 666 native
d. On R1 and R3, create the subinterfaces for VLANs 99, 100, 110, 120, and 200. For example, configure R1 with a subinterface associated with VLAN 99 as follows:
R1(config)# interface g0/1.99 R1(config-subif)# encapsulation dot1q 99 R1(config-subif)# ip address 10.1.99.1 255.255.255.0 R1(config-subif)# ipv6 address fe80::1 link-local R1(config-subif)# ipv6 address 2001:DB8:CAFE:99::1/64
Because Classic EIGRP is already configured on the distribution switch SVIs and Named EIGRP is already configured on the core routers, the IPv4 and IPv6 EIGRP adjacencies will automatically form! Note that there are now four EIGRP multi-access neighbors on each VLAN (99, 100, 110, 120, and 200). The subinterface IPv4 and IPv6 addresses on DLS2 end with .3 and ::3, respectively, as seen in the logical topologies at the beginning of Task 1 (TT-A).
Step 7: Implement GLBP for IPv4.
a. GLBP supports IPv4 and IPv6. In this, the first stage of the network baseline upgrade, GLBP will only be used for IPv4 support. Configure GLBP for IPv4 on subinterfaces 99, 100, 110, 120, and 200 of G0/0 of R1 and R3, with the same priorities that are used with HSRP for IPv6. Use the VLAN number for the GLBP-for-IPv4 group number. For example, here are the required GLBP commands for VLAN 99
interface GigabitEthernet0/1.99 glbp 99 ip 10.1.99.254 glbp 99 priority 110 glbp 99 preempt
and the required GLBP commands for VLAN 100
interface GigabitEthernet0/1.100 glbp 100 ip 10.1.100.254 glbp 100 preempt
b. After completing the GLBP configuration, verify the AVG and AVF status. For example, the output
R1# show glbp gigabitEthernet 0/1.99 brief Interface Grp Fwd Pri State Address Active router Standby router Gi0/1.99 99 - 110 Active 10.1.99.254 local 10.1.99.3 Gi0/1.99 99 1 - Listen 0007.b400.6301 10.1.99.3 - Gi0/1.99 99 2 - Active 0007.b400.6302 local -
shows that
- R1 is the AVG for VLAN 99
- R1 is currently an AVF for the GLBP virtual MAC address 0007.b400.6302: R1 serves as the default gateway for hosts that receive ARP replies from the AVG with virtual MAC address 0007.b400.6302 – note that your output may be reversed by the nature of GLBP’s round-robin behavior, with R1 the AVF associated with MAC address 0007.b400.6301
- R3 (we can infer) is currently an AVF for the GLBP virtual MAC address 0007.b400.6301: R3 serves as the default gateway for hosts that receive ARP replies from the AVG with virtual MAC address 0007.b400.6301 – note that your output may be reversed by the nature of GLBP’s round-robin behavior, with R3 the AVF associated with MAC address 0007.b400.6302
Because weighting has not been configured, GLBP uses the default method, round-robin, resulting in one AVF for each virtual MAC address. If weighting were configured, R1 and R3 could both be AVFs for each virtual MAC address.
c. After releasing and renewing, the IPv4 addresses for PC-B and PC-C should now be in the new excluded ranges for DHCPv4. Verify Internet IPv4 connectivity from PC-B and PC-C.
d. Change the IPv4 static IP address on SRV1 to 10.1.100.5/24 to remove the IP address conflict with G0/1.100 on R1! Verify Internet IPv4 connectivity from SRV1.
e. Replace all instances of archiving, syslog, and SNMP commands containing “10.1.100.1” on all devices with “10.1.100.5”. Restart the program(s) on SRV1 that handle archiving, syslog, and SNMP. Verify that archiving, syslog, and SNMP are operating correctly.
f. Verify GLBP failover by performing a continuous IPv4 ping to the Internet from PC-B and SRV1 and shutting down G0/1 on R1. Only a few ICMP echo requests should time out during failover and recovery.
Note: The configuration files to be loaded on the devices in Task 2 are obtained from the configuration files of the devices at the end of Task 1. So one option is to continue at this point with Task 2 using the configurations obtained by completing Task 1 (without loading the configuration files for TT-B).
Task 2: Network Baseline Upgrade Lab 5-1 TT-B
Logical Topology (Second BASE)
Step 1: Review requirements ticket Lab 5-1 TT-B.
Some noticeable improvements in redundancy are now in place with the completion of stage one of the network baseline upgrade (Experimental BASE). However, network technicians are reporting that some of the failover behaviors and DHCP allocation behaviors are inconsistent. In order to provide a more reliable solution for the employees, it is time to implement the second stage of the network baseline upgrade (Second BASE).
Both IPv4 and IPv6 FHRP redundancy will be handled by the core routers with GLBP. DLS2 will serve as a redundant DHCP server for IPv4 and IPv6 to improve DHCP allocation performance and consistency. Route authentication will be implemented on core and distribution devices to complete the network baseline upgrade. And FHRP authentication for both IPv4 and IPv6 will be implemented. The new baseline will put the network in a ready position for additional improvements, such as weighted load balancing and object tracking with IP SLAs.
Beginning with the Experimental BASE, you have the following tasks:
- Remove the HSRP for IPv6 configurations.
- Configure GLBP for IPv6 on R1 and R3 for VLANs 99, 100, 110, 120, and 200.
- Verify the GLBP functionality for both IPv4 and IPv6. Add 400 to the GLBP-for-IPv4 group numbers to obtain the GLBP-for-IPv6 group numbers.
- Configure DLS2 as a redundant DHCP server for IPv4 and IPv6.
- Configure MD5 route authentication for EIGRP at the at the distribution layer, and between the distribution and core devices. Configure HMAC-SHA-256 authentication for EIGRP between the core devices.
- Configure GLBP MD5 authentication for IPv4 and IPv6.
- Verify GLBP and EIGRP functionality.
Step 2: Load the Experimental BASE configuration files for TT-B.
Using the procedure described in the BASE Lab, verify that the lab configuration files are present in flash. Load the proper configuration files indicated in the Device Configuration File Table.
Device Configuration File Table (from Experimental BASE)
| Device Name | File to Load | Notes |
|---|---|---|
| ALS1 | Lab51-ALS1-TT-B-Cfg.txt | |
| DLS1 | Lab51-DLS1-TT-B-Cfg.txt | |
| DLS2 | Lab51-DLS2-TT-B-Cfg.txt | |
| R1 | Lab51-R1-TT-B-Cfg.txt | |
| R2 | Lab51-R2-TT-B-Cfg.txt | |
| R3 | Lab51-R3-TT-B-Cfg.txt | |
| SRV1 | N/A | Static IP: 10.1.100.5 and 2001:DB8:CAFE:100::5 Default gateway: 10.1.100.254 and FE80::5:73FF:FEA0:64 |
| PC-B | N/A | DHCPv4 and DHCPv6 |
| PC-C | N/A | DHCPv4 and DHCPv6 |
Step 3: Configure SRV1 and start the syslog and TFTP servers.
Note that the static IP address has changed for SRV1 to 10.1.100.5 because R1 G0/1.100 now has the IP address 10.1.100.1. The IPv6 address and gateway on SRV1 are indicated in the table above; recall that the gateway IPv6 address is the HSRP virtual IPv6 address for VLAN 100.
Step 4: Remove HSRP for IPv6.
On DLS1 and DLS2, remove all configuration commands pertaining to HSRP.
Step 5: Implement GLBP for IPv6.
a. GLBP is the only FHRP option that simultaneously supports IPV4 and IPv6 redundancy on the same interface. The distribution layer devices do not support GLBP. The core routers support GLBP. Configure GLBP for IPv6 on the subinterfaces of R1 and R3 corresponding to VLANs 99, 100, 110, 120, and 200. The same group number cannot be used for IPv4 and IPv6: the network design prescribes adding 400 to each GLBP-for-IPv4 group number to obtain the respective GLBP-for-IPv6 group number. Use the same priorities as were configured for GLBP for IPv4 (from Experimental BASE).
To illustrate, the IPv6 GLBP configuration for G0/1.99 on R1 introduces GLBP virtual IPv6 autoconfiguration, raises the default priority of 100 to 110, and implements preemptive AVG election:
interface GigabitEthernet0/1.99 glbp 499 ipv6 autoconfig glbp 499 priority 110 glbp 499 preempt
The autoconfig keyword indicates that a virtual link-local IPv6 address for each AVF will be generated automatically from the link-local prefix, FE80:/64, and a modified EUI-64 format interface identifier, where the EUI-64 interface identifier is created from the relevant GLBP virtual MAC address. For example, 0007.B401.F302 is the virtual MAC address for AVF2 of GLBP group 499 in the GLBP format because 499 in hexadecimal is 1F3, so the virtual link-local IPv6 address for AFV2 is FE80::7:B4FF:FE01:F300. This is the virtual IP address for all AVFs in GLBP group 499 (a GLBP group can have up to four AVFs).
For another illustration, the IPv6 GLBP configuration on G0/1.200 of R3 is consistent with that for IPv4:
interface GigabitEthernet0/1.200 glbp 600 ipv6 autoconfig glbp 600 priority 110 glbp 600 preempt
b. Verify the IPv6 GLBP configuration. For example, since 600 in hexadecimal is 258, the output
R3# show glbp brief | include 600 Gi0/1.200 600 - 110 Active FE80::7:B4FF:FE02:5800 Gi0/1.200 600 1 - Active 0007.b402.5801 FE80::3 - Gi0/1.200 600 2 - Listen 0007.b402.5802 local
indicates that the virtual IP address for AVFs in VLAN 200 is FE80::7:B4FF:FE02:5800, and that R3 is the AVG for IPv6 GLBP group 600.
c. Change the IPv6 default gateway on SRV1 to FE80::7:B4FF:FE01:F400, the GLBP virtual IPv6 address for VLAN 100.
d. Change the default route on ALS1 to point to FE80::7:B4FF:FE01:F300, the GLBP virtual IPv6 address for VLAN 99.
e. Release and renew the IPv4/6 configurations on PC-B and PC-C. Verify that PC-B and PC-C have full IPv4/6 connectivity.
f. Verify that SRV1 has full IPv4/6 connectivity.
g. Test IPv4 and IPv6 failover by performing simultaneous continuous pings from two command prompts on SRV1 to 2.2.2.2 and 2001:DB8:ECAF::2 and then shutting down interface G0/1 on R3. Failover should result in the timeout of just a few ICMP echo requests. Upon bringing G0/1 back up the network reconvergence will result in more timeouts.
h. Generate a continuous ping to 2.2.2.2 from PC-B and a continuous ping from PC-C to 2001:DB8:EFAC::2 and then shut down interface G0/1 on R1. The results should be similar to that from SRV1.
Step 6: Configure DHCP redundancy for IPv4 and IPv6.
a. Configure DLS2 as a redundant DHCP server. For the DHCPv6 configuration on DLS2, the DHCPv6 configuration on DLS1 can be copied onto DLS2. For the DHCPv4 configuration on DLS2, configure the address space so that addresses are allocated from 10.1.x.129 through 10.1.x.250 on VLANs 110, 120, and 200. To this end, paste the following command sequence into global configuration mode on DLS2:
ip dhcp excluded-address 10.1.120.251 10.1.120.254 ip dhcp excluded-address 10.1.200.251 10.1.200.254 ip dhcp excluded-address 10.1.110.251 10.1.110.254 ip dhcp excluded-address 10.1.110.1 10.1.110.128 ip dhcp excluded-address 10.1.120.1 10.1.120.128 ip dhcp excluded-address 10.1.200.1 10.1.200.128 ! ip dhcp pool VOICE network 10.1.200.0 255.255.255.0 default-router 10.1.200.254 ! ip dhcp pool GUEST network 10.1.110.0 255.255.255.0 default-router 10.1.110.254 ! ip dhcp pool OFFICE network 10.1.120.0 255.255.255.0 default-router 10.1.120.254 ! ipv6 unicast-routing ipv6 dhcp pool DHCPv6OFFICE address prefix 2001:DB8:CAFE:120:ABCD::/80 domain-name tshoot.net ! ipv6 dhcp pool DHCPv6VOICE address prefix 2001:DB8:CAFE:200:ABCD::/80 domain-name tshoot.net ! ipv6 dhcp pool DHCPv6GUEST address prefix 2001:DB8:CAFE:110:ABCD::/80 domain-name tshoot.net ! interface Vlan110 ipv6 dhcp server DHCPv6GUEST ! interface Vlan120 ipv6 dhcp server DHCPv6OFFICE ! interface Vlan200 ipv6 dhcp server DHCPv6VOICE
If you have not already, increase the line delay in your terminal emulator to at least 100 ms to avoid a buffer overflow, resulting in some commands not being processed when you paste this configuration into global configuration mode of DLS2.
b. On DLS1, add the following lines:
ip dhcp excluded-address 10.1.120.129 10.1.120.250 ip dhcp excluded-address 10.1.200.129 10.1.200.250 ip dhcp excluded-address 10.1.110.129 10.1.110.250
At this point, the addresses that DLS1 can allocate are:
10.1.110.6 to 10.1.110.128 10.1.120.6 to 10.1.120.128 10.1.200.6 to 10.1.200.128
And the addresses that DLS2 can allocate are:
10.1.110.129 to 10.1.110.250 10.1.120.129 to 10.1.120.250 10.1.200.129 to 10.1.200.250
The specifications for the IPv6 Neighbor Discovery Protocol (NDP) include the duplicate address detection feature (DAD) to ensure that hosts are assigned unique IPv6 addresses. Note that the DHCPv6 address pool for each VLAN has over a trillion addresses.
Now, DLS1 allocates addresses from the first half of the IPv4 address space in each VLAN and DLS2 allocates addresses in the second half of the IPv4 address space in each VLAN.
This completes the implementation of redundant DHCP servers for the network.
Step 7: Configure MD5 route authentication for EIGRP within the distribution layer and between the distribution layer and the core layer.
a. Rotation of keys is enabled by the use of key chains. Each key is valid for the period defined by the accept-lifetime and send-lifetime commands. Set the clock on the NTP master so that the time is current. The setting here is just an example:
R2# clock set 09:05:00 Oct 29 2014
Create key chains on DLS1, DLS2, R1, and R3, starting in global configuration mode:
key chain morphism key 3 key-string finite accept-lifetime 00:00:00 Jun 1 2014 00:00:00 Sep 12 2015 send-lifetime 00:00:00 Jun 1 2014 00:00:00 Aug 12 2015 key 4 key-string smooth accept-lifetime 00:00:00 Aug 12 2015 00:00:00 Dec 12 2016 send-lifetime 00:00:00 Sep 12 2015 00:00:00 Nov 12 2016 key 5 key-string flat accept-lifetime 00:00:00 Nov 12 2016 00:00:00 Mar 12 2017 send-lifetime 00:00:00 Dec 12 2016 00:00:00 Feb 12 2017
The key lifetimes for the keys in the key chain overlap to avoid neighbor authentication failure during a transition between keys.
Note: The key lifetimes on the distribution and core devices require the correct date and time for EIGRP operation. If the current time does not fall in the range June 1, 2014 to February 12, 2017, EIGRP will not converge – in this case, add a fixed number n as appropriate to each year appearing above (six times) so that the resulting time ranges encompass the current time.
b. On each of SVI 99, 100, 110, 120, and 200 of DLS1 and DLS2, enter the following four commands:
ip authentication mode eigrp 1 md5 ip authentication key-chain eigrp 1 morphism ipv6 authentication mode eigrp 1 md5 ipv6 authentication key-chain eigrp 1 morphism
c. On R1 and R3 configure the following commands, starting from global configuration mode:
router eigrp HQ address-family ipv4 unicast autonomous-system 1 af-interface g0/1.99 authentication key-chain morphism authentication mode md5 exit-af-interface af-interface g0/1.100 authentication key-chain morphism authentication mode md5 exit-af-interface af-interface g0/1.110 authentication key-chain morphism authentication mode md5 exit-af-interface af-interface g0/1.120 authentication key-chain morphism authentication mode md5 exit-af-interface af-interface g0/1.200 authentication key-chain morphism authentication mode md5 exit-af-interface exit-address-family ! address-family ipv6 unicast autonomous-system 1 af-interface g0/1.99 authentication key-chain morphism authentication mode md5 exit-af-interface af-interface g0/1.100 authentication key-chain morphism authentication mode md5 exit-af-interface af-interface g0/1.110 authentication key-chain morphism authentication mode md5 exit-af-interface af-interface g0/1.120 authentication key-chain morphism authentication mode md5 exit-af-interface af-interface g0/1.200 authentication key-chain morphism authentication mode md5 exit-af-interface exit-address-family
Step 8: Configure HMAC-SHA-256 route authentication for EIGRP within the core layer.
On R1, R2, and R3, configure the following commands, starting from global configuration mode:
key chain manifold key 0 key-string riemannian accept-lifetime 00:00:00 Jun 1 2014 00:00:00 Sep 12 2015 send-lifetime 00:00:00 Jun 1 2014 00:00:00 Aug 12 2015 key 1 key-string symplectic accept-lifetime 00:00:00 Aug 12 2015 00:00:00 Dec 12 2016 send-lifetime 00:00:00 Sep 12 2015 00:00:00 Nov 12 2016 key 2 key-string lie-group accept-lifetime 00:00:00 Nov 12 2016 00:00:00 Mar 12 2017 send-lifetime 00:00:00 Dec 12 2016 00:00:00 Feb 12 2017 ! router eigrp HQ address-family ipv4 unicast autonomous-system 1 af-interface s0/0/0 authentication mode hmac-sha-256 scheme authentication key-chain manifold exit-af-interface af-interface s0/0/1 authentication mode hmac-sha-256 scheme authentication key-chain manifold exit-af-interface exit-address-family address-family ipv6 unicast autonomous-system 1 af-interface s0/0/0 authentication mode hmac-sha-256 scheme authentication key-chain manifold exit-af-interface af-interface s0/0/1 authentication mode hmac-sha-256 scheme authentication key-chain manifold exit-af-interface exit-address-family
Note that authentication commands on the unused interfaces S0/0/1 of R1 and S0/0/0 of R3 is for future use.
This completes the configuration of EIGRP route authentication for Second BASE.
Step 8: Configure GLBP MD5 authentication for IPv4 and IPv6.
On R1 and R3 configure the following commands, starting from global configuration mode:
interface GigabitEthernet0/1.99 glbp 99 authentication md5 key-chain morphism glbp 499 authentication md5 key-chain morphism ! interface GigabitEthernet0/1.100 glbp 100 authentication md5 key-chain morphism glbp 500 authentication md5 key-chain morphism ! interface GigabitEthernet0/1.110 glbp 110 authentication md5 key-chain morphism glbp 510 authentication md5 key-chain morphism ! interface GigabitEthernet0/1.120 glbp 120 authentication md5 key-chain morphism glbp 520 authentication md5 key-chain morphism ! interface GigabitEthernet0/1.200 glbp 200 authentication md5 key-chain morphism glbp 600 authentication md5 key-chain morphism
The same keys are used for GLBP as are used for route authentication between the distrubtion and core devices.
Step 9: Verify EIGRP and GLBP functionality.
a. There are many ways to verify EIGRP functionality. DLS1 has all IPv4 and IPv6 EIGRP routes:
DLS1# show ip route eigrp
b. There are many ways to verify GLBP functionality. R1 has a complete GLBP solution for IPv4 and IPv6:
R1# show glbp brief
Interface Grp Fwd Pri State Address Active router Standby router
Gi0/1.99 99 - 110 Active 10.1.99.254 local 10.1.99.3
Gi0/1.99 99 1 - Listen 0007.b400.6301 10.1.99.3 -
Gi0/1.99 99 2 - Active 0007.b400.6302 local -
Gi0/1.99 499 - 110 Active FE80::7:B4FF:FE01:F300
local FE80::3
Gi0/1.99 499 1 - Active 0007.b401.f301 local -
Gi0/1.99 499 2 - Listen 0007.b401.f302 FE80::3 -
Gi0/1.100 100 - 100 Standby 10.1.100.254 10.1.100.3 local
Gi0/1.100 100 1 - Active 0007.b400.6401 local -
Gi0/1.100 100 2 - Listen 0007.b400.6402 10.1.100.3 -
Gi0/1.100 500 - 100 Standby FE80::7:B4FF:FE01:F400
FE80::3 local
Gi0/1.100 500 1 - Listen 0007.b401.f401 FE80::3 -
Gi0/1.100 500 2 - Active 0007.b401.f402 local -
Gi0/1.110 110 - 110 Active 10.1.110.254 local 10.1.110.3
Gi0/1.110 110 1 - Listen 0007.b400.6e01 10.1.110.3 -
Gi0/1.110 110 2 - Active 0007.b400.6e02 local -
Gi0/1.110 510 - 110 Active FE80::7:B4FF:FE01:FE00
local FE80::3
Gi0/1.110 510 1 - Active 0007.b401.fe01 local -
Gi0/1.110 510 2 - Listen 0007.b401.fe02 FE80::3 -
Gi0/1.120 120 - 110 Active 10.1.120.254 local 10.1.120.3
Gi0/1.120 120 1 - Listen 0007.b400.7801 10.1.120.3 -
Gi0/1.120 120 2 - Active 0007.b400.7802 local -
Gi0/1.120 520 - 110 Active FE80::7:B4FF:FE02:800
local FE80::3
Gi0/1.120 520 1 - Active 0007.b402.0801 local -
Gi0/1.120 520 2 - Listen 0007.b402.0802 FE80::3 -
Gi0/1.200 200 - 100 Standby 10.1.200.254 10.1.200.3 local
Gi0/1.200 200 1 - Active 0007.b400.c801 local -
Gi0/1.200 200 2 - Listen 0007.b400.c802 10.1.200.3 -
Gi0/1.200 600 - 100 Standby FE80::7:B4FF:FE02:5800
FE80::3 local
Gi0/1.200 600 1 - Listen 0007.b402.5801 FE80::3 -
Gi0/1.200 600 2 - Active 0007.b402.5802 local -
This completes Task 2, creating Second BASE. This baseline will be reused in some other TSHOOT labs.