Troubleshooting summary
1、R100 does not receive the "/16" route of R1-R7
Solution: To confirm the first problem, R42 is controlled by redistribution using route-map. As a result, I directly applied the prefix list without the associated route-map. Confirm that R10/R11/R20/R21 are critical devices, because these devices do not have a policy of forwarding only local routes. It is normal to try to remove the prefix of R20/R21 out. Locate the prefix and restore it after reconfiguration. R100, AS65004, AS65005, and AS65006 do not receive the 10.7.0.0/16 route. The policy check is correct. Finally, the static mask error of R24 about 10.7 is written as /25, which is filtered out.
2、The R20 route is sent and received abnormally. The phenomenon of "10.4.0.0/16" is incorrect. CCIE Routing and Switching are important for us. The phenomenon is as follows:
Solution: After testing the RR of R23, it was found that R20 could not receive the "10.4.0.0/16" route from R4 and confirmed that MPLS-VPNV4 had a problem with RT. At the same time, check the R40 "out" direction strategy, "show ip bgp nei x.x.x.x ad", locate on MPLS R6 and R4, and finally confirm the R4 RT import exception.
Screenshot below:
3、The final phenomenon graph of R10 has a "10.4.0.0/16" next hop error.
After troubleshooting, it is confirmed that R11 is not received from ISP10001, and the "out" filter-list of R41 is unloaded and restored. Then R11 got the route and the R13 reflector was also taken. R13 did not optimize the AS number for the shortest join, but chose R10 to receive it from MPLS.
Screenshot below:
Feedback to the teacher, said that R11 is not configured with "next-hop-self", resulting in R13 eventually not selecting R11's "10.4.0.0/16", supplementing R11's "next-hop-self", returning to normal
Screenshot below:
Key: Note that in R13 "show ip bgp 10.4.0.0/16", if the table is normal, the metric will be displayed. If it is not normal, the word "inaccessible" will appear.
Screenshot below:
4、R60 cannot traceroute "10.5.100.252" (SW501)
Solution: Confirm that there is a problem with the R14 and R51 strategies. Remember the routing control of R14 and R51. Be sure to release the other (add a "permit 20"). First trigger the next hop optimization of NHRP, then try to hang the "out" strategy for R13 on R14. Soft clean and then test.
5、R13 ping multicast 239.250.1.1 no echo
Solution: SW111 vlan2001 is not announced in the IGP, and has not been added to the "239.250.1.1" IGMP group.
6、R51 receives the 10.6 route, but cannot pass it to the IBGP neighbor, and at the same time, it circumvents MPLS from R50.
Solution: Before I think of it, there is a problem that after the BGP routing is stabilized, he will be stable on the device that establishes the BGP neighbor for the longest time. Therefore, the "best" seen at this time is R50, because my configuration order R50 will be received "10.6" first. Finally, hard clear the BGP neighbors of the R50, and the phenomenon is coming out!
Solution: To confirm the first problem, R42 is controlled by redistribution using route-map. As a result, I directly applied the prefix list without the associated route-map. Confirm that R10/R11/R20/R21 are critical devices, because these devices do not have a policy of forwarding only local routes. It is normal to try to remove the prefix of R20/R21 out. Locate the prefix and restore it after reconfiguration. R100, AS65004, AS65005, and AS65006 do not receive the 10.7.0.0/16 route. The policy check is correct. Finally, the static mask error of R24 about 10.7 is written as /25, which is filtered out.
2、The R20 route is sent and received abnormally. The phenomenon of "10.4.0.0/16" is incorrect. CCIE Routing and Switching are important for us. The phenomenon is as follows:
Solution: After testing the RR of R23, it was found that R20 could not receive the "10.4.0.0/16" route from R4 and confirmed that MPLS-VPNV4 had a problem with RT. At the same time, check the R40 "out" direction strategy, "show ip bgp nei x.x.x.x ad", locate on MPLS R6 and R4, and finally confirm the R4 RT import exception.
Screenshot below:
3、The final phenomenon graph of R10 has a "10.4.0.0/16" next hop error.
After troubleshooting, it is confirmed that R11 is not received from ISP10001, and the "out" filter-list of R41 is unloaded and restored. Then R11 got the route and the R13 reflector was also taken. R13 did not optimize the AS number for the shortest join, but chose R10 to receive it from MPLS.
Screenshot below:
Feedback to the teacher, said that R11 is not configured with "next-hop-self", resulting in R13 eventually not selecting R11's "10.4.0.0/16", supplementing R11's "next-hop-self", returning to normal
Screenshot below:
Key: Note that in R13 "show ip bgp 10.4.0.0/16", if the table is normal, the metric will be displayed. If it is not normal, the word "inaccessible" will appear.
Screenshot below:
4、R60 cannot traceroute "10.5.100.252" (SW501)
Solution: Confirm that there is a problem with the R14 and R51 strategies. Remember the routing control of R14 and R51. Be sure to release the other (add a "permit 20"). First trigger the next hop optimization of NHRP, then try to hang the "out" strategy for R13 on R14. Soft clean and then test.
5、R13 ping multicast 239.250.1.1 no echo
Solution: SW111 vlan2001 is not announced in the IGP, and has not been added to the "239.250.1.1" IGMP group.
6、R51 receives the 10.6 route, but cannot pass it to the IBGP neighbor, and at the same time, it circumvents MPLS from R50.
Solution: Before I think of it, there is a problem that after the BGP routing is stabilized, he will be stable on the device that establishes the BGP neighbor for the longest time. Therefore, the "best" seen at this time is R50, because my configuration order R50 will be received "10.6" first. Finally, hard clear the BGP neighbors of the R50, and the phenomenon is coming out!
评论
发表评论