IPexpert's CCIE R&S (v5) Mock Lab Workbook (Vol. 2) Lab 5 DSG

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

Volume 2 Detailed Solution Guide
Lab 5
Version 5.1B
iPexpert's Detailed Solution Guide

for Cisco's CCIE Routing and Switching Lab Exam, Volume 2, Lab 5
Table of Contents
Lab 5: Troubleshooting Section :: Detailed Solutions.................................................................................................10
Detailed Solution Guide ...........................................................................................................................................10
General Rules ...........................................................................................................................................................10
Pre-Setup ..................................................................................................................................................................11
Incident 1..................................................................................................................................................................12
Incident 2..................................................................................................................................................................28
Incident 3 .................................................................................................................................................................37
Incident 4..................................................................................................................................................................45
Incident 5..................................................................................................................................................................51
Incident 6..................................................................................................................................................................57
Incident 7..................................................................................................................................................................64
Incident 8..................................................................................................................................................................70
Incident 9..................................................................................................................................................................78
Incident 10 ...............................................................................................................................................................84
Lab 5: Diagnostic Section :: Detailed Solutions .......................................................................................................... 89
Detailed Solution Guide ...........................................................................................................................................89
General Rules ...........................................................................................................................................................89
Ticket 1 .....................................................................................................................................................................90
Ticket 2 .................................................................................................................................................................. 125
Ticket 3 .................................................................................................................................................................. 132
Lab 5: Configuration Section :: Detailed Solutions ...................................................................................................140
Detailed Solution Guide ........................................................................................................................................ 140
General Rules ........................................................................................................................................................ 140
Pre-Setup ............................................................................................................................................................... 141
Section 1.0: Layer 2 Technologies........................................................................................................................ 149
Section 2.0: IP Routing ......................................................................................................................................... 177
Section 3.0: IPv4 VPN Technology ....................................................................................................................... 249
Section 4.0: IP Security ......................................................................................................................................... 267
Section 5.0: Infrastructure Services ..................................................................................................................... 272
Technical Verification and Support .............................................................................................................................275
2|Page
Version 5.1B

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
Version 5.1B
3|Page

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.
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.
4|Page
Version 5.1B

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.1B
5|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.
6|Page
Version 5.1B

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.1B
7|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.
8|Page
Version 5.1B

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.1B
9|Page

Lab 5: 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
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 routers have an interface loopback 0 with the address 10.x.x.x, where x is the router
number. ISP routers have a loopback address of 10.10x.10x.10x. BB routers have a loopback
address of 100.x.x.x .Switches have loopback addresses of 172.xx.xx.xx.
MPLS routers have a loopback address of 10.x.x.x /32.
Static/default routes are NOT allowed unless otherwise stated in the task.
Save your configurations often.
10 | P a g e
Version 5.1B

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.1B
11 | P a g e

Diagram 5.1
12 | P a g e
Version 5.1B

Diagram 5.2
Version 5.1B
13 | P a g e

Diagram 5.3
14 | P a g e
Version 5.1B

Diagram 5.4
Version 5.1B
15 | P a g e

Incident 1
(3 points)
Users from remote branch-1 have lost connectivity to the IPexpert HQ office.
The users mentioned that they can still reach the other remote branches.
Fix the issues so that remote branch-1 can reach the HQ and all the remote branches, the outputs
should match the output below:
16 | P a g e
Version 5.1B

R24
R24#sh ip route eigrp
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
10.0.0.0/8 is variably subnetted, 7 subnets, 2 masks
D EX
10.4.4.0/24 [170/542771200] via 192.168.24.6, 03:11:05, Serial2/0
10.13.13.0/24 [90/27008000] via 40.40.40.13, 00:00:16, Tunnel66
10.15.15.0/24 [90/27033600] via 40.40.40.13, 00:00:16, Tunnel66
D EX
10.23.23.0/24 [170/28288000] via 40.40.40.23, 00:00:09, Tunnel66
D EX
10.25.25.0/24 [170/28288000] via 40.40.40.25, 00:00:09, Tunnel66

172.5.0.0/24 is subnetted, 1 subnets
172.5.5.0 [90/27033600] via 40.40.40.13, 00:00:16, Tunnel66

172.16.200.0 [90/26905856] via 40.40.40.13, 00:00:16, Tunnel66
172.16.214.0 [90/26905600] via 40.40.40.13, 00:00:16, Tunnel66
172.16.215.0 [90/26905600] via 40.40.40.13, 00:00:16, Tunnel66
172.16.216.0 [90/26931200] via 40.40.40.13, 00:00:16, Tunnel66
D EX
192.168.0.0/16 [170/542771200] via 192.168.24.6, 03:11:05, Serial2/0
192.168.13.0/24 [90/34036062] via 192.168.24.6, 03:11:05, Serial2/0
192.168.15.0/24 [90/27417600] via 40.40.40.13, 00:00:16, Tunnel66
192.168.23.0/24 [90/44276062] via 192.168.24.6, 03:11:05, Serial2/0
192.168.25.0/24 [90/23796062] via 192.168.24.6, 03:11:05, Serial2/0
192.168.74.0/24 [90/34036062] via 192.168.24.6, 03:11:05, Serial2/0
192.168.76.0/24 [90/23796062] via 192.168.24.6, 03:11:05, Serial2/0
R24#traceroute 10.23.23.23
Type escape sequence to abort.
Tracing the route to 10.23.23.23
VRF info: (vrf in name/id, vrf out name/id)
1 40.40.40.23 37 msec 37 msec *
Version 5.1B
17 | P a g e

Solution
First, start out by going to R24 and looking at the routing table:
R24
R24#sh ip route
Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP
Gateway of last resort is not set

C
10.24.24.0/24 is directly connected, Loopback0

40.40.40.0/24 is directly connected, Tunnel66
40.40.40.24/32 is directly connected, Tunnel66
D EX
192.168.0.0/16 [170/542771200] via 192.168.24.6, 2w0d, Serial2/0
192.168.13.0/24 [90/34036062] via 192.168.24.6, 2w0d, Serial2/0
192.168.15.0/24 [90/34036062] via 192.168.24.6, 5d22h, Serial2/0
192.168.23.0/24 [90/44276062] via 192.168.24.6, 2w0d, Serial2/0

192.168.24.0/24 is directly connected, Serial2/0
192.168.25.0/24 [90/23796062] via 192.168.24.6, 2w0d, Serial2/0
192.168.74.0/24 [90/34036062] via 192.168.24.6, 2w0d, Serial2/0
192.168.76.0/24 [90/23796062] via 192.168.24.6, 2w0d, Serial2/0
18 | P a g e
Version 5.1B

At this point, we can see that there are no routes being learned via EIGRP pointing to the tunnel
interface. Next we will go and verify the DMVPN tunnel status:
R24
R24#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: Tunnel66, IPv4 NHRP Details

Type:Spoke, NHRP Peers:1,
# Ent
Peer NBMA Addr Peer Tunnel Add State
UpDn Tm Attrb
----- --------------- --------------- ----- -------- ----1 192.168.13.13
40.40.40.13
IKE 00:00:30
At this point, the issue in the incident has been identified and we know that it seems as we are having
an IKE issue. This would lead us to verify the ISAKMP (IKE Phase 1) status:
R24
R24#show crypto isakmp sa
IPv4 Crypto ISAKMP SA
dst
src
state
192.168.13.13
192.168.24.24
MM_NO_STATE
0 ACTIVE
192.168.13.13
192.168.24.24
MM_NO_STATE
0 ACTIVE (deleted)
Version 5.1B
conn-id status
19 | P a g e

The ISAKMP status of "MM_NO_STATE" indicates that ISAKMP SA has been created but nothing else
has happened yet, indicating we might have some sort of a connectivity issue. Let's verify basic
connectivity between R24 to the HUB router R13:
R24
R24#ping 192.168.13.13 source s2/0
Sending 5, 100-byte ICMP Echos to 192.168.13.13, timeout is 2 seconds:
Packet sent with a source address of 192.168.24.24
.....
Success rate is 0 percent (0/5)
R24#traceroute 192.168.13.13 numeric source s2/0

1 192.168.24.6 9 msec 9 msec 9 msec
2
We have successfully identified a connectivity issue, we are stopping at ISP6 router so there may be
an issue on ISP6 - we shall now go over to ISP6 and verify the configurations starting with the NAT
configurations, since the diagram indicates NAT is enabled on ISP6 router.
ISP6
ISP6#show ip nat statistics
Total active translations: 8 (2 static, 6 dynamic; 8 extended)
Peak translations: 30, occurred 00:01:27 ago
Outside interfaces:
Serial4/0
Inside interfaces:
Serial2/1
Hits: 305173
Misses: 0
CEF Translated packets: 304516, CEF Punted packets: 480

Expired translations: 59
Dynamic mappings:
-- Inside Source
[Id: 1] access-list 100 interface Serial4/0 refcount 6
20 | P a g e
Version 5.1B

ISP6#sh ip nat translations

Pro Inside global
Inside local
Outside local
Outside global
icmp 192.168.76.6:4
192.168.24.24:4
192.168.13.13:4
192.168.13.13:4
udp 192.168.76.6:500
192.168.24.24:500
192.168.13.13:500
192.168.13.13:500
udp 192.168.76.6:500
192.168.24.24:500
192.168.13.13:500
192.168.13.13:500
udp 192.168.76.6:500
192.168.24.24:500
192.168.13.13:500
192.168.13.13:500
udp 192.168.76.6:500
192.168.24.24:500
192.168.13.13:500
192.168.13.13:500
udp 192.168.76.6:500
192.168.24.24:500
192.168.13.13:500
192.168.13.13:500
udp 192.168.24.24:500
192.168.76.6:500
---
---
---
---
udp 192.168.24.24:4500 192.168.76.6:4500
We now see that there are 2 static and 6 dynamic translations, after looking at the active sessions we
can immediately notice that the last two lines indicate that we might have a wrong NAT mapping.
ISP6
ISP6#sh run | include nat|interface
interface Loopback0
interface Ethernet1/0
interface Serial2/0
interface Serial2/1
ip nat inside
interface Serial4/0
ip nat outside
ip nat inside source list 100 interface Serial4/0 overload
ip nat inside source static udp 192.168.76.6 500 192.168.24.24 500 extendable
At this point, we can clearly see the mapping is reversed, whereas 192.168.24.24 is the inside local
and 192.168.76.6 should be the inside global. Modify the NAT configuration and verify again:
Version 5.1B
21 | P a g e

ISP6
ISP6(config)#no ip nat inside source static udp 192.168.76.6 500 192.168.24.24 500
extendable
ISP6(config)#no ip nat inside source static udp 192.168.76.6 4500 192.168.24.24 4500
extendable
ISP6(config)#ip nat inside source static udp 192.168.24.24 500 192.168.76.6 500
extendable
ISP6(config)#ip nat inside source static udp 192.168.24.24 4500 192.168.76.6 4500
extendable
ISP6(config)#do sh ip nat translations
Pro Inside global
Inside local
Outside local
Outside global
udp 192.168.76.6:500
192.168.24.24:500
192.168.13.13:500
192.168.13.13:500
udp 192.168.76.6:500
192.168.24.24:500
---
---
udp 192.168.76.6:4500
192.168.24.24:4500 192.168.13.13:4500 192.168.13.13:4500
udp 192.168.76.6:4500
192.168.24.24:4500 ---
---
R24
dst
src
state
conn-id status
192.168.13.13
192.168.24.24
MM_KEY_EXCH
1017 ACTIVE
192.168.13.13
192.168.24.24
MM_NO_STATE
1016 ACTIVE (deleted)
The last output indicates we still have an issue with the ISAKMP (IKE Phase 1) and according to the
state message of "MM_KEY_EXCH", we can identify that there's an ISAKMP authentication issue. We
will go over to R24 and R13 and verify the pre-shared keys match exactly:
R24
R24#sh run | sec crypto
crypto isakmp policy 10
encr aes
authentication pre-share
group 2
crypto isakmp key &IPX address 0.0.0.0
crypto ipsec transform-set DMVPN-IPX-SET esp-aes esp-sha-hmac
mode transport
crypto ipsec profile DMVPN-IPX
set transform-set DMVPN-IPX-SET
22 | P a g e
Version 5.1B

R13
R13#sh run | sec crypto
crypto isakmp policy 10
encr aes
authentication pre-share
group 2
crypto isakmp key $IPX address 0.0.0.0
crypto ipsec transform-set DMVPN-IPX-SET esp-aes esp-sha-hmac
mode transport
crypto ipsec profile DMVPN-IPX
set transform-set DMVPN-IPX-SET
At this point, we have identified the second fault - incorrect pre-shared key configured on the remote
spoke (R24). Modify the pre-shared key and verify again:
NOTE
Always modify according to the Hub configurations, and not the other way around.
R24
R24#conf t
R24(config)#no crypto isakmp key &IPX address 0.0.0.0
R24(config)#crypto isakmp key $IPX address 0.0.0.0
R24(config)#do show dmvpn

==========================================================================

# Ent
UpDn Tm Attrb
----- --------------- --------------- ----- -------- -----
Version 5.1B
23 | P a g e

1 192.168.13.13
40.40.40.13
UP 00:00:24
R24#sh crypto isakmp sa

dst
src
state
conn-id status
192.168.13.13
192.168.24.24
QM_IDLE
1032 ACTIVE
192.168.13.13
192.168.24.24
MM_NO_STATE
1031 ACTIVE (deleted)
The state message of "QM_IDLE" indicates that the ISAKMP negotiations are complete. Phase 1
successfully completed. It remains authenticated with its peer and may be used for subsequent Quick
Mode exchanges. Now we will reverify the route table output for R24:
R24

D
10.13.13.0/24 [90/27008000] via 40.40.40.13, 00:08:15, Tunnel66
10.15.15.0/24 [90/27033600] via 40.40.40.13, 00:08:15, Tunnel66

172.5.5.0 [90/27033600] via 40.40.40.13, 00:08:15, Tunnel66

172.6.6.0 [90/27059200] via 40.40.40.13, 00:08:15, Tunnel66

172.16.56.0 [90/26905856] via 40.40.40.13, 00:08:15, Tunnel66
172.16.100.0 [90/26931456] via 40.40.40.13, 00:08:15, Tunnel66
172.16.200.0 [90/26905856] via 40.40.40.13, 00:08:15, Tunnel66
172.16.214.0 [90/26905600] via 40.40.40.13, 00:08:15, Tunnel66
172.16.215.0 [90/26905600] via 40.40.40.13, 00:08:15, Tunnel66
172.16.216.0 [90/26931200] via 40.40.40.13, 00:08:15, Tunnel66
D EX
192.168.0.0/16 [170/542771200] via 192.168.24.6, 2w0d, Serial2/0
192.168.13.0/24 [90/34036062] via 192.168.24.6, 2w0d, Serial2/0
192.168.15.0/24 [90/27417600] via 40.40.40.13, 00:08:15, Tunnel66
192.168.23.0/24 [90/44276062] via 192.168.24.6, 2w0d, Serial2/0
192.168.25.0/24 [90/23796062] via 192.168.24.6, 2w0d, Serial2/0
192.168.74.0/24 [90/34036062] via 192.168.24.6, 2w0d, Serial2/0
192.168.76.0/24 [90/23796062] via 192.168.24.6, 2w0d, Serial2/0
24 | P a g e
Version 5.1B

If we look close enough, we can see that we are still missing the remote branches routes. Remember,
we must match exactly to the given output! Go back to the Hub (R13) check for the remote branches
routes, notice the highlighted routes we are missing at the far end:
R13

D
10.15.15.0/24 [90/409600] via 172.16.214.2, 2w0d, Ethernet0/1
D EX
10.23.23.0/24 [170/27008000] via 40.40.40.23, 6d01h, Tunnel66
D EX
10.24.24.0/24 [170/27008000] via 40.40.40.24, 00:17:20, Tunnel66
D EX
10.25.25.0/24 [170/27008000] via 40.40.40.25, 6d01h, Tunnel66
R13#show run interface tun66

Building configuration...
Current configuration : 355 bytes
!
interface Tunnel66
ip address 40.40.40.13 255.255.255.0
no ip redirects
ip mtu 1400
no ip next-hop-self eigrp 300
ip nhrp authentication IPX-CCIE
ip nhrp map multicast dynamic
ip nhrp network-id 54321
ip tcp adjust-mss 1360
tunnel source Serial5/0
tunnel mode gre multipoint
tunnel key 1234567
tunnel protection ipsec profile DMVPN-IPX
!
Version 5.1B
25 | P a g e

Take a closer look at the tunnel interface, recall that we have a point-to-multipoint tunnel interface
and for EIGRP the split-horizon is turned on by default. Modify the EIGRP configuration and check the
output on R24 again:
R13
R13(config)#interface tunnel66
R13(config-if)#no ip split-horizon eigrp 300
R24
R24#show ip route eigrp

D
10.13.13.0/24 [90/27008000] via 40.40.40.13, 00:22:25, Tunnel66
10.15.15.0/24 [90/27033600] via 40.40.40.13, 00:22:25, Tunnel66
D EX
10.23.23.0/24 [170/28288000] via 40.40.40.23, 00:00:30, Tunnel66
D EX
10.25.25.0/24 [170/28288000] via 40.40.40.25, 00:00:30, Tunnel66

172.5.5.0 [90/27033600] via 40.40.40.13, 00:22:25, Tunnel66

172.6.6.0 [90/27059200] via 40.40.40.13, 00:22:25, Tunnel66

172.16.56.0 [90/26905856] via 40.40.40.13, 00:22:25, Tunnel66
172.16.100.0 [90/26931456] via 40.40.40.13, 00:22:25, Tunnel66
172.16.200.0 [90/26905856] via 40.40.40.13, 00:22:25, Tunnel66
172.16.214.0 [90/26905600] via 40.40.40.13, 00:22:25, Tunnel66
172.16.215.0 [90/26905600] via 40.40.40.13, 00:22:25, Tunnel66
172.16.216.0 [90/26931200] via 40.40.40.13, 00:22:25, Tunnel66
D EX
192.168.0.0/16 [170/542771200] via 192.168.24.6, 2w0d, Serial2/0
192.168.13.0/24 [90/34036062] via 192.168.24.6, 2w0d, Serial2/0
192.168.15.0/24 [90/27417600] via 40.40.40.13, 00:22:25, Tunnel66
192.168.23.0/24 [90/44276062] via 192.168.24.6, 2w0d, Serial2/0
192.168.25.0/24 [90/23796062] via 192.168.24.6, 2w0d, Serial2/0
192.168.74.0/24 [90/34036062] via 192.168.24.6, 2w0d, Serial2/0
192.168.76.0/24 [90/23796062] via 192.168.24.6, 2w0d, Serial2/0
26 | P a g e
Version 5.1B

Summary of Changes
R24
conf t
no crypto isakmp key &IPX address 0.0.0.0
crypto isakmp key $IPX address 0.0.0.0
end
R13
conf t
interface tunnel66
no ip split-horizon eigrp 300
end
ISP6
conf t
no ip nat inside source static udp 192.168.76.6 500 192.168.24.24 500 extendable
no ip nat inside source static udp 192.168.76.6 4500 192.168.24.24 4500 extendable
end
Version 5.1B
27 | P a g e

Incident 2
(1 point)
Users that are located in VLAN100 of the IPexpert HQ office have lost access to the Server which
is located in VLAN200.
Isolate and fix the issues so R10 is reachable from R14. The outputs should match the below:
28 | P a g e
Version 5.1B

R14
R14#ping 172.16.200.2
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/1 ms
R14#traceroute 172.16.200.2 num

1 172.16.100.1 1 msec 0 msec 0 msec
2 172.16.56.5 0 msec 0 msec 1 msec
3 172.16.200.2 0 msec *
0 msec
Solution
The incident states that we should be able to reach the server in VLAN200, we will start by checking
for connectivity.
R14
R14#sh ip route

C

R14#sh ip interface br | e ass

Interface
IP-Address
OK? Method Status
Protocol
Loopback0
10.14.14.14
YES manual up
up
Version 5.1B
29 | P a g e

Next we will want to identify R14's interface , in order to verify the configurations on that port .
R14
R14#sh cdp ne
Capability Codes: R - Router, T - Trans Bridge, B - Source Route Bridge
S - Switch, H - Host, I - IGMP, r - Repeater, P - Phone,
D - Remote, C - CVTA, M - Two-port Mac Relay
Device ID
Local Intrfce
Holdtme
SW6
Eth 0/1
157
Capability
R S
Platform
Port ID
Eth 1/2
Total cdp entries displayed : 1
R14#sh run interface e0/1


!
ip address dhcp client-id Ethernet0/1 hostname R14
end
We can see that R14 is supposed to be assigned an IP address via DHCP, now we need to check SW6
interface configuration and follow the DHCP related configs trail.
SW6
SW6#sh run interface e1/2
!
switchport access vlan 100
switchport mode access
duplex auto
spanning-tree portfast
ip dhcp snooping trust
end
SW6#sh run interface vlan100
30 | P a g e
Version 5.1B

!
interface Vlan100
ip address 172.16.100.1 255.255.255.0
ip helper-address 10.13.13.13
ip helper-address 10.15.15.15
The DHCP configurations on SW6 seem to be correct, we can also see that we are doing DHCP relay
towards R13 and R15 , next we will have to check their configurations.
R13
R13#sh run | sec dhcp
ip dhcp excluded-address 172.16.200.1
ip dhcp excluded-address 172.16.100.1 172.16.100.99
ip dhcp pool VLAN200
network 172.16.200.0 255.255.255.0
default-router 172.16.200.1
dns-server 172.16.200.1
domain-name ipexpert.com
network 172.16.100.0 255.255.255.0
dns-server 172.16.100.1
ip dhcp pool VLAN200-HOST
host 172.16.200.2 255.255.255.0
client-identifier 01aa.bbcc.000a.00
dns-server 172.16.200.1
host 172.16.100.100 255.255.255.0
dns-server 172.16.100.1
Version 5.1B
31 | P a g e

R15
R15#sh run | sec dhcp
ip dhcp excluded-address 172.16.200.1
network 172.16.200.0 255.255.255.0
dns-server 172.16.200.1
network 172.16.100.0 255.255.255.0
dns-server 172.16.100.1
host 172.16.200.2 255.255.255.0
dns-server 172.16.200.1
host 172.16.100.100 255.255.255.0
dns-server 172.16.100.1
32 | P a g e
Version 5.1B

R14
R14#sh interface e0/1
Ethernet0/1 is up, line protocol is up
Hardware is AmdP2, address is aabb.cc00.0e10 (bia aabb.cc00.0e10)
Internetwork address will be negotiated using DHCP
MTU 1500 bytes, BW 10000 Kbit/sec, DLY 1000 usec,
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation ARPA, loopback not set
Keepalive set (10 sec)
ARP type: ARPA, ARP Timeout 04:00:00
Last input 00:00:00, output 00:00:04, output hang never
Last clearing of "show interface" counters never
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
871067 packets input, 62888524 bytes, 0 no buffer
Received 750287 broadcasts (106 IP multicasts)
0 runts, 0 giants, 0 throttles
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
0 input packets with dribble condition detected
174722 packets output, 21433219 bytes, 0 underruns
0 output errors, 0 collisions, 3 interface resets
6 unknown protocol drops
0 babbles, 0 late collision, 0 deferred
0 lost carrier, 0 no carrier
0 output buffer failures, 0 output buffers swapped out
At this point, we will make sure that the dhcp pools settings for VLAN100 are correct: default-route,
dns-server, subnet, host ip address, client-identifier -- all these need to match the diagram given to
us. We want to quickly obtain the correct mac-address to be used as the client-identifier (according
to the previous output the mac-add seems to be different).
NOTE
Notice that we have logging turned off on all devices, to quickly ident ify faults it is advised to turn
these on.
Version 5.1B
33 | P a g e

R13 / R15
conf t
logging monitor 7
logging buffered 7
logging console 7
end
debug dhcp det
debug ip dhcp server events
We will want to quickly trigger a DHCP discover packet to be sent from R14 towards the DHCP server
routers:
R14
conf t
interface e0/1
shutdown
no shutdown
end
R13 / R15
*Mar 28 03:49:34.199: DHCPD: client's VPN is .
*Mar 28 03:49:34.199: DHCPD: No option 125
*Mar 28 03:49:34.199: DHCPD: Sending notification of DISCOVER:
*Mar 28 03:49:34.199:
DHCPD: htype 1 chaddr aabb.cc00.0e10
*Mar 28 03:49:34.199:
DHCPD: remote id 020a0000ac10d80201000000
*Mar 28 03:49:34.199:
DHCPD: circuit id 00000000
*Mar 28 03:49:34.199: DHCPD: DHCPDISCOVER received from client 01aa.bbcc.000e.10

through relay 172.16.100.1.
*Mar 28 03:49:34.199: DHCPD: Seeing if there is an internally specified pool class:
*Mar 28 03:49:34.199:
*Mar 28 03:49:34.199:
*Mar 28 03:49:34.199:
*Mar 28 03:49:34.199: DHCPD: Allocate an address without class information

(172.16.100.0)
*Mar 28 03:49:34.199: DHCPD: subnetwork [172.16.100.1,172.16.100.254] in address pool
VLAN100 is empty.
*Mar 28 03:49:34.199: DHCPD: Sending notification of ASSIGNMENT FAILURE:
*Mar 28 03:49:34.199:
34 | P a g e
Version 5.1B

*Mar 28 03:49:34.199:
*Mar 28 03:49:34.199:
*Mar 28 03:49:34.199: DHCPD: Sending notification of ASSIGNMENT_FAILURE:

*Mar 28 03:49:34.199:
DHCPD: due to: POOL EXHAUSTED
*Mar 28 03:49:34.199:
The pool says it is exhausted, we can also see that the client-identifier is different,
let's modify this:
R13 / R15
RX(config)#ip dhcp pool VLAN100-HOST
RX(dhcp-config)#no client-identifier 01aa.bbcc.000a.10
RX(dhcp-config)#client-identifier 01aa.bbcc.000e.10
R14
R14(config)#interface e0/1
R14(config-if)#shutdown
R14(config-if)#no shutdown
Let us now recheck the connectivity towards VLAN200 server:
R14
R14#sh ip route
Gateway of last resort is 172.16.100.1 to network 0.0.0.0
S*
0.0.0.0/0 [254/0] via 172.16.100.1


172.16.100.0/24 is directly connected, Ethernet0/1
172.16.216.2/32 [254/0] via 172.16.100.1, Ethernet0/1
R14#ping 172.16.200.2
Version 5.1B
35 | P a g e

.!!!!
R14#
Summary of Changes
R13 / R15
conf t
no client-identifier 01aa.bbcc.000a.10
client-identifier 01aa.bbcc.000e.10
end
36 | P a g e
Version 5.1B

Incident 3
(2 points)
ISP3 is trying to reach ISP2 network of 10.102.102.0 /24 but is unsuccessful.

Isolate and fix the issues so that it is reachable from ISP3, the outputs should match the below:
ISP3#ping 10.102.102.102
!!!!!
Version 5.1B
37 | P a g e

Solution
First, verify that ISP3 has no connectivity to ISP2 network 10.102.102.0/24:
ISP3
ISP3#traceroute 10.102.102.102
1 132.56.78.10 8 msec 9 msec 8 msec
2 132.56.78.10 !H
!H
With the above traceroute command, we have established that there might be an issue from ISP1
towards ISP2, let's take a look at ISP1 config:
ISP1
ISP1#sh cdp ne
Device ID
Local Intrfce
Holdtme
Capability
Platform
Port ID
ISP3.global.com
Ser 3/0
161
R B
Ser 3/0
R2
Ser 2/0
169
R B
Ser 2/2
ISP2
Ser 2/2
154
R B
Ser 2/2
Total cdp entries displayed : 3
ISP1#sh ppp all

Interface/ID OPEN+ Nego* Fail-
Stage
Peer Address
Peer Name
------------ --------------------- -------- --------------- -------------------Se2/2
LCP+ CHAP+ IPCP+ IPV> LocalT
0.0.0.0
ISP2
Se2/0
132.56.78.2
R2
Se3/0
132.56.78.9
ISP3
With the above output, we identified that ISP2 has no peer address for its PPP link.
The reasons for that can be:
wrong ppp credentials
38 | P a g e
Version 5.1B

wrong encapsulation
wrong ppp method of authentication
missing local credentials for identifying the remote side (or vice versa)
Let's look closer at the connection of ISP1 <> ISP2 configuration:
ISP1
ISP1#sh run | sec 2/2|username|pool
ip dhcp pool PPP-POOL
network 132.56.78.4 255.255.255.252
username R2 password 0 CC1E
username ISP3 password 0 CC1E
interface Serial2/2
ip address 132.56.78.6 255.255.255.252
encapsulation ppp
no peer neighbor-route
peer default ip address pool PPP-P00L
ipv6 address 2001:CC1E:112::1/64
ipv6 ospf 1 area 0
ppp max-failure 3
ppp authentication chap
ppp chap hostname ISP1
ppp chap password 0 CC1E
ISP2
ISP2#sh run | sec 2/2|username
interface Serial2/2
ip address negotiated
encapsulation ppp
ipv6 address 2001:CC1E:112::2/64
ipv6 ospf 1 area 0
ppp authentication chap
ppp chap hostname ISP2
ppp chap password 0 CC1E
serial restart-delay 0
Version 5.1B
39 | P a g e

NOTE
Notice that we have logging turned off on all devices. To quickly identify faults it is advised to turn
these on.
ISP1 / ISP2
conf t
logging monitor 7
logging buffered 7
logging console 7
end
debug ppp authentication
debug ppp negotiation
ISP1
<output omitted>
*Mar 28 04:27:18.313: Se2/2 LCP:
AuthProto CHAP (0x0305C22305)
*Mar 28 04:27:18.313: Se2/2 LCP:
MagicNumber 0x098CF2A3 (0x0506098CF2A3)
*Mar 28 04:27:18.313: Se2/2 LCP: O CONFACK [REQsent] id 1 len 15

*Mar 28 04:27:18.313: Se2/2 LCP:
*Mar 28 04:27:18.313: Se2/2 LCP:
MagicNumber 0x098CF2A3 (0x0506098CF2A3)
*Mar 28 04:27:18.313: Se2/2 LCP: Event[Receive ConfReq+] State[REQsent to ACKsent]

*Mar 28 04:27:18.314: Se2/2 LCP: I CONFACK [ACKsent] id 1 len 15
*Mar 28 04:27:18.314: Se2/2 LCP:
*Mar 28 04:27:18.314: Se2/2 LCP:
MagicNumber 0xFC64C302 (0x0506FC64C302)
*Mar 28 04:27:18.314: Se2/2 LCP: Event[Receive ConfAck] State[ACKsent to Open]

*Mar 28 04:27:18.323: Se2/2 PPP: Phase is AUTHENTICATING, by both
*Mar 28 04:27:18.323: Se2/2 CHAP: O CHALLENGE id 1 len 25 from "ISP1"
*Mar 28 04:27:18.323: Se2/2 LCP: State is Open
*Mar 28 04:27:18.327: Se2/2 CHAP: I CHALLENGE id 1 len 25 from "ISP2"
*Mar 28 04:27:18.327: Se2/2 PPP: Sent CHAP SENDAUTH Request
*Mar 28 04:27:18.327: Se2/2 PPP: Received SENDAUTH Response PASS
*Mar 28 04:27:18.327: Se2/2 CHAP: Using hostname from interface CHAP
*Mar 28 04:27:18.328: Se2/2 CHAP: Using password from AAA
*Mar 28 04:27:18.328: Se2/2 CHAP: O RESPONSE id 1 len 25 from "ISP1"
*Mar 28 04:27:18.332: Se2/2 CHAP: I RESPONSE id 1 len 25 from "ISP2"
*Mar 28 04:27:18.332: Se2/2 PPP: Phase is FORWARDING, Attempting Forward
*Mar 28 04:27:18.332: Se2/2 PPP: Phase is AUTHENTICATING, Unauthenticated User
40 | P a g e
Version 5.1B

*Mar 28 04:27:18.332: Se2/2 PPP: Sent CHAP LOGIN Request
*Mar 28 04:27:18.333: Se2/2 PPP: Received LOGIN Response PASS
*Mar 28 04:27:18.333: Se2/2 IPCP: Authorizing CP
*Mar 28 04:27:18.337: Se2/2 PPP: Phase is AUTHENTICATING, Authenticated User
*Mar 28 04:27:18.337: Se2/2 CHAP: O SUCCESS id 1 len 4
*Mar 28 04:27:18.337: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial2/2,
changed state to up
*Mar 28 04:27:18.337: Se2/2 PPP: Outbound cdp packet dropped, line protocol not up
*Mar 28 04:27:18.337: Se2/2 PPP: Phase is UP
*Mar 28 04:27:18.339: Se2/2 IPCP: I CONFREQ [REQsent] id 1 len 10
*Mar 28 04:27:18.339: Se2/2 IPCP:
Address 0.0.0.0 (0x030600000000)
*Mar 28 04:27:18.339: Se2/2 IPCP AUTHOR: Start.

*Mar 28 04:27:18.339: Se2/2 IPCP AUTHOR: Done.
Her address 0.0.0.0, we want 0.0.0.0

Her address 0.0.0.0, we want 0.0.0.0
*Mar 28 04:27:18.339: Se2/2 IPCP: Cannot satisfy pool request

*Mar 28 04:27:18.340: Se2/2 IPCP: Neither side knows remote address
*Mar 28 04:27:18.340: Se2/2 IPCP: O CONFREJ [REQsent] id 1 len 10
*Mar 28 04:27:18.340: Se2/2 IPCP:
Address 0.0.0.0 (0x030600000000)
*Mar 28 04:27:18.340: Se2/2 IPCP: Event[Receive ConfReq-] State[REQsent to REQsent]
The debug output reveals with no doubt that an address cannot be assigned due to a pool issue, also
the authentication passed successfully. Further to the debug output if we look further into the actual
configs we can identify 2 of the faults:
The "peer default ip address pool xxx" syntax is incorrect.

The pool name is wrong, should be PPP-POOL instead of PPP-P00L .
mistyped "0" instead of "O".
Let's correct these and check for reachability from ISP3.
ISP1
ISP1(config)#no ip dhcp pool PPP-POOL
ISP1(config)#ip local pool PPP-POOL 132.56.78.5 132.56.78.5
ISP1(config)#interface serial2/2
ISP1(config-if)#shutdown
ISP1(config-if)#no peer default ip address pool PPP-P00L
ISP1(config-if)#peer default ip address pool PPP-POOL
ISP1(config-if)#no shutdown
Version 5.1B
41 | P a g e

ISP3
ISP3#traceroute 10.102.102.102 num
1 132.56.78.10 8 msec 8 msec 8 msec
2 132.56.78.10 !H
!H
Seems as if we still have an issue; let's go to ISP2 and verify some configs:
ISP2
ISP2#sh ip aliases
Address Type
IP Address
Port
Interface
10.102.102.102
ISP2#sh ppp all

Stage
Peer Address
Peer Name
------------ --------------------- -------- --------------- -------------------Se2/2
132.56.78.6
ISP1
We can see that the ppp negotiation is successful and we have an ip address assigned
to our interface, but it seems that we have no route to get back to ISP3. Since we are forbidden to
use static routes or remove configs, we shall modify the configs while respecting these restrictions:
42 | P a g e
Version 5.1B

ISP2
ISP2(config)#interface serial2/2
ISP2(config-if)#shutdown
ISP2(config-if)#ppp ipcp route default
ISP2(config-if)#no shutdown
ISP2#sh ip route
S*
0.0.0.0/0 [1/0] via 132.56.78.6


132.56.78.0/30 [120/1] via 132.56.78.6, 00:00:24
132.56.78.2/32 [120/1] via 132.56.78.6, 00:00:24
132.56.78.8/30 [120/1] via 132.56.78.6, 00:00:24
132.56.78.9/32 [120/1] via 132.56.78.6, 00:00:24
ISP3
ISP3#traceroute 10.102.102.102
1 132.56.78.10 9 msec 9 msec 9 msec
2 132.56.78.5 17 msec *
17 msec
ISP3#ping 10.102.102.102
!!!!!
As you can see from the ping results above, network 10.102.102.0/24 is now reachable from ISP3 as
the incident requested.
Version 5.1B
43 | P a g e

Summary of Changes
ISP1
conf t
no ip dhcp pool PPP-POOL
ip local pool PPP-POOL 132.56.78.5 132.56.78.5
interface serial2/2
no peer default ip address pool PPP-P00L
peer default ip address pool PPP-POOL
ISP2
conf t
interface serial2/2
ppp ipcp route default
44 | P a g e
Version 5.1B

Incident 4
(2 points)
Starbucks Coffee branch-1 cannot communicate with Starbucks branch-2.

Troubleshoot and fix the issues so that both sites have reachability.
The outputs should match the below:
R16#ping 10.20.20.20 source lo0
!!!!!
R20#ping 10.16.16.16 so lo0
Version 5.1B
45 | P a g e

!!!!!
Solution
Lets first look at the output from the specified command in the incident to determine where to focus
our efforts. We will start by testing the reachability:
R16
R16#ping 10.20.20.20 source l0
..
R20
R20#ping 10.16.16.16 so lo0
.....
The connectivity check is unsuccessful. We will now review configs of the central router according to
the diagram and see if full reachability is available from there.
R18
R18#sh ip route
B
10.16.16.0/24 [20/0] via 132.56.16.16, 2w1d

46 | P a g e
Version 5.1B

C
The given output reveals to us that we are missing a route towards network 10.20.20.0/24. We will
now try and investigate why R18 doesn't learn any routes from R20.
R18
R18#sh ip bgp summary
BGP router identifier 10.18.18.18, local AS number 62566
BGP table version is 5, main routing table version 5
<output omitted>
Neighbor
AS MsgRcvd MsgSent
TblVer
InQ OutQ Up/Down
State/PfxRcd
132.56.16.16
65501
24090
24089
0 2w1d
132.56.20.20
65502
0 00:09:22 Active
R18#ping 132.56.20.20
.....
Obviously something is wrong between these two routers R18 <> R20, we can't even ping from one
to the other, and the bgp neighborship is down as well. The issue might be a Layer1-Layer2.
According to the diagram VLAN1820 is the L2 vlan used to connect these two, thus we should check
the switch.
R18
R18#sh cdp ne
Device ID
Local Intrfce
Holdtme
ISP3.global.com
Ser 2/0
129
R B
Ser 3/3
SW7
Eth 0/0
169
R S
Eth 0/3
SW8
Eth 0/1
176
R S
Eth 0/2
Version 5.1B
Capability
Platform
Port ID
47 | P a g e

SW8
duplex auto
end
SW8#sh interface status

Port
Name
Status
Vlan
Duplex
Et0/0
connected
1618
auto
auto unknown
Et0/1
connected
auto
auto unknown
Et0/2
connected
1820
auto
auto unknown
Et0/3
connected
auto
auto unknown
Et1/0
connected
auto
auto unknown
Et1/1
err-disabled 1802
auto
auto unknown
Et1/2
connected
auto
auto unknown
Speed Type
<output omitted>
We can immediately identify that we have one interface which state is "err-disabled", if we look
further we can see that the err-disabled is caused due to port-security violation policy and the macaddress is incorrect . The second fault seen here is a mistyped vlan id # (1802) instead of (1820).
NOTE
The err-disabled port can also be identified if we make sure to enabled the logging on the switch and
flapping the interface "up" / "down".
SW8

!
48 | P a g e
Version 5.1B

switchport port-security
switchport port-security mac-address sticky
switchport port-security mac-address sticky aabb.cc00.1410
duplex auto
ip dhcp snooping trust
SW8#sh port-security
Secure Port
MaxSecureAddr
CurrentAddr
(Count)
(Count)
SecurityViolation
Security Action
(Count)
--------------------------------------------------------------------------Et1/1
Shutdown
--------------------------------------------------------------------------Total Addresses in System (excluding one mac per port)
: 0
Max Addresses limit in System (excluding one mac per port) : 4096
Let's fix these two faults and see if the problem is solved:
SW8
conf t
logging monitor 7
logging buffered 7
logging console 7
interface e1/1
shutdown
no shutdown
end
SW8(config-if)#
*Mar 28 08:46:38.435: %PM-4-ERR_DISABLE: psecure-violation error detected on Et1/1,
putting Et1/1 in err-disable state
SW8(config-if)#
*Mar 28 08:46:38.436: %PORT_SECURITY-2-PSECURE_VIOLATION: Security violation occurred,
caused by MAC address aabb.c000.1410 on port Ethernet1/1.
SW8(config)#interface e1/1
Version 5.1B
49 | P a g e

SW8(config-if)#shutdown
SW8(config-if)#switchport access vlan 1820
SW8(config-if)#no switchport port-security mac-address sticky
SW8(config-if)#switchport port-security mac-address sticky
SW8(config-if)#no shutdown
Since the switch interface is configured with the "sticky" feature, removing and re-enabling the sticky
feature allows the switch to learn a new mac-address and save it into its config for future use. Once
this was modified the switch immediately brings the interface to the "up" state, and we can re-test
for reachability between the branches.
R16
R16#ping 10.20.20.20 source l0
!!!!!
R20
R20#ping 10.16.16.16 so lo0
!!!!!
Summary of Changes
SW8
conf t
interface e1/1
shutdown
no switchport port-security mac-address sticky
switchport port-security mac-address sticky
no shutdown
50 | P a g e
Version 5.1B

Incident 5
(1 point)
The Global Provider network engineer is having IPv6 connectivity issues between the Data Center
and their DR site and cannot reach one of their IPv6 Management web sites.
Fix the issue so that the following sequence of commands produces the same relevant result:
ISP3#ping www.global.com
Sending 5, 100-byte ICMP Echos to 2001:50:50::50, timeout is 2 seconds:
!!!!!
ISP3#telnet www.global.com 80
Translating "www.global.com"...domain server (255.255.255.255)
Trying 2001:50:50::50, 80 ... Open
get
HTTP/1.1 400 Bad Request
Version 5.1B
51 | P a g e

Date: Wed, 04 Feb 2015 11:01:43 GMT
Server: cisco-IOS
Accept-Ranges: none
400 Bad Request

[Connection to www.global.com closed by foreign host]
Solution
The incident states that we should be able to access the web site, we will start by checking to see if
we have a proper DNS resolving:
ISP3
AAAAA
There is a DNS resolving of the hostname www.global.com to an IPv6 address, but it doesn't seem to
be successful, instead we are receiving a "AAAAA" ping response which indicates "Administrative
unreachable".
Administrative unreachable usually happens when we have an ACL blocking the traffic. We will now
want to isolate the cause and quickly identify all the faults , thus we will check to see if the web site is
reachable via port 80 HTTP.
ISP3
ISP3#telnet www.global.com 80
Trying 2001:50:50::50, 80 ...
% Destination unreachable; gateway or host down
No success, at this point we should investigate and check for an IPv6 access-list along the path to our
destination of 2001:50:50::50 which exists on R50.
R2
R2#sh ipv6 access-list
52 | P a g e
Version 5.1B

ISP1
ISP1#sh ipv6 access-list
R50
IPv6 access list IPv6-WEB
permit tcp host 2001:50:50::50 eq www host 2001:CC1E:113::2 sequence 5
host 2001:50:50::50 host 2001:CC1E:113::2 sequence 10
permit icmp
deny tcp any host 2001:50:50::50 eq www (1 match) sequence 15

deny icmp any any (5 matches) sequence 20
permit ipv6 any any (66197 matches) sequence 25
R50#sh ipv6 interface | inc line|access

Serial2/0 is up, line protocol is up
Inbound access list IPv6-WEB
Serial2/1 is up, line protocol is up
Inbound access list IPv6-WEB
Loopback0 is up, line protocol is up
There is a mis-configuration of the IPv6 access-list. Since the ACL is applied inbound on R50 then
sequence 5 & 10 should be reversed allowing the traffic instead of blocking it; notice the fact that we
are also missing hit counts on these lines. Let's modify this and see what happens.
R50
R50(config)#no ipv6 access-list IPv6-WEB
R50(config)#ipv6 access-list IPv6-WEB
R50(config-ipv6-acl)#sequence 5 permit tcp host 2001:CC1E:113::2 host 2001:50:50::50
eq 80
R50(config-ipv6-acl)#sequence 10 permit icmp host 2001:CC1E:113::2 host 2001:50:50::50
R50(config-ipv6-acl)#sequence 15 deny tcp any host 2001:50:50::50 eq 80
R50(config-ipv6-acl)#sequence 20 deny icmp any any
R50(config-ipv6-acl)#sequence 25 permit ipv6 any any
Version 5.1B
53 | P a g e

ISP3
!!!!!
ISP3#telnetwork www.global.com 80
Trying 2001:50:50::50, 80 ...
% Destination unreachable; gateway or host down
Still can't access the web site, at this point we should verify the modified ACL and look for hit counts,
also check that the HTTP service is actually enabled on the router.
R50
IPv6 access list IPv6-WEB
permit tcp host 2001:CC1E:113::2 host 2001:50:50::50 eq www (1 match) sequence 5
permit icmp host 2001:CC1E:113::2 host 2001:50:50::50 (5 matches) sequence 10
deny tcp any host 2001:50:50::50 eq www sequence 15
deny icmp any any sequence 20
permit ipv6 any any (18 matches) sequence 25
R50#sh ip http server status

HTTP server status: Disabled
HTTP server port: 80
<output omitted>
The output above is indicative that the HTTP service is disabled on the router, we should enable this
and see if the problem is solved.
R50
R50(config)#ip http server
54 | P a g e
Version 5.1B

ISP3
ISP3# telnetwork www.global.com 80
Trying 2001:50:50::50, 80 ... Open
get
HTTP/1.1 400 Bad Request
Date: Sat, 28 Mar 2015 09:37:34 GMT
Server: cisco-IOS
Accept-Ranges: none
400 Bad Request

[Connection to www.global.com closed by foreign host]
Everything seems to be operational and match the given output of the incident, we will make one
final verification to be 100% sure we are correct by examining the HTTP server connection history on
R50.
R50
R50#sh ip http server history
HTTP server history:
local-ipaddress:port
[2001:50:50::50]:80
remote-ipaddress:port in-bytes
out-bytes
end-time
122
10:50:44 03/20
122
10:54:09 03/20
\
[2001:CC1E:113::2]:19931 \
5
[2001:50:50::50]:80
\
[2001:CC1E:113::2]:56720 \
13
Version 5.1B
55 | P a g e

Summary of Changes
R50
no ipv6 access-list IPv6-WEB
ipv6 access-list IPv6-WEB
sequence 5 permit tcp host 2001:CC1E:113::2 host 2001:50:50::50 eq 80
sequence 10 permit icmp host 2001:CC1E:113::2 host 2001:50:50::50
sequence 15 deny tcp any host 2001:50:50::50 eq 80
sequence 20 deny icmp any any
sequence 25 permit ipv6 any any
exit
ip http server
56 | P a g e
Version 5.1B

Incident 6
(2 points)
The NOC team has identified it has lost connectivity to the Global Provider DR Site.
Isolate and fix the configuration such that the traffic can reach its destination as shown in the
output:
Version 5.1B
57 | P a g e

R2
R2#sh ip route vrf ISP 221.50.0.50
Routing Table: ISP
Routing entry for 221.0.0.0/8, supernet
Known via "bgp 7200", distance 20, metric 0
Tag 20001, type external
Last update from 123.10.1.6 00:07:20 ago
Routing Descriptor Blocks:
* 123.10.1.6, from 123.10.1.6, 00:07:20 ago
Route metric is 0, traffic share count is 1
AS Hops 1
Route tag 20001
MPLS label: none
R2#traceroute vrf ISP 221.50.0.50 num
1 123.10.1.6 9 msec
Solution
First thing to notice is that the incident output refers to BGP routes, which is our starting point and
we will focus on that.
R2
Routing Table: ISP
% Network not in table
By looking at the output above we can conclude that the route is not being received or learned from
our BGP peers, so we will check the BGP peering status:
58 | P a g e
Version 5.1B

R2
R2#sh bgp vpnv4 unicast all summary
<output omitted>
Neighbor
10.7.7.7
7200
4882
452
10.8.8.8
7200
4299
450
123.10.1.6
132.56.78.1
AS MsgRcvd MsgSent
20001
10100
0
10843
TblVer
12
12
0
10841
InQ OutQ Up/Down
06:44:22
06:44:23
1
12
State/PfxRcd
0
0
1w0d
6d20h
Idle
2
Let's turn on logging on the router to maybe help us identify the root cause of this.
R2
logging monitor 7
logging buffered 7
logging console 7
*Mar 28 09:52:38.335: %TCP-6-BADAUTH: Invalid MD5 digest from 123.10.1.6(62888) to

123.10.1.5(179) tableid - 1
R2#
*Mar 28 09:52:42.335: %TCP-6-BADAUTH: Invalid MD5 digest from 123.10.1.6(62888) to
123.10.1.5(179) tableid - 1
Version 5.1B
59 | P a g e

The logs immediately reveal to us that we have an authentication issue between our two BGP peers.
Let's compare both routers configs and afterwards fix it and verify again.
R2
R2#sh run | sec bgp
router bgp 7200
bgp router-id 10.2.2.2
bgp log-neighbor-changes
no bgp default ipv4-unicast-unicast
<output omitted>
!
address-family ipv4 vrf ISP
network 132.56.78.0 mask 255.255.255.252
neighbor 123.10.1.6 remote-as 20001
neighbor 123.10.1.6 password ipx$S
neighbor 123.10.1.6 activate
neighbor 123.10.1.6 send-community both
neighbor 123.10.1.6 route-map BGP-COMM-CLEAR in
maximum-paths 2
exit-address-family
R50
R50#sh run | sec bgp
router bgp 20001
bgp router-id 10.50.50.50
network 10.50.50.0 mask 255.255.255.0
redistribute connected
neighbor 123.10.1.5 password ipx$2
neighbor 123.10.1.5 default-originate
neighbor 123.10.1.5 route-map BGP-PREPEND out
60 | P a g e
Version 5.1B

R2
R2(config)#router bgp 7200
R2(config-router)#address-family ipv4 vrf ISP
R2(config-router-af)#no neighbor 123.10.1.6 password ipx$S
R2(config-router-af)#neighbor 123.10.1.6 password ipx$2
At this point, we immediately receive several new log messages which indicate another issue, this
message states that our peer is not using the correct AS of 1C20 (in hex). Looking at the diagram we
can see that the correct ASN is 7200.
NOTE
Hex value of 1C20 converted into Decimal value gives us a value of 7200.
R2
*Mar 28 09:58:52.941: %BGP-3-NOTIFICATION: received from neighbor 123.10.1.6 active
2/2 (peer in wrong AS) 2 bytes 1C20
R2#
*Mar 28 09:58:52.941: %BGP-5-NBR_RESET: Neighbor 123.10.1.6 active reset (BGP
Notification received)
*Mar 28 09:58:52.942: %BGP-5-ADJCHANGE: neighbor 123.10.1.6 active vpn vrf ISP Down
BGP Notification received
*Mar 28 09:58:52.942: %BGP_SESSION-5-ADJCHANGE: neighbor 123.10.1.6 IPv4 Unicast vpn
vrf ISP topology base removed from session BGP Notification received
We now know that the opposite router (R50) is trying to peer using the wrong ASN, we will go and fix
that and see if that gets us the final solution.
R50
R50(config-router)#router bgp 20001
R50(config-router)#no neighbor 123.10.1.5 remote-as 72000
R50(config-router)#neighbor 123.10.1.5 remote-as 7200
R50(config-router)#neighbor 123.10.1.5 password ipx$2
R50(config-router)#neighbor 123.10.1.5 send-community both
R50(config-router)#neighbor 123.10.1.5 default-originate
R50(config-router)#neighbor 123.10.1.5 route-map BGP-PREPEND out
R2
*Mar 28 10:06:38.622: %BGP-5-ADJCHANGE: neighbor 123.10.1.6 vpn vrf ISP Up
Version 5.1B
61 | P a g e

Immediately notice the "neighbor x.x.x.x up" message on R2 indicating that the peer from R2 <> R50
is up and we should be receiving routes now. Let's make sure of this and display the output we were
asked for at incident.
R2
R2#sh bgp vpnv4 unicast all sum
<output omitted>
Neighbor
AS MsgRcvd MsgSent
TblVer
InQ OutQ Up/Down
State/PfxRcd
10.7.7.7
7200
5206
477
84
0 07:03:57
10.8.8.8
7200
4581
475
84
0 07:03:59
123.10.1.6
20001
84
0 00:00:50
73
132.56.78.1
10100
10865
10867
84
0 6d20h

Routing Table: ISP
Known via "bgp 7200", distance 20, metric 0
Last update from 123.10.1.6 00:04:36 ago
* 123.10.1.6, from 123.10.1.6, 00:04:36 ago
AS Hops 1
Route tag 20001
MPLS label: none
R2#traceroute vrf ISP 221.50.0.50 numeric

1 123.10.1.6 9 msec *
62 | P a g e
9 msec
Version 5.1B

Summary of Changes
R2
conf t
router bgp 7200
address-family ipv4 vrf ISP
no neighbor 123.10.1.6 password ipx$S
end
R50
conf t
router bgp 20001
no neighbor 123.10.1.5 remote-as 72000
neighbor 123.10.1.5 default-originate
neighbor 123.10.1.5 route-map BGP-PREPEND out
end
Version 5.1B
63 | P a g e

Incident 7
(3 points)
ISP4 is trying to reach the internet ip address of 8.8.8.8 but is unsuccessful.

Fix the issue so that the following sequence of commands produces the same relevant result:
R50
R50#traceroute 192.168.44.1 source loopback1
1 123.10.1.5 8 msec 9 msec 9 msec
2 123.10.82.8 [AS 10100] [MPLS: Labels 21/18 Exp 0] 26 msec 26 msec 26 msec
3
*
194.45.67.1 [AS 10100] [MPLS: Labels 17/18 Exp 0] 27 msec *
4 192.168.44.2 [AS 65505] [MPLS: Label 18 Exp 0] 17 msec 17 msec 17 msec

5 192.168.44.1 [AS 65505] 26 msec 26 msec *
64 | P a g e
Version 5.1B

ISP4
ISP4#ping 8.8.8.8
!!!!!
NOTE
This incident is dependent on Incident 6.
The first step here will be to test the commands given in the output and see what doesn't exactly
work. This will give us a direction as to what we should be focusing on. Let's observe the results of the
required successful traceroute and ping. Also remember that this incident is dependent on Incident 6.
R50
R50#traceroute 192.168.44.1
1
ISP4
ISP4#ping 8.8.8.8
..
ISP4#sh ip route
<output omitted>
C
192.168.0.0/16 [200/0] via 0.0.0.0, 2w1d, Null0
192.168.13.0/24 [90/23796062] via 192.168.74.7, 2w1d, Serial4/0
L
D

192.168.76.0/24 [90/23796062] via 192.168.74.7, 2w1d, Serial4/0
Version 5.1B
65 | P a g e

We have now confirmed that we cannot reach our destination and cannot go further than ISP4, we
have no default route or any specific routes toward our destination. Let's try and identify what might
be the problem from R4's side. Let's further look into the BGP and VRF configurations (implied by the
diagram).
R4
R4#sh bgp vpnv4 unicast all summary
<output omitted>
Neighbor
10.7.7.7
7200
AS MsgRcvd MsgSent
16696
10986
TblVer
2
InQ OutQ Up/Down

0
0 6d22h
State/PfxRcd
0
10.8.8.8
7200
16029
10977
0 6d22h
192.168.44.1
65505
10988
10977
0 6d22h
R4#sh ip vrf
Name
Default RD
Interfaces
Customer_B
245:10
Se2/0
R4#sh ip route vrf Customer_B

Routing Table: Customer_B
<output omitted>
192.168.0.0/16 [20/0] via 192.168.44.1, 6d22h

We can notice that we are not receiving any routes from neighbors R7 and R8 which according to the
diagram are the Route-Reflectors, that seems odd and we will have to investigate that further. Let's
see if the vrf configs on R4 are correct. We can also use the MPLS diagram provided to compare the
VRFs settings.
66 | P a g e
Version 5.1B

R4
R4#sh run | section vrf
ip vrf Customer_B
rd 245:10
route-target export 245:100
route-target import 10100:10
ip vrf forwarding Customer_B
address-family ipv4 vrf Customer_B
network 10.4.4.0 mask 255.255.255.0
R2
R2#sh run | section vrf
ip vrf ISP
rd 10100:10
export map RMAP-EXPORT
<output omitted>
R2#sh route-map RMAP-EXPORT

route-map RMAP-EXPORT, permit, sequence 10
Match clauses:
ip address prefix-lists: EXPORT
Set clauses:
extended community RT:10100:101
Policy routing matches: 0 packets, 0 bytes
route-map RMAP-EXPORT, permit, sequence 20
Match clauses:
Set clauses:
extended community RT:10100:100
Policy routing matches: 0 packets, 0 bytes
R2#sh ip prefix-li detail

Prefix-list with the last deletion/insertion: EXPORT
Version 5.1B
67 | P a g e

ip prefix-list EXPORT:
count: 1, range entries: 0, sequences: 5 - 5, refcount: 3
seq 5 permit 8.8.4.4/32 (hit count: 3, refcount: 1)
If we look close enough we can clearly see that the export route-target used on R2 is a different
network than the one we are using on R4 for import route-target (it is a mistyped rt). Let's fix that and
see what happens.
R4
R4(config)#ip vrf Customer_B
R4(config-vrf)#no route-target import 10100:10
R4(config-vrf)#route-target import 10100:100
R4#sh ip bgp vpnv4 all sum
<output omitted>
Neighbor
AS MsgRcvd MsgSent
TblVer
InQ OutQ Up/Down
State/PfxRcd
10.7.7.7
7200
49
0 00:01:57
74
10.8.8.8
7200
49
0 00:01:57
74
192.168.44.1
65505
0 00:01:57
R4
undebug all
As we can see here we are now receiving 74 routes from our RRs each, let's run the sequence of
commands asked for in the beginning of the incident.
R50
R50#traceroute 192.168.44.1 source loopback1
1 123.10.1.5 8 msec 9 msec 9 msec
2 123.10.82.8 [AS 10100] [MPLS: Labels 21/18 Exp 0] 26 msec 26 msec 26 msec
3
*
194.45.67.1 [AS 10100] [MPLS: Labels 17/18 Exp 0] 27 msec *
4 192.168.44.2 [AS 65505] [MPLS: Label 18 Exp 0] 17 msec 17 msec 17 msec

5 192.168.44.1 [AS 65505] 26 msec 26 msec *
68 | P a g e
Version 5.1B

ISP4
ISP4#ping 8.8.8.8
!!!!!
Summary of Changes
R4
conf t
ip vrf Customer_B
no route-target import 10100:100
end
clear ip bgp *
Version 5.1B
69 | P a g e

Incident 8
(2 points)
Administrator users that are connected to the R5 router are not able to use tftp to download the
configuration backup from BB1, which is located at the remote Office.
Fix the problem so that the following tftp session is successful:

R5#copy tftp://192.1.1.2/startup-config null:
Accessing tftp://192.1.1.2/startup-config...
Loading startup-config from 192.1.1.2 (via Tunnel1): !
[OK - 2364 bytes]
2364 bytes copied in 0.110 secs (21491 bytes/sec)
NOTE
While resolving this issue, you are not allowed to create any new interface.
70 | P a g e
Version 5.1B

Solution
Start by verifying if we have reachability to BB1 from R5.
R5
R5#ping 192.1.1.2
.....
According to this result we have no connectivity so we will first need to get this fixed. Let's turn on
some logging on the router see if that can help us identify the cause.
R5
conf t
logging monitor 7
logging buffered 7
logging console 7
*Mar 28 12:26:38.924: %DUAL-5-NBRCHANGE: EIGRP-IPv4 400: Neighbor 172.20.0.1 (Tunnel1)

is down: retry limit exceeded
is up: new adjacency
R1
R1#ping 194.45.67.17 so e0/1
..
Version 5.1B
71 | P a g e

From the logs we can see that we have an EIGRP neighbor flapping, we need to investigate this
further since it looks as if this affects the DMVPN Tunnel which we need to traverse in order to reach
our destination of 192.1.1.1 (as per the diagram).
R1
R1#show dmvpn
==========================================================================
# Ent
UpDn Tm Attrb
----- --------------- --------------- ----- -------- ----1 194.45.67.17
172.20.0.5
NHRP 00:01:44
R1#ping 194.45.67.17 source e0/1

.....
R5
R5#sh dmvpn
==========================================================================
Type:Hub, NHRP Peers:1,
# Ent
UpDn Tm Attrb
----- --------------- --------------- ----- -------- ----1 136.78.90.1
72 | P a g e
172.20.0.1
UP 00:05:07
Version 5.1B

R5#ping 136.78.90.1 source s4/0

.....
R5#sh ip route 136.78.90.0
% Network not in table
There is a definite connectivity issue from R5 to R1 and we need that fixed. Let's check R3's routing
table for the tunnel sources routes.
R3
R3#sh ip route vrf Customer_A
Routing Table: Customer_A
<output omitted>
B
8.8.4.4 [20/0] via 194.45.67.17 (Customer_C), 00:12:32, Serial4/0


172.9.9.9 [20/0] via 194.45.67.17 (Customer_C), 00:12:31, Serial4/0

<output omitted>
B
194.45.67.4/30
[20/0] via 194.45.67.17 (Customer_C), 00:12:31, Serial4/0
194.45.67.16/30
is directly connected (Customer_C), 00:12:31, Serial4/0
R3#sh ip route vrf Customer_A 136.78.90.0

Routing Table: Customer_A
Routing entry for 136.78.90.0/30
Known via "connected", distance 0, metric 0 (connected, via interface)
Version 5.1B
73 | P a g e

* directly connected, via Ethernet0/1
We are not advertising network 136.78.90.0/30 into BGP and that is the fault, let's fix that on R3.
R3
R3(config-router)#address-family ipv4 vrf Customer_A
R3(config-router-af)#network 136.78.90.0 mask 255.255.255.252
R5
R5#sh ip route
<output omitted>

D EX
8.8.4.4 [170/62003200] via 172.17.219.1, 00:21:03, Ethernet0/0


D EX
136.78.90.0 [170/61491200] via 194.45.67.18, 00:00:34, Serial4/0

<output omitted>
NOTE
We might be required to shut / no shut both tunnel ends to get this up and running.
We are now receiving the correct route of 136.78.90.0 and the tunnel interfaces come up. Let's
double check this as well:
74 | P a g e
Version 5.1B

R1
R1#sh dmvpn
==========================================================================
# Ent
UpDn Tm Attrb
----- --------------- --------------- ----- -------- ----1 194.45.67.17
172.20.0.5
UP 00:02:30
R5
R5#sh dmvpn
==========================================================================

# Ent
UpDn Tm Attrb
----- --------------- --------------- ----- -------- ----1 136.78.90.1
172.20.0.1
UP 00:19:05
At this point the DMVPN tunnel is stable but our EIGRP neighbor keeps on flapping, we are also
receiving new error messages in our logs:
R1
is down: Interface PEER-TERMINATION received
is up: new adjacency
*Mar 28 11:57:09.462: %ADJ-5-PARENT: Midchain parent maintenance for IP midchain out
of Tunnel1, addr 172.20.0.5 - looped chain attempting to stack
Version 5.1B
75 | P a g e

These types of error messages "looped chain attempting to stack" are usually caused by route
recursion, meaning that we are advertising the source of the tunnel over the Tunnel. Let's review the
EIGRP config on R5.
R5
R5#sh run | sec eigrp
router eigrp CCIE
!
address-family ipv4 unicast autonomous-system 400
!
topology base
exit-af-topology
network 172.17.218.2 0.0.0.0
network 172.17.219.2 0.0.0.0
network 172.20.0.5 0.0.0.0
network 194.45.67.17 0.0.0.0
<<-- we are advertising the tunnel SRC here
Let's go ahead and fix that on R5 by preventing this network from being advertised over the tunnel
interface.
NOTE
The prefix-list BLK194 already exists on the router, so probably someone must have removed part of
the configs by mistake.
R5
R5(config)#route-map RMAP-CONNECTED-2-EIGRP deny 10
R5(config-route-map)#match ip address prefix-list BLK194
R5(config-route-map)#route-map RMAP-CONNECTED-2-EIGRP permit 20
R5(config-route-map)#!
R5(config-route-map)#router eigrp CCIE
R5(config-router)#address-family ipv4 unicast autonomous-system 400
R5(config-router-af)#topology base
R5(config-router-af-topology)#distribute-list route-map RMAP-CONNECTED-2-EIGRP out
Tunnel1
R5#sh ip ei neighbors
EIGRP-IPv4 VR(CCIE) Address-Family Neighbors for AS(400)
76 | P a g e
Version 5.1B

H
Address
Interface
Hold Uptime
SRTT
(sec)
(ms)
RTO
Seq
Cnt Num
172.20.0.1
Tu1
13 00:02:54
35
1398
4626
172.17.218.1
Et0/1
14 09:49:46
100
10529
172.17.219.1
Et0/0
14 09:49:46
100
7591
194.45.67.18
Se4/0
10 2w0d
100
1456
Our tunnel interface is now up and our EIGRP neighbor is stable, we should now try the TFTP
download.
R5
R5#copy tftp://192.1.1.2/startup-config null:
Accessing tftp://192.1.1.2/startup-config...
Loading startup-config from 192.1.1.2 (via Tunnel1): !
[OK - 2364 bytes]
2364 bytes copied in 0.110 secs (21491 bytes/sec)
Summary of Changes
R3
conf t
router bgp 7200
address-family ipv4 vrf Customer_A
network 136.78.90.0 mask 255.255.255.252
end
R5
conf t
route-map RMAP-CONNECTED-2-EIGRP deny 10
match ip address prefix-list BLK194
route-map RMAP-CONNECTED-2-EIGRP permit 20
router eigrp CCIE

address-family ipv4 unicast autonomous-system 400
topology base
distribute-list route-map RMAP-CONNECTED-2-EIGRP out Tunnel1
Version 5.1B
77 | P a g e

Incident 9
(1 point)
Users traffic from the Starbucks Asia Pacific office must load balance traffic towards the
172.9.9.9 Server.
Fix the issue so that BB3 can ping the server and we have the following output on SW2:
NOTE
You are not allowed to remove any configurations.
78 | P a g e
Version 5.1B

BB3
BB3#ping 172.9.9.9
!!!!!
SW2#sh ip route 172.9.9.9
Known via "eigrp 400", distance 90, metric 307232, type internal
Redistributing via eigrp 400
Last update from 172.17.12.1 on Vlan12, 00:00:02 ago
* 172.17.218.2, from 172.17.218.2, 00:00:02 ago, via Vlan218
Total delay is 2001 microseconds, minimum bandwidth is 10000 Kbit
Reliability 255/255, minimum MTU 1500 bytes
172.17.12.1, from 172.17.12.1, 00:00:02 ago, via Vlan12
Solution
For this incident we will start by verifying the commands in the output, since we don't really have
other information to go with.
BB3
BB3#ping 172.9.9.9
.!!!!
Version 5.1B
79 | P a g e

SW2
* 172.17.218.2, from 172.17.218.2, 10:17:03 ago, via Vlan218
Loading 1/255, Hops 2
We can see that we have reachability and that SW2 is only using one path to reach its destination of
172.9.9.9, let's check to see if the EIGRP database contains two paths.
SW2
SW2#show ip eigrp topo 172.9.9.9 255.255.255.255
EIGRP-IPv4 VR(CCIE) Topology Entry for AS(400)/ID(172.2.2.2) for 172.9.9.9/32
State is Passive, Query origin flag is 1, 1 Successor(s), FD is 281888
Descriptor Blocks:
172.17.218.2 (Vlan218), from 172.17.218.2, Send flag is 0x0
Composite metric is (281888/281632), route is Internal
Vector metric:
Minimum bandwidth is 10000 Kbit
Total delay is 1011 microseconds
Reliability is 255/255
Load is 1/255
Minimum MTU is 1500
Hop count is 2
Vector metric:
Load is 1/255
Minimum MTU is 1500
Hop count is 2
80 | P a g e
Version 5.1B

We have two paths for 172.9.9.9 and we are preferring the path with a feasible distance (FD) of
281888, in order to load balance the route we need to equalize the FD of both paths.
First, we will map the first path's bandwidth and delay values along that path, next we will do the
same for the alternate path, and once we have everything mapped we can easily decide where and
what value we need to change.
Notice that since the bandwidth values are equal for both paths we will only need to equalize the
delay value for each path.
NOTE
The formula is (( 10^7 / Lowest BW in kbps ) + ( sum of delays/10 ) x 256
For the first path (SW2 <> R5 <> R9):

BW = 10,000,000 / 10,000 = 1000
DLY = ( 10 + 1000 + 1.25 ) / 10 = 1011.25 / 10 = 101.125
The path through R5 has a minimum bandwidth of 10,000kbps, and a total delay of 101.125
microseconds.
Composite Metric = ( 1000 + 101.125 ) * 256 = 281888
For the alternate path (SW2 <> SW1 <> R9):

BW = 10,000,000 / 10,000 = 1000
DLY = ( 1000 + 1000 + 1.25 ) / 10 = 2001.25 / 10 = 200.125
The path through R5 has a minimum bandwidth of 10,000kbps, and a total delay of 200.125
microseconds.
Composite Metric = ( 1000 + 200.125 ) * 256 = 307232
Version 5.1B
81 | P a g e

Now that we have the calculations laid out, we can easily see that we only need to manipulate the
delay value of vlan218 (SW2 <> R5) and modify it to be 1000 microseconds. Let's do that and see
what we get.
SW2
SW2(config)#interface vlan218
SW2(config-if)#delay 100
SW2#sh ip ei topo 172.9.9.9 255.255.255.255

State is Passive, Query origin flag is 1, 2 Successor(s), FD is 281888
Descriptor Blocks:
Vector metric:
Load is 1/255
Minimum MTU is 1500
Hop count is 2
Vector metric:
Load is 1/255
Minimum MTU is 1500
Hop count is 2
82 | P a g e
Version 5.1B

Remember, we must match the output exactly as the incident depicts, there are other solutions but
they will not match our given output.
SW2
* 172.17.218.2, from 172.17.218.2, 00:01:44 ago, via Vlan218
172.17.12.1, from 172.17.12.1, 00:01:44 ago, via Vlan12
Summary of Changes
SW2
conf t
interface vlan218
delay 100
Version 5.1B
83 | P a g e

Incident 10
(2 points)
User BB3 is unable to reach the DNS server of 8.8.4.4 in the internet.
Fix the issues so that we have reachability.
The outputs should match the below:
BB3
BB3#ping 8.8.4.4
!!!!!
BB3#traceroute 8.8.4.4
84 | P a g e
Version 5.1B

1 172.17.30.1 0 msec 2 msec 0 msec
2 172.17.217.2 0 msec 0 msec 1 msec
3 194.45.67.6 9 msec 8 msec 9 msec
4 194.45.67.10 [MPLS: Labels 23/32 Exp 0] 30 msec 28 msec 26 msec
6 123.10.1.5 [MPLS: Label 32 Exp 0] 18 msec 20 msec 14 msec
7 123.10.1.6 31 msec 26 msec *
NOTE
This incident is dependent on Incident 6.
Solution
Since the incident did not specify what type of issue the Remote Offices are having, we will need to
take a structured approach to this issue. Since there is an ISP in the middle of the topology and the
entry point into the Regional Office 1 is R5, lets start by looking at the config for R5.
BB3
BB3#ping 8.8.4.4
.....
BB3#traceroute 8.8.4.4 numeric

1 172.17.30.1 1 msec 1 msec 0 msec
2 172.17.217.2 0 msec 1 msec 1 msec
3 194.45.67.6 9 msec 10 msec 9 msec
4
Version 5.1B
85 | P a g e

You can see that traffic stops at R6, so we should go to R6 and review configs.
R6
R6#sh ip route vrf Customer_C
Routing Table: Customer_C
<output omitted>

B
8.8.4.4 [200/0] via 10.2.2.2, 1d03h

10.1.1.0 [90/90112000] via 194.45.67.5, 1d01h, Serial3/0

136.78.90.0 [200/0] via 10.3.3.3, 1d01h
The route exists and it points towards R2, let's see what path we are using to get to R2.
R6
R6#sh ip route 10.2.2.2
Known via "ospf 1", distance 110, metric 95, type inter area
Last update from 194.45.67.26 on Ethernet0/1, 1d11h ago
* 194.45.67.26, from 10.8.8.8, 1d11h ago, via Ethernet0/1
R6#sh mpls forwarding-table 10.2.2.2
Local
Outgoing
Prefix
Bytes Label
Outgoing
Label
Label
or Tunnel Id
Switched
interface
51
No Label
10.2.2.2/32
Et0/1
Next Hop
194.45.67.26
As we can see the traffic to 10.2.2.2 is pointing towards R4 through interface e0/1, which is causing
labeled traffic to go out a non MPLS interface, let's fix that and see what happens next.
R6
R6(config-if)#mpls ip
86 | P a g e
Version 5.1B

BB3
1 172.17.30.1 1 msec 0 msec 1 msec
2 172.17.217.2 0 msec 0 msec 1 msec
3 194.45.67.6 9 msec 10 msec 5 msec
8 123.10.1.6 27 msec *
23 msec
Very well! The fault has been identified, but if we compare the given output with the incident initial
output we can see that the traffic is taking a different path to reach its destination. We can either go
through R4 or R7, let's examine the OSPF interfaces cost values.
R6
R6#sh ip ospf interface br
Interface
PID
Area
IP Address/Mask
Cost
State Nbrs F/C
Lo0
10.6.6.6/32
LOOP
0/0
Et0/1
194.45.67.25/30
10
DR
1/1
Et0/0
194.45.67.9/30
1000
BDR
1/1
At this point we have two possible solutions, either increment the OSPF cost for interface
e0/1 (make it less preferred) or lower the OSPF cost for interface e0/0. Since we know we aren't
supposed to remove configs (unless absolutely necessary), we will choose option 1. Let's modify the
configurations and see the result.
R6
R6(config-if)#ip ospf cost 1500
Version 5.1B
87 | P a g e

BB3
1 172.17.30.1 0 msec 1 msec 0 msec
2 172.17.217.2 0 msec 1 msec 1 msec
3 194.45.67.6 10 msec 9 msec 9 msec
7 123.10.1.6 27 msec *
24 msec
Summary of Changes
R21
conf t
interface e0/1
ip ospf cost 1500
mpls ip
This concludes the Troubleshooting Section of iPexpert's R&S Lab 5 DSG, Volume 2
Copyright iPexpert. All Rights Reserved.
88 | P a g e
Version 5.1B

Lab 5: Diagnostic Section :: Detailed

Solutions
General Rules
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.1B
89 | P a g e

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. Diagnose and help resolve the issue:
Email Chain Between Helpdesk and Customer

From: Bob Mecoy
Sent: Wednesday, January 13, 2015 9:17 AM
To: iPexpert Helpdesk
Subject: Network Failure general packetloss HELP!
Hi,
We came to the office this morning to find that all hell broke loose, users are calling the helpdesk
complaining of slow response times while browsing the internet/ sending emails / accessing the
corporate servers.
We need help to figure out what is causing this issue.
Bob Mecoy
IT Manager, Blade Corp.
Direct: 111-014-014
E-mail: bob.mecoy@blade.com
From: iPexpert Helpdesk

To: Bob Mecoy
Mr. Mecoy,
We would love to assist with this issue. We have opened up an Incident ticket # 187465 for internal
tracking. In order to better help, please provide the following:
1. A network diagram that shows the topology
2. The switches configs for which those users are having issues, make sure to attach the
backbone config.
3. Run several ping commands to key point servers in your network and send us the output.
4. In continue to step #3, please perform a packet capture on the VLAN broadcast domain
where those users reside, no SPAN required.
Once we have the above information, we will review, assign an engineer, and get back to you.
90 | P a g e
Version 5.1B

Dade Murphy
HelpDesk Representative
Office: 999-999-9999 | helpdesk@ipexpert.com
From: Bob Mecoy

To: iPexpert Helpdesk
The information requested has been attached. I am having packetloss throughout the entire
network, around 5-10% packetloss to random users and servers as one. I cannot seem to connect to
all the switches in the management domain. I cannot attach the packet capture file which I took from
my personal computer due to its large size, instead I have provided several statistics outputs from the
sniffing program. Please understand that this is a network down issue and we need assistance asap.
Also, you should be aware that due to the company policies we wont be able to give you remote
access to diagnose our network in real-time.
Bob Mecoy
IT Manager, Blade Corp.
Direct: 111-111-1111
E-mail: jiminy.cricket@acme.com
From: iPexpert Helpdesk

To: Bob Mecoy
Subject: RE: EIGRP Config Tuning HELP!
Mr. Mecoy,
This incident has been assigned to our top tier Network Engineer for review. You should hear
something back very soon. Thank you for your patience.
Dade Murphy
HelpDesk Representative
Office: 999-999-9999 | helpdesk@ipexpert.com
Version 5.1B
91 | P a g e

Router Configuration
SW-BB Config
SW-BB#sh run

!
version 12.2
no service pad
service timestamps debug datetime localtime
service timestamps log datetime localtime
service password-encryption
!
hostname SW-BB
!
logging buffered 16192 debugging
enable secret 5 $1$5Iw1$S5se75dA/IDCdlAyuaGPiQ0
!
username admin privilege 15 secret 5 $1$Wqu.$DqTWHRayMj9RSgqfMN4xc.
aaa new-model
aaa authentication login default group radius local
aaa authentication enable default enable
aaa authorization exec default group radius local
!
aaa session-id common
switch 1 provision ws-c3750g-24ts-1u
switch 2 provision ws-c3750g-24ts-1u
system mtu routing 1500
vtp domain BLADE
vtp mode transparent
udld enable
ip subnet-zero
ip routing
no ip domain-lookup
ip domain-name blade.com
92 | P a g e
Version 5.1B

!
ip dhcp pool voice
network 172.20.1.0 255.255.255.0
option 150 ip 172.20.1.1 172.20.3.1
default-router 172.20.1.253 172.20.1.200
domain-name wr
!
!
spanning-tree mode pvst
spanning-tree loopguard default
spanning-tree portfast bpduguard default
spanning-tree extend system-id
spanning-tree vlan 1,100,200,221,502-503 priority 4096
!
vlan internal allocation policy ascending
!
vlan 2-3
!
vlan 22
name AS400_Replication_vlan
!
vlan 161
name TO_INTERNAL_FW
!
vlan 200
!
vlan 221
name NEW-COM
!
vlan 500
name AP_MGMT
!
vlan 501
name WIFI_USERS
!
vlan 502
name WIFI_INTERNET
!
Version 5.1B
93 | P a g e

vlan 503
name WIFI_HDS
!
interface GigabitEthernet1/0/1
description connect to voice_router
!
description connect to ccm-pub
!
description Line_60MB_To_SAP_Replication
switchport nonegotiate
bandwidth 61440
load-interval 30
!
no switchport
bandwidth 40960
ip address 10.1.0.3 255.255.255.240
ip rip authentication mode md5
ip rip authentication key-chain Troy
load-interval 30
!
switchport voice vlan 200
!
description ##_TO_FW_BLD-1_##
94 | P a g e
Version 5.1B

load-interval 30
no cdp enable
spanning-tree bpdufilter enable
spanning-tree bpduguard enable
!
description ##_TO_FW_BLD-2_##
load-interval 30
no cdp enable
!
description ESX-BLD-NIC1
switchport trunk encapsulation dot1q
switchport trunk native vlan 3
switchport trunk allowed vlan 2,3
switchport mode trunk
load-interval 30
!
!
description ESX-BLD-ILO
!
Version 5.1B
95 | P a g e

description SAPDEV DR Replication Port
!
description ESX-BLD-NIC2
switchport trunk native vlan 3
switchport trunk allowed vlan 2,3
!
load-interval 30
!
description PINEAPP
!
description SAPDEV DR Replication Port
!
speed 1000
duplex full
96 | P a g e
Version 5.1B

!
description To FW_BLD_1 2200-1 (Lan5) for External WiFi Users
!
description HMC
speed 1000
duplex full
!
speed 1000
duplex full
!
description To FW_BLD_2 2200-1 (Lan5) for External WiFi Users
!
description connect to SW_2960_3_Backup
storm-control broadcast level 5.00
Version 5.1B
97 | P a g e

storm-control multicast level 5.00
storm-control action shutdown
!
!
description connect to SW_2960_7
!
!
!
98 | P a g e
Version 5.1B

!
description Connect to BLD_MAIN
load-interval 30
channel-group 1 mode on
!
description Connect to BLD_MAIN
load-interval 30
channel-group 1 mode on
!
interface Vlan1
description vlan to BLD_Old
ip address 10.10.30.12 255.255.255.0
ip rip authentication mode md5
ip rip authentication key-chain Troy
!
interface Vlan2
description Admin
ip address 210.0.35.249 255.255.255.0
!
interface Vlan22
ip address 172.22.0.254 255.255.255.0
shutdown
!
interface Vlan161
ip address 10.20.161.9 255.255.255.0
!
interface Vlan200
description VOICE-VLAN
ip address 172.20.1.253 255.255.255.0
!
Version 5.1B
99 | P a g e

interface Vlan221
description NEW-COM
ip address 172.21.21.1 255.255.255.0
!
ip classless
ip route 172.32.32.32 255.255.255.255 10.20.161.10 track 255
ip route 0.0.0.0 0.0.0.0 10.20.161.10
ip route 1.1.10.0 255.255.255.0 10.1.0.1
ip route 10.1.10.0 255.255.255.0 10.1.0.1
ip route 10.205.1.1 255.255.255.255 10.1.0.1
ip route 81.218.75.162 255.255.255.255 10.20.161.10
ip route 111.0.0.0 255.255.255.0 10.1.0.1
ip route 123.2.2.91 255.255.255.255 10.10.30.254
ip route 123.2.2.95 255.255.255.255 10.10.30.254
ip route 172.17.1.0 255.255.255.0 10.20.161.10
ip route 172.19.0.0 255.255.0.0 10.1.0.1
ip route 172.20.18.0 255.255.255.0 10.1.0.1
ip route 172.21.0.0 255.255.255.0 10.20.161.10
ip route 172.28.2.0 255.255.255.0 10.1.0.1
ip route 192.168.2.0 255.255.255.0 10.1.0.1
ip route 192.168.7.0 255.255.255.0 10.1.0.1
ip route 192.168.46.71 255.255.255.255 10.1.0.1
ip route 192.168.131.0 255.255.255.0 10.1.0.1
ip route 194.90.1.5 255.255.255.255 10.20.161.10
ip route 212.179.42.0 255.255.255.0 10.1.0.1
ip route 212.179.67.62 255.255.255.255 10.1.0.1
no ip http server
ip radius source-interface Vlan1
!
logging trap warnings
logging 123.1.1.89
access-list 5 remark SNMP_Access
access-list 5 permit 123.1.1.89
access-list 5 permit 212.179.20.0 0.0.0.63
access-list 5 deny
any

100 | P a g e
Version 5.1B

access-list 10 remark VTY-ACCESS
access-list 10 deny
any
!
snmp-server community public RO
snmp-server community NMSRO RO 5
snmp-server enable traps license
snmp-server host 123.1.1.89 bladewr
snmp-server host 123.1.1.123 public
radius-server host 123.1.1.16 auth-port 1812 acct-port 1813 key 7 123A0C25134855522E28
radius-server source-ports 1645-1646
!
control-plane
!
banner motd ^C
******************************
Blade Company LTD.
Device name: $hostname
Warning:
Any unauthorized access to
this system is unlawful, and
may be subject to civil and/or
criminal penalties!
******************************
^C
alias exec u undebug all
!
line con 0
logging synchronous
line vty 0 4
access-class 10 in
logging synchronous
Version 5.1B
101 | P a g e

line vty 5 15
access-class 10 in
logging synchronous
!
ntp clock-period 36029257
ntp server 10.10.30.254
end
SW-BB#sh cdp ne
S - Switch, H - Host, I - IGMP, r - Repeater, P - Phone
Device ID
Local Intrfce
Holdtme
ccmpub
Gig 1/0/2
166
SEP001A6D10AD7E
Gig 1/0/5
Capability
Platform
Port ID
VMware
eth0
124
ATA 186
Port 1
170
R S I
WS-C4506
Gig 4/14
170
R S I
WS-C4506
Gig 4/13
Gig 1/0/2
130
VMware
eth0
BLD_MAIN_SW
Gig 1/0/28
175
R S I
WS-C3560- Gig 0/2
BLD_MAIN_SW
Gig 1/0/27
173
R S I
WS-C3560- Gig 0/1
160
Gig 1/0/1
148
R S I
BLD_SW_1
Gig 1/0/24
122
S I
WS-C2960- Gig 0/1
BLD_SW_2
Gig 1/0/22
172
S I
WS-C2960- Gig 0/1
BLD_SW_3
Gig 1/0/21
134
S I
WS-C2960- Gig 0/1
BLD_SW_4
Gig 1/0/26
160
S I
WS-C2960- Gig 0/1
BLD_SW_6
Gig 1/0/25
137
S I
WS-C2960- Gig 0/1
BLD_SW_8
Gig 1/0/23
124
S I
WS-C2960- Gig 0/1
blade_BB.blade.com
Gig 1/0/4
blade_BB.blade.com
Gig 1/0/3
unitypub.blade.com
Presence.blade.com
Gig 1/0/2
VMware
eth0
2811
Fas 0/0
Meir_BLD_Router_VOICE.blade.com
BLD_SW1 Config
BLD_SW_1#sh run
102 | P a g e
Version 5.1B

!
version 12.2
no service pad
service tcp-keepalives-in
service tcp-keepalives-out
service timestamps debug datetime msec localtime show-timezone
service timestamps log datetime msec localtime show-timezone
!
hostname BLD_SW_1
!
boot-start-marker
boot-end-marker
!
logging buffered 16192
enable secret 5 $1$ZD8T$H.4Ha78RwnXai9g8PBaHLM0
!
username admin privilege 15 secret 5 $1$/o/.$j2rdtSMA0iHciiiCXpT9z1
aaa new-model
!
!
!
!
!
udld aggressive
ip subnet-zero
!
no ip domain-lookup
!
!
!
!
!
Version 5.1B
103 | P a g e

!
!
!
!
!
!
interface FastEthernet0/1
!
!
!
104 | P a g e
Version 5.1B

!
description Printer ZEBRA
!
!
!
description PRINTER (210.0.37.202)
Version 5.1B
105 | P a g e

!
!
!
!
106 | P a g e
Version 5.1B

!
!
!
!
!
Version 5.1B
107 | P a g e

!
!
!
!
108 | P a g e
Version 5.1B

!
!
!
!
interface GigabitEthernet0/1
description connect to SW_3750_MAIN
spanning-tree port-priority 16
!
Version 5.1B
109 | P a g e

media-type rj45
!
interface Vlan1
description Management Network
ip address 10.10.30.17 255.255.255.0
no ip route-cache
!
no ip http server
logging 123.1.1.89
access-list 5 deny
any

access-list 10 deny
any

radius-server host 123.1.1.16 auth-port 1812 acct-port 1813 key 7
052805F3D200F175F1D06
!
control-plane
!
banner motd ^C
110 | P a g e
Version 5.1B

*********************************
Blade Company LTD.
Warning:
criminal penalties!
*********************************
^C
!
line con 0
exec-timeout 5 0
line vty 0 4
access-class 10 in
exec-timeout 0 0
password 7 070D245564B18100B03
line vty 5 15
access-class 10 in
exec-timeout 0 0
!
ntp server 10.1.0.1
end
BLD_SW2 Config
BLD_SW_2#sh run

!
version 12.2
no service pad
service tcp-keepalives-in
service tcp-keepalives-out
service timestamps debug datetime msec localtime show-timezone
service timestamps log datetime msec localtime show-timezone
Version 5.1B
111 | P a g e

!
hostname BLD_SW_2
!
boot-start-marker
boot-end-marker
!
logging buffered 16192
enable secret 5 $1$ZD8T$H.4Ha78RwnXai9g8PBaHLM0
!
username admin privilege 15 secret 5 $1$/o/.$j2rdtSMA0iHciiiCXpT9z1
aaa new-model
!
!
!
!
!
udld aggressive
ip subnet-zero
!
no ip domain-lookup
!
!
!
!
!
!
!
!
112 | P a g e
Version 5.1B

!
!
!
!
!
!
!
Version 5.1B
113 | P a g e

description Printer ZEBRA
!
!
!
description PRINTER (210.0.37.202)
!
114 | P a g e
Version 5.1B

!
!
!
!
Version 5.1B
115 | P a g e

!
!
!
!
116 | P a g e
Version 5.1B

!
!
!
!
!
Version 5.1B
117 | P a g e

!
!
!
description connect to SW_3750_MAIN
!
media-type rj45
!
interface Vlan1
description Management Network
ip address 10.10.30.17 255.255.255.0
118 | P a g e
Version 5.1B

no ip route-cache
!
no ip http server
logging 123.1.1.89
access-list 5 deny
any

access-list 10 deny
any

radius-server host 123.1.1.16 auth-port 1812 acct-port 1813 key 7
052805F3D200F175F1D06
!
control-plane
!
banner motd ^C
*********************************
Blade Company LTD.
Warning:
criminal penalties!
Version 5.1B
119 | P a g e

*********************************
^C
!
line con 0
exec-timeout 5 0
line vty 0 4
access-class 10 in
exec-timeout 0 0
password 7 070D2455364B18100B03
line vty 5 15
access-class 10 in
exec-timeout 0 0
!
ntp server 10.1.0.1
end
Network Topology
120 | P a g e
Version 5.1B

Packet Capture Information
Version 5.1B
121 | P a g e

Using the information provided, select the most logical cause of the issue from the list below
(multiple answers):
BLD_SW1 seems to be causing the issues.

SW_BB is undergoing a broadcast storm.
Everything seems to be ok, further information is required.
The storm-control statements used on the switches are causing network flaps.
There seems to be a broadcast storm affecting the entire network.
A bad uplink between the remote switch and the SW-BB is the reason.
A massive packet rate of traffic seems to be broadcast to every user on the LAN.
According to the sniffer conversation statistics output provided choose the mac-addresses which
should be further investigated:
28:c0:da:30:f6:81
00:00:00:00:fd:00
00:00:00:00:fe:01
122 | P a g e
Version 5.1B

08:00:27:00:A4:99
80:86:F2:6B:0D:DB
IPv4mcast_05
ff:ff:ff:ff:ff:ff
Vmware:ca:7d:f4
Cisco_45:9a:24
Cisco_45:9a:20
00:27:0d:45:9a:24
Solution
Using the information provided, select the most logical cause of the issue from the list below
(multiple answers):

SW_BB is undergoing a broadcast storm.
Everything seems to be ok, further information is required.
The storm-control statements used on the switches are causing network flaps.
There seems to be a broadcast storm affecting the entire network.
A bad uplink between the remote switch and the SW-BB is the reason.
A massive packet rate of traffic seems to be broadcast to every user on the LAN.
Explanation
Looking at the outputs provided by the client, we see the configuration of the switches does contain
some sort of storm-control restriction, but there is no indication that the storm-control is hitting the
threshold set and thus dropping traffic. Also, the pcap statistics show a count of 3,993,827 Million
packets received in a time interval of 172seconds (around 3min) which is very high for traffic destined
to users. According to that we can immediately assume that some sort of broadcast/multicast storm
is undergoing throughout the network.
Version 5.1B
123 | P a g e

According to the sniffer conversation statistics output provided choose the mac-addresses which
should be further investigated:
28:c0:da:30:f6:81
00:00:00:00:fd:00
00:00:00:00:fe:01
08:00:27:00:A4:99
80:86:F2:6B:0D:DB
IPv4mcast_05
ff:ff:ff:ff:ff:ff
Vmware:ca:7d:f4
Cisco_45:9a:24
Cisco_45:9a:20
00:27:0d:45:9a:24
Explanation
From looking at the Statistics outputs we can clearly see that 00:27:0d:45:9a:24 and also
00:00:00:00:fd:00 have the highest packet count of 1.9 million packets which is very extreme for
internal traffic originating from one address.
124 | P a g e
Version 5.1B

Ticket 2
(3 point)
You have been away to a Cisco training for the past week. While you were out, your company added a
new supplier using BGP protocol. Your co-worker configured the entire thing and everything is
working properly. Now they have decided that an IPv6 BGP peer is necessary on top of this
connection, unfortunately he configured the entire thing in the NLRI format (legacy syntax).
You've been asked to modify the BGP configuration to support multi address-families without
removing any configurations and explicitly NO down time. Review the information provided for a
better understanding of the issue.
Router Configuration
RTR-SUP#sh run

!
version 15.2
service timestamps debug datetime msec
service timestamps log datetime msec
no service password-encryption
!
hostname RTR-SUP
!
boot-start-marker
boot-end-marker
!
!
enable password cps
!
no aaa new-model
clock timezone CET 1 0
mmi polling-interval 60
no mmi auto-configure
no mmi pvc
mmi snmp-timeout 180
!
!
ip multicast-routing
Version 5.1B
125 | P a g e

ip cef
no ipv6 cef
!
multilink bundle-name authenticated
!
!
!
redundancy
!
!
interface Loopback0
ip address 123.16.16.16 255.255.255.255
ip pim sparse-mode
!
ip address 203.3.16.2 255.255.255.252
!
ip address 123.20.1.2 255.255.255.248
ip pim sparse-mode
!
ip address 123.20.1.17 255.255.255.248
ip pim sparse-mode
!
no ip address
!
no ip address
!
no ip address
!
no ip address
!
no ip address
126 | P a g e
Version 5.1B

!
no ip address
shutdown
!
no ip address
shutdown
!
no ip address
shutdown
!
no ip address
shutdown
!
interface Serial5/0
no ip address
shutdown
!
interface Serial5/1
no ip address
shutdown
!
interface Serial5/2
no ip address
shutdown
!
router bgp 65248
neighbor 123.20.1.18 password IPX
neighbor 123.20.1.18 ebgp-multihop 255
Version 5.1B
127 | P a g e

neighbor 123.20.1.18 route-map BGP-OUT out
!
ip forward-protocol nd
!
!
no ip http server
no ip http secure-server
!
!
ip prefix-list BGP-OUT seq 5 permit 0.0.0.0/0 le 32
!
route-map BGP-OUT permit 10
match ip address prefix-list BGP-OUT
!
!
!
control-plane
!
!
!
!
!
!
!
line con 0
exec-timeout 0 0
privilege level 15
logging synchronous
line aux 0
line vty 0 4
password cisco
login
transport input none
!
!
end
RTR-SUP#sh ip bgp sum

128 | P a g e
Version 5.1B

Neighbor
3.3.3.20
64782
AS MsgRcvd MsgSent
0
TblVer
1
InQ OutQ Up/Down

0
0 never
Idle
State/PfxRcd
10.10.10.20
65489
0 never
Idle
123.20.1.18
8005
0 00:02:44
Using the information provided, choose the best option to accomplish this task:
Schedule a maintenance window, quickly remove existing bgp config and replace with new
multi-af config.
Fortunately, IOS provides a feature to automate the transition in the form of a simple
command: bgp upgrade-cli, which is run at the global under configuration. No down time is
required.
command: bgp upgrade-cli, which is run at the global under configuration. This cannot be
accomplished without any downtime.
command: bgp upgrade-cli, which is run under the bgp process configuration. No down time
is required.
command: bgp upgrade-cli, which is run under the bgp process configuration. This cannot be
Version 5.1B
129 | P a g e

Solution
Using the information provided, choose the best option to accomplish this task:
Schedule a maintenance window, quickly remove existing bgp config and replace with new
multi-af config.
command: bgp upgrade-cli, which is run at the global under configuration. No down time is
required.
command: bgp upgrade-cli, which is run at the global under configuration. This cannot be
command: bgp upgrade-cli, which is run under the bgp process configuration. No down time
is required.
command: bgp upgrade-cli, which is run under the bgp process configuration. This cannot be
Explanation
Fortunately, IOS provides a feature to automate the transition in the form of a simple command: bgp
upgrade-cli. We can issue this command under BGP process configuration to automatically convert
our legacy syntax.
The command bgp upgrade-cli does not disrupt active adjacencies, and the multiprotocol extensions
are backward compatible so that the configuration on individual routers can be upgraded
independently.
130 | P a g e
Version 5.1B

After converting to the multiprotocol configuration syntax, we can create additional address families:
RTR-SUP
RTR-SUP(config)#router bgp 65248
RTR-SUP(config-router)#bgp upgrade-cli
You are about to upgrade to the hierarchical AFI syntax of bgp commands
Are you sure ? [yes]: yes

RTR-SUP(config-router)#^Z
RTR-SUP#sh ip bgp sum
Neighbor
AS MsgRcvd MsgSent
TblVer
InQ OutQ Up/Down
State/PfxRcd
3.3.3.20
64782
0 never
Idle
10.10.10.20
65489
0 never
Idle
123.20.1.18
8005
0 00:03:28
RTR-SUP#sh run | sec bgp

router bgp 65248
neighbor 123.20.1.18 password IPX
neighbor 123.20.1.18 ebgp-multihop 255
!
address-family ipv4
neighbor 123.20.1.18 route-map BGP-OUT out
exit-address-family
Once we finish the migration to the multi address-family mode we can easily configure the ipv6
address-family.
Version 5.1B
131 | P a g e

Ticket 3
(3 points)
Users are complaining and have opened a trouble ticket that has been assigned to you. They are
complaining that they cannot reach a specific remote office (R2 / R3), but can reach the Main office
(R1). Obviously there is a connectivity issue of some sort. Help identify the cause and choose a
solution.
R1 Outputs
R1#sh ip ei ne
IP-EIGRP neighbors for process 100
H
Address
Interface
Hold Uptime
SRTT
(sec)
(ms)
RTO
Seq
Cnt Num
10.10.10.3
Fa0/0
14 00:00:09
212
1272
10.10.10.2
Fa0/0
14 00:01:08 1041
5000
R1#sh ip route
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
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

C
100.0.0.0/8 is a summary, 00:02:17, Null0
20.0.0.0/8 [90/409600] via 10.10.10.2, 00:02:02, FastEthernet0/0

10.10.10.0/24 is directly connected, FastEthernet0/0
10.0.0.0/8 is a summary, 00:02:17, Null0
R1#debug ip eigrp
*Mar 1 00:26:25.343: IP-EIGRP(Default-IP-Routing-Table:100): route installed for
100.0.0.0 (Summary)
132 | P a g e
Version 5.1B

10.0.0.0 (Summary)
*Mar 1 00:26:25.683: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 100: Neighbor 10.10.10.3
(FastEthernet0/0) is up: new adjacency
*Mar
1 00:26:27.307: %LINK-3-UPDOWN: Interface FastEthernet0/0, changed state to up
*Mar
1 00:26:28.303: %SYS-5-CONFIG_I: Configured from console by console
*Mar 1 00:26:28.307: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/0,

changed state to up
*Mar 1 00:26:28.855: IP-EIGRP(Default-IP-Routing-Table:100): Processing incoming
UPDATE packet
UPDATE packet
UPDATE packet
*Mar 1 00:26:30.727: IP-EIGRP(Default-IP-Routing-Table:100): Int 20.0.0.0/8 M 409600
- 256000 153600 SM 128256 - 256 128000
20.0.0.0 ()
*Mar 1 00:26:30.735: IP-EIGRP(Default-IP-Routing-Table:100): 100.100.100.0/24 - don't
advertise out FastEthernet0/0
*Mar 1 00:26:30.735: IP-EIGRP(Default-IP-Routing-Table:100): 10.10.10.0/24 - do
*Mar 1 00:26:30.739: IP-EIGRP(Default-IP-Routing-Table:100): Int 100.0.0.0/8 metric
128256 - 256 128000
*Mar 1 00:26:30.739: IP-EIGRP(Default-IP-Routing-Table:100): 10.0.0.0/8 - poison
UPDATE packet
- 256000 153600 SM 128256 - 256 128000
30.0.0.0 ()
409600 - 256000 153600
409600 - 256000 153600
UPDATE packet
*Mar 1 00:26:31.023: IP-EIGRP(Default-IP-Routing-Table:100): Int 100.0.0.0/8 M
4294967295 - 256000 4294967295 SM 4294967295 - 256000 4294967295
Version 5.1B
133 | P a g e

128256 - 256 128000
409600 - 256000 153600
409600 - 256000 153600
UPDATE packet
4294967295 - 256000 4294967295 SM 4294967295 - 256000 4294967295
R2 Outputs
R2#sh ip ei ne
H
Address
10.10.10.1
Interface
Fa0/0
Hold Uptime
SRTT
(sec)
(ms)
13 00:01:18
48
RTO
Seq
Cnt Num
288
R2#sh ip route

20.0.0.0/8 is a summary, 00:04:05, Null0

134 | P a g e
Version 5.1B

C
10.0.0.0/8 is a summary, 00:04:05, Null0
R2#debug ip eigrp
(FastEthernet0/0) is down: holding time expired
UPDATE packet
128256 - 256 128000
UPDATE packet
- 256000 153600 SM 128256 - 256 128000
100.0.0.0 ()
409600 - 256000 153600
UPDATE packet
4294967295 - 256000 4294967295 SM 4294967295 - 256000 4294967295
UPDATE packet
4294967295 - 256000 4294967295 SM 4294967295 - 256000 4294967295
R3 Outputs
R3#sh ip ei ne
H
Address
10.10.10.1
Version 5.1B
Interface
Fa0/0
Hold Uptime
SRTT
(sec)
(ms)
11 00:00:26
164
RTO
Seq
Cnt Num
984
135 | P a g e

R3#sh ip ei ne
H
Address
Interface
Hold Uptime
SRTT
(sec)
(ms)
10.10.10.2
Fa0/0
11 00:00:26 1283
10.10.10.1
Fa0/0
11 00:00:26
164
RTO
Seq
Cnt Num
5000
984
R3#sh ip route

10.0.0.0/8 is a summary, 00:04:05, Null0

30.0.0.0/8 is a summary, 00:04:05, Null0
R3#debug ip eigrp
UPDATE packet
128256 - 256 128000
136 | P a g e
Version 5.1B

UPDATE packet
4294967295 - 256000 4294967295 SM 4294967295 - 256000 4294967295
UPDATE packet
- 256000 153600 SM 128256 - 256 128000
100.0.0.0 ()
409600 - 256000 153600
UPDATE packet
4294967295 - 256000 4294967295 SM 4294967295 - 256000 4294967295
EIGRP Topology
Version 5.1B
137 | P a g e

Assuming R2 and R3 are configured correctly and using the information provided, choose the device
that contains the configuration error and then choose the best method to fix the issue:
Device with Issue:
Area of Issue:
R2
Enable split-horizon on R1
R3
PC1
PC2
Disable split-horizon on R3
PC3
R1
Enable next-hop-self on R1
Disable next-hop-self on R1
Disable auto-summary on R1
Enable auto-summary on R2
Disable auto-summary on All
138 | P a g e
Version 5.1B

Solution
Device with Issue:
Area of Issue:
R2
R3
PC1
PC2
PC3
R1
Enable next-hop-self on R1
Disable next-hop-self on R1
Disable auto-summary on R1
Disable auto-summary on All
Explanation
First, we can clearly see that R1 has two neighborships, whereas R2 and R3 only have a
neighborship with R1. Next, when we look in the route table of both R2 and R3 we can see a
missing route to either one, also for R1 we see all routes. This means only one thing, splithorizon is enabled, meaning that information about the routing for a particular network is
never sent back in the direction from which it was received.
This concludes the Diagnostic Section of iPexpert's R&S Lab 5 DSG, Volume 2
Version 5.1B
139 | P a g e

Lab 5: Configuration Section :: Detailed

Solutions
General Rules
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.
140 | P a g e
Version 5.1B

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 task.
Version 5.1B
141 | P a g e

Diagram 5.5: Layer 2
142 | P a g e
Version 5.1B

Diagram 5.6: IPv4
Version 5.1B
143 | P a g e

Diagram 5.7: BGP
144 | P a g e
Version 5.1B

Diagram 5.8: DMVPN
Version 5.1B
145 | P a g e

Diagram 5.9: IPv6
146 | P a g e
Version 5.1B

Diagram 5.10: MCAST
Version 5.1B
147 | P a g e

Diagram 5.11: MP-BGP
148 | P a g e
Version 5.1B

Section 1.0: Layer 2 Technologies

Task 1.1:
Layer 2 Ports
(12 points)
(2 points)
Using the given diagrams, configure the switch-to-switch links as dot1q trunks.
Make sure that the trunk configuration is not negotiated.
Ensure that the following unused ports on all four switches are shutdown and configured as
access ports in vlan 999:
o
e3/2, e4/0 and e4/1 are unused on SW1 and SW2
e4/0 and e4/1 are unused on SW3 and SW4
All unused ports on all switches are to be shutdown and configured as access ports in vlan 999 as
well.
Configure the networks of San Francisco office (ASN 23456) and Hawaii office (ASN 34567) as per
the following requirements:
o
Using the given diagrams, configure the switch-to-switch links as dot1q trunks on
interfaces e2/0 and e2/1.
Make sure that the trunk configuration is not negotiated.
All unused ports on all switches are to be shutdown and configured as access in VLAN
999.
Solution
Create the trunk links between SW1, SW2, SW3, and SW4. Allow the VLANs required across the
trunks (also according to task 1.3). Use static non-negotiable Dot1Q encapsulation. Start by shutting
down the relevant interfaces to avoid issues which might arise otherwise.
SW1-SW4 (paste to all)

SWX(config)#interface range e3/0-1,e5/0-1
SWX(config-if-range)#shutdown
SWX(config-if-range)#switchport
SWX(config-if-range)#switchport trunk encapsulation dot1q
SWX(config-if-range)#switchport mode trunk
Version 5.1B
149 | P a g e

SWX(config-if-range)#sw trunk allowed vlan
23,26,37,61,17,64,75,45,10,20,30,40,50,1,999
SWX(config-if-range)#interface ra e3/0-1,e5/0-1
SWX(config-if-range)#no sh
Next, we should shutdown and configure VLAN 999 on unused ports as instructed:
SW1, SW2
SWX(config)#interface range e4/0-1,e3/2
SWX(config-if-range)#switchport mode access
SWX(config-if-range)#switchport access vlan 999
SW3, SW4
SWX(config)#interface range e4/0-1
SWX(config-if-range)#switchport mode access
SWX(config-if-range)#switchport access vlan 999
Next, let's complete the configurations for switches 5-8.
SW5, SW6
SWX(config-if-range)#sw trunk allowed vlan 155,156,56,135,126,111,1,999
SWX(config-if-range)#no shutdown
150 | P a g e
Version 5.1B

SW7, SW8
SWX(config-if-range)#switchport trunk allowed vlan 77,88,222,1,999
SWX(config-if-range)#no shutdown
SW1
SW1(config)#interface range e0/0,e1/0,e1/3,e2/0-3,e3/3
SW1(config-if-range)#shutdown
SW1(config-if-range)#switchport mode access
SW1(config-if-range)#switchport access vlan 999
SW1(config-if-range)#interface range e4/2-3,e5/2-3
SW2
SW2(config)#interface range e0/0,e1/0-1,e2/0,e2/2-3
SW2(config-if-range)#interface range e3/3,e4/2-3,e5/2-3
SW3
SW3(config)#interface range e0/0-3,e1/2-3,e2/0-3
SW3(config-if-range)#interface range e3/2-3,e4/2-3,e5/2-3
Version 5.1B
151 | P a g e

SW4
SW4(config)#interface range e0/0-1,e1/0-1,e2/0,e2/2-3
SW5
SW5(config)#interface range e2/2-3,e0/0,e0/3,e1/1-3
SW6
SW6(config)#interface range e2/2-3,e0/0,e0/3,e1/1-3
152 | P a g e
Version 5.1B

SW7
SW8
Verification
Lets perform some verifications now, we should receive an output saying that the 802.1q interfaces
have been statically set for trunking.
SW1
SW1#show int trunk
Port
Mode
Encapsulation
Status
Native vlan
Et3/0
on
802.1q
trunking
Et3/1
on
802.1q
trunking
Et5/0
on
802.1q
trunking
Et5/1
on
802.1q
trunking
Port
Vlans allowed on trunk
Et3/0
1,10,17,20,23,26,30,37,40,45,50,61,64,75,999
Et3/1
1,10,17,20,23,26,30,37,40,45,50,61,64,75,999
Et5/0
1,10,17,20,23,26,30,37,40,45,50,61,64,75,999
Et5/1
1,10,17,20,23,26,30,37,40,45,50,61,64,75,999
Version 5.1B
153 | P a g e

SW2
SW2#show int trunk
Port
Mode
Encapsulation
Status
Native vlan
Et3/0
on
802.1q
trunking
Et3/1
on
802.1q
trunking
Et5/0
on
802.1q
trunking
Et5/1
on
802.1q
trunking
Port
Et3/0
1,10,17,20,23,26,30,37,40,45,50,61,64,75,999
Et3/1
1,10,17,20,23,26,30,37,40,45,50,61,64,75,999
Et5/0
1,10,17,20,23,26,30,37,40,45,50,61,64,75,999
Et5/1
1,10,17,20,23,26,30,37,40,45,50,61,64,75,999
SW3
SW3#show int trunk
Port
Mode
Encapsulation
Status
Native vlan
Et3/0
on
802.1q
trunking
Et3/1
on
802.1q
trunking
Et5/0
on
802.1q
trunking
Et5/1
on
802.1q
trunking
Port
Et3/0
1,10,17,20,23,26,30,37,40,45,50,61,64,75,999
Et3/1
1,10,17,20,23,26,30,37,40,45,50,61,64,75,999
Et5/0
1,10,17,20,23,26,30,37,40,45,50,61,64,75,999
Et5/1
1,10,17,20,23,26,30,37,40,45,50,61,64,75,999
SW4
SW4#show int trunk
Port
154 | P a g e
Mode
Encapsulation
Status
Native vlan
Version 5.1B

Et3/0
on
802.1q
trunking
Et3/1
on
802.1q
trunking
Et5/0
on
802.1q
trunking
Et5/1
on
802.1q
trunking
Port
Et3/0
1,10,17,20,23,26,30,37,40,45,50,61,64,75,999
Et3/1
1,10,17,20,23,26,30,37,40,45,50,61,64,75,999
Et5/0
1,10,17,20,23,26,30,37,40,45,50,61,64,75,999
Et5/1
1,10,17,20,23,26,30,37,40,45,50,61,64,75,999
SW5
SW5#show int trunk
Port
Mode
Encapsulation
Status
Native vlan
Et2/0
on
802.1q
trunking
Et2/1
on
802.1q
trunking
Port
Et2/0
1,56,111,126,135,155-156,999
Et2/1
1,56,111,126,135,155-156,999
SW6
SW6#show int trunk
Port
Mode
Encapsulation
Status
Native vlan
Et2/0
on
802.1q
trunking
Et2/1
on
802.1q
trunking
Port
Et2/0
1,56,111,126,135,155-156,999
Et2/1
1,56,111,126,135,155-156,999
Version 5.1B
155 | P a g e

SW7
SW7#show int trunk
Port
Mode
Encapsulation
Status
Native vlan
Et2/0
on
802.1q
trunking
Et2/1
on
802.1q
trunking
Port
Et2/0
1,77,88,222,999
Et2/1
1,77,88,222,999
SW8
SW8#show int trunk
Port
Mode
Encapsulation
Status
Native vlan
Et2/0
on
802.1q
trunking
Et2/1
on
802.1q
trunking
Port
Et2/0
1,77,88,222,999
Et2/1
1,77,88,222,999
Task 1.2:
Switch Administration
(2 points)
Use VTP domain name "CCIERS".

Secure all VTP updates with an MD5 of the ASCII password "iPexpert?"
SW1 should always be the VTP master. All other switches should be set to client.
Do not configure any VLANs on SW2, SW3, or SW4. They should learn the VLANs from the VTP
server.
Configure the network of San Francisco office (ASN 23456) as per the following requirements:
o
156 | P a g e
SW6 must be the vtp server and SW5 must be the vtp client.
Version 5.1B

Use VTP domain name "CCIE".
Configure the network of Hawaii office (ASN 34567) as per the following requirements:
o
SW7 and SW8 should be configured as VTP Transparent.
Use VTP domain name "CCIERS".
Solution
First configure the VTP domain and password. You should notice that the password we have been
asked to configure contains the "?" character, this character can't be just pasted into the
configuration and will require from us to use the Ctrl+V key combination before typing the "?"
character.
NOTE
Notice that we are concentrating the entire tasks configuration as one complete list of commands
this is done for efficiency purposes.
We will make sure to set SW1&SW6 as the VTP server, all others should be clients.
SW7 and SW8 should be VTP transparent.
SW1
SW1(config)#vtp version 2
SW1(config)#vtp domain CCIERS
SW1(config)#vtp password iPexpert?
SW1(config)#vtp mode server
SW2, SW3, SW4

SWX(config)#conf t
SWX(config)#vtp domain CCIERS
SWX(config)#vtp mode client
SWX(config)#vtp password iPexpert?
Version 5.1B
157 | P a g e

SW5
SW5(config)#vtp domain CCIE
SW5(config)#vtp mode client
SW6
SW6(config)#vtp domain CCIE
SW6(config)#vtp version 2
SW6(config)#vtp mode server
SW7, SW8
SWX(config)#vtp domain CCIERS
SWX(config)#vtp mode transparent
Verification
Lets confirm we have everything configured properly. SW1 should be the VTP server, all others
should be VTP Clients.
SW1
SW1#sh vtp status
VTP Version capable
: 1 to 3
VTP version running
: 2
VTP Domain Name
: CCIERS
VTP Pruning Mode
: Disabled
VTP Traps Generation
: Disabled
Device ID
: aabb.cc00.6500
Configuration last modified by 172.17.111.111 at 5-1-15 07:07:21

Local updater ID is 172.17.111.111 on interface Lo0 (first layer3 interface found)
Feature VLAN:
-------------VTP Operating Mode
: Server
SW1#show vtp password

VTP Password: iPexpert?
158 | P a g e
Version 5.1B

SW2
SW2#sh vtp status
VTP Version capable
: 1 to 3
VTP version running
: 2
VTP Domain Name
: CCIERS
VTP Pruning Mode
: Disabled
: Disabled
Device ID
: aabb.cc00.6600
Feature VLAN:
: Client

SW3
SW3#sh vtp status
VTP Version capable
: 1 to 3
VTP version running
: 2
VTP Domain Name
: CCIERS
VTP Pruning Mode
: Disabled
: Disabled
Device ID
: aabb.cc00.6700
Feature VLAN:
: Client

SW4
SW4#sh vtp status
VTP Version capable
Version 5.1B
: 1 to 3
159 | P a g e

VTP version running
: 2
VTP Domain Name
: CCIERS
VTP Pruning Mode
: Disabled
: Disabled
Device ID
: aabb.cc00.6800
Feature VLAN:
: Client

SW6 should be the VTP server, SW5 should be VTP Client.
SW5
SW5#sh vtp status
VTP Version capable
: 1 to 3
VTP version running
: 2
VTP Domain Name
: CCIE
VTP Pruning Mode
: Disabled
: Disabled
Device ID
: aabb.cc00.6900
Feature VLAN:
: Client
SW6
SW6#sh vtp status
VTP Version capable
: 1 to 3
VTP version running
: 2
VTP Domain Name
: CCIE
VTP Pruning Mode
: Disabled
: Disabled
Device ID
: aabb.cc00.6a00
160 | P a g e
Version 5.1B

Local updater ID is 101.33.10.2 on interface Vl56 (lowest numbered VLAN interface
found)
Feature VLAN:
: Server
SW7-8 should be both VTP transparent, meaning they should forward all VTP without actually
modifying their own VLAN database.
SW7
SW7#sh vtp status
VTP Version capable
: 1 to 3
VTP version running
: 1
VTP Domain Name
: CCIERS
VTP Pruning Mode
: Disabled
: Disabled
Device ID
: aabb.cc00.6b00

Feature VLAN:
: Transparent
SW8
SW8#sh vtp status
VTP Version capable
: 1 to 3
VTP version running
: 1
VTP Domain Name
: CCIERS
VTP Pruning Mode
: Disabled
: Disabled
Device ID
: aabb.cc00.6c00

Feature VLAN:
Version 5.1B
: Transparent
161 | P a g e

Task 1.3:
Layer 2 VLANs
(3 points)
Configure the necessary VLANs.

Using the Layer 2 diagram, configure all interfaces connected to a router as access ports, unless
connected to a router with sub-interfaces, these connections must use 802.1q trunking.
Only allow the VLANs required across the trunk links.

Do not modify any pre-configured subinterfaces, VLANs, or 802.1q trunks.
Solution
Configure the necessary VLANs according to the diagram and port mapping we have done, make sure
not to forget VLANs 1 and 999. Also, we will limit interfaces which are configured as trunk ports to
allow only the required VLANs.
NOTE
We only need to have the VLANs configured on SW1, it should then be propagated to SW2-SW4 via VTP
we have already set up at the previous task.
SW1
SW1(config)#vlan 23,26,37,61,17,64,75,45,10,20,30,40,50,1,999
NOTE
We only need to have the VLANs configured on SW6, it should then be propagated to SW5 via VTP we
have already set up at the previous task.
SW5, SW6
SW6(config)#vlan 155,156,56,135,126,111,1,999
SWX(config-if-range)#switchport trunk allowed vlan 155,156,56,135,126,111,1,999
SW7-8
SWX(config)#vlan 77,88,222,1,999
SWX(config-vlan)#interface range e2/0-1
SWX(config-if-range)#switchport trunk allowed vlan 77,88,222,1,999
162 | P a g e
Version 5.1B

Now, we need to configure the switchports that connect to the routers interfaces:
SW1
SW1(config)#default interface e0/1
SW1(config-if)#switchport mode access
SW1(config-if)#default interface e0/2
SW1(config-if)#interface range e0/1-3,e1/1-2
SW1(config-if-range)#no sh
SW2
SW2(config-if)#switchport trunk encapsulation dot1q
SW2(config-if)#switchport mode trunk
SW2(config-if)#sw trunk all vlan 26,10,20,30,40,50
Version 5.1B
163 | P a g e

SW2(config-if)#switchport trunk allowed vlan 37,10,20,30,40,50
SW2(config-if)#switchport trunk allowed vlan ad 10,20,30,40,50
SW2(config-if)#interface range e0/1-3,e1/2-3,e2/1
SW2(config-if-range)#no shutdown
SW3
SW3(config-if)#interface range e1/0-1
SW4
SW4(config-if)#switchport trunk allowed vlan ad 64,26
164 | P a g e
Version 5.1B

SW4(config-if)#switchport trunk allowed vlan ad 37,75
SW4(config-if)#switchport trunk allowed vlan ad 10,20,30,40,50
SW4(config-if)#interface range e1/3-3,e2/1
SW5
SW5(config-if)#interface ra e0/1-2,e1/0
SW6
Version 5.1B
165 | P a g e

SW7
SW8
166 | P a g e
Version 5.1B

Verification
This task can be verified by connecting to all devices in the network and pinging the broadcast ip
address (basic CCNA method), this will reveal which connections are correctly set up and help quickly
identify faults. The expected result for each device is receiving a reply from all directly connected
interfaces to that device.
All Routers/Switches
Device#ping 255.255.255.255 repeat 2
See example below:
R1
R1#ping 255.255.255.255 repeat 2
Reply to request 0 from 101.33.1.30, 5 ms

R1#
R2
R2#ping 255.255.255.255 repeat 2

Version 5.1B
167 | P a g e

Task 1.4:
Spanning-Tree
(3 points)
Use the spanning-tree protocol which maintains one STP instance per VLAN and converges
rapidly.
SW1 should be the Root bridge for all odd VLANs and the secondary root bridge for all even
VLANs.
SW2 should be the primary Root bridge for all even VLANs and the secondary root bridge for all
odd VLANs.
SW6 should be the Root bridge for all odd VLANs and the secondary root bridge for all even
VLANs.
SW5 should be the primary Root bridge for all even VLANs and the secondary root bridge for all
odd VLANs.
Statically set the primary and secondary Root bridges to protect against other switches becoming
the root bridge.
All access ports should move to forwarding state immediately after coming up.
Use a single command to accomplish this on each device.
Enable port state recovery for storm-control errors, and also modify the interval to be half of the
default value.
Configure inter switch ports of SW1-SW4 in order to enforce the Root bridge placement in the
network.
Verify all directly connected devices can ping each other in Hawaii, San Francisco, and New York
HQ.
Solution
The first assignment in this task is to configure Rapid-PVST which enables us to maintain one STP
instance per vlan. SW1 should be the primary root bridge for all odd VLANs and the secondary root
168 | P a g e
Version 5.1B

bridge for all even VLANs. SW2 should be the primary root bridge for all even VLANs and the
secondary root bridge for all odd VLANs. We will also address the root bridge priority and set it
statically to ensure the switches roles in our network domain. Notice we do not need to make any
changes for SW3-4. We will also address the requirement to transition all ports to forwarding state
(portfast) immediately after coming up using a single command.
SW1
SW1(config)#spanning-tree mode rapid
SW1(config)#spanning-tree vlan 23,37,61,17,75,45,1,999 priority 0
SW1(config)#spanning-tree vlan 26,64,10,20,30,40,50 priority 4096
SW1(config)#spanning-tree portfast default
Next, to protect the root bridges from being replaced by some other switch in the network (besides
having set the switch priority) we shall use the mechanism of root guard which ensures that when we
receive a superior STP bridge BPDUs on a root guard-enabled port, root guard moves this port to a
root-inconsistent STP state. In this way, the root guard enforces the position of the root bridge.
SW1
SW1(config)#interface range e0/1-3,e1/1-2
SW1(config-if-range)#spanning-tree guard root
SW2
SW2(config)#spanning-tree vlan 23,37,61,17,75,45,1,999 priority 4096
SW2(config)#spanning-tree vlan 26,64,10,20,30,40,50 priority 0
SW2(config)#interface range e0/1-3,e1/2-3,e2/1
SW2(config-if-range)#spanning-tree guard root
SW3-SW4
SWX(config)#spanning-tree mode rapid
SWX(config)#spanning-tree portfast default
Next, SW6 should be the primary root bridge for all odd VLANs and the secondary root bridge for all
even VLANs. SW5 should be the primary root bridge for all even VLANs and the secondary root bridge
for all odd VLANs. We will also address the root bridge priority and set it statically to ensure the
switches roles in our network domain.
Version 5.1B
169 | P a g e

SW6
SW6(config)#spanning-tree vlan 155,135,1,111,999 priority 0
SW6(config)#spanning-tree vlan 156,56,126 priority 4096
SW5
SW5(config)#spanning-tree vlan 155,135,1,111,999 priority 4096
SW5(config)#spanning-tree vlan 156,56,126 priority 0
Configure SW7, and SW8 for Rapid-PVST mode only.
SW7, SW8
We have been asked to also enable error recovery for storm-control while setting the interval to half
of the default value (300sec) for all 8 switches:
SW1, SW2, SW3, SW4, SW5, SW6, SW7, SW8

SWX(config)#errdisable recovery interval 150
SWX(config)#errdisable recovery cause storm-control
Verification
First, we will need to verify that the spanning-tree mode was configured as required. Second, we will
check to see who is the Root Bridge for each switch domain. Notice that SW1 is the root bridge for all
EVEN VLANs, and SW2 is the root bridge for the ODD VLANs. We can save time and confirm this from
the point of view of a non root bridge Switch in the domain so it will display who is the root bridge.
SW4
SW4#show spanning-tree root
Vlan
Root ID
Root
Hello Max Fwd
Cost
Time
Age Dly
---------------- -------------------- --------- ----- --- ---
170 | P a g e
Root Port
------------
Version 5.1B

VLAN0001
1 aabb.cc00.6500
200
20
15
Et5/0
VLAN0010
10 aabb.cc00.6600
100
20
15
Et5/0
VLAN0017
17 aabb.cc00.6500
200
20
15
Et5/0
VLAN0020
20 aabb.cc00.6600
100
20
15
Et5/0
VLAN0023
23 aabb.cc00.6500
200
20
15
Et5/0
VLAN0026
26 aabb.cc00.6600
100
20
15
Et5/0
VLAN0030
30 aabb.cc00.6600
100
20
15
Et5/0
VLAN0037
37 aabb.cc00.6500
200
20
15
Et5/0
VLAN0040
40 aabb.cc00.6600
100
20
15
Et5/0
VLAN0045
45 aabb.cc00.6500
200
20
15
Et5/0
VLAN0050
50 aabb.cc00.6600
100
20
15
Et5/0
VLAN0061
61 aabb.cc00.6500
200
20
15
Et5/0
VLAN0064
64 aabb.cc00.6600
100
20
15
Et5/0
VLAN0075
75 aabb.cc00.6500
200
20
15
Et5/0
VLAN0999
999 aabb.cc00.6500
200
20
15
Et5/0
SW1
SW1#sh span
VLAN0001
Spanning tree enabled protocol rstp
Root ID
Priority
Address
aabb.cc00.6500
This bridge is the root

Hello Time
Bridge ID
2 sec
Max Age 20 sec
Priority
Address
aabb.cc00.6500
Forward Delay 15 sec
(priority 0 sys-id-ext 1)
Hello Time
2 sec
Aging Time
300 sec
Max Age 20 sec
SW2
SW2#sh span
VLAN0001
Spanning tree enabled protocol rstp
Root ID
Version 5.1B
Priority
Address
aabb.cc00.6500
171 | P a g e

Cost
100
Port
13 (Ethernet3/0)
Hello Time
Bridge ID
2 sec
Max Age 20 sec
Priority
4097
Address
aabb.cc00.6600
Hello Time
2 sec
Aging Time
300 sec
(priority 4096 sys-id-ext 1)
Max Age 20 sec
Next, quickly verify that we have successfully enabled port-fast globally. We can verify this using
several methods, below is our preferred method. The command should be run on all switches for
proper verification.
SW1-8
SW1#show spanning-tree detail | include portfast
The port is in the portfast mode by default
Next, we will verify that the errdisable recovery was set to 150sec and that storm-control is indeed
enabled. The below output depicts only SW1, for the LAB you will have to run this on every Switch.
SW1
SW1#show errdisable recovery | inc storm|Tim
ErrDisable Reason
Timer Status
storm-control
Enabled
Timer interval: 150 seconds
Finally verify connectivity. In this case only output from R2 is shown:
R2
R2#ping 10.10.29.1
!!!!!
172 | P a g e
Version 5.1B

R2#ping 101.33.1.2
!!!!!
R2#ping 101.33.1.6
!!!!!
Task 1.5:
WAN Switching
(2 points)
The WAN links must rely on a layer 2 protocol that supports link negotiation and authentication.
The provider connections with R24 and R25 must use ip address negotiation and be
authenticated using a 3-Way Handshake with ISP6.
The one-way authentication must be initiated by ISP6:

o
R24 must use the username "IPX-24" and the password "IPXKEY"
Solution
Configure PPP encapsulation on R20, R24, and R25 along with the correct username/password as
specified in the task.
R20
R20(config)#interface s2/2
R20(config-if)#encapsulation ppp
R20(config-if)#ppp chap hostname IPX-20
R20(config-if)#ppp chap password IPXKEY
Version 5.1B
173 | P a g e

R24
R25
We only need to configure the ppp encapsulation, chap hostname, and password that will be sent,
since this is a one-way authentication.
Verification
The verification for this task can be done using the command "who" or "show users", which displays
the current connected users and helps us easily check if PPP is properly working.
R20
R20#show users
Line
*
User
0 con 0
Host(s)
Idle
idle
00:00:00
Location
Interface
User
Mode
Idle
Peer Address
Se2/2
ISP6
Sync PPP
00:00:01 195.13.206.2
R24
R24#who
Line
*
User
0 con 0
Host(s)
Idle
idle
00:00:00
Location
Interface
User
Mode
Idle
Peer Address
Se2/0
ISP6
Sync PPP
00:00:02 193.190.24.1
R24#sh ppp all

Stage
Peer Address
Peer Name
------------ --------------------- -------- --------------- -------------------Se2/0
174 | P a g e
LCP+ IPCP+ CDPCP+
LocalT
193.190.24.1
ISP6
Version 5.1B

R25
R25#show users
Line
*
User
0 con 0
Host(s)
Idle
idle
00:00:00
Location
Interface
User
Mode
Idle
Peer Address
Se2/0
ISP6
Sync PPP
00:00:00 193.190.25.1
R25#sh ppp int s2/0

PPP Serial Context Info
------------------Interface
: Se2/0
PPP Serial Handle: 0xB9000001

PPP Handle
: 0x40000001
SSS Handle
: 0x38000001
AAA ID
: 14
Access IE
: 0x50000001
SHDB Handle
: 0x0
State
: Up
Last State
: Binding
Last Event
: LocalTerm
PPP Session Info

---------------Interface
: Se2/0
PPP ID
: 0x40000001
Phase
: UP
Stage
: Local Termination
Peer Name
: ISP6
Peer Address
: 193.190.25.1
Control Protocols: LCP[Open] IPCP[Open] CDPCP[Open]

Session ID
: 1
AAA Unique ID
: 14
SSS Manager ID
: 0x38000001
SIP ID
: 0xB9000001
PPP_IN_USE
: 0x11
Se2/0 LCP: [Open]
Version 5.1B
175 | P a g e

Our Negotiated Options
Se2/0 LCP:
MagicNumber 0xBC3C23B1 (0x0506BC3C23B1)
Peer's Negotiated Options

Se2/0 LCP:
Se2/0 LCP:
MagicNumber 0xBC3C1F1A (0x0506BC3C1F1A)
Se2/0 IPCP: [Open]

Se2/0 IPCP:
Address 193.190.25.25 (0x0306C1BE1919)

Se2/0 IPCP:
Address 193.190.25.1 (0x0306C1BE1901)
Se2/0 CDPCP: [Open]

NONE
NONE
176 | P a g e
Version 5.1B

Section 2.0: IP Routing

Task 2.1:
(35 points)
OSPF in New York HQ
(2 points)
Configure the OSPF process id 12345 and set the router-id as the interface Loopback0 on all
routers.
Add all interfaces to the OSPF process except the links that leave the Autonomous System.
o
Do not use the ip ospf command under interface configuration.
Restrict OSPF to these interfaces without using the passive-interface feature.
All addresses in the OSPF domain should be reachable by all devices in the AS.
The switches must not participate in routing at all.
Make sure the loopback interfaces are advertised properly with the original mask.
When finished, R1 must see the following OSPF routes in the routing table without modifying the
cost on any link:
R1
R1#sh ip route ospf
O
101.33.1.0/30 [110/65555] via 101.33.1.30, 00:00:02, Ethernet0/1

[110/65555] via 101.33.1.25, 00:00:02, Ethernet0/0
101.33.1.4/30 [110/65545] via 101.33.1.25, 00:00:02, Ethernet0/0
101.33.1.8/30 [110/65545] via 101.33.1.30, 00:00:02, Ethernet0/1
101.33.1.12/30 [110/65545] via 101.33.1.25, 00:00:02, Ethernet0/0
101.33.1.16/30 [110/65545] via 101.33.1.30, 00:00:02, Ethernet0/1
101.33.1.20/30 [110/65555] via 101.33.1.30, 00:00:02, Ethernet0/1

[110/65555] via 101.33.1.25, 00:00:02, Ethernet0/0
172.17.2.0/24 [110/65546] via 101.33.1.25, 00:00:02, Ethernet0/0
172.17.3.0/24 [110/65546] via 101.33.1.30, 00:00:02, Ethernet0/1
172.17.4.0/24 [110/65546] via 101.33.1.25, 00:00:02, Ethernet0/0
172.17.5.0/24 [110/65546] via 101.33.1.30, 00:00:02, Ethernet0/1
172.17.6.0/24 [110/65536] via 101.33.1.25, 00:00:02, Ethernet0/0
172.17.7.0/24 [110/65536] via 101.33.1.30, 00:00:02, Ethernet0/1
Version 5.1B
177 | P a g e

Solution
We need to first acknowledge all of the requirements for this task. First, lets consider the basic OSPF
configuration first, and then we will work through the advanced configuration steps. This
configuration will be in Area 0. External Links will not be added to OSPF. The router-id will be set as
the loopback0 interface.
To restrict the OSPF process to only the interfaces specified, we will use very specific network
commands under the OSPF process. Also, the task specifically asks that loopback 0 interfaces should
be advertised with their original masks by using the OSPF network type point-to-point.
R1
R1(config)#router ospf 12345
R1(config-router)#router-id 172.17.1.1
R1(config-router)#network 101.33.1.26 0.0.0.0 area 0
R1(config-router)#interface loopback0
R1(config-if)#ip ospf network point-to-point
R2
R3
178 | P a g e
Version 5.1B

R4
R5
R6
R7
Version 5.1B
179 | P a g e

We have been asked to remove R1 from the forwarding path for OSPF. We need to treat R1 as a stub
router without manually changing any OSPF costs. We can achieve this using the OSPF graceful
shutdown feature. This allows us to set the highest metric possible for all paths, thus forcing traffic
not pass through R1.
R1
R1(config-router)#max-metric router-lsa
Verification
Lets perform a connectivity test of all subnets at New York HQ. We can do this with a TCL script.
Below, there is an example from R1, but you will need to do this on all devices at New York HQ.
R1
tclsh
foreach i {
172.17.2.2
172.17.3.3
172.17.4.4
172.17.5.5
172.17.6.6
172.17.7.7
} { ping $i repeat 1}
tclquit
[Results removed...]
NOTE
Don't forget to properly exit the tcl shell, Cisco uses scripting for grading, while not using the tclquit
command we might leave some scripts in memory which might impact those results.
180 | P a g e
Version 5.1B

The output of the OSPF routes after the configuration change on R1:
R1
R1#sh ip route ospf
O
101.33.1.0/30 [110/65555] via 101.33.1.30, 00:00:02, Ethernet0/1

[110/65555] via 101.33.1.25, 00:00:02, Ethernet0/0
101.33.1.4/30 [110/65545] via 101.33.1.25, 00:00:02, Ethernet0/0
101.33.1.8/30 [110/65545] via 101.33.1.30, 00:00:02, Ethernet0/1
101.33.1.12/30 [110/65545] via 101.33.1.25, 00:00:02, Ethernet0/0
101.33.1.16/30 [110/65545] via 101.33.1.30, 00:00:02, Ethernet0/1
101.33.1.20/30 [110/65555] via 101.33.1.30, 00:00:02, Ethernet0/1

[110/65555] via 101.33.1.25, 00:00:02,
Ethernet0/0
O
172.17.2.0/24 [110/65546] via 101.33.1.25, 00:00:02, Ethernet0/0
172.17.3.0/24 [110/65546] via 101.33.1.30, 00:00:02, Ethernet0/1
172.17.4.0/24 [110/65546] via 101.33.1.25, 00:00:02, Ethernet0/0
172.17.5.0/24 [110/65546] via 101.33.1.30, 00:00:02, Ethernet0/1
172.17.6.0/24 [110/65536] via 101.33.1.25, 00:00:02, Ethernet0/0
172.17.7.0/24 [110/65536] via 101.33.1.30, 00:00:02, Ethernet0/1
Task 2.2:
EIGRP in AS 23456
(3 points)
Create EIGRP ASN 23456 in San Francisco.

Configure all interfaces for EIGRP except those connected to other Autonomous Systems.
Ensure that no interfaces advertise hello messages other than the ones specified.
All EIGRP adjacencies should be authenticated using MD5 and the password CCIERock$ (no
quotations).
o
Use only one command to accomplish this.
All subnets included in EIGRP ASN 23456 should be reachable from every device in the AS,
including the Loopback interface of each router.
Using a single command only on one switch, ensure that R11 installs two equal-cost route for the
following routes:
Version 5.1B
181 | P a g e

o
vlan 135
R13's interface Loopback0
Do not change the interface bandwidth on any physical interface in ASN 23456.
Solution
First, note here that EIGRP wide metrics are required. The only configuration that is able to use EIGRP
wide metrics is the named EIGRP config. This is a key observation as it changes the looks of our
configurations. Second, notice that EIGRP is using MD5 authentication (using one command). Also, as
with our earlier OSPF configuration, we need to be very specific in our network statements since we
are asked to ensure no hellos are advertised on undesired interfaces.
R11
R11(config)#key chain EIGRPKEY
R11(config-keychain)#key 1
R11(config-keychain-key)#key-string CCIERock$
R11(config-keychain-key)#router eigrp CCIE
R11(config-router)#address ipv4 unicast autonomous 23456
R11(config-router-af)#network 101.33.10.5 0.0.0.0
R11(config-router-af)#af-interface default
R11(config-router-af-interface)#authentication mode md5
R11(config-router-af-interface)#authentication key-chain EIGRPKEY
R12
182 | P a g e
Version 5.1B

R13
All devices in the AS have been asked to participate, so SW5 and SW6 will also be configured for
EIGRP. Furthermore, we need to modify EIGRP using a single command on one switch alone to ensure
R11 installs two equal-cost routes for VLAN 135 and R13's loopback interface (no bandwidth metric
can be used to achieve this).
SW5
SW5(config)#key chain EIGRPKEY
SW5(config-keychain)#key 1
SW5(config-keychain-key)#key-string CCIERock$
SW5(config-keychain-key)#router eigrp CCIE
SW5(config-router)#address ipv4 unicast autonomous 23456
SW5(config-router-af)#network 101.33.10.1 0.0.0.0
SW5(config-router-af)#af-interface default
SW5(config-router-af-interface)#authentication mode md5
SW5(config-router-af-interface)#authentication key-chain EIGRPKEY
Version 5.1B
183 | P a g e

SW6
SW6(config)#key chain EIGRPKEY
SW6(config-keychain)#key 1
SW6(config-keychain-key)#key-string CCIERock$
SW6(config-keychain-key)#router eigrp CCIE
SW6(config-router)#address ipv4 unicast autonomous 23456
SW6(config-router-af)#af-interface default
SW6(config-router-af-interface)#authentication mode md5
SW6(config-router-af-interface)#authentication key-chain EIGRPKEY
To get two cost-equal routes from R11's point of view, we will need to modify SW6's interconnecting
VLAN to SW5 (VLAN 56) which, according to our calculations, requires a value of 30msec on this
interface. To identify the values needed we shall use these commands:
NOTE
See highlighted fields, these are the key values to look at.
R11
R11#sh ip ei topo 101.33.10.12 255.255.255.252
State is Passive, Query origin flag is 1, 1 Successor(s), FD is 131727360, RIB is
1029120
Descriptor Blocks:
101.33.10.10 (Ethernet0/1), from 101.33.10.10, Send flag is 0x0
Vector metric:
Total delay is 1020000000 picoseconds
Load is 1/255
Minimum MTU is 1500
Hop count is 2
184 | P a g e
Version 5.1B

Vector metric:
Load is 1/255
Minimum MTU is 1500
Hop count is 1
R11#sh ip ei topo 172.17.13.0 255.255.255.0

State is Passive, Query origin flag is 1, 1 Successor(s), FD is 131809280, RIB is
1029760
Descriptor Blocks:
Vector metric:
Load is 1/255
Minimum MTU is 1500
Hop count is 3
Vector metric:
Load is 1/255
Minimum MTU is 1500
Hop count is 2
Version 5.1B
185 | P a g e

Notice, we only have one route installed in our RIB table.
R11
R11#sh ip
route 101.33.10.12

Last update from 101.33.10.10 on Ethernet0/1, 00:00:50 ago
* 101.33.10.10, from 101.33.10.10, 00:00:50 ago, via Ethernet0/1
R11#sh ip route 172.17.13.13

Let's modify the delay value.
SW6
SW6(config)#interface vlan 56
SW6(config-if)#delay 3
186 | P a g e
Version 5.1B

Verification
First, we should have seen log messages showing that our neighbor relationships are up. Lets verify
that they are using MD5 encryption. We can do this using the following show command:
R11
R11#sh ip ei int de | inc Et|Authen|Se
Et0/0
Authentication mode is md5,

Et0/1
0/0
0/0
421
0/2
2104
654
0/2
3268
key-chain is "EIGRPKEY"
0/0
0/0
R11#sh key chain

Key-chain EIGRPKEY:
key 1 -- text "CCIERock$"
accept lifetime (always valid) - (always valid) [valid now]
send lifetime (always valid) - (always valid) [valid now]
Now, lets verify full reachability with another TCL script. The example shows the test from R11, but
you will need to verify from all devices.
R11
tclsh
foreach i {
172.17.11.11
172.17.12.12
172.17.13.13
172.17.115.115
172.17.116.116
} { ping $i r 1}
tclquit
[Results partialy Truncated]
Version 5.1B
187 | P a g e

We need to check that we actually do have two cost-equal routes for the networks asked in the task;
we will do that using the following commands from R11's point of view:
R11
R11#sh ip route 172.17.13.13
101.33.10.6, from 101.33.10.6, 00:00:59 ago, via Ethernet0/0
R11#sh ip route 101.33.10.12

101.33.10.6, from 101.33.10.6, 00:01:00 ago, via Ethernet0/0
188 | P a g e
Version 5.1B

Task 2.3:
EIGRP in AS 34567
(2 points)
The EIGRP Autonomous System number is 34567.

Add all interfaces in Hawaii to the EIGRP process except those connected to other Autonomous
Systems.
o
Use any method to accomplish this requirement.
For all three routers R18, R19, R20 use EIGRP with 64bit metrics.
SW7 and SW8 are Layer 3 switches and must configure EIGRP.
Advertise the loopback 0 interface of all devices in EIGRP AS 34567 as internal routes.
Solution
Similar to AS 23456, this autonomous system also requires EIGRP named configuration. Looking at
the task, there are not any special requirements. But, we should notice that R18 and R19 are on a
shared segment with SW7, in the same way we also have R18 and R20 on a shared segment with
SW8. This means that in order to ensure proper routes advertisement between these peers we need
to disable the EIGRP split horizon feature to allow sending out an update on the interface on which
that update came. We will also prepare ourselves for the DMVPN task 3.2 which will also require split
horizon disabled.
R18
R18(config)#router eigrp CCIE
R18(config-router-af)#af-interface e0/0
R18(config-router-af-interface)#no split-horizon
R18(config-router-af-interface)#af-interface e0/1
Version 5.1B
189 | P a g e

R19
R20
R20(config-router-af-interface)#af-interface tun0
SW7
SW7(config)#router eigrp CCIE
SW7(config-router)#address-family ipv4 unicast autonomous-system 34567
SW7(config-router-af)#af-interface vlan 77
SW7(config-router-af-interface)#no split-horizon
SW8
SW8(config)#router eigrp CCIE
SW8(config-router)#address-family ipv4 unicast autonomous-system 34567
SW8(config-router-af)#af-interface vlan 88
SW8(config-router-af-interface)#no split-horizon
190 | P a g e
Version 5.1B

Verification
Lets take a look at the routing table of R18 and verify it is learning all of the routes it should be.
R18
o - ODR, P - periodic downloaded static route, H - NHRP, l - LISP
a - application route
+ - replicated route, % - next hop override

D
101.33.20.16/29 [90/1536000] via 101.33.20.10, 1d19h, Ethernet0/1

[90/1536000] via 101.33.20.2, 1d19h, Ethernet0/0
172.17.19.0/24 [90/1024640] via 101.33.20.2, 1d19h, Ethernet0/0
172.17.20.0/24 [90/1024640] via 101.33.20.10, 1d19h, Ethernet0/1
172.17.117.0/24 [90/3584000] via 101.33.20.3, 1d19h, Ethernet0/0
172.17.118.0/24 [90/3584000] via 101.33.20.11, 1d19h, Ethernet0/1
Now, lets do the final verification and test connectivity to all addresses using a TCL script. The
example is from R20, but you will need to perform this test from all devices.
R20
R20#tclsh
R20(tcl)#foreach i {
+>172.17.19.19
+>172.17.20.20
+>172.17.18.18
+>172.17.117.117
+>172.17.118.118
+>} { ping $i repeat 1}
Version 5.1B
191 | P a g e

!
!
!
!
!
R20(tcl)#tclquit
Task 2.4:
EIGRP in Australia and Mexico AS 34567
(2 points)
Enable EIGRP 34567 in Australia and Mexico.

Advertise the loopback 24 interface of R24 as an external route.
Advertise the loopback 25 interface of R25 as an external route.
Use the pre-configured DMVPN tunnel interface of R20, R24, and R25 to establish the EIGRP
relationships.
R20 is the DMVPN hub, R24, R25 are spokes.

Ensure that R24 and R25 receive also a default route.
192 | P a g e
Do not use redistribution to accomplish this.
Do not use static routing to accomplish this.

Version 5.1B

Solution
This task is dependent on several other tasks (2.7, and 3.3-4), first we will need to have the BGP
operational for AS 6666 which is required to get the underlay working for full connectivity between
ASN 65423, and ASN 65420. On top of that, we will need to bring up the DMVPN tunnels between
R20 <> R24, and R25. Once that is complete we will be able to complete this task and configure the
overlay EIGRP protocol.
NOTE
With that said, since we have read the entire workbook at the beginning of the lab we should have
identified the need to skip this task and move forward to solving these later tasks 2.7, and then right
after 3.3-4, only then will we get back to this task.
Next, we can now do the configuration required for the overlay.
R20
R20(config-router-af-interface)#af-interface tun0
R24
R24(config)#route-map CONNECTED-2-EIGRP permit 10
R24(config-route-map)#match interface Lo24
R24(config-router-af-topology)#redistribute connected route-map CONNECTED-2-EIGRP
Version 5.1B
193 | P a g e

R25
R25(config)#route-map CONNECTED-2-EIGRP per 10
R25(config-route-map)#match interface Lo25
R25(config-router-af-topology)#redistribute connected route-map CONNECTED-2-EIGRP
In the above configuration, we are only allowing the loopback interface routes to be redistributed
into EIGRP.
Verification
NOTE
You will not be able to match the verification outputs below until you finish other tasks (BGP and
DMVPN).
We need to make sure our peerings are up and that we are sending prefixes. We will not be learning
prefixes yet as no other BGP peerings have been established up to this point. We also need to verify
that the filtering is working properly.
R11
Neighbor
AS MsgRcvd MsgSent
TblVer
InQ OutQ Up/Down
172.17.12.12
65444
8888
8891
103
172.17.13.13
65444
8910
8904
103
0 5d14h
188.166.153.3
3333
8901
8914
103
0 5d14h
89
State/PfxRcd
0 5d14h
Now lets take a look at the prefixes that are being advertised to verify our filtering,
we should allow all Class A 172.0.0.0/8 prefixes.
194 | P a g e
Version 5.1B

R11
R11#sh ip bgp neighbors 188.166.153.3 advertised-routes
BGP table version is 103, local router ID is 172.17.11.11
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
*>
172.17.11.0/24
0.0.0.0
*>
172.17.12.0/24
*>
Metric LocPrf Weight Path

0
32768 ?
101.33.10.10
1029760
32768 ?
172.17.13.0/24
101.33.10.6
1045120
32768 ?
*>
172.17.115.0/24
101.33.10.6
3599360
32768 ?
*>
172.17.116.0/24
101.33.10.10
3584000
32768 ?
Total number of prefixes 5
R20
R20#sh ip eigrp neighbors
EIGRP-IPv4 VR(CCIE) Address-Family Neighbors for AS(34567)
H
Address
Interface
Hold Uptime
SRTT
(sec)
(ms)
RTO
Seq
Cnt Num
192.168.20.25
Tu0
14 00:03:43
16
132
192.168.20.24
Tu0
13 00:04:46
16
132
101.33.20.17
Et0/0
11 06:48:05
100
59
101.33.20.11
Et0/1
13 06:48:27
100
15
101.33.20.9
Et0/1
10 07:04:21
100
69
Version 5.1B
195 | P a g e

R24
R24#sh ip ro 0.0.0.0
Known via "eigrp 34567", distance 170, metric 56883200, candidate default path
Last update from 192.168.20.20 on Tunnel0, 00:05:35 ago
* 192.168.20.20, from 192.168.20.20, 00:05:35 ago, via Tunnel0
Route tag 3333
Task 2.5:
BGP in AS 65333
(4 points)
Use loopback 0 as the BGP router-id on all routers.

R1 must be the IPv4 route-reflector for ASN 65333.
IPv4 unicast family address must be disabled by default in all BGP routers.
R6 and R7 must not establish any BGP session at any time.
Configure all iBGP peerings using the loopback 0 interface.
Use peer group name "IBGP" for all internal neighbor relationship on R1.
Configure eBGP VPNv4 and IPv4 peerings between New York and AS 1111, AS 2222, and AS 4444.
o
Use the directly connected interfaces to form these peerings.
Advertise the loopback0 interface to these eBGP peers via redistribution.

o
Do not advertise any other prefixes.
Configure eBGP between iPExperts New York and RPT according to the following requirements:
196 | P a g e
Version 5.1B

o
R9 is a CE router and uses eBGP to connect to management services that are provided by
the PE routers R2 and R3.
R9 must establish a separate eBGP peering with both R2 and R3 for every VRF.
R9 must advertise the following prefixes to all of its BGP peers:

o
10.0.0.0/8 summary-only
172.0.0.0/8 summary-only
R9 must advertise a default route to all of its BGP peers except for INET.
Solution
Configure BGP as outlined in the task. First, we need to use Loopback0 as the BGP router-id. Second,
we have to disable IPv4 for BGP by default. Third, we need to use peer-group called IBGP on R1.
Fourth, we must use the loopback0 interfaces of each device to create all IBGP peerings. Finally, R1
should be configured as route-reflector.
Further, we need to configure eBGP VPNv4 and IPv4 peerings with our Service Providers ASes: 1111,
2222, 4444 using directly connected interfaces. Last, we need to advertise the loopback0
interface(only) to these eBGP peers via redistribution.
R1
R1(config-router)#bgp router-id 172.17.1.1
R1(config-router)#no bgp default ipv4-unicast
R1(config-router)#neighbor IBGP peer-group
R1(config-router)#neighbor IBGP remote-as 65333
R1(config-router)#neighbor IBGP update-source lo0
R1(config-router)#neighbor 172.17.2.2 peer-group IBGP
R1(config-router)#address-family ipv4 unicast
R1(config-router-af)#neighbor IBGP route-reflector-client
R1(config-router-af)#neighbor 172.17.2.2 activate
Version 5.1B
197 | P a g e

R2
R2(config)#route-map CONNECTED-2-BGP permit 10
R2(config-route-map)#match interface loopback0
R2(config-route-map)#router bgp 65333
R2(config-router)#neighbor 172.17.1.1 update-source lo0
R2(config-router-af)#neighbor 172.17.1.1 next-hop-self
R2(config-router-af)#redistribute connected route-map CONNECTED-2-BGP
R2(config-router-af)#address-family vpnv4
R3
198 | P a g e
Version 5.1B

R4
R5
Next, we will configure R9 in AS 64520 to peer with R2 and R3 while taking into consideration the
requirements:
First, establish a separate eBGP peering for every VRF - we will also need to do the actual VRF
configurations according to the diagram. Second, advertise a default-route to all except for VRF INET.
Third, advertise 10.0.0.0/8 and 172.0.0.0/8 summaries while suppressing all others.
Version 5.1B
199 | P a g e

R3
R3(config)#ip vrf BLUE
R3(config-vrf)# rd 64520:20
R3(config-vrf)# route-target export 20:20
R3(config-vrf)# route-target import 20:20
R3(config-vrf)#!
R3(config-vrf)#ip vrf GREEN
R3(config-vrf)#!
R3(config-vrf)#ip vrf INET
R3(config-vrf)#!
R3(config-vrf)#ip vrf RED
R3(config-vrf)#!
R3(config-vrf)#ip vrf YELLOW
!
R3(config-if)#ip address 101.33.1.2 255.255.255.252
R3(config-if)#interface e0/1.10
R3(config-subif)#encapsulation dot1q 10
R3(config-subif)#ip vrf for GREEN
R3(config-subif)#ip address 10.10.39.3 255.255.255.0
R3(config-subif)#interface e0/1.20
R3(config-subif)#ip vrf for BLUE
200 | P a g e
Version 5.1B

R3(config-subif)#ip vrf for RED
R3(config-subif)#ip vrf for YELLOW
R3(config-subif)#ip vrf for INET
R3(config-subif)#interface s2/3
R3(config-if)#ip add 92.82.32.3 255.255.255.0
!
R3(config-router)#address-family ipv4 vrf BLUE
R3(config-router-af)#neighbor 10.20.39.1 remote-as 64520
R3(config-router-af)#address-family ipv4 vrf GREEN
R3(config-router-af)#address-family ipv4 vrf INET
R3(config-router-af)#address-family ipv4 vrf RED
R3(config-router-af)#address-family ipv4 vrf YELLOW
R2
Version 5.1B
201 | P a g e

R2(config-vrf)#!
R2(config-vrf)#!
R2(config-vrf)#ip vrf INET
R2(config-vrf)#!
R2(config-vrf)#!
R2(config-vrf)#ip vrf YELLOW
!
R2(config-if)#ip address 101.33.1.1 255.255.255.252
R2(config-if)#interface e0/1.10
R2(config-subif)#ip vrf for GREEN
R2(config-subif)#ip vrf for BLUE
R2(config-subif)#ip vrf for RED
R2(config-subif)#ip vrf for YELLOW
202 | P a g e
Version 5.1B

R2(config-subif)#ip vrf for INET
R2(config-subif)#interface s2/2
R2(config-if)#ip add 92.82.12.2 255.255.255.0
!
R2(config-router)#address-family ipv4 vrf BLUE
R2(config-router-af)#address-family ipv4 vrf GREEN
R2(config-router-af)#address-family ipv4 vrf INET
R2(config-router-af)#address-family ipv4 vrf RED
R2(config-router-af)#address-family ipv4 vrf YELLOW
R9
Version 5.1B
203 | P a g e

R9(config-router)#network 10.10.29.0 mask 255.255.255.0
R9(config-router-af)#aggregate-address 172.0.0.0 255.0.0.0 summary-only
R9(config-router-af)#aggregate-address 10.0.0.0 255.0.0.0 summary-only
The quickest way of advertising a default-route to all but VRF INET is using the default-originate
neighbor specific command, let's configure:
R9(config-router-af)#neighbor 10.10.29.2 default-originate
Verification
We should now see a default route and other prefixes coming from the RTP network, make sure to
verify the output for both routers. Lets take a look at the routing table of R2 and R3.
204 | P a g e
Version 5.1B

R3
R3#sh bgp all summary
For address family: IPv4 Unicast
86 network entries using 12040 bytes of memory
164 path entries using 13120 bytes of memory
11/7 BGP path/bestpath attribute entries using 1584 bytes of memory
2 BGP rrinfo entries using 48 bytes of memory
8 BGP AS-PATH entries using 192 bytes of memory
5 BGP extended community entries using 120 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 27104 total bytes of memory
BGP activity 105/5 prefixes, 188/10 paths, scan interval 60 secs
Neighbor
AS MsgRcvd MsgSent
TblVer
InQ OutQ Up/Down
State/PfxRcd
92.82.32.2
2222
61
47
87
0 00:25:22
83
172.17.1.1
65333
42
36
87
0 00:25:27
80
For address family: VPNv4 Unicast

Neighbor
10.10.39.1
64520
18
10.20.39.1
64520
19
16
25
10.30.39.1
64520
19
16
25
10.40.39.1
64520
18
16
25
Version 5.1B
AS MsgRcvd MsgSent
16
TblVer
25
InQ OutQ Up/Down

0
State/PfxRcd
0 00:11:17
0 00:11:15
0 00:11:12
0 00:11:14
205 | P a g e

Neighbor
10.50.39.1
64520
AS MsgRcvd MsgSent
18
16
TblVer
25
InQ OutQ Up/Down

0
0 00:11:21
State/PfxRcd
2
92.82.32.2
2222
61
47
25
0 00:25:23
For address family: VPNv4 Multicast
For address family: MVPNv4 Unicast
R2
R2#sh bgp all | be VPNv4

Network
Next Hop
Route Distinguisher: 9999:50 (default for vrf INET)

*>
10.0.0.0
10.50.29.1
0 64520 i
*>
172.0.0.0/8
10.50.29.1
0 64520 i
Route Distinguisher: 64520:10 (default for vrf GREEN)

*>
0.0.0.0
10.10.29.1
0 64520 i
*>
10.0.0.0
10.10.29.1
0 64520 i
*>
172.0.0.0/8
10.10.29.1
0 64520 i
Route Distinguisher: 64520:20 (default for vrf BLUE)

*>
0.0.0.0
10.20.29.1
0 64520 i
*>
10.0.0.0
10.20.29.1
0 64520 i
*>
172.0.0.0/8
10.20.29.1
0 64520 i
Route Distinguisher: 64520:30 (default for vrf RED)

*>
0.0.0.0
10.30.29.1
*>
10.0.0.0
10.30.29.1
Network
Next Hop
172.0.0.0/8
10.30.29.1
*>
0 64520 i
0
0 64520 i

0
0 64520 i
Route Distinguisher: 65423:40 (default for vrf YELLOW)

*>
0.0.0.0
206 | P a g e
10.40.29.1
0 64520 i
Version 5.1B

*>
10.0.0.0
10.40.29.1
0 64520 i
*>
172.0.0.0/8
10.40.29.1
0 64520 i
[ Omitted]
Now, lets do a connectivity test between RTP and New York. We can use a TCL script for this. The
example is performed from R9.
R9
tclsh
foreach i {
10.10.29.2
10.10.39.3
10.20.29.2
10.20.39.3
10.30.29.2
10.30.39.3
10.40.29.2
10.40.39.3
10.50.29.2
10.50.39.3
} { ping $i repeat 1 }

!
!
!
!
Version 5.1B
207 | P a g e

!
!
!
!
!
!
Task 2.6:
BGP in AS 65444
(4 points)

IPv4 must be disabled by default.
Configure a full mesh iBGP peering between all three routers using any configuration method.
Configure the eBGP peerings to AS 3333, AS 7777.
R11 must be selected as the preferred exit point for traffic destined to remote-ASes.
R13 must be selected as the next preferred exit point in case R11 fails.
No BGP speaker should use the network command.
208 | P a g e
Version 5.1B

Ensure that BGP next-hop is never marked as unreachable as long as loopback 0 interface of the
remote peer are known via the IGP.
Redistribute EIGRP into BGP on R11.
Solution
Configure BGP as outlined in the task. First, we need to use Loopback0 as the BGP router-id for all
routers. Second, we have to disable IPv4 for BGP by default. Third, we can use any method to create
the IBGP peerings - we will use the loopback0. Fourth, we need to prefer R11 as the exit point to the
Service Providers (remember we have two, one through AS3333, and also AS7777), make sure that
R13 is the next preferred exit. Fifth, make sure that BGP next-hop is never marked as unreachable as
long as loopback 0 of the peers are known - basically we need to use next-hop-self to accomplish
this. Finally, redistribute EIGRP into BGP on R11.
R11
R11(config)#route-map RMAP-PREF permit 10
R11(config-route-map)#set local-pref 200
R11(config-router)#neighbor 172.17.13.13 update-source loopback0
R11(config-router)#address-family ipv4
R11(config-router-af)#redistribute eigrp 23456
R11(config-router-af)#neighbor 188.166.153.3 route-map RMAP-PREF in
Version 5.1B
209 | P a g e

R12
R13
R13(config)#route-map RMAP-PREF permit 10
R13(config-route-map)#set local-pref 150
R13(config-router)#neighbor 172.17.11.11 up lo0
R13(config-router)#neighbor 172.17.12.12 up lo0
R13(config-router-af)#neighbor 188.166.137.2 route-map RMAP-PREF in
210 | P a g e
Version 5.1B

Verification
Lets verify that R11 is the preferred exit point to other ASes by looking at the route table of R12. On
R13, we can also see that we have two paths for external destinations - one with local-preference of
200 (R11) and the other of 150 (ISP7); remember default local-preference value is 100.
R11
Neighbor
AS MsgRcvd MsgSent
TblVer
InQ OutQ Up/Down
State/PfxRcd
172.17.12.12
65444
32
53
276
0 00:20:49
172.17.13.13
65444
29
33
276
0 00:11:10
188.166.153.3
3333
33
36
276
0 00:16:26
80
R12
Version 5.1B
211 | P a g e

Neighbor
172.17.11.11
65444
AS MsgRcvd MsgSent
53
32
TblVer
523
InQ OutQ Up/Down

0
0 00:21:02
State/PfxRcd
91
172.17.13.13
65444
27
21
523
0 00:11:39
R13
Neighbor
AS MsgRcvd MsgSent
TblVer
InQ OutQ Up/Down
State/PfxRcd
172.17.11.11
65444
33
29
348
0 00:11:38
91
172.17.12.12
65444
22
27
348
0 00:11:53
188.166.137.2
7777
29
36
348
0 00:16:47
81
R12
R12#sh ip bgp
Network
Next Hop
*>i 0.0.0.0
172.17.13.13
150
0 7777 i
*>i 5.5.5.5/32
172.17.11.11
200
0 3333 7777 ?
*>i 13.13.1.0/24
172.17.11.11
200
0 3333 ?
*>i 13.13.1.1/32
172.17.11.11
200
0 3333 ?
*>i 13.13.1.3/32
172.17.11.11
200
0 3333 1111 ?
*>i 20.0.0.0
172.17.11.11
200
0 3333 7777 ?
212 | P a g e
Version 5.1B

*>i 21.0.0.0
172.17.11.11
200
0 3333 7777 ?
*>i 22.0.0.0
172.17.11.11
200
0 3333 7777 ?
*>i 23.0.0.0
172.17.11.11
200
0 3333 7777 ?
*>i 24.0.0.0
172.17.11.11
200
0 3333 7777 ?
*>i 25.0.0.0
172.17.11.11
200
0 3333 7777 ?
*>i 26.0.0.0
172.17.11.11
200
0 3333 7777 ?
*>i 27.0.0.0
172.17.11.11
200
0 3333 7777 ?
*>i 28.0.0.0
172.17.11.11
200
0 3333 7777 ?
[ Omitted ]
R13
R13#sh ip bgp
*>
Network
Next Hop
0.0.0.0
188.166.137.2

150
0 7777 i
*>i 5.5.5.5/32
172.17.11.11
200
0 3333 7777 ?
188.166.137.2
150
0 7777 ?
*>i 13.13.1.0/24
172.17.11.11
200
0 3333 ?
188.166.137.2
150
0 7777 3333 ?
*>i 13.13.1.1/32
172.17.11.11
200
0 3333 ?
188.166.137.2
150
0 7777 3333 ?
*>i 13.13.1.3/32
172.17.11.11
200
0 3333 1111 ?
188.166.137.2
150
0 7777 3333 1111 ?
*>i 20.0.0.0
172.17.11.11
200
0 3333 7777 ?
188.166.137.2
150
0 7777 ?
*>i 21.0.0.0
172.17.11.11
200
0 3333 7777 ?
188.166.137.2
150
0 7777 ?
*>i 22.0.0.0
172.17.11.11
200
0 3333 7777 ?
188.166.137.2
150
0 7777 ?
[ Omitted ]
Version 5.1B
213 | P a g e

Task 2.7:
BGP in AS 65423 and AS 65420
(3 points)

R18 must establish an eBGP peering with AS 3333.
It must receive a default route and all other prefixes from AS 3333.
R18 must advertise a summary route to AS 3333 for 101.33.20.0/24 and suppress all other
routes.
R18 must redistribute BGP into EIGRP and vice versa.

R20, R24, and R25 must establish an eBGP peering with AS 6666 in vrf GW.
o
They must not advertise any prefixes at all to AS 6666.
They must receive a default route and all other prefixes from AS 6666.
Use directly connected interfaces for the peering addresses.
Solution
This configuration is rather simple, we need to configure BGP peerings between AS 6666 and AS
65423, and also AS 65420 to achieve connectivity between the Hub and Spoke routers.
The task specifically calls for us not to advertise any routes back into AS 6666, but receive a default
route and all other prefixes. This is relevant due to the VRF configuration. Thus we will create some
filters and apply them to the BGP neighbors.
R20
R20(config)#route-map DENY deny 10
R20(config-router)#address-family ipv4 unicast vrf GW
R20(config-router-af)#neighbor 195.13.206.2 route-map DENY out
214 | P a g e
Version 5.1B

R24
R25
Next, we are asked to peer with AS 3333 and must advertise a summary route for 101.33.20.0/24 and
suppress all other routes. R18 should also do mutual redistribution between EIGRP and BGP.
R18
R18(config-router)#no auto-summary
R18(config-router)#aggregate-address 101.33.20.0 255.255.255.0 summary-only
R18(config-router)#redistribute eigrp 34567
R18(config-router)#!
R18(config-router)#router eigrp CCIE
R18(config-router-af-topology)#redistribute bgp 65423 metric 100 10 1 1 1
NOTE
Don't forget to set the k metrics for proper redistribution.
Version 5.1B
215 | P a g e

Verification
We should now be learning routes on R20, R24, and R25 from BGP, and we shouldnt advertise any
routes back to the Local Service Provider.
R20
R20#sh bgp vpnv4 unicast vrf GW
Network
Next Hop
Route Distinguisher: 65423:20 (default for vrf GW)

*>
0.0.0.0
195.13.206.2
0 6666 i
*>
5.5.5.5/32
195.13.206.2
0 6666 7777 ?
*>
13.13.1.0/24
195.13.206.2
0 6666 7777 3333 ?
[Results Deprecated]
R24
Network
Next Hop

*>
0.0.0.0
193.190.24.1
0 6666 i
*>
5.5.5.5/32
193.190.24.1
0 6666 7777 ?
*>
13.13.1.0/24
193.190.24.1
0 6666 7777 3333
216 | P a g e
Version 5.1B

R25
Network
Next Hop

*>
0.0.0.0
193.190.25.1
0 6666 i
*>
5.5.5.5/32
193.190.25.1
0 6666 7777 ?
*>
13.13.1.0/24
193.190.25.1
0 6666 7777 3333 ?
Next, let's verify we aren't advertising anything to AS 6666:
R20
R20#sh bgp vpnv4 unicast vrf GW neighbors 195.13.206.2 advertised-routes
R24
R25
Dont forget to verify R18s part:
Version 5.1B
217 | P a g e

R18
R18#sh ip ro bgp
| be Gate
B*
0.0.0.0/0 [20/0] via 195.13.183.2, 00:03:45
10.0.0.0/8 [20/0] via 195.13.183.2, 00:03:45

101.33.20.0/24 [200/0] via 0.0.0.0, 00:02:52, Null0
172.0.0.0/8 [20/0] via 195.13.183.2, 00:03:45
R18#sh ip bgp | in 101

s>
101.33.20.0/29
0.0.0.0
*>
101.33.20.0/24
0.0.0.0
s>
101.33.20.8/29
0.0.0.0
s>
101.33.20.16/29
*>
32768 ?
32768 i
32768 ?
101.33.20.2
1536000
32768 ?
172.17.19.0/24
101.33.20.2
1024640
32768 ?
*>
172.17.20.0/24
101.33.20.10
1024640
32768 ?
*>
172.17.117.0/24
101.33.20.3
3584000
32768 ?
*>
172.17.118.0/24
101.33.20.11
3584000
32768 ?
R18#sh ip bgp neighbors 195.13.183.2 advertised-routes

Network
Next Hop
*>
101.33.20.0/24
0.0.0.0
*>
172.17.18.0/24
0.0.0.0
*>
172.17.19.0/24
*>

32768 i
0
32768 ?
101.33.20.2
1024640
32768 ?
172.17.20.0/24
101.33.20.10
1024640
32768 ?
*>
172.17.117.0/24
101.33.20.3
3584000
32768 ?
*>
172.17.118.0/24
101.33.20.11
3584000
32768 ?
218 | P a g e
Version 5.1B

Task 2.8:
BGP in ASes: 65521, 65522, 65523
(3 points)
Create the eBGP peerings from ASes: 65521, 65522, and 65523 to AS 4444.
Create the eBGP peering from AS 65522 to AS 7777.
Use the directly connected serial interfaces to make these peerings.
Do not perform any redistribution in these ASs
R22 should not be sending 172.16.22.0/24 and 172.0.0.0/8 to ISP7
R22 should prefer AS 4444 as the preferred exit point for traffic destined to remote-ASes.
o
Accomplish this other than using local-preference.
Solution
First, we are asked to peer ASN 4444 with ASNs 65521-23. Second, we should use the directly
connected IP address to successfully complete the BGP peerings. Third, ASN 65522 should also peer
with ASN 7777 but prefer ASN 4444 as the exit point for traffic destined to remote-ASes. This is easily
accomplished by using the "weight" metric (prefer highest); there are also other ways to accomplish
this, but this is the fastest method (single command).
R21
R22
R22(config)#ip prefix-list NO22 seq 5 permit 172.16.22.0/24
R22(config)#ip prefix-list NO22 seq 7 permit 172.0.0.0/8
R22(config)#route-map NO22 deny 10
R22(config-route-map)# match ip address prefix-list NO22
R22(config-route-map)#route-map NO22 permit 20
R22(config-router)#neighbor 92.82.22.1 weight 100
R22(config-router)#neighbor 92.83.22.21 route-map NO22 out
Version 5.1B
219 | P a g e

R23
Verification
Let's verify that all three routers have successfully peered with the SP ASes; also notice that at this
point we won't be learning any routes at all since the MPLS VPNv4 tasks have not yet been
completed.
R21
Neighbor
92.82.21.1
AS MsgRcvd MsgSent
4444
8900
8900
TblVer
5
InQ OutQ Up/Down

0
0 5d14h
State/PfxRcd
1
R22
Neighbor
AS MsgRcvd MsgSent
TblVer
InQ OutQ Up/Down
State/PfxRcd
92.82.22.1
4444
8897
8905
0 5d14h
92.83.22.21
7777
8896
8896
0 5d14h
R23
Neighbor
92.82.23.1
220 | P a g e
AS MsgRcvd MsgSent
4444
8889
8899
TblVer
6
InQ OutQ Up/Down

0
0 5d14h
State/PfxRcd
2
Version 5.1B

Lets also make sure our weight attribute is working (note that right now we dont receive any
prefixes from AS 4444 but the connected subnet):
R22
R22#sh ip bgp
Network
Next Hop
*>
0.0.0.0
92.83.22.21
r>
92.82.22.0/24
92.82.22.1
*>
172.16.22.0/24
0.0.0.0
0 7777 i
100 4444 ?
32768 i
R22#sh ip bgp neigh 92.83.22.21 adve

r>
Network
Next Hop
92.82.22.0/24
92.82.22.1

0
100 4444 ?
Task 2.9:
BGP Routing Policies
(3 points)
All routers in AS 65333 must filter the BGP prefixes which are advertised to their Service
Providers - they must allow 172.0.0.0/8 prefix and a default route. All other VRFs must propagate
all prefixes.
All routers in AS 65444 must filter the BGP prefixes that are advertised to their Service Providers
and must allow only all prefixes that belong to 172.0.0.0/8 network.
Version 5.1B
221 | P a g e

Do not use any route-map or access-list to accomplish the above requirements.

ASes 65521 and 65523 must be reachable from Australia and Mexico, you should be able to ping
their interface loopbacks 21 and 23. Traceroute must reveal the exact same path as show in the
following output:
R24#trace 172.16.21.254 so l24 num
1 192.168.20.20 18 msec 20 msec 21 msec
2 101.33.20.9 26 msec 21 msec 24 msec
3 195.13.183.2 30 msec 29 msec 29 msec
6 10.10.29.2 47 msec 45 msec 48 msec
8 92.82.21.21 64 msec *
65 msec
R24#trace 172.16.23.254 so l24 num

1 192.168.20.20 21 msec 21 msec 21 msec
2 101.33.20.9 22 msec 21 msec 22 msec
3 195.13.183.2 30 msec 26 msec 29 msec
6 10.30.29.2 47 msec 47 msec 47 msec
8 92.82.23.23 65 msec *
222 | P a g e
64 msec
Version 5.1B

R25
R25#trace 172.16.21.254 so l25 num
1 192.168.20.20 43 msec 19 msec 21 msec
2 101.33.20.9 21 msec 21 msec 21 msec
3 195.13.183.2 29 msec 21 msec 30 msec
6 10.10.29.2 48 msec 48 msec 47 msec
8 92.82.21.21 64 msec *
64 msec
R25#trace 172.16.23.254 so l25 num

1 192.168.20.20 21 msec 21 msec 21 msec
2 101.33.20.9 21 msec 21 msec 22 msec
3 195.13.183.2 23 msec 29 msec 30 msec
6 10.30.29.2 47 msec 45 msec 47 msec
8 92.82.23.23 63 msec *
Version 5.1B
65 msec
223 | P a g e

R21
R21#ping 172.16.25.254 so lo021
!!!!!
R21#ping 172.16.24.254 so lo021

!!!!!
R23
R23#ping 172.16.24.254 so l23
!!!!!
R23#ping 172.16.25.254 so l23

!!!!!
Solution
This task needs to be precisely done. For all routers in ASN 65333 we need to filter the prefixes
advertised and should allow the class A 172.0.0.0/8 prefix+default route alone. The routers in ASN
65444 should also filter prefixes to their Service Providers and allow all prefixes belonging to Class A
172.0.0.0/8. Further, all these filtering should be done without the use of route-maps/access-lists, we
will be using prefix-lists as the means for the desired result. Finally, we will verify connectivity
between Australia and Mexico branch to these three ASes.
224 | P a g e
Version 5.1B

R2
R2(config)#ip prefix-list BGP-OUT permit 172.0.0.0/8
R2(config-router)#address-family vpnv4
R2(config-router-af)#neighbor 92.82.12.1 prefix-list BGP-OUT out
R3
R4
R11
R11(config)#ip prefix-list BGP-OUT permit 172.0.0.0/8 le 32
R13
R13(config)#ip prefix-list BGP-OUT permit 172.0.0.0/8 le 32
Version 5.1B
225 | P a g e

Verification
Let's start by verifying that we are successfully advertising the filtered prefixes according to the tasks
instructions.
NOTE
This verification output is dependent on later tasks, you will need to return to this task by the end of the
workbook to re-verify the desired output.
R2, R3, R4
R2#sh bgp all neighbors 92.82.12.1 advertised-routes
[Output omitted]

Network
Next Hop
Route Distinguisher: 9999:50 (default for vrf INET)

*>
172.0.0.0/8
10.50.29.1
0 64520 i
Route Distinguisher: 64520:10 (default for vrf GREEN)

*>
0.0.0.0
10.10.29.1
*>
172.0.0.0/8
10.10.29.1
0 64520 i
0
0 64520 i
Route Distinguisher: 64520:20 (default for vrf BLUE)

*>
0.0.0.0
10.20.29.1
*>
172.0.0.0/8
10.20.29.1
0 64520 i
0
0 64520 i
Route Distinguisher: 64520:30 (default for vrf RED)

*>
0.0.0.0
10.30.29.1
*>
172.0.0.0/8
10.30.29.1
0 64520 i
0
0 64520 i
Route Distinguisher: 65423:40 (default for vrf YELLOW)

*>
0.0.0.0
10.40.29.1
*>
172.0.0.0/8
10.40.29.1
Network
Next Hop
226 | P a g e
0 64520 i
0
0 64520 i
Version 5.1B

Repeat the same command for R3 and R4 to verify the filtering just dont forget to replace the
neighbor IP address.
Do the same verification for ASN 65444 to see that we met the requirements.
R11 & R13

R11#sh bgp all neighbors 188.166.153.3 advertised-routes
For address family: IPv4 Unicast
Network
Next Hop
*>
172.17.11.0/24
0.0.0.0
*>
172.17.12.0/24
*>

0
32768 ?
101.33.10.10
1029760
32768 ?
172.17.13.0/24
101.33.10.6
1045120
32768 ?
*>
172.17.115.0/24
101.33.10.6
3599360
32768 ?
*>
172.17.116.0/24
101.33.10.10
3584000
32768 ?
Repeat the same command for R13 to verify the filtering, replace the neighbor IP address.
Last, notice that we can't verify the connectivity to Australia and Mexico offices, we are dependent on
almost all of the topology and tasks. We will have to verify this after we complete all tasks.
These are the outputs you should be receiving, make sure to match the outputs exactly.
Version 5.1B
227 | P a g e

R25
R25#trace 172.16.21.254 so l25 num
1 192.168.20.20 43 msec 19 msec 21 msec
2 101.33.20.9 21 msec 21 msec 21 msec
3 195.13.183.2 29 msec 21 msec 30 msec
6 10.10.29.2 48 msec 48 msec 47 msec
8 92.82.21.21 64 msec *
64 msec
R25#trace 172.16.23.254 so l25 num

1 192.168.20.20 21 msec 21 msec 21 msec
2 101.33.20.9 21 msec 21 msec 22 msec
3 195.13.183.2 23 msec 29 msec 30 msec
6 10.30.29.2 47 msec 45 msec 47 msec
8 92.82.23.23 63 msec *
228 | P a g e
65 msec
Version 5.1B

R24
R24#trace 172.16.21.254 so l24 num
1 192.168.20.20 18 msec 20 msec 21 msec
2 101.33.20.9 26 msec 21 msec 24 msec
3 195.13.183.2 30 msec 29 msec 29 msec
6 10.10.29.2 47 msec 45 msec 48 msec
8 92.82.21.21 64 msec *
65 msec
R24#trace 172.16.23.254 so l24 num

1 192.168.20.20 21 msec 21 msec 21 msec
2 101.33.20.9 22 msec 21 msec 22 msec
3 195.13.183.2 30 msec 26 msec 29 msec
6 10.30.29.2 47 msec 47 msec 47 msec
8 92.82.23.23 65 msec *
Version 5.1B
64 msec
229 | P a g e

R21
R21#ping 172.16.25.254 so lo021
!!!!!
R21#ping 172.16.24.254 so lo021

!!!!!
R23
R23#ping 172.16.25.254 so lo023
!!!!!
R23#ping 172.16.24.254 so lo023

!!!!!
230 | P a g e
Version 5.1B

Task 2.10: IPv6 OSPF
(3 points)
Assign IPv6 addresses according to the IPv6 diagram and table below:
Table 5.12
Device
Interface
IPv6 Address
R2
e0/0
2004::23:1/112
e0/1.26
2004::26:5/112
e0/0
2004::23:2/112
e0/1.37
2004::37:9/112
e0/1.26
2004::26:6/112
e0/1.64
2004::64:13/112
e0/1.37
2004::37:10/112
e0/1.75
2004::75:17/112
R4
e0/1
2004::64:14/112
R5
e0/1
2004::75:18/112
R3
R6
R7
Also advertise loopbacks0 of the above mentioned routers.

Configure the OSPF process ID 12345.
All routers should support Multi-AF OSPF.
Do not enable OSPF on any interfaces that are not referenced in the IPv6 diagram/table.
R2 must be elected as the DR on VLAN23, R3 must be selected as the backup DR on VLAN23 and
should take over if R2 is down.
Configure OSPF Areas: 0,10,20,30,40.
Solution
First step, configuring IPv6 addresses, was already done for us the addresses are already configured
on the interfaces. Second step to this task is to configure OSPF process ID 12345 but make sure it
supports multi address-family (ipv4/ipv6, etc.), thus we will be using OSPFv3 which is the only one
that supports this (neither OSPFv2 nor IPv6 OSPFv2 support multi address-families). Second, enable
OSPFv3 only on required interfaces by issuing 1 command at the interface level. Third, make R2 the
elected OSPF designated router on VLAN23, while also making sure that R3 will take over once R2 is
down.
Version 5.1B
231 | P a g e

NOTE
Remember that the ipv6 unicast-routing command globally enables IPv6 Routing and must be
the first IPv6 command executed on the router.
R2
R2(config)#ipv6 unicast-routing
R2(config)#router ospfv3 12345
R2(config-router-af)#router-id 172.17.2.2
R2(config-router-af)#interface e0/1.26
R2(config-subif)#ospfv3 12345 ipv6 area 10
R2(config-subif)#interface e0/0
R2(config-if)#ospfv3 12345 ipv6 area 0
R2(config-if)#ospfv3 12345 ipv6 priority 255
R2(config-if)#interface lo0
R3
R3(config-subif)#interface e0/0
R3(config-if)#ospfv3 12345 ipv6 priority 254
R6
232 | P a g e
Version 5.1B

R6(config-subif)#interface lo0
R7
R7(config-subif)#interface lo0
Next step is to configure OSPFv3 Area30 and Area 40. The process is very similar to the EIGRP
process, however, you do not need to enable it globally. Once OSPFv3 is enabled on an interface, the
router enables the process globally.
Now the tricky part, we need to be able and have reachability to Areas 30,40 but if we look closely we
can see that these areas don't have a direct connection to the Backbone Area 0.
We will overcome this obstacle by configuring "virtual-link" connections for each area.
Version 5.1B
233 | P a g e

Diagram 5.13
234 | P a g e
Version 5.1B

R2
R2(config-router-af)#area 10 virtual-link 172.17.6.6
R3
R6
R7
R4
R4(config-router-af)#interface e0/1
Version 5.1B
235 | P a g e

R5
R5(config-router-af)#interface e0/1
Verification
We can verify the requirements of this task by first looking at the routing table of R2 and R3. It should
hold OSPF inter-area and intra-area routes.
R2
R2#sh ipv6 route ospf
IPv6 Routing Table - default - 20 entries
Codes: C - Connected, L - Local, S - Static, U - Per-user Static route
B - BGP, HA - Home Agent, MR - Mobile Router, R - RIP
H - NHRP, I1 - ISIS L1, I2 - ISIS L2, IA - ISIS interarea
IS - ISIS summary, D - EIGRP, EX - EIGRP external, NM - NEMO
ND - ND Default, NDp - ND Prefix, DCE - Destination, NDr - Redirect
O - OSPF Intra, OI - OSPF Inter, OE1 - OSPF ext 1, OE2 - OSPF ext 2
ON1 - OSPF NSSA ext 1, ON2 - OSPF NSSA ext 2, ls - LISP site
ld - LISP dyn-EID, a - Application
O
2001::3/128 [110/10]
via FE80::A8BB:CCFF:FE00:300, Ethernet0/0
OI
2001::4/128 [110/20]
via FE80::A8BB:CCFF:FE00:610, Ethernet0/1.26
OI
2001::5/128 [110/30]
2001::6/128 [110/10]
OI
2001::7/128 [110/20]
OI
2004::37:0/112 [110/20]
OI
2004::37:9/128 [110/10]
236 | P a g e
Version 5.1B

OI
2004::64:0/112 [110/20]
OI
2004::75:0/112 [110/30]
R3
R3#sh ipv6 route ospf
IPv6 Routing Table - default - 20 entries
Codes: C - Connected, L - Local, S - Static, U - Per-user Static route
B - BGP, HA - Home Agent, MR - Mobile Router, R - RIP
H - NHRP, I1 - ISIS L1, I2 - ISIS L2, IA - ISIS interarea
IS - ISIS summary, D - EIGRP, EX - EIGRP external, NM - NEMO
ND - ND Default, NDp - ND Prefix, DCE - Destination, NDr - Redirect
O - OSPF Intra, OI - OSPF Inter, OE1 - OSPF ext 1, OE2 - OSPF ext 2
ON1 - OSPF NSSA ext 1, ON2 - OSPF NSSA ext 2, ls - LISP site
ld - LISP dyn-EID, a - Application
O
2001::2/128 [110/10]
OI
2001::4/128 [110/30]
OI
2001::5/128 [110/20]
OI
2001::6/128 [110/20]
2001::7/128 [110/10]
OI
2004::26:0/112 [110/20]
OI
2004::26:5/128 [110/10]
OI
2004::64:0/112 [110/30]
OI
2004::75:0/112 [110/20]
Version 5.1B
237 | P a g e

Next, check to see who is the designated router and backup designated router for VLAN 23.
R2
R2#sh ospfv3 int ethernet 0/0
Ethernet0/0 is up, line protocol is up
Link Local Address FE80::A8BB:CCFF:FE00:200, Interface ID 3
Area 0, Process ID 12345, Instance ID 0, Router ID 172.17.2.2
Network Type BROADCAST, Cost: 10
Transmit Delay is 1 sec, State DR, Priority 255
Designated Router (ID) 172.17.2.2, local address FE80::A8BB:CCFF:FE00:200
Backup Designated router (ID) 172.17.3.3, local address FE80::A8BB:CCFF:FE00:300
Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5
Hello due in 00:00:07
Graceful restart helper support enabled
Index 1/2/3, flood queue length 0
Next 0x0(0)/0x0(0)/0x0(0)
Last flood scan length is 0, maximum is 8
Last flood scan time is 0 msec, maximum is 1 msec
Neighbor Count is 1, Adjacent neighbor count is 1
Adjacent with neighbor 172.17.3.3
(Backup Designated Router)
Suppress hello for 0 neighbor(s)
Next, although we should've already identified areas 30,40 prefixes in our routing table, we will verify
the virtual-link status.
R6
R6#sh ospfv3 virtual-links
OSPFv3 12345 address-family ipv6 (router-id 172.17.6.6)
Virtual Link OSPFv3_VL0 to router 172.17.2.2 is up
Interface ID 33, IPv6 address 2004::26:5
Run as demand circuit
DoNotAge LSA allowed.
Transit area 10, via interface Ethernet0/1.26, Cost of using 10
Transmit Delay is 1 sec, State POINT_TO_POINT,
Adjacency State FULL (Hello suppressed)
Index 1/1/3, retransmission queue length 0, number of retransmission 0
238 | P a g e
Version 5.1B

First 0x0(0)/0x0(0)/0x0(0) Next 0x0(0)/0x0(0)/0x0(0)
Last retransmission scan length is 0, maximum is 0
Last retransmission scan time is 0 msec, maximum is 0 msec
R7
R7#sh ospfv3 virtual-links
OSPFv3 12345 address-family ipv6 (router-id 172.17.7.7)
Virtual Link OSPFv3_VL0 to router 172.17.3.3 is up
Interface ID 33, IPv6 address 2004::37:9
Run as demand circuit
DoNotAge LSA allowed.
Transit area 20, via interface Ethernet0/1.37, Cost of using 10
Transmit Delay is 1 sec, State POINT_TO_POINT,
Adjacency State FULL (Hello suppressed)
Index 1/1/3, retransmission queue length 0, number of retransmission 0
First 0x0(0)/0x0(0)/0x0(0) Next 0x0(0)/0x0(0)/0x0(0)
Last retransmission scan length is 0, maximum is 0
Last retransmission scan time is 0 msec, maximum is 0 msec
We indeed see each of these routes. Now, lets verify full connectivity of the IPv6 topology using a
TCL script.
R2 & R3
tclsh
foreach address {
2001::2
2001::3
2001::4
2001::5
2001::6
2001::7
} { ping $address repeat 1 source lo0}
Version 5.1B
239 | P a g e

Task 2.11: IPv6 BGP
(3 points)
Assign the IPv6 addressing according to the following table:
Table 5.14
Device
Interface
IPv6 Address
R4
s2/0
2004::44:1/112
R5
s2/0
2004::54:5/112
R21
s2/0
2004::21:21/112
R23
s2/0
2004::23:23/112
Configure IPv6 eBGP peerings between ASes 65521, 65523 and 65333 with AS 4444.
o
Only add the interfaces that are in the IPv6 diagram.
Redistribute OSPF into BGP on R4.

Perform mutual redistribution between OSPF and BGP on R5.
No BGP speaker should use the network command.
Do not use any static route or default route anywhere.
Verify that loopback 21 of R21 and loopback23 of R23 have full connectivity to R2's, and R3's
loopback addresses; also the following outputs should match:
R21#ping 2001::2 source Lo21
Sending 5, 100-byte ICMP Echos to 2001::2, timeout is 2 seconds:
Packet sent with a source address of 2021::21
!!!!!

!!!!!
240 | P a g e
Version 5.1B

R21#traceroute ipv6 2001::2

Tracing the route to 2001::2
1 2004::21:1 8 msec 9 msec 8 msec

2 2004::44:1 [AS 4444] 16 msec 16 msec 17 msec
3 2004::64:13 [AS 65333] 17 msec 16 msec 17 msec
4 2004::26:5 [AS 65333] 17 msec 17 msec 17 msec

1 2004::21:1 9 msec 8 msec 8 msec

2 2004::54:5 [AS 4444] 18 msec 17 msec 18 msec
3 2004::75:17 [AS 65333] 17 msec 17 msec 17 msec
4 2004::37:9 [AS 65333] 18 msec 16 msec 17 msec
R23
R23#ping ipv6 2001::2 source lo23
!!!!!

!!!!!
Version 5.1B
241 | P a g e

Solution
The first step is (IPv6 addresses) is pre-configured. Always look at initial configs so you dont waste
time configuring things which are already in place.
The second step to this task is to configure the eBGP peerings for ASN 65521 and 65523 with ASN
4444 without using any network statements. Third, we need to peer ASN 65333 with ASN 4444
and properly configure mutual redistribution between the IPv6 BGP and the OSPFv3 protocols.
R4
R4(config-router)#neighbor 2004::44:2 remote-as 4444
R4(config-router-af)#redistribute ospf 12345 match internal external include-connected
R4(config-router-af)#neighbor 2004::44:2 activate
R5
R5(config-router-af)#redistribute ospf 12345 match internal external include-connected
R5(config-router-af)#router ospfv3 12345
R5(config-router-af)#redistribute bgp 65333
R21
R21(config-router-af)#redistribute connected
242 | P a g e
Version 5.1B

R23
R23(config-router-af)#redistribute connected
Verification
Let's verify that we meet all the task requirements by pinging from R21, and R23 towards R2 and R3.
Also, we should match the exact tracer command output given in the task. We should have full
reachability from R21, and R22 towards R2, and R3 as well as all the rest.
R21
!!!!!
!!!!!
1 2004::21:1 8 msec 9 msec 8 msec
2 2004::44:1 [AS 4444] 16 msec 16 msec 17 msec
3 2004::64:13 [AS 65333] 17 msec 16 msec 17 msec
4 2004::26:5 [AS 65333] 17 msec 17 msec 17 msec
Version 5.1B
243 | P a g e

1 2004::21:1 9 msec 8 msec 8 msec
2 2004::54:5 [AS 4444] 18 msec 17 msec 18 msec
3 2004::75:17 [AS 65333] 17 msec 17 msec 17 msec
4 2004::37:9 [AS 65333] 18 msec 16 msec 17 msec
R23
!!!!!

!!!!!
OK, this is our final reachability test. And of course, we are going to use our favorite testing
mechanism, a TCL script to accomplish this.
R21
tclsh
foreach address {
2001::2
2001::3
2001::4
2001::5
2001::6
2001::7
} { ping ipv6 $address repeat 1 so loop21}
244 | P a g e
Version 5.1B

R23
tclsh
foreach address {
2001::2
2001::3
2001::4
2001::5
2001::6
2001::7
2021::21
2001::21
2023::23
2001::23
} { ping ipv6 $address repeat 1 source l23}
Task 2.12: IPv4 Multicast
(3 points)
SW8 is a multicast server on interface Loopback 0.

The rendezvous point must be dynamically discovered using standard methods.
R18's loopback 0 interface must be the elected RP.
To test configure R19, R24, and R25 loopback0 to join group 232.8.8.8 as multicast receivers.
All devices in ASN 65423 and ASN 65420 must participate in multicast routing.
A ping to 232.8.8.8 must result in a response from R19, R24, and R25 loopback 0 interfaces as
displayed in the following output below:
SW8#ping 232.8.8.8 source lo0

Version 5.1B
245 | P a g e

Solution
Several things we need to notice before we start. First, the task asks us to configure a Rendezvous
Point (RP) and that it must be discovered using standard methods. So, we need to use sparse-mode
and BSR candidate.
The RP should be R18's loopback 0 interface. Also, we are explicitly told that all devices must
participate, although R20,R18, and SW7 have no receivers. There also aren't any specifications to
enable multicast ONLY for the interfaces needed, but it is still a good practice. To simulate multicast
receivers R19, R24, and R25 should join multicast group 232.8.8.8.
NOTE
Remember the ip multicast-routing command globally enables IP multicast routing and must be
the first multicast command executed on the router.
R18
R18(config)#ip multicast-routing
R18(config-if)#ip pim sparse-mode
R18(config-if)#interface e0/1
R18(config-if)#int lo0
R18(config-if)#ip pim rp-candidate loopback0
R18(config)#ip pim bsr-candidate loopback0
R19
R19(config-if)#ip igmp join-group 232.8.8.8
Configure PIM sparse-mode on R20, R24, and R25. Specifically don't forget about the tunnel
interfaces of these routers.
246 | P a g e
Version 5.1B

R20
R20(config-if)#int tun0
Also, we need to configure the multicast receivers using igmp-join.
R24
R24(config)#int tun0
R25
R25(config)#int tun0
Verification
NOTE
You will not be able verify this task until DMVPN is up and running.
To verify this task we will ping 232.8.8.8 from SW8 (the multicast server), this must result in a
response from R19, R24, and R25 which are the multicast receivers.
Version 5.1B
247 | P a g e

SW8
SW8#ping 232.8.8.8 source lo0

If something is not functioning properly, we should start by methodically verifying the PIM
neighborships between the devices, then proceed to identify if there are any routing issues which
might be affecting our RPF check.
248 | P a g e
Version 5.1B

Section 3.0: IPv4 VPN Technology

Task 3.1:
MPLS VPN
(16 points)
(3 points)
Refer to the BGP diagram and VPN topology.

The global and regional Service providers have agreed to transport the iPexpert VPNs via PE to PE
eBGP peering that are already fully configured.
Complete the configuration of mpls L3VPN in the iPexpert network according to the following
requirements:
o
Enable LDP only on required interfaces on all seven routers in AS 65333.
Use the interface Lo0 to establish LDP Peerings.
R2, R3, R4 and R5 must be configured as PE routers.
R6, R7 and R1 must be configured as P routers.
Use only one command to achieve this.
Ensure that no MPLS interface that belongs to any router in AS 65333 is visible on a
traceroute that originates outside of the AS.
Solution
There is a lot going on in this task. Not to mention, it requires the configuration of the next task as
well to work properly. Lets take it step by step. First, lets enable MPLS throughout the MPLS Core
network. Second, use the loopback0 interface to establish the LDP peerings.
R2
R2(config)#ip cef
R2(config)#mpls ldp router-id lo0 force
R2(config)#interface range e0/0,e0/1.26
R2(config-if-range)#mpls ip
R2(config-if-range)#interface s2/2
Version 5.1B
249 | P a g e

R3
R3(config)#ip cef
R3(config)#interface range e0/0,e0/1.37
R4
R4(config)#ip cef
R4(config)#interface range e0/0,e0/1
R5
R5(config)#ip cef
R5(config)#interface range e0/0,e0/1
Next, we were asked to enable LDP on R6, R7, and R1 using only one command.
R1, R6, R7
RX(config)#ip cef
RX(config)#mpls ldp router-id lo0 force
RX(config)#router ospf 12345
RX(config-router)#mpls ldp autoconfig area 0
250 | P a g e
Version 5.1B

Last, we need to ensure that the routers in the MPLS domain cannot be visible on a traceroute that
originates from outside of the AS. This is used to control the generation of the time-to-live (TTL) field
in the MPLS header when labels are first added to an IP packet, this command is used in the global
configuration mode.
R1-R7
RX(config-router)#no mpls ip propagate-ttl forwarded
Verification
At this point, the only thing we can verify is the LDP relationships. We can glean the status of LDP by
looking at R1 which should have a peering with all the MPLS routers. We expect only 2 LDP neighbors.
R1
R1#show mpls ldp neighbor | include Peer|State
Peer LDP Ident: 172.17.6.6:0; Local LDP Ident 172.17.1.1:0
State: Oper; Msgs sent/rcvd: 9050/9060; Downstream
Peer LDP Ident: 172.17.7.7:0; Local LDP Ident 172.17.1.1:0
State: Oper; Msgs sent/rcvd: 9070/9066; Downstream
Next, we can also take a peak in R1's mpls forwarding table to see if we have all ldp-id address of all
router peers we are expecting.
R1
R1#sh mpls forwarding-table
Local
Outgoing
Prefix
Bytes Label
Outgoing
Label
Label
or Tunnel Id
Switched
interface
16
16
101.33.1.0/30
Et0/0
101.33.1.25
16
101.33.1.0/30
Et0/1
101.33.1.30
17
Pop Label
101.33.1.4/30
Et0/0
101.33.1.25
18
Pop Label
101.33.1.8/30
Et0/1
101.33.1.30
19
Pop Label
101.33.1.12/30
Et0/0
101.33.1.25
20
Pop Label
101.33.1.16/30
Et0/1
101.33.1.30
21
19
101.33.1.20/30
Et0/0
101.33.1.25
19
101.33.1.20/30
Et0/1
101.33.1.30
22
22
172.17.2.0/24
Et0/0
101.33.1.25
23
23
172.17.3.0/24
Et0/1
101.33.1.30
24
24
172.17.4.0/24
Et0/0
101.33.1.25
25
25
172.17.5.0/24
Et0/1
101.33.1.30
Version 5.1B
Next Hop
251 | P a g e

26
Pop Label
172.17.6.0/24
Et0/0
101.33.1.25
27
Pop Label
172.17.7.0/24
Et0/1
101.33.1.30
Later we will do the full verification of MPLS VRF VPNs after the next section.
Task 3.2:
MPLS VPN Connectivity
(5 points)
R1 must reflect VPNv4 prefixes from any PE to any other PE in AS 65333.

R2 and R3 must establish an eBGP peering with both Service Providers (AS 1111 and AS 2222 ) for
the following VRFs:
o
GREEN
BLUE
RED
YELLOW
INET
R4 must establish an eBGP peering with the Service Providers AS 4444 for the following VRFs:
o
GREEN
BLUE
RED
No BGP speaker in AS 65333 may use the network statement under any address-family of the
BGP router configuration.
Peer between ASN 65333 (R2, R3) and ASN 64520 (R9). Each sub-interface should have its own
BGP peering in its respective VRF.
Solution
First, lets configure the VRFs that are to be used for the MPLS VPNs on all P/PE devices that are
missing this configuration. This is a requirement to get the MPLS VPNs to work correctly. The VRFs
are listed in the BGP diagram.
252 | P a g e
Version 5.1B

R1, R5
RX(config)#ip vrf BLUE
RX(config-vrf)# rd 64520:20
RX(config-vrf)# route-target export 20:20
RX(config-vrf)# route-target import 20:20
RX(config-vrf)#!
RX(config-vrf)#ip vrf GREEN
RX(config-vrf)#!
RX(config-vrf)#ip vrf INET
RX(config-vrf)#!
RX(config-vrf)#ip vrf RED
RX(config-vrf)#!
RX(config-vrf)#ip vrf YELLOW
Version 5.1B
253 | P a g e

R4 will only peer for BLUE, GREEN and RED (read the next task):
R4
R4(config-vrf)#!
R4(config-vrf)#!
Next, we need to configure R1 as the VPNv4 route-reflector for ASN 65333. Let's configure that. The
restriction to pay attention to - we cannot use any network statement under the address-family of
the BGP configuration.
R1
R1(config-router-af)#neighbor IBGP route-reflector-client
R2-R5
RX(config)#router bgp 65333
RX(config-router)#address-family vpnv4
RX(config-router-af)#neighbor 172.17.1.1 activate
RX(config-router-af)#neighbor 172.17.1.1 next-hop-self
254 | P a g e
Version 5.1B

NOTE
The remaining part of this task was configured earlier (peerings with ASes 1111,2222, 4444 and 64520).
Verification
R1
| be VPNv4

Neighbor
AS MsgRcvd MsgSent
TblVer
InQ OutQ Up/Down
State/PfxRcd
172.17.2.2
65333
31
40
55
0 00:01:53
20
172.17.3.3
65333
29
41
55
0 00:01:50
20
172.17.4.4
65333
16
38
55
0 00:01:48
172.17.5.5
65333
37
55
0 00:01:46
R2
| be VPNv4

Version 5.1B
255 | P a g e

Neighbor
AS MsgRcvd MsgSent
TblVer
InQ OutQ Up/Down
10.10.29.1
64520
442
435
60
0 06:32:11
10.20.29.1
64520
441
435
60
0 06:32:09
10.30.29.1
64520
442
435
60
0 06:32:11
10.40.29.1
64520
422
419
60
0 06:13:37
Neighbor
AS MsgRcvd MsgSent
TblVer
10.50.29.1
64520
420
414
60
0 06:13:36
92.82.12.1
1111
453
470
60
0 06:21:36
172.17.1.1
65333
59
51
60
0 00:19:32
InQ OutQ Up/Down
State/PfxRcd
State/PfxRcd
R3
| be VPNv4

Neighbor
10.10.39.1
64520
442
437
51
0 06:33:03
10.20.39.1
64520
445
436
51
0 06:33:06
10.30.39.1
64520
442
439
51
0 06:33:03
10.40.39.1
64520
423
419
51
0 06:14:04
Neighbor
AS MsgRcvd MsgSent
TblVer
10.50.39.1
64520
422
417
51
0 06:14:37
92.82.32.2
2222
293
302
51
0 03:57:20
172.17.1.1
65333
62
49
51
0 00:20:23
27
256 | P a g e
AS MsgRcvd MsgSent
TblVer
InQ OutQ Up/Down
InQ OutQ Up/Down
State/PfxRcd
3
State/PfxRcd
Version 5.1B

R4
R4#sh bgp all su | be VPNv4
Neighbor
92.82.44.2
4444
490
518
67
0 06:31:22
172.17.1.1
65333
124
58
67
0 00:29:21
Task 3.3:
AS MsgRcvd MsgSent
TblVer
InQ OutQ Up/Down
State/PfxRcd
DMVPN
(4 points)
Configure DMVPN in ASN 34567 as per the following requirements:

o
Use the preconfigured interface tunnel0 on R20, R24, and R25 in order to accomplish this
task.
R20 must be configured as DMVPN hub.
Use interface s2/0 as the source address of the tunnel on each device,
except for R20 which uses interface s2/2.
R24 and R25 must be the spokes and must participate in the NHRP information exchange.
Place the tunnel source interfaces in VRF GW.
Disable send ICMP redirect messages on all three tunnel interfaces.
Configure the following parameter on all three tunnel interface:

Version 5.1B
257 | P a g e

Bandwidth: 1000 kbps
Delay: 10000 msec
IP MTU: 1400 Bytes
TCP MSS: 1380 Bytes
NHRP Authentication: "DMVPNk6y"
NHRP network-id: 34567
NHRP hold time: 10 min
Tunnel Key: 34567
Ensure that spoke-to-spoke traffic does not transit via the hub.
Solution
This task is a little tricky. First of all we notice that this needs to be a tunnel which is VRF aware,
which affects the way of configuring the DMVPN and its encryption later on. We are also asked to
make sure the spoke routers R24 and R25 participate in the NHRP information exchange, also spoketo-spoke should not transit via the hub making this a Phase-3 DMVPN deployment. Let's configure the
DMVPN hub on R20. Assign all the parameters as outlined in the task such as bandwidth, delay and
tcp-mss adjust. Configure ip nhrp redirect so that the spokes can connect to each other
without going through the hub (phase 3). Lastly, disable EIGRP split-horizon.
R20
R20(config-if)#no ip redirects
R20(config-if)#tunnel vrf GW
R20(config-if)#ip nhrp map multicast dynamic
R20(config-if)#ip nhrp network-id 34567
R20(config-if)#ip nhrp holdtime 600
R20(config-if)#ip nhrp auth DMVPNk6y
R20(config-if)#ip nhrp redirect
R20(config-if)#bandwidth 1000
R20(config-if)#delay 1000
R20(config-if)#ip mtu 1400
R20(config-if)#ip tcp adjust-mss 1380
258 | P a g e
Version 5.1B

R20(config-if)#tunnel key 34567
R20(config-if)#tunnel source s2/2
R20(config-if)#tunnel destination dynamic
R20(config-if)#tunnel mode gre multipoint
R20(config-if)#!
R20(config-if)#router eigrp CCIE
R20(config-router-af)#af-interface tun0
R20(config-router-af-interface)#no next-hop-self
Now, let's configure the DMVPN spokes.
R24
R24(config-if)#ip nhrp map 192.168.20.20 195.13.206.1
R24(config-if)#ip nhrp map multicast 195.13.206.1
R24(config-if)#ip nhrp nhs 192.168.20.20
R24(config-if)#ip nhrp shortcut
Version 5.1B
259 | P a g e

R25
R25(config-if)#ip nhrp map 192.168.20.20 195.13.206.1
R25(config-if)#ip nhrp map multicast 195.13.206.1
R25(config-if)#ip nhrp nhs 192.168.20.20
R25(config-if)#ip nhrp shortcut
Verification
Let's verify this, first we will go to the HUB router (R20) and check to see if all spokes are properly
registered.
R20
R20#sh ip nhrp
192.168.20.24/32 via 192.168.20.24
Tunnel0 created 5d13h, expire 00:08:10
Type: dynamic, Flags: unique registered used nhop
NBMA address: 193.190.24.24
192.168.20.25/32 via 192.168.20.25
Tunnel0 created 5d13h, expire 00:08:17
Type: dynamic, Flags: unique registered used nhop
R20#sh dmvpn
260 | P a g e
Version 5.1B

=======================================================================
# Ent
UpDn Tm Attrb
----- --------------- --------------- ----- -------- ----1 193.190.24.24
192.168.20.24
UP
5d13h
1 193.190.25.25
192.168.20.25
UP
5d13h
Next, let's see the NHRP mapping on the spokes side.
R24
R24#sh ip nhrp
192.168.20.20/32 via 192.168.20.20
Tunnel0 created 5d14h, never expire
Type: static, Flags: used
R25
R25#sh ip nhrp
192.168.20.20/32 via 192.168.20.20
Last, we need to see that we successfully configured DMVPN phase-3. We will ping the other remote
site, the first ping initiates the dynamic tunnel creation. And the next packets should flow directly
through the dynamic tunnel. We will take a traceroute before and after to identify this behavior.
NOTE
To see the correct outputs matching below, you should now go back to Task 2.4 and configure EIGRP
between the routers so they can start exchanging the prefixes over the Cloud. Once you are done with
Task 2.4, Task 2.12 (multicasting) should be also working at that point.
Version 5.1B
261 | P a g e

R24
R24#traceroute 172.16.25.254 source lo24
1 192.168.20.20 21 msec
192.168.20.25 21 msec
R24#sh ip nhrp
192.168.20.20/32 via 192.168.20.20
192.168.20.25/32 via 192.168.20.25
Tunnel0 created 00:00:52, expire 00:09:07
Type: dynamic, Flags: router used nhop
R24#traceroute 172.16.25.254 source lo24
1 192.168.20.25 21 msec *
Task 3.4:
22 msec
<<< Only one HOP away
DMVPN Encryption
(4 points)
Refer to "Diagram 4: DMVPN Topology"

Secure the DMVPN tunnel with IPsec according to the following requirements:
Configure IKE Phase 1 according to the following requirements:
262 | P a g e
Configure a single policy with priority 50.
Use AES encryption with the pre-shared key "IPXrulez".
The key must appear in plain text in the configuration.
All IPsec tunnels must be authenticated using the same IKE Phase 1 pre-shared key.
Version 5.1B

Use 1024 bits for the key exchange using the Diffie-Hellman algorithm.
Configure IKE Phase 2 according to the following requirements:

o
Transform-set name: "IPXTransform"
Use the IPsec security protocol ESP and the algorithm AES with 128 bits.
IPsec profile name: DMVPNPROFILE
Use IPsec in transport mode.
Ensure that the DMVPN cloud is secured using the above parameters.
Solution
Configure the encryption settings according to the task and then apply it to tunnel0.
R20, R24, R25

RX(config)#crypto isakmp policy 50
RX(config-isakmp)#authentication pre-share
RX(config-isakmp)#encr aes
RX(config-isakmp)#group 2
RX(config-isakmp)#!
RX(config-isakmp)#crypto keyring DMVPN vrf GW
RX(conf-keyring)#pre-shared-key address 0.0.0.0 key IPXrulez
RX(conf-keyring)#!
RX(conf-keyring)#crypto ipsec transform-set IPXTransform esp-aes esp-sha-hmac
RX(cfg-crypto-trans)# mode transport
RX(cfg-crypto-trans)#crypto ipsec profile DMVPNPROFILE
RX(ipsec-profile)# set transform-set IPXTransform
RX(ipsec-profile)#!
RX(ipsec-profile)#interface tunnel0
RX(config-if)#tunnel protection ipsec profile DMVPNPROFILE
NOTE
Notice that we configured VRF-Aware IPSEC. Using the VRF-Aware IPSEC feature, you can map IPsec
tunnels to Virtual Routing and Forwarding (VRF) instances without using a public-facing address.
Version 5.1B
263 | P a g e

Verification
Quickly verify this, first by pinging from spoke to spoke, should be operational; then by verifying the
dmvpn crypto session details. Last, by looking at the phase-1 & phase-2 status output.
R24
R24#sh dmvpn detail
output omitted
# Ent
UpDn Tm Attrb
Target Network
----- --------------- --------------- ----- -------- ----- -----------1 195.13.206.1
192.168.20.20
UP 00:00:07 S 192.168.20.20/32
Crypto Session Details:

--------------------------------------------------------------------------------
Interface: Tunnel0
Session: [0xA2C0F118]
Session ID: 0
IKEv1 SA: local 193.190.24.24/500 remote 195.13.206.1/500 Active
Capabilities:(none) connid:1009 lifetime:23:59:22
Crypto Session Status: UP-ACTIVE
fvrf: GW,
Phase1_id: 195.13.206.1
IPSEC FLOW: permit 47 host 193.190.24.24 host 195.13.206.1

Active SAs: 2, origin: crypto map
Inbound:
#pkts dec'ed 10 drop 0 life (KB/Sec) 4150792/3592
Outbound: #pkts enc'ed 12 drop 0 life (KB/Sec) 4150792/3592

Outbound SPI : 0xC5551EBB, transform : esp-aes esp-sha-hmac
Socket State: Open

dst
src
state
195.13.206.1
193.190.24.24
QM_IDLE
conn-id status
1009 ACTIVE
R24#show crypto ipsec sa | inc Status|pkts

#pkts encaps: 63, #pkts encrypt: 63, #pkts digest: 63
264 | P a g e
Version 5.1B

#pkts decaps: 65, #pkts decrypt: 65, #pkts verify: 65
#pkts compressed: 0, #pkts decompressed: 0
#pkts not compressed: 0, #pkts compr. failed: 0
#pkts not decompressed: 0, #pkts decompress failed: 0
Status: ACTIVE(ACTIVE)
R25
R25#sh dmvpn detail
output omitted
# Ent
UpDn Tm Attrb
Target Network
----- --------------- --------------- ----- -------- ----- ----------------1 195.13.206.1
192.168.20.20
UP
5d14h
192.168.20.20/32
1 193.190.24.24
192.168.20.24
UP 00:09:01
192.168.20.24/32
1 193.190.25.25
192.168.20.25
UP 00:09:01
DLX
192.168.20.25/32
Crypto Session Details:

-----------------------------------------------------------------------
Interface: Tunnel0
Session: [0xA565D598]
Session ID: 0
IKEv1 SA: local 193.190.25.25/500 remote 195.13.206.1/500 Active
Capabilities:(none) connid:1007 lifetime:13:24:41
Crypto Session Status: UP-ACTIVE
fvrf: GW,
Phase1_id: 195.13.206.1
IPSEC FLOW: permit 47 host 193.190.25.25 host 195.13.206.1

Active SAs: 2, origin: crypto map
Inbound:
#pkts dec'ed 144455 drop 0 life (KB/Sec) 4342871/3551
Outbound: #pkts enc'ed 139354 drop 0 life (KB/Sec) 4342871/3551

Outbound SPI : 0xAD39BEA1, transform : esp-aes esp-sha-hmac
Socket State: Open

Version 5.1B
265 | P a g e

dst
src
state
193.190.25.25
195.13.206.1
QM_IDLE
conn-id status
1007 ACTIVE
R25#show crypto ipsec sa | inc Status|pkts

#pkts encaps: 139388, #pkts encrypt: 139388, #pkts digest: 139388
#pkts decaps: 144490, #pkts decrypt: 144490, #pkts verify: 144490
#pkts compressed: 0, #pkts decompressed: 0
#pkts not compressed: 0, #pkts compr. failed: 0
#pkts not decompressed: 0, #pkts decompress failed: 0
266 | P a g e
Version 5.1B

Section 4.0: IP Security

Task 4.1:
Device Security
(5 points)
(3 points)
Configure R9 in the iPexpert RTP office as per the following requirements:

o
All users who connect from R2 to R9 via VTY line using telnet & using the username
"OPERATOR" and Password "CISCO" must be prompted with the displayed menu.
No other users should receive this menu.
Leave one line for regular telnet access authenticating users with the Local Database.
Every single function in the menu must display the correct output.
R2#telnet 172.16.9.254 /vrf YELLOW

Trying 172.16.9.254 ... Open
User Access Verification

Username: OPERATOR
Password:
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - IPexpert Operator Menu - - - - - - - - Welcome To IPXpert's
Operator Menu
Authorized users only,
violaters will be shot on sight!
use this menu for ADMIN Operations
Choose desired function
- - - - - - - - - - - - - - - - - - - - - - - - - - 1
Display Routing table
Display Running Config
Escape to Shell
Disconnect
Version 5.1B
267 | P a g e

Solution
For this task we are asked to create a menu which will be displayed for particular admin user
connecting to the router via telnet. The menu will allow us to operate admin functionalities without
having to be familiar with the syntax.
NOTE
Solving this task is based either on previous hands-on experience or solving this using your skills to
explore the cisco DOC. Remember that a CCIE is expected to be familiar with a wide variety of
technologies and solutions but also means that you have the ability to quickly learn new topics.
* This can be found in the cisco DOC under:
Support HomeProducts > IOS and NX-OS SoftwareIOS > IOS Software Release 15M&T > IOS 15.4M&T >
Master Index ... "m
First, configure the menu title according to the requirements.
R9
R9(config)#menu OPERATOR title #
Enter TEXT message.
End with the character '#'.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - IPexpert Operator Menu - - - - - - - - Welcome To IPXpert's

Operator Menu
- - - - - - - - - - - - - - - - - - - - - - - - - - #
Second, we configure the menu text for each line and also the command to be run with it.
R9
R9(config)#menu OPERATOR text 1 Display Routing table
R9(config)#menu OPERATOR command 1 show ip route
R9(config)#menu OPERATOR text 2 Display Running Config
R9(config)#menu OPERATOR command 2 show run
268 | P a g e
Version 5.1B

R9(config)#menu OPERATOR text 3 Escape to Shell
R9(config)#menu OPERATOR command 3 menu-exit
R9(config)#menu OPERATOR text 4 Disconnect
R9(config)#menu OPERATOR command 4 exit
Last, we will complete the configuration by setting the username we were asked to in the task
requirements. Also, make sure to enable one VTY line to use local authentication on a non-standard
port and allow the telnet service in.
R9
R9(config)#username OPERATOR autocommand menu OPERATOR
R9(config)#username OPERATOR password CISCO
R9(config)#username OPERATOR privilege 15
R9(config)#line vty 0 3
R9(config-line)#login
R9(config-line)#transport input none
R9(config-line)#line vty 4
R9(config-line)#login local
R9(config-line)#rotary 4
R9(config-line)#transport input telnet
Verification
The verification for this task is rather easy, just telnet to R9 and execute each operation for validating
its functionality.
R2
R2#telnet 172.16.9.254 /vrf YELLOW
Trying 172.16.9.254 ... Open
User Access Verification

Username: OPERATOR
Password:
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - IPexpert Operator Menu - - - - - - - - Welcome To IPXpert's
Operator Menu
Version 5.1B
269 | P a g e

- - - - - - - - - - - - - - - - - - - - - - - - - - 1
Display Routing table
Display Running Config
Escape to Shell
Disconnect
Task 4.2:
Network Security
(2 points)
Refer to "Diagram 1: Layer topology."

The IPexpert New York office holds business critical information, for that reason we need to limit
unknown or rogue users from connecting to our network, configure the office as per the
following requirements:
o
Ensure that interfaces E0/1-3, and E1/2-E1/3 of SW2 forward traffic that was sent from
expected and legitimate hosts and servers.
SW2 must dynamically learn only one MAC address per port and must save the MAC
address in its startup configuration.
SW2 must shut down the port if a security violation occurs on any of these ports.
Solution
At first glance this task seems to be easy, we are asked to restrict rouge users access to the network.
But once we look into the specific interfaces configuration we can see that we have two interfaces
(Ethernet 0/2-3) which are 802.1q trunk ports, which require us to address each mac-address per
every vlan which is set on that trunk link, meaning that we would want to limit 1x mac-address per
vlan unlike 1x mac-address per interface.
SW2
SW2(config)#interface range e0/1,e1/2-3
SW2(config-if-range)#switchport port-security mac-address sticky
SW2(config-if-range)#switchport port-security max 1
SW2(config-if-range)#switchport port-security violation shutdown
SW2(config-if-range)#switchport port-security
Now, we will address the 802.1q interfaces (note here we allow 1 MAC address per VLAN) :
270 | P a g e
Version 5.1B

SW2
SW2(config)#interface range e0/2-3
SW2(config-if-range)#switchport port-security mac-addr sticky
SW2(config-if-range)#switchport port-security max 1 vlan
SW2(config-if-range)#switchport port-security violation shutdown
SW2(config-if-range)#switchport port-security
Verification
Let's verify the functionality of the switchport port-security using one global command.
SW2
SW2#sh port-security
Secure Port
MaxSecureAddr
CurrentAddr
(Count)
(Count)
SecurityViolation
Security Action
(Count)
----------------------------------------------------------------------Et0/1
Shutdown
Et0/2
Shutdown
Et0/3
Shutdown
Et1/2
Shutdown
Et1/3
Shutdown
--------------------------------------------------------------------------Total Addresses in System (excluding one mac per port)
: 0
SW2#sh port-security address

Secure Mac Address Table
----------------------------------------------------------------------------Vlan
Mac Address
Type
Ports
Remaining Age
(mins)
----
-----------
----
-----
-------------
61
aabb.cc00.0100
SecureDynamic
Et0/1
61
aabb.cc00.0600
SecureDynamic
Et1/2
17
aabb.cc00.0700
SecureDynamic
Et1/3
----------------------------------------------------------------------------Total Addresses in System (excluding one mac per port)
: 0
Version 5.1B
271 | P a g e

Section 5.0: Infrastructure Services

Task 5.1:
(4 points)
Configuration Change Notification
(2 points)
The New York branch needs a CLI configuration auditing solution, one that doesn't require
purchasing any new devices/servers such as TACACS+ or any AAA solution.
Configure routers R1-R3 in ASN 12345 to locally track changes made to its running configuration.
o
Track changes made to the Cisco software running configuration by maintaining a

configuration log.
Log these changes to syslog.
Ensure that passwords in the configuration will not be sent across this communication
channel.
Limit the maximum number of logged commands that will be kept by the config log to a
maximum of 1000 entries.
Verify this on all routers by typing the following commands and receiving the same
output:
conf t
RX (config)#int e0/0
*May 16 15:49:25.578 UTC: %PARSER-5-CFGLOG_LOGGEDCMD: User:console

command:interface Ethernet0/0
logged
Solution
This is an easy task, again as for task 4.1 you either are familiar with the configurations or you need to
rely on the Cisco DOC. Let's configure this:
R1, R2, R3
RX(config)#archive
RX(config-archive)#log config
RX(config-archive-log-cfg)#logging enable
RX(config-archive-log-cfg)#logging size 200
RX(config-archive-log-cfg)#hidekeys
RX(config-archive-log-cfg)#notify syslog
272 | P a g e
Version 5.1B

Verification
The verification for this task is rather easy, just enter configure terminal, int e0/0 and see the
magic happen. You dont have to repeat this verification for other routers if you copied-pasted the
config.
R1
R1(config)#int e0/0
R1(config-if)#
command:interface Ethernet0/0
logged
R1(config-if)#end
R1#
logged command:end
R1#show archive log config all

idx
sess
user@line
Logged command
console@console
logging enable
console@console
logging size 200
console@console
hidekeys
console@console
notify syslog
console@console
|interface Ethernet0/0
console@console
console@console
console@console
| exit
Task 5.2:
Network Optimization
(2 points)
Configure R20 as per the following requirement:

o
The output that is shown below must be seen on R20 during 10 seconds after R25
successfully pinged interface Lo21 of R21.
R21#ping 172.16.25.254 source lo21

!!!!!
Version 5.1B
273 | P a g e

R20#show ip flow top-talkers
SrcIf
SrcIPaddress
DstIf
DstIPaddress
Pr SrcP DstP Bytes
Et0/1
172.16.21.254
Tu0*
172.16.25.254
01 0000 0800
500
1 of 10 top talkers shown. 1 of 1 flows matched.
Solution
This task can be easy to lose points on, make sure to match all fields in the output.
NOTE
If you aren't familiar with this configuration then you might consider skipping this and leaving it for the
end, if you have any spare time left.
R20
R20(config-if)#ip flow egress
R20(config-if)#ip flow-top-talkers
R20(config-flow-top-talkers)#match source address 172.16.21.254/32
R20(config-flow-top-talkers)#match destination address 172.16.25.254/32
R20(config-flow-top-talkers)#cache-timeout 10000
R20(config-flow-top-talkers)#top 10
R20(config-flow-top-talkers)#sort-by bytes
Verification
This task can be tricky, make sure to match the output exactly as in the task requirements. Let's
generate traffic from R21 towards R25, it is important to do as the task asks or otherwise, e.g. if we
generate traffic the other way around, R25 towards R21, we will get a different output result which
might be confusing.
NOTE
Pay close attention to the highlighted sections, these must be exact.
274 | P a g e
Version 5.1B

R21
R21#ping 172.16.25.254 source loopback21
!!!!!
R20
R20#sh ip flow top-talkers
SrcIf
SrcIPaddress
DstIf
DstIPaddress
Pr SrcP DstP Bytes
Et0/1
172.16.21.254
Tu0*
172.16.25.254
01 0000 0800
500
1 of 10 top talkers shown. 1 of 1 flows matched.
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 concludes the Configuration Section and iPexpert's R&S Lab 5 DSG, Volume 2
Version 5.1B
275 | P a g e

IPexpert&#39;s CCIE R&amp;S (v5) Mock Lab Workbook (Vol. 2) Lab 5 DSG

Transféré par

Informations du document

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

IPexpert&#39;s CCIE R&amp;S (v5) Mock Lab Workbook (Vol. 2) Lab 5 DSG

Transféré par

Droits d'auteur :

Formats disponibles

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

CCIE Routing & Switching

iPexpert's Detailed Solution Guide

iPexpert's Detailed Solution Guide

iPexpert's End-User License Agreement

iPexpert's Detailed Solution Guide

U.S. Government - Restricted Rights

iPexpert's Detailed Solution Guide

Welcome, and Thank You!

Technical Support and Freebies

iPexpert's Detailed Solution 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 Solution Guide

Lab Exam Grading

iPexpert's Detailed Solution Guide

Reevaluation of Lab Results

iPexpert's Detailed Solution Guide

Lab 5: Troubleshooting Section :: Detailed

iPexpert's Detailed Solution Guide

iPexpert's Detailed Solution Guide

iPexpert's Detailed Solution Guide

iPexpert's Detailed Solution Guide

iPexpert's Detailed Solution Guide

iPexpert's Detailed Solution Guide

iPexpert's Detailed Solution Guide

10.4.4.0/24 [170/542771200] via 192.168.24.6, 03:11:05, Serial2/0

10.13.13.0/24 [90/27008000] via 40.40.40.13, 00:00:16, Tunnel66

10.15.15.0/24 [90/27033600] via 40.40.40.13, 00:00:16, Tunnel66

10.23.23.0/24 [170/28288000] via 40.40.40.23, 00:00:09, Tunnel66

10.25.25.0/24 [170/28288000] via 40.40.40.25, 00:00:09, Tunnel66

172.5.5.0 [90/27033600] via 40.40.40.13, 00:00:16, Tunnel66

172.16.200.0 [90/26905856] via 40.40.40.13, 00:00:16, Tunnel66

172.16.214.0 [90/26905600] via 40.40.40.13, 00:00:16, Tunnel66

172.16.215.0 [90/26905600] via 40.40.40.13, 00:00:16, Tunnel66

172.16.216.0 [90/26931200] via 40.40.40.13, 00:00:16, Tunnel66

192.168.0.0/16 [170/542771200] via 192.168.24.6, 03:11:05, Serial2/0

192.168.13.0/24 [90/34036062] via 192.168.24.6, 03:11:05, Serial2/0

192.168.15.0/24 [90/27417600] via 40.40.40.13, 00:00:16, Tunnel66

192.168.23.0/24 [90/44276062] via 192.168.24.6, 03:11:05, Serial2/0

192.168.25.0/24 [90/23796062] via 192.168.24.6, 03:11:05, Serial2/0

192.168.74.0/24 [90/34036062] via 192.168.24.6, 03:11:05, Serial2/0

192.168.76.0/24 [90/23796062] via 192.168.24.6, 03:11:05, Serial2/0

iPexpert's Detailed Solution Guide

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

10.24.24.0/24 is directly connected, Loopback0

10.24.24.24/32 is directly connected, Loopback0

40.40.40.0/24 is directly connected, Tunnel66

40.40.40.24/32 is directly connected, Tunnel66

192.168.0.0/16 [170/542771200] via 192.168.24.6, 2w0d, Serial2/0

192.168.13.0/24 [90/34036062] via 192.168.24.6, 2w0d, Serial2/0

192.168.15.0/24 [90/34036062] via 192.168.24.6, 5d22h, Serial2/0

192.168.23.0/24 [90/44276062] via 192.168.24.6, 2w0d, Serial2/0

192.168.24.0/24 is directly connected, Serial2/0

192.168.24.24/32 is directly connected, Serial2/0

192.168.25.0/24 [90/23796062] via 192.168.24.6, 2w0d, Serial2/0

192.168.74.0/24 [90/34036062] via 192.168.24.6, 2w0d, Serial2/0

192.168.76.0/24 [90/23796062] via 192.168.24.6, 2w0d, Serial2/0

iPexpert's Detailed Solution Guide

IPexpert's CCIE R&S (v5) Mock Lab Workbook (Vol. 2) Lab 5 DSG

IPexpert's CCIE R&S (v5) Mock Lab Workbook (Vol. 2) Lab 5 DSG