OCT. 9, 2012 TS WORKBOOK (MPLS VERSION)

MPLS tickets (TS4)

Q1.

On R22 is not able to use Telnet to connect to R23

Loopback 0. Fix problem so that the following Telnet

connection can be established:

R22#telnet 10.1.1.23 /source-interface loopback 0

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.

R23

R22

OSPF Area 2

Net: 172.16.12.x/30

OSPF MD5 Auth

S1/0=.1

S0/0=.2

FR2switchDLCI

LMI CISCO

22

23

S0/1

S0/0

Q2

On R14, host 10.1.1.14 is not able to

use Telnet to connect to host

10.1.1.8 and to host 10.1.1.7. Fix

problem so that the following

Telnet connection can be establish:

R14#telnet 10.1.1.8 /source-

interface loopback 0

R14#telnet 10.1.1.7 /source-

interface loopback 0

While you are resolving this issue,

you are not allowed to create any

new Layer 3 interfaces. Refer to the

Troubleshooting guidelines to

determine if your solution is

appropriate. Make sure that you

disconnect the telnet session after verification.

R7 R8

R9 R10

R11

R12

OSPF Area 0

Net: 10.10.10.x/30

OSPF MD5 Auth

10.1.1.7E0/3=.25

E0/1=.21E0/2=.17

E0/1=.18 E0/0=.14

E0/2=.13E0/1=.9

E0/0=.10 E0/1=.22

E0/3=.26

E0/3=.29

E0/2=.37

E0/0=.38

E0/2=.41

E0/0=.42

10.1.1.14

10.1.1.12

E0/0=.30

10.1.1.11

10.1.1.8

R14

SW1 SW2

R13

E0/3=.33

E0/0=.34

Q3

Host 200.20.20.20 attached to R20 is not able to ping host 192.168.20.1, which attached to R26 in RIP

domain. Fix the problem so that the following ping results in 100 percent success:

R20#ping 192.168.20.1 source lo3

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.

R22

R20R21

R24

R25

R26

R27

OSPF Area 0

OSPF Area 1 NSSA

Net: 172.16.11.x/30

Net: 172.16.13.x/29

OSPF MD5 Auth

OSPF MD5 Auth

E0/1=.5

E0/0=.6

E0/0=.1

E0/0=.2

345

354

351

315

341

314S1/0=.1

S1/0=.2

S0/0=.3

DLCILMI CISCO

DLCILMI CISCO

DLCILMI CISCO

E0/0=.9

E0/0=.10

E0/0=.11

10.1.1.27

192.168.20.1

FR1switch

RIP

S0/0

S0/2

S0/1

200.20.20.20

Q4

All four provider edge PE routers

must see Loopback 1 addresses

of other three PE with two

available paths in their own IPv4

BGP table and must see each of

these prefixes in their IPv4

routing table as BGP prefix of

which the next-hop is the

remote PE loopbacks 0.

Make sure to accomplish this

task for all four PE.

Use the following output as an example of what R3 must see. (It doesnt matter which one of the two

paths is chosen as the best path as long as it sees two available paths per next-hop).

R1 R2

R3

R4 R6

R5

OSPF Area 0

Net: 192.168.10.x/30

OSPF MD5 Auth

iBGP MD5 Auth

PE

PE

PEPE

E0/1=.34

E0/0=.6

E0/0=.5

E0/1=.9

E0/0=.10

E0/1=.30 E0/0=.14

E0/1=.26

E0/1=.25

E0/0=.21

E0/1=.22

E0/0=.18

E0/3=.33

E0/2=.29E0/2=.13

E0/3=.17

iBGP AS3 iBGP AS3

iBGP AS3 iBGP AS3

RRRR

Q5

Host 171.1.1.1 attached to R8 in VPN Site-A1 cannot ping host 171.2.2.2, which is attached to R20 in

VPN Site-A2. Fix the problem so that the following ping resolves in 100 percent success:

R8#ping 171.2.2.2 source lo1

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.

R1 R2

R3

R4 R6

R5

R8

R20

OSPF Area 0

OSPF Area 0

Net: 192.168.10.x/30

Net: 172.16.11.x/30

Net: 172.32.10.x/30Area 101

Area 101

OSPF MD5 Auth

OSPF MD5 Auth

10.10.10.4/30

iBGP MD5 Auth

PE

PE

PEPE

CE

CE

VPN Site A2171.2.2.2

VPN Site A1171.1.1.1

E0/1=.34

E0/0=.6

E0/0=.5

E0/1=.9

E0/0=.10

E0/1=.30 E0/0=.14

E0/1=.26

E0/1=.25

E0/0=.21

E0/1=.22

E0/0=.18

E0/3=.33

E0/2=.29E0/2=.13

E0/3=.17

E0/2=.5

S1/0=.1

S1/0=.2

iBGP AS3 iBGP AS3

iBGP AS3 iBGP AS3

RRRR

E0/0=.6

OSPF MD5 Auth

Q6

All six routers in Area 0 from the MPLS Core have been connected to IPv4-IPv6 dual-stack for testing

purposes. R8 is simulating an IPv6 host: it must receive its IPv6 address directly from R5 and must not

participate in any IPv6 routing protocol.

Loopback 100 for R4 is simulating an IPv6 server with IPv6 address 2001:CC1E:100::100/128.

The Ipv6 host R8 has lost connectivity to the IPv6 server. (R4 loopback 100).

Fix the problem so that the following ping resolves in 100 percent success:

R8#ping 2001:CC1E:100::100

You are allowed to use any method to resolve this issue but you are not allowed to manually configure a

specific IPv6 address in R8. You are also not allowed to add any new static route or Layer 3 interfaces.

Do not change any password or VTY configuration.

R1 R2

R3

R4 R6

R5

R8

OSPF Area 0

Net: 192.168.10.x/30

Area 101

OSPF MD5 Auth

10.10.10.4/30

iBGP MD5 Auth

PE

PE

PEPE

E0/1=.34

E0/0=.6

E0/0=.5

E0/1=.9

E0/0=.10

E0/1=.30 E0/0=.14

E0/1=.26

E0/1=.25

E0/0=.21

E0/1=.22

E0/0=.18

E0/3=.33

E0/2=.29E0/2=.13

E0/3=.17

E0/2=.5

iBGP AS3 iBGP AS3

iBGP AS3 iBGP AS3

RRRR

E0/0=.6

10.1.1.8

OSPF MD5 Auth

Q7

Traffic that is marked with IP precedence 4 and coming from hosts 10.1.1.11 or 10.1.1.12 must reach R7

or R8 with IP precedence 5.

Fix the problem so that the following extended ping result in 100 percent success:

While resolving this issue, you are not allowed to modify the configuration of any existing access-list in

R7, R8 or R9

R7 R8

R9 R10

R11

R12

OSPF Area 0

Net: 10.10.10.x/30

OSPF MD5 Auth

10.1.1.7E0/3=.25

E0/1=.21E0/2=.17

E0/1=.18 E0/0=.14

E0/2=.13E0/1=.9

E0/0=.10 E0/1=.22

E0/3=.26

E0/3=.29

E0/2=.37

E0/0=.38

E0/2=.41

E0/0=.42

10.1.1.14

10.1.1.12

E0/0=.30

10.1.1.11

10.1.1.8

R14

SW1 SW2

R13

E0/3=.33

E0/0=.34

Q8

R27 Ethernet 0/0 is supposed to stat administratively

enabled at all times. (It is currently connected to a hub so

will stay up/up once enabled). The administrator has

configured and EEM script that should automatically re-

enable the interface if it is manually disabled.

The script is not working as expected.

Fix the issue so that the interface is automatically re-

enabled when someone issues the shutdown command under the interface e0/1.

R27

OSPF Area 1 NSSA

Net: 172.16.13.x/29

E0/0=.11

10.1.1.27

Q9

Host 10.1.1.16 attached to R16 is not able to use Telnet to connect to host 10.1.1.19, which is attached

to R19.

Fix problem so that the following Telnet connection can be established:

R16#telnet 10.1.1.19 /source-interface loopback 0

While you are resolving this issue, you are not allowed to create any new interfaces. Do not remove any

ACL in this configuration.

Refer to the Troubleshooting guidelines to determine if your solution is appropriate. Make sure that you

disconnected the telnet session after verification.

R16 R15

R17

R18

R19

EIGRP AS200

Net: 172.16.10.x/29

EIGRP MD5 Auth

PPP CHAP

NTP client

NTP client

NTP MD5 Auth

DHCP ServerNetwork 172.16.10.16/29

10.1.1.19

E0/1=.1

E0/0=.19

DHCP client

E0/1 E0/0=.10

DHCP client

E0/1 E0/0=.11

E0/0=.9

10.1.1.16

S1/0=.2

S0/1=.1

NTP Server

Q10

R20 Ethernet 1/0 must be able to use Telnet to connect to the host 172.16.11.10, which connected to

R22 Ethernet 1/0.

When using Telnet on port 23, the source address must always be translated to R22 Ethernet 1/0 before

matching the destination host.

When using Telnet on port 80, the source address must always be translated to R22 Loopback0.

R20#telnet 172.16.11.10

R20#telnet 172.16.11.10 80

Fix the problem so that the following NAT entries are seen on R22, when the two aforementioned

connections are successfully established (inside global IPs and outside global IPs and ports must match).

While you are resolving this issue, you are 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.

TG1R22

R20

OSPF Area 0

Net: 172.16.11.x/30

OSPF MD5 Auth

E0/1=.5

E0/0=.6

E0/1=.9

E0/0=.10