2. MPLSv1 ticket
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
FR2
switchDLCI
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.7
E0/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
- 2 -
Specially created for certcollection.org
Specially created for certcollection.org
Specially
created
forcertcollection.org
Specially
created
forcertcollection.org
3. 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
VPN SiteA2
171.2.2.2
E0/1=.5
E0/0=.6
E0/0=.1
E0/0=.2
345
354
351
315
341
314
S1/0=.1
S1/0=.2
S0/0=.3
DLCI
LMI CISCO
DLCI
LMI CISCO
DLCI
LMI CISCO
E0/0=.9
E0/0=.10
E0/0=.11
10.1.1.27
192.168.20.1
FR1
switch
RIP
S0/0
S0/2
S0/1
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.
R1 R2
R3
R4 R6
R5
Net: 192.168.10.x/30
OSPF MD5 Auth
iBGP MD5 Auth
S1/0=.1
PE
PE
PE
PE
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=.29
E0/2=.13
E0/3=.17
E0/2=.5
iBGP iBGP
iBGP iBGP
RRRR
BGP AS3
OSPF Area 0
Use the following output as an example of what R3 must see. (It doesn’t matter which one of the two paths
is chosen as the best path as long as it sees two available paths per next-hop).
- 3 -
Specially created for certcollection.org
Specially created for certcollection.org
Specially
created
forcertcollection.org
Specially
created
forcertcollection.org
4. 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
Net: 192.168.10.x/30
Net: 172.32.10.x/30
Area 101
Area 101
OSPF MD5 Auth
OSPF MD5 Auth
10.10.10.4/30
iBGP MD5 Auth
S1/0=.1
PE
PE
PE
PE
CE
CE
VPN SiteA2
171.2.2.2
VPN SiteA1
171.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=.29
E0/2=.13
E0/3=.17
E0/2=.5
E0/2=.1
S1/0=.1
S1/0=.2
iBGP iBGP
iBGP iBGP
RRRR
E0/0=.6
OSPF MD5 Auth
BGP AS3
OSPF Area 0
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.
- 4 -
Specially created for certcollection.org
Specially created for certcollection.org
Specially
created
forcertcollection.org
Specially
created
forcertcollection.org
5. R1 R2
R3
R4 R6
R5
R8
Net: 192.168.10.x/30
Area 101
OSPF MD5 Auth
10.10.10.4/30
iBGP MD5 Auth
10.1.1.8
S1/0=.1
PE
PE
PE
PE
CE
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=.29
E0/2=.13
E0/3=.17
E0/2=.5
E0/2=.1
iBGP iBGP
iBGP iBGP
RRRR
E0/0=.6
OSPF MD5 Auth
BGP AS3
OSPF Area 0
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.
- 5 -
Specially created for certcollection.org
Specially created for certcollection.org
Specially
created
forcertcollection.org
Specially
created
forcertcollection.org
6. R7 R8
R9 R10
R11
R12
OSPF Area 0
Net: 10.10.10.x/30
OSPF MD5 Auth
10.1.1.7
E0/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/1 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.
- 6 -
Specially created for certcollection.org
Specially created for certcollection.org
Specially
created
forcertcollection.org
Specially
created
forcertcollection.org
7. 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 Server
Network
172.16.10.16/2910.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
R20OSPF Area 0
Net: 172.16.11.x/30
OSPF MD5 Auth
E0/1=.5
E0/0=.6
E0/1=.9
E0/0=.10
- 7 -
Specially created for certcollection.org
Specially created for certcollection.org
Specially
created
forcertcollection.org
Specially
created
forcertcollection.org
