CCNP TSHOOT Chapter 5 Lab 5-1, Second Base (Version 7)

Physical Topology

CCNP TSHOOT Chapter 5 Lab 5-1, Second Base (Version 7) 1

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)

CCNP TSHOOT Chapter 5 Lab 5-1, Second Base (Version 7) 2

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)

CCNP TSHOOT Chapter 5 Lab 5-1, Second Base (Version 7) 3

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

D     2.0.0.0/8 [90/2170144] via 10.1.100.3, 01:08:11, Vlan100
                [90/2170144] via 10.1.100.1, 01:08:11, Vlan100
                [90/2170144] via 10.1.99.3, 01:08:11, Vlan99
                [90/2170144] via 10.1.99.1, 01:08:11, Vlan99
      10.0.0.0/8 is variably subnetted, 19 subnets, 3 masks
D        10.1.1.0/30 [90/2170112] via 10.1.200.1, 01:08:11, Vlan200
                     [90/2170112] via 10.1.110.1, 01:08:11, Vlan110
                     [90/2170112] via 10.1.100.1, 01:08:11, Vlan100
                     [90/2170112] via 10.1.99.1, 01:08:11, Vlan99
D        10.1.1.1/32 [90/2682112] via 10.1.200.3, 01:08:09, Vlan200
                     [90/2682112] via 10.1.110.3, 01:08:09, Vlan110
                     [90/2682112] via 10.1.100.3, 01:08:09, Vlan100
                     [90/2682112] via 10.1.99.3, 01:08:09, Vlan99
D        10.1.1.2/32 [90/2170112] via 10.1.200.1, 01:08:11, Vlan200
                     [90/2170112] via 10.1.110.1, 01:08:11, Vlan110
                     [90/2170112] via 10.1.100.1, 01:08:11, Vlan100
                     [90/2170112] via 10.1.99.1, 01:08:11, Vlan99
D        10.1.1.4/30 [90/2170112] via 10.1.200.3, 01:08:09, Vlan200
                     [90/2170112] via 10.1.110.3, 01:08:09, Vlan110
                     [90/2170112] via 10.1.100.3, 01:08:09, Vlan100
                     [90/2170112] via 10.1.99.3, 01:08:09, Vlan99
D        10.1.1.5/32 [90/2682112] via 10.1.200.1, 01:08:11, Vlan200
                     [90/2682112] via 10.1.110.1, 01:08:11, Vlan110
                     [90/2682112] via 10.1.100.1, 01:08:11, Vlan100
                     [90/2682112] via 10.1.99.1, 01:08:11, Vlan99
D        10.1.1.6/32 [90/2170112] via 10.1.200.3, 01:08:09, Vlan200
                     [90/2170112] via 10.1.110.3, 01:08:09, Vlan110
                     [90/2170112] via 10.1.100.3, 01:08:09, Vlan100
                     [90/2170112] via 10.1.99.3, 01:08:09, Vlan99
D        10.1.201.1/32 [90/2848] via 10.1.200.1, 01:08:11, Vlan200
                       [90/2848] via 10.1.110.1, 01:08:11, Vlan110
                       [90/2848] via 10.1.100.1, 01:08:11, Vlan100
                       [90/2848] via 10.1.99.1, 01:08:11, Vlan99
D        10.1.202.1/32 [90/2170144] via 10.1.100.3, 01:08:11, Vlan100
                       [90/2170144] via 10.1.100.1, 01:08:11, Vlan100
                       [90/2170144] via 10.1.99.3, 01:08:11, Vlan99
                       [90/2170144] via 10.1.99.1, 01:08:11, Vlan99
D        10.1.203.1/32 [90/2848] via 10.1.200.3, 01:08:09, Vlan200
                       [90/2848] via 10.1.110.3, 01:08:09, Vlan110
                       [90/2848] via 10.1.100.3, 01:08:09, Vlan100
                       [90/2848] via 10.1.99.3, 01:08:09, Vlan99
DLS1# show ipv6 route eigrp

D   2001:DB8:CAFE:10::/64 [90/2170112]
     via FE80::1, Vlan99
     via FE80::1, Vlan120
     via FE80::1, Vlan100
     via FE80::1, Vlan110
     via FE80::1, Vlan200
D   2001:DB8:CAFE:14::/64 [90/2170112]
     via FE80::3, Vlan99
     via FE80::3, Vlan100
     via FE80::3, Vlan110
     via FE80::3, Vlan200
     via FE80::3, Vlan120
D   2001:DB8:CAFE:201::/64 [90/2848]
     via FE80::1, Vlan99
     via FE80::1, Vlan120
     via FE80::1, Vlan100
     via FE80::1, Vlan110
     via FE80::1, Vlan200
D   2001:DB8:CAFE:202::/64 [90/2170144]
     via FE80::1, Vlan99
     via FE80::3, Vlan99
     via FE80::1, Vlan120
     via FE80::1, Vlan100
     via FE80::3, Vlan100
     via FE80::1, Vlan110
     via FE80::3, Vlan110
     via FE80::1, Vlan200
     via FE80::3, Vlan200
     via FE80::3, Vlan120
D   2001:DB8:CAFE:203::/64 [90/2848]
     via FE80::3, Vlan99
     via FE80::3, Vlan100
     via FE80::3, Vlan110
     via FE80::3, Vlan200
     via FE80::3, Vlan120
D   2001:DB8:EFAC::/48 [90/2170144]
     via FE80::1, Vlan99
     via FE80::3, Vlan99
     via FE80::1, Vlan120
     via FE80::1, Vlan100
     via FE80::3, Vlan100
     via FE80::1, Vlan110
     via FE80::3, Vlan110
     via FE80::1, Vlan200
     via FE80::3, Vlan200
     via FE80::3, Vlan120

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.

Subscribe
Notify of
guest

0 Comments
Inline Feedbacks
View all comments