OSPF topology troubleshooting report

OSPFTroubleshooting report

 

Fault Point 1: PPPLink fault

Fault symptom:

The PPP link between R2.

Fault analysis:

1) whether the PPP authentication types are consistent

2) whether the user configured for ppp chap authentication is correct

3) is the pppp chap authentication password correctly configured?

4) whether the user performing CHAP authentication includes the PPP service type

Troubleshooting:

1) Use "display current-configuration int S0/1/0" on rt2 to view the authentication configuration under the interface. It is found that the local authentication type is chap and the authentication user and password are configured, run the preceding command on rt4 to view the authentication configuration under the interface. The configured authentication username and password are both rt2.

2) use "display current-configuration conf luser" on rt4 to check whether the rt4 password of the authenticated user configured on rt2 is correct and whether it contains the service type PPP.

3) Use "display current-configuration conf luser" on rt2 to find that the CHAP authentication user configured on rt4 does not exist. In the system view, enter "Local-user rt2 ", create a local user rt2, enter "password simple rt2" in this mode to set the rt2 password to rt2, and use the "service-type PPP" command to set the service type to PPP.

4) enter the S0/1/0 interface on rt2, execute the shudown and undo shutdown commands, close the interface and activate the interface, and re-negotiate the interface for PPP authentication.

5) run the "display IP interface brief" command on rt2 and rt4 to check the interface status of the PPP link. The physical and Protocol dual-up is detected and the fault is eliminated.

Fault point 2: MSTPFault

Fault symptom:

Run the "display STP brief" command on SW1, sw2, and sw3 to check the role status of the interface of the MSTP instance, and find that the blocked interface does not meet the question requirements, sw2 and sw3 have master role interfaces.

Fault analysis:

1) Whether to create the VLAN corresponding to the MSTP instance

2) whether the encapsulation type of the device interconnection interface is trunk

3) whether the device interconnection interface allows business VLAN

4) is the domain name of the MSTP domain configuration of the device consistent?

5) whether the VLAN and instance ing relationship of the MSTP domain configuration information of the device are consistent

6) Whether to manually specify the Master/Slave root of the Instance

Troubleshooting:

1) Use "display STP brief" on SW1, sw2, and sw3 to view VLAN information. It is found that all three devices have business vlan10 and vlan20 as required.

2) use "display port trunk" on SW1, sw2, and sw3 to view the trunk interfaces and interfaces of the three devices, it is found that all the device interconnection interfaces are encapsulated as trunk and the service VLAN required by the topic is allowed.

3) using "display STP region-configuration" on SW1, sw2, and sw3, we found that none of the three devices have manually configured domain names, use "STP region-configuration" in the System View of SW1, sw2, and sw3 to enter the MSTP domain configuration view. Use "region-name H3C" to set the same domain name, execute "active region-configuration" to reactivate the domain configuration information.

4) use "display STP brief" on SW1, sw2, and sw3 to view the corresponding interface role of the instance. It is found that instance 1 corresponding to sw3 blocks the E0/4/1 interface, instance 2 blocks the E0/4/0 interface, while instance 1 blocks the E0/4/0 interface, and instance 2 blocks the E0/4/1 interface, which does not meet the requirement.

5) in the System View of SW1 and sw2, use "display current-configuration Configuration | include root" to view the master and slave root settings of the instance. It is found that the master root of instance 1 is sw2, the slave root is SW1. The master root of instance 2 is SW1 and the slave root is sw2, which does not meet the requirements of the question. In the system view of SW1, enter:

STP instance 1 Root primary

STP instance 2 root secondary

Make SW1 the master root of instance 1 and the slave root of instance 2

In the system view of sw2, enter:

STP instance 2 Root primary

STP instance 1 root secondary

Make sw2 the master root of instance 2 and the slave root of instance 1

6) use "display STP brief" on sw3 to view the role information of the interface, and find that the instance is blocked by E0/4/0, and the instance is blocked by E0/4/1. Troubleshooting.

Fault 3: vrrpFault

Fault symptom:

When "display vrrp" is used on SW1, it is found that VLAN 10 is the backup role. When "display vrrp" is used on sw2, it is found that VLAN 10 is the master role, while VLAN 20 is the int state.

Fault analysis:

1) whether a reasonable priority is configured

2) whether the virtual IP address is correct

Troubleshooting:

1) Use "display current-configuration int VLAN-interface 10" on SW1 to view the vrrp configuration information of vlan10. No configuration priority is found, run the same command on sw2 to view the vrrp configuration information of VLAN 10. It is found that the IP address of VLAN 10 on the VLAN Interface of sw2 is 192.168.0.253 24, because VLAN 10 on SW1 has no configuration priority, therefore, the default priority of both ends is 100. The determination of the master and backup roles depends on the interface IP address value. Because the interface IP address of sw2 vlan10 is large, it is the IP address owner.

Use "int VLAN-interface 10" on SW1 to enter the interface view of VLAN 10. Use "vrrp vrid 1 Priority 110" to change the priority to 110, use "display vrrp" on SW1 to view vrrp information. It is found that the role of VLAN 10 has changed to master.

2) use "display current-configuration int VLAN-interface 20" on SW1 to view the vrrp configuration of VLAN 20. No problems are found, run this command on sw2 to view the vrrp configuration of VLAN 20. The virtual machine address of VLAN 20 is incorrect and the interface address is not in the same network segment, use "int VLAN-interface 20" on sw2 to enter the interface of VLAN 20, and use "undo vrrp vrid 2 virtual-IP 10.1.1.254" to delete the virtual address of VLAN 20, use "vrrp vrid 2 virtual-IP 10.1.0.254" to change the VLAN 20 address to 10.1.0.254. Use "display vrrp" on sw2 to view vrrp information and find that VLAN 20 of sw2 has become the master role.

Fault point 4: OSPFFault

Fault description: When "display OSPF peer" is used on SW1 to view OSPF neighbors, no sw2 is found

Fault analysis:

1) Whether to Use OSPF Verification

2) use the direct connection interface to declare

3) whether to declare the interface address to the correct Region

4) check whether the MTU values of the direct connection interface are consistent and enable MTU detection of OSPF

5) whether the interface uses ACL to filter OSPF packets

6) Whether the interface is set as a silent Interface

7) Whether the router ID of OSPF conflicts

Troubleshooting:

1) in the System View of SW1 and sw2, use "display current-configuration conf OSPF" to view the OSPF configuration. It is found that OSPF verification is not enabled.

2) In the Protocol view of SW1 and sw2, use "display OSPF interface" to view the advertised OSPF interface. It is found that the interfaces VLAN 30 of SW1 and sw2 are correctly declared.

3) Use "display int VLAN-interface 30" on SW1 and sw2 to view the VLAN 30 interface configuration. No MTU detection for enabling interfaces is found, and the MTU of interfaces is the default value.

4) use "display current-configuration interface VLAN-interface 30" on SW1 and sw2 to check whether the interface calls the packet filtering firewall. If no, the interface is not manually set to a silent interface.

5) use "display OSPF brief" on SW1 and sw2 to check the OSPF router ID. It is found that the OSPF router IDs of SW1 and sw2 are 192.168.1.12, the loopback interface address must be used as the OSPF router ID of the device. The router ID conflict.

In the system view of sw2, use "OSPF 1 router-ID 192.168.20.12" to set the OSPF router-ID for sw2, in the user view of sw2, use "Reset OSPF process" to restart the OSPF Protocol process. It is found that SW1 and sw2 establish OSPF neighbor relationships through the vlan30 interface. This troubleshooting is performed.

Fault 5: GRE over IPSecFault

Fault symptom:

On rt1, the system constantly prompts the tunnel interface to be up and down for a while.

Fault analysis:

The source address of the tunnel is declared in the RIP Protocol process.

Troubleshooting:

Because rt1, rT3, and rt4 run the RIP Protocol through the GRE tunnel, after the IPSec VPN is triggered to establish a tunnel, the GRE tunnel source and destination are reachable, and routes are learned through the RIP Protocol, due to the RIP Protocol error, the source address of the tunnel is declared as a Protocol process. When the router learns the source address of the tunnel through the RIP Protocol, the load changes to load. In this case, the tunnel actively goes down, after the tunnel is down, because the default route is configured locally, the source of the tunnel interface is the local loopback address, and the target is the peer loopback interface address. It matches the default route and the tunnel port is up, after the tunnel port is up, due to the RIP Protocol declaring the tunnel port address, the RIP Protocol packet triggers the establishment of the IPSec VPN. After the establishment of the IPSec VPN tunnel, the source and target of the tunnel can be reached and the route can be learned through rip, when the source address of the Peer tunnel is learned, the load of the GRE tunnel is changed to load. As a result, rt1 and rT3 constantly prompt the tunnel to be up and down.

Use "display current-configuration conf rip" on rt1 to view the rip configuration. In the System View on rt1, enter "Rip 1" to enter the RIP Protocol view and use "undo network 192.168.255.0 ", delete the channel Source Address of the error message.

If the same operation is performed on rT3 and rt4, The rt1 GRE tunnel is normal.

Use "display Ike SA" on rt1 to check whether the IPSec VPN is established normally in the two phases. It is found that there is only a relationship with rt5 and there is no relationship with rt3.

Run the ping command on rt1 to test whether the public network interface 64.67.1.1 of rT3 can be reached. The public network interface of rt1 and rT3 cannot be reached.

On rT3, use "display IP interface brief" to view the status of the tunnel port. It is found that the physical and protocol of the GRE tunnel are down. On rT3, run the "display IP routing-table" command to view the route table, no default route is found. In the rT3 System View:

[RT3] IP route-static 0.0.0.0 0 64.67.1.2

When the default route is configured, the tunnel port is up. In this case, test the public IP address 61.67.1.1 of rt1 from rt3ping, and the network is reachable.

When "display Ike SA" is used on rT3, it is found that IPSec VPN has been successfully established in both stages.

Fault 6: NatFault

Fault symptom:

On SW1, use the gateway address 192.168.0.254 with the source VLAN 10 and the target address 61.67.1.2. Ping 100.0.0.100 on rT3.

Fault analysis:

1) whether or not Nat is performed

2) whether the NAT call ACL matches

3) whether there is a local default route

Troubleshooting:

1) when "display Nat bound" is used on rt1, it is found that easy IP is implemented on G0/0/1.

2) use "display ACL 2000" to check whether a stream is matched.

3) "display IP routing-table" is used on SW1 and no default value is found.

4) Send the default route for SW1 in the ospf protocol view of rt1

[RT1-ospf-1] default-route-advertise

Test on SW1 and Ping 61.67.1.2.

<SW1> Ping-A 192.168.0.254 61.67.1.2

When [rt1] display Nat session is used on rt1, a NAT translation entry is found.

5) use "display Nat static" on rt1 to view the static NAT configuration. If it is found that it is null, the local B flow 10.1.0.100 and the public network 64.67.1.100 must be configured for static Nat, create static Nat ing on rt1

[Rt1] Nat static 10.1.0.100 64.67.1.100, and then execute [RT1-GigabitEthernet0/0/1] Nat outbound static on the public network interface.

Troubleshooting.

Fault point 7: Route filtering faults

Fault symptom:

Use "display IP routing-Table | include rip" on rT3 to view the rip route entries in the IP route table:

192.168.111.1/32

192.168.120.1/32

Fault analysis:

The question requires that the second-level B stream cannot intercommunicate with each other, and requires filtering on rt1. Use "display current-configuration conf rip" on rt1 to view the rip configuration, if filter-policy is used, the IP address-Prefix called is filter, and "display IP-prefix filter" is used to view the prefix list:

[Rt1] display IP-prefix filter

In the prefix list, the suffix of Stream B is 19 and only 192.168.96.0 19 is matched, while Stream B on rT3 is simulated using the address of the loopback port, therefore, the B stream of/32 cannot be matched.

Troubleshooting:

Delete the filter prefix list with index 10 in the rt1 System View.

Undo IP-prefix filter index 10

Then, rewrite a prefix list with index 10 to replace the original/19 prefix list.

[Rt1] IP-prefix filter index 10 deny 192.168.96.0 19 less-equal 32

After the rip route is converged, use "display IP routing-Table | include rip" in rt5 to view the rip route entries in the IP route table of rt5, troubleshooting.

Fault 8: QoSFault

Fault symptom:

When "<rt2> display QoS policy interface" is used on rt2, it is found that the QoS policy is not applied on the interface.

Fault analysis:

You can use <rt2> display QoS policy user-defined on rt2 to view the User-Defined QoS policy. It is found that an AF bandwidth is 1.5 MB, use "[rt2] display int S0/1/0" to view the interface bandwidth. It is found that the V.35 cable uses the default 64 Kbps and the local end is the DCE end.

Troubleshooting:

On rt2, enter the S0/1/0 interface and modify the bandwidth.

[RT2-Serial0/1/0] QoS max-bandwidth 2048

Then apply the defined QoS policy to the outbound direction of the interface.

[RT2-Serial0/1/0] QoS apply policy H3C outbound

Perform the same operation on rt4.