Chalange Lab - Solutions

Challenge lab - Solution

 

Ticket 1:

 

The problems:

 

There are two problems:

 

1.     R2 is missing DLCI mapping for its P2P interface S1/0.26.

2.     R2 is using EIGRP process #11 while R6 is using process #1. They need to match in-order for EIGRP to form an EIGRP relationship.

 

The Fix: 

 

1.     Map interface S1/0.26 to DLCI 206.

2.     Change R2's EIGRP process # to 1. 

3.     Also remember to fix the redistribution of EIGRP to RIP because you deleted Eigrp 11.

 

Ticket 2:

 

The problem:

 

R6 was configured with a static route to 21.21.21.21 pointing to F0/0 as the next hop.

 

When using a static route pointing to an Ethernet interface, R6 will use proxy-arp, and send an ARP request on F0/0 for 21.21.21.21.

 

The problem is that BB1 is not responding to these requests.

 

The fix:

 

Add a static arp entry to map 21.21.21.21 to BB1's F0/0 MAC address.

 

 
Ticket 3:


Notice: There is a problem, really!!!!

 
The problem:


ODR is enabled on R6. BB2 has a bogus interface IP address with R2's F0/0 IP address.

 

When pinging from R6, we actually ping BB2 and not R2. We need to enable ICMP debugging on R2 to verify this.

 

The fix:

 

Disable CDP on the interface facing BB2, R6's F0/1.

 
Ticket 4:

 

The problem:

 

Someone, sourced at 1.1.1.1 is injecting bogus RIP routes to R2's F0/0 interface. 

 

R2 should have discarded these RIP advertisements, but it was configured with "no validate-update-source" in its RIP process configuration.

 

Also, there is no EIGRP neighbor adjacency between R5 and R6 as R5 is configured with passive-interface default.

 

The fix:

 

Re-enable the "validate-update-source" on R2 and remove the "passive-interface default" from R5.

 

Ticket 5:
 

The problem:

 

R5's router ID is not set manually, therefore, OSPF process choose 200.5.5.5 instead of 136.86.5.5, but the virtual link configured on R4 is using R5's Lo0 ip address.

 

The fix:

 

Set the OSPF router-id on R5 manually, and bounce the OSPF process.

 

 
Ticket 6:
 

The problem:

 

R3's Serial1/0 interface is administratively down.

 

R4 is using the same IP address for both S1/0.14 and S1/0.34, resulting in duplicate IP address, and we all know that OSPF can't handle this with it’s SPF calculation.

 

Note, here the diagram is wrong, and that was done on purpose. As in real life, documentation is not always perfect, and since this task is all about IP addressing, you might have missed the duplicate IP addresses by just relying on the diagram. But a closer look should have raised some questions.

 

The fix:

 

Enable (No shut) interface Serial1/0 on R3.

 

Use "ip unnumbered s1/0.14" on s1/0.34 or place s1/0.34 under different OSPF process.

 

 
Ticket 7:
 

The problem:

 

R4 is the DR on the link towards R6. However R4 has no RP mappings.

 

The fix:

 

Configure R4 not to be the DR by settings its priority to 0. Now R5 is the DR on the link between R5 and R4, and R5 knows who the RP is.

 

 
Ticket 8:
 

The problem:

 

Both the route-map and the distribute-list where configured to comply with the policy, but they do not work together. The order of operation as far as policy enforcement in BGP is very important BUT an easy task to remember:
 

·  Outbound policy evaluation order: Don't Plan Fix Results.

·  Inbound policy evaluation order: the reverse order of the outbound order.

 

What does “Don't Plan Fix Results” stands for?
 

·  D – Distribute-list

·  P – Prefix-list

·  F – Filter-list (AS path filter)

·  R – Route-map

 

The route-map that's setting the "no-export" community is also filtering all other routes before ACL#11 has a chance to filter only the 24.24.24.1 prefix.

 

The fix:

 

Configure the "fromBB4" route-map to allow all other routes from BB4, and do a “clear ip bgp 24 in”.

 
 
Ticket 9:
 

The problem:

 

R4 is not part of the BGP network, therefore, it doesn’t know about BB4's routes.

 

The fix:

 

Enable MPLS on the interfaces between R1 and R5.

 

Set the LDP router-ID on R5. You will need to reload R5.


There is no need to set a static route on R1 for R5's Lo0 IP address, as we do not need an LSP on the way back, as R4 knows how to reach R6's IP addresses. .
You can also use NAT on R5 or even IPSEC tunnel on R5 or R6.
Ticket 10:
 

The problem:

 

The static NAT IP local inside IP address is wrong.

 

R6 is using NAT to allow R2 to communicate with BB1, as BB1 doesn’t have a route back to R2.

 

R6 is using an inbound ACL which is using R2's real address instead of R2's global address.

 

The fix:

 

Fix NAT IP addresses.

 

Change the ACL to allow returning traffic to R2's global address.