Demonstration: Analysis and troubleshooting of RIP route updates

Demonstration: Analysis and troubleshooting of RIP route updates

Fault Background: In the network environment shown in 14.6, engineers configured the interface address on the corresponding interface and started the RIP route protocol throughout the network, for some special reasons, the vros2 S2/0 interface does not have a specific IP address configured. The Unnumbered IP address (ipunnumbered e1/0) is used ), in fact, the IP address on the S2/0 interface is borrowed from the E1/0 interface. In the actual production environment, this Unnumbered IP address is generated to save IP addresses on point-to-point links and prevent address waste. Therefore, this application is valid. For some security features, the engineer configures the ACL list in the Inbound direction of the E1/0 interface of router R1, only subnets with the source address 192.168.3.1 and source subnet 192.168.6.0/24 can access any network. Other traffic is denied by the Deny statement hidden by ACL101. After completing the preceding configuration, there is now a phenomenon: Router R1 cannot learn any route 14.7, R2 route learning is completely normal, and R3 cannot learn any route 14.8.

Analyze the causes of these faults and troubleshoot the faults without changing the original configuration.

Original configuration for fault generation: the original configuration for fault generation is as follows.

Original configuration of router R1:

Interface Loopback1

Ip address 192.168.5.1 255.255.255.0

!

InterfaceEthernet1/0

Ip address 192.168.2.1 255.255.255.0

Ip access-group 101 in

Duplex half

!

Router rip

Version 2

Network 192.168.2.0

Network 192.168.5.0

No auto-summary

Access-list 101 permit ip host 192.168.3.1 any

Access-list 101 permit ip 192.168.6.0 0.0.255 any

Original configuration of vror2 R2:

InterfaceEthernet1/0

Ip address 192.168.2.2 255.255.255.0

Duplex half

!

Interface serial/0

Ip unnumbered Ethernet1/0

Encapsulation ppp

!

Routerrip

Version 2

Network 192.168.2.0

No auto-summary

Original configuration of router R3:

Interface Loopback1

Ip address 192.168.6.1 255.255.255.0

!

Interface serial/0

Ip address 192.168.3.2 255.255.255.252

Encapsulation ppp

!

Router rip

Version 2

Network 192.168.3.0

Network 192.168.6.0

No auto-summary

Fault Analysis: in the actual working environment, sometimes faults are not in the same place. For example, the fault occurs on routers R1 and R3, and the middle router R2 works normally, in case of such a composite fault, divide and conquer the fault and conduct independent analysis. This can reduce the scope of troubleshooting after overlap. Note that this is a very good suggestion. So now we need to use the debug ip rip events command on router R3 to debug the RIP operation process. In this way, we can see the data packets that RIP works on the background, as shown in 14.10, it indicates that the S2/0 interface of router R3 receives a bad RIP packet. The source address for sending a bad RIP packet is 192.168.2.2, which is actually the S2/0 interface of router R2, because the S2/0 interface of router R2 is an ip address borrowed from E1/0, the cause of this fault is that S2/0 of router R2 uses an unnumbered ip address (ip unnumbered ), the S2/0 interface of router R3 uses a specific IP address. In this case, router R3 checks the validity of the update source, the route update source address of router R2 must be in the same subnet as the IP address on its S2/0 interface. Otherwise, router R3 reports that it has received bad route updates, there are two solutions to this fault: one is to configure a specific IP address with the same subnet as the S2/0 interface of router R2, however, this solution has damaged the original Some address designs change the original configuration, because in many cases, troubleshooting is based on the principle of not damaging the original configuration of the device. The second solution is to disable the RIP update source legality check function on router R3. By default, this function is enabled. For specific troubleshooting procedures, see solution, after this behavior is completed, you can see that the router R3 is learned normally, and the route table successfully learns the route update sent by R2, as shown in 14.12. The router R3.

The configuration on router R1 seems reasonable because the ACL allows all remote subnets In the RIP network to reach router R1. In this case, you should first use the debug ip rip event command on router R1 to check the RIP Update Status, as shown in Figure 14.11, indicating that router R1 has not received any route updates from router R2, if the physical link is normal and the RIP configuration is normal, the hidden Deny statement of the ACL rejects the RIP update multicast address whose target address is 224.0.0.9, this will cause the RIP route update to fail. The solution is to add a multicast address that allows the destination address 224.0.0.9 to the existing ACL of router R1 to reach router R1,

For more information about the troubleshooting process, see solution. After completing this action, you can see that router R1 learns normally, as shown in Figure 14.13. The fault is successfully rectified.

Solution:

R3 (config) # router rip

R3 (config-router) # no validate-update-source * disable the RIP update source validity check.

R3 (config-router) # exit

R1 (config) # access-list 101 permit ip any host 224.0.0.9

* Adds an ACL entry that allows the RIP to update multicast entries.

This article is from the "untitled Christ" blog and will not be reproduced!