360rsw05 WKB Ca01 Ak PDF

360RSW05-WKB-CA01
Cisco 360 CCIE R&S Exercise

Workbook Introduction
The Cisco 360 CCIE R&S Exercise Workbook contains 20 challenging scenarios at the CCIE level
that can be used for rigorous self-paced practice.
Each lab provides an extensive answer key, Mentor Guide support, and verification tables and is
designed to maximize learning by providing practical experience. Also, self-paced learning resources
such as the Cisco 360 CCIE R&S Reference Library and Cisco 360 CCIE R&S lessons supplement the
Exercise Workbook scenarios.
Cisco 360 CCIE R&S Exercise

Workbook Lab 1 Configuration
Section Answer Key
COPYRIGHT. 2013. CISCO SYSTEMS, INC. ALL RIGHTS RESERVED. ALL CONTENT AND
MATERIALS, INCLUDING WITHOUT LIMITATION, RECORDINGS, COURSE MATERIALS, HANDOUTS
AND PRESENTATIONS AVAILABLE ON THIS PAGE, ARE PROTECTED BY COPYRIGHT LAWS.
THESE MATERIALS ARE LICENSED EXCLUSIVELY TO REGISTERED STUDENTS FOR THEIR
INDIVIDUAL PARTICIPATION IN THE SUBJECT COURSE. DOWNLOADING THESE MATERIALS
SIGNIFIES YOUR AGREEMENT TO THE FOLLOWING: (1) YOU ARE PERMITTED TO PRINT THESE
MATERIALS ONLY ONCE, AND OTHERWISE MAY NOT REPRODUCE THESE MATERIALS IN ANY
FORM, OR BY ANY MEANS, WITHOUT PRIOR WRITTEN PERMISSION FROM CISCO; AND (2) YOU
ARE NOT PERMITTED TO SAVE ON ANY SYSTEM, MODIFY, DISTRIBUTE, REBROADCAST,
PUBLISH, TRANSMIT, SHARE OR CREATE DERIVATIVE WORKS ANY OF THESE MATERIALS. IF
YOU ARE NOT A REGISTERED STUDENT THAT HAS ACCEPTED THESE AND OTHER TERMS
OUTLINED IN THE STUDENT AGREEMENT OR OTHERWISE AUTHORIZED BY CISCO, YOU ARE NOT
AUTHORIZED TO ACCESS THESE MATERIALS.
Cisco 360 CCIE R&S Exercise Workbook Lab 1 Answer Key
2013 Cisco Systems, Inc.
Table of Contents
Cisco 360 CCIE R&S Exercise Workbook Lab 1 Configuration Section Answer Key........... 2
Answer Key Structure .............................................................................................................................. 4
Section One ....................................................................................................................................... 4
Section Two ....................................................................................................................................... 4
Exercise Workbook Lab 1 Configuration Section Answer Key .............................................. 5

Grading and Duration ............................................................................................................................... 5
Difficulty Level .......................................................................................................................................... 5
Restrictions and Goals ............................................................................................................................. 5
Explanation of Each of the Restrictions and Goals .................................................................................. 7
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
Switch Configuration .......................................................................................................................... 8

DMVPN Communications................................................................................................................. 16
IPv4 OSPF ....................................................................................................................................... 17
IPv4 EIGRP ...................................................................................................................................... 21
IPv4 RIP ........................................................................................................................................... 28
Redistribution ................................................................................................................................... 29
BGP.................................................................................................................................................. 30
Traffic Optimization .......................................................................................................................... 34
IPv6 Routing..................................................................................................................................... 36
Quality of Service ........................................................................................................................... 39
System Administration.................................................................................................................... 42
Multicast ......................................................................................................................................... 45
Answer Key Structure

Section One
The answer key PDF document is downloadable from the web portal.
Section Two
To obtain a comprehensive view of the configuration for a specific section, access the Mentor Guide
engine in the web portal.
Exercise Workbook Lab 1

Configuration Section Answer
Key
Note
Regardless of any configuration you perform in this lab, it is very important that you conform to
the general guidelines that are provided in the Restrictions and Goals section. If you do not
conform to the guidelines, you could have a significant deduction of points in your final score.
Grading and Duration
Configuration lab duration:

Configuration maximum score:
Note
6 hours
76 points
You can assess your progress on the self-paced labs in this workbook by adding up the points
that are assigned to sections and tasks. Consider taking the full Assessment Labs to assess
your readiness level.
Difficulty Level
Difficulty: Intermediate
Restrictions and Goals

Note
Read this section carefully.
To receive credit for a subsection, you must fully complete the subsection per the
requirements. You will not receive partial credit for partially completed subsections.
IPv4 subnets that are displayed in the IPv4 IGP diagram belong to network 172.10.0.0/16.
Points will be deducted from multiple sections for failing to assign correct IPv4 addresses.
Do not use any static routes.
Advertise loopback interfaces with their original masks.
Network 0.0.0.0/0 should not appear in any routing table (show ip route), except on R9.
Do not introduce any new IP addresses.
All the IP addresses that are involved in this scenario must be reachable, unless explicitly
specified otherwise.
Unless explicitly specified otherwise, addresses and networks that are advertised in the
BGP section need to be reachable by all BGP routers but do not have to be reachable by
routers that use only IGP. Use conventional routing algorithms only, unless specified
otherwise.
Do not create new interfaces to fulfill IGP requirements, and do not summarize unless you
are explicitly asked to do so.
Do not modify the hostname, console, or vty configuration unless you are specifically asked
to do so.
Do not modify the initial interface or IP address numbering.
Explanation of Each of the Restrictions and Goals

IPv4 subnets that are displayed in the scenario diagram belong to network 172.10.0.0/16.
All IP addresses in this lab belong to the 172.10.0.0/16 address space, except for prefixes that are explicitly
specified as being part of a different IP space.
Do not use any static routes.
Static routes can be used to solve a range of reachability problems. However, you cannot use them in this lab.
You must rely on skillful configuration of all your unicast routing protocols.
Advertise loopback interfaces with their original masks.
The original mask is the mask that is configured on the loopback interface. Open Shortest Path First (OSPF),
by default, treats loopback interfaces as host routes and advertises them as /32 prefixes. You need to provide a
solution to represent the original mask of addresses assigned to loopback interfaces. A possible option is
changing the OSPF network type or summarizations.
Network 0.0.0.0/0 should not appear in any routing table (show ip route), except on R9.
A 0.0.0.0/0 entry can be used to solve a range of reachability problems. In particular, a 0.0.0.0/0 entry can be
used to set up the gateway of last resort. In this exercise, you cannot use any 0.0.0.0/0 entries. Route
summarization is an alternative to using the 0.0.0.0/0 route to solve the reachability problem.
Do not use the default-information originate, ip default-gateway, or ip default-network commands.
These commands can be used to solve reachability issues by setting the gateway of last resort. They generate a
0.0.0.0/0 route. You cannot use them in this scenario.
All the IP addresses that are involved in this scenario must be reachable, unless explicitly specified
otherwise.
This goal is a key goal to observe. It requires that all of your IGPs and your routing policy tasks be configured
properly. The key elements of your routing policy include route redistribution and the controlling of routing
updates using the distribute-list, route-map, and distance commands. A key point to remember about this lab
is that the term redistribution is not explicitly used. However, you must perform redistribution to ensure that
all IP addresses are reachable without the use of static routes.
Unless explicitly specified otherwise, addresses and networks that are advertised in the BGP section
need to be reachable by all BGP routers but do not have to be reachable by routers that use only IGP.
This statement relaxes the requirement that all IP addresses must be reachable. The BGP prefixes need to be
reachable among only the routers specified in the BGP section. They can be used in other unicast tables.
However, BGP routers need to have the prefixes in the routing tables and to be able to forward traffic to the
addresses that are known via BGP.
Use conventional routing algorithms only, unless specified otherwise.

This restriction prevents you from solving any problems by configuring policy routing. At the heart of this
restriction is the interpretation of conventional routing algorithms. Although this phrase can be interpreted in
different ways, this interpretation is applied in this workbook:
Conventional routing algorithms are routing algorithms that apply destination-based prefix lookups in
a routing table. They do not use any other type of information other than the destination address to
make a packet-forwarding decision.
Because of this restrictive interpretation, no form of policy routing can be applied. Whenever you see this
restriction, you will need to use dynamic routing protocols to fulfill all packet-forwarding requirements.
1. Switch Configuration
General Tasks
Like any switch configuration, you must address the following basic configuration requirements:
Set the Virtual Trunking Protocol (VTP) mode.
Configure the VLANs and the VLAN names.
Configure the trunk ports.
Statically assign the ports of the switches to the VLANs.
Note
For a good reference on mastering basic Cisco Catalyst 3560 Switch configuration tasks,
access the full set of Catalyst video-on-demand (VoD) sessions within the Link Layer lesson
in the Cisco 360 learning portal. These self-paced sessions provide more than 7 hours of
instruction on a range of basic Catalyst switch configuration tasks. Some of the Cisco Catalyst
3560 Switch configuration commands are not available on the virtual instances of the
switches.
Use the VLANs table, the Switch-to-Router Connections table, and the Switch-to-Switch
Connections table for reference.
Make sure that the VLAN names are spelled correctly and match the letter case.
Carefully review the entire scenario. Closely examine the supplied diagram and any associated
tables. Determine how you need to configure VTP, how to configure ports that are assigned as
trunks, and how to configure ports that are assigned as simply static VLAN ports. For any ports
that are statically assigned to a VLAN, it is recommended that you statically assign the
switchport mode access command.
See the following diagram for the VLAN layout.
VLAN Distribution
E0/0
LEGEND
VLAN10
VLAN20
VLAN30
VLAN100
VLAN999
R5
E0/0
E0/1
E0/1
E0/0
DOT1Q
R6
R4
E0/1
R2
E0/1
ACCESS
R3
E0/0
PORT CHANNEL
E0/1
SVI
E0/0
ROUTED
SHUTDOWN
R1
E0/0
E0/1
E0/0 E0/1 E0/2 E0/3 E1/0 E1/1
E1/1 E1/0 E0/3 E0/2 E0/1 E0/0
SW1
E2/2
E2/2
E2/3
E2/3
R7
E2/0
E2/0
E0/0
E1/2 E1/3
E2/1
E2/1
E1/2 E1/3
E1/2 E1/3
E2/0
E2/0
E1/2 E1/3
BB
SW2
R8
E0/0
R9
E0/0
E2/1
E2/1
E2/2
E0/1
E2/2
E0/1
E2/3
E2/3
E0/0
SW4
SW3
E0/0
E0/0
Issue: Do not use any dynamic VLAN advertisement protocol.

Solution:
If you are told not to advertise VLANs, this instruction provides a hint as to how you should
configure VTP: use VTP transparent mode on all of your switches. Switches that are configured
in VTP transparent mode will not advertise any VLANs that are created on them.
Configure the vtp mode transparent command on SW1, SW2, SW3, and SW4. The following
example shows the configuration on SW1:
SW1#conf t
Enter configuration commands, one per line. End with CNTL/Z.
SW1(config)#vtp mode transparent
Setting device to VTP Transparent mode for VLANS.
SW1(config)#end
SW1#
Verify the VTP status on each switch. Here is an example from SW1:
SW1#show vtp status
VTP Version
Configuration Revision
Maximum VLANs supported locally
Number of existing VLANs
:
:
:
:
3 (capable)
0
1005
5
VTP Operating Mode

: Transparent
VTP Domain Name
:
VTP Pruning Mode
: Disabled (Operationally Disabled)
VTP V2 Mode
: Disabled
VTP Traps Generation
: Disabled
MD5 digest
: 0x57 0xCD 0x40 0x65 0x63 0x59 0x47 0xBD
Configuration last modified by 0.0.0.0 at 0-0-00 00:00:00
VTP version running
: 1
SW1#
Configure all necessary VLANs on SW1, SW2, SW3, and SW4 according to the scenario
requirements and the VLANs table.
Here is an example of the SW1 VLAN configuration:
SW1#conf t
SW1(config)#vlan 10
SW1(config-vlan)#name VLAN-10
SW1(config-vlan)#vlan 20
% Applying VLAN changes may take few minutes. Please wait...
SW1(config-vlan)#vlan 30
% Applying VLAN changes may take few minutes.
Please wait...
SW1(config-vlan)#end
% Applying VLAN changes may take few minutes.
Please wait...
SW1#
After you complete the VLAN configuration on all switches, verify the VLANs on all switches.
Your output should resemble the following example on SW1, SW2, SW3, and SW4:
SW1#show vlan brief | exclude ^100[2345]
VLAN Name
---- -------------------------------<skipped>
10
VLAN-10
20
VLAN-20
30
VLAN-30
Status
Ports
--------- ------------------------------active
active
active
SW1#
VLAN Name
---- -------------------------------<skipped>
30
VLAN-30
999 BB
100 DMVPN
Status
Ports
--------- ------------------------------active
active
active
SW2#
VLAN Name
---- -------------------------------<skipped>
10
VLAN-10
20
VLAN-20
10
Status
Ports
--------- ------------------------------active
active
SW3#
VLAN Name
---- -------------------------------<skipped>
20
VLAN-20
999 BB
Status
Ports
--------- ------------------------------active
active
SW4#
Issue: Use the IEEE 802.1Q protocol for trunking.

Solution:
You have to configure a switch port as a dot1q trunk. Issue the switchport trunk encapsulation
dot1q command under the interface configuration for that port.
Issue: Traffic for VLAN 20 should not be allowed on ports E2/2 of SW1 and SW2.
Solution:
If VLAN 20 traffic is not allowed between SW1 and SW2, the only choice that remains for
forwarding traffic between R5 and R6 is to transit through SW3 and SW4. See the VLAN
Distribution diagram.
Configure the switch-to-router connections according to the Switch-to-Router Connections
table.
SW1:
interface Ethernet0/1
switchport access vlan 10
switchport mode access
duplex auto
!
duplex auto
!
switchport trunk encapsulation dot1q
switchport trunk allowed vlan 20,30
switchport mode trunk
duplex auto
!
duplex auto
!
SW2:
duplex auto
!
duplex auto
11
!
duplex auto
!
duplex auto
!
duplex auto
!
SW3:
duplex auto
!
duplex auto
!
interface Vlan10
ip address 172.10.23.254 255.255.255.0
!
SW4:
switchport trunk allowed vlan 999
duplex auto
!
duplex auto
!
Configure the switch-to-switch connections according to the Switch-to-Switch Connections

table.
SW1:
duplex auto
!
duplex auto
!
duplex auto
!
12
Shut down the following interfaces:

SW1#show ip interface brief | inc admin
Ethernet2/0
unassigned
YES unset
Ethernet2/1
unassigned
YES unset
Ethernet2/3
unassigned
YES unset
Vlan1
unassigned
YES unset
SW1#
administratively
administratively
administratively
administratively
down
down
down
down
down
down
down
down
administratively
administratively
administratively
administratively
administratively
down
down
down
down
down
down
down
down
down
down
administratively
administratively
administratively
administratively
down
down
down
down
down
down
down
down
SW2:
duplex auto
!
duplex auto
!

Ethernet1/3
unassigned
YES unset
Ethernet2/0
unassigned
YES unset
Ethernet2/1
unassigned
YES unset
Ethernet2/3
unassigned
YES unset
Vlan1
unassigned
YES unset
SW2#
SW3:
!
duplex auto
!
duplex auto
!
duplex auto
!

Ethernet2/0
unassigned
YES unset
Ethernet2/1
unassigned
YES unset
Ethernet2/3
unassigned
YES unset
Vlan1
unassigned
YES unset
SW3#
SW4:
13

duplex auto
!
duplex auto
!

Ethernet1/3
unassigned
YES unset
Ethernet2/0
unassigned
YES unset
Ethernet2/1
unassigned
YES unset
Ethernet2/3
unassigned
YES unset
Vlan1
unassigned
YES unset
SW4#
administratively
administratively
administratively
administratively
administratively
down
down
down
down
down
down
down
down
down
down
Issue: A PC with the network interface card (NIC) MAC address 00-07-85-92-D0-E7 is
connected to port E0/3 of SW3 on the default VLAN. Make sure that only this PC is allowed to
access port E0/3.
Solution:
To restrict access to only the data-link address that is listed, configure the following interface
configuration commands on the 0/3 port of SW3:
Ethernet0/3 is configured as a default dynamic port after the lab initialization. Port security
configuration cannot be applied on the dynamic ports. Use the switchport nonegotiate
command to force the port to be nondynamic or configure the switchport mode access
command on the interface. The switchport mode access command is used in this answer
key, along with these commands:
switchport port-security mac-address 0007.8592.D0E7
switchport port-security
Verify the status of the switch port security:

SW3#show port-security interface e0/3
Port Security
: Enabled
Port Status
: Secure-up
Violation Mode
: Shutdown
Aging Time
: 0 mins
Aging Type
: Absolute
SecureStatic Address Aging : Disabled
Maximum MAC Addresses
: 1
Total MAC Addresses
: 1
Configured MAC Addresses
: 1
Sticky MAC Addresses
: 0
Last Source Address
: 0000.0000.0000
Last Source Address VlanId : 0
Security Violation Count
: 0
SW3#
SW3#show port-security interface e0/3 address
Secure Mac Address Table
------------------------------------------------------------------Vlan
Mac Address
Type
Ports
Remaining Age
14
(mins)
--------------------------------1
0007.8592.d0e7
SecureConfigured
Et0/3
------------------------------------------------------------------Total Addresses: 1
SW3#
Issue: If a host residing in VLAN 20 remains silent, SW4 should erase its MAC address from its
MAC address table two times faster than the default would have erased it.
Solution:
The Cisco Command Reference
(http://www.cisco.com/en/US/products/hw/switches/ps5528/prod_command_reference_list.html)
instructs you to use the global configuration command mac address-table aging-time to set the
length of time that a dynamic entry remains in the MAC address table after the entry is used or
updated. The default is 300 seconds, or 5 minutes.
Configure the mac-address-table aging-time 150 vlan 20 command on SW4 and verify the
MAC address table:
SW4#show mac address-table aging-time
Vlan
Aging Time
------------1
300
20
150
999
300
SW4#
Note
To obtain a comprehensive view of the configuration tasks in this section, access the Mentor
Guide engine. You can enter into the engine over 1000 Cisco IOS Software commands, as
well as a collection of proprietary commands such as show all.
15
2. DMVPN Communications
Configure the mGRE Tunnel124 on R1, R2, and R4 according to the scenario requirements:
R1:
!
interface Tunnel124
ip address 172.10.124.129 255.255.255.128
tunnel source Ethernet0/1
tunnel mode gre multipoint
tunnel key 10
!
R2:
!
interface Tunnel124
ip address 172.10.124.130 255.255.255.128
tunnel key 10
!
!
R4:
!
interface Tunnel124
ip address 172.10.124.131 255.255.255.128
tunnel key 10
!
Note that the tunnel key 10 command is used to configure the tunnel key in this answer key.
Since the lab does not specify the tunnel key value, you can use any number as long as it matches
between the tunnel endpoints.
Configure the NHRP and DMVPN on R1, R2, and R4 according to the scenario requirements:
R1:
!
interface Tunnel124
ip address 172.10.124.129 255.255.255.128
ip nhrp network-id 10
tunnel key 10
!
R2:
interface Tunnel124
ip address 172.10.124.130 255.255.255.128
ip nhrp map 172.10.124.129 10.10.1.1
ip nhrp nhs 172.10.124.129
tunnel key 10
!
R4:
!
interface Tunnel124
ip address 172.10.124.131 255.255.255.128
16
ip nhrp map 172.10.124.129 10.10.1.1

ip nhrp nhs 172.10.124.129
tunnel key 10
!
Note that R1 is defined as an NHS and the NHRP mapping for NHS is done on the NHRP spokes
R2 and R4. Also the DMVPN network ID is defined on all DMVPN routers with the ip nhrp
network-id 10 command.
Verify the NHRP registrations on R1:
R1#show ip nhrp
172.10.124.130/32 via 172.10.124.130
Tunnel124 created 00:37:37, expire 01:22:22
Type: dynamic, Flags: unique registered
NBMA address: 10.10.1.2
172.10.124.131/32 via 172.10.124.131
Tunnel124 created 00:37:23, expire 01:22:36
Type: dynamic, Flags: unique registered
NBMA address: 10.10.1.4
R1#
Verify the DMVPN connectivity. Here is an example on R4:

R4#ping 172.10.124.129
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.10.124.129, timeout
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max
R4#ping 172.10.124.130
Sending 5, 100-byte ICMP Echos to 172.10.124.130, timeout
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max
R4#
is 2 seconds:
= 1/1/1 ms
is 2 seconds:
= 1/1/1 ms
Note that the spoke R4 can ping the hub R1 and the other spoke, R2.
Note
3. IPv4 OSPF
Note
All OSPF routers must be configured with only one OSPF process ID (PID). Use your IGP
diagram to help guide your configuration.
Issue: Do not elect a designated router (DR) or backup designated router (BDR) on VLAN 20.
Make sure that OSPF packets are exchanged on VLAN 20 without the use of a multicast address
for security reasons.
17
Solution:
If you cannot elect a DR or BDR on VLAN 20, then you cannot use the OSPF broadcast or
nonbroadcast network types. This restriction leaves the following OSPF network types: point-topoint, point-to-multipoint, and point-to-multipoint nonbroadcast. Of these, both point-to-point and
point-to-multipoint use the 224.0.0.5 multicast address for advertising hello messages. The pointto-multipoint nonbroadcast network type does not use the 224.0.0.5 multicast at all. Therefore,
configure VLAN 20 by using the point-to-multipoint nonbroadcast network type. Remember to
configure neighbor statements for point-to-multipoint nonbroadcast to identify the unicast
destination of OSPF packets.
Issue: Create loopback 106 on R6 and place it in area 600.
Solution:
The Restrictions and Goals section instructs learners to advertise loopback interfaces with their
original masks. When loopback interfaces are assigned to an OSPF area, they are advertised as
host routes by default. To change this behavior, configure the loopback interface as an OSPF
point-to-point network type. With this configuration, the IP address that is assigned to the
loopback interface on R6 will be advertised with its native prefix.
Configure the loopback with the OSPF point-to-point network type by issuing the ip ospf
network point-to-point command.
Since R6 possesses no direct link to OSPF area 0, a virtual link must be configured over area 10,
allowing the area 600 prefix to be learned by all OSPF routers. Remember to include the virtual
link in the area 0 authentication configuration.
To verify that the virtual link is active, issue the show ip ospf virtual-links command. The up
indication on the first line of the output can be deceiving; look for Adjacency State Full.
Issue: Use cleartext authentication on area 0. The password is test.
Solution:
This authentication configuration is applied to all interfaces that are assigned to area 0, including
all virtual links that are configured in this scenario.
Issue: Use Message Digest 5 (MD5) authentication on area 10. Use the password rstest.
Solution:
The MD5 authentication type is applied to all interfaces that are assigned to area 10, but not to
any virtual links that are configured in this scenario that may transit OSPF area 10.
Configure OSPF on R3, R5, and R6 according to the scenario requirements:
R3:
ip address 172.10.35.3 255.255.255.0
ip ospf authentication-key test
!
router ospf 1
area 0 authentication
network 172.10.35.0 0.0.0.255 area 0
!
R5:
18
interface Loopback105
ip address 172.10.105.1 255.255.255.0
ip ospf network point-to-point
!
!
interface Ethernet0/0.20
encapsulation dot1Q 20
ip address 172.10.65.5 255.255.255.0
ip ospf message-digest-key 1 md5 rstest
ip ospf network point-to-multipoint non-broadcast
!
ip address 172.10.35.5 255.255.255.0
!
router ospf 1
router-id 172.10.105.1
area 10 authentication message-digest
area 10 virtual-link 172.10.106.1 authentication-key test
network 172.10.35.0 0.0.0.255 area 0
network 172.10.65.0 0.0.0.255 area 10
network 172.10.105.0 0.0.0.255 area 0
neighbor 172.10.65.6
!
R6:
ip address 172.10.106.1 255.255.255.0
!
ip address 172.10.65.6 255.255.255.0
ip ospf message-digest-key 1 md5 rstest
ip ospf network point-to-multipoint non-broadcast
!
ip address 10.1.1.6 255.255.255.0
ip ospf 1 area 7
router ospf 1
router-id 172.10.106.1
network 172.10.65.0 0.0.0.255 area 10
network 172.10.106.1 0.0.0.0 area 600
!
Verify the OSPF routing table on R3:

R3#show ip route ospf | inc ^O
O IA
7.10.124.128 [110/31] via 172.10.35.5, 00:12:45, Ethernet0/1
O IA
10.1.1.0 [110/30] via 172.10.35.5, 00:12:45, Ethernet0/1
O IA
172.10.65.5/32 [110/10] via 172.10.35.5, 01:16:29, Ethernet0/1
O IA
172.10.65.6/32 [110/20] via 172.10.35.5, 01:16:29, Ethernet0/1
O
172.10.105.0/24 [110/11] via 172.10.35.5, 01:16:29, Ethernet0/1
O IA
172.10.106.0/24 [110/21] via 172.10.35.5, 01:16:29, Ethernet0/1
R3#
Note that R3 learns the loopback networks with the mask /24 from R5 and R6.
19
Verify the OSPF Area 0 and Area 10 configuration. Since R5 is connected to both areas, here is
an example from R5:
R5#show ip ospf | begin Area BACKBONE
Area BACKBONE(0)
Number of interfaces in this area is 3 (1 loopback)
Area has simple password authentication
SPF algorithm last executed 00:09:36.367 ago
SPF algorithm executed 5 times
Area ranges are
Number of LSA 9. Checksum Sum 0x0522E3
Number of opaque link LSA 0. Checksum Sum 0x000000
Number of DCbitless LSA 0
Number of indication LSA 0
Number of DoNotAge LSA 4
Flood list length 0
Area 10
Number of interfaces in this area is 1
This area has transit capability: Virtual Link Endpoint
Area has message digest authentication
SPF algorithm last executed 00:10:24.497 ago
SPF algorithm executed 5 times
Area ranges are
Number of LSA 5. Checksum Sum 0x02FD93
Number of opaque link LSA 0. Checksum Sum 0x000000
Number of DCbitless LSA 0
Number of indication LSA 0
Number of DoNotAge LSA 0
Flood list length 0
R5#
Note that Area 0 has simple password authentication and Area 10 has Message Digest
authentication. Also, Area 10 is configured as a transit area for the virtual link.
Verify the OSPF virtual link configuration on R5:
R5#show ip ospf virtual-links
Virtual Link OSPF_VL0 to router 172.10.106.1 is up
Run as demand circuit
DoNotAge LSA allowed.
Transit area 10, via interface Ethernet0/0.20
Topology-MTID
Cost
Disabled
Shutdown
Topology Name
0
10
no
no
Base
Transmit Delay is 1 sec, State POINT_TO_POINT,
Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5
Hello due in 00:00:07
Adjacency State FULL (Hello suppressed)
Index 2/3, retransmission queue length 0, number of retransmission 0
First 0x0(0)/0x0(0) Next 0x0(0)/0x0(0)
Last retransmission scan length is 0, maximum is 0
Last retransmission scan time is 0 msec, maximum is 0 msec
Simple password authentication enabled
R5#
Note that the OSPF virtual link is up and that simple password authentication is enabled on the
virtual link.
Verify the OSPF interfaces on VLAN 20. Here is an example from R5:
R5#show ip ospf interface e0/0.20
Ethernet0/0.20 is up, line protocol is up
Internet Address 172.10.65.5/24, Area 10, Attached via Network Statement
Process ID 1, Router ID 172.10.105.1, Network Type POINT_TO_MULTIPOINT, Cost:
10
Topology-MTID
Cost
Disabled
Shutdown
Topology Name
0
10
no
no
Base
20
Transmit Delay is 1 sec, State POINT_TO_MULTIPOINT

Timer intervals configured, Hello 30, Dead 120, Wait 120, Retransmit 5
oob-resync timeout 120
Hello due in 00:00:19
Supports Link-local Signaling (LLS)
Cisco NSF helper support enabled
IETF NSF helper support enabled
Index 1/3, flood queue length 0
Next 0x0(0)/0x0(0)
Last flood scan length is 1, maximum is 1
Last flood scan time is 0 msec, maximum is 0 msec
Neighbor Count is 1, Adjacent neighbor count is 1
Adjacent with neighbor 172.10.106.1
Suppress hello for 0 neighbor(s)
Message digest authentication enabled
Youngest key id is 1
R5#
Note that the output of the show ip ospf interface e0/0.20 command on R5 shows that the
E0/0.20 interface is up, is configured with the point-to-multipoint network type, and is using
Message Digest authentication. The E0/0.20 OSPF interface shows the OSPF adjacency with R6.
Verify the OSPF connectivity. Here is an example from R3:
R3#ping 172.10.106.1
Sending 5, 100-byte ICMP Echos to 172.10.106.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/1 ms
R3#ping 172.10.105.1
!!!!!
R3#ping 172.10.65.6
!!!!!
R3#ping 7.10.124.129
!!!!!
R3#
Note that R3 can ping interfaces on R5, R6, and BB.
Note
4. IPv4 EIGRP
Issue: Do not allow multicast EIGRP traffic on the DMVPN and the Serial HDLC subnets. R3
and R8 must not form the EIGRP neighbor relationship. The DMVPN should be used as a backup
communication path for traffic forwarding in case the link between R2 and R3 fails.
21
Solution:
To prevent EIGRP traffic from being multicast on the DMVPN and the serial HDLC subnets,
configure neighbor statements between R1 and R2, between R1 and R4, and between R3 and R4.
Unlike the Routing Information Protocol (RIP), do not put the EIGRP interfaces that will send
unicast traffic into a passive state.
Make sure that split horizon is disabled on the Tunnel124 interface of R1. R1 is the hub of a huband-spoke topology on the 172.10.124.128/25 subnet. By disabling the EIGRP split horizon, you
allow R1 to pass the EIGRP route updates between the spokes via the hub, so the networks that
are advertised from the spokes can communicate via R1, the DMVPN hub.
Split horizon is enabled by default on all interface types for EIGRP. Therefore, you must
manually disable split horizon on R1.
Issue: Summarize the following networks with the most optimal mask:
ip address 172.10.25.89 255.255.255.252
ip address 172.10.25.93 255.255.255.252
ip address 172.10.25.97 255.255.255.252
Make sure that R2 does not have this summary.

Solution:
EIGRP summarization is performed at the interface level. The longest match summary for these
prefixes is 172.10.25.64/26. Apply the summary on the E0/0 interface and the Tunnel124
interface on R2.
Issue: Advertise the loopback address 4.4.4.4 255.255.255.0 on R4 as the internal EIGRP prefix.
Advertise the loopback address 1.1.1.1 255.255.255.0 on R1 as the internal EIGRP prefix.
Solution:
This task is setting the stage for a BGP configuration requirement. By advertising these prefixes
into EIGRP, a BGP recursive routing issue between R1 and R4 is allowed. See the BGP section
for more details.
Issue: Configure EIGRP AS 100 on the VLAN 10 subnet 172.10.23.0/24 between R2, R3, and
R7. EIGRP AS 100 on R2 must be configured with the network 172.10.0.0 statement. Make
sure that R2 does not advertise the subnet 172.10.100.0/24.
Solution:
Configure the distribute-list out command in the EIGRP routing process on R2 to prevent R2
from advertising the subnet 172.10.100.0/24.
Issue: Ping loopback 172.10.100.1 from the rest of the network by using the address
172.10.23.100.
Solution:
This creates a NAT configuration requirement on R2. Do the following:
22
Configure loopback 100 on R2 as the ip nat inside interface.
Configure E0/0 on R2 as the ip nat outside interface.
Configure Tunnel124 on R2 as the ip nat outside interface.
Configure NAT translation with the command ip nat inside source static 172.10.100.1
172.10.23.100.
Issue the show ip nat translations command to verify the NAT operations on R2.
Issue: The subnet 172.10.32.0/24 is configured on VLAN 10 between R3 and R8. R8 should not
run the ip routing process. R8 should be reachable from the rest of the network.
Solution:
The 172.10.32.0/24 subnet is configured as a secondary subnet on R3.
Configure the no ip routing command on R8. This configuration will make R8 act as a host that
is connected to the EIGRP domain.
Configure the ip default-gateway command on R8 to forward traffic to the first-hop router R3.
Configure EIGRP on R1, R2, R3, R4, R7, and R8 according to the scenario requirements.
R1:
interface Tunnel124
ip address 172.10.124.129 255.255.255.128
no ip redirects
no ip split-horizon eigrp 100
tunnel key 10
!
router eigrp 100
network 1.1.1.0 0.0.0.255
network 172.10.0.0
neighbor 172.10.124.131 Tunnel124
!
R2:
interface Tunnel124
ip address 172.10.124.130 255.255.255.128
no ip redirects
ip nat outside
ip nhrp map 172.10.124.129 10.10.1.1
ip nhrp nhs 172.10.124.129
ip virtual-reassembly in
ip summary-address eigrp 100 172.10.25.64 255.255.255.192
tunnel key 10
ip address 172.10.23.2 255.255.255.0
ip nat outside
ip virtual-reassembly in
ip summary-address eigrp 100 172.10.25.64 255.255.255.192
!
router eigrp 100
distribute-list NoLoop100 out
network 172.10.0.0
!
23
ip nat inside source static 172.10.100.1 172.10.23.100

!
ip access-list standard NoLoop100
deny
172.10.100.0 0.0.0.255
permit any
!
R3:
router eigrp 100
network 172.10.0.0
neighbor 172.10.43.4 Serial1/0
!
R4:
!
router eigrp 100
network 4.4.4.0 0.0.0.255
network 172.10.0.0
!
R7:
router eigrp 100
network 172.10.0.0
!
R8:
no ip routing
ip default-gateway 172.10.32.3
Here are the examples of some verification commands.

Verify the EIGRP interface configuration on Tunnel124 on R1:
R1#show ip eigrp interfaces detail tunnel 124
EIGRP-IPv4 Interfaces for AS(100)
Xmit Queue
PeerQ
Multicast
Pending
Interface
Peers Un/Reliable Un/Reliable
Flow Timer
Routes
Tu124
2
0/0
0/0
492
0
Hello-interval is 5, Hold-time is 15
Split-horizon is disabled
Next xmit serial <none>
Packetized sent/expedited: 27/3
Hello's sent/expedited: 1240/3
Un/reliable mcasts: 0/0 Un/reliable ucasts: 40/48
Mcast exceptions: 0 CR packets: 0 ACKs suppressed: 2
Retransmissions sent: 0 Out-of-sequence rcvd: 0
Topology-ids on interface - 0
Authentication mode is not set
R1#
Mean
Pacing Time
SRTT
Un/Reliable
3
6/238
Note that the EIGRP split horizon is disabled. R1 does not send and receive any multicast
updates, only the unicast.
Verify the EIGRP routing table on R2 with the operational E0/0 interface:
R2#show ip route eigrp | inc ^D
D
1.1.1.0 [90/27008000] via 172.10.124.129, 00:33:46, Tunnel124
24
D
D
D
D
D
D
D
D
R2#
4.4.4.0 [90/2323456] via 172.10.23.3, 00:33:46, Ethernet0/0

172.10.25.64/26 is a summary, 01:10:55, Null0
172.10.32.0/24 [90/28697600] via 172.10.124.129, 00:33:48, Tunnel124
172.10.35.0/24 [90/307200] via 172.10.23.3, 00:33:45, Ethernet0/0
172.10.43.0/24 [90/2195456] via 172.10.23.3, 00:33:46, Ethernet0/0
172.10.101.0/24 [90/27008000] via 172.10.124.129, 00:33:46, Tunnel124
172.10.103.0/24 [90/409600] via 172.10.23.3, 00:33:45, Ethernet0/0
172.10.104.0/24 [90/2323456] via 172.10.23.3, 00:33:46, Ethernet0/0
Note that R2 learns the update via a faster link between R2 and R3.
Shut down the E0/0 interface on R2 and verify the EIGRP routing table on R2 again:
R2#conf t
R2(config)#int e0/0
R2(config-if)#shut
R2(config-if)#end
R2#
*Apr
22
22:44:11.844:
%LINEPROTO-5-UPDOWN:
Line
protocol
on
Interface
Ethernet0/0, changed state to down
R2#show ip route eigrp | inc ^D
D
1.1.1.0 [90/27008000] via 172.10.124.129, 00:34:57, Tunnel124
D
4.4.4.0 [90/28288000] via 172.10.124.129, 00:00:05, Tunnel124
D
172.10.23.0/24 [90/28697600] via 172.10.124.129, 00:00:05, Tunnel124
D
172.10.25.64/26 is a summary, 01:12:06, Null0
D
172.10.32.0/24 [90/28697600] via 172.10.124.129, 00:34:59, Tunnel124
D
172.10.35.0/24 [90/28697600] via 172.10.124.129, 00:00:05, Tunnel124
D
172.10.43.0/24 [90/28672000] via 172.10.124.129, 00:00:05, Tunnel124
D
172.10.101.0/24 [90/27008000] via 172.10.124.129, 00:34:57, Tunnel124
D
172.10.103.0/24 [90/28800000] via 172.10.124.129, 00:00:05, Tunnel124
D
172.10.104.0/24 [90/28288000] via 172.10.124.129, 00:00:05, Tunnel124
R2#
Note that the network converged via DMVPN.

Bring the E0/0 interface on R2 back up.
R2#conf t
Enter configuration commands, one per line.
R2(config)#int e0/0
R2(config-if)#no shut
R2(config-if)#end
R2#
End with CNTL/Z.
Verify a summary EIGRP network on R3:

R3#show ip route eigrp | inc \.25\.
D
172.10.25.64/26 [90/409600] via 172.10.23.2, 00:01:11, Ethernet0/0
R3#
Note that the R2 loopback networks are summarized to a /26 prefix.

Ping 172.10.23.100 from R1.
R1#ping 172.10.23.100
!!!!!
R1#
Verify the NAT table on R2:

25
R2#show ip nat translations

Pro Inside global
Inside local
icmp 172.10.23.100:10 172.10.100.1:10
--- 172.10.23.100
172.10.100.1
R2#
Outside local
172.10.124.129:10
---
Outside global
172.10.124.129:10
---
Verify the EIGRP domain connectivity from R8.

You can use the following Tcl script to test the EIGRP reachability. To use the script, enter the
command tclsh in privileged mode, and paste in the script. To kill failing pings, hold down CtrlShift and press the 6 key twice. When you are finished, enter tclquit to leave Tcl mode. Note that
the IP address 172.10.23.100 is included in the script, and the connectivity should fail.
Note
Tcl connectivity verification scripts for each router are available via the Verification link in the
CIERSWB service tab on the web portal.
tclsh
foreach addr {
1.1.1.1
172.10.124.129
172.10.101.1
172.10.124.130
172.10.23.2
172.10.102.1
172.10.25.97
172.10.25.93
172.10.25.89
172.10.23.100
172.10.32.3
172.10.43.3
172.10.23.3
172.10.103.1
4.4.4.4
172.10.124.131
172.10.43.4
172.10.104.1
} {ping $addr}
Tclquit
R8#tclsh
R8(tcl)#foreach addr {
+>(tcl)#1.1.1.1
+>(tcl)#172.10.124.129
+>(tcl)#172.10.101.1
+>(tcl)#172.10.124.130
+>(tcl)#172.10.23.2
+>(tcl)#172.10.102.1
+>(tcl)#172.10.25.97
+>(tcl)#172.10.25.93
+>(tcl)#172.10.25.89
+>(tcl)#172.10.23.100
+>(tcl)#172.10.32.3
+>(tcl)#172.10.43.3
+>(tcl)#172.10.23.3
+>(tcl)#172.10.103.1
+>(tcl)#4.4.4.4
+>(tcl)#172.10.124.131
+>(tcl)#172.10.43.4
+>(tcl)#172.10.104.1
+>(tcl)#} {ping $addr}
26

!!!!!
!!!!!
!!!!!
!!!!!
!!!!!
!!!!!
!!!!!
!!!!!
!!!!!
!!!!!
!!!!!
!!!!!
!!!!!
!!!!!
!!!!!
!!!!!
!!!!!
27

!!!!!
R8(tcl)#exit
R8#
Note
5. IPv4 RIP
Issue: Configure RIP version 2 (RIPv2) between R5 and R9 only. Set the gateway of last resort
on R9 only if the backbone prefix 7.10.124.128/25 is in the R5 routing table.
Solution:
To fulfill this configuration requirement, enter the following command in router RIP
configuration mode: default-information originate route-map RIP-default-condition. The
route map RIP-default-condition will match on an access list permitting the 7.10.124.128/25
prefix only. The effect of this configuration will be to allow R5 to advertise to R9 a 0.0.0.0/0
route only if R5 possesses the 7.10.124.128/25 prefix in its local routing table. The
7.10.124.128/25 prefix is a backbone OSPF prefix.
Configure RIPv2 on R5 and R9 according to the scenario requirements.
R5:
router rip
version 2
passive-interface default
no passive-interface Ethernet0/0.20
network 172.10.0.0
default-information originate route-map RIP-default-condition
no auto-summary
!
ip access-list standard RIP-default-condition
permit 7.10.124.128 0.0.0.127
!
!
route-map RIP-default-condition permit 10
match ip address RIP-default-condition
!
R9:
router rip
version 2
passive-interface default
no passive-interface Ethernet0/0
network 172.10.0.0
no auto-summary
!
Verify the routing table on R5:

R5#show ip route | begin 7.0.0
7.0.0.0/25 is subnetted, 1 subnets
O IA
7.10.124.128 [110/21] via 172.10.65.6, 00:12:09, Ethernet0/0.20
10.0.0.0/24 is subnetted, 1 subnets
<skipped>
28
R5#
Note that R5 learns the backbone prefix 7.10.124.128/25 via OSPF from R6.
Verify the RIP routing table on R9:
R9#show ip route rip | inc ^R
R*
0.0.0.0/0 [120/1] via 172.10.65.5, 00:00:23, Ethernet0/0
R
172.10.35.0/24 [120/1] via 172.10.65.5, 00:00:23, Ethernet0/0
R
172.10.105.0/24 [120/1] via 172.10.65.5, 00:00:23, Ethernet0/0
R9#
Note that R9 receives the 0.0.0.0/0 prefix from R5.
Note
6. Redistribution
In this scenario, the core protocol is EIGRP. It spans almost the whole topology. RIP is a stub
area, and OSPF provides transit between the RIP and EIGRP domains. R3 is a redistribution point
between the OSPF and EIGRP domains. R5 is a redistribution point between the OSPF and RIP
domains.
RIP sends only two networks into OSPF: 172.10.65.0/24 and 172.10.120.0/24. Notice that the
redistribution of RIP into OSPF on R5 does not result in an external type 2 (E2) route on R3 for
172.10.65.0/24. The OSPF point-to-multipoint network type models this link as a collection of
point-to-point links, and it represents the link as a collection of /32 host routes, not as a /24
subnet. Because OSPF does not accept the RIP version of the link as a /24 subnet, the address
172.10.65.10 on R9 becomes unreachable off the link. One remedy is to perform an interarea
summary on R5 for the subnet 172.10.65.0/24.
Redistribution from OSPF into RIP is not required for full reachability. Instead, RIP generates a
conditional default route (0.0.0.0/0) into the RIP domain.
Configure the route redistribution on R3 and R5 according to the scenario requirements.
R3:
router eigrp 100
default-metric 1500 100 255 1 1500
network 172.10.0.0
redistribute ospf 1
!
router ospf 1
redistribute eigrp 100 subnets
network 172.10.35.0 0.0.0.255 area 0
!
R5:
router ospf 1
router-id 172.10.105.1
29
area 10 range 172.10.65.0 255.255.255.0
redistribute rip subnets
network 172.10.35.0 0.0.0.255 area 0
network 172.10.65.0 0.0.0.255 area 10
network 172.10.105.0 0.0.0.255 area 0
!
You can use the following Tcl script to test universal reachability. To use the script, enter the
command tclsh in privileged mode, and paste in the script. To kill failing pings, hold down CtrlShift and press the 6 key twice. When you are finished, enter tclquit to leave Tcl mode.
Note
Tcl connectivity verification scripts for each router are available via the Verification link in the
CIERSWB service tab on the web portal.
tclsh
foreach addr {
1.1.1.1
172.10.124.129
172.10.101.1
172.10.124.130
172.10.23.2
172.10.102.1
172.10.25.97
172.10.25.93
172.10.25.89
172.10.32.3
172.10.35.3
172.10.43.3
172.10.23.3
172.10.103.1
4.4.4.4
172.10.124.131
172.10.43.4
172.10.104.1
172.10.35.5
172.10.105.1
172.10.65.5
172.10.106.1
172.10.65.6
172.10.23.10
172.10.23.100
172.10.32.10
172.10.120.1
172.10.65.10} {ping $addr}
tclquit
Note
7. BGP
Issue: Configure AS 23 on R2 and R3. Configure AS 4 on R4. Configure peering between the
following:
30
R4 and R2 (do not use loopback interfaces)
R4 and R3 (do not use loopback interfaces)
R4 and R1 (use loopbacks 1.1.1.1 and 4.4.4.4).
Advertise the network 4.4.4.0/24 in AS 4. Advertise the network 172.10.23.0/24 in AS 23.

Solution:
These fairly straightforward peering and advertising directions set the stage for the remaining
BGP tasks. For configuration details, see the online Mentor Guide engine.
Verify peering with the show ip bgp summary command. What follows is the result on R4. The
number of prefixes learned, at the end of each line, indicates a good peering. Entries such as
Active or Idle would indicate peering problems.
Issue: Configure AS 1 on R1. Configure peering between R1 and R4 by using the loopbacks
1.1.1.1 and 4.4.4.4. Advertise the network 1.1.1.0/24 in AS 1. Advertise the network 4.4.4.0/24 in
AS 4.
Solution:
This configuration creates a recursive routing issue. Here is an example from R1:
R1#
*Apr 22 23:57:01.799: %BGP-3-NOTIFICATION: received from neighbor 4.4.4.4 4/0
(hold time expired) 0 bytes
R1#
*Apr 22 23:57:01.799: %BGP-5-NBR_RESET: Neighbor 4.4.4.4 reset (BGP Notification
received)
*Apr 22 23:57:01.799: %BGP-5-ADJCHANGE: neighbor 4.4.4.4 Down BGP Notification
received
*Apr 22 23:57:01.799: %BGP_SESSION-5-ADJCHANGE: neighbor 4.4.4.4 IPv4 Unicast
topology base removed from session BGP Notification received
*Apr 22 23:57:02.021: %BGP-5-ADJCHANGE: neighbor 4.4.4.4 Up
R1#
Because the 1.1.1.0/24 and the 4.4.4.0/24 prefixes are advertised via EBGP speakers, the
administrative distance for these prefixes is set to 20. Since these same prefixes are used to form
the EBGP neighbor relationship between R1 and R4, they need to be learned via an IGP such as
OSPF or EIGRP.
Note
These prefixes have already been assigned to the EIGRP routing process.
To eliminate the problem, change the administrative distance for these prefixes on R1 and R4 so
that IGP routes are preferred to BGP routes. The easiest way to complete this change is by using
the BGP backdoor command.
Issue: Outbound traffic from a PC that is connected to the 172.10.23.0/24 subnet and destined to
the 4.4.4.0/24 network should flow through R2.
Solution:
This task influences the HSRP configuration that is specified later in this scenario.
31
Issue: Incoming traffic from the 4.4.4.0/24 network to a PC that is connected to the
172.10.23.0/24 subnet should flow through R2. If the DMVPN link on R2 becomes inactive, this
traffic should pass through R3.
Return the traffic pattern through R2 when the DMVPN link on R2 becomes active again.
Solution:
This task is also related to the HSRP configuration that is discussed later in this scenario. See the
following diagram for more detail on the BGP topology.
IPv4 BGP Diagram
HSRP Active
Tracking mGRE
interface
Outbound
Primary
Change AD of BGP next hop to prefer EIGRP route:

router bgp 4
address-family ipv4
network 1.1.1.0 mask 255.255.255.0 backdoor
AS 23
R2
R1
Inbound
Primary
1.1.1.1
AS 4
EBGP
IBGP
AS 1
EBGP
4.4.4.4
R4
EBGP
Inbound
Backup
R3
Outbound
Backup
Change AD of BGP next hop to prefer EIGRP route:

router bgp 1
address-family ipv4
HSRP
Standby
Issue: Make sure that BGP will use the minimal number of decision steps.
Solution:
Use the BGP administrative weight attribute, since it is the first attribute to be compared in the
BGP path selection process. Because it is the first attribute compared between two possible BGP
paths, it fulfills the configuration requirement of using the minimal number of BGP decision steps
to accomplish the stated task. Configure the weight on R4 to the prefixes received from R2 by
issuing the command neighbor 172.10.124.130 weight 10.
Configure the BGP on R1, R2, R3, and R4 according to the scenario requirements.
R1:
32
router bgp 1
bgp router-id 1.1.1.1
bgp log-neighbor-changes
network 1.1.1.0 mask 255.255.255.0
neighbor 4.4.4.4 remote-as 4
neighbor 4.4.4.4 ebgp-multihop 10
neighbor 4.4.4.4 update-source Loopback1
!
R2:
router bgp 23
network 172.10.23.0 mask 255.255.255.0
!
R3:
router bgp 23
network 172.10.23.0 mask 255.255.255.0
!
R4:
router bgp 4
network 4.4.4.0 mask 255.255.255.0
neighbor 1.1.1.1 ebgp-multihop 10
neighbor 1.1.1.1 update-source Loopback4
neighbor 172.10.124.130 weight 10
!
!
Verify the BGP prefixes on R1:

R1#show ip bgp
BGP table version is 8, local router ID is 1.1.1.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter,
x best-external, a additional-path, c RIB-compressed,
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found
*>
r>
*>
R1#
Network
1.1.1.0/24
4.4.4.0/24
172.10.23.0/24
Next Hop
0.0.0.0
4.4.4.4
4.4.4.4
Metric LocPrf Weight Path

0
32768 i
0
0 4 i
0 4 23 i
Verify the BGP prefixes on R4. Also verify that the preferred path to 172.10.23.0 is through R2:
33
R4#show ip bgp
r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter,
x best-external, a additional-path, c RIB-compressed,
RPKI validation codes: V valid, I invalid, N Not found
r>
*>
*
*>
R4#
Network
1.1.1.0/24
4.4.4.0/24
172.10.23.0/24
Note
Next Hop
1.1.1.1
0.0.0.0
172.10.43.3
172.10.124.130

0
0 1 i
0
32768 i
0
0 23 i
0
10 23 i
8. Traffic Optimization
Issue: Every minute, from now on, R1 should measure and record the time it takes to connect to
the Telnet server with the IP address 172.10.105.1on R5.
Solution:
Configure the tcp-connect command in the configuration of the IP SLA on R1. The default
frequency is 1 minute. Disable control packets, since the router natively supports the service and
no responder is configured. Verify the correct operation with the command show ip sla monitor
statistics. No special configuration is required on R5.
R1:
ip sla 23
tcp-connect 172.10.105.1 23 control disable
ip sla schedule 23 life forever start-time now
!
R1#show ip sla statistics
IPSLAs Latest Operation Statistics
IPSLA operation id: 23
Latest RTT: 1 milliseconds
Latest operation start time: 16:39:12 PST Mon Apr 22 2013
Latest operation return code: OK
Number of successes: 3
Number of failures: 0
Operation time to live: Forever
R1#
34
Note
35
9. IPv6 Routing
Issue: Assign IPv6 addresses.
Solution:
Configure IPv6 addresses on R1, R2, R3, and R4 according to the scenario requirements.
Enter the command IPv6 unicast-routing in global configuration mode.
Assign the required addresses to the interfaces.
These tasks are shown here for R3:

ipv6 unicast-routing
!
ip address 172.10.32.3 255.255.255.0 secondary
ip address 172.10.23.3 255.255.255.0
ipv6 address FEC0:23::3/64
!
interface Serial1/0
ip address 172.10.43.3 255.255.255.0
ipv6 address FE80::3 link-local
serial restart-delay 0
!
Make sure that you can ping within the same subnet before moving forward. Can R3 ping all of
the addresses on the connected links?
R3#ping FE80::4
Output Interface: serial1/0
Sending 5, 100-byte ICMP Echos to FE80::4, timeout is 2 seconds:
Packet sent with a source address of FE80::3%Serial1/0
!!!!!
R3#
R3#ping FEC0:23::2
Sending 5, 100-byte ICMP Echos to FEC0:23::2, timeout is 2 seconds:
!!!!!
R3#
Issue: Configure IPv6 BGP peers by using directly connected global IPv6 addresses.
Solution:
The routers are peered just as they were for the IPv4 BGP exercise, as shown in the IPv6 BGP
diagram.
36
IPv6 BGP Diagram
AS 23
Preferred Exit
FEC0:10:10::/47
R2
R1
FEC0:10:10::1/64
FEC0:10:11::1/64
FEC0:10:12::1/64
FEC0:10:13::1/64
FEC0:10:14::1/64
FEC0:10:15::1/64
FEC0:10:16::1/64
FEC0:10:17::1/64
AS 4
IBGP
EBGP
EBGP
Aggregate
FEC0:10:14::/46
AS 1
R4
EBGP
R3
Preferred Exit
FEC0:10:12::/47
Under the primary BGP process, configure the neighbor and the remote autonomous system (AS).
Then activate the neighbor with the address-family ipv6 command. Here is the relevant part of
the configuration on R2:
router bgp 23
neighbor FEC0:23::3 remote-as 23
neighbor FEC0:124::131 remote-as 4
no auto-summary
!
address-family ipv6
neighbor FEC0:23::3 activate
exit-address-family
Verify the required peering. The output here shows five prefixes learned from R3 and seven
learned from R4. This output reflects the number of BGP updates that is expected when this entire
lab is completed. You might not see any BGP updates at this stage. Entries of active or idle
under PfxRcd would indicate failed peering.
R2#show bgp ipv6 unicast summary | inc ^FE
FEC0:23::3
4
23
18
5
FEC0:124::131
4
4
18
7
R2#
20
23
0 00:10:50
16
23
0 00:09:20
Issue: Use network statements to advertise all connected IPv6 addresses into BGP. All IPv6
addresses should be reachable within the IPv6 BGP domain.
37
Solution:
Under the IPv6 address family on each IPv6 router, issue a network statement for each connected,
global IPv6 prefix. You are using BGP to provide IPv6 reachability throughout the pod. Since
you are peering to directly connected addresses, there should not be recursive routing or peering
address issues. Here is the relevant configuration from R2:
router bgp 23
!
address-family ipv6
network FEC0:23::/64
exit-address-family
Issue: Add the following prefixes to loopback 0 on R1. Advertise the prefixes into BGP with a
single statement. AS 23 should see only an aggregate for the highest four of these addresses. R1
should not see this aggregate.
Solution:
The simplest way to advertise these eight addresses into BGP is to issue the command
redistribute connected under the IPv6 address family on R1. To avoid seeing the aggregate on
R1, create it on R4 using the as-set keyword. This keyword preserves the AS path attribute,
causing R1 to drop the update. If you are not used to seeing IP addresses in hexadecimal format, it
may not be apparent that these four addresses fall on a very neat bit boundary. Here are the first
48 bits of each address:
FEC0:10:14
FEC0:10:15
FEC0:10:16
FEC0:10:17
=
=
=
=
1111 1110
1111 1110
1111 1110
1111 1110
16 bits
1100
1100
1100
1100
0000
0000
0000
0000
:
:
:
:
0000 0000
0000 0000
0000 0000
0000 0000
16 bits
0001
0001
0001
0001
0000
0000
0000
0000
:
:
:
:
0000
0000
0000
0000
16
0000
0000
0000
0000
bits
0001
0001
0001
0001
0100
0101
0110
0111
:
:
:
:
Of the first 48 bits in each address, only the last two vary. Since the first 46 bits are identical, you
can summarize them as FEC0:10:14::/46.
Here is the relevant configuration from R4:
router bgp 4
address-family ipv6
aggregate-address FEC0:10:14::/46 as-set summary-only
exit-address-family
!
Here is a Tcl script you can use to test for universal IPv6 reachability:
tclsh
foreach address {
FEC0:10:10::1
FEC0:10:11::1
FEC0:10:12::1
FEC0:10:13::1
FEC0:10:14::1
FEC0:10:15::1
FEC0:10:16::1
FEC0:10:17::1
FEC0:124::129
38
FEC0:23::2
FEC0:124::130
FEC0:23::3
FEC0:43::3
FEC0:124::131
FEC0:43::4
} {ping $address}
Issue: Traffic that leaves AS 23 for the prefixes FEC0:10:10::/64 and FEC0:10:11::/64 should
have a next hop of FEC0:124::129. Traffic that leaves AS 23 for the prefixes FEC0:10:12::/64
and FEC0:10:13::/64 should have a next hop of FEC0:43::4.
Solution:
Local preference is commonly used within a dual-homed AS to indicate a preferred exit. Because
R2 is preferred as the exit for the prefixes that start with FEC0:10:10::/47, you raise the local
preference on these prefixes as they arrive at R2. You raise the local preference on the prefixes
that start with FEC0:10:12::/47 as they arrive at R3. The following is the relevant configuration
for R2, and the R3 configuration is similar. Remember to reset your peers when you change
policy. Some prefer the command clear ip BGP *. Others prefer to add the soft keyword.
ipv6 prefix-list LOCALPREF seq 5 permit FEC0:10:10::/47 ge 64 le 64
route-map LOCALPREF permit 10
match ipv6 address prefix-list LOCALPREF
set local-preference 200
address-family ipv6
neighbor FEC0:124::131 route-map LOCALPREF in
In the partial BGP table that follows, notice that R2 prefers the EBGP paths to the first two
prefixes, and the IBGP paths to the other two, based on the local preference attributes. Note that
the next hop for FEC0:10:10::/64 is the address for R1, even though R2 is not peering with R1.
BGP is smart enough to use a forwarding address when peers are on a shared network. Note that
when you reload your devices, you may need to enter the clear ip bgp * soft in and clear ipv6
route * commands on R2 in order to see FEC0:124::129 instead of FEC0:124::131 as the next
hop for the subnets FEC0:10:10::/64 and FEC0:10:11::/64.
R2#show bgp IPv6 unicast
r RIB-failure, S Stale
Network
*> FEC0:10:10::/64
*> FEC0:10:11::/64
* FEC0:10:12::/64
*>i
* FEC0:10:13::/64
*>i
Note
Next Hop
FEC0:124::129
FEC0:124::129
FEC0:124::129
FEC0:43::4
FEC0:124::129
FEC0:43::4

200
0 4 1 ?
200
0 4 1 ?
0 4 1 ?
0
200
0 4 1 ?
0 4 1 ?
0
200
0 4 1 ?
10. Quality of Service
39
Issue: Allocate a reservable bandwidth of 60 kb/s on the interfaces that are involved in this
section. Send a Path message from R4 to R5 requesting bandwidth reservation for Telnet that is
sourced from 172.10.43.4 port 5000 on R4 and destined to 172.10.35.5 port 23 on R5. Make sure
that you have a single reservation for a guaranteed bit rate of 5 kb/s that allows bursts up to 2 KB.
Verify the reservation setup with the command show ip rsvp reservation.
Solution:
Configure Resource Reservation Protocol (RSVP) bandwidth on all interfaces that make up the
path between R4 and R5. Two interfaces on R3 are included. You can send the Path message for
the specified application from R4 to R5 by configuring the ip rsvp sender-host command on R4.
This command enables a router to simulate a host generating RSVP Path messages. Configure R5
with the ip rsvp reservation-host command to behave as though it is continuously receiving an
RSVP reservation message (Resv message) from the originator containing the indicated attributes.
The ip rsvp reservation-host command enables a router to simulate a host generating Resv
messages.
1. Reserve the bandwidth along the IP forwarding path between R4 and R5 to enable the
forwarding of Path IP messages:
R4
interface Serial1/0
ip address 172.10.43.4 255.255.255.0
ip rsvp bandwidth 60
R3
interface Seria1/0
ip address 172.10.43.3 255.255.255.0
!
interface e0/1
ip address 172.10.35.3 255.255.255.0
R5
interface e0/0.30
ip address 172.10.35.5 255.255.255.0
2. Simulate a Path message on R4 and an Resv message on R5:

R4
ip rsvp sender-host 172.10.35.5 172.10.43.4 TCP 23 5000 5 2
To see the Path message, turn on the following debug:

R4#deb ip rsvp dump-messages path
RSVP message dump debugging is on
R4#
*Apr 23 02:06:43.846: Outgoing Path:
*Apr 23 02:06:43.846:
version:1 flags:0000 cksum:7978 ttl:255 reserved:0
length:136
*Apr 23 02:06:43.846: SESSION
type 1 length 12:
*Apr 23 02:06:43.846:
Destination 172.10.35.5, Protocol_Id 6, Don't Police ,
DstPort 23
*Apr 23 02:06:43.846: HOP
type 1 length 12:
*Apr 23 02:06:43.846:
Hop Addr: 172.10.43.4 LIH: 0x02000403
*Apr 23 02:06:43.846: TIME_VALUES
type 1 length 8 :
*Apr 23 02:06:43.846:
Refresh Period (msec): 30000
40
*Apr
*Apr
*Apr
*Apr
*Apr
*Apr
*Apr
*Apr
*Apr
*Apr
*Apr
*Apr
R4#
*Apr
*Apr
*Apr
*Apr
*Apr
*Apr
R4#
23
23
23
23
23
23
23
23
23
23
23
23
02:06:43.846:
02:06:43.846:
02:06:43.846:
02:06:43.846:
02:06:43.846:
02:06:43.846:
02:06:43.846:
02:06:43.846:
02:06:43.846:
02:06:43.846:
02:06:43.846:
02:06:43.846:
SENDER_TEMPLATE
type 1 length 12:
Sender address: 172.10.43.4, port: 5000
SENDER_TSPEC
type 2 length 36:
version=0, length in words=7
Token bucket fragment (service_id=1, length=6 words
parameter id=127, flags=0, parameter length=5
average rate=625 bytes/sec, burst depth=2000 bytes
peak rate
=625 bytes/sec
min unit=0 bytes, max pkt size=2147483647 bytes
ADSPEC
type 2 length 48:
version=0 length in words=10
General Parameters break bit=0 service length=8
23
23
23
23
23
23
02:06:43.846:
02:06:43.846:
02:06:43.846:
02:06:43.846:
02:06:43.846:
02:06:43.846:
IS Hops:1
Minimum Path Bandwidth (bytes/sec):193000
Path Latency (microseconds):0
Path MTU:1500
Controlled Load Service break bit=0 service length=0
R5
ip rsvp reservation-host 172.10.35.5 172.10.43.4 TCP 23 5000 FF RATE 5 2
To see the Resv message, turn on the following debug:

debug ip rsvp dump-messages resv
R5#debug ip rsvp dump-messages resv
RSVP message dump debugging is on
R5#
*Apr 23 02:09:07.508: Outgoing Resv:
*Apr 23 02:09:07.508:
version:1 flags:0000 cksum:EDB0 ttl:255 reserved:0
length:108
*Apr 23 02:09:07.508: SESSION
type 1 length 12:
*Apr 23 02:09:07.508:
Destination 172.10.35.5, Protocol_Id 6, Don't Police ,
DstPort 23
*Apr 23 02:09:07.508: HOP
type 1 length 12:
*Apr 23 02:09:07.508:
Hop Addr: 172.10.35.5 LIH: 0x02000402
*Apr 23 02:09:07.508: TIME_VALUES
type 1 length 8 :
*Apr 23 02:09:07.508:
Refresh Period (msec): 30000
*Apr 23 02:09:07.508: STYLE
type 1 length 8 :
*Apr 23 02:09:07.508:
Fixed-Filter (FF)
*Apr 23 02:09:07.508: FLOWSPEC
type 2 length 48:
R5#
*Apr 23 02:09:07.508:
version = 0 length in words = 10
*Apr 23 02:09:07.508:
service id = 2, service length = 9
*Apr 23 02:09:07.508:
tspec parameter id = 127, flags = 0,length = 5
*Apr 23 02:09:07.508:
average rate = 625 bytes/sec, burst depth = 2000 bytes
*Apr 23 02:09:07.508:
peak rate
= 625 bytes/sec
*Apr 23 02:09:07.508:
min unit = 0 bytes,max pkt size = 0 bytes
*Apr 23 02:09:07.508:
rspec parameter id=130,rspec flags=0, rspec length=2
*Apr 23 02:09:07.508:
requested rate=625, slack=0
*Apr 23 02:09:07.508: FILTER_SPEC
type 1 length 12:
*Apr 23 02:09:07.508:
SrcAddress 172.10.43.4, SrcPort 5000
*Apr 23 02:09:07.508:
R5#
3. Verify that the reservation is made on all three routers:

R4#show ip rsvp reservation
To
From
Pro DPort Sport Next Hop
172.10.35.5
172.10.43.4
TCP 23
5000 172.10.43.3
R4#
To
From
I/F
Se1/0
Fi Serv BPS
FF RATE 5K
I/F
Fi Serv BPS
41
172.10.35.5
R3#
172.10.43.4
TCP 23
5000
172.10.35.5

To
From
172.10.35.5
172.10.43.4
TCP 23
5000 none
R5#
Note
Et0/1
FF RATE 5K
I/F
none
Fi Serv BPS
FF RATE 5K
11. System Administration

Issue: Assign the IP address of 172.10.23.1 to the virtual gateway. Make sure that the MAC
address that is associated with the virtual gateway is set to 0000.0c07.ac14.
Solution:
To use the MAC address that is specified above, assign the value of 20 to the standby group.
The standby group number is in decimal format. The decimal standby group number gets
translated into hexadecimal format and is used as the last two hexadecimal digits of the MAC
address that is used by HSRP to communicate with other HSRP speakers. When you translate
20 from decimal to hexadecimal, you end up with 0x14.
Issue:
Authenticate HSRP on the 172.10.23.0/24 subnet (with the password test). Make sure
that hello packets are exchanged three times faster than by default.
Solution:
The default HSRP hello time is 3 seconds. Therefore, set it to 1 second. Also, configure HSRP
authentication between the HSRP peers. Configure HSRP timers by issuing the command
standby 20 timers 1 4. Authenticate HRSP adjacencies with the command standby 20
authentication test.
Issue: Select the preferred gateway that is most suitable for other tasks in this lab by using
priority 150.
Solution:
The BGP section requires that devices on the VLAN 10 link prefer R2 as an exit, unless the
DMVPN tunnel interface is down. The following configuration on R2 helps achieve that result by
making it primary, unless the tracked interface becomes inactive. The decrement value of 51
would reduce the priority to 99, which is one below the default priority of 100 on R3.
Configure the HSRP on R2 and R3.
R2:
track 1 interface Tunnel124 line-protocol
!
ip address 172.10.23.2 255.255.255.0
standby 20 ip 172.10.23.1
standby 20 timers 1 4
standby 20 priority 150
standby 20 preempt
standby 20 authentication test
standby 20 track 1 decrement 51
42
R3:
ip address 172.10.32.3 255.255.255.0 secondary
ip address 172.10.23.3 255.255.255.0
standby 20 ip 172.10.23.1
standby 20 timers 1 4
standby 20 preempt
standby 20 authentication test
!
Issue the show standby command on R2 and R3:

R2#show standby
Ethernet0/0 - Group 20
State is Active
5 state changes, last state change 00:01:25
Virtual IP address is 172.10.23.1
Active virtual MAC address is 0000.0c07.ac14
Local virtual MAC address is 0000.0c07.ac14 (v1 default)
Hello time 1 sec, hold time 4 sec
Next hello sent in 0.944 secs
Authentication text, string "test"
Preemption enabled
Active router is local
Standby router is 172.10.23.3, priority 100 (expires in 3.744 sec)
Priority 150 (configured 150)
Track interface Tunnel124 state Up decrement 51
Group name is "hsrp-Et0/0-20" (default)
R2#
R3#show standby
Ethernet0/0 - Group 20
State is Standby
4 state changes, last state change 00:03:40
Virtual IP address is 172.10.23.1
Active virtual MAC address is 0000.0c07.ac14
Local virtual MAC address is 0000.0c07.ac14 (v1 default)
Hello time 1 sec, hold time 4 sec
Next hello sent in 0.240 secs
Authentication text, string "test"
Preemption enabled
Active router is 172.10.23.2, priority 150 (expires in 4.112 sec)
Standby router is local
Priority 100 (default 100)
Group name is "hsrp-Et0/0-20" (default)
R3#
Note that the show standby command shows all the parameters that are required by the scenario
specifications. R2 is the active HSRP router.
Test the HSRP group failover operations. Shut down the Tunnel124 interface on R2:
R2#conf t
R2(config)#int tu124
R2(config-if)#shut
R2(config-if)#
*Apr 23 12:04:59.919: %TRACKING-5-STATE: 1 interface Tu124 line-protocol Up>Down
*Apr 23 12:04:59.924: %BGP-5-NBR_RESET: Neighbor 172.10.124.131 reset (Interface
flap)
43
*Apr 23 12:04:59.924: %DUAL-5-NBRCHANGE: EIGRP-IPv4 100: Neighbor 172.10.124.129

(Tunnel124) is down: interface down
*Apr 23 12:04:59.925: %BGP-5-ADJCHANGE: neighbor 172.10.124.131 Down Interface
flap
*Apr 23 12:04:59.925: %BGP_SESSION-5-ADJCHANGE: neighbor 172.10.124.131 IPv4
Unicast topology base removed from session Interface flap
*Apr 23 12:05:00.130: %HSRP-5-STATECHANGE: Ethernet0/0 Grp 20 state Active ->
Speak
R2(config-if)#
*Apr 23 12:05:01.923: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel124,
changed state to down
*Apr 23 12:05:01.924: %LINK-5-CHANGED: Interface Tunnel124, changed state to
administratively down
R2(config-if)#
*Apr 23 12:05:04.409: %HSRP-5-STATECHANGE: Ethernet0/0 Grp 20 state Speak ->
Standby
R2(config-if)#
Note that R2 transitioned from the active state to speak and to standby.
Bring the Tunnel124interface back up on R2:
R2(config-if)#no shut
R2(config-if)#end
*Apr 23 12:05:42.580: %TRACKING-5-STATE: 1 interface Tu124 line-protocol Down>Up
*Apr 23 12:05:43.057: %HSRP-5-STATECHANGE: Ethernet0/0 Grp 20 state Standby ->
Active
*Apr 23 12:05:44.009: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel124,
changed state to up
R2(config-if)#end
R2#
Note that R2 transitioned from the standby state to active.

Issue: On R6, make sure that all changes that are made to the current configuration are logged.
Double the size of the configuration logging buffer. All changes should also be sent to a server
located at 172.10.65.65.
Solution:
According to the Cisco Configuration Guide:
The Configuration Change Notification and Logging (Configuration Logging)
feature allows the tracking of configuration changes that are entered on a persession and per-user basis by implementing a configuration log. The
configuration log will track each configuration command that is applied, who
applied the command, the parser return code for that command, and the time that
the command was applied. This feature also adds a notification mechanism that
sends asynchronous notifications to registered applications whenever the
configuration logging changes.
According to the Cisco Command Reference:
To specify the maximum number of entries retained in the configuration log, use
the logging size command in configuration change logger configuration mode.
When the configuration log is full, the oldest log entry will be removed every
time a new entry is added. The maximum number of entries is retained in the
configuration log. Valid values range from 1 to 1000. The default value is 100
entries.
44
Enter the following commands on R6:

logging 172.10.65.65
archive
log config
logging enable
logging size 200
notify syslog
Note
12. Multicast
Issue: Configure R3 to query for multicast membership every 30 seconds. Each host should reply
within 15 seconds.
Solution:
According to the Cisco Configuration Guide:
Multicast routers send IGMP host query messages to discover which multicast
groups are present on attached networks. These messages are sent to the allsystems group address of 224.0.0.1 with a TTL of 1. Multicast routers send host
query messages periodically to refresh their knowledge of memberships present
on their networks. If, after some number of queries, the Cisco IOS Software
discovers that no local hosts are members of a multicast group, the software
stops forwarding onto the local network multicast packets from remote origins
for that group and sends a prune message upstream toward the source.
Enter the following commands under interface E0/1 on R3:
ip igmp query-interval 30
ip igmp query-max-response-time 15
Issue: If R3 stops sending Internet Group Management Protocol (IGMP) queries on VLAN 30,
R5 should take over R3 twice as fast as the default value.
Solution:
According to the Cisco Command Reference:
To configure the timeout period before the router takes over to query on behalf of
the interface after the previous queries have stopped, use the ip igmp queriertimeout command in interface configuration mode. Indicate the number of
seconds that the router waits after the previous querier has stopped querying and
before it takes over as the querier. The range is from 30 to 300 seconds. The
default timeout period is two times the query interval. The default query interval
is 60 seconds.
Enter the following command under interface E0/0.30 on R5:
ip igmp querier-timeout 60
Issue: Join dense group 229.50.50.50 on the interface loopback 105 of R5.
45
Solution:
Configure the ip pim dense-mode and ip igmp join-group 229.50.50.50 commands under the
specified interface of R5.
Issue: Make sure that you can ping 229.50.50.50 from R1.
Solution:
R1 is the source of the multicast ping and R1 is connected to the first-hop multicast router R4 via
the DMVPN. You need to provide a mapping for the multicast traffic between R1 and R4.
When you fulfill this configuration requirement, carefully determine whether there is a Reverse
Path Forwarding (RPF) lookup issue on any of the routers. Since the ping is originating from R1,
the multicast packets will get forwarded to R4, and R4 will then forward them out to all its
interfaces.
Multicast Diagram
Multicast to
229.50.50.50
R1
Tu124: 124.129/25
SPARSE-DENSE
R4
Tu124: 124.131/25
S1/0: 43.4/24
E0/0.30: 35.5/24
R3
E0/1: 35.3/24
Lo105: 105.1/24
S1/0: 43.3/24
R5
igmp join
229.50.50.50
There is an RPF check failure on R3 toward the source of multicast traffic. R3 prefers the path to
the source over E1/0, whereas traffic comes from R4, which is on the slower path to R1. To make
the RPF check successful, a static multicast route (mroute) is added on R3, pointing to the IP
address of the S1/0 interface on R4 as the next hop toward the source. Configure a static mroute
on R3 by issuing the command ip mroute 172.10.124.129 255.255.255.255 172.10.43.4.
Apply the multicast configuration on R1, R3, R4, and R5.
R1:
interface Tunnel124
ip address 172.10.124.129 255.255.255.128
46
no ip redirects
no ip split-horizon eigrp 100
ip nhrp map multicast 10.10.1.4
tunnel key 10
!
R3:
ip multicast-routing
!
ip address 172.10.35.3 255.255.255.0
ip pim sparse-dense-mode
ip igmp query-max-response-time 15
ip igmp query-interval 30
!
interface Serial1/0
ip address 172.10.43.3 255.255.255.0
!
ip mroute 172.10.124.129 255.255.255.255 172.10.43.4
R4:
!
interface Tunnel124
ip address 172.10.124.131 255.255.255.128
no ip redirects
ip nhrp map 172.10.124.129 10.10.1.1
ip nhrp map multicast 10.10.1.1
ip nhrp nhs 172.10.124.129
tunnel key 10
!
interface Serial1/0
ip address 172.10.43.4 255.255.255.0
!
R5:
!
ip address 172.10.105.1 255.255.255.0
ip igmp join-group 229.50.50.50
47

!
ip address 172.10.35.5 255.255.255.0
ip igmp querier-timeout 60
!
You can verify the static mroute with the command show ip mroute static on R3:
R3#show ip mroute static
Mroute: 172.10.124.129/32, RPF neighbor: 172.10.43.4, distance: 1
R3#
To verify its operation, enter the mtrace command to the source address:
R3#mtrace 172.10.124.129
Mtrace from 172.10.124.129 to 172.10.23.3 via RPF
From source (?) to destination (?)
Querying full reverse path...
0 172.10.23.3
-1 172.10.23.3 ==> 172.10.43.3 PIM_MT [172.10.124.129/32]
-2 172.10.43.4 ==> 172.10.124.131 PIM_MT [172.10.124.128/25]
-3 172.10.124.129
R3#
Note that the 172.10.23.3 outgoing interface is overridden by the static mroute.
Verify a ping from R1:
R1#ping 229.50.50.50 rep 5
Reply
Reply
Reply
Reply
Reply
R1#
Note
48
to
to
to
to
to
request
request
request
request
request
0
1
2
3
4
from
from
from
from
from
172.10.105.1,
172.10.105.1,
172.10.105.1,
172.10.105.1,
172.10.105.1,
67 ms
9 ms
9 ms
9 ms
9 ms

360rsw05 WKB Ca01 Ak PDF

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

360rsw05 WKB Ca01 Ak PDF

Uploaded by

Copyright:

Available Formats

360RSW05-WKB-CA01

Cisco 360 CCIE R&S Exercise

Cisco 360 CCIE R&S Exercise

Cisco 360 CCIE R&S Exercise Workbook Lab 1 Answer Key

2013 Cisco Systems, Inc.

Exercise Workbook Lab 1 Configuration Section Answer Key .............................................. 5

Switch Configuration .......................................................................................................................... 8

2013 Cisco Systems, Inc.

Cisco 360 CCIE R&S Exercise Workbook Lab 1 Answer Key

Answer Key Structure

Cisco 360 CCIE R&S Exercise Workbook Lab 1 Answer Key

2013 Cisco Systems, Inc.

Exercise Workbook Lab 1

Grading and Duration

Configuration lab duration:

Restrictions and Goals

Read this section carefully.

Do not use any static routes.

Advertise loopback interfaces with their original masks.

Do not introduce any new IP addresses.

2013 Cisco Systems, Inc.

Cisco 360 CCIE R&S Exercise Workbook Lab 1 Answer Key

Do not modify the initial interface or IP address numbering.

Cisco 360 CCIE R&S Exercise Workbook Lab 1 Answer Key

2013 Cisco Systems, Inc.

Explanation of Each of the Restrictions and Goals

2013 Cisco Systems, Inc.

Cisco 360 CCIE R&S Exercise Workbook Lab 1 Answer Key

Use conventional routing algorithms only, unless specified otherwise.

Set the Virtual Trunking Protocol (VTP) mode.

Configure the VLANs and the VLAN names.

Configure the trunk ports.

Statically assign the ports of the switches to the VLANs.

Cisco 360 CCIE R&S Exercise Workbook Lab 1 Answer Key

2013 Cisco Systems, Inc.

E0/0 E0/1 E0/2 E0/3 E1/0 E1/1

E1/1 E1/0 E0/3 E0/2 E0/1 E0/0

Issue: Do not use any dynamic VLAN advertisement protocol.

Cisco 360 CCIE R&S Exercise Workbook Lab 1 Answer Key

VTP Operating Mode

Cisco 360 CCIE R&S Exercise Workbook Lab 1 Answer Key

2013 Cisco Systems, Inc.

Issue: Use the IEEE 802.1Q protocol for trunking.

Cisco 360 CCIE R&S Exercise Workbook Lab 1 Answer Key

Configure the switch-to-switch connections according to the Switch-to-Switch Connections

Cisco 360 CCIE R&S Exercise Workbook Lab 1 Answer Key

2013 Cisco Systems, Inc.

Shut down the following interfaces:

Shut down the following interfaces:

Shut down the following interfaces:

Cisco 360 CCIE R&S Exercise Workbook Lab 1 Answer Key

switchport trunk encapsulation dot1q

Shut down the following interfaces:

switchport port-security mac-address 0007.8592.D0E7

Verify the status of the switch port security:

Cisco 360 CCIE R&S Exercise Workbook Lab 1 Answer Key

2013 Cisco Systems, Inc.

2013 Cisco Systems, Inc.

Cisco 360 CCIE R&S Exercise Workbook Lab 1 Answer Key

Cisco 360 CCIE R&S Exercise Workbook Lab 1 Answer Key

2013 Cisco Systems, Inc.

ip nhrp map 172.10.124.129 10.10.1.1