ccie r&s v5 troubleshoot updated on 15 jan,2016€¦ · more practical information about the...

CCIE R&S v5 Troubleshoot Updated on 15th Jan,2016

[email protected] All Right Reserved

mailto:[email protected]



Disclaimer : CCCIE RSv5 lab Exam Workbook is designed to provide extensive

practical information to help candidates in the preparation for CISCO Systems CCIE RSv5 Lab Exam. We do not take liability or responsibility to any person or entity with respect to loss or damage caused by the information presented in the workbook Cisco, Cisco Systems,and CCIE (Cisco Certified Internetwork Expert) are registered trademarks of Cisco Systems, Inc.And of its affiliates in the USA and other countries . The information presented in the workbook is not necessarily related to Cisco Systems, Inc. This workbook is not affiliated, endorsed or sponsored by Cisco Systems, Inc.This workbook provides detailed and comprehensive practical examples for the preparation of CCIE RSv5 labs but cannot be used as a replacement of other supplementary books or prescribed materials. Purpose of the workbook is to provide more practical information about the CCIE RSv5 lab Exam. This workbook is prepared for the individual candidates who have purchased it with non-disclosure agreement. Imitation, copying, editing or posting contents of the workbook over the internet is part of copyright and non-disclosure agreement violation.




Question 1 - Ticket 1 ( L2 Switching & DHCP) User's that are located in VLAN 100 of the BancoBank Headquarters have lost access to Server1, which is located in VLAN 200. Fix the issue so that the following output gets matched. PC101#ping SERVER1 !!!!!




Possible Faults:-

1. Switchport security on switch interface connecting to PC101 2. Switchport security on switch interface connecting to SERVER1 3. Wrong MAC address might be configured for client identifier for PC 101 / SERVER1 4. Gateway IP address is missing in DHCP pool 5. Vlan 12 is not created on SW1 / SW2 6. Access ports might be wrongly configured on SW1 / SW2 7. DHCP helper address might be not configured on SW1 / SW2 8. Wrong subnet mask configured in DHCP Pool on R7 and R8 9. Remove DHCP Snooping 10. Wrong client id pool for vlan 100 / vlan 200 on R7 / R8 11. Vlan 12 might not be allowed on trunk. 12. Check for access-list , if any affecting.

While you are resolving these faults, you are not allowed to perform redistribution, add static or default route, layer 3 interfaces or modify access lists. Refer to the Troubleshooting guidelines to determine if your solution is appropriate.




Question 2 - Ticket 2 (PPP) Local ISP NOC connected to R11 has lost access to R17. Local ISP Gateways must authenticate their ppp subscribers using chap authentication Local ISP Gateways must offer Dynamic IP addresses to ppp subscribers. Subscribers must have a default route in their routing table pointing towards Local ISP. Subscribers must not use routing protocols to connect with Local ISP Gateways. Fix the issue so to restore the connectivity. R17#ping 145.11.11.11 !!!!!




Possible Faults:-

1. Wrong DHCP / Local Pool name on R12 / R17 2. Wrong Network/Subnet in DHCP pool on R12 / R17 3. Check for username and Password on R12 4. Check for CHAP Hostname and Password on R17 5. Check for one-way or 2-way authentication 6. Check ip address negotiate command on R17. 7. ADD PPP ipcp route default on R17. 8. Check for access-list , if any affecting.

While you are resolving these faults, your are not allowed to add any new static routes, default routes or Layer 3 interfaces. Refer to the Troubleshooting guidelines to determine if your solution is appropriate.




Question 3 - Ticket 3 (OSFP) Assume that there is a server located in OSPF Area 1 on the link between R21 and R22 in the Global ISP network.The NOC team has identified that the traffic that originates in OSPF Area 0 and destined to this server is not load balanced by R1. Fix the issue so that R1 traffic be can load balanced as shown in output R1#traceroute 134.56.78.49 1 123.45.67.6 [MPLS: Label 42 Exp 0] 1 msec 123.45.67.18 [MPLS: Label 80 Exp 0] 0 msec 123.45.67.6 [MPLS: Label 42 Exp 0] 0 msec 2 123.45.67.42 1 msec 123.45.67.38 0 msec *




Possible Faults:-

1. Check for OSPF Neighborship 2. Check for OSPF Routes-Path 3. Neighborship might be down due

a) Any interface administratively shutdown b) Wrong Subnet mask c) Wrong Hello-Dead timers. d) Mismatched Network-type e) Remove Passive interface in ospf which is impacting your neighborship f) Permit dscp 6 in access list (if denied or not permitted)

4. Wrong subnet mask is configured on R22 interface. 5. Check for any ospf cost if extra added then modify accordingly 6. Wrong OSPF metric configured 7. Check for Summary Address if any then remove it 8. Max-metric router-lsa might be configured on R3/R5 9. Check for offset-list , modify if required. (Do not remove) 10. Check for access-list , if any affecting.

While you are resolving these faults, your are not allowed to configure static IP and add any new static route, default route or Layer 3 interfaces. Refer to the Troubleshooting guidelines to determine if your solution is appropriate.




Question 4 - Ticket 4 (EIGRP Load Balancing) Traffic originating from R11 in Local ISP Core destined to loopback 0 of R14 must be load balanced via EIGRP as shown in below output R11#show ip route 145.14.14.14 Routing entry for 145.14.14.14/32 Known via "eigrp 145", distance 90, metric 1703, type internal Redistributing via eigrp 145 Last update from 145.67.89.2 on Ethernet0/0, 00:02:05 ago Routing Descriptor Blocks: * 145.67.89.6, from 145.67.89.6, 00:02:05 ago, via Ethernet1/0 Route metric is 1703, traffic share count is 1 Total delay is 7000 microseconds, minimum bandwidth is 10000 Kbit Reliability 255/255, minimum MTU 1500 bytes Loading 1/255, Hops 2 145.67.89.2, from 145.67.89.2, 00:02:05 ago, via Ethernet0/0 Route metric is 1703, traffic share count is 1 Total delay is 7000 microseconds, minimum bandwidth is 10000 Kbit Reliability 255/255, minimum MTU 1500 bytes Loading 1/255, Hops 2




Possible Faults:-

1. Check for EIGRP neighborship 2. Check for EIGRP routes. 3. Check for any extra Bandwidth / Delay on R11 / R12 / R13 R14 4. Check for EIGRP Metric weight values. 5. Check for passive interface in eigrp if configured which will deny eigrp neighborship 6. Check for any distribute list which is denying loopback advertisement. 7. Check for Offset list which might be manipulating EIGRP metrics 8. Check for access-list , if any affecting.

While you are resolving these faults, your are not allowed to add new static routes, default routes or layer 3 interfaces. Refer to the Troubleshooting guidelines to determine if your solution is appropriate.




Question 5 - Ticket 5 (BGP) Networks hosted behind Internet must be able to be reached from R12 in EIGRP 145 Domain. R12 should be able to prefer the reachability through R22 rather than R21. Fix the so that the following traceroute from R12 should be matched with the output as given below: R12#traceroute 8.8.8.8 Goes via R21 R12#traceroute 194.1.1.1 Goes via R22 R12#traceroute 123.3.3.3 Goes via R4 R12#traceroute 123.21.21.21 Goes via R6




Possible Faults:-

1. Check for BGP neighborship 2. Check for BGP routes. 3. Check for next-hop-self if any missing. 4. Check for route-reflector client if any missing 5. Metric mis-configuration for particular routes on R21 / R22. 6. Metric mis-configuration for particular routes on R4 / R6 7. R12 is not enabled for EBGP Multipath. 8. Check for Local Preference on Routers if any affecting your solution for load-balancing . 9. Check for Med on Routers if any affecting your solution for load-balancing 10. Check for access-list / prefix-list / distribute-list , if any affecting. 11. Check for route-map, if any affecting.

While you are resolving these faults, your are not allowed to and add any new static routes, default routes or Layer 3 interfaces. Refer to the Troubleshooting guidelines to determine if your solution is appropriate




.

Question 6 - Ticket 6 (IPv6) The mobile phone which is connected in Mobile IPv6 network has lost access to remote server that is located in the BGP AS 65535. Fix the issue so that the following output is matched Global SP does not allow any IGP over IPv6 traffic to or from the Mobile IPv6 network MOBILE#ping 2001::26 !!!!!




Possible Faults:-

1. On R25 , check if nd suppress-ra command,then remove it. 2. Wrong Next-hop might be configured on R25 / R22 3. Check whether R25 interface pointing mobile is advertised in BGP 4. Check for ip auto-config on mobile 5. Check for default route on Mobile. 6. Check for Wrong Network/Subnet on R25 pointing towards mobile. 7. Check for access-list , if any affecting.

While you are resolving these faults, your are not allowed to configure static IP and add any new static routes, default routes or Layer 3 interfaces. Refer to the Troubleshooting guidelines to determine if your solution is appropriate.




Question 7 - Ticket 7 (DMVPN) R15 in UBER Market HQ is configured as DMVPN HUB, it should be able to connect R18 as Spoke Client. Fix the issue so that the USERs in Uber Market Sites can reach to VPN Client PC 111 attached to R18.




Possible Faults:-

1. Check DMVPN HUB / Spoke Configuration 2. Check DMVPN Tunnel Configuration. 3. Check for Network / Subnet advertisements. 4. Check DMVPN crypto configuration. 5. On R15 exclude interface ethernet 0/0 in redistribution by creating route-map 6. Check connectivity from SW5-Server2 / SW5 – R15. It should ping 7. Check Vlan and interface vlan on SW5 8. Check for access-list , if any affecting. 9. Check for route-map , if any affecting. 10. Check for Traffic-blocking / Not permitted for protocol esp / gre on R19 / 20

While you are resolving these faults, your are not allowed to add any new static routes or Layer 3 interfaces or modify acl. Refer to the Troubleshooting guidelines to determine if your solution is appropriate.




Question 8 - Ticket 8 (MPLS) The BancoBank network design requires that any outbound traffic that generates from any remote site be routed via the HeadQuarters gateways, including internet traffic. R7 must be the primary gateway of the headquarters and R8 must take over if R7 is down. Both gateways must translate the source IP address of any private corporate traffic that is destined to the internet using their interface E1/0.125. Part - 1 PC106#ping 172.16.200.200 !!!!! PC106#traceroute 172.16.200.200 It should go via R7 and on failure of R7 it should prefer R8 as backup Part - 2 PC105#traceroute 8.8.8.8 1 192.168.12.1 0 msec 0 msec 0 msec 2 192.168.13.1 1 msec 0 msec 0 msec 3 123.45.67.33 0 msec 0 msec 0 msec 4 123.45.67.13 [MPLS: Labels 22/31 Exp 0] 1 msec 1 msec 0 msec 5 123.45.67.1 [MPLS: Labels 16/31 Exp 0] 0 msec 1 msec 1 msec 6 123.45.67.21 [MPLS: Label 31 Exp 0] 0 msec 7 msec 1 msec 7 123.45.67.22 7 msec 0 msec 1 msec 8 125.45.67.21 0 msec 0 msec 1 msec 9 123.45.67.38 1 msec 0 msec 0 msec 10 134.56.78.6 1 msec 1 msec 0 msec 11 8.8.8.8 1 msec 1 msec *




Possible Faults:-

1. R3-R7 Network is not advertised in to BGP 2. R3-R4 are not importing RT of remote sites 3. R7 is not advertising default route to remote sites (default-originate) 4. R8 is not advertising default route to remote sites (default-originate) 5. IP NAT inside is not configured on R7 interface ethernet 0/0.123 6. IP NAT inside is not configured on R7 interface ethernet 0/0.124 7. IP NAT outside is not configured on R7 interface ethernet 0/0.125 8. Check for ospf cost on R4 / R6 interface ethernet 2/0 for failover 9. Check for redistribution 10. Check for metric values in redistribution 11. Check for VPNv4 Configuration full mesh BGP VPNv4 between R3/R5/R6/R7. 12. Check for access-list , if any affecting. 13. Check for route-map , if any affecting. 14. Check for Traffic-blocking for protocol , if any affecting





Question 9 - Ticket 9 (DMVPN & NAT) There is DMVPN configured between R7 - R24 via Nat Network (R23). R7 is configured as HUB and R24 as Spoke. User (PC 109) attached to R24 has lost the access to Headquaters. It must be able to reach Server in Bancobank Headquaters in BGP AS 65100. Fix the issue so that the user can reach to the Server through DMVPN. PC109#ping server1.bancobank.org !!!!! PC109#traceroute server1.bancobank.org 1 10.25.45.1 1 msec 1 msec 0 msec 2 172.247.247.1 9 msec 9 msec 10 msec 3 172.16.0.2 9 msec 9 msec 10 msec 4 server1.bancobank.org (172.16.200.200) 9 msec * 6 msec




Possible Faults:-

1. Check for ISAKMP key Address might be wrong on R7 2. R24 Tunnel source might be incorrect 3. R24 and R23 must have default route for next-hop reachabilty. 4. Check for NAT Transparency. 5. Check on R24 whether missing crypto ipsec profile configuration 6. Check R23 for NAT inside and outside . 7. IPSec parameters might not be matching, transform set wrong 8. R3 must forward the route- 125.45.67.20/30 in BGP address-family. 9. R7 might be having wrong peer address / wrong group 10. Check end-to-end reachability. 11. Check ip nat statement for port 4500 / 500 12. Check Vlan configuration on SW5 / SW6 by CDP neighbor on R23 / R24 for ping

While you are resolving these faults you are allowed to modify acl.Refer to the Troubleshooting guidelines to determine if your solution is appropriate.




Question 10 - Ticket 10 (NAS/NAT) Internet user's have lost access to the NAS server that is located in the home network. Fix the s so that the following sequence of commands produces the same output: R21#telnet nas.home.net 8008 Trying net.home.net (134.56.78.10, 8008)... Open get HTTP/1.1 400 Bad Request Date: Sun, 12 Oct 2014 21:08:02 GMT Server: cisco-IOS Accept-Ranges: none 400 Bad Request [Connection to net.home.net closed by foreign host] The NAS must be able to reach an external server as per below output: NAS#ping www.cciecloud.net Translating "www.cciecloud.net"...domain server (192.168.1.1) [OK] Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 192.168.1.4, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/1 ms

Disconnect the session after testing.


http://www.cciecloud.net/

http://www.cciecloud.net/



Possible Faults:-

1. Secondary IP address configured on R24. 2. Enable IP Domian lookup on R21 / R23 / NAS. 3. Wrong DHCP client-mac id configured on R23. 4. Wrong Network / Host ip address on R23 under DHCP for NAS

5. R23 NAT is redirecting to wrong port of NAS. 6. Check NAT statement on R23. 7. Check access-list for port 23 / 80 / 8008 8. NAS shpild have telnet enabled under line vty. 9. Check Domain Name and DNS Server on R23 under DHCP



http://www.cciecould.net/

ccie r&s v5 troubleshoot updated on 15 jan,2016€¦ · more practical information about the...

Documents