A certain site MSR3620-X DHCP relay fails to obtain an address

2025-11-18 14:47:00 Published
  • 0 Followed
  • 0Collected ,10Browsed

Network Topology

MSR3620-X-----HW switch-----terminal

 

The on-site MSR router acts as a DHCP server, performing DHCP static binding of IP+MAC to assign specified IP addresses to terminals with designated MAC addresses. The HW switch serves as the aggregation gateway for xx.xx.16.1 and is configured with DHCP relay.

Problem Description

The terminal cannot automatically obtain the DHCP statically bound address via DHCP. Test terminal IP address: xx.xx.16.41. It fails to obtain an address automatically but works normally when manually set to xx.xx.16.41.

 

Feedback indicates it worked two days ago but is now unavailable.

 

HW switch configuration:


Process Analysis

Manually configuring the same address allows normal internet access, indicating that network connectivity is functioning properly. Request on-site personnel to collect debugging dhcp server all information on the MSR, which shows No matching network for the client.

The field terminal belongs to the xx.xx.16.1 subnet. Debug information shows that the relay device address is in the xx.xx.14.1 subnet. On the relay HW switch, the subnet masks for both xx.xx.16.1 and xx.xx.14.1 are 23. These two subnets are not in the same network segment, so a no matching network prompt appears. The VLAN IF interface on the relay HW switch is configured with primary and secondary addresses. Communication with the xx.xx.14.1 gateway cannot be relayed due to subnet mismatch, while communication with the xx.xx.16.1 gateway can be relayed to the address.


Solution

Acknowledged on-site that the xx.xx.14.1 subnet does not require relay configuration. Modified the primary and secondary addresses, with the xx.xx.16.1 subnet as the primary address for the VLAN IF interface and the xx.xx.14.1 subnet as the secondary address for the VLAN IF interface. After the changes, both subnets were tested without issues. The xx.xx.16.1 subnet can relay normally, and the xx.xx.14.1 subnet operates correctly.

Please rate this case:   
0 Comments

No Comments

Add Comments: