For Cisco's CCIE Routing & Switching Lab Exam, Lab 2

for Cisco's CCIE Routing & Switching Lab Exam, Lab 2
(v5)
CCIE Routing & Switching

Volume 2 Detailed Solution Guide
Lab 2
Version 5.1A
iPexpert's Detailed Solution Guide
for Cisco's CCIE Routing and Switching Lab Exam, Volume 2, Lab 2
Table of Contents
iPexpert's End-User License Agreement ................................................................................................................................. 4
U.S. Government - Restricted Rights....................................................................................................................................... 5
Welcome, and Thank You! ...................................................................................................................................................... 6
Feedback.................................................................................................................................................................................. 6
Technical Support and Freebies .............................................................................................................................................. 6
How to Use This Lab Preparation Workbook .......................................................................................................................... 7
Cisco's New Retake Policy ....................................................................................................................................................... 8
Cisco R&S V5 Blueprint (Primary Sections w/ Assigned Point Values) ................................................................................... 8
How to Use This Lab Preparation Workbook .......................................................................................................................... 8
Additional Information Pertaining to Cisco's CCIE R&S Lab Exam .......................................................................................... 8
Lab 2: Troubleshooting Section :: Detailed Solutions...................................................................................................................... 11
Detailed Solution Guide ........................................................................................................................................................11
General Rules ........................................................................................................................................................................11
Pre-Setup ...............................................................................................................................................................................12
Diagram 2.1: Layer 2 .............................................................................................................................................................13
Diagram 2.2: BGP ..................................................................................................................................................................14
Incident 1 .............................................................................................................................................................. 15
Incident 2...............................................................................................................................................................................19
Incident 3 ..............................................................................................................................................................................24
Incident 4...............................................................................................................................................................................33
Incident 5...............................................................................................................................................................................37
Incident 6...............................................................................................................................................................................41
Incident 7...............................................................................................................................................................................45
Incident 8...............................................................................................................................................................................50
Incident 9...............................................................................................................................................................................54
Incident 10.............................................................................................................................................................................59
Lab 2: Diagnostic Section :: Detailed Solutions ............................................................................................................................... 63
Before You Begin ...................................................................................................................................................................63
General Rules ........................................................................................................................................................................63
Ticket 1 ..................................................................................................................................................................................64
Ticket 2 ..................................................................................................................................................................................68
Ticket 3 ..................................................................................................................................................................................71
Lab 2: Configuration Section :: Detailed Solutions .......................................................................................................................... 73
Before You Begin ...................................................................................................................................................................73
General Rules ........................................................................................................................................................................73
Pre-Setup ...............................................................................................................................................................................74
Diagram 2.3: ..........................................................................................................................................................................75
Diagram 2.4: BGP...................................................................................................................................................................76
Diagram 2.5: IPv4 VPN...........................................................................................................................................................77
Diagram 2.6: IPv6 ..................................................................................................................................................................78
Diagram 2.7: MPLS VPN ........................................................................................................................................................79
Section 1.0: Layer 2 Technologies .............................................................................................................................................. 80
Task 1.1: Layer 2 VLANs ......................................................................................................................................... 80
Task 1.2: Switch-to-Switch Links ..........................................................................................................................................88
Version 5.1A
2|Page
iPexpert's Detailed Soluiton Guide

Task 1.3: Router Links ...........................................................................................................................................................92
Task 1.4: Spanning-Tree Tuning ...........................................................................................................................................97
Task 1.5: Verify Connectivity ...............................................................................................................................................104
Section 2.0: IP Routing..............................................................................................................................................................105
Task 2.1: EIGRP AS 111 ........................................................................................................................................................105
Task 2.2: EIGRP 112 ............................................................................................................................................................109
Task 2.3: OSPF Area 0 .........................................................................................................................................................111
Task 2.4: BGP HQ MPLS Core ..........................................................................................................................................114
Task 2.5: BGP Dallas, TX ...................................................................................................................................................116
Task 2.6: BGP Seattle HQ .................................................................................................................................................117
Task 2.7: BGP TeleWorkers and Distro-Center ...............................................................................................................119
Task 2.8: IPv6 ......................................................................................................................................................................120
Table 2.8 ..............................................................................................................................................................................121
Task 2.9: Multicast ..............................................................................................................................................................125
Section 3.0: IPv4 VPN ...............................................................................................................................................................127
Task 3.1: MPLS VPN ............................................................................................................................................................127
Task 3.2: DMVPN ................................................................................................................................................................132
Task 3.3: DMVPN Encryption ..............................................................................................................................................136
Task 3.4: Virtual Tunnel Interfaces .....................................................................................................................................139
Section 4.0: Infrastructure Security ........................................................................................................................................146
Task 4.1: Time Based Access-List ........................................................................................................................................146
Task 4.2: Device Hardening ................................................................................................................................................147
Section 5.0: Infrastructure Services ............................................................................................................................. 149
Task 5.1: Config Backups ....................................................................................................................................................149
Task 5.2: Address Administration .......................................................................................................................................150
Technical Verification and Support...........................................................................................................................................151
3|P a g e
Version 5.1A

iPexpert's End-User License Agreement

END USER LICENSE FOR ONE (1) PERSON ONLY
IF YOU DO NOT AGREE WITH THESE TERMS AND CONDITIONS,
DO NOT OPEN OR USE THE TRAINING MATERIALS.
This is a legally binding agreement between you and IPEXPERT, the Licensor, from whom you have licensed the IPEXPERT training materials (the
Training Materials). By using the Training Materials, you agree to be bound by the terms of this License, except to the extent these terms have
been modified by a written agreement (the Governing Agreement) signed by you (or the party that has licensed the Training Materials for your
use) and an executive officer of Licensor. If you do not agree to the License terms, the Licensor is unwilling to license the Training Materials to
you. In this event, you may not use the Training Materials, and you should promptly contact the Licensor for return instructions.
The Training Materials shall be used by only ONE (1) INDIVIDUAL who shall be the sole individual authorized to use the Training Materials
throughout the term of this License.
Copyright and Proprietary Rights
The Training Materials are the property of IPEXPERT, Inc. ("IPEXPERT") and are protected by United States and International copyright laws. All
copyright, trademark, and other proprietary rights in the Training Materials and in the Training Materials, text, graphics, design elements, audio,
and all other materials originated by IPEXPERT at its site, in its workbooks, scenarios and courses (the "IPEXPERT Information") are reserved to
IPEXPERT.
The Training Materials cannot be used by or transferred to any other person. You may not rent, lease, loan, barter, sell or time-share the Training
Materials or accompanying documentation. You may not reverse engineer, decompile, or disassemble the Training Materials. You may not
modify, or create derivative works based upon the Training Materials in whole or in part. You may not reproduce, store, upload, post, transmit,
download or distribute in any form or by any means, electronic, mechanical, recording or otherwise any part of the Training Materials and
IPEXPERT Information other than printing out or downloading portions of the text and images for your own personal, non-commercial use
without the prior written permission of IPEXPERT.
You shall observe copyright and other restrictions imposed by IPEXPERT. You may not use the Training Materials or IPEXPERT Information in any
manner that infringes the rights of any person or entity.
Exclusions of Warranties
THE TRAINING MATERIALS AND DOCUMENTATION ARE PROVIDED AS IS. LICENSOR HEREBY DISCLAIMS ALL OTHER WARRANTIES, EXPRESS,
IMPLIED, OR STATUTORY, INCLUDING WITHOUT LIMITATION, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
PURPOSE. SOME STATES DO NOT ALLOW THE LIMITATION OF INCIDENTAL DAMAGES OR LIMITATIONS ON HOW LONG AN IMPLIED WARRANTY
LASTS, SO THE ABOVE LIMITATIONS OR EXCLUSIONS MAY NOT APPLY TO YOU. This agreement gives you specific legal rights, and you may have
other rights that vary from state to state.
Choice of Law and Jurisdiction
This Agreement shall be governed by and construed in accordance with the laws of the State of Michigan, without reference to any conflict of law
principles. You agree that any litigation or other proceeding between you and Licensor in connection with the Training Materials shall be brought
in the Michigan state or courts located in Port Huron, Michigan, and you consent to the jurisdiction of such courts to decide the matter. The
parties agree that the United Nations Convention on Contracts for the International Sale of Goods shall not apply to this License. If any provision
of this Agreement is held invalid, the remainder of this License shall continue in full force and effect.
Limitation of Claims and Liability
ANY ACTION ON ANY CLAIM AGAINST IPEXPERT MUST BE BROUGHT BY THE USER WITHIN ONE (1) YEAR FOLLOWING THE DATE THE CLAIM FIRST
ACCRUED, OR SHALL BE DEEMED WAIVED. IN NO EVENT WILL THE LICENSORS LIABILITY UNDER, ARISING OUT OF, OR RELATING TO THIS
AGREEMENT EXCEED THE AMOUNT PAID TO LICENSOR FOR THE TRAINING MATERIALS. LICENSOR SHALL NOT BE LIABLE FOR ANY SPECIAL,
INCIDENTAL, INDIRECT, OR CONSEQUENTIAL DAMAGES, HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, REGARDLESS OF WHETHER
LICENSOR HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. WITHOUT LIMITING THE FOREGOING, LICENSOR WILL NOT BE LIABLE FOR
LOST PROFITS, LOSS OF DATA, OR COSTS OF COVER.
Version 5.1A
4|Page

Entire Agreement
This is the entire agreement between the parties and may not be modified except in writing signed by both parties.
U.S. Government - Restricted Rights

The Training Materials and accompanying documentation are commercial computer Training Materials and commercial computer Training
Materials documentation, respectively, pursuant to DFAR Section 227.7202 and FAR Section 12.212, as applicable. Any use, modification,
reproduction release, performance, display, or disclosure of the Training Materials and accompanying documentation by the U.S. Government
shall be governed solely by the terms of this Agreement and shall be prohibited except to the extent expressly permitted by the terms of this
Agreement.
IF YOU DO NOT AGREE WITH THE ABOVE TERMS AND CONDITIONS, DO NOT OPEN OR USE THE TRAINING MATERIALS AND CONTACT LICENSOR FOR
INSTRUCTIONS ON RETURN OF THE TRAINING MATERIALS.
5|P a g e
Version 5.1A

Welcome, and Thank You!

On behalf of the entire iPexpert team, I'd personally like to thank you for putting your greatest
certification journey in our hands, and trusting us to deliver cutting-edge training to help you
accomplish this goal. Although there is no way to guarantee a 100% pass rate on the CCIE Lab, my
team and I feel extremely confident that your chances of passing will improve dramatically with the
use of our training materials.
-Respectfully, Wayne A. Lawson II, CCIE #5244 (Emeritus) / Founder & CEO - iPexpert, Inc.
Feedback
At iPexpert, we value the feedback (both positive and constructive) offered by our clientele. Our
dedication to offering the best tools and content to help students succeed could not be possible
without your comments and suggestions. Your feedback is what continually keeps us enhancing our
product portfolio, and it is greatly appreciated. If there is anything you'd like us to know, please do so
via the feedback@ipexpert.com alias.
In addition, when you pass your CCIE Lab exam, we want to hear about it! Please email your Full
Name (used in the CCIE Verification Tool), CCIE number and the track to success@ipexpert.com and
let us know how iPexpert played a role in your success. We would like to be sure you're welcomed
into the "CCIE Club" appropriately, by sending you a gift for your accomplishment.
Technical Support and Freebies

To conclude, we are also proud to lead the industry with multiple support options at your disposal,
free of charge. Our online support community has attracted a membership of your peers from around
the world, and is monitored on a daily basis by our instructors and our students. We also consistently
publish technical articles / papers on our blog. You can also follow up on Facebook, Twitter, LinkedIn,
Google+ and YouTube for more in-depth discussion on current industry trends and CCIE preparation
tips.
Lastly, referrals are very important to us. It tells us that; 1) you like, value, and approve of our training
and 2) it helps us to continue to grow as a company. If you have any of your peers who you feel will
value the use of any of our training materials, please send us their name, email address, telephone
number and what certification and track you feel that they're interested in. If your referral makes a
purchase, we will provide you with in-house credit that can be used at any time. If your referrals
exceed a certain threshold, we will also include a gift card of your choice (either an American Express
or Amazon gift card).
Version 5.1A
6|Page

How to Use This Lab Preparation Workbook

In 2014 Cisco announced a new CCIE Routing and Switching blueprint for their V5 version of the Lab
exam. This change was one of the biggest changes we've seen over the 14 years since we've been
delivering cutting-edge CCIE training materials. The changes consisted of a modification of the lab
structure to now include:
A restructure of the way the lab is delivered. You will first have to complete a Troubleshooting
section where you'll have access to the rack that Cisco provides you to do so. The next section
consists of the Diagnostics section, which is done without access to your rack. The third section is
the Configuration section, which is the actual "lab" that most people focus on, and have been
primarily concerned about in the past. With this new lab structure, it's VERY IMPORTANT that you
are well prepared for all three Sections of the lab exam. At any point, you could fail the lab exam
if you don't receive enough points in 1 of the 3 sections.
Cisco has also made a drastic change in the topology that you'll be given. It's common knowledge
at the time of this book's publication that the topology you're given has gone from their previous
6 to 8 router / 4 switch topology (seen in the labs previous to V4), to a topology that could
potentially consist of up to 40 routers and 8 switches. It's imperative that you work through
practice scenarios on a large topology so you're familiar with the intricacies and technological
specifics that can be introduced with a topology that large.
Cisco has also changed their retake policy, which now requires their CCIE candidates to wait
longer durations before their next attempt(s). Below we have listed Cisco's new policy.
And, finally, Cisco has created this impressive blueprint and broken it into sections. Cisco provides
you with the 5 section titles and the number of points so you're able to understand how their
grading works and how much focus and attention is placed on that various section. The primary
section outline is provided below; however, we have not provided all of the topics and subtopics
that Cisco has provided. We recommend that you reference Cisco's website URL which provides
these details for the Routing and Switching V5 Lab - which will require you to have a CCO and
Cisco Learning Network login prior to being given access. That URL was found here at the date of
this book's publication.
7|P a g e
Version 5.1A

Cisco's New Retake Policy
Cisco R&S V5 Blueprint (Primary Sections w/ Assigned Point Values)
Layer 2 Technologies: 20%

Layer 3 Technologies: 40%
VPN Technologies: 20%
Infrastructure Security: 5%
Infrastructure Services: 15%
How to Use This Lab Preparation Workbook

Throughout this workbook, you'll be asked to reference various diagrams and to pre-load
configurations. These pre-loaded configurations will be automatically loaded when you're utilizing our
online rack rental solution. All diagrams are provided in a .zip file that's accessed when you're logged
into your iPexpert's Member's Area. If you're asked to reference a table, it will be located within this
actual workbook, unless otherwise noted.
Additional Information Pertaining to Cisco's CCIE R&S Lab Exam

NOTE
THE FOLLOWING INFORMATION HAS BEEN OBTAINED FROM CISCO'S LEARNING NETWORK. WE ARE NOT AFFILIATED
WITH, OR ENDORSED IN ANY WAY BY CISCO.
Version 5.1A
8|Page

About the CCIE Lab Exam
The CCIE Lab Exam is an eight-hour, hands-on exam, which requires you to configure and
troubleshoot a series of complex networks to given specifications. Knowledge of troubleshooting is an
important skill and candidates are expected to diagnose and solve issues as part of the CCIE lab exam.
You will not configure end-user systems, but are responsible for all devices residing in the network
(hubs, etc.). Point values and testing criteria are provided. More detail is found on the Routing and
Switching Lab Exam Blueprint and the list of Lab Equipment and IOS Versions.
Cost
The Lab Exam cost does not include travel and lodging expenses. Costs may vary due to exchange
rates and local taxes (VAT, GST). You are responsible for any fees your financial institution charges to
complete the payment transaction. Price not confirmed and is subject to change until full payment is
made. For more information on the Lab Exam Registration please reference the Take Your Lab
Exam tab.
Lab Environment
The Cisco documentation is available in the lab room, but the exam assumes knowledge of the more
common protocols and technologies. The documentation can be navigated using the index. No
outside reference materials are permitted in the lab room. You must report any suspected equipment
issues to the proctor during the exam; adjustments cannot be made once the exam is over.
Lab Exam Grading
The labs are graded by proctors, who ensure that all the criteria have been met. They will use
automatic tools to gather data from the routers in order to perform preliminary evaluations.
Candidates must reach a minimum threshold in all three sections and achieve an overall passing
score.
Lab Format
The CCIE Routing and Switching Lab exam consists of a 2-hour Troubleshooting section, a 30-minute
Diagnostic section, and a 5-hour Configuration section. Candidates may choose to borrow up to 30
minutes from the Configuration section and use it in the Troubleshooting section.
9|P a g e
Version 5.1A

Results
You can review your lab exam results online (login required), usually within 48 hours. Results are
Pass/Fail and failing score reports indicate major topic areas where additional study and preparation
may be useful.
Reevaluation of Lab Results
A Reread involves having a second proctor load your configurations into a rack to re-create the test
and re-score the entire exam. Rereads are available for the Routing and Switching, and Service
Provider technology tracks.
A Review involves having a second proctor verify your answers and any applicable system-generated
debug data saved from your exam. Reviews are available for all other tracks.
Payment Terms
Make your request within 14 days following your exam date by using the "Request for Reread" link
next to your lab record. A Reread costs $1000.00 USD and a Review costs $400.00 USD. Payment is
made online via credit card and your Reread or Review will be initiated upon successful payment. You
may not cancel the appeal request once the process has been initiated. Refunds are given only when
results change from fail to pass.
Troubleshooting
The CCIE Routing and Switching Lab exam features a 2-hour Troubleshooting section. Candidates will
be presented with a series of trouble tickets for preconfigured networks and need to diagnose and
resolve the network fault or faults. As with the configuration section, the network must be up and
running for a candidate to receive credit. Candidates who finish the troubleshooting section early
may proceed on to the diagnostic section, but they will not be allowed to go back to troubleshooting.
NOTE
THIS CONCLUDES ANY REFERENCED CONTENT SEEN OR FOUND ON CISCO'S LEARNING NETWORK.
Version 5.1A
10 | P a g e

Lab 2: Troubleshooting Section :: Detailed

Solutions
Detailed Solution Guide
This part of the material is designed to provide our students with the exact commands to use, when
to use them, and also the various show commands that will allow you to understand what you're
looking for. In addition, the instructor has provided some detail as to why the various solutions have
been used versus another potential command set that would have accomplished the same outcome.
General Rules
11|P a g e
You may modify, but not delete or remove any prefix-lists, route-maps, or access-lists.
Do not modify any IP addressing on any interfaces.
The BB routers are not accessible.
All Non ISP/backbone routers have an interface loopback 0 with the address 172.16.xx.xx, where
xx is the router number. ISP routers have loopback address of 172.168.2xx.2xx. Switches have
loopback addresses of 172.168.1xx.1xx.
Static/default routes are NOT allowed unless otherwise stated in the task.
Save your configurations often.
Version 5.1A

Pre-Setup
Please login to your vRack and load the initial Configuration.
This lab is intended to be used with online rack access. Connect to the terminal server and complete
the troubleshooting tasks as detailed below.
Version 5.1A
12 | P a g e

Diagram 2.1: Layer 2
13|P a g e
Version 5.1A

Diagram 2.2: BGP
Version 5.1A
14 | P a g e

Incident 1
(3 points)
Loopback0 of R21 cannot talk to Loopback0 of R22. Troubleshoot and fix the issues so that R21
can ping 172.16.22.22 sourced from its Loopback0 interface.
This incident contains multiple faults. Use the BGP diagram to aid you with troubleshooting.
15|P a g e
Version 5.1A

Solution
We need to first test the symptom outlined in the incident to confirm the issue. The incident states
that the loopback 0 interface of R21 cannot ping the loopback 0 interface of R22. Lets take a look.
R21
R21#ping 172.16.22.22 source loopback 0
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.6.22.22, timeout is 2 seconds:
Packet sent with a source address of 172.16.21.21
.....
Success rate is 0 percent (0/5)
The IPv4 diagram shows that the Remote offices routers are connected to ISP4. Also, the task asks us
to use the BGP diagram. This signifies that BGP being used as a transport and that there may be a
problem with BGP. Also remember that we are allowed to look at and configure the ISP routers in
this Troubleshooting lab. Lets take a look at the BGP config of R21, R22, and ISP4.
R21
R21#sh run | sec bgp
router bgp 2121
bgp log-neighbor-changes
neighbor 1.1.1.26 remote-as 444
R22
router bgp 2222
no bgp log-neighbor-changes
redistribute connected
ISP4
ISP4#sh run | sec bgp
router bgp 444
no bgp default ipv4-unicast
neighbor 172.16.207.207 ebgp-multihop 255
Version 5.1A
16 | P a g e

neighbor 172.16.207.207 update-source Loopback0
!
address-family ipv4
exit-address-family
!
address-family vpnv4
neighbor 172.16.207.207 activate
neighbor 172.16.207.207 send-community extended
exit-address-family
!
address-family ipv4 vrf CORE
neighbor 1.1.1.31 ttl-security hops 2
exit-address-family
Notice that the neighbor command for R22s connection to ISP4 is in the wrong AS. It should be
AS444, not 4444. Also notice that R21 is not redistributing connected routes like R22 is. We will keep
that in our back pocket and first work through the wrong AS configuration on R22.
R22
R22(config)#router bgp 2222
R22(config-router)#no neighbor 1.1.1.28 remote-as 4444
R22(config-router)#neighbor 1.1.1.28 remote-as 444
Now lets test the ping again.
R21
.....
17|P a g e
Version 5.1A

We are still not able to perform the ping outlined in the task. Lets revisit the redistribute connected
issue on R21. Without either a network statement or a redistribute connected statement, R21 is not
able to advertise any routes into BGP. Since R22 is already configured to redistribute connected into
BGP, lets do the same for R21.
R21
R21(config-router)#redistribute connected
Verification
Perform the ping outlined in the incident to verify we get good results.
R21
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 16/16/17 ms
Summary of Changes
R21
R21(config-router)#redistribute connected
R22
R22(config-router)#no neighbor 1.1.1.28 remote-as 4444
Version 5.1A
18 | P a g e

Incident 2
(2 points)
BB3 has lost connectivity to the Chicago hub. Interface E0/0 of BB3 should learn its IP address
from R1 and participate in OSPF. The BB3 loopback network 172.16.113.113 should have full
reachability to all devices throughout the network.
You may not access BB3 while troubleshooting this fault.
This incident has multiple faults.
19|P a g e
Version 5.1A

Solution
The incident states that BB3 should learn its IP address of E0/0 from R1. This leads us to conclude
that R1 is acting as a DHCP server. Also, we are not allowed to access or look at BB3 for this incident.
Lets test basic connectivity to E0/0 of BB3 as well as the 172.16.113.113 network from R1.
R1
R1#ping 10.10.1.254
.....
R1#ping 172.16.113.113
.....
R1 does not have basic layer 3 connectivity to BB3. Since the incident called out that R1 is providing
the IP address to BB3, lets take a look at the DHCP config on R1.
R1
R1#sh run | sec dhcp
ip dhcp pool BB3
network 10.10.1.252 255.255.255.252
ip dhcp pool BB3-E00
host 10.10.1.254 255.255.255.252
client-identifier aabb.cc01.f700
client-name BB3
Notice that a client identifier is configured and that there is only 1 available IP address in the DHCP
pool. Lets debug the DHCP process and bounce the link to see if we can glean any information.
R1
R1#debug ip dhcp server packet
DHCP server packet debugging is on.
Version 5.1A
20 | P a g e

R1#conf t
R1(config)#int e0/0
R1(config-if)#shut
R1(config-if)#no shut
02:39:08: DHCPD: client's VPN is .
02:39:08: DHCPD: No option 125
02:39:08: DHCPD: DHCPDISCOVER received from client 01aa.bbcc.01f7.00 on interface
Ethernet0/0.
02:39:08: DHCPD: Allocate an address without class information (10.10.1.252)
Notice that the client identifier does not match. On R1, it was configured with the MAC address of
the E0/0 interface on BB3. However, Cisco uses a modified MAC address as the client-identifier, and
it is prepended with 01. This holds true for all default configurations of DHCP when the client is a
router or switch. Also notice that the decimal placement changes when prepending the client-id with
01. This is also important as the decimals are required in the client-id and must match exactly. Lets
change the client-id of BB3 on R1 under the DHCP process.
R1
R1(config)#ip dhcp pool BB3-E00
R1(dhcp-config)#no client-identifier aabb.cc01.f700
R1(dhcp-config)#client-identifier 01aa.bbcc.01f7.00
R1(dhcp-config)#int e0/0
R1(config-if)#shut
R1(config-if)#no shut
Lets now run the same verification test we ran initially to see where we stand now. We should have
Layer 3 connectivity to the E0/0 interface of BB3 now.
R1
R1#ping 10.10.1.254
.!!!!
R1#ping 172.16.113.113
.....
21|P a g e
Version 5.1A

Just as we suspected, we now have basic layer 3 connectivity, but still cannot ping the network
behind E0/0 on BB3. The task specifies that BB3 should participate in the OSPF process. Lets run a
debug on R1 for OSPF.
R1
R1#debug ip ospf adj
OSPF adjacency debugging is on
R1#
02:55:02: OSPF-1 ADJ
0.0.0.1 in the header
Et0/0: Rcv pkt from 10.10.1.254, area 0.0.0.0, mismatched area
R1#
There it is! The areas are mismatched between BB3 and R1. We now need to dig deep to figure out
what the area should be. Since we cannot login to BB3, we need to match the area that BB3 is
already configured for. The debug shows that the area id is 0.0.0.1. This equals a decimal value of 1.
If it was 0.0.0.10, then the decimal value would be 10. In OSPF, you can either use integer or dotted
decimal notation, as long as they equal each other when translated. In this case, we will use integer
notation. Lets change the area for this network to 1. Also keep in mind that the network command
for this network also encompasses other connected networks, so lets configure a more specific
network statemet for this specific segment.
R1
R1(config)#router ospf 1
R1(config-router)#network 10.10.1.253 0.0.0.0 area 1
%OSPF-5-ADJCHG: Process 1, Nbr 192.168.3.1 on Ethernet0/0 from LOADING to FULL,
Loading Done
Verification
R1
R1#ping 10.10.1.254
!!!!!
R1#ping 172.16.113.113
!!!!!
Version 5.1A
22 | P a g e

Summary of Changes
R1
R1(config)#ip dhcp pool BB3-E00
R1(dhcp-config)#no client-identifier aabb.cc01.f700
R1(dhcp-config)#client-identifier 01aa.bbcc.01f7.00
R1(config-router)#network 10.10.1.253 0.0.0.0 area 1
23|P a g e
Version 5.1A

Incident 3
(2 points)
Users in the Miami Hub are complaining that they have lost connectivity to the Denver HQ office.
All provider-to-provider links should use MPLS VPN as the routing mechanism.
Troubleshoot and fix the issue so that all devices at the Miami Hub have full reachability to all
devices at the Denver HQ office and that both paths through ISP2 and ISP7 are in the BGP
topology table for vrf CORE.
Version 5.1A
24 | P a g e

Solution
Miami has lost connectivity to Denver HQ. Lets start by taking a look at the routing table of R2 and
see if it has routes to the 10.10.100.X networks since it is the exit point for Miami.
R2
R2#sh ip route 10.10.100.0
% Subnet not in table
R2 is not learning any routes for Denver. Now, lets take a look at R11 at Denver to see if it is learning
routes to Miami.
R11
R11#sh ip route 10.10.30.0
% Subnet not in table
At this point, R2 and R11 are not advertising their internal routes into BGP or there is an issue within
the BGP ISP network (or it could be a combination of both). Lets verify that the internal routes are
being advertised into BGP on R2 and R11:
R2
R2#sh run | sec bgp
redistribute bgp 202 metric 100 10 1 1 1
router bgp 202
redistribute eigrp 300
R11
router bgp 1111
redistribute rip
We are redistributing our IGPs into BGP without any filtering. It is time to take a look at the routing
tables of the ISP routers. Lets look at both paths, first through ISP2 and ISP7.
25|P a g e
Version 5.1A

ISP2
ISP2#show ip route vrf CORE
1.0.0.0/8 is variably subnetted, 2 subnets, 2 masks

C
1.1.1.14/31 is directly connected, Serial2/1

10.0.0.0/30 is subnetted, 7 subnets
10.10.1.8 [20/0] via 1.1.1.15, 00:38:32
10.10.1.12 [20/0] via 1.1.1.15, 00:38:32
10.10.1.32 [20/11] via 1.1.1.15, 00:38:32
10.10.1.40 [20/11] via 1.1.1.15, 00:38:32

172.16.3.0/24 [20/0] via 1.1.1.15, 00:38:32
172.16.102.102/32 [20/12] via 1.1.1.15, 00:38:32
As you can see, ISP2 is not learning any routes from Miami or Denver. There may be an issue with
BGP. Lets take a look at R2s BGP configuration.
ISP2
ISP2#show run | sec bgp
router bgp 222
!
address-family ipv4
exit-address-family
!
exit-address-family
Version 5.1A
26 | P a g e

!

exit-address-family
ISP2 does not have any BGP vpnv4 neighbors! The MPLS core is configured to use MPLS VPN using
BGP. Also notice that unicast is disabled for ipv4. We need to activate each of its P-to-P neighbors in
the vpnv4 address family.
ISP2
ISP2(config)#router bgp 222
ISP2(config-router)#address-family vpnv4
ISP2(config-router-af)#neighbor 172.16.201.201 activate
Remember that there are 2 requirements for this task. First, we need to ping across the network.
The second requirement asks us to verify that the BGP topology table shows both paths between the
two networks, one through ISP2 and the second path through ISP7. Looking at the routing table of
ISP1, we can confirm this. Yet, we still cant ping. This is because even though the routes are being
learned, and the path through ISP2 should work, the route installed in the routing table still takes the
path of ISP7. While this is not the problem itself, it is indicative that ISP7 still has an issue.
ISP1
ISP1#sh ip bgp vpnv4 vrf CORE
BGP table version is 75, local router ID is 172.16.201.201
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
Network
Next Hop
Metric LocPrf Weight Path
Route Distinguisher: 111:111 (default for vrf CORE)

*
1.1.1.22/31
*>
*
1.1.1.24/31
*>
*
1.1.1.26/31
172.16.202.202
0 222 777 666 2424 ?
172.16.207.207
0 777 666 2424 ?
172.16.202.202
0 222 777 666 2525 ?
172.16.207.207
0 777 666 2525 ?
172.16.202.202
0 222 777 444 2121 ?
Results Truncated
27|P a g e
Version 5.1A

So we are learning routes but we are not passing traffic. This is very typical of a network that has
MPLS disabled on its links. The inicident indicates that all provider-to-provider links should use MPLS
as the routing mechanism. Lets verify that ISP7 has MPLS enabled on the P-to-P links.
ISP7
ISP7#sh run int s4/0
interface Serial4/0
ip address 1.1.1.32 255.255.255.254
serial restart-delay 0

interface Serial4/1
ip address 1.1.1.8 255.255.255.254

interface Serial5/3
ip address 1.1.1.3 255.255.255.254
We can also confirm this by looking at the MPLS forwarding table of ISP7 (only part of command
output is shown):
ISP7
ISP7#sh mpls forwarding-table vrf CORE
Local
Outgoing
Prefix
Bytes Label
Outgoing
Label
Label
or Tunnel Id
Switched
interface
33
41
10.10.30.0/31[V] 0
drop
34
47
10.10.30.0/30[V] 0
drop
35
52
10.10.30.8/30[V] 0
drop
36
53
10.10.30.24/30[V]
Label
Label
or Tunnel Id
37
44
\
Switched
interface
drop
10.10.30.32/30[V]
\
0
38
48
10.10.30.40/30[V]
drop
\
0
39
49
10.10.30.48/30[V]
drop
\
Version 5.1A
Next Hop
drop
28 | P a g e

40
46
10.10.30.56/30[V]
\
0
47
25
10.10.100.0/29[V]
drop
\
0
48
38
drop
10.10.100.32/29[V]
drop
Results Truncated
MPLS is NOT enabled between the P-to-P links. When looking at the MPLS forwarding table, the
packets are being dropped because there is not an exit interface specified. Lets enable MPLS on
these links.
ISP7
ISP7(config-if)#int s5/3
ISP7(config-if)#mpls ip
Now lets take a look at the MPLS forwarding table again. We should see routes to both 10.10.30.X
and 10.10.100.X with destination interfaces.
ISP7
ISP7#sh mpls forwarding-table vrf CORE
Local
Outgoing
Prefix
Bytes Label
Outgoing
Label
Label
or Tunnel Id
Switched
interface
33
41
10.10.30.0/31[V] 0
Se5/3
point2point
34
47
10.10.30.0/30[V] 0
Se5/3
point2point
35
52
10.10.30.8/30[V] 0
Se5/3
point2point
36
53
10.10.30.24/30[V]
Se5/3
point2point
Se5/3
point2point
Se5/3
point2point
\
0
37
44
10.10.30.32/30[V]
\
0
38
48
10.10.30.40/30[V]
\
0
39
29|P a g e
49
10.10.30.48/30[V]
Next Hop
Version 5.1A

0
40
46
10.10.30.56/30[V]
Se5/3
\
0
47
25
10.10.100.0/29[V]
Se5/3
\
0
48
38
Se4/1
point2point
point2point
10.10.100.32/29[V]
Se4/1
point2point
Results Truncated
Verification
We need to verify 2 things. First, that Miami can ping Denver. Second, that ISP1 and ISP3 show both
paths in the BGP topology table.
R5
R5#ping 10.10.100.1
!!!!!
We have reachability! Now, lets make sure both paths exist in the BGP topology tables of ISP1 and
ISP3.
ISP1
ISP1#sh ip bgp vpnv4 all 10.10.100.0 255.255.255.248
BGP routing table entry for 111:111:10.10.100.0/29, version 216
Paths: (2 available, best #2, table CORE)
Advertised to update-groups:
4
Refresh Epoch 1
222 333 1111
172.16.202.202 (metric 2297856) from 172.16.202.202 (172.16.202.202)
Origin incomplete, localpref 100, valid, external
Extended Community: RT:111:111
mpls labels in/out 31/60
rx pathid: 0, tx pathid: 0
Refresh Epoch 1
Version 5.1A
30 | P a g e

777 333 1111
172.16.207.207 (metric 2297856) from 172.16.207.207 (172.16.207.207)
Origin incomplete, localpref 100, valid, external, best
rx pathid: 0, tx pathid: 0x0
ISP3
ISP3#sh ip bgp vpnv4 all 10.10.30.0 255.255.255.252
BGP routing table entry for 111:111:10.10.30.0/30, version 189
Paths: (2 available, best #2, table CORE)
Advertised to update-groups:
1
Refresh Epoch 2
222 111 202
172.16.202.202 (metric 2297856) from 172.16.202.202 (172.16.202.202)
Origin incomplete, localpref 100, valid, external
rx pathid: 0, tx pathid: 0
Refresh Epoch 1
777 111 202
172.16.207.207 (metric 2297856) from 172.16.207.207 (172.16.207.207)
Origin incomplete, localpref 100, valid, external, best
rx pathid: 0, tx pathid: 0x0
31|P a g e
Version 5.1A

Summary of Changes
ISP7
ISP2
ISP2(config)#router bgp 222
ISP2(config-router)#address-family vpnv4
Version 5.1A
32 | P a g e

Incident 4
(2 points)
IPv6 customers at the Denver HQ office are reporting limited reachability between their IPv6
addresses.
Fix the issues so that connectivity is restored and the following ping commands show successful
results:
R11#ping 7777:135::15
R15#ping 7777:111::11
33|P a g e
Version 5.1A

Solution
We need to start by verifying the issue. The incident asks us for 2 specific pings.
R11
R11#ping 7777:135::15
Sending 5, 100-byte ICMP Echos to 7777:135::15, timeout is 2 seconds:
.....
R15
R15#ping 7777:111::11
% No valid route for destination

Lets do a traceroute to see where the traffic is stopping.
R11
R11#traceroute 7777:135::15
Tracing the route to 7777:135::15
1 7777:111::10 0 msec 1 msec 0 msec

2 7777:135::13 1 msec 0 msec 1 msec
3
R15
R15#traceroute 7777::11:11
Tracing the route to 7777::11:11
Version 5.1A
34 | P a g e

Traffic sourced from R11 destined for R15 dies at R13. R15 doesnt have a route back to R11. If you
look at the routing table of R11, you can see that the IPv6 topology is using OSPFv3. Another thing
you should notice is a following syslog message:
R15
%OSPFv3-4-AREA_MISMATCH: OSPFv3-1-IPv6 Received packet with incorrect area from
FE80::A8BB:CCFF:FE00:D10, Ethernet0/1, area 0.0.0.1, packet area 0.0.0.0
There is an area mismatch for OSPFv3. Lets take a look at the OSPF configuration of R13 to verify
what are it should be in. Remember that OSPFv3 is configured under the interface.
R13
R13#sh run int e0/1
interface Ethernet0/1
ip address 10.10.100.25 255.255.255.248
ipv6 address 7777:135::13/64
ipv6 ospf 1 area 0
Lets change the OSPFv3 area to 0 on R15 and observe the results.
R15
R15(config)#int e0/1
R15(config-if)#ipv6 ospf 1 area 0
%OSPFv3-5-ADJCHG: Process 1, Nbr 172.16.13.13 on Ethernet0/1 from LOADING to FULL,
Loading Done
Verification
R11
R11#ping 7777:135::15
!!!!!
35|P a g e
Version 5.1A

R15
R15#ping 7777:111::11
!!!!!
Summary of Changes
R15
Version 5.1A
36 | P a g e

Incident 5
(3 points)
Users are reporting that customers connecting to the 10.10.30.252/30 network are only getting
half of the bandwidth that was guaranteed in their Customer Agreement. The Customer
Agreement states that 10.10.30.252/30 should get 3Mbps of bandwidth to the rest of the
network.
Troubleshoot and fix the issue. Ensure that users connected to the 10.10.30.252/30 network get
3Mbps bandwidth when connecting to the rest of the network.
37|P a g e
Version 5.1A

Solution
There are 2 serial links connected between R6 and R9. On the IPv4 diagram, there is only 1 IP address
for this link. This leads to a conclusion that there is some form of bonding going on, typically PPP
multilink. Lets take a look at the interface configurations of R6 and R9.
R6
R6#sh run int s3/0
interface Serial3/0
bandwidth 1500
no ip address
encapsulation ppp
ppp multilink
ppp multilink group 1
R6#sh run int s3/1

interface Serial3/1
bandwidth 1500
no ip address
encapsulation ppp
ppp multilink
R9
R9#sh run int s3/0
interface Serial3/0
bandwidth 1500
no ip address
encapsulation ppp
ppp multilink
end
R9#sh run int s3/1

interface Serial3/1
Version 5.1A
38 | P a g e

bandwidth 1500
no ip address
encapsulation ppp
ppp multilink
The serial interfaces are part of ppp-multilink 1. Notice that S3/1 of R9 is not part of the multilink.
That is definitely a problem. Lets add it to the multilink.
R9
R9(config)#int s3/1
R9(config-if)#ppp multilink group 1
Verification
At this point, the multilink interface should have come up. Lets take a look at the multilink interface.
R9
R9#sh int multilink 1
Multilink1 is up, line protocol is up
Hardware is multilink group interface
Internet address is 10.10.30.66/30
MTU 1500 bytes, BW 3000 Kbit/sec, DLY 20000 usec,
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation PPP, LCP Open, multilink Open
Open: IPCP, CDPCP, loopback not set
Keepalive set (10 sec)
DTR is pulsed for 2 seconds on reset
Last input 00:00:00, output never, output hang never
Last clearing of "show interface" counters 00:57:24
Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
Queueing strategy: fifo
Output queue: 0/40 (size/max)
5 minute input rate 0 bits/sec, 0 packets/sec
5 minute output rate 0 bits/sec, 0 packets/sec
36 packets input, 5750 bytes, 0 no buffer
Received 0 broadcasts (0 IP multicasts)
0 runts, 0 giants, 0 throttles
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
39|P a g e
Version 5.1A

37 packets output, 6376 bytes, 0 underruns
0 output errors, 0 collisions, 1 interface resets
0 unknown protocol drops
0 output buffer failures, 0 output buffers swapped out
0 carrier transitions
R6
R6#sh int multilink 1
Multilink1 is up, line protocol is up
Hardware is multilink group interface
Internet address is 10.10.30.65/30
MTU 1500 bytes, BW 3000 Kbit/sec, DLY 20000 usec,
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation PPP, LCP Open, multilink Open
Open: IPCP, CDPCP, loopback not set
Keepalive set (10 sec)
DTR is pulsed for 2 seconds on reset
Last input 00:00:02, output never, output hang never
Last clearing of "show interface" counters 11:03:46
Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
Queueing strategy: fifo
Output queue: 0/40 (size/max)
5 minute input rate 0 bits/sec, 0 packets/sec
5 minute output rate 0 bits/sec, 0 packets/sec
85 packets input, 9627 bytes, 0 no buffer
Received 0 broadcasts (0 IP multicasts)
0 runts, 0 giants, 0 throttles
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
91 packets output, 10839 bytes, 0 underruns
0 output errors, 0 collisions, 5 interface resets
0 unknown protocol drops
0 output buffer failures, 0 output buffers swapped out
0 carrier transitions
Summary of Changes
R9
R9(config)#int s3/1
R9(config-if)#ppp multilink group 1
Version 5.1A
40 | P a g e

Incident 6
(2 points)
The Network Admins at the Miami Hub report that R9 cannot ping all members of the
225.10.10.10 group. PIM should not be enabled on any interfaces of R9.
The loopback 0 interface of R5 is the Rendezvous Point for the multicast network.
Fix the issues so that connectivity is restored and the following ping command shows a successful
result:
41|P a g e
Version 5.1A

R9#ping 225.10.10.10 source 10.10.30.26 rep 5

Reply to request 0 from 10.10.30.25, 4 ms

Solution
Perform the ping to the multicast group as outlined in the incident to verify the issue.
R9
R9#ping 225.10.10.10 source 10.10.30.26 rep 1
We only get one response and it was from the directly connected peer, R5. Lets take a look at the
Multicast configuration on R9 and R5.
R9
R9#sh run | sec multicast
(no output)
R9#sh run | sec igmp
(no output)
R9#sh run | sec pim

ip pim bidir-enable
ip pim rp-address 172.16.5.5 bidir
R9#sh run int e0/1

ip address 10.10.30.26 255.255.255.252
Version 5.1A
42 | P a g e

There is no multicast routing enabled on R9! Also notice that PIM is NOT configured on E0/1,
connected to R9. However, note that R9 has an RP configured and that bidirectional PIM is enabled.
Lets take a look at the multicast configuration of R5.
R5
R5#sh run | sec multicast
ip multicast-routing
R5#sh run | sec pim

ip pim dense-mode
ip pim dense-mode
ip pim dense-mode
ip pim bidir-enable
ip pim rp-address 172.16.5.5 bidir
R5#show run int e0/1

ip address 10.10.30.25 255.255.255.252
ip igmp join-group 225.10.10.10
Multicast routing IS enabled on R5. So is bidirectional PIM. The only issue is that R5 is not running
PIM on the link towards R9. Lets think about that for a second. R9 does not have PIM enabled
either. How can this work? The incident states that PIM should not be enabled on any interfaces of
R9. PIM bidirectional is the key here. PIM bi-directional mode will never build a (S,G) entry. Rather,
it builds a (*,G). The benefit of using bidirectional mode is Multicast up AND down the shared tree,
rather than just down. There is also no RPF check! The server does not need to run PIM, rather, its
upstream router to the RP does. So lets enable PIM on the e0/1 interface of R5 and observe the
results.
R5
R5(config)#int e0/1
R5(config-if)#ip pim dense-mode
Verification
R9
R9#ping 225.10.10.10 source 10.10.30.26 rep 5
43|P a g e
Version 5.1A


Summary of Changes
R5
R5(config)#int e0/1
R9
R9#ping 225.10.10.10 source 10.10.30.26 rep 5


Version 5.1A
44 | P a g e

Incident 7
(2 points)
Users on R7 are reporting slow connectivity to VLAN 82 and VLAN 95.
All traffic sourced or destined for R7 should use the serial connection between R8 and R7, and
not the Ethernet connection between R2 and R7. The Ethernet connection has only 512Kbps of
bandwidth and the serial connection has 45Mbps of bandwidth.
Fix the issue so that R7 prefers the serial connection R8, and then to R2, so that it is assigned the
appropriate bandwidth on both connections.
Also verify that both paths are in R7s EIGRP topology table.
45|P a g e
Version 5.1A

Solution
The incident states that users connected to R7 are reporting slow connectivity. It also points out a
few key pieces of information. First, all traffic from R7 should use the serial link to R8, and not the
Ethernet interface connected to R2. Second, it states that the Ethernet interface is only 512Kbps and
the said Serial interface is 45Mbps on R7. Also note that the topology is using EIGRP as the routing
protocol and know that EIGRP uses bandwidth and delay as its primary attributes to compute its
metric. Lets take a look at the interface configurations of R7, R8, and R2 first to verify bandwidth
settings.
R2
R2#sh run int e0/0
bandwidth 512
ip address 10.10.30.49 255.255.255.252
R7
R7#sh run int e0/0
bandwidth 512
ip address 10.10.30.50 255.255.255.252
R7#sh run int s3/0

interface Serial3/0
bandwidth 45
ip address 10.10.30.58 255.255.255.252
R8
R8#sh run int s3/0
interface Serial3/0
bandwidth 45
ip address 10.10.30.57 255.255.255.252
The bandwidth on the serial interfaces is set to 45Kbps, not 45Mbps. Lets get the bandwidth issue
fixed first and then go from there.
Version 5.1A
46 | P a g e

R7
R7(config)#int s3/0
R7(config-if)#bandwidth 45000
R8
R8(config)#int s3/0
Now lets perform a traceroute from R7 to R2, VLAN 82 to see which route it takes. It should take the
route through R8, even though R2 is directly connected.
R7
R7#traceroute 10.10.30.2
Tracing the route to 10.10.30.2
VRF info: (vrf in name/id, vrf out name/id)
1 10.10.30.57 1 msec 0 msec 0 msec
2 10.10.30.34 5 msec 5 msec 0 msec
3 10.10.30.10 5 msec 6 msec 1 msec
4 10.10.30.41 2 msec *
3 msec
OK so the path is actually via R8, but then also via R4 and R5, not directly to R2. Lets take a look at
R8s EIGRP configuration. It should peer with 3 different directly connected neighbors, R7, R2, and
R4.
R8
R8# sh ip eigrp nei
EIGRP-IPv4 Neighbors for AS(300)
H
Address
Interface
Hold Uptime
(sec)
SRTT
RTO
(ms)
Seq
Cnt Num
10.10.30.34
Et0/0
13 00:11:06
100
11
10.10.30.58
Se3/0
11 00:11:38
175
3324
25
R8 is only peering with R4 and R7. Check out the syslogs:
R8
%DUAL-6-NBRINFO: EIGRP-IPv4 300:neighbor 10.10.30.2 (Ethernet0/1) is blocked: not on
common subnet (10.10.30.1/31)
47|P a g e
Version 5.1A

According to the IPv4 diagram, EIGRP AS 300 should be IPed with subnet masks of /30. The debug
output shows that R8 is configured with a mask of /31. Lets change this to /30.
R8
R8(config)#int e0/1
R8(config-if)#ip address 10.10.30.1 255.255.255.252
We need to now verify that R8 is now peering with R2 via EIGRP.
R8
R8#show ip eigrp nei
H
Address
Interface
Hold Uptime
SRTT
RTO
(sec)
Seq
(ms)
10.10.30.2
Et0/1
11 00:01:27
100
232
10.10.30.34
Et0/0
11 00:17:48
100
14
10.10.30.58
Se3/0
12 00:18:20
89
534
33
Cnt Num
Verification
Perform a traceroute from R7 to VLAN 82 of R2 and the Vlan 95 interface of R9 and verify that it is
taking a path through R8.
R7
1 10.10.30.57 2 msec 0 msec 1 msec
2 10.10.30.2 1 msec *
2 msec
1 10.10.30.57 1 msec 0 msec 0 msec
2 10.10.30.2 1 msec 1 msec 0 msec
3 10.10.30.42 1 msec 1 msec 1 msec
4 10.10.30.26 2 msec *
Version 5.1A
3 msec
48 | P a g e

Summary of Changes
R7
R7(config)#int s3/0
R8
R8(config)#int s3/0
R8(config)#int e0/1
49|P a g e
Version 5.1A

Incident 8
(3 points)
Users on VLAN 169 at the Atlanta Hub have lost connectivity to the rest of the network.
Troubleshoot the incident and fix any issues to restore VLAN 169 connectivity.
Refer to the Layer 2 and IPv4 diagrams to resolve this incident.
Version 5.1A
50 | P a g e

Solution
We can start troubleshooting this incident by verifying basic layer 3 connectivity between R19 and
R16.
R19
R19#ping 10.10.200.42
.....
We indeed cannot ping R16, which is directly connected. The ticket specifies to use the Layer 2
diagram. This leads to the conclusion that there is an issue with layer 2. Lets take a look at the
switch ports connecting VLAN 169 according to the layer 2 diagram.
SW8
SW8#sh run int e0/0 (R16 Connection)
switchport access vlan 169
switchport mode access
duplex auto
SW8#sh run int e1/0 (R19 Connection)

switchport trunk encapsulation dot1q
switchport trunk allowed vlan 179
switchport mode trunk
duplex auto
Well, there is our first problem. SW8 is not allowing VLAN 169 across the trunk. Lets add VLAN 169
into the allowed vlan statement.
SW8
SW8(config)#int e1/0
SW8(config-if)#switchport trunk allowed vlan add 169
Lets verify that VLAN 169 is now allowed across the trunk by looking at the trunk interface.
51|P a g e
Version 5.1A

SW8
SW8#sh int trunk (Results Truncated)
Port
Mode
Encapsulation
Status
Native vlan
Et1/0
on
802.1q
trunking
Port
Vlans allowed on trunk
Et1/0
169,179
Port
Vlans allowed and active in management domain
Et1/0
179
Port
Vlans in spanning tree forwarding state and not pruned
Et1/0
179
Now the VLAN is being allowed across the trunk, but is still not showing as forwarding or active on the
trunk. We need to verify that the VLAN actually exists in the VLAN database.
SW8
SW8#show vlan
VLAN Name
Status
Ports
---- -------------------------------- --------- ----------------------1
default
active
Et0/3, Et1/2, Et1/3, Et3/0

Et3/1, Et3/2, Et3/3, Et4/0
Et4/1, Et4/2, Et4/3, Et5/0
Et5/1, Et5/2, Et5/3
169
VLAN0169
act/lshut Et0/0
172
VLAN0172
active
Et1/1
187
VLAN0187
active
Et0/2
Look at that, VLAN 169 is shutdown. Lets no shut the VLAN and observe the results.
SW8
SW8(config)#vlan 169
SW8(config-vlan)#no shut
Version 5.1A
52 | P a g e

Verification
R19
R19#ping 10.10.200.42
!!!!!
Lets also ping from R16 E0/1 to the rest of the Atlanta Hub network.
R16
R16#ping 10.10.200.25
!!!!!
R16#ping 10.10.200.17
!!!!!
*** Note you might need to reload SW7 if your ping is failing ***
Summary of Changes
SW8
SW8(config-if)#switchport trunk allowed vlan add 169
SW8(config)#vlan 169
SW8(config-vlan)#no shut
SW8(config-vlan)#exit
53|P a g e
Version 5.1A

Incident 9
(2 points)
Network Time is not updating on R20. Ensure that R20 uses authentication for NTP and that it is
working with 2 NTP servers for time synchronization.
R17 should be the preferred NTP server and R19 should be the secondary NTP server.
Version 5.1A
54 | P a g e

Solution
This is a very specific incident and the ticket outlines what is needed. First, R20 should use NTP,
preferring R17 as the primary NTP server and R19 as the secondary NTP server. Also, this NTP
communication should be authenticated. Lets start by looking at the NTP associations on R20 to get
an idea of where the issue is.
R20
R20#sh ntp associations
address
ref clock
st when
poll reach
delay offset
disp
*~172.16.17.17
127.127.1.1
920
1024
377
0.000 0.000
1.992
~172.16.19.19
172.16.17.17
830
1024
377
1.000 0.500 16.994
* sys.peer, # selected, + candidate, - outlyer, x falseticker, ~ configured
R20#sh run | sec ntp

ntp authentication-key 1 md5 07063154 7
ntp authenticate
ntp trusted-key 1
ntp server 172.16.17.17 prefer
ntp server 172.16.19.19
R17 is showing as the preferred NTP server and R19 is showing up as well as secondary. However, we
are not able to see the authentication with this command. We need to show ntp associations in
detail to see authentication.
R20
R20# sh ntp associations detail
172.16.17.17 configured, ipv4, our_master, sane, valid, stratum 2
ref ID 127.127.1.1
, time D7E6D24F.EF9DB4C0 (23:35:59.936 CET Mon Oct 13 2014)
our mode client, peer mode server, our poll intvl 1024, peer poll intvl 1024
root delay 0.00 msec, root disp 2.18, reach 377, sync dist 5.80
delay 0.00 msec, offset 0.0000 msec, dispersion 1.98, jitter 0.97 msec
precision 2**10, version 4
assoc id 129, assoc name 172.16.17.17
assoc in packets 1005, assoc out packets 1006, assoc error packets 0
org time 00000000.00000000 (01:00:00.000 CET Mon Jan 1 1900)
rec time D7E6D251.245A1D10 (23:36:01.142 CET Mon Oct 13 2014)
xmt time D7E6D251.245A1D10 (23:36:01.142 CET Mon Oct 13 2014)
filtdelay =
55|P a g e
1.00
0.00
1.00
1.00
1.00
1.00
1.00
1.00
Version 5.1A

filtoffset =
0.50
0.00
0.50
0.50
0.50
0.50
0.50
0.50
filterror =
1.95
1.98
2.01
2.04
2.07
2.10
2.13
2.16
minpoll = 6, maxpoll = 10
172.16.19.19 configured, ipv4, insane, invalid, stratum 3
ref ID 172.16.17.17
, time D7E6D231.EED91918 (23:35:29.933 CET Mon Oct 13 2014)
filtdelay =
1.00
1.00
1.00
0.00
1.00
1.00
0.00
0.00
filtoffset =
0.50
0.50
0.50
0.00
0.50
0.50
0.00
0.00
filterror =
1.95
1.98
2.01
2.04
2.07
2.10 16000.0 16000.0
There are few things to notice here. First, R19 is showing insane meaning we can talk to it but we
are not synchronizing with it. Second, there is no authentication showing up. Now it is time to look
at the NTP configs for R17 and R19.
R17
R17#show run | section ntp
ntp authentication-key 1 md5 08285C56 7
ntp trusted-key 1
ntp source Loopback0
ntp master 2
ntp peer 172.16.19.19
R19
R19#show run | section ntp
ntp authentication-key 1 md5 030D4B13 7
ntp trusted-key 1
ntp source Loopback0
ntp master 1
ntp peer 172.16.17.17
Version 5.1A
56 | P a g e

With NTP, only the client needs to initiate the authentication. There needs to be a trusted key
configured on the clients and the server, but the client is the one that initiates the authentication.
R20
R20(config)#ntp server 172.16.17.17 key 1 prefer
R20(config)#ntp server 172.16.19.19 key 1
Verification
R20
R20#sh ntp association detail
172.16.17.17 configured, ipv4, authenticated, sane, valid, stratum 2
ref ID 127.127.1.1
, time D7E6D61F.EFDF3DF8 (23:52:15.937 CET Mon Oct 13 2014)
filtdelay =
0.00
1.00
1.00
1.00
0.00
0.00
1.00
1.00
filtoffset =
0.00
0.50
0.50
0.50
0.00
0.00
0.50
0.50
filterror =
1.95
1.98
3.97
4.00
5.02
5.91
5.94
5.97
172.16.19.19 configured, ipv4, authenticated, our_master, sane, valid, stratum 1

ref ID .LOCL., time D7E6D5CF.73F7D018 (23:50:55.453 CET Mon Oct 13 2014)
rec time D7E6D5D7.245A1D10 (23:51:03.142 CET Mon Oct 13 2014)
57|P a g e
Version 5.1A

xmt time D7E6D5D7.245A1D10 (23:51:03.142 CET Mon Oct 13 2014)
filtdelay =
1.00
1.00
1.00
0.00
1.00
0.00
0.00
1.00
filtoffset =
0.50
0.50
0.50
0.00
0.50
0.00
0.00
0.50
filterror =
1.95
1.98
3.84
3.87
3.90
3.93
3.96
3.99
Summary of Changes
R20
R20(config)#ntp server 172.16.17.17 key 1 prefer
R20(config)#ntp server 172.16.19.19 key 1
Version 5.1A
58 | P a g e

Incident 10
(3 points)
R23 cannot establish a BGP peer relationship with ISP4.
Resolve the issue so that the peer relationship is formed from R23 to ISP4. The fix action must be
applied to R23 and not to ISP4.
Use the IPv4 and BGP diagrams to resolve this incident.
59|P a g e
Version 5.1A

Solution
The incident states that R23 cannot form a BGP relationship with ISP4. We need to establish basic
Layer 3 connectivity and then start looking at the BGP configuration of R23 and ISP4 to see if we can
get any base information to start with.
R23
R23#ping 1.1.1.30
!!!!!
R23#show run | section bgp

router bgp 2323
redistribute connected
ISP4
ISP4#sh run | section bgp
router bgp 444
!
address-family ipv4
exit-address-family
!
exit-address-family
!
Version 5.1A
60 | P a g e

neighbor 1.1.1.31 ttl-security hops 2
We have basic layer 3 connectivity. There is one thing that stands out in the BGP configuration of
ISP4. There is TTL-Security configured for the R23 peering. Remember that when TTL-Security is
configured on one side, the other side needs to be configured with multi-hop, or also needs to be
configured with TTL-Security. By default, a router sends out a TTL of 1. This forces a peer to be
directly connected. With this in mind, this also states that a router will only accept BGP peerings with
a TTL of 1. The TTL-Security feature inverts the direction in thich the TTL is counted. By enabling this
feature, the accepted TTL is set to 255 minus the hop-count, in this case 2. So now the peering will
ONLY accept messages with a TTL greater than or equal to 253. Lets set TTL-Security on R23. We
could also enable multihop (with TTL set to 253-255) to satisfy the requirements of this incident.
R23
R23(config-router)#neighbor 1.1.1.30 ttl-security hops 2
Verification
R23
R23#sh ip bgp neighbor
BGPneighbor is 1.1.1.30,
remote AS 444, external link
BGP version 4, remote router ID 172.16.204.204

BGP state = Established, up for 00:01:30
Last read 00:00:37, last write 00:00:37, hold time is 180, keepalive interval is 60
seconds
neighbor sessions:
1 active, is not multisession capable (disabled)
neighbor capabilities:
Route refresh: advertised and received(new)
Four-octets ASN Capability: advertised and received
Address family IPv4 Unicast: advertised and received
Enhanced Refresh Capability: advertised and received
Multisession Capability:
Stateful switchover support enabled: NO for session 1
Message statistics:
61|P a g e
Version 5.1A

InQ depth is 0
OutQ depth is 0
Sent
Rcvd
Opens:
Notifications:
Updates:
Keepalives:
Route Refresh:
Total:
10
Default minimum time between advertisement runs is 30 seconds
Summary of Changes
R23
R23(config-router)#neighbor 1.1.1.30 ttl-security hops 2
This concludes the Troubleshooting Section of iPexpert's R&S Lab 2 Detailed Solution Guide, Volume 2
Copyright iPexpert. All Rights Reserved.
Version 5.1A
62 | P a g e

Lab 2: Diagnostic Section :: Detailed

Solutions
Before You Begin
Please look at the provided information and read through this entire lab before you start. Read the
directions very carefully to make sure you are doing what is being asked of you. This is very important
when you take Ciscos CCIE lab.
Each task may contain a large amount of information including diagrams, email chains, trouble
tickets, device configs, and Wireshark captures. It is extremely important that you read through each
piece of information before answering the task.
Each task will require you to provide an answer to the issues provided, based off of the information
that is presented.
General Rules
63|P a g e
You do not have access to any equipment.

You are not required to configure any equipment.
Questions may be best selection, fill in the blank, multiple choice, order of operations, or best
match.
Version 5.1A

Ticket 1
(3 points)
A new trouble ticket has been escalated to you. The following information has been provided to help
with understanding the issue. Suggest the best methods to correct the issue.
Email Chain Between Customer and Helpdesk

From: Acme LLC
Sent: Wednesday, August 13, 2014 9:17 AM
To: iPexpert Level2
Subject: OSPF Issues
Hello,
We are implementing a new DMVPN network utilizing OSPF to connect to 2 new acquisition
companies. We are not able to bring up the OSPF adjacencies. We need some assistance. This issue
has high visibility so any priority you can put on this would be greatly appreciated!
Johnny Rocket
CIO, Acme Corp.
Direct: 111-111-1111
E-mail: johnny.rocket@acme.com
From: iPexpert Helpdesk

To: Acme LLC
Subject: RE: OSPF Issues
Mr. Rocket,
We would love to assist with this issue. We have opened up a ticket named Incident 45678 for
internal tracking. In order to better help, please provide the following:
A network diagram that shows the DMVPN and OSPF connectivity

Is there currently Internet connectivity at the 3 sites?
Is the DMVPN up and connected?
Once we have the above information, we will review, assign an engineer, and get back to you.
Kimye East
iPexpert Level 2 Engineer
Office: 999-999-9999 | level2@ipexpert.com
Version 5.1A
64 | P a g e

From: Johnny Rocket
To: iPexpert Level 2
Subject: OSPF Issues
The requested diagram has been attached. We have verified that there is full Internet connectivity
through the ISP at all 3 sites and we can ping all of the public interfaces from each device. The
DMVPN tunnel is up on each device and we can ping from HQ back to both spokes, but no networks
past them. We also do not want all traffic to flow through the hub router, spoke to spoke traffic
should not go through the Hub.
Thanks,
Johnny Rocket
CIO, Acme Corp.
Direct: 111-111-1111
E-mail: johnny.rocket@acme.com
From: iPexpert Level2

To: Johnny Rocket
Subject: RE: OSPF Issues
Mr. Cricket,
This incident has been assigned to our Sr. Network Engineer for review. You should hear something
back very soon. Thank you for your patience.
Kimye East
iPexpert Level 2 Engineer
Office: 999-999-9999 | level2@ipexpert.com
65|P a g e
Version 5.1A

Network Diagram
Acme HQ
DMVPN Hub
R1
Int Tun 10
10.10.10.1
Int E0/0
12.12.12.1
ISP1
Int Tun 10
10.10.10.2
Int E0/0
2.2.2.1
Int Tun 10
10.10.10.3
Int E0/0
3.3.3.1
R2
R3
Acquisition 1
Acquisition 2
This ticket has been assigned to you. You need to respond to the email thread with 2 suggestions for
best practices when using OSPF with DMVPN. Select the 2 best suggestions from the list below:
Use OSPF point-to-point as the network type on the tunnel interface of the DMVPN hub.
Configure the spokes to act as DMVPN designated routers.
Configure the spokes to act as DMVPN backup designated routers.
Use OSPF point-to-multipoint as the network type on tunnel interfaces of all 3 routers.
Manually set the OSPF timers on the DMVPN hub router to match those of the spoke routers.
Configure the DMVPN hub as the OSPF designated router.
Configure the DMVPN hub as the OSPF backup designated router.
Configure OSPF network type of broadcast on the DMVPN interfaces.
Version 5.1A
66 | P a g e

Solution
You need to respond to the email thread with 2 suggestions for best practices when using OSPF with
DMVPN. Select the 2 best suggestions from the list below:
Use OSPF point-to-point as the network type on the tunnel interface of the DMVPN hub.
Configure the spokes to act as DMVPN designated routers.
Configure the spokes to act as DMVPN backup designated routers.
Use OSPF point-to-multipoint as the network type on tunnel interfaces of all 3 routers.
Manually set the OSPF timers on the DMVPN hub router to match those of the spoke routers.
Configure the DMVPN hub as the OSPF designated router.
Configure the DMVPN hub as the OSPF backup designated router.
Configure OSPF network type of broadcast on the DMVPN interfaces.
Explanation
We need to remember that the task is asking for us to recommend the best practices out of the list
that is provided. While there may be better ways to perform the task or fix the issue, we need to
follow the guidelines of the test.
The first answer is to make the DMVPN hub the DR for the DMVPN network. In this implementation,
the hub is the only device that can send OSPF hellos to all spokes, which is the responsibility of the
DR.
The second answer is to config the DMVPN interfaces as broadcast. Non-broadcast and point-tomultipoint would also work but would not be the best practice here. Non-broadcast is not listed as
an option and does not scale well at all. Since the neighboring is not done dynamically, eachneighbor
has to be manually configured under the OSPF process. Point-to-Multipoint does not work for this
scenario because the last sentence of the email thread states that the Spokes should communicate
directly with each other and not traverse the Hub. Point-to-Multipoint would force traffic through
the hubs. The best answer here is to use broadcast as the network type. If we use broadcast, and
force the Hub to be DR, then the DR would be responsible for handling LSAs, while allowing the
Spokes to have direct communication.
67|P a g e
Version 5.1A

Ticket 2
(3 points)
A new trouble ticket has been escalated to you. The following information has been provided to help
with understanding the issue. Select the correct configuration to present to the customer.
Trouble Ticket from HelpDesk

From: Rock Johnson
Issue: Access Control List Assistance
9/12/2014 / 8:12am (Rock Johnson) Ticket creation.
9/12/2014 / 8:12am (Rock Johnson) Hello. We want to allow access for our Digital Video Recorders
(DVR) at each of our broadcasting sites to a central location, which is our broadcasting hub. While the
subnet is different, each sites DVR has the same host IP address of .227. There is currently a deny by
default access-list applied inbound at the broadcasting hub. We do not want to manage multiple
access-list rules. We are reaching out to you to get a solution that would allow us to only use 1 rule to
allow access from the .237 addresses at each site to the 172.16.1.5 host address at our central hub
on port tcp/465. Is this even possible and can you help us develop such a rule?
9/12/2014 / 8:15am (iPexpert Level2) Hi Mr. Johnson. This is absolutely possible and we would be
glad to help. We will need a few things to get started. First, we need a copy of the current access-list
that you have applied inbound at the broadcasting hub. Second, we will need the subnet information
for each of your remote broadcasting sites. You can input the information into this ticket. Once we
have that, we will get your request over to a Sr. Network Engineer and they will develop the new ACL.
9/12/2014 / 9:30am (Rock Johnson) Thanks! The information requested is below. The Access-list is
sequenced from 10 and increments by 10 for each line. We would like to keep our number
sequencing starting at 10 and incrementing by 10.
IP Info:
Broadcasting Site 1: 10.10.1.0/24
Affiliate Site 1: 10.150.16.0/24
Access-Control List:
ip access-list extended BC-HUB-INBOUND
10 permit icmp any 172.16.1.0 0.0.0.255
20 permit tcp 10.0.0.0 0.255.255.255 host 172.16.1.5 eq 25 22 21 80
30 permit tcp 10.0.0.0 0.255.255.255 host 172.16.1.15 eq 80 443
40 deny ip any any log
Version 5.1A
68 | P a g e

9/12/2014 / 9:35am (iPexpert Level2) Perfect! Thank you. I am assigning this ticket to our Level 3
Engineer. He will be in contact with you soon.
9/12/2014 / 9:38am (iPexpert Level2) Incident Assigned to Level 3 Engineer.
Based on the information in the ticket, select the configuration that meets all of the needs of the
customer from the list below. Choose 1:
69|P a g e

5 permit tcp 10.10.0.0 0.0.3.255 host 172.16.1.5 eq 465
ip access-list resequence BC-HUB-INBOUND 1 10




Version 5.1A

Solution
Based on the information in the ticket, select the configuration that meets all of the needs of the
customer from the list below. Choose 1:





Explanation
There are a few requirements here that will lead to the answer. First, they only want 1 line in the
ACL. Second, we need to match on the first and last octet since the second and third octets at the
sites change. Third, they want there sequence numbers to go in increments of 10, starting at 10. The
selected answer is the only one that matches all of the given criteria.
Version 5.1A
70 | P a g e

Ticket 3
(3 points)
You are developing a proposal for an internal VoIP service for a client, Risky Business. They are having
issues with voice quality over their WAN. Phones within each local LAN are not having any issues. You
have been tasked with creating a QoS policy that can be applied to minimize jitter, delay, and give
voice packets priority on the network. Review the information provided and select the 3 most
relevant considerations when developing a QoS policy to support VoIP.
Network Information
All phones at Headquarters are connected to Cisco 3750 switches and have port speeds of 1Gbps.
The switches are interconnected via 10Gbps fiber connections and each have a redundant path. The
network uses MST spanning-tree for loop avoidance. The switches only perform at layer 2 and do not
provide routing. A pair of Cisco 3900 ISR routers provides the routing. The switches connect to the ISR
routers via a trunk and the ISR routers utilize sub-interfaces with 802.1q tagging.
The phones at the other sites are setup similarly, but the networks are much smaller.
For WAN connectivity, each remote site has 2 T-1s using PPP multilink and HQ has 2 DS-3s using PPP
multilink, all connecting to a private MPLS cloud.
You need to identify common practices/pitfalls for a QoS policy when designed for VoIP in your
proposal. Select the 3 best common practices/pitfalls from the list below that apply to this scenario
for your proposal.
71|P a g e
You cannot apply QoS on a router sub-interface.
In addition to QoS, disabling PPP interleaving will help improve call quality and reduce jitter
and delay.
In addition to QoS, using RTP header compression on the PPP links will help improve call
quality and reduce voice latency.
Use a priority-queue to give the voice packets priority over other data.
When configured with a bandwidth or bandwidth percentage, a priority-queue does not

allocate bandwidth and shares bandwidth with the other queues.
Using RTP header compression on the PPP links will degrade voice call quality.
In addition to QoS, enabling PPP interleaving will help improve call quality and reduce jitter
and delay.
Version 5.1A

Solution
You need to identify common practices/pitfalls for a QoS policy when designed for VoIP in your
proposal. Select the 3 best common practices/pitfalls from the list below that apply to this scenario
for your proposal.
You cannot apply QoS on a router sub-interface.
In addition to QoS, disabling PPP interleaving will help improve call quality and reduce jitter and
delay.
In addition to QoS, using RTP header compression on the PPP links will help improve call quality
and reduce voice latency.
Use a priority-queue to give the voice packets priority over other data.
When configured with a bandwidth or bandwidth percentage, a priority-queue does not allocate
bandwidth and shares bandwidth with the other queues.
Using RTP header compression on the PPP links will degrade voice call quality.
In addition to QoS, enabling PPP interleaving will help improve call quality and reduce jitter and
delay.
Explanation
Enabling PPP interleaving helps with voice quality over slower serial links. Data packets tend to be
very large, usually 1500 bytes and voice packets are usually smaller, around 20-100 bytes, depending
on the codecs used. Interleaving allows the larger data packets to be broken into smaller ones and
interleaving the smaller voice packets with them so that they do not have to wait on the bigger
packets to get serialized.
RTP header compression also helps with jitter and delay. It is not a requirement, but it is a best
practice defined by Cisco. By enabling this, the RTP header is reduced from 40 bytes to 2-4 bytes.
This significately reduces the amount of bandwidth consumed by the RTP protocol and reduces the
size of the voice packet.
Giving voice traffic a priority queue guarantees that the voice traffic gets the defined amount of
bandwidth no matter what is on the link. It is a best practice however there are some pitfalls to be
careful of and must be considered. First, the priority queue is dedicated and does not share
resources with other queues. Second, it also polices traffic to the given bandwidth that is defined,
limiting what the voice traffic can use.
This concludes the Diagnostic Section of iPexpert's R&S Lab 2 Workbook, Volume 2
Version 5.1A
72 | P a g e

Lab 2: Configuration Section :: Detailed

Solutions
Before You Begin
Please look at the provided diagrams and read through the whole lab before you start. Read the
directions very carefully to make sure you are doing what is being asked of you. This concept is very
important when you take the CCIE lab administered by Cisco.
Multiple topology diagrams are available for this lab. Be sure to understand each diagram and what
information is being conveyed.
General Rules
73|P a g e
All IPv4 addresses are pre-configured except SVI, tunnel, sub-interfaces, and IPv6 interfaces
unless otherwise noted.
All Service Provider routers are pre-configured and cannot be accessed during the lab.
Do not modify any IP addressing on any interfaces unless instructed to do so.
The BB routers are not accessible.
Static/default routes are NOT allowed unless otherwise stated in the task.
Save your configurations often.
Version 5.1A

Pre-Setup
Please login to your vRack and load the initial Configuration.
This lab is intended to be used with online rack access. Connect to the terminal server and complete
the troubleshooting tasks as detailed below.
Version 5.1A
74 | P a g e

Diagram 2.3: IPv4
75|P a g e
Version 5.1A

Diagram 2.4: BGP
Version 5.1A
76 | P a g e

Diagram 2.5: IPv4 VPN
77|P a g e
Version 5.1A

Diagram 2.6: IPv6
Version 5.1A
78 | P a g e

Diagram 2.7: MPLS VPN
79|P a g e
Version 5.1A

Section 1.0: Layer 2 Technologies

Task 1.1: Layer 2 VLANs
(14 points)
(4 points)
HQ MPLS Core
o
Configure the necessary VLANs on SW1 and SW2.
Use VTP domain name IPX.
Use VTP password IPExpert!.
Use VTP version 2.
SW2 should always be the VTP master. SW1 should not learn any VLANs from SW2, but should
pass VLAN information using VTP. All other switches should be set to client. SW1 should know
about all local VLANs.
Do not configure any VLANs on SW3 or SW4. They should learn the VLANs from the VTP server.
Configure the necessary VLANs on SW5, SW6, SW7, and SW8.

o
Do not use VTP to accomplish this.
SW5, SW6, SW7, and SW8 should pass VTP information but not use it to configure VLANs.
Solution
We will work this task from the top down. The first part of this task is to configure the necessary
VLANs for SW1-4. We are to use VTP and SW2 is the VTP master. Also, SW1 should not to
participate in VTP but should pass VTP traffic. We need to first create the VLANs on SW2 and then
on SW1 since it will not learn them via VTP.
SW1 and SW2

(config)#vlan 17,19,31,67,59,120,510,666,999
Now, lets configure SW1 and SW2 for VTP. We configure SW3 and SW4 next.
80|P a g e
Version 5.1A

SW1
SW1(config)#vtp mode transparent
SW1(config)#vtp domain IPX
SW1(config)#vtp password IPExpert!
SW1(config)#vtp version 2
SW2
SW2(config)#vtp mode server
SW2(config)#vtp domain IPX
SW2(config)#vtp password IPExpert!
SW2(config)#vtp version 2
Configure SW3 and SW4 as VTP clients.
SW3 and SW4

(config)#vtp domain IPX
(config)#vtp password IPExpert!
(config)#vtp version 2
(config)#vtp mode client
We now move on to SW5 and SW6. These switches need to be in VTP Transparent mode. Configure
the VLANs and VTP as follows:
SW5 and SW6

(config)#vtp mode transparent
(config)#vlan 102,114,121,123,134
We need to do the same thing for SW7 and SW8.
SW7 and SW8

(config)#vtp mode transparent
(config)#vlan 168,169,179,189,207,209
Verification
NOTE
Some commands are truncated.
81|P a g e
Version 5.1A

SW1
SW1#show vlan
VLAN Name
Status
Ports
---- -------------------------------- --------- ----------------------17
VLAN0017
active
19
VLAN0019
31
VLAN0031
active
59
VLAN0059
active
67
VLAN0067
active
120
VLAN0120
510
VLAN0510
active
666
VLAN0666
active
999
VLAN0999
active
active
active
SW1#show vtp status

VTP Version capable
: 1 to 3
VTP version running
: 2
VTP Domain Name
: IPX
VTP Pruning Mode
: Disabled
VTP Traps Generation
: Disabled
Device ID
: aabb.cc00.6500
Configuration last modified by 172.16.101.101 at 11-1-14 15:21:49
Feature VLAN:
-------------VTP Operating Mode
: Transparent
Maximum VLANs supported locally
: 1005
Number of existing VLANs
: 14
Configuration Revision
: 0
SW2
SW2#show vlan
VLAN Name
Status
Ports
---- -------------------------------- --------- ----------------------17
VLAN0017
19
VLAN0019
31
VLAN0031
active
59
VLAN0059
active
Version 5.1A
active
active
82 | P a g e

67
VLAN0067
active
120
VLAN0120
510
VLAN0510
active
666
VLAN0666
active
999
VLAN0999
active
active
SW2#show vtp status

VTP Version capable
: 1 to 3
VTP version running
: 2
VTP Domain Name
: IPX
VTP Pruning Mode
: Disabled
: Disabled
Device ID
: aabb.cc00.6600

Local updater ID is 172.16.102.102 on interface Lo0 (first layer3 interface found)
Feature VLAN:
: Server
: 1005
: 14
: 2
SW3
SW3#show vlan
VLAN Name
Status
Ports
---- -------------------------------- --------- ----------------------17
VLAN0017
19
VLAN0019
31
VLAN0031
active
59
VLAN0059
active
67
VLAN0067
active
120
VLAN0120
510
VLAN0510
active
666
VLAN0666
active
999
VLAN0999
active
83|P a g e
active
active
active
Version 5.1A

SW3#show vtp status
VTP Version capable
: 1 to 3
VTP version running
: 2
VTP Domain Name
: IPX
VTP Pruning Mode
: Disabled
: Disabled
Device ID
: aabb.cc00.6700
Feature VLAN:
: Client
: 1005
: 14
: 2
SW4
SW4#show vlan
VLAN Name
Status
Ports
---- -------------------------------- --------- ----------------------17
VLAN0017
active
19
VLAN0019
31
VLAN0031
active
59
VLAN0059
active
67
VLAN0067
active
120
VLAN0120
510
VLAN0510
active
666
VLAN0666
active
999
VLAN0999
active
active
active
SW4#show vtp status

VTP Version capable
: 1 to 3
VTP version running
: 2
VTP Domain Name
: IPX
VTP Pruning Mode
: Disabled
: Disabled
Device ID
: aabb.cc00.6800
Version 5.1A
84 | P a g e

Feature VLAN:
: Client
: 1005
: 14
: 2
SW5
SW5#show vlan
VLAN Name
Status
Ports
---- -------------------------------- --------- ----------------------102
VLAN0102
active
114
VLAN0114
active
121
VLAN0121
active
123
VLAN0123
active
134
VLAN0134
active
SW5#sh vtp status

VTP Version capable
: 1 to 3
VTP version running
: 1
VTP Domain Name
VTP Pruning Mode
: Disabled
: Disabled
Device ID
: aabb.cc00.6900

Feature VLAN:
: Transparent
: 1005
: 10
: 0
85|P a g e
Version 5.1A

SW6
SW6#show vlan
102
VLAN0102
active
114
VLAN0114
active
121
VLAN0121
active
123
VLAN0123
active
134
VLAN0134
active
SW6#show vtp status

VTP Version capable
: 1 to 3
VTP version running
: 1
VTP Domain Name
VTP Pruning Mode
: Disabled
: Disabled
Device ID
: aabb.cc00.6a00
Feature VLAN:
: Transparent
: 1005
: 10
: 0
SW7
SW7#show vlan
168
VLAN0168
active
169
VLAN0169
active
179
VLAN0179
active
189
VLAN0189
active
207
VLAN0207
active
209
VLAN0209
active
SW7#show vtp status

VTP Version capable
: 1 to 3
VTP version running
: 1
VTP Domain Name
VTP Pruning Mode
: Disabled
Version 5.1A
86 | P a g e

: Disabled
Device ID
: aabb.cc00.6b00
Feature VLAN:
: Transparent
: 1005
: 11
: 0
SW8
SW8#show vlan
168
VLAN0168
active
169
VLAN0169
active
179
VLAN0179
active
189
VLAN0189
active
207
VLAN0207
active
209
VLAN0209
active
SW8#show vtp status

VTP Version capable
: 1 to 3
VTP version running
: 1
VTP Domain Name
VTP Pruning Mode
: Disabled
: Disabled
Device ID
: aabb.cc00.6c00
Feature VLAN:
: Transparent
: 1005
: 11
: 0
87|P a g e
Version 5.1A

Task 1.2: Switch-to-Switch Links
Using the Layer 2 diagram, configure the switch-to-switch links on SW1, SW2, SW3, and SW4 as
dot1q trunks.
o
Use a Cisco proprietary technology to perform this task.
Create an ether-channel using interfaces e4/0 and e4/1 between SW1 and SW4. Perform the
same task between SW2 and SW3.
o
Make sure that the trunk configuration is not negotiated and is always on.
Create an ether-channel using interfaces e3/0, e3/1 and 3/2 on both SW1 and SW2.
o
(4 points)
Use a non-proprietary protocol to accomplish this task.
Configure the switch-to-switch links on SW5, SW6, SW7, and SW8 as dot1q trunks.
o
Make sure that the trunk links are not negotiated.
All trunks should use 802.1q as the encapsulation protocol.
Ensure that only the VLANs needed for the topology are allowed across the trunks.
Solution
The first bullet asks us to configure the inter-switch links in the HQ MPLS Core topology. The only
gotcha here is that is specifies us to use dot1q and to not allow trunk negotiation.
SW1 and SW2

(config)#int range e3/0-2, e4/0-1, e5/0
(config-if-range)#switchport trunk encapsulation dot1q
(config-if-range)#switchport mode trunk
SW3 and SW4

(config)#int range e3/0-1, e4/0-1, e5/0
Version 5.1A
88 | P a g e

We need to configure an Etherchannel between SW1 and SW2. It also states to use a Cisco
proprietary protocol to accomplish the task. There are 2 options, LACP and PAgP. PAgP is the Cisco
proprietary protocol.
SW1 and SW2

(config)#interface port-channel 1
(config-if)#switchport
(config-if)#switchport trunk encapsulation dot1q
(config-if)#switchport mode trunk
(config)#interface range e3/0-2

(config-if-range)#channel-group 1 mode desirable
Next, we need to configure EtherChannel between SW1 and SW3, and between SW2 and SW4. The
task asks us to use a non-propriatary protocol, which tells us that we need to use LACP.
SW1, SW2, SW3, and SW4

(config)#interface port-channel 2
(config-if)#switchport
(config-if)#switchport trunk encapsulation dot1q
(config-if)#switchport mode trunk
(config)#interface range e4/0-1
(config-if-range)#channel-group 2 mode active
The final part to this task is to create the trunks between SW5-SW6 and SW7-SW8. The trunk needs
to be dot1q and not negotiated. We also need to only allow the VLANs needed for each area.
SW5 and SW6

(config)#int range e2/0-3
(config-if-range)#switchport trunk allowed vlan 102,114,121,123,134
SW7 and SW8

(config)#int range e2/0-3
(config-if-range)#switchport trunk allowed vlan 168,168,179,189,207,209
89|P a g e
Version 5.1A

Verification
Lets first verify that SW1, SW2, SW3, and SW4 are using the port-channels, the port-channels are
setup for PAgP and LACP, and that the trunks are setup as dot1q trunks. The results below are from
SW1, but you will need to perform this verification on each switch.
SW1
SW1#show etherchannel summ
Number of channel-groups in use: 2
Number of aggregators:
Group
Ports
Port-channel
Protocol
------+-------------+-----------+----------------------------------------------1
Po1(SU)
PAgP
Et3/0(P)
Et3/1(P)
Po2(SU)
LACP
Et4/0(P)
Et4/1(P)
Et3/2(P)
SW1#show interface trunk

Port
Mode
Encapsulation
Status
Native vlan
Et5/0
on
802.1q
trunking
Po2
on
802.1q
trunking
Po1
on
802.1q
trunking
Port
Et5/0
1-4094
Po2
1-4094
Po1
1-4094
Port
Et5/0
1,17,19,31,59,67,120,510,666,999
Po2
1,17,19,31,59,67,120,510,666,999
Po1
1,17,19,31,59,67,120,510,666,999
Port
Et5/0
1,17,19,31,59,67,120,510,666,999
Po2
1,17,19,31,59,67,120,510,666,999
Po1
1,17,19,31,59,67,120,510,666,999
Version 5.1A
90 | P a g e

Now lets verify SW5-SW6 and SW7-SW8. The below output is from SW5 but will need to be done on
each switch. We need to verify that the trunks are using 802.1q encapsulation and is not negotiated.
Last, verify that only the needed VLANs are allowed across the trunk.
SW5
SW5#show interface trunk
Port
Mode
Encapsulation
Status
Native vlan
Et2/0
on
802.1q
trunking
Et2/1
on
802.1q
trunking
Et2/2
on
802.1q
trunking
Et2/3
on
802.1q
trunking
Port
Et2/0
102,114,121,123,134
Et2/1
102,114,121,123,134
Et2/2
102,114,121,123,134
Et2/3
102,114,121,123,134
Port
Et2/0
102,114,121,123,134
Et2/1
102,114,121,123,134
Et2/2
102,114,121,123,134
Et2/3
102,114,121,123,134
Port
Et2/0
102,114,121,123,134
Et2/1
102,114,121,123,134
Et2/2
102,114,121,123,134
Et2/3
102,114,121,123,134
91|P a g e
Version 5.1A

SW7
SW7#sh int tru
Port
Mode
Encapsulation
Status
Native vlan
Et2/0
on
802.1q
trunking
Et2/1
on
802.1q
trunking
Et2/2
on
802.1q
trunking
Et2/3
on
802.1q
trunking
Port
Et2/0
168,179,189,207,209
Et2/1
168,179,189,207,209
Et2/2
168,179,189,207,209
Et2/3
168,179,189,207,209
Port
Et2/0
168,179,189,207,209
Et2/1
168,179,189,207,209
Et2/2
168,179,189,207,209
Et2/3
168,179,189,207,209
Port
Et2/0
168,179,189,207,209
Et2/1
168,179,189,207,209
Et2/2
168,179,189,207,209
Port
Et2/3
168,179,189,207,209
Task 1.3: Router Links
(3 points)
Using the IPv4 and Layer 2 diagrams, configure each Router connection in the correct VLAN.
All Switch-to-Router interfaces should be set as an access port except those connected to subinterfaces. Sub-interfaces should be set up as an 802.1q trunk without negotiation. These trunk
links should only allow the VLANs needed for the topology to function correctly.
Version 5.1A
92 | P a g e

Solution
Keeping all of these interfaces straight and jumping between the Layer 2 and IPv4 diagrams can be a
chore. Be sure to verify that you are configuring the correct interface on the switch. It is easy to
transpose the router interface and the switch interface. Also remember that there are a few trunks
needed for Routers with sub-interfaces. These trunks should be setup for 802.1q encapsulation and
to only allow the vlans needed on the trunks.
SW1
SW1(config-if)#switchport mode access
SW1(config-if)#switchport access vlan 120
SW2
SW2(config-if)#switchport trunk encapsulation dot1q
SW2(config-if)#switchport mode trunk
SW2(config-if)#switchport trunk allowed vlan 17,31
93|P a g e
Version 5.1A

SW3
SW3(config)#interface e1/1
SW3(config)#interface e1/0
SW4
SW5
Version 5.1A
94 | P a g e

SW6
SW7
95|P a g e
Version 5.1A

SW8
Version 5.1A
96 | P a g e

Verification
The best way to verify this section is to ping all directly connected peers from each device. Below is
the output from R1 but you will need to do this from EVERY device connected Layer3 through a
switch. This is extremely important. You do not want to be in a situation where you are
troubleshooting Layer 2 issues while configuring other technologies.
R1
R1#ping 192.168.1.17
.!!!!
R1#ping 192.168.1.9
.!!!!
R1#ping 192.168.1.21
!!!!!
Task 1.4: Spanning-Tree Tuning
(3 points)
SW1, SW2, SW3, SW4 should all have 3 spanning-tree instances.

o
SW1 should be the primary root bridge for all even VLANs and the secondary root for all
odd VLANs.
SW2 should be the primary root bridge for all odd VLANs and the secondary root bridge
for all even VLANs.
All non-trunking ports on SW1, SW2, SW3, and SW4 should participate in STP and move directly
into the forwarding state when enabled. Use a single command on each device to accomplish
this.
All non-trunking ports on SW1, SW2, SW3, and SW4 should be shutdown when a BPDU is
received. Use a single command on each device to accomplish this.
97|P a g e
Version 5.1A

Solution
The task asks us to configure spanning-tree to have 3 instances for SW1, SW2, SW3, and SW4. We
can do this using MST. We need to create an instance for even VLANs, for odd VLANs. The third
instance will be instance zero which is created by default.

(config)#spanning-tree mst configuration
(config-mst)#instance 1 vlan 17,19,31,59,67,999
(config-mst)#instance 2 vlan 120,510,666
(config-mst)#revision 1
(config-mst)#exit
(config)#spanning-tree mode mst
Now lets configure the Root and Backup Root bridges for the instances. SW1 is the primary for even
VLANs (instance 2) and secondary for odd VLANs. SW2 is primary for odd VLANs (instance 1) and
secondar for even VLANs.
SW1
SW1(config)#spanning-tree mst 2 root primary
SW1(config)#spanning-tree mst 1 root secondary
SW2
SW2(config)#spanning-tree mst 1 root primary
SW2(config)#spanning-tree mst 2 root secondary
The next part of this task asks us to configure each switchport to go to the forwarding STP state
immediately and only use 1 command to accomplish this. This is the STP port-fast feature. You can
enable port-fast globally with 1 command.

(config)#spanning-tree portfast default
Just with the last step, we need to enable BPDU-guard globally since the task asks for ports to be
shutdown if a BPDU is detected on an interface and to enable this with 1 command.

(config)#spanning-tree portfast bpduguard default
Version 5.1A
98 | P a g e

Verification
We need to verify a few things. First, spanning-tree needs to be in MST mode and running 3
instances. Also, the root bridges are setup properly. And last, that BPDU and PortFast are enabled.
SW1
SW1#sh spanning-tree mst
##### MST0
vlans mapped:
1-16,18,20-30,32-58,60-66,68-119,121-509
511-665,667-998,1000-4094
Bridge
address aabb.cc00.6500
Root
this switch for the CIST
Operational
Configured
Interface
priority
32768 (32768 sysid 0)
hello time 2 , forward delay 15, max age 20, txholdcount 6

hello time 2 , forward delay 15, max age 20, max hops
Role Sts Cost
20
Prio.Nbr Type
---------------- ---- --- --------- -------- -------------------------Et0/1
Desg FWD 2000000
128.2
Shr Edge
Et0/2
Desg FWD 2000000
128.3
Shr Edge
Et0/3
Desg FWD 2000000
128.4
Shr Edge
Et1/1
Desg FWD 2000000
128.6
Shr Edge
Et5/0
Desg FWD 2000000
128.21
Shr
Po1
Desg FWD 2000000
128.65
Shr
Po2
Desg FWD 1000000
128.66
Shr
##### MST1
vlans mapped:
Bridge
priority
28673 (28672 sysid 1)
Root
priority
24577 (24576 sysid 1)
port
cost
2000000
Interface
17,19,31,59,67,999
Po1
Role Sts Cost
rem hops 19
Prio.Nbr Type
---------------- ---- --- --------- -------- -------------------------Et0/3
Desg FWD 2000000
128.4
Shr Edge
Et1/1
Desg FWD 2000000
128.6
Shr Edge
Et5/0
Altn BLK 2000000
128.21
Shr
Et5/3
Desg FWD 2000000
128.24
Shr Edge
Po1
Root FWD 2000000
128.65
Shr
Po2
Desg FWD 1000000
128.66
Shr
##### MST2
99|P a g e
vlans mapped:
120,510,666
Version 5.1A

Bridge
Root
this switch for MST2
Interface
Role Sts Cost
priority
24578 (24576 sysid 2)
Prio.Nbr Type
---------------- ---- --- --------- -------- -------------------------Et0/1
Desg FWD 2000000
128.2
Shr Edge
Et1/2
Desg FWD 2000000
128.7
Shr Edge
Et5/0
Desg FWD 2000000
128.21
Shr
Po1
Desg FWD 2000000
128.65
Shr
Po2
Desg FWD 1000000
128.66
Shr
SW2
SW2#show spanning-tree mst
##### MST0
vlans mapped:
1-16,18,20-30,32-58,60-66,68-119,121-509
511-665,667-998,1000-4094
Bridge
priority
32768 (32768 sysid 0)
Root
priority
32768 (32768 sysid 0)
port
path cost
priority
32768 (32768 sysid 0)
Po1
Regional Root address aabb.cc00.6500
internal cost 2000000 rem hops 19

Operational
Configured
Interface
hello time 2 , forward delay 15, max age 20, txholdcount 6

Role Sts Cost
20
Prio.Nbr Type
---------------- ---- --- --------- -------- -------------------------Et0/1
Desg FWD 2000000
128.2
Shr
Et0/2
Desg FWD 2000000
128.3
Shr Edge
Et0/3
Desg FWD 2000000
128.4
Shr Edge
Et1/3
Desg FWD 2000000
128.8
Shr Edge
Et2/0
Desg FWD 2000000
128.9
Shr Edge
Et2/1
Desg FWD 2000000
128.10
Shr Edge
Et5/0
Altn BLK 2000000
128.21
Shr
Et5/3
Desg FWD 2000000
128.24
Shr Edge
Po1
Root FWD 2000000
128.65
Shr
Po2
Desg FWD 1000000
128.66
Shr
##### MST1
vlans mapped:
Bridge
Version 5.1A
17,19,31,59,67,999
priority
24577 (24576 sysid 1)
100 | P a g e

Root
Interface
this switch for MST1
Role Sts Cost
Prio.Nbr Type
---------------- ---- --- --------- -------- -------------------------------Et0/1
Desg FWD 2000000
128.2
Shr
Et1/3
Desg FWD 2000000
128.8
Shr Edge
Et2/1
Desg FWD 2000000
128.10
Shr Edge
Et5/0
Desg FWD 2000000
128.21
Shr
Po1
Desg FWD 2000000
128.65
Shr
Po2
Desg FWD 1000000
128.66
Shr
##### MST2
vlans mapped:
Bridge
priority
28674 (28672 sysid 2)
Root
priority
24578 (24576 sysid 2)
port
cost
2000000
Interface
120,510,666
Po1
Role Sts Cost
rem hops 19
Prio.Nbr Type
---------------- ---- --- --------- -------- -------------------------Et2/0
Desg FWD 2000000
128.9
Shr Edge
Et5/0
Altn BLK 2000000
128.21
Shr
Po1
Root FWD 2000000
128.65
Shr
Po2
Desg FWD 1000000
128.66
Shr
SW3
##### MST0
vlans mapped:
1-16,18,20-30,32-58,60-66,68-119,121-509
511-665,667-998,1000-4094
Bridge
priority
32768 (32768 sysid 0)
Root
priority
32768 (32768 sysid 0)
port
path cost
priority
32768 (32768 sysid 0)
Et5/0

Operational
hello time 2 , forward delay 15, max age 20,txholdcount 6
Configured
hello time 2 , forward delay 15, max age 20,max hops
Interface
Role Sts Cost
20
Prio.Nbr Type
---------------- ---- --- --------- -------- -------------------------Et1/1
101|P a g e
Desg FWD 2000000
128.6
Shr Edge
Version 5.1A

Et3/0
Altn BLK 2000000
128.13
Shr
Et3/1
Altn BLK 2000000
128.14
Shr
Et5/0
Root FWD 2000000
128.21
Shr
Po2
Altn BLK 1000000
128.65
Shr
##### MST1
vlans mapped:
Bridge
priority
32769 (32768 sysid 1)
Root
priority
24577 (24576 sysid 1)
port
cost
1000000
Interface
17,19,31,59,67,999
Po2
Role Sts Cost
rem hops 19
Prio.Nbr Type
---------------- ---- --- --------- -------- -------------------------Et3/0
Desg FWD 2000000
128.13
Shr
Et3/1
Desg FWD 2000000
128.14
Shr
Et5/0
Desg FWD 2000000
128.21
Shr
Po2
Root FWD 1000000
128.65
Shr
##### MST2
vlans mapped:
Bridge
priority
32770 (32768 sysid 2)
Root
priority
24578 (24576 sysid 2)
port
cost
2000000
Interface
120,510,666
Et5/0
Role Sts Cost
rem hops 19
Prio.Nbr Type
---------------- ---- --- --------- -------- -------------------------Et1/0
Desg FWD 2000000
128.5
Shr Edge
Et1/1
Desg FWD 2000000
128.6
Shr Edge
Et3/0
Altn BLK 2000000
128.13
Shr
Et3/1
Altn BLK 2000000
128.14
Shr
Et5/0
Root FWD 2000000
128.21
Shr
Po2
Altn BLK 1000000
128.65
Shr
SW4
##### MST0
vlans mapped:
1-16,18,20-30,32-58,60-66,68-119,121-509
511-665,667-998,1000-4094
Bridge
priority
32768 (32768 sysid 0)
Root
priority
32768 (32768 sysid 0)
Version 5.1A
102 | P a g e

port
Po2
path cost
priority
32768 (32768 sysid 0)

Operational hello time 2 , forward delay 15, max age 20, txholdcount 6
Configured
Interface
Role Sts Cost
20
Prio.Nbr Type
---------------- ---- --- --------- -------- -------------------------Et1/2
Desg FWD 2000000
128.7
Shr Edge
Et1/3
Desg FWD 2000000
128.8
Shr Edge
Et2/0
Desg FWD 2000000
128.9
Shr Edge
Et2/1
Desg FWD 2000000
128.10
Shr Edge
Et3/0
Desg FWD 2000000
128.13
Shr
Et3/1
Desg FWD 2000000
128.14
Shr
Et5/0
Desg FWD 2000000
128.21
Shr
Po2
Root FWD 1000000
128.65
Shr
##### MST1
vlans mapped:
Bridge
priority
32769 (32768 sysid 1)
Root
priority
24577 (24576 sysid 1)
port
cost
2000000
Interface
17,31,59,67,999
Et5/0
Role Sts Cost
rem hops 19
Prio.Nbr Type
---------------- ---- --- --------- -------- -------------------------Et1/2
Desg FWD 2000000
128.7
Shr Edge
Et1/3
Desg FWD 2000000
128.8
Shr Edge
Et2/1
Desg FWD 2000000
128.10
Shr Edge
Et3/0
Altn BLK 2000000
128.13
Shr
Et3/1
Altn BLK 2000000
128.14
Shr
Et5/0
Root FWD 2000000
128.21
Shr
Po2
Altn BLK 1000000
128.65
Shr
##### MST2
vlans mapped:
Bridge
priority
32770 (32768 sysid 2)
Root
priority
24578 (24576 sysid 2)
port
cost
1000000
Interface
120,510,666
Po2
Role Sts Cost
rem hops 19
Prio.Nbr Type
---------------- ---- --- --------- -------- --------------------------
103|P a g e
Version 5.1A

Et3/0
Desg FWD 2000000
128.13
Shr
Et3/1
Desg FWD 2000000
128.14
Shr
Et5/0
Desg FWD 2000000
128.21
Shr
Po2
Root FWD 1000000
128.65
Shr
Task 1.5: Verify Connectivity
Verify all directly connected devices can ping each other.
Version 5.1A
104 | P a g e

Section 2.0: IP Routing

Task 2.1: EIGRP AS 111
Enable EIGRP in AS 111 on all interfaces that do not leave the autonomous system.
Ensure that no interfaces advertise hello messages other than the ones specified.
o
(28 points)
(2 points)
Do not use the passive-interface feature of EIGRP to accomplish this.
Use EIGRP wide metrics.
Advertise the Loopback0 interface of each device into EIGRP as internal routes.
Authenticate all EIGRP neighbor relationships using the MD5 password IPXpert!.
Solution
There are two parts to this configuration. First, it states that we should use EIGRP wide metrics. This
is done by configuring EIGRP using named mode. The second part to this is that EIGRP is using
authentication. We will configure authentication after we get EIGRP up. Lets start with bringing
EIGRP up. The task states that we should not advertise hellos out of interfaces that are not part of
the EIGRP topology. We can do this by using host network statements specific to the interface.
R1
R1(config)#router eigrp CORE
R1(config-router)#address-family ipv4 autonomous-system 111
R1(config-router-af)#network 192.168.1.18 0.0.0.0
R2
105|P a g e
Version 5.1A

R3
R4
R5
R6
R7
Version 5.1A
106 | P a g e

R8
R9
Now, lets configure authentication. With EIGRP named mode, this task has become more
streamlined. First, define the key-chain, then apply it to the default interface under EIGRP.
On ALL Devices in EIGRP 111

(config)#key chain EIGRP
(config-keychain)#key 1
(config-keychain-key)#key-string IPXpert!
(config)#router eigrp CORE

(config-router)#address-family ipv4 autonomous-system 111
(config-router-af)#af-interface default
(config-router-af-interface)#authentication mode md5
(config-router-af-interface)#authentication key-chain EIGRP
Verification
We can verify connectivity by running the below TCL script to ping all subnets within the EIGRP 111
topology, including loopback interfaces. All results should be succesfull from the generated pings.
107|P a g e
Version 5.1A

On All Devices in EIGRP 111

(tcl)#tclsh
(tcl)#foreach address {
+>(tcl)#192.168.1.253
+>(tcl)#192.168.1.254
+>(tcl)#192.168.1.17
+>(tcl)#192.168.1.18
+>(tcl)#192.168.1.22
+>(tcl)#192.168.1.21
+>(tcl)#192.168.1.10
+>(tcl)#192.168.1.9
+>(tcl)#192.168.1.1
+>(tcl)#192.168.1.2
+>(tcl)#192.168.1.241
+>(tcl)#192.168.1.242
+>(tcl)#192.168.1.6
+>(tcl)#192.168.1.5
+>(tcl)#192.168.1.246
+>(tcl)#192.168.1.245
+>(tcl)#192.168.1.13
+>(tcl)#192.168.1.14
+>(tcl)#192.168.1.25
+>(tcl)#192.168.1.26
+>(tcl)#172.16.2.2
+>(tcl)#172.16.3.3
+>(tcl)#172.16.1.1
+>(tcl)#172.16.7.7
+>(tcl)#172.16.6.6
+>(tcl)#172.16.8.8
+>(tcl)#172.16.9.9
+>(tcl)#172.16.5.5
+>(tcl)#172.16.4.4
+>(tcl)#10.10.1.1
+>(tcl)#10.10.2.1
+>(tcl)#10.10.3.1
+>(tcl)#10.10.4.1
+>(tcl)#} { ping $address }
Version 5.1A
108 | P a g e

Task 2.2: EIGRP 112
Enable EIGRP in AS 112 on all interfaces that do not leave the autonomous system.
Ensure that no interfaces advertise hello messages other than the ones specified.
o
(4 points)
Use the passive-interface feature for this.
When using the network command, use only the class-full network.
Do not use EIGRP named mode for this configuration.
Advertise the Loopback0 interface of each device into EIGRP as internal routes.
R24 and R25 should peer with EIGRP via their tunnel interfaces and advertise their loopback
interfaces.
Verify full connectivity in Dallas as well as to the loopback interfaces of R24 and R25.
Solution
There are a few things to note here. First, we are to use classfull network statements. Second, we
should use the passive-interface default feature. Third, we should NOT use named mode. Finally, we
are supposed to advertise the tunnel interfaces of R24 and R25 but we have not configured the
tunnels yet. We will need to revist this once we bring up the tunnels. Lets get EIGRP configured.
R10
R10(config)#router eigrp 112
R10(config-router)#network 172.16.0.0
R10(config-router)#passive-interface default
R10(config-router)#no passive-interface e0/1
R11
109|P a g e
Version 5.1A

R12
R12(config-router)#no passive-interface e0/0.102
R12(config-router)#no passive-interface e0/0.123
R13
R14
Verification
We will run the same verification as the last task on each device. We will verify R24 and R25 as soon
as we configure the Tunnels in a later task.
Version 5.1A
110 | P a g e

On All Devices in EIGRP 112

#tclsh
+>192.168.11.17
+>192.168.11.18
+>192.168.11.1
+>192.168.11.2
+>192.168.11.13
+>192.168.11.14
+>192.168.11.5
+>192.168.11.6
+>192.168.11.9
+>192.168.11.10
+>172.16.10.10
+>172.16.11.11
+>172.16.12.12
+>172.16.13.13
+>172.16.14.14
+>} { ping $address }
Task 2.3: OSPF Area 0
(4 points)
Enable OSPF 0 on all interfaces that do not leave the autonomous system.
R19 should be the DR, and there should not be a BDR elected for VLANs 169, 179, 189, and 209.
o
Ensure no other device can become DR/BDR for the specified VLANs.
Area 0 should be authenticated using MD5 and the password IPXOSPF.
Advertise the loopback 0 interface of all devices in area 0 with their original mask.
The Teleworker offices should be in OSPF area 1 and peer with R20 via the tunnel interface.
Verify full connectivity in Seattle HQ, along with the Teleworker office Loopback interfaces.
111|P a g e
Version 5.1A

Solution
We need to configure OSPF along with MD5 authentication as follows:
R16, R17, R18, and R20

(config)#router ospf 1
(config-router)#area 0 authentication message-digest
(config-router)#network 172.16.0.0 0.0.255.255 area 0
(config)#interface e0/0
(config-if)#ip ospf message-digest-key 1 md5 IPXOSPF
(config-if)#ip ospf prio 0
(config)#interface e0/1
(config-if)#ip ospf prio 0
(config-if)#ip ospf message-digest-key 1 md5 IPXOSPF
R19
R19(config-router)# area 0 authentication message-digest
R19(config-router)# network 172.16.0.0 0.0.255.255 area 0
R19(config-router)# network 192.168.54.0 0.0.0.255 area 0
R19(config-router)#interface e0/0.169
R19(config-subif)#ip ospf message-digest-key 1 md5 IPXOSPF
R19(config-subif)#interface e0/0.189
The task asks for us to advertise the loopback interfaces with their original masks. The network
commands for the loopbacks are already added to OSPF but the routes are showing up as /32 host
routes. By default, OSPF advertised loopback interfaces with /32 masks. We can change this
behavior by setting the OSPF network type of the interface to point-to-point.
Version 5.1A
112 | P a g e

R16, R17, R18, R19, and R20

(config)#int loopback 0
(config-if)#ip ospf network point-to-point
The next part of this task asks us to add the Teleworker offices into OSPF via the tunnel interfaces.
We have not configured the tunnel interfaces yet so we will need to do this once we get to that part
in the Lab. Write it down as a reminder.
Verification
Run the following TCL script for the area on all devices to test full reachability.
R19
R19#sh ip ospf ne
Neighbor ID
Pri
State
Dead Time
Address
Interface
172.16.20.20
FULL/DROTHER
00:00:39
192.168.54.18
Ethernet0/1.209
172.16.17.17
FULL/DROTHER
00:00:39
192.168.54.22
Ethernet0/1.179
172.16.18.18
FULL/DROTHER
00:00:39
192.168.54.14
Ethernet0/0.189
172.16.16.16
FULL/DROTHER
00:00:39
192.168.54.9
Ethernet0/0.169
On All Devices in OSPF 0

#tclsh
+>192.168.54.1
+>192.168.54.2
+>192.168.54.9
+>192.168.54.10
+>192.168.54.13
+>192.168.54.14
+>192.168.54.17
+>192.168.54.18
+>192.168.54.21
+>192.168.54.22
+>192.168.54.5
+>192.168.54.6
+>172.16.16.16
+>172.16.17.17
113|P a g e
Version 5.1A

+>172.16.18.18
+>172.16.19.19
+>172.16.20.20
Task 2.4: BGP HQ MPLS Core
(5 points)
Use the BGP and MPLS VPN diagrams to accomplish this task.
R6 will be the primary P router in the MPLS design.
The HQ MPLS Core is a transit network and does not have reachability to the VRF networks
specified in the MPLS VPN diagram.
IPv4 should be disabled by default and no peer groups should be configured.
Make the following BGP VPNv4 peerings in the HQ MPLS Core using interface Loopback 0:
o
AS 65102 -> AS 65106
AS 65103 -> AS 65106
AS 65101 -> AS 65106
AS 65107 -> AS 65106
AS 65105 -> AS 65106
AS 65109 -> AS 65106
Solution
According to the task, all HQ MPLS BGP peerigns are EBGP, so we do not need to configure routereflectors or have full mesh. It also states that the peerings are to use Loopback 0 as the source and
that the peerings should be VPNv4, not IPv4, using R6 as the main P router for the topology. We also
need to disable the IPv4 address-family by default. Lets configure the peerings within the HQ MPLS
Core topology first.
Version 5.1A
114 | P a g e

R6
R6(config-router)# bgp log-neighbor-changes
R6(config-router)# no bgp default ipv4-unicast
R6(config-router)#neighbor 172.16.1.1 ebgp-multihop 255
R6(config-router)#neighbor 172.16.1.1 update-source Loopback0
R6(config-router)#address-family vpnv4
R6(config-router-af)#neighbor 172.16.1.1 activate
R6(config-router-af)#neighbor 172.16.1.1 send-community extended
115|P a g e
Version 5.1A

Wow, that is a lot of config for 1 device. How could we have made that more efficient? With the use
of peer-groups. However, the task specifically states that we cannot use peer-groups. Bummer.
R1, R2, R3, R5, R7, and R9

(config)#router bgp 6510x (x is the Router Number)
(config-router)# bgp log-neighbor-changes
(config-router)# no bgp default ipv4-unicast
(config-router)# neighbor 172.16.6.6 remote-as 65106
(config-router)# neighbor 172.16.6.6 ebgp-multihop 255
(config-router)# neighbor 172.16.6.6 update-source Loopback0
(config-router)# address-family vpnv4

(config-router-af)#
(config-router-af)#
Verification
We will verify connectivity under the MPLS task later in the lab.
Task 2.5: BGP Dallas, TX
Peer BGP AS 65111 with AS 222.

o
(1 point)
Use the directly connected serial interface to accomplish this.
Mutually redistribute EIGRP 112 and BGP 65111 on R11.
Solution
Create the peering as described in the task. Use the directly connected links and not the loopbacks.
Remember that R11 should learn a default route from ISP2.
R11
Now, lets perform mutual redistribution between EIGRP 112 and BGP 65111.
Version 5.1A
116 | P a g e

R11
R11(config-router)#redistribute eigrp 112

R11(config-router)#redistribute bgp 65111 metric 100 10 1 1 1
Verification
Since there are not any routes advertised into BGP yet, we will verify this task in a later section.
Task 2.6: BGP Seattle HQ
Use the directly connected serial interfaces to accomplish this task.
Mutually redistribute OSPF 0 and BGP 65154 on R18.
(2 points)
Solution
Configure the peerings as outlined in the task. We will perform redistribution next.
R18
R20
R20(config-router)#neigh 6.6.20.1 remote-as 666
Time to perform redistribution:
117|P a g e
Version 5.1A

R18
R18(config-router)# redistribute bgp 65154 subnets

R18(config-router)#redis ospf 1
Verification
Lets make sure we are learning routes from BGP on R18. We should not be learning any routes on
VRF TELE yet.
R18
R18#sh ip route bgp
Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
o - ODR, P - periodic downloaded static route, H - NHRP, l - LISP
a - application route
+ - replicated route, % - next hop override
Gateway of last resort is not set

B
1.1.3.0 [20/0] via 3.3.18.1, 00:01:53

2.2.2.0 [20/0] via 3.3.18.1, 00:01:53
2.2.11.0 [20/0] via 3.3.18.1, 00:01:53

12.12.12.0 [20/0] via 3.3.18.1, 00:01:53

13.13.13.0 [20/0] via 3.3.18.1, 00:01:53

32.32.32.0 [20/0] via 3.3.18.1, 00:01:53

Version 5.1A
118 | P a g e

B
172.16.10.0/24 [20/0] via 3.3.18.1, 00:01:53
172.16.11.0/24 [20/0] via 3.3.18.1, 00:01:53
172.16.12.0/24 [20/0] via 3.3.18.1, 00:01:53
172.16.13.0/24 [20/0] via 3.3.18.1, 00:01:53
172.16.14.0/24 [20/0] via 3.3.18.1, 00:01:53
172.16.101.0/24 [20/0] via 3.3.18.1, 00:01:53
172.16.202.0/24 [20/0] via 3.3.18.1, 00:01:53
172.16.203.0/24 [20/0] via 3.3.18.1, 00:01:53

192.168.11.0 [20/0] via 3.3.18.1, 00:01:53
192.168.11.4 [20/0] via 3.3.18.1, 00:01:53
192.168.11.8 [20/0] via 3.3.18.1, 00:01:53
192.168.11.12 [20/0] via 3.3.18.1, 00:01:53
192.168.11.16 [20/0] via 3.3.18.1, 00:01:53
Task 2.7: BGP TeleWorkers and Distro-Center
(3 points)
Peer BGP AS 65121, 65122, and 65123 with AS 444.

o
R21, R22, and R23 should learn their addressing via PPP from the provider.
Peer BGP AS 65124 and 65125 with AS 666.
Use the directly connected serial interfaces to accomplish this task.
Solution
First thing to notice is that R21, R22, and R23 should learn their IP addresses via PPP. Lets configure
that first.
R21, R22, and R23

(config)#int s2/0
(config-if)#encapsulation ppp
(config-if)#ip address negotiated
Now that we have communication to the provider from the TeleWorker Routers, lets peer them via
BGP.
119|P a g e
Version 5.1A

R21
R22
R23
R23(config-if)#router bgp 65123
Create the BGP peerings for the Distro-Center routers.
R24
R25
Verification
We will perform our verification at the end of the MPLS VPN task.
Task 2.8: IPv6
(4 points)
Assign the following IPv6 address according to the IPv6 diagram:
Version 5.1A
120 | P a g e

Table 2.8
Device
R16
R17
R18
R19
R20
Interface
IPv6 Address
E0/0
E0/1
E0/0
E0/1
E0/0
E0/1
E0/0.169
E0/0.189
E0/1.209
E0/1.179
E0/0
E0/1
2003:169::16/64
2003:168::16/64
2003:172::17/64
2003:179::17/64
2003:189::18/64
2003:168::18/64
2003:169::19/64
2003:189::19/64
2003:209::19/64
2003:179::19/64
2003:172::20/64
2003:209::20/64
Configure OSPFv3 area 0 and advertise the networks specified in the IPv6 diagram.
Configure EIGRP AS 616 and advertise the networks specified in the IPv6 diagram.
Perform mutual redistribution on R19 between OSPF and EIGRP.
Verify full connectivity to all devices in the IPv6 network.
Solution
The first part of this task is to assign the IPv6 addressing to the interfaces according to the table
provided.
R16
R16(config-if)#ipv6 address 2003:169::16/64
R16(config-if)#int e0/1
R17
121|P a g e
Version 5.1A

R18
R19
R19(config)#int e0/0.169
R19(config-subif)#ipv6 address 2003:169::19/64
R20
Configure OSPFv3 Area 0. Remember to enable IPv6 routing!
R16
R16(config)#ipv6 unicast-routing
R16(config-if)# ipv6 ospf 1 area 0
R18
Version 5.1A
122 | P a g e

R19
R19(config-subif)# ipv6 ospf 1 area 0
R19(config-subif)# ipv6 ospf 1 area 0
Now we will configure EIGRP in AS616.
R17
R17(config)#ipv6 router eigrp 616
R17(config-rtr)#exit
R17(config-if)#ipv6 eigrp 616
R19
R19(config-if)#int e0/1.209
R19(config-subif)#ipv6 eigrp 616
R19(config-subif)#int e0/1.179
R19(config-subif)#ipv6 eigrp 616
R20
123|P a g e
Version 5.1A

Now lets perform mutual redistribution on R19.
R19
R19(config)#ipv6 router ospf 1
R19(config-router-af)#redistribute eigrp 616 include-connected

R19(config-rtr)#redistribute ospf 1 include-connected metric 100 10 1 1 1
Verification
At this point, we should have full reachability between all IPv6 addresses. Use a TCL script to verify.
All IPv6 Devices

#tclsh
+>2003:172::20
+>2003:209::20
+>2003:169::19
+>2003:189::19
+>2003:209::19
+>2003:179::19
+>2003:189::18
+>2003:168::18
+>2003:172::17
+>2003:179::17
+>2003:169::16
+>2003:168::16
Version 5.1A
124 | P a g e

Task 2.9: Multicast
(3 points)
Configure PIM Dense Mode on the following links:

Device
Interface
R11
E0/1
R12
E0/0.102
E0/1
Join the E0/0.102 interface of R12 to the PIM dense multicast group of 224.1.1.10.
Ping the multicast group from R11, and ensure that R11 receives a reply from R12 on multicast
group 224.1.1.10.
Solution
Configure the interfaces listed in the table for dense-mode and join R12s E0/0.102 interface to the
IGMP group of 224.1.1.10.
R11
R12
R12(config)#ip multicast-routing
R12(config-subif)#ip pim dense-mode
R12(config-subif)#ip igmp join-group 224.1.1.10
Verification
R11
R11#ping 224.1.1.10
125|P a g e
Version 5.1A

Section 3.0: IPv4 VPN

Task 3.1: MPLS VPN
All ISPs have agreed to pass MPLS VPN information throughout their networks.
Configure each MPLS P and PE router with the following VRFs:

o
VRF CORE: rd 111:111
VRF TELE: rd 222:222
(15 points)
(6 points)
Configure MPLS on each required interface in the HQ MPLS Core
Make the following BGP IPv4 peerings in the HQ MPLS Core using the directly connected serial
interfaces:
o
AS 65102 -> AS 222
AS 65103 -> AS 111
R2-S3/3 should be placed in the CORE VRF.
R3-S2/2 should be placed in the TELE VRF.
AS 65105 -> AS444
R5-S2/0 should be placed in the CORE VRF
The PE ISP routers have already been configured with the correct VRFs.
The TeleWorker offices belong in VRF TELE.

o
The serial interfaces of the TeleWorker offices need connectivity to the S2/2 interface of
R20 at the Seattle HQ offices.
Solution
The first step to this task is to configure the VRFs.
Version 5.1A
126 | P a g e

On All Devices in HQ MPLS Core

(config)#ip vrf CORE
(config-vrf)# rd 111:111
(config-vrf)# route-target export 111:111
(config-vrf)# route-target import 111:111
(config-vrf)#ip vrf TELE

(config-vrf)# rd 222:222
(config-vrf)# route-target export 222:222
(config-vrf)# route-target import 222:222
On All MPLS Interfaces

(config-if)#mpls ip
Now lets configure the provider interfaces for the correct VRFs. Remember that when you add an
interface to a VRF, you lose your IP address configuration.
R2
R2(config)#interface s3/3
R2(config-if)#ip vrf forwarding CORE
R3
R3(config)#int s2/2
R3(config-if)#ip vrf forwarding TELE
R5
R5(config)#int s2/0
R5(config-if)#ip vrf forwarding CORE
Configure BGP for the VRF on the provider connected links. R3 will be the exit point for VRF TELE,
and R2/R5 will be the exit point for VRF CORE.
127|P a g e
Version 5.1A

R2
R2(config-router)#address-family ipv4 vrf CORE
R2(config-router-af)#neighbor 2.2.2.1 remote-as 222
R3
R3(config-router)#address-family ipv4 vrf TELE
R3(config-router-af)#neigh 1.1.3.1 remote-as 111
R3(config-router-af)#neigh 1.1.3.1 send-community extended
R5
R5(config-router)#address-family ipv4 vrf CORE
R5(config-router-af)#neigh 4.4.5.1 remote-as 444
R5(config-router-af)#neigh 4.4.5.1 send-community extended
Verification
Check the peerings. Then we need to verify that the TeleWorker offices have connectivity to the serial
interface of R20 and do not have access to any thing else. Note that the output below is truncated
and only shown for R23 make sure that R21 and R22 can also ping 6.6.20.20.
R5
R5#sh bgp vpnv4 un all sum
BGP router identifier 172.16.5.5, local AS number 65105
BGP table version is 428, main routing table version 428
36 network entries using 5472 bytes of memory
36 path entries using 2880 bytes of memory
8/6 BGP path/bestpath attribute entries using 1216 bytes of memory
6 BGP AS-PATH entries using 176 bytes of memory
2 BGP extended community entries using 48 bytes of memory
0 BGP route-map cache entries using 0 bytes of memory
0 BGP filter-list cache entries using 0 bytes of memory
BGP using 9792 total bytes of memory
BGP activity 153/117 prefixes, 153/117 paths, scan interval 60 secs
Version 5.1A
128 | P a g e

Neighbor
AS MsgRcvd MsgSent
TblVer
InQ OutQ Up/Down
State/PfxRcd
4.4.5.1
444
15
19
428
0 00:09:05
172.16.6.6
65106
262
232
428
0 03:22:01
33
R23
#sh ip route bgp
B
4.4.5.0/24 [20/0] via 4.4.23.1, 00:08:24
4.4.21.0/24 [20/0] via 4.4.23.1, 00:08:24
4.4.21.21/32 [20/0] via 4.4.23.1, 00:08:24
4.4.22.0/24 [20/0] via 4.4.23.1, 00:08:24
4.4.22.22/32 [20/0] via 4.4.23.1, 00:08:24
4.4.23.0/24 [20/0] via 4.4.23.1, 00:08:24

6.6.20.0 [20/0] via 4.4.23.1, 00:00:11

#ping 6.6.20.20
!!!!!
Next, we need to make sure that Dallas can talk to Seattle. The output below is from R14, but you
need to verify from all devices.
R14
R14#sh ip route eigrp | i EX
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area

D EX
1.1.3.0 [170/25628160] via 192.168.11.13, 00:13:07, Ethernet0/0
D EX
2.2.2.0 [170/25628160] via 192.168.11.13, 00:13:38, Ethernet0/0
D EX
3.3.18.0 [170/25628160] via 192.168.11.13, 00:13:38, Ethernet0/0
D EX
4.4.5.0/24 [170/25628160] via 192.168.11.13, 00:05:18, Ethernet0/0
D EX
4.4.21.0/24 [170/25628160] via 192.168.11.13, 00:05:18, Ethernet0/0
D EX
4.4.21.21/32 [170/25628160] via 192.168.11.13, 00:05:18, Ethernet0/0
D EX
4.4.22.0/24 [170/25628160] via 192.168.11.13, 00:05:18, Ethernet0/0
D EX
4.4.22.22/32 [170/25628160] via 192.168.11.13, 00:05:18, Ethernet0/0
D EX
4.4.23.0/24 [170/25628160] via 192.168.11.13, 00:05:18, Ethernet0/0
129|P a g e
Version 5.1A

D EX
4.4.23.23/32 [170/25628160] via 192.168.11.13, 00:05:18, Ethernet0/0
D EX
6.6.20.0 [170/25628160] via 192.168.11.13, 00:05:18, Ethernet0/0
D EX
6.6.24.0 [170/25628160] via 192.168.11.13, 00:05:18, Ethernet0/0
D EX
6.6.25.0 [170/25628160] via 192.168.11.13, 00:05:18, Ethernet0/0
D EX
12.12.12.0 [170/25628160] via 192.168.11.13, 00:13:38, Ethernet0/0
D EX
13.13.13.0 [170/25628160] via 192.168.11.13, 00:13:38, Ethernet0/0
D EX
32.32.32.0 [170/25628160] via 192.168.11.13, 00:13:38, Ethernet0/0
D EX
74.74.74.0 [170/25628160] via 192.168.11.13, 00:05:18, Ethernet0/0
D EX
76.76.76.0 [170/25628160] via 192.168.11.13, 00:05:18, Ethernet0/0
D EX
172.16.16.0/24
D EX
172.16.17.0/24
D EX
172.16.18.0/24
D EX
172.16.19.0/24
D EX
172.16.20.0/24
D EX
172.16.201.0/24
D EX
172.16.202.0/24
D EX
172.16.203.0/24
D EX
172.16.204.0/24
D EX
172.16.206.0/24
D EX
172.16.207.0/24
D EX
192.168.54.0 [170/25628160] via 192.168.11.13, 00:13:38, Ethernet0/0
D EX
192.168.54.4 [170/25628160] via 192.168.11.13, 00:13:38, Ethernet0/0
D EX
192.168.54.8 [170/25628160] via 192.168.11.13, 00:13:38, Ethernet0/0
D EX
192.168.54.12 [170/25628160] via 192.168.11.13, 00:13:38, Ethernet0/0
D EX
192.168.54.16 [170/25628160] via 192.168.11.13, 00:13:38, Ethernet0/0
D EX
192.168.54.20 [170/25628160] via 192.168.11.13, 00:13:38, Ethernet0/0
R14#ping 192.168.54.10
!!!!!
Version 5.1A
130 | P a g e

Task 3.2: DMVPN
R20 should function as a DMVPN hub for the TeleWorker sites.
Use the following Tunnel Interfaces:

o
R20 Interface Tunnel 20
(4 points)
Use the IPv4 VPN diagram to assign addressing to the tunnel interfaces.
Use Interface Serial 2/0 on R21, R22, and R23 as the source interface.
Use interface Serial 2/2 on R20 as the source interface.
The Teleworker sites should have full reachability to all devices in Seattle HQ and Dallas when
sourced from the Loopback XX (router number) interfaces.
o
This connectivity should be obtained via OSPF area 1.
Also advertise Loopback XX (router number) on each of the TeleWorker devices into OSPF area 1.
Solution
Lets start with the hub.
R20
R20(config)#interface Tunnel20
R20(config-if)# ip address 10.10.20.1 255.255.255.0
R20(config-if)# no ip redirects
R20(config-if)# ip nhrp map multicast dynamic
R20(config-if)# ip nhrp network-id 20
R20(config-if)# ip ospf network point-to-multipoint
R20(config-if)# tunnel source Serial2/2
R20(config-if)# tunnel mode gre multipoint
Configure the Spokes.

131|P a g e
Version 5.1A

R21
R21(config-if)# ip nhrp map multicast 6.6.20.20
R21(config-if)# ip nhrp map 10.10.20.1 6.6.20.20
R21(config-if)# ip nhrp nhs 10.10.20.1
R22
R23
Version 5.1A
132 | P a g e

Last, we need to configure OSPF on the tunnel interfaces so that the TeleWorker loopbacks have full
reachability to the rest of the network.
On R20, R21, R22, and R23

(config)#router ospf 1
Verification
From R21, R22, and R23, ping to all devices in Seattle HQ and Dallas using the following TCL Script.
R20#sh dmvpn
Legend: Attrb --> S - Static, D - Dynamic, I - Incomplete
N - NATed, L - Local, X - No Socket
# Ent --> Number of NHRP entries with same NBMA peer
NHS Status: E --> Expecting Replies, R --> Responding, W --> Waiting
UpDn Time --> Up or Down Time for a Tunnel
==========================================================================
Interface: Tunnel20, IPv4 NHRP Details

Type:Hub, NHRP Peers:3,
# Ent
Peer NBMA Addr Peer Tunnel Add State
UpDn Tm Attrb
----- --------------- --------------- ----- -------- ----1 4.4.21.21
10.10.20.21
UP 00:01:45
1 4.4.22.22
10.10.20.22
UP 00:01:28
1 4.4.23.23
10.10.20.23
UP 00:01:18
133|P a g e
Version 5.1A

R21, R22, and R23

R21#tclsh
R21(tcl)#foreach address {
+>192.168.11.17
+>192.168.11.18
+>192.168.11.1
+>192.168.11.2
+>192.168.11.13
+>192.168.11.14
+>192.168.11.5
+>192.168.11.6
+>192.168.11.9
+>192.168.11.10
+>172.16.10.10
+>172.16.11.11
+>172.16.12.12
+>172.16.13.13
+>172.16.14.14
+>192.168.54.1
+>192.168.54.2
+>192.168.54.9
+>192.168.54.10
+>192.168.54.13
+>192.168.54.14
+>192.168.54.17
+>192.168.54.18
+>192.168.54.21
+>192.168.54.22
+>192.168.54.5
+>192.168.54.6
+>172.16.16.16
+>172.16.17.17
+>172.16.18.18
+>172.16.19.19
+>172.16.20.20
Version 5.1A
134 | P a g e

Task 3.3: DMVPN Encryption
(2 points)
Encrypt the DMVPN network between Seattle HQ and the TeleWorker offices using the following
parameters:
o
Transform set name: IPXTransform
Transform set: esp-aes esp-sha-hmac
Crypto IPSEC profile name: IPXIpsecProfile
Pre-shared key: ipxpertPSK!
Solution
Configure the crypto policy using the parameters specified in the task.
On R20, R21, R22, R23

(config)#crypto isakmp policy 10
(config-isakmp)# authentication pre-share
(config-isakmp)#crypto isakmp key ipxpertPSK! address 0.0.0.0
(config)#crypto ipsec transform-set IPXTransform esp-aes esp-sha-hmac
(cfg-crypto-trans)# mode transport
(cfg-crypto-trans)#crypto ipsec profile IPXIpsecProfile
(ipsec-profile)# set transform-set IPXTransform
(config)#int tunnel XX (XX is the router number)

(config-if)#tunnel protection ipsec profile IPXIpsecProfile
(config-if)#shut
(config-if)#no shut
Verification
First, we will look at the DMVPN peers and the crypto connections to verify encryption is working.
Then, we will run the TCL script again to verify we still have full reachability.
135|P a g e
Version 5.1A

R20
R20#show dmvpn
Legend: Attrb --> S - Static, D - Dynamic, I - Incomplete
N - NATed, L - Local, X - No Socket
# Ent --> Number of NHRP entries with same NBMA peer
NHS Status: E --> Expecting Replies, R --> Responding, W --> Waiting
UpDn Time --> Up or Down Time for a Tunnel
==========================================================================
Interface: Tunnel20, IPv4 NHRP Details

Type:Hub, NHRP Peers:3,
# Ent
Peer NBMA Addr Peer Tunnel Add State
UpDn Tm Attrb
----- --------------- --------------- ----- -------- ----1 4.4.21.21
10.10.20.21
UP 00:00:41
1 4.4.22.22
10.10.20.22
UP 00:00:40
1 4.4.23.23
10.10.20.23
UP 00:00:40
R20#sho crypto isakmp sa

IPv4 Crypto ISAKMP SA
dst
src
state
6.6.20.20
4.4.21.21
QM_IDLE
1009 ACTIVE
6.6.20.20
4.4.22.22
QM_IDLE
1010 ACTIVE
6.6.20.20
4.4.23.23
QM_IDLE
1011 ACTIVE
Version 5.1A
conn-id status
136 | P a g e

R21, R22, and R23

R21#tclsh
R21(tcl)#foreach address {
+>192.168.11.17
+>192.168.11.18
+>192.168.11.1
+>192.168.11.2
+>192.168.11.13
+>192.168.11.14
+>192.168.11.5
+>192.168.11.6
+>192.168.11.9
+>192.168.11.10
+>172.16.10.10
+>172.16.11.11
+>172.16.12.12
+>172.16.13.13
+>172.16.14.14
+>192.168.54.1
+>192.168.54.2
+>192.168.54.9
+>192.168.54.10
+>192.168.54.13
+>192.168.54.14
+>192.168.54.17
+>192.168.54.18
+>192.168.54.21
+>192.168.54.22
+>192.168.54.5
+>192.168.54.6
+>172.16.16.16
+>172.16.17.17
+>172.16.18.18
+>172.16.19.19
+>172.16.20.20
137|P a g e
Version 5.1A

Task 3.4: Virtual Tunnel Interfaces
(3 points)
The Distro-Center needs to connect directly with the Dallas, TX offices. Create 2 separate Static
Virtual Tunnel interfaces on R11 for this connectivity.
The Distro-Center Routers should be setup with Static Virtual Tunnel interfaces to connect back
to Dallas.
All tunnel interfaces should not be configured with an IP address and should use the IP address of
the serial interfaces as the IP of the tunnel interface.
The connected serial interfaces should also be used as the source of each tunnel interface.
Use the following IPSEC parameters to form the tunnels:
Pre-shared key: IPXpsk!
Encryption: 3des
Transform-Set name: IPX123TFS
Transform-Set: esp-3des esp-sha-hmac
IPSEC Profile: IPExpertProfile1
Peer R24 and R25 via EIGRP with R11 and advertise the Loopback24 and Loopback25 interfaces
into EIGRP. The routes should be in the EIGRP topology table, but the BGP routes should be
installed in the routing tables of R24 and R25.
Solution
First, create the ISAKMP policy and the IPSec profile using the paremeters outlined in the task.
R11, R24, R25

(config)#crypto isakmp policy 1
(config-isakmp)# encr 3des
(config-isakmp)# authentication pre-share
(config-isakmp)# group 2
(config)#crypto isakmp key IPXpsk! address 0.0.0.0
(config)#crypto ipsec transform-set IPX123TFS esp-3des esp-sha-hmac
Version 5.1A
138 | P a g e

(cfg-crypto-trans)# mode tunnel
(config)#crypto ipsec profile IPExpertProfile1

(ipsec-profile)# set transform-set IPX123TFS
Now lets create the static tunnels on R11 since it is acting as a multi-termination point. We need to
use the serial interfaces of all 3 routers as the source and destination for the tunnels.
R11
R11(config-if)# ip unnumbered Serial2/3
R11(config-if)# tunnel mode ipsec ipv4
R11(config-if)# tunnel destination 6.6.24.24
R11(config-if)# tunnel protection ipsec profile IPExpertProfile1
R11(config-if)#interface Tunnel25
R11(config-if)# ip unnumbered Serial2/3
R11(config-if)# tunnel mode ipsec ipv4
R11(config-if)# tunnel destination 6.6.25.25
R11(config-if)# tunnel protection ipsec profile IPExpertProfile1
Build the tunnel interface on R24 and R25 the same way.
R24 and R25

(config)# interface Tunnel11
(config-if)# ip unnumbered Serial2/0
(config-if)# tunnel source Serial2/0
(config-if)# tunnel mode ipsec ipv4
(config-if)# tunnel destination 2.2.11.11
(config-if)# tunnel protection ipsec profile IPExpertProfile1
The last part of this task asks us to add R24 and R25 into EIGRP and advertise their loopbacks. One
big thing to remember here is that in the earlier EIGRP task, it calls for AS112 to use the passiveinterface default command. Do not forget this as you are configuring your EIGRP processes or you
will not get points for the previous EIGRP section.
139|P a g e
Version 5.1A

R11
R11(config-router)# network 2.2.11.11 0.0.0.0
R11(config-router)#no passive-interface tunnel 24
R11(config-router)#no passive-interface tunnel 25
R24
R24(config-router)# passive-interface default
R24(config-router)# no passive-interface tunnel 11
R25(config-router)# no passive-interface loop 24
R25
R25(config-router)# passive-interface default
R25(config-router)# no passive-interface tunnel 11
R25(config-router)# no passive-interface loop 25
Verification
There are a few verifications that we need to do. First, verify that the tunnels are up. Second, verify
that the EIGRP adjacencies are formed. Lastly, verify that the routes are showing up in the EIGRP
topology table, but not the routing table.
R11
R11#sh crypto isakmp sa
IPv4 Crypto ISAKMP SA
dst
src
state
conn-id status
6.6.25.25
2.2.11.11
QM_IDLE
1005 ACTIVE
6.6.24.24
2.2.11.11
QM_IDLE
1006 ACTIVE
R11#show ip eigrp nei

Version 5.1A
140 | P a g e

H
Address
Interface
Hold Uptime
SRTT
(sec)
(ms)
RTO
Seq
Cnt Num
6.6.25.25
Tu25
12 00:02:19
577
3462
18
6.6.24.24
Tu24
14 00:02:20
70
1440
27
192.168.11.14
Et0/0
11 02:55:51
100
64
192.168.11.1
Et0/1
12 02:56:34
100
92
R24
R24#sh ip route
Gateway of last resort is not set

B
2.2.2.0 [20/0] via 6.6.24.1, 00:16:34
2.2.11.0 [20/0] via 6.6.24.1, 00:16:34

4.4.5.0 [20/0] via 6.6.24.1, 00:16:34

6.6.25.0/24 [20/0] via 6.6.24.1, 00:16:34

10.10.20.1/32 [20/0] via 6.6.24.1, 00:16:34
10.10.20.21/32 [20/0] via 6.6.24.1, 00:16:34
10.10.20.22/32 [20/0] via 6.6.24.1, 00:16:34
10.10.20.23/32 [20/0] via 6.6.24.1, 00:16:34
10.10.24.0/24 is directly connected, Loopback24
10.10.25.0/24 [20/0] via 6.6.24.1, 00:14:53

172.16.10.0/24 [20/0] via 6.6.24.1, 00:15:24
172.16.11.0/24 [20/0] via 6.6.24.1, 00:15:24
172.16.12.0/24 [20/0] via 6.6.24.1, 00:15:24
172.16.13.0/24 [20/0] via 6.6.24.1, 00:15:24
172.16.14.0/24 [20/0] via 6.6.24.1, 00:15:24
172.16.16.0/24 [20/0] via 6.6.24.1, 00:16:34
172.16.17.0/24 [20/0] via 6.6.24.1, 00:16:34
172.16.18.0/24 [20/0] via 6.6.24.1, 00:16:34
172.16.19.0/24 [20/0] via 6.6.24.1, 00:16:34
141|P a g e
Version 5.1A

B
172.16.20.0/24 [20/0] via 6.6.24.1, 00:16:34

192.168.11.0 [20/0] via 6.6.24.1, 00:15:24
192.168.11.4 [20/0] via 6.6.24.1, 00:15:24
192.168.11.8 [20/0] via 6.6.24.1, 00:15:24
192.168.11.12 [20/0] via 6.6.24.1, 00:15:24
192.168.11.16 [20/0] via 6.6.24.1, 00:15:24

192.168.54.0 [20/0] via 6.6.24.1, 00:16:34
192.168.54.4 [20/0] via 6.6.24.1, 00:16:34
192.168.54.8 [20/0] via 6.6.24.1, 00:16:34
192.168.54.12 [20/0] via 6.6.24.1, 00:16:34
192.168.54.16 [20/0] via 6.6.24.1, 00:16:34
192.168.54.20 [20/0] via 6.6.24.1, 00:16:3
R24#sh ip eigrp topology

P 172.16.18.0/24, 0 successors, FD is Infinity, tag is 222
via 2.2.11.11 (26882560/25602560), Tunnel11
P 192.168.11.8/30, 0 successors, FD is Infinity
via 2.2.11.11 (26931200/307200), Tunnel11
via 2.2.11.11 (26882560/25602560), Tunnel11
P 6.6.24.0/24, 1 successors, FD is 2169856
via Connected, Serial2/0
via 2.2.11.11 (26882560/25602560), Tunnel11
via 2.2.11.11 (26882560/25602560), Tunnel11
via 2.2.11.11 (27059200/435200), Tunnel11
via 2.2.11.11 (26882560/25602560), Tunnel11
via 2.2.11.11 (26931200/307200), Tunnel11
via 2.2.11.11 (26882560/25602560), Tunnel11
Version 5.1A
142 | P a g e

via 2.2.11.11 (27059200/435200), Tunnel11
via 2.2.11.11 (26882560/25602560), Tunnel11
via 2.2.11.11 (26905600/281600), Tunnel11
via 2.2.11.11 (26882560/25602560), Tunnel11
via 2.2.11.11 (27033600/409600), Tunnel11
via 2.2.11.11 (27392000/2169856), Tunnel11
via 2.2.11.11 (26882560/25602560), Tunnel11
via 2.2.11.11 (26882560/25602560), Tunnel11
via 2.2.11.11 (26882560/25602560), Tunnel11
via 2.2.11.11 (28288000/27008000), Tunnel11
via 2.2.11.11 (26931200/307200), Tunnel11
P 10.10.24.0/24, 1 successors, FD is 128256
via Connected, Loopback24
via 2.2.11.11 (27033600/409600), Tunnel11
via 2.2.11.11 (26882560/25602560), Tunnel11
via 2.2.11.11 (26882560/25602560), Tunnel11
via 2.2.11.11 (26882560/25602560), Tunnel11
via 2.2.11.11 (27008000/128256), Tunnel11
via 2.2.11.11 (26882560/25602560), Tunnel11
via 2.2.11.11 (26882560/25602560), Tunnel11
via 2.2.11.11 (26882560/25602560), Tunnel11
143|P a g e
Version 5.1A

via 2.2.11.11 (26905600/281600), Tunnel11
via 2.2.11.11 (26882560/25602560), Tunnel11
Version 5.1A
144 | P a g e

Section 4.0: Infrastructure Security

Task 4.1: Time Based Access-List
(5 Points)
(3 points)
Configure R3 so that telnet is allowed to the device only from the 192.168.1.0/24 network during
the non-business hours of 5:00pm-8:00am, Monday-Friday. Also allow access over the weekend.
Solution
Configure the time-based ACL as outlined in the task so that telnet is only allowed on R3 during nonbusiness hours. We need to first configure the time-range.
R3
R3(config)#time-range WORK-WEEK
R3(config-time-range)# periodic weekdays 17:00 to 23:59
R3(config-time-range)# periodic weekdays 00:00 to 7:59
R3(config-time-range)# periodic weekend 0:00 to 23:59
Then, we need to configure the Access-list and apply it to the vty lines.
R3
R3(config)#access-list 101 permit tcp 192.168.1.0 0.0.0.255 any eq telnet time-range
WORK-WEEK
R3(config)#line vty 0 4
R3(config-line)# access-class 101 in
R3(config-line)# login
R3(config-line)# password cisco
R3(config-line)# transport input telnet
Verification
From R2, attempt to telnet to R3. This could be successful if you are within the time frame-specified.
The input below shows it being denied since the ACL is not active.
145|P a g e
Version 5.1A

R2
R2#telnet 192.168.1.254
Trying 192.168.1.254 ...
% Connection refused by remote host
R3 should show the ACL as unactive or active depending on what time it is.
R3
R3#show access-list 101
Extended IP access list 101
10 permit tcp 192.168.1.0 0.0.0.255 any eq telnet time-range WORK-WEEK (inactive)
Task 4.2: Device Hardening
(2 points)
All passwords should be encrypted as level 7 by default on all devices in the HQ MPLS Core
network.
o
Use only one command on each device to accomplish this task.
HTTP should be disabled and HTTPS should use port 8080 on all devices in the HQ MPLS Core
network.
No devices in the HQ MPLS Core network should show any MPLS VPN hop when originating a
traceroute from either VRF CORE or VRF TELE.
Solution
Since all parts of this task relate to the HQ MPLS Core network, lets configure them at the same time.
First, we need to enable service-password encryption. Then, we need to disable HTTP and change
the HTTPS port to 8080. Last, we need to disable MPLS ttls so that the MPLS hops do not show up in
a traceroute.
On ALL Devices in HQ MPLS Core Network

(config)#service password-encryption
(config)#no ip http server
(config)#ip http secure-server
(config)#ip http secure-port 8080
Version 5.1A
146 | P a g e

(config)#no mpls ip propagate-ttl
Verification
To test the password encryption, we can look at the line VTY password of R3 and verify that it is
encrypted.
R3
R3#sh run | sec line
line vty 0 4
access-class 101 in
password 7 121A0C041104
login
transport input telnet
R3#sh ip http server status | in status

HTTP server status: Disabled
HTTP secure server status: Enabled
R3#sh ip http server secure status

HTTP secure server status: Enabled
HTTP secure server port: 8080
HTTP secure server ciphersuite: 3des-ede-cbc-sha des-cbc-sha rc4-128-md5 rc4-128-sha
HTTP secure server client authentication: Disabled
HTTP secure server trustpoint:
HTTP secure server active session modules: ALL
147|P a g e
Version 5.1A

Section 5.0: Infrastructure Services

Task 5.1: Config Backups
(5 Points)
(3 points)
Configure R6 to send a copy of its running configuration to an FTP server located at 10.10.1.1
every 5 minutes.
Use Loopback0 as the source of this communication.
The FTP server has the username IPExpert and the password IPXPass for FTP.
Do not use FTP passive mode.
The configuration file should be saved on 10.10.1.1 under the directory IPX with the filename
R6.txt and include version numbers.
Solution
We need to first setup the ftp username/password and hard-code an interface for FTP sessions:
R6
R6(config)#ip ftp username IPExpert
R6(config)#ip ftp password IPXPass
R6(config)#ip ftp source-interface loopback 0
Next, we need to setup configuration archiving using the parameters specified in the task. It calls for
a specific filename and for a specific directory location. Also note that we need to include revision
numbers. We need to also use FTP passive-mode which is done by setting the file prompt to quiet.
R6
R6(config)#archive
R6(config-archive)# path ftp://10.10.1.1/IPX/R6.cfg
R6(config-archive)# time-period 5
R6(config-archive)#file prompt quiet
Verification
R6 should generate a log every 5 minutes as follows:
R6
Writing IPX/R6.cfg-Nov--3-11-04-26-0
Version 5.1A
148 | P a g e

Task 5.2: Address Administration
(2 points)
Configure R9 as a DHCP server.
Assign the subnet of 192.168.1.96/30.
.98 should be the only IP that is generated. All other IPs should be reserved.
.97 should be the gateway.
8.8.8.8 is the DNS server.
Interface E0/0 on BB1 is pre-configured to use this IP pool. From R9, verify that BB1 pulled IP
address 192.168.1.98 and that R9 can ping 192.68.1.98.
BB1 should form an EIGRP neighbor adjacency with R9. BB1 should be reachable from the HQ
MPLS Core network.
Soluiton
Configure R9 as a DHCP server for BB1 using the details outlined in the task.
R9
R9(config)#ip dhcp excluded-address 192.168.1.96 192.168.1.97
R9(config)#ip dhcp pool BB1

R9(dhcp-config)# network 192.168.1.96 255.255.255.252
R9(dhcp-config)# default-router 192.168.1.97
R9(dhcp-config)# dns-server 8.8.8.8
Verification
Lets go up to R3 and ping BB1s loopback interface.
R3
R3#ping 172.16.111.111
149|P a g e
Version 5.1A

!!!!!
R9
R9#sh ip dhcp binding
Bindings from all pools not associated with VRF:
IP address
Client-ID/
Lease expiration
Type
Jul 22 2015 01:38 PM
Automatic
Hardware address/
User name
192.168.1.98
0063.6973.636f.2d61.
6162.622e.6363.3031.
2e66.3530.302d.4574.
302f.30
Technical Verification and Support

If you need assistance with any of this book's content, please visit our Member Community at
http://community.ipexpert.com.
This
Section
of iPexpert's
R&S 1-Week
Lab
Experience Volume
DSG, Lab21
Thisconcludes
concludesthe
theDiagnostic
Configuration
Section
and iPexpert's
R&S Lab
2 Workbook,
Version 5.1A
150 | P a g e

For Cisco's CCIE Routing & Switching Lab Exam, Lab 2

Caricato da

Informazioni sul documento

Titolo originale

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

For Cisco's CCIE Routing & Switching Lab Exam, Lab 2

Caricato da

Copyright:

Formati disponibili

for Cisco's CCIE Routing & Switching Lab Exam, Lab 2

CCIE Routing & Switching

iPexpert's Detailed Solution Guide

iPexpert's Detailed Soluiton Guide

iPexpert's Detailed Solution Guide

iPexpert's End-User License Agreement

iPexpert's Detailed Soluiton Guide

U.S. Government - Restricted Rights

iPexpert's Detailed Solution Guide

Welcome, and Thank You!

Technical Support and Freebies

iPexpert's Detailed Soluiton Guide

How to Use This Lab Preparation Workbook

iPexpert's Detailed Solution Guide

Cisco's New Retake Policy

Cisco R&S V5 Blueprint (Primary Sections w/ Assigned Point Values)

Layer 2 Technologies: 20%

How to Use This Lab Preparation Workbook

Additional Information Pertaining to Cisco's CCIE R&S Lab Exam

iPexpert's Detailed Soluiton Guide

iPexpert's Detailed Solution Guide

iPexpert's Detailed Soluiton Guide

Lab 2: Troubleshooting Section :: Detailed

iPexpert's Detailed Solution Guide

iPexpert's Detailed Soluiton Guide

Diagram 2.1: Layer 2

iPexpert's Detailed Solution Guide

Diagram 2.2: BGP

iPexpert's Detailed Solution Guide

iPexpert's Detailed Solution Guide

iPexpert's Detailed Soluiton Guide

Now lets test the ping again.

iPexpert's Detailed Solution Guide

iPexpert's Detailed Soluiton Guide

You may not access BB3 while troubleshooting this fault.

This incident has multiple faults.

iPexpert's Detailed Solution Guide

iPexpert's Detailed Soluiton Guide

iPexpert's Detailed Solution Guide

Et0/0: Rcv pkt from 10.10.1.254, area 0.0.0.0, mismatched area

iPexpert's Detailed Soluiton Guide

iPexpert's Detailed Solution Guide

iPexpert's Detailed Soluiton Guide

iPexpert's Detailed Solution Guide

1.0.0.0/8 is variably subnetted, 2 subnets, 2 masks

1.1.1.14/31 is directly connected, Serial2/1

1.1.1.14/32 is directly connected, Serial2/1

10.10.1.8 [20/0] via 1.1.1.15, 00:38:32

10.10.1.12 [20/0] via 1.1.1.15, 00:38:32

10.10.1.32 [20/11] via 1.1.1.15, 00:38:32

10.10.1.40 [20/11] via 1.1.1.15, 00:38:32

172.16.3.0/24 [20/0] via 1.1.1.15, 00:38:32

172.16.102.102/32 [20/12] via 1.1.1.15, 00:38:32

iPexpert's Detailed Soluiton Guide

address-family ipv4 vrf CORE

Metric LocPrf Weight Path

Route Distinguisher: 111:111 (default for vrf CORE)

0 222 777 666 2424 ?

0 777 666 2424 ?

0 222 777 666 2525 ?

0 777 666 2525 ?

0 222 777 444 2121 ?

iPexpert's Detailed Solution Guide