HTA-OSPF-01: Network Reachability Issue

Scenario

You just received the following email from your colleague and are asked to help him troubleshoot and resolve the issue.

Hi,

I hope you’re doing well.

I wanted to bring a network connectivity issue to your attention that I’ve been investigating this morning. We’re currently experiencing intermittent connectivity problems affecting several internal services and user endpoints.

From my initial checks, it looks like the issue may be related to unstable routing between the routers, but I haven’t been able to pinpoint the exact cause yet. I’ve already verified physical links and basic configurations, and everything appears normal on the surface. The following ping no longer works, but it was working last week.

<R1>ping -a 1.1.1.1 3.3.3.3
PING 3.3.3.3: 56 data bytes, press CTRL_C to break
Request time out
Request time out
Request time out
Request time out
Request time out

--- 3.3.3.3 ping statistics ---
5 packet(s) transmitted
0 packet(s) received
100.00% packet loss

Could you please take a closer look when you have a moment? Your expertise on this would be really helpful to identify and resolve the root cause as quickly as possible.

Thanks in advance for your support!

Best regards,
Alex Carter
Junior Network Engineer

He's also provided you with a layout, various configuration templates, and different troubleshooting information.

Topology

Huawei Troubleshooting HTA-OSPF-01

Configurations

# sysname R1# snmp-agent local-engineid 800007DB03000000000000 snmp-agent # clock timezone China-Standard-Time minus 08:00:00#portal local-server load portalpage.zip# drop illegal-mac alarm# set cpu-usage threshold 80 restore 75#aaa  authentication-scheme default authorization-scheme default accounting-scheme default domain default  domain default_admin  local-user admin password cipher %$%$K8m.Nt84DZ}e#<0`8bmE3Uw}%$%$ local-user admin service-type http#firewall zone Local priority 15#interface GigabitEthernet0/0/0 ip address 10.0.12.1 255.255.255.0 #interface GigabitEthernet0/0/1#interface GigabitEthernet0/0/2#interface NULL0#interface LoopBack0 ip address 1.1.1.1 255.255.255.255 #ospf 1  silent-interface all area 0.0.0.0   network 1.1.1.1 0.0.0.0   network 10.0.12.0 0.0.0.255 #user-interface con 0 authentication-mode password idle-timeout 30000 0user-interface vty 0 4user-interface vty 16 20#wlan ac#
52 lines

Additional Information

<R1>ping 10.0.12.2  PING 10.0.12.2: 56  data bytes, press CTRL_C to break    Reply from 10.0.12.2: bytes=56 Sequence=1 ttl=255 time=80 ms    Reply from 10.0.12.2: bytes=56 Sequence=2 ttl=255 time=10 ms    Reply from 10.0.12.2: bytes=56 Sequence=3 ttl=255 time=20 ms    Reply from 10.0.12.2: bytes=56 Sequence=4 ttl=255 time=20 ms    Reply from 10.0.12.2: bytes=56 Sequence=5 ttl=255 time=20 ms  --- 10.0.12.2 ping statistics ---    5 packet(s) transmitted    5 packet(s) received    0.00% packet loss    round-trip min/avg/max = 10/30/80 ms<R1>
15 lines

Wireshark Captures

No Wireshark captures were provided.

View Expert Analysis

Based on the configurations and additional information, we can see the following:

  • All IP addresses are configured correctly according to the layout - there are no typos.
  • Router R3 has the OSPF routes from R2; there is a successful OSPF adjacency here.
  • Router R1 can ping R2 - there is most likely no physical problem.
  • It appears that there is no OSPF adjacency between R1 and R2. We would see this by running the display ospf peer command on R1 or R2.

Since we don't have direct access to the devices, let's take another look at the configuration templates for R1 and R2. We see that the MTU size is the same on both sides (if nothing is displayed, then it is the default value of 1500). The OSPF network type is also the same, which is Broadcast for an Ethernet interface. As previously verified, the IP addresses and, most importantly, the subnet masks are correct. Thus, the interface configurations appear to be correct.

However, if we now look at the OSPF configuration, we see that the silent-interface all command is configured on R1. As a result, by default, the router does not send OSPF hello packets on any interface and therefore does not establish OSPF adjacencies. It appears that the network engineer attempted to enable this security feature but configured it incorrectly or incompletely.

We can now either delete the command or, better yet, enable the G0/0/0 interface using the command undo silent-interface GigabitEthernet0/0/0. As soon as this command is configured on R1, the OSPF adjacency will come up immediately.

 

Newsletter

Get information about new guides, courses, and training updates directly via email.

Main Menu Offcanvas (de)