MSDPv2 Qbook

8/12/2019 MSDPv2 Qbook

1/9

1

Troubleshoot Question book MSDPv2

March, 2013


2/9

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 lo0While 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.

R 4

R 5

OSPF Area 2DLCILMI CISCO

DLCI

LMI CISCO

DLCI

LMI CISCO OSPF MD5 Auth

353

335334

343

345

354S1/0=.3

S1/0=.1

S0/0=.2

FR1

Switch

Net: 172.16.12.x/29

RNTP 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.

R R 5 R 9

EIGRP AS200

Net: 172.16.14.x/29 DLCILMI CISCO

1.1.100.0/30

RIP

192.168.20.1

S1/0=.2

S0/1=.1

PPP CHAP

S0/0=.26S1/0=.25

10.1.1.24

354345

Frame relay 2

Switch

EIGRP MD5 Authentication


3/9

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

R 6

R 7 R 8

R 9

R2

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/9

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 which1.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

R R R6

R7

R8

R 6

R 7

R 8

S1/0=.10.1

Net: 172.16.11.x/29BGP AS300

iBGP

BGP

AS100Net: 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

PIMPIM

OSPF MD5 Auth

RP AS200

BGP

AS200

RR


5/9

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.

R R23

R4

R6

R7

R8

R

R

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=.10E0/1=.18

E0/3=.9

FTP Server

10.1.1.10E0/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

E0/1=.1

4E0/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

PIMPIMPIM

OSPF MD5 AuthOSPF MD5 Auth

RP RP

SW1 SW2

1.1.40.0/30

AS200

BGP

AS200

RR

E0/0=.1E0/0=.2

PIM

R9E0/1=.13

E0/2=.5

E0/1=.2

R 3

E0/0=40.2

E0/2=40.1

NTP Server

NTP Client NTP Client


R 2

R5


6/9

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.

R

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.

R

R

OSPF Area 0

OSPF MD5 Auth

Net: 10.10.10.x/30

1.1.30.0/30

E0/0=.10E0/1=.18

E0/3=.9

FTP Server

10.1.1.10E0/1=.1

E0/2=.17

E0/1

=.14E0

/0=.6

SW1 SW2

E0/0=.1E0/0=.2

R9E0/1

=.13

E0/2

=.5

E0/1=.2

E0/2=40.1

NTP Server


NTP ClientNTP Client

R 2

R5


7/9

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.

R 5 R

R

R 3

R 4

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/9

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

R

R

OSPF Area 0

OSPF MD5 Auth

Net: 10.10.10.x/30

1.1.30.0/30

E0/0=.10E0/1=.18

E0/3=.9

FTP Server

10.1.1.10E0/1=.1

E0/2=.17

E0/1=.14E0/0

=.6

SW1 SW2

E0/0=.1E0/0=.2

R9E0/1=.13

E0/2=.5

E0/1=.2

E0/2=40.1

NTP Server


NTP ClientNTP Client

R 2

R5


9/9

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 R291.1.100.0/30

RIP

192.168.20.1

S1/0=.2

S0/1=.1

PPP CHAP

R3

R3

E0/0=.1

E0/1=.1

E0/0=.2

E0/0=.2

172.16.16.x/29

172.16.17.x/29

Documents

MSDPv2 Qbook