Professional Documents
Culture Documents
IPexpert S CCIE R S v5 Mock Lab Workbook Vol 2 Lab 5 DSG PDF
IPexpert S CCIE R S v5 Mock Lab Workbook Vol 2 Lab 5 DSG PDF
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
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.
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.
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.
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 LICENSOR’S LIABILITY UNDER, ARISING OUT OF, OR RELATING TO THIS
AGREEMENT EXCEED THE AMOUNT PAID TO LICENSOR FOR THE TRAINING MATERIALS. LICENSOR SHALL NOT BE LIABLE FOR ANY SPECIAL,
INCIDENTAL, INDIRECT, OR CONSEQUENTIAL DAMAGES, HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, REGARDLESS OF WHETHER
LICENSOR HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. WITHOUT LIMITING THE FOREGOING, LICENSOR WILL NOT BE LIABLE FOR
LOST PROFITS, LOSS OF DATA, OR COSTS OF COVER.
Entire Agreement
This is the entire agreement between the parties and may not be modified except in writing signed by both parties.
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.
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.
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).
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.
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.
NOTE
The following information has been obtained from Cisco's Learning Network. We are not affiliated
with, or endorsed in any way by Cisco.
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.
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.
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.
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.
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
iPexpert's Detailed Solution Guide
for Cisco's CCIE Routing and Switching Lab Exam, Volume 2, Lab 5
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
iPexpert's Detailed Solution Guide
for Cisco's CCIE Routing and Switching Lab Exam, Volume 2, Lab 5
Diagram 5.1
12 | P a g e Version 5.1B
iPexpert's Detailed Solution Guide
for Cisco's CCIE Routing and Switching Lab Exam, Volume 2, Lab 5
Diagram 5.2
Version 5.1B 13 | P a g e
iPexpert's Detailed Solution Guide
for Cisco's CCIE Routing and Switching Lab Exam, Volume 2, Lab 5
Diagram 5.3
14 | P a g e Version 5.1B
iPexpert's Detailed Solution Guide
for Cisco's CCIE Routing and Switching Lab Exam, Volume 2, Lab 5
Diagram 5.4
Version 5.1B 15 | P a g e
iPexpert's Detailed Solution Guide
for Cisco's CCIE Routing and Switching Lab Exam, Volume 2, Lab 5
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
iPexpert's Detailed Solution Guide
for Cisco's CCIE Routing and Switching Lab Exam, Volume 2, Lab 5
R24
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
iPexpert's Detailed Solution Guide
for Cisco's CCIE Routing and Switching Lab Exam, Volume 2, Lab 5
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
18 | P a g e Version 5.1B
iPexpert's Detailed Solution Guide
for Cisco's CCIE Routing and Switching Lab Exam, Volume 2, Lab 5
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
========================================================================
# Ent Peer NBMA Addr Peer Tunnel Add State UpDn Tm Attrb
----- --------------- --------------- ----- -------- -----
1 192.168.13.13 40.40.40.13 IKE 00:00:30 S
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
Version 5.1B 19 | P a g e
iPexpert's Detailed Solution Guide
for Cisco's CCIE Routing and Switching Lab Exam, Volume 2, Lab 5
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
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
20 | P a g e Version 5.1B
iPexpert's Detailed Solution Guide
for Cisco's CCIE Routing and Switching Lab Exam, Volume 2, Lab 5
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
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
iPexpert's Detailed Solution Guide
for Cisco's CCIE Routing and Switching Lab Exam, Volume 2, Lab 5
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
R24
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
22 | P a g e Version 5.1B
iPexpert's Detailed Solution Guide
for Cisco's CCIE Routing and Switching Lab Exam, Volume 2, Lab 5
R13
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
# Ent Peer NBMA Addr Peer Tunnel Add State UpDn Tm Attrb
----- --------------- --------------- ----- -------- -----
Version 5.1B 23 | P a g e
iPexpert's Detailed Solution Guide
for Cisco's CCIE Routing and Switching Lab Exam, Volume 2, Lab 5
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
24 | P a g e Version 5.1B
iPexpert's Detailed Solution Guide
for Cisco's CCIE Routing and Switching Lab Exam, Volume 2, Lab 5
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
Version 5.1B 25 | P a g e
iPexpert's Detailed Solution Guide
for Cisco's CCIE Routing and Switching Lab Exam, Volume 2, Lab 5
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
26 | P a g e Version 5.1B
iPexpert's Detailed Solution Guide
for Cisco's CCIE Routing and Switching Lab Exam, Volume 2, Lab 5
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
ip nat inside source static udp 192.168.24.24 500 192.168.76.6 500 extendable
ip nat inside source static udp 192.168.24.24 4500 192.168.76.6 4500 extendable
end
Version 5.1B 27 | P a g e
iPexpert's Detailed Solution Guide
for Cisco's CCIE Routing and Switching Lab Exam, Volume 2, Lab 5
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
iPexpert's Detailed Solution Guide
for Cisco's CCIE Routing and Switching Lab Exam, Volume 2, Lab 5
R14
R14#ping 172.16.200.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.16.200.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/1 ms
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
…
Gateway of last resort is not set
Version 5.1B 29 | P a g e
iPexpert's Detailed Solution Guide
for Cisco's CCIE Routing and Switching Lab Exam, Volume 2, Lab 5
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
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
30 | P a g e Version 5.1B
iPexpert's Detailed Solution Guide
for Cisco's CCIE Routing and Switching Lab Exam, Volume 2, Lab 5
Building configuration...
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
Version 5.1B 31 | P a g e
iPexpert's Detailed Solution Guide
for Cisco's CCIE Routing and Switching Lab Exam, Volume 2, Lab 5
R15
32 | P a g e Version 5.1B
iPexpert's Detailed Solution Guide
for Cisco's CCIE Routing and Switching Lab Exam, Volume 2, Lab 5
R14
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
iPexpert's Detailed Solution Guide
for Cisco's CCIE Routing and Switching Lab Exam, Volume 2, Lab 5
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
34 | P a g e Version 5.1B
iPexpert's Detailed Solution Guide
for Cisco's CCIE Routing and Switching Lab Exam, Volume 2, Lab 5
The pool says it is exhausted, we can also see that the client-identifier is different,
let's modify this:
R13 / R15
R14
R14(config)#interface e0/1
R14(config-if)#shutdown
R14(config-if)#no shutdown
R14
R14#sh ip route
…
Gateway of last resort is 172.16.100.1 to network 0.0.0.0
R14#ping 172.16.200.2
Type escape sequence to abort.
Version 5.1B 35 | P a g e
iPexpert's Detailed Solution Guide
for Cisco's CCIE Routing and Switching Lab Exam, Volume 2, Lab 5
Summary of Changes
R13 / R15
conf t
ip dhcp pool VLAN100-HOST
no client-identifier 01aa.bbcc.000a.10
client-identifier 01aa.bbcc.000e.10
end
36 | P a g e Version 5.1B
iPexpert's Detailed Solution Guide
for Cisco's CCIE Routing and Switching Lab Exam, Volume 2, Lab 5
Incident 3 (2 points)
• Isolate and fix the issues so that it is reachable from ISP3, the outputs should match the below:
ISP3#ping 10.102.102.102
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.102.102.102, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 11/16/20 ms
Version 5.1B 37 | P a g e
iPexpert's Detailed Solution Guide
for Cisco's CCIE Routing and Switching Lab Exam, Volume 2, Lab 5
Solution
First, verify that ISP3 has no connectivity to ISP2 network 10.102.102.0/24:
ISP3
ISP3#traceroute 10.102.102.102
Type escape sequence to abort.
Tracing the route to 10.102.102.102
VRF info: (vrf in name/id, vrf out name/id)
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
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 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
With the above output, we identified that ISP2 has no peer address for its PPP link.
The reasons for that can be:
38 | P a g e Version 5.1B
iPexpert's Detailed Solution Guide
for Cisco's CCIE Routing and Switching Lab Exam, Volume 2, Lab 5
• wrong encapsulation
• missing local credentials for identifying the remote side (or vice versa)
ISP1
ISP2
Version 5.1B 39 | P a g e
iPexpert's Detailed Solution Guide
for Cisco's CCIE Routing and Switching Lab Exam, Volume 2, Lab 5
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: AuthProto CHAP (0x0305C22305)
*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: AuthProto CHAP (0x0305C22305)
*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
iPexpert's Detailed Solution Guide
for Cisco's CCIE Routing and Switching Lab Exam, Volume 2, Lab 5
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:
ISP1
Version 5.1B 41 | P a g e
iPexpert's Detailed Solution Guide
for Cisco's CCIE Routing and Switching Lab Exam, Volume 2, Lab 5
ISP3
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
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
iPexpert's Detailed Solution Guide
for Cisco's CCIE Routing and Switching Lab Exam, Volume 2, Lab 5
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
Gateway of last resort is not set
ISP3
ISP3#traceroute 10.102.102.102
Type escape sequence to abort.
Tracing the route to 10.102.102.102
VRF info: (vrf in name/id, vrf out name/id)
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
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.102.102.102, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 17/17/18 ms
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
iPexpert's Detailed Solution Guide
for Cisco's CCIE Routing and Switching Lab Exam, Volume 2, Lab 5
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
iPexpert's Detailed Solution Guide
for Cisco's CCIE Routing and Switching Lab Exam, Volume 2, Lab 5
Incident 4 (2 points)
• Troubleshoot and fix the issues so that both sites have reachability.
Version 5.1B 45 | P a g e
iPexpert's Detailed Solution Guide
for Cisco's CCIE Routing and Switching Lab Exam, Volume 2, Lab 5
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/1 ms
Solution
Let’s 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
R20
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
Gateway of last resort is not set
46 | P a g e Version 5.1B
iPexpert's Detailed Solution Guide
for Cisco's CCIE Routing and Switching Lab Exam, Volume 2, Lab 5
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#ping 132.56.20.20
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 132.56.20.20, timeout is 2 seconds:
.....
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
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
Version 5.1B 47 | P a g e
iPexpert's Detailed Solution Guide
for Cisco's CCIE Routing and Switching Lab Exam, Volume 2, Lab 5
SW8
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 mac-
address 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
iPexpert's Detailed Solution Guide
for Cisco's CCIE Routing and Switching Lab Exam, Volume 2, Lab 5
SW8#sh port-security
Secure Port MaxSecureAddr CurrentAddr SecurityViolation Security Action
(Count) (Count) (Count)
---------------------------------------------------------------------------
Et1/1 1 1 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
iPexpert's Detailed Solution Guide
for Cisco's CCIE Routing and Switching Lab Exam, Volume 2, Lab 5
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
R20
Summary of Changes
SW8
conf t
interface e1/1
shutdown
switchport access vlan 1820
no switchport port-security mac-address sticky
switchport port-security mac-address sticky
no shutdown
50 | P a g e Version 5.1B
iPexpert's Detailed Solution Guide
for Cisco's CCIE Routing and Switching Lab Exam, Volume 2, Lab 5
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
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2001:50:50::50, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 25/28/30 ms
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
iPexpert's Detailed Solution Guide
for Cisco's CCIE Routing and Switching Lab Exam, Volume 2, Lab 5
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
ISP3#ping www.global.com
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2001:50:50::50, timeout is 2 seconds:
AAAAA
Success rate is 0 percent (0/5)
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
Translating "www.global.com"...domain server (255.255.255.255)
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
52 | P a g e Version 5.1B
iPexpert's Detailed Solution Guide
for Cisco's CCIE Routing and Switching Lab Exam, Volume 2, Lab 5
ISP1
R50
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
Version 5.1B 53 | P a g e
iPexpert's Detailed Solution Guide
for Cisco's CCIE Routing and Switching Lab Exam, Volume 2, Lab 5
ISP3
ISP3#ping www.global.com
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2001:50:50::50, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 25/25/26 ms
ISP3#telnetwork www.global.com 80
Translating "www.global.com"...domain server (255.255.255.255)
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
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
54 | P a g e Version 5.1B
iPexpert's Detailed Solution Guide
for Cisco's CCIE Routing and Switching Lab Exam, Volume 2, Lab 5
ISP3
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
Version 5.1B 55 | P a g e
iPexpert's Detailed Solution Guide
for Cisco's CCIE Routing and Switching Lab Exam, Volume 2, Lab 5
Summary of Changes
R50
56 | P a g e Version 5.1B
iPexpert's Detailed Solution Guide
for Cisco's CCIE Routing and Switching Lab Exam, Volume 2, Lab 5
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
iPexpert's Detailed Solution Guide
for Cisco's CCIE Routing and Switching Lab Exam, Volume 2, Lab 5
R2
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
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
iPexpert's Detailed Solution Guide
for Cisco's CCIE Routing and Switching Lab Exam, Volume 2, Lab 5
R2
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
Version 5.1B 59 | P a g e
iPexpert's Detailed Solution Guide
for Cisco's CCIE Routing and Switching Lab Exam, Volume 2, Lab 5
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
R50
60 | P a g e Version 5.1B
iPexpert's Detailed Solution Guide
for Cisco's CCIE Routing and Switching Lab Exam, Volume 2, Lab 5
R2
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
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
R2
Version 5.1B 61 | P a g e
iPexpert's Detailed Solution Guide
for Cisco's CCIE Routing and Switching Lab Exam, Volume 2, Lab 5
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
62 | P a g e Version 5.1B
iPexpert's Detailed Solution Guide
for Cisco's CCIE Routing and Switching Lab Exam, Volume 2, Lab 5
Summary of Changes
R2
conf t
router bgp 7200
address-family ipv4 vrf ISP
no neighbor 123.10.1.6 password ipx$S
neighbor 123.10.1.6 password ipx$2
end
R50
conf t
router bgp 20001
no neighbor 123.10.1.5 remote-as 72000
neighbor 123.10.1.5 remote-as 7200
neighbor 123.10.1.5 password ipx$2
neighbor 123.10.1.5 send-community both
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
iPexpert's Detailed Solution Guide
for Cisco's CCIE Routing and Switching Lab Exam, Volume 2, Lab 5
Incident 7 (3 points)
• Fix the issue so that the following sequence of commands produces the same relevant result:
R50
64 | P a g e Version 5.1B
iPexpert's Detailed Solution Guide
for Cisco's CCIE Routing and Switching Lab Exam, Volume 2, Lab 5
ISP4
ISP4#ping 8.8.8.8
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 8.8.8.8, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 27/28/30 ms
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
Type escape sequence to abort.
Tracing the route to 192.168.44.1
VRF info: (vrf in name/id, vrf out name/id)
1 * * *
2 * * *
ISP4
ISP4#ping 8.8.8.8
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 8.8.8.8, timeout is 2 seconds:
..
Success rate is 0 percent (0/5)
ISP4#sh ip route
… <output omitted>
Gateway of last resort is not set
10.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
C 10.104.104.0/24 is directly connected, Loopback0
L 10.104.104.104/32 is directly connected, Loopback0
B 192.168.0.0/16 [200/0] via 0.0.0.0, 2w1d, Null0
D 192.168.13.0/24 [90/23796062] via 192.168.74.7, 2w1d, Serial4/0
L 192.168.74.4/32 is directly connected, Serial4/0
D 192.168.76.0/24 [90/23796062] via 192.168.74.7, 2w1d, Serial4/0
Version 5.1B 65 | P a g e
iPexpert's Detailed Solution Guide
for Cisco's CCIE Routing and Switching Lab Exam, Volume 2, Lab 5
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 ip vrf
Name Default RD Interfaces
Customer_B 245:10 Se2/0
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
iPexpert's Detailed Solution Guide
for Cisco's CCIE Routing and Switching Lab Exam, Volume 2, Lab 5
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
neighbor 192.168.44.1 remote-as 65505
neighbor 192.168.44.1 activate
R2
Version 5.1B 67 | P a g e
iPexpert's Detailed Solution Guide
for Cisco's CCIE Routing and Switching Lab Exam, Volume 2, Lab 5
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
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
Type escape sequence to abort.
Tracing the route to 192.168.44.1
VRF info: (vrf in name/id, vrf out name/id)
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
iPexpert's Detailed Solution Guide
for Cisco's CCIE Routing and Switching Lab Exam, Volume 2, Lab 5
ISP4
ISP4#ping 8.8.8.8
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 8.8.8.8, timeout is 2 seconds:
!!!!!
Summary of Changes
R4
conf t
ip vrf Customer_B
no route-target import 10100:100
route-target import 10100:10
end
clear ip bgp *
Version 5.1B 69 | P a g e
iPexpert's Detailed Solution Guide
for Cisco's CCIE Routing and Switching Lab Exam, Volume 2, Lab 5
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.
NOTE
While resolving this issue, you are not allowed to create any new interface.
70 | P a g e Version 5.1B
iPexpert's Detailed Solution Guide
for Cisco's CCIE Routing and Switching Lab Exam, Volume 2, Lab 5
Solution
Start by verifying if we have reachability to BB1 from R5.
R5
R5#ping 192.1.1.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.1.1.2, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)
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
R1
Version 5.1B 71 | P a g e
iPexpert's Detailed Solution Guide
for Cisco's CCIE Routing and Switching Lab Exam, Volume 2, Lab 5
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
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: Tunnel1, IPv4 NHRP Details
Type:Spoke, NHRP Peers:1,
# Ent Peer NBMA Addr Peer Tunnel Add State UpDn Tm Attrb
----- --------------- --------------- ----- -------- -----
1 194.45.67.17 172.20.0.5 NHRP 00:01:44 S
R5
R5#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: Tunnel1, IPv4 NHRP Details
Type:Hub, NHRP Peers:1,
# Ent Peer NBMA Addr Peer Tunnel Add State UpDn Tm Attrb
----- --------------- --------------- ----- -------- -----
1 136.78.90.1 172.20.0.1 UP 00:05:07 D
72 | P a g e Version 5.1B
iPexpert's Detailed Solution Guide
for Cisco's CCIE Routing and Switching Lab Exam, Volume 2, Lab 5
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
Version 5.1B 73 | P a g e
iPexpert's Detailed Solution Guide
for Cisco's CCIE Routing and Switching Lab Exam, Volume 2, Lab 5
We are not advertising network 136.78.90.0/30 into BGP and that is the fault, let's fix that on R3.
R3
R5
R5#sh ip route
…<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
iPexpert's Detailed Solution Guide
for Cisco's CCIE Routing and Switching Lab Exam, Volume 2, Lab 5
R1
R1#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: Tunnel1, IPv4 NHRP Details
Type:Spoke, NHRP Peers:1,
# Ent Peer NBMA Addr Peer Tunnel Add State UpDn Tm Attrb
----- --------------- --------------- ----- -------- -----
1 194.45.67.17 172.20.0.5 UP 00:02:30 S
R5
R5#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
==========================================================================
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
Version 5.1B 75 | P a g e
iPexpert's Detailed Solution Guide
for Cisco's CCIE Routing and Switching Lab Exam, Volume 2, Lab 5
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
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#sh ip ei neighbors
EIGRP-IPv4 VR(CCIE) Address-Family Neighbors for AS(400)
76 | P a g e Version 5.1B
iPexpert's Detailed Solution Guide
for Cisco's CCIE Routing and Switching Lab Exam, Volume 2, Lab 5
Our tunnel interface is now up and our EIGRP neighbor is stable, we should now try the TFTP
download.
R5
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
Version 5.1B 77 | P a g e
iPexpert's Detailed Solution Guide
for Cisco's CCIE Routing and Switching Lab Exam, Volume 2, Lab 5
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
iPexpert's Detailed Solution Guide
for Cisco's CCIE Routing and Switching Lab Exam, Volume 2, Lab 5
BB3
BB3#ping 172.9.9.9
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.9.9.9, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/1 ms
SW2#sh ip route 172.9.9.9
Routing entry for 172.9.9.9/32
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
Routing Descriptor Blocks:
* 172.17.218.2, from 172.17.218.2, 00:00:02 ago, via Vlan218
Route metric is 307232, traffic share count is 1
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
Route metric is 307232, traffic share count is 1
Total delay is 2001 microseconds, minimum bandwidth is 10000 Kbit
Reliability 255/255, minimum MTU 1500 bytes
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
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.9.9.9, timeout is 2 seconds:
.!!!!
Success rate is 80 percent (4/5), round-trip min/avg/max = 1/1/1 ms
Version 5.1B 79 | P a g e
iPexpert's Detailed Solution Guide
for Cisco's CCIE Routing and Switching Lab Exam, Volume 2, Lab 5
SW2
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
172.17.12.1 (Vlan12), from 172.17.12.1, Send flag is 0x0
Composite metric is (307232/28192), route is Internal
Vector metric:
Minimum bandwidth is 10000 Kbit
Total delay is 2001 microseconds
Reliability is 255/255
Load is 1/255
Minimum MTU is 1500
Hop count is 2
80 | P a g e Version 5.1B
iPexpert's Detailed Solution Guide
for Cisco's CCIE Routing and Switching Lab Exam, Volume 2, Lab 5
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
Version 5.1B 81 | P a g e
iPexpert's Detailed Solution Guide
for Cisco's CCIE Routing and Switching Lab Exam, Volume 2, Lab 5
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
82 | P a g e Version 5.1B
iPexpert's Detailed Solution Guide
for Cisco's CCIE Routing and Switching Lab Exam, Volume 2, Lab 5
Remember, we must match the output exactly as the incident depicts, there are other solutions but
they will not match our given output.
SW2
Summary of Changes
SW2
conf t
interface vlan218
delay 100
Version 5.1B 83 | P a g e
iPexpert's Detailed Solution Guide
for Cisco's CCIE Routing and Switching Lab Exam, Volume 2, Lab 5
Incident 10 (2 points)
• User BB3 is unable to reach the DNS server of 8.8.4.4 in the internet.
BB3
BB3#ping 8.8.4.4
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 8.8.4.4, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 24/26/30 ms
BB3#traceroute 8.8.4.4
Type escape sequence to abort.
Tracing the route to 8.8.4.4
84 | P a g e Version 5.1B
iPexpert's Detailed Solution Guide
for Cisco's CCIE Routing and Switching Lab Exam, Volume 2, Lab 5
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, let’s start by looking at the config for R5.
BB3
BB3#ping 8.8.4.4
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 8.8.4.4, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)
Version 5.1B 85 | P a g e
iPexpert's Detailed Solution Guide
for Cisco's CCIE Routing and Switching Lab Exam, Volume 2, Lab 5
You can see that traffic stops at R6, so we should go to R6 and review configs.
R6
The route exists and it points towards R2, let's see what path we are using to get to R2.
R6
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)#interface e0/1
R6(config-if)#mpls ip
86 | P a g e Version 5.1B
iPexpert's Detailed Solution Guide
for Cisco's CCIE Routing and Switching Lab Exam, Volume 2, Lab 5
BB3
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
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)#interface e0/1
R6(config-if)#ip ospf cost 1500
Version 5.1B 87 | P a g e
iPexpert's Detailed Solution Guide
for Cisco's CCIE Routing and Switching Lab Exam, Volume 2, Lab 5
BB3
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
iPexpert's Detailed Solution Guide
for Cisco's CCIE Routing and Switching Lab Exam, Volume 2, Lab 5
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
iPexpert's Detailed Solution Guide
for Cisco's CCIE Routing and Switching Lab Exam, Volume 2, Lab 5
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:
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
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:
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
iPexpert's Detailed Solution Guide
for Cisco's CCIE Routing and Switching Lab Exam, Volume 2, Lab 5
Dade Murphy
HelpDesk Representative
Office: 999-999-9999 | helpdesk@ipexpert.com
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 won’t 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
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
iPexpert's Detailed Solution Guide
for Cisco's CCIE Routing and Switching Lab Exam, Volume 2, Lab 5
Router Configuration
SW-BB Config
SW-BB#sh run
Building configuration...
ip subnet-zero
ip routing
no ip domain-lookup
ip domain-name blade.com
ip dhcp excluded-address 172.20.1.1 172.20.1.10
92 | P a g e Version 5.1B
iPexpert's Detailed Solution Guide
for Cisco's CCIE Routing and Switching Lab Exam, Volume 2, Lab 5
Version 5.1B 93 | P a g e
iPexpert's Detailed Solution Guide
for Cisco's CCIE Routing and Switching Lab Exam, Volume 2, Lab 5
vlan 503
name WIFI_HDS
!
interface GigabitEthernet1/0/1
description connect to voice_router
switchport access vlan 200
switchport mode access
spanning-tree portfast
!
interface GigabitEthernet1/0/2
description connect to ccm-pub
switchport access vlan 200
switchport mode access
spanning-tree portfast
!
interface GigabitEthernet1/0/3
description Line_60MB_To_SAP_Replication
switchport access vlan 22
switchport mode access
switchport nonegotiate
bandwidth 61440
load-interval 30
!
interface GigabitEthernet1/0/4
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
!
interface GigabitEthernet1/0/5
switchport access vlan 2
switchport mode access
switchport voice vlan 200
spanning-tree portfast
!
interface GigabitEthernet1/0/6
description ##_TO_FW_BLD-1_##
94 | P a g e Version 5.1B
iPexpert's Detailed Solution Guide
for Cisco's CCIE Routing and Switching Lab Exam, Volume 2, Lab 5
Version 5.1B 95 | P a g e
iPexpert's Detailed Solution Guide
for Cisco's CCIE Routing and Switching Lab Exam, Volume 2, Lab 5
interface GigabitEthernet1/0/11
description SAPDEV DR Replication Port
switchport access vlan 22
switchport mode access
spanning-tree portfast
!
interface GigabitEthernet1/0/12
description ESX-BLD-NIC2
switchport trunk encapsulation dot1q
switchport trunk native vlan 3
switchport trunk allowed vlan 2,3
switchport mode trunk
!
interface GigabitEthernet1/0/13
switchport access vlan 221
switchport mode access
load-interval 30
spanning-tree portfast
spanning-tree bpduguard enable
!
interface GigabitEthernet1/0/14
description PINEAPP
switchport access vlan 3
switchport mode access
spanning-tree portfast
spanning-tree bpduguard enable
!
interface GigabitEthernet1/0/15
description SAPDEV DR Replication Port
switchport access vlan 22
switchport mode access
spanning-tree portfast
!
interface GigabitEthernet1/0/16
switchport access vlan 3
switchport mode access
speed 1000
duplex full
spanning-tree portfast
96 | P a g e Version 5.1B
iPexpert's Detailed Solution Guide
for Cisco's CCIE Routing and Switching Lab Exam, Volume 2, Lab 5
!
interface GigabitEthernet1/0/17
description To FW_BLD_1 2200-1 (Lan5) for External WiFi Users
switchport access vlan 502
switchport mode access
switchport nonegotiate
spanning-tree portfast
spanning-tree bpdufilter enable
spanning-tree bpduguard enable
!
interface GigabitEthernet1/0/18
description HMC
switchport access vlan 3
switchport mode access
speed 1000
duplex full
spanning-tree portfast
!
interface GigabitEthernet1/0/19
switchport access vlan 3
switchport mode access
speed 1000
duplex full
spanning-tree portfast
!
interface GigabitEthernet1/0/20
description To FW_BLD_2 2200-1 (Lan5) for External WiFi Users
switchport access vlan 502
switchport mode access
switchport nonegotiate
spanning-tree portfast
spanning-tree bpdufilter enable
spanning-tree bpduguard enable
!
interface GigabitEthernet1/0/21
description connect to SW_2960_3_Backup
switchport trunk encapsulation dot1q
switchport mode trunk
storm-control broadcast level 5.00
Version 5.1B 97 | P a g e
iPexpert's Detailed Solution Guide
for Cisco's CCIE Routing and Switching Lab Exam, Volume 2, Lab 5
98 | P a g e Version 5.1B
iPexpert's Detailed Solution Guide
for Cisco's CCIE Routing and Switching Lab Exam, Volume 2, Lab 5
Version 5.1B 99 | P a g e
iPexpert's Detailed Solution Guide
for Cisco's CCIE Routing and Switching Lab Exam, Volume 2, Lab 5
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 123.1.1.57
access-list 5 permit 212.179.20.0 0.0.0.63
access-list 5 deny any
access-list 10 permit 123.2.2.123
access-list 10 permit 10.0.12.46
access-list 10 permit 10.0.12.45
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
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
Capability Codes: R - Router, T - Trans Bridge, B - Source Route Bridge
S - Switch, H - Host, I - IGMP, r - Repeater, P - Phone
BLD_SW1 Config
BLD_SW_1#sh run
Building configuration...
!
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
service password-encryption
!
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
!
!
aaa authentication login default group radius local
aaa authentication enable default enable
aaa authorization exec default group radius local
!
!
!
aaa session-id common
system mtu routing 1500
udld aggressive
ip subnet-zero
!
no ip domain-lookup
!
!
!
!
!
!
!
spanning-tree mode pvst
spanning-tree loopguard default
spanning-tree portfast bpduguard default
spanning-tree extend system-id
!
vlan internal allocation policy ascending
!
!
!
interface FastEthernet0/1
switchport access vlan 2
switchport mode access
switchport voice vlan 200
storm-control broadcast level 5.00
storm-control multicast level 5.00
storm-control action shutdown
spanning-tree portfast
!
interface FastEthernet0/2
switchport access vlan 2
switchport mode access
switchport voice vlan 200
storm-control broadcast level 5.00
storm-control multicast level 5.00
storm-control action shutdown
spanning-tree portfast
!
interface FastEthernet0/3
switchport access vlan 2
switchport mode access
switchport voice vlan 200
storm-control broadcast level 5.00
storm-control multicast level 5.00
storm-control action shutdown
spanning-tree portfast
!
interface FastEthernet0/4
interface FastEthernet0/17
switchport access vlan 2
switchport mode access
switchport voice vlan 200
storm-control broadcast level 5.00
storm-control multicast level 5.00
storm-control action shutdown
spanning-tree portfast
!
interface FastEthernet0/18
switchport access vlan 3
switchport mode access
switchport voice vlan 200
storm-control broadcast level 5.00
storm-control multicast level 5.00
storm-control action shutdown
spanning-tree portfast
!
interface FastEthernet0/19
switchport access vlan 2
switchport mode access
switchport voice vlan 200
storm-control broadcast level 5.00
storm-control multicast level 5.00
storm-control action shutdown
spanning-tree portfast
!
interface FastEthernet0/20
switchport access vlan 2
switchport mode access
switchport voice vlan 200
storm-control broadcast level 5.00
storm-control multicast level 5.00
storm-control action shutdown
spanning-tree portfast
!
interface FastEthernet0/21
switchport access vlan 2
switchport mode access
*********************************
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
!
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 clock-period 36029424
ntp server 10.1.0.1
end
BLD_SW2 Config
BLD_SW_2#sh run
Building configuration...
!
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
!
!
aaa authentication login default group radius local
aaa authentication enable default enable
aaa authorization exec default group radius local
!
!
!
aaa session-id common
system mtu routing 1500
udld aggressive
ip subnet-zero
!
no ip domain-lookup
!
!
!
!
!
!
!
spanning-tree mode pvst
spanning-tree loopguard default
spanning-tree portfast bpduguard default
spanning-tree extend system-id
!
vlan internal allocation policy ascending
!
!
!
interface FastEthernet0/1
switchport access vlan 500
switchport mode access
switchport voice vlan 200
storm-control broadcast level 5.00
storm-control multicast level 5.00
storm-control action shutdown
spanning-tree portfast
!
interface FastEthernet0/2
switchport access vlan 500
switchport mode access
switchport voice vlan 200
storm-control broadcast level 5.00
storm-control multicast level 5.00
storm-control action shutdown
spanning-tree portfast
!
interface FastEthernet0/3
switchport access vlan 500
switchport mode access
switchport voice vlan 200
storm-control broadcast level 5.00
storm-control multicast level 5.00
storm-control action shutdown
spanning-tree portfast
!
interface FastEthernet0/4
switchport access vlan 500
switchport mode access
switchport voice vlan 200
storm-control broadcast level 5.00
storm-control multicast level 5.00
storm-control action shutdown
spanning-tree portfast
!
interface FastEthernet0/5
description Printer ZEBRA
switchport access vlan 3
switchport mode access
switchport voice vlan 200
storm-control broadcast level 5.00
storm-control multicast level 5.00
storm-control action shutdown
spanning-tree portfast
!
interface FastEthernet0/6
switchport access vlan 500
switchport mode access
switchport voice vlan 200
storm-control broadcast level 5.00
storm-control multicast level 5.00
storm-control action shutdown
spanning-tree portfast
!
interface FastEthernet0/7
switchport access vlan 500
switchport mode access
switchport voice vlan 200
storm-control broadcast level 5.00
storm-control multicast level 5.00
storm-control action shutdown
spanning-tree portfast
!
interface FastEthernet0/8
description PRINTER (210.0.37.202)
switchport access vlan 3
switchport mode access
switchport voice vlan 200
storm-control broadcast level 5.00
storm-control multicast level 5.00
storm-control action shutdown
spanning-tree portfast
!
interface FastEthernet0/9
!
interface FastEthernet0/18
switchport access vlan 3
switchport mode access
switchport voice vlan 200
storm-control broadcast level 5.00
storm-control multicast level 5.00
storm-control action shutdown
spanning-tree portfast
!
interface FastEthernet0/19
switchport access vlan 500
switchport mode access
switchport voice vlan 200
storm-control broadcast level 5.00
storm-control multicast level 5.00
storm-control action shutdown
spanning-tree portfast
!
interface FastEthernet0/20
switchport access vlan 500
switchport mode access
switchport voice vlan 200
storm-control broadcast level 5.00
storm-control multicast level 5.00
storm-control action shutdown
spanning-tree portfast
!
interface FastEthernet0/21
switchport access vlan 500
switchport mode access
switchport voice vlan 200
storm-control broadcast level 5.00
storm-control multicast level 5.00
storm-control action shutdown
spanning-tree portfast
!
interface FastEthernet0/22
switchport access vlan 500
no ip route-cache
!
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 123.1.1.57
access-list 5 permit 212.179.20.0 0.0.0.63
access-list 5 deny any
access-list 10 permit 123.2.2.123
access-list 10 permit 10.0.12.46
access-list 10 permit 10.0.12.45
access-list 10 remark VTY-ACCESS
access-list 10 permit 10.0.12.138
access-list 10 permit 10.0.12.136
access-list 10 permit 10.0.12.199
access-list 10 permit 123.1.1.0 0.0.0.255
access-list 10 permit 10.10.10.0 0.0.0.255
access-list 10 permit 10.10.30.0 0.0.0.255
access-list 10 deny any
snmp-server community public RO
snmp-server community NMSRO RO 5
snmp-server host 123.1.1.89 public
radius-server host 123.1.1.16 auth-port 1812 acct-port 1813 key 7
052805F3D200F175F1D06
!
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
!
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 clock-period 36029424
ntp server 10.1.0.1
end
Network Topology
Using the information provided, select the most logical cause of the issue from the list below
(multiple answers):
• The storm-control statements used on the switches are causing network flaps.
• 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
• 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):
• The storm-control statements used on the switches are causing network flaps.
• 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
iPexpert's Detailed Solution Guide
for Cisco's CCIE Routing and Switching Lab Exam, Volume 2, Lab 5
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.
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
Building configuration...
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
!
interface Ethernet0/0
ip address 203.3.16.2 255.255.255.252
!
interface Ethernet0/1
ip address 123.20.1.2 255.255.255.248
ip pim sparse-mode
!
interface Ethernet0/2
ip address 123.20.1.17 255.255.255.248
ip pim sparse-mode
!
interface Ethernet0/3
no ip address
!
interface Ethernet1/0
no ip address
!
interface Ethernet1/1
no ip address
!
interface Ethernet1/2
no ip address
!
interface Ethernet1/3
no ip address
!
interface Ethernet2/0
no ip address
shutdown
!
interface Ethernet2/1
no ip address
shutdown
!
interface Ethernet2/2
no ip address
shutdown
!
interface Ethernet2/3
no ip address
shutdown
!
interface Serial5/0
no ip address
shutdown
serial restart-delay 0
!
interface Serial5/1
no ip address
shutdown
serial restart-delay 0
!
interface Serial5/2
no ip address
shutdown
serial restart-delay 0
!
router bgp 65248
bgp log-neighbor-changes
neighbor 3.3.3.20 remote-as 64782
neighbor 10.10.10.20 remote-as 65489
neighbor 123.20.1.18 remote-as 8005
neighbor 123.20.1.18 password IPX
neighbor 123.20.1.18 ebgp-multihop 255
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.
• 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. This cannot be
accomplished without any downtime.
• Fortunately, IOS provides a feature to automate the transition in the form of a simple
command: bgp upgrade-cli, which is run under the bgp process configuration. No down time
is required.
• Fortunately, IOS provides a feature to automate the transition in the form of a simple
command: bgp upgrade-cli, which is run under the bgp process configuration. This cannot be
accomplished without any downtime.
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.
• 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.
• 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. This cannot be
accomplished without any downtime.
• Fortunately, IOS provides a feature to automate the transition in the form of a simple
command: bgp upgrade-cli, which is run under the bgp process configuration. No down time
is required.
• Fortunately, IOS provides a feature to automate the transition in the form of a simple
command: bgp upgrade-cli, which is run under the bgp process configuration. This cannot be
accomplished without any downtime.
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.
After converting to the multiprotocol configuration syntax, we can create additional address families:
RTR-SUP
Once we finish the migration to the multi address-family mode we can easily configure the ipv6
address-family.
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 RTO Q Seq
(sec) (ms) Cnt Num
1 10.10.10.3 Fa0/0 14 00:00:09 212 1272 0 5
0 10.10.10.2 Fa0/0 14 00:01:08 1041 5000 0 6
R1#sh ip route
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
o - ODR, P - periodic downloaded static route
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)
R2 Outputs
R2#sh ip ei ne
IP-EIGRP neighbors for process 100
H Address Interface Hold Uptime SRTT RTO Q Seq
(sec) (ms) Cnt Num
0 10.10.10.1 Fa0/0 13 00:01:18 48 288 0 6
R2#sh ip route
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
o - ODR, P - periodic downloaded static route
R2#debug ip eigrp
*Mar 1 00:25:17.315: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 100: Neighbor 10.10.10.1
(FastEthernet0/0) is down: holding time expired
*Mar 1 00:26:27.259: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 100: Neighbor 10.10.10.1
(FastEthernet0/0) is up: new adjacency
*Mar 1 00:26:27.447: IP-EIGRP(Default-IP-Routing-Table:100): Processing incoming
UPDATE packet
*Mar 1 00:26:29.243: IP-EIGRP(Default-IP-Routing-Table:100): 20.20.20.0/24 - don't
advertise out FastEthernet0/0
*Mar 1 00:26:29.243: IP-EIGRP(Default-IP-Routing-Table:100): 10.10.10.0/24 - do
advertise out FastEthernet0/0
*Mar 1 00:26:29.247: IP-EIGRP(Default-IP-Routing-Table:100): 20.0.0.0/8 - do
advertise out FastEthernet0/0
*Mar 1 00:26:29.247: IP-EIGRP(Default-IP-Routing-Table:100): Int 20.0.0.0/8 metric
128256 - 256 128000
*Mar 1 00:26:29.247: IP-EIGRP(Default-IP-Routing-Table:100): 10.0.0.0/8 - poison
advertise out FastEthernet0/0
*Mar 1 00:26:29.403: IP-EIGRP(Default-IP-Routing-Table:100): Processing incoming
UPDATE packet
*Mar 1 00:26:29.407: IP-EIGRP(Default-IP-Routing-Table:100): Int 100.0.0.0/8 M 409600
- 256000 153600 SM 128256 - 256 128000
*Mar 1 00:26:29.407: IP-EIGRP(Default-IP-Routing-Table:100): route installed for
100.0.0.0 ()
*Mar 1 00:26:29.427: IP-EIGRP(Default-IP-Routing-Table:100): Int 100.0.0.0/8 metric
409600 - 256000 153600
*Mar 1 00:26:29.559: IP-EIGRP(Default-IP-Routing-Table:100): Processing incoming
UPDATE packet
*Mar 1 00:26:29.563: IP-EIGRP(Default-IP-Routing-Table:100): Int 20.0.0.0/8 M
4294967295 - 256000 4294967295 SM 4294967295 - 256000 4294967295
*Mar 1 00:26:29.855: IP-EIGRP(Default-IP-Routing-Table:100): Processing incoming
UPDATE packet
*Mar 1 00:26:29.859: IP-EIGRP(Default-IP-Routing-Table:100): Int 30.0.0.0/8 M
4294967295 - 256000 4294967295 SM 4294967295 - 256000 4294967295
R3 Outputs
R3#sh ip ei ne
IP-EIGRP neighbors for process 100
H Address Interface Hold Uptime SRTT RTO Q Seq
(sec) (ms) Cnt Num
0 10.10.10.1 Fa0/0 11 00:00:26 164 984 0 6
R3#sh ip ei ne
IP-EIGRP neighbors for process 100
H Address Interface Hold Uptime SRTT RTO Q Seq
(sec) (ms) Cnt Num
1 10.10.10.2 Fa0/0 11 00:00:26 1283 5000 0 6
0 10.10.10.1 Fa0/0 11 00:00:26 164 984 0 6
R3#sh ip route
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
o - ODR, P - periodic downloaded static route
R3#debug ip eigrp
*Mar 1 00:26:26.071: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 100: Neighbor 10.10.10.1
(FastEthernet0/0) is up: new adjacency
*Mar 1 00:26:28.023: IP-EIGRP(Default-IP-Routing-Table:100): Processing incoming
UPDATE packet
*Mar 1 00:26:28.035: IP-EIGRP(Default-IP-Routing-Table:100): 30.30.30.0/24 - don't
advertise out FastEthernet0/0
*Mar 1 00:26:28.035: IP-EIGRP(Default-IP-Routing-Table:100): 10.10.10.0/24 - do
advertise out FastEthernet0/0
*Mar 1 00:26:28.035: IP-EIGRP(Default-IP-Routing-Table:100): 30.0.0.0/8 - do
advertise out FastEthernet0/0
*Mar 1 00:26:28.039: IP-EIGRP(Default-IP-Routing-Table:100): Int 30.0.0.0/8 metric
128256 - 256 128000
*Mar 1 00:26:28.039: IP-EIGRP(Default-IP-Routing-Table:100): 10.0.0.0/8 - poison
advertise out FastEthernet0/0
EIGRP Topology
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:
• R2 • Enable split-horizon on R1
• R3 • Enable split-horizon on R2
• PC1
• Disable split-horizon on R3
• PC2
• Disable split-horizon on R2
• PC3
• Disable split-horizon on R1
• R1
• Enable next-hop-self on R1
• Disable next-hop-self on R1
• Disable auto-summary on R1
• Enable auto-summary on R2
• Enable auto-summary on R3
Solution
Device with Issue: Area of Issue:
• R2 • Enable split-horizon on R1
• R3 • Enable split-horizon on R2
• R1 • Enable next-hop-self on R1
• Disable next-hop-self on R1
• Disable auto-summary on R1
• Enable auto-summary on R2
• Enable auto-summary on R3
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, split-
horizon 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
Copyright© iPexpert. All Rights Reserved.
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.
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.
• Ensure that the following unused ports on all four switches are shutdown and configured as
access ports in vlan 999:
• 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.
o 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 VLAN’s 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.
Next, we should shutdown and configure VLAN 999 on unused ports as instructed:
SW1, SW2
SW3, SW4
SW5, SW6
SW7, SW8
SW1
SW2
SW3
SW4
SW5
SW6
SW7
SW8
Verification
Let’s perform some verifications now, we should receive an output saying that the 802.1q interfaces
have been statically set for trunking.
SW1
SW2
SW3
SW4
SW5
SW6
SW7
SW8
• 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 VLAN’s on SW2, SW3, or SW4. They should learn the VLAN’s from the VTP
server.
• Configure the network of San Francisco office (ASN 23456) as per the following requirements:
o SW6 must be the vtp server and SW5 must be the vtp client.
• Configure the network of Hawaii office (ASN 34567) as per the following requirements:
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 task’s 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.
SW1
SW1(config)#vtp version 2
SW1(config)#vtp domain CCIERS
SW1(config)#vtp password iPexpert?
SW1(config)#vtp mode server
SWX(config)#conf t
SWX(config)#vtp domain CCIERS
SWX(config)#vtp mode client
SWX(config)#vtp password iPexpert?
SW5
SW6
SW7, SW8
Verification
Let’s confirm we have everything configured properly. SW1 should be the VTP server, all others
should be VTP Clients.
SW1
Feature VLAN:
--------------
VTP Operating Mode : Server
SW2
Feature VLAN:
--------------
VTP Operating Mode : Client
SW3
Feature VLAN:
--------------
VTP Operating Mode : Client
SW4
Feature VLAN:
--------------
VTP Operating Mode : Client
SW5
Feature VLAN:
--------------
VTP Operating Mode : Client
SW6
Feature VLAN:
--------------
VTP Operating Mode : Server
SW7-8 should be both VTP transparent, meaning they should forward all VTP without actually
modifying their own VLAN database.
SW7
Feature VLAN:
--------------
VTP Operating Mode : Transparent
SW8
Feature VLAN:
--------------
VTP Operating Mode : Transparent
• 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.
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)#interface range e2/0-1
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
Now, we need to configure the switchports that connect to the routers’ interfaces:
SW1
SW2
SW3
SW4
SW4(config)#interface e1/3
SW4(config-if)#switchport trunk encapsulation dot1q
SW4(config-if)#switchport mode trunk
SW4(config-if)#switchport trunk allowed vlan ad 37,75
SW4(config-if)#default interface e2/1
SW4(config)#interface e2/1
SW4(config-if)#switchport trunk encapsulation dot1q
SW4(config-if)#switchport mode trunk
SW4(config-if)#switchport trunk allowed vlan ad 10,20,30,40,50
SW4(config-if)#interface range e1/3-3,e2/1
SW4(config-if-range)#no shutdown
SW5
SW6
SW6(config)#interface e0/1
SW6(config-if)#switchport access vlan 156
SW6(config-if)#switchport mode access
SW6(config-if)#interface ra e0/1-2,e1/0
SW6(config-if-range)#no shutdown
SW7
SW8
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
R1
R2
• 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.
• 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
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
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
SW2
SW3-SW4
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.
SW6
SW5
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:
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
SW1
SW1#sh span
VLAN0001
Spanning tree enabled protocol rstp
Root ID Priority 1
Address aabb.cc00.6500
This bridge is the root
Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec
SW2
SW2#sh span
VLAN0001
Spanning tree enabled protocol rstp
Root ID Priority 1
Address aabb.cc00.6500
Cost 100
Port 13 (Ethernet3/0)
Hello Time 2 sec Max Age 20 sec Forward Delay 15 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
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
R2
R2#ping 10.10.29.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.10.29.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/1 ms
R2#ping 101.33.1.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 101.33.1.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/1 ms
R2#ping 101.33.1.6
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 101.33.1.6, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/1 ms
• The provider connections with R24 and R25 must use ip address negotiation and be
authenticated using a 3-Way Handshake with ISP6.
o R24 must use the username "IPX-24" and the password "IPXKEY"
o R25 must use the username "IPX-25" and the password "IPXKEY"
o R20 must use the username "IPX-20" 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
R24
R24(config)#interface s2/0
R24(config-if)#encapsulation ppp
R24(config-if)#ppp chap hostname IPX-24
R24(config-if)#ppp chap password IPXKEY
R25
R25(config)#interface s2/0
R25(config-if)#encapsulation ppp
R25(config-if)#ppp chap hostname IPX-25
R25(config-if)#ppp chap password IPXKEY
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 Host(s) Idle Location
* 0 con 0 idle 00:00:00
Interface User Mode Idle Peer Address
Se2/2 ISP6 Sync PPP 00:00:01 195.13.206.2
R24
R24#who
Line User Host(s) Idle Location
* 0 con 0 idle 00:00:00
Interface User Mode Idle Peer Address
Se2/0 ISP6 Sync PPP 00:00:02 193.190.24.1
R25
R25#show users
Line User Host(s) Idle Location
* 0 con 0 idle 00:00:00
Interface User Mode Idle Peer Address
Se2/0 ISP6 Sync PPP 00:00:00 193.190.25.1
• Add all interfaces to the OSPF process except the links that leave the Autonomous System.
• All addresses in the OSPF domain should be reachable by all devices in the AS.
• 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
Solution
We need to first acknowledge all of the requirements for this task. First, let’s 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
R2
R3
R4
R5
R6
R7
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
Verification
Let’s 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.
The output of the OSPF routes after the configuration change on R1:
R1
• 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).
• 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:
o vlan 135
• 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
R12
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
SW6
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
Vector metric:
Minimum bandwidth is 10000 Kbit
Total delay is 1040000000 picoseconds
Reliability is 255/255
Load is 1/255
Minimum MTU is 1500
Hop count is 1
R11
SW6
SW6(config)#interface vlan 56
SW6(config-if)#delay 3
Verification
First, we should have seen log messages showing that our neighbor relationships are up. Let’s verify
that they are using MD5 encryption. We can do this using the following show command:
R11
Now, let’s 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…]
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
• Add all interfaces in Hawaii to the EIGRP process except those connected to other Autonomous
Systems.
• 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
R19
R20
SW7
SW8
Verification
Let’s take a look at the routing table of R18 and verify it is learning all of the routes it should be.
R18
Now, let’s 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}
• Use the pre-configured DMVPN tunnel interface of R20, R24, and R25 to establish the EIGRP
relationships.
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.
R20
R24
R25
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
Now let’s 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.
R11
R20
R24
R24#sh ip ro 0.0.0.0
Routing entry for 0.0.0.0/0, supernet
Known via "eigrp 34567", distance 170, metric 56883200, candidate default path
Tag 3333, type external
Redistributing via eigrp 34567
Last update from 192.168.20.20 on Tunnel0, 00:05:35 ago
Routing Descriptor Blocks:
* 192.168.20.20, from 192.168.20.20, 00:05:35 ago, via Tunnel0
Route metric is 56883200, traffic share count is 1
Total delay is 11100 microseconds, minimum bandwidth is 100 Kbit
Reliability 1/255, minimum MTU 1 bytes
Loading 1/255, Hops 2
Route tag 3333
• IPv4 unicast family address must be disabled by default in all BGP routers.
• 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.
• Configure eBGP between iPExpert‘s New York and RPT according to the following requirements:
o R9 is a CE router and uses eBGP to connect to management services that are provided by
the PE routers R2 and R3.
o R9 must establish a separate eBGP peering with both R2 and R3 for every VRF.
o 10.0.0.0/8 summary-only
o 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
R2
R3
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.
R3
R2
R2(config-vrf)#!
R2(config-vrf)#ip vrf GREEN
R2(config-vrf)# rd 64520:10
R2(config-vrf)# route-target export 10:10
R2(config-vrf)# route-target import 10:10
R2(config-vrf)#!
R2(config-vrf)#ip vrf INET
R2(config-vrf)# rd 9999:50
R2(config-vrf)# route-target export 50:50
R2(config-vrf)# route-target import 50:50
R2(config-vrf)#!
R2(config-vrf)#ip vrf RED
R2(config-vrf)# rd 64520:30
R2(config-vrf)# route-target export 30:30
R2(config-vrf)# route-target import 30:30
R2(config-vrf)#!
R2(config-vrf)#ip vrf YELLOW
R2(config-vrf)# rd 65423:40
R2(config-vrf)# route-target export 40:40
R2(config-vrf)# route-target import 40:40
!
R2(config)#interface e0/0
R2(config-if)#ip address 101.33.1.1 255.255.255.252
R2(config-if)#interface e0/1.10
R2(config-subif)#encapsulation dot1q 10
R2(config-subif)#ip vrf for GREEN
R2(config-subif)#ip address 10.10.29.2 255.255.255.0
R2(config-subif)#interface e0/1.20
R2(config-subif)#encapsulation dot1q 20
R2(config-subif)#ip vrf for BLUE
R2(config-subif)#ip address 10.20.29.2 255.255.255.0
R2(config-subif)#interface e0/1.30
R2(config-subif)#encapsulation dot1q 30
R2(config-subif)#ip vrf for RED
R2(config-subif)#ip address 10.30.29.2 255.255.255.0
R2(config-subif)#interface e0/1.40
R2(config-subif)#encapsulation dot1q 40
R2(config-subif)#ip vrf for YELLOW
R2(config-subif)#ip address 10.40.29.2 255.255.255.0
R2(config-subif)#interface e0/1.50
R2(config-subif)#encapsulation dot1q 50
R2(config-subif)#ip vrf for INET
R2(config-subif)#ip address 10.50.29.2 255.255.255.0
R2(config-subif)#interface e0/1.26
R2(config-subif)#encapsulation dot1q 26
R2(config-subif)#ip address 101.33.1.5 255.255.255.252
R2(config-subif)#interface s2/2
R2(config-if)#ip add 92.82.12.2 255.255.255.0
!
R2(config)#router bgp 65333
R2(config-router)#address-family ipv4 vrf BLUE
R2(config-router-af)#neighbor 10.20.29.1 remote-as 64520
R2(config-router-af)#neighbor 10.20.29.1 activate
R2(config-router-af)#address-family ipv4 vrf GREEN
R2(config-router-af)#neighbor 10.10.29.1 remote-as 64520
R2(config-router-af)#neighbor 10.10.29.1 activate
R2(config-router-af)#address-family ipv4 vrf INET
R2(config-router-af)#neighbor 10.50.29.1 remote-as 64520
R2(config-router-af)#neighbor 10.50.29.1 activate
R2(config-router-af)#address-family ipv4 vrf RED
R2(config-router-af)#neighbor 10.30.29.1 remote-as 64520
R2(config-router-af)#neighbor 10.30.29.1 activate
R2(config-router-af)#address-family ipv4 vrf YELLOW
R2(config-router-af)#neighbor 10.40.29.1 remote-as 64520
R2(config-router-af)#neighbor 10.40.29.1 activate
R9
The quickest way of advertising a default-route to all but VRF INET is using the default-originate
neighbor specific command, let's configure:
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. Let’s take a look at the routing table of R2 and R3.
R3
R2
[… Omitted…]
Now, let’s 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 }
• Configure a full mesh iBGP peering between all three routers using any configuration method.
• 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.
• 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.
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
R12
R13
Verification
Let’s 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
R12
R13
R12
R12#sh ip bgp
BGP table version is 523, local router ID is 172.17.12.12
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
[… Omitted …]
R13
R13#sh ip bgp
BGP table version is 348, local router ID is 172.17.13.13
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
[… Omitted …]
• 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.
• R20, R24, and R25 must establish an eBGP peering with AS 6666 in vrf GW.
o They must receive a default route and all other prefixes from AS 6666.
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
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
NOTE
Don't forget to set the k metrics for proper redistribution.
Verification
We should now be learning routes on R20, R24, and R25 from BGP, and we shouldn’t advertise any
routes back to the Local Service Provider.
R20
[Results Deprecated…]
R24
[Results Deprecated…]
R25
R20
R24
R25
R18
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
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
R22
R23
Let’s also make sure our weight attribute is working (note that right now we don’t receive any
prefixes from AS 4444 but the connected subnet):
R22
R22#sh ip bgp
BGP table version is 4, local router ID is 172.17.22.22
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
• 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.
• 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:
R25
R21
R23
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.
R2
R3
R4
R11
R13
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
[Output omitted…]
Repeat the same command for R3 and R4 to verify the filtering – just don’t forget to replace the
neighbor IP address.
Do the same verification for ASN 65444 to see that we met the requirements.
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.
R25
R24
R21
R23
Table 5.12
• 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.
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
iPexpert's Detailed Solution Guide
for Cisco's CCIE Routing and Switching Lab Exam, Volume 2, Lab 5
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)#address-family ipv6 unicast
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
R2(config-if)#ospfv3 12345 ipv6 area 0
R3
R3(config)#ipv6 unicast-routing
R3(config)#router ospfv3 12345
R3(config-router)#address-family ipv6 unicast
R3(config-router-af)#router-id 172.17.3.3
R3(config-router-af)#interface e0/1.37
R3(config-subif)#ospfv3 12345 ipv6 area 20
R3(config-subif)#interface e0/0
R3(config-if)#ospfv3 12345 ipv6 area 0
R3(config-if)#ospfv3 12345 ipv6 priority 254
R3(config-if)#interface lo0
R3(config-if)#ospfv3 12345 ipv6 area 0
R6
R6(config)#ipv6 unicast-routing
R6(config)#router ospfv3 12345
R6(config-router)#address-family ipv6 unicast
R6(config-router-af)#router-id 172.17.6.6
R6(config-router-af)#interface e0/1.64
R6(config-subif)#ospfv3 12345 ipv6 area 30
R6(config-subif)#interface e0/1.26
R6(config-subif)#ospfv3 12345 ipv6 area 10
R6(config-subif)#interface lo0
R6(config-if)#ospfv3 12345 ipv6 area 10
R7
R7(config)#ipv6 unicast-routing
R7(config)#router ospfv3 12345
R7(config-router)#address-family ipv6 unicast
R7(config-router-af)#router-id 172.17.7.7
R7(config-router-af)#interface e0/1.75
R7(config-subif)#ospfv3 12345 ipv6 area 40
R7(config-subif)#interface e0/1.37
R7(config-subif)#ospfv3 12345 ipv6 area 20
R7(config-subif)#interface lo0
R7(config-if)#ospfv3 12345 ipv6 area 20
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.
Diagram 5.13
R2
R3
R6
R7
R4
R5
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
R3
Next, check to see who is the designated router and backup designated router for VLAN 23.
R2
Next, although we should've already identified areas 30,40 prefixes in our routing table, we will verify
the virtual-link status.
R6
R7
We indeed see each of these routes. Now, let’s 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}
Table 5.14
• Configure IPv6 eBGP peerings between ASes 65521, 65523 and 65333 with AS 4444.
• 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:
R23
Solution
The first step is (IPv6 addresses) is pre-configured. Always look at initial configs so you don’t 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)#ipv6 unicast-routing
R4(config)#router bgp 65333
R4(config-router)#neighbor 2004::44:2 remote-as 4444
R4(config-router)#address-family ipv6 unicast
R4(config-router-af)#redistribute ospf 12345 match internal external include-connected
R4(config-router-af)#neighbor 2004::44:2 activate
R5
R5(config)#ipv6 unicast-routing
R5(config)#router bgp 65333
R5(config-router)#neighbor 2004::54:4 remote-as 4444
R5(config-router)#address-family ipv6 unicast
R5(config-router-af)#redistribute ospf 12345 match internal external include-connected
R5(config-router-af)#neighbor 2004::54:4 activate
R5(config-router-af)#router ospfv3 12345
R5(config-router)#address-family ipv6 unicast
R5(config-router-af)#redistribute bgp 65333
R21
R21(config)#ipv6 unicast-routing
R21(config)#router bgp 65521
R21(config-router)#neighbor 2004::21:1 remote-as 4444
R21(config-router)#address-family ipv6 unicast
R21(config-router-af)#redistribute connected
R21(config-router-af)#neighbor 2004::21:1 activate
R23
R23(config)#ipv6 unicast-routing
R23(config)#router bgp 65523
R23(config-router)#neighbor 2004::23:1 remote-as 4444
R23(config-router)#address-family ipv6 unicast
R23(config-router-af)#redistribute connected
R23(config-router-af)#neighbor 2004::23:1 activate
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
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}
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}
• 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:
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)#interface e0/0
R18(config-if)#ip pim sparse-mode
R18(config-if)#interface e0/1
R18(config-if)#ip pim sparse-mode
R18(config-if)#int lo0
R18(config-if)#ip pim sparse-mode
R18(config-if)#ip pim rp-candidate loopback0
R18(config)#ip pim bsr-candidate loopback0
R19
R19(config)#ip multicast-routing
R19(config)#interface e0/0
R19(config-if)#ip pim sparse-mode
R19(config-if)#interface e0/1
R19(config-if)#ip pim sparse-mode
R19(config-if)#int lo0
R19(config-if)#ip pim sparse-mode
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.
R20
R20(config)#ip multicast-routing
R20(config)#interface e0/0
R20(config-if)#ip pim sparse-mode
R20(config-if)#interface e0/1
R20(config-if)#ip pim sparse-mode
R20(config-if)#int tun0
R20(config-if)#ip pim sparse-mode
R24
R24(config)#ip multicast-routing
R24(config)#int tun0
R24(config-if)#ip pim sparse-mode
R24(config-if)#int lo0
R24(config-if)#ip pim sparse-mode
R24(config-if)#ip igmp join-group 232.8.8.8
R25
R25(config)#ip multicast-routing
R25(config)#int tun0
R25(config-if)#ip pim sparse-mode
R25(config-if)#int lo0
R25(config-if)#ip pim sparse-mode
R25(config-if)#ip igmp join-group 232.8.8.8
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.
SW8
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.
• 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 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. Let’s take it step by step. First, let’s 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
R2(config-if)#mpls ip
R3
R3(config)#ip cef
R3(config)#mpls ldp router-id lo0 force
R3(config)#interface range e0/0,e0/1.37
R3(config-if-range)#mpls ip
R3(config-if-range)#interface s2/3
R3(config-if)#mpls ip
R4
R4(config)#ip cef
R4(config)#mpls ldp router-id lo0 force
R4(config)#interface range e0/0,e0/1
R4(config-if-range)#mpls ip
R4(config-if-range)#interface s2/0
R4(config-if)#mpls ip
R5
R5(config)#ip cef
R5(config)#mpls ldp router-id lo0 force
R5(config)#interface range e0/0,e0/1
R5(config-if-range)#mpls ip
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
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
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
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
Later we will do the full verification of MPLS VRF VPN’s after the next section.
• R2 and R3 must establish an eBGP peering with both Service Providers (AS 1111 and AS 2222 ) for
the following VRF‘s:
o GREEN
o BLUE
o RED
o YELLOW
o INET
• R4 must establish an eBGP peering with the Service Providers AS 4444 for the following VRF‘s:
o GREEN
o BLUE
o 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, let’s configure the VRF’s that are to be used for the MPLS VPN’s on all P/PE devices that are
missing this configuration. This is a requirement to get the MPLS VPN’s to work correctly. The VRF’s
are listed in the BGP diagram.
R1, R5
R4 will only peer for BLUE, GREEN and RED (read the next task):
R4
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
R2-R5
NOTE
The remaining part of this task was configured earlier (peerings with ASes 1111,2222, 4444 and 64520).
Verification
R1
R2
R3
R4
o Use the preconfigured interface tunnel0 on R20, R24, and R25 in order to accomplish this
task.
o Use interface s2/0 as the source address of the tunnel on each device,
o R24 and R25 must be the spokes and must participate in the NHRP information exchange.
• 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 spoke-
to-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)#interface tunnel0
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
R24
R24(config)#interface tunnel0
R24(config-if)#no ip redirects
R24(config-if)#tunnel vrf GW
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 network-id 34567
R24(config-if)#ip nhrp holdtime 600
R24(config-if)#ip nhrp auth DMVPNk6y
R24(config-if)#ip nhrp shortcut
R24(config-if)#bandwidth 1000
R24(config-if)#delay 1000
R24(config-if)#ip mtu 1400
R24(config-if)#ip tcp adjust-mss 1380
R24(config-if)#tunnel key 34567
R24(config-if)#tunnel source s2/0
R24(config-if)#tunnel mode gre multipoint
R25
R25(config)#interface tunnel0
R25(config-if)#no ip redirects
R25(config-if)#tunnel vrf GW
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 network-id 34567
R25(config-if)#ip nhrp holdtime 600
R25(config-if)#ip nhrp auth DMVPNk6y
R25(config-if)#ip nhrp shortcut
R25(config-if)#bandwidth 1000
R25(config-if)#delay 1000
R25(config-if)#ip mtu 1400
R25(config-if)#ip tcp adjust-mss 1380
R25(config-if)#tunnel key 34567
R25(config-if)#tunnel source s2/0
R25(config-if)#tunnel mode gre multipoint
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
NBMA address: 193.190.25.25
R20#sh dmvpn
Legend: Attrb --> S - Static, D - Dynamic, I - Incomplete
N - NATed, L - Local, X - No Socket
# Ent Peer NBMA Addr Peer Tunnel Add State UpDn Tm Attrb
----- --------------- --------------- ----- -------- -----
1 193.190.24.24 192.168.20.24 UP 5d13h D
1 193.190.25.25 192.168.20.25 UP 5d13h D
R24
R24#sh ip nhrp
192.168.20.20/32 via 192.168.20.20
Tunnel0 created 5d14h, never expire
Type: static, Flags: used
NBMA address: 195.13.206.1
R25
R25#sh ip nhrp
192.168.20.20/32 via 192.168.20.20
Tunnel0 created 5d14h, never expire
Type: static, Flags: used
NBMA address: 195.13.206.1
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.
R24
R24#sh ip nhrp
192.168.20.20/32 via 192.168.20.20
Tunnel0 created 5d14h, never expire
Type: static, Flags: used
NBMA address: 195.13.206.1
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
NBMA address: 193.190.25.25
Secure the DMVPN tunnel with IPsec according to the following requirements:
o All IPsec tunnels must be authenticated using the same IKE Phase 1 pre-shared key.
o Use 1024 bits for the key exchange using the Diffie-Hellman algorithm.
o Use the IPsec security protocol ESP and the algorithm AES with 128 bits.
• 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.
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.
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
output omitted …
# Ent Peer NBMA Addr Peer Tunnel Add State UpDn Tm Attrb Target Network
----- --------------- --------------- ----- -------- ----- ------------
1 195.13.206.1 192.168.20.20 UP 00:00:07 S 192.168.20.20/32
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
R25
output omitted …
# Ent Peer NBMA Addr Peer Tunnel Add State UpDn Tm Attrb Target Network
----- --------------- --------------- ----- -------- ----- -----------------
1 195.13.206.1 192.168.20.20 UP 5d14h S 192.168.20.20/32
1 193.190.24.24 192.168.20.24 UP 00:09:01 D 192.168.20.24/32
1 193.190.25.25 192.168.20.25 UP 00:09:01 DLX 192.168.20.25/32
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
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.
o Leave one line for regular telnet access authenticating users with the Local Database.
o Every single function in the menu must display the correct output.
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.
R9
Second, we configure the menu text for each line and also the command to be run with it.
R9
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
Verification
The verification for this task is rather easy, just telnet to R9 and execute each operation for validating
its functionality.
R2
• 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.
o SW2 must dynamically learn only one MAC address per port and must save the MAC
address in its startup configuration.
o 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
Now, we will address the 802.1q interfaces (note here we allow 1 MAC address per VLAN) :
SW2
Verification
Let's verify the functionality of the switchport port-security using one global command.
SW2
SW2#sh port-security
Secure Port MaxSecureAddr CurrentAddr SecurityViolation Security Action
(Count) (Count) (Count)
-----------------------------------------------------------------------
Et0/1 1 1 0 Shutdown
Et0/2 1 0 0 Shutdown
Et0/3 1 0 0 Shutdown
Et1/2 1 1 0 Shutdown
Et1/3 1 1 0 Shutdown
---------------------------------------------------------------------------
Total Addresses in System (excluding one mac per port) : 0
Max Addresses limit in System (excluding one mac per port) : 4096
• Configure routers R1-R3 in ASN 12345 to locally track changes made to its running configuration.
o Ensure that passwords in the configuration will not be sent across this communication
channel.
o Limit the maximum number of logged commands that will be kept by the config log to a
maximum of 1000 entries.
o Verify this on all routers by typing the following commands and receiving the same
output:
conf t
RX (config)#int e0/0
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
Verification
The verification for this task is rather easy, just enter “configure terminal”, “int e0/0” and see the
magic happen. You don’t have to repeat this verification for other routers if you copied-pasted the
config.
R1
R1(config)#int e0/0
R1(config-if)#
*May 22 05:16:31.451 UTC: %PARSER-5-CFGLOG_LOGGEDCMD: User:console logged
command:interface Ethernet0/0
R1(config-if)#end
R1#
*May 22 05:16:34.188 UTC: %PARSER-5-CFGLOG_LOGGEDCMD: User:console logged command:end
o The output that is shown below must be seen on R20 during 10 seconds after R25
successfully pinged interface Lo21 of R21.
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)#interface tunnel0
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.
R21
R20
This concludes the Configuration Section and iPexpert's R&S Lab 5 DSG, Volume 2
Copyright© iPexpert. All Rights Reserved.