MSDPv2 tickets Q1. 4 faults: R15 is not able to use telnet to connect to R13 and R14 loopback 0. Fix problem so that the following telnet connection can be established: R15#telnet 10.1.1.13 /source-interface lo0 R15#telnet 10.1.1.14 /source-interface lo0 While you are resolving this issue, you are not allowed to create any new interfaces. Refer to the Troubleshooting guidelines to determine if your solution is appropriate. Make sure that you disconnected the telnet session after verification.
Q2 4 faults: Host 10.1.1.24 attached to R24 is not able to use telnet to connect to host 192.168.20.1 which is attached to R29. Fix problem so that the following telnet connection can be established: R24#telnet 192.168.20.1 /source-interface lo0 Do not use two way authentication. While you are resolving this issue, you are not allowed to create any new interfaces. Refer to the Troubleshooting guidelines to determine if your solution is appropriate. Make sure that you disconnected the telnet session after verification. R24 R25 R29 EIGRP AS200 Net: 172.16.14.x/29 DLCI LMI CISCO 1.1.100.0/30 RIP 192.168.20.1 S1/0=.2 S0/1=.1 PPP CHAP S0/0=.26 S1/0=.25 10.1.1.24 354 345 Frame relay 2 Switch EIGRP MD5 Authentication
3
Q3 6 faults: Host 10.1.1.20 attached to R20 is not able to ping host 10.1.1.28, which is attached to R28. Fix the problem so that the following ping result in 100-percent success: R20#ping 10.1.1.28 source lo0 This incident contains two separate faults. While you are resolving these faults, you are not allowed to add any new static or Layer 3 interfaces. Do not change any password or VTY configuration. Do not modify any configuration in OSPF Area 1 in order to resolve these faults.
Q4 5 faults: BGP AS 200 requires BGP AS 300 to consider R7 as the preferred entry point compared to R8. In other words, R28 in BGP AS 300 must select R26 172.16.15.1 as the next-hop for all prefixes from BGP AS 100 and AS 200. The less preferred path via R27 must remain available to R28 in case R26 goes down. Resolve the issue so that the following commands on R28 produce the same relevant output (all prefixes that R28 receives from R26 must be used as best path and R28 must see two available paths for these prefixes, of which 1.100.100.100 is just an example. You are not allowed to add new lines in community lists or other access lists. You are not allowed to remove any route-map or community lists from existing configuration. Do not modify any configuration from any device in BGP AS 100 and AS 300. R28#show ip bgp neighbors 172.16.15.1 | s Prefix activity|state
Output must match exactly, with no communities: R28#show ip bgp 1.100.100.100
Q5 8 faults: Hosts that are attached to R8 in BGP AS 200 must be able to receive multicast traffic that is sent from sources in BGP AS 100 to the group address 224.100.100.100. Fix the problem so that the following ping resolves replies from R8 172.16.11.11: R13#ping 224.100.100.100
You are not allowed to remove any static mroute. This incident contains two separate faults. While you are resolving these faults, you are not allowed to add any new static or Layer 3 interfaces. R1 R2 R3 R4 R6 R7 R8 R10 R11 S1/0=.10.1 Net: 172.16.11.x/29 iBGP BGP AS100 OSPF Area 0 OSPF MD5 Auth Net: 172.16.10.x/29 Net: 10.10.10.x/30 E0/1=.9 1.1.10.0/30 E0/0=.1 E0/0=.2 E0/0=.10 E0/0=.11 1.1.30.0/30 E0/0=.10 E0/1=.18 E0/3=.9 FTP Server 10.1.1.10 E0/1=.1 E0/0=.11 E0/1=.9 E0/0=.10 10.1.1.4 E0/0=.2 E0/0=.1 1.100.100.100 10.1.1.3 E0/2=.17 E 0 / 1 = . 1 4 E 0 / 0 = . 6 NMS OSPF Area 1 S1/0=.10.2 S1/1=.20.1 S1/1=.20.2 1.1.20.0/30 BGP AS200 eBGP MD5 Auth IPv4 multicast IPv4 unicast OSPF Area 1 iBGP MD5 Auth PIM PIM PIM OSPF MD5 Auth OSPF MD5 Auth RP RP SW1 SW2 1.1.40.0/30 AS200 BGP AS200 RR E0/0=.1 E0/0=.2 PIM R9 E 0 / 1 = . 1 3 E 0 / 2 = . 5 E0/1=.2 R13 E0/0=40.2 E0/2=40.1 NTP Server NTP Client NTP Client NTP Client NTP Client R12 R5
6
Q6 4 faults: All routes from OSPF Area 0 and Area 1 from BGP AS 100 have been converted to dual-stack for testing purposes. The host attached to R1 has lost access to the server attached to R4. Fix the problem so that the following Telnet connection can be established. R1#telnet 2011:CC1E:10:1:1::4 /source lo1 You are not allowed to remove or add any IPv6 ACL line, but allowed to correct it if needed. You are not allowed to remove any configuration line under interface, but allowed to correct it if needed. While you are resolving this issue, you are not allowed to remove any existing configuration line in any devices. R1 R3 R4 Net: 172.16.10.x/29 E0/1=.9 E0/0=.10 10.1.1.4 E0/0=.2 E0/0=.1 1.100.100.100 10.1.1.3 NMS OSPF Area 1 OSPF MD5 Auth RP
Q7 4 faults: R10 must be able to reach R9 via a single hop. Make sure that a traceroute from R10 to R9 resolves in one hop as shown below: R10#trace 10.1.1.9
While you are resolving this issue, you are not allowed to modify any configuration in SW1. R10 R11 OSPF Area 0 OSPF MD5 Auth Net: 10.10.10.x/30 1.1.30.0/30 E0/0=.10 E0/1=.18 E0/3=.9 FTP Server 10.1.1.10 E0/1=.1 E0/2=.17 E 0 / 1 = . 1 4 E 0 / 0 = . 6 SW1 SW2 E0/0=.1 E0/0=.2 R9 E 0 / 1 = . 1 3 E 0 / 2 = . 5 E0/1=.2 E0/2=40.1 NTP Server NTP Client NTP Client NTP Client NTP Client R12 R5
7
Q8 5 faults: R22 and R23 are sharing a virtual IP address on their interface Ethernet 0/0. R22 must be the HSRP Active router and R23 must be the Standby router. Fix the problem so that the following outputs show their expected roles.
Q9 5 faults: R5 is the NTP server for OSPF Area 0 from BGP AS 100. Fix the problem so that R13 shows the exact same output as the following: R13#sh ntp associations detail | i authenticate
R13#sh ntp status | i synchronized
R10 R11 OSPF Area 0 OSPF MD5 Auth Net: 10.10.10.x/30 1.1.30.0/30 E0/0=.10 E0/1=.18 E0/3=.9 FTP Server 10.1.1.10 E0/1=.1 E0/2=.17 E 0 / 1 = . 1 4 E 0 / 0 = . 6 SW1 SW2 E0/0=.1 E0/0=.2 R9 E 0 / 1 = . 1 3 E 0 / 2 = . 5 E0/1=.2 E0/2=40.1 NTP Server NTP Client NTP Client NTP Client NTP Client R12 R5
9
Q10 4 faults: R29 must see an established session within its inspection policy when R30 uses Telnet to connect to R31. Fix the issue so that the following sequence of commands produced the same relevant output: R30#telnet 172.16.17.2
Make sure that you disconnected the telnet session after verification. R25 R29 1.1.100.0/30 RIP 192.168.20.1 S1/0=.2 S0/1=.1 PPP CHAP R30 R31 E0/0=.1 E0/1=.1 E0/0=.2 E0/0=.2 172.16.16.x/29 172.16.17.x/29