链接：http://dans-net.com/Blog/files/TS_Challenge_is_on.html

一个tripple IE的排错实验，看了下还有点意思。前后陆陆续续花了3个小时。

以下是我发给此人的解法邮件。

 

A:eigrp AS number on R2 is misconfigered,change as number from 11 to 1.
I missed redistribution part of rip on R2,I added it this time.

I turned on "debug ip packet XXX(an acl of icmp packet only)" on R6 and found "encapsu fail" message when R6 forwords icmp packet to BB1.

So make a static arp entry mapping of 21.21.21.21 on R6.
command "arp 21.21.21.21 H.H.H arpa" on R6

A: R2's show ip rip datebase looks strange.
136.85.45.5/32
   [1] via 1.1.1.1, 00:00:27, FastEthernet0/0
It seems BB has mistakenly advertise 136.85.45.5 to R2.
so use distribute-list to prevent R2 learn this router from BB.
command On R2:
   access-list 1 deny   136.85.45.5
   router rip
   distribute-list 1 in

A: due to virtual-link configure on R4&R5. and R5's interface loopback0 configure as area 0 .chaneg R4's Loopback0 from ospf area 4 to area 0."ip ospf 1 area 0" under interface loopback0 on R4.and change R5' ospf router-id to "136.85.5.5"

>>>>Ticket 6
R4 can NOT ping R1’s or R3’s Lo0.

A:frame-relay NMBA in ospf scenario.:).
two points to stress.
1.ospf network type of these routers's subinterces.
2.make R4 to be DR!!!

R4:
interface Serial1/0.14 multipoint
 ip address 136.85.134.4 255.255.255.0
 ip ospf network point-to-multipoint
 ip ospf 1 area 4
 mpls ip
 frame-relay map ip 136.85.134.3 403 broadcast
 frame-relay map ip 136.85.134.1 401 broadcast
!
interface Serial1/0.34 point-to-point
 ip address 136.85.134.4 255.255.255.0
 ip ospf 1 area 4

R1
interface Serial1/0.14 point-to-point
 ip address 136.85.134.1 255.255.255.0
 ip ospf network point-to-multipoint
 ip ospf priority 0
 ip ospf 1 area 4
 mpls ip
 frame-relay interface-dlci 104

R3
interface Serial1/0.34 point-to-point
 ip address 136.85.134.3 255.255.255.0
 ip ospf network point-to-multipoint
 ip ospf priority 0
 ip ospf 1 area 4
 frame-relay interface-dlci 304

A:configure bgp community.BTW:I'm not quite understand this requirement.so i configure R1 to see all four bgp route from BB4,R5 has three bgp route from BB4,and R6 has only two.

>>>>Ticket 9
R6 can NOT ping 24.24.24.3. You should fix this problem without configuring BGP or any redistribution.

A:that because R4 doesn't have the route of 24.24.24.3.Configure mpls on the path from R6 to R1.so when R5 forward packer from R6 to BB4,it push a mpls label and R4 will pop it to R1.

>>>>Ticket 10
R6 is configured to ONLY allow R2 to Telnet to BB1, R2 can NOT Telnet to BB1. You should fix this problem while keeping the policy.

A:this is due to access-list 111,it only permit telnet packet destinationed to "136.85.26.2",but telnet from R2 to 21.21.21 is
translated to " 136.85.216.2", so change the access-list.
besides "ip nat inside source static 136.86.26.2 136.85.216.2" the nat inside address should be "136.85.26.2" not "136.86.26.2"

 

 

=================================

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.

 

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

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.

 

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.

 

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.

 

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.

 

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.

 

The problem:

 

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

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

 

·  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”.

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.

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.