Sie sind auf Seite 1von 9

1

Troubleshoot Question book MSDPv2


March, 2013


































2

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.

R14
R15
OSPF Area 2
DLCI
LMI CISCO
DLCI
LMI CISCO
DLCI
LMI CISCO
OSPF MD5 Auth
353
335
334
343
345
354
S1/0=.3
S1/0=.1
S0/0=.2
FR1
Switch
Net: 172.16.12.x/29
R13
NTP Client



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.

R7
R8
R16
R17 R18
R19
R20
R26
R27
R28
Net: 172.16.11.x/29
BGP AS300
Net: 172.16.15.x/29
172.16.13.x/30
OSPF Area 0
Net: 10.10.20.x/29
OSPF Area 3
MED
E0/0=.10
E0/0=.11
E0/1=.1
E0/1=.2
LP
E0/1=.1 E0/1=.2
E0/0=.1
E0/0=.3
E0/0=.2
10.1.1.28
E0/2=.1
E0/1=.2
E0/0=.1
E0/0=.2
E0/1=.1
E0/1=.2
OSPF
Virtual Link
MD5 Auth
E0/0=.1
E0/0=.2
E0/0=.3
10.1.1.20
OSPF Area 1
1.1.80.0/30
1.1.90.0/30
MED
eBGP MD5 Auth
iBGP MD5 Auth
LP
1.1.50.0/30
OSPF MD5 Auth
BGP
AS200
1.1.60.0/30
















4

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


R1 R2 R6
R7
R8
R26
R27
R28
S1/0=.10.1
Net: 172.16.11.x/29
BGP AS300
iBGP
BGP
AS100
Net: 172.16.10.x/29
Net: 172.16.15.x/29
E0/1=.9
1.1.10.0/30
E0/0=.1
E0/0=.2
MED
E0/0=.10
E0/0=.11
E0/1=.1
E0/1=.2
LP
E0/1=.1 E0/1=.2
E0/0=.1
E0/0=.3
E0/0=.2
10.1.1.28
E0/2=.1
1.100.100.100
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
1.1.80.0/30
1.1.90.0/30
MED
eBGP MD5 Auth
iBGP MD5 Auth
LP
iBGP MD5 Auth
PIM
PIM
OSPF MD5 Auth
RP AS200
BGP
AS200
RR
















5

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.





R15 R21
R22
R23
R24
OSPF Area 2
1.1.70.0/30
EIGRP AS200
Net: 172.16.14.x/29
OSPF MD5 Auth
10.1.1.24
E0/0=.35
E0/0=.33
E0/0=34
E0/0=.2
E0/0=.1
E0/1=.2
E0/1=.10
E0/1=.1
Net: 172.16.12.x/29
E0/2=.9
EIGRP MD5 Authentication















8

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

Das könnte Ihnen auch gefallen