Why cannot the IP address in a GRE or MPLS packet payload be matched on an S series switch

3

For S series switches, the IP header in a GRE or MPLS packet payload is the content in the packet and cannot be matched using a basic ACL or an advanced ACL.

Other related questions:
Reasons why IP packets matching binding entries are discarded a while after S series switch generates the dynamic binding table
After the dynamic binding table on the S series switches is generated for a while, If the IP packets that match the entries in the binding table are discarded, you need to check that the binding table still exists. The dynamic binding table has the aging time. If the IP address lease is not renewed after the aging time expires, the binding table ages out. As a result, the IP packets that match entries in the expired binding table are discarded.

Can an S series switches forward a packet if both the source and destination IP addresses of the packet are multicast addresses
The S5710-C-LI or S5700SI drops packets whose source and destination IP addresses are both multicast addresses. Other switches broadcast such packets in a VLAN.

IPSG does not take effect on an S series switch. What are the possible causes
If IPSG does not take effect on an S series switch (except the S1700), possible causes include the following: 1. A binding entry is incorrect. a. A static binding table is created using the user-bind static command. If the binding entry of a valid host is not in the binding table, add the host's binding entry to the binding table. If the host's entry exists in the binding table, check whether the MAC address in the entry is the same as the host's MAC address. If the network card of the host is replaced, the MAC address in the entry may not be updated. Check whether the host's entry contains VLAN information. Only when the interface connected to this host has been added to the correct VLAN, the switch allows the packets from the host to pass. b. A dynamic binding table is generated only when DHCP snooping is enabled, the interface connected to the DHCP server is configured as a trusted interface, and then the PC obtains a new IP address. 2. IPSG is not enabled in the specified interface or VLAN view. After a binding table is generated, the IPSG function must be enabled in the interface or VLAN view using the ip source check user-bind enable command. IPSG takes effect only on the interface or VLAN where it is enabled, and IPSG check is not performed on the interfaces or VLANs with IPSG disabled. Therefore, if IPSG does not take effect on an interface or in a VLAN, the IPSG function may not be enabled on this interface or in this VLAN. 3. IPSG is enabled in the VLAN to which the uplink interface belongs. IPSG is enabled on the user-side interface, namely, the downlink interface. If IPSG is enabled on the uplink interface, the packets returned by the gateway may be discarded. As a result, user service is interrupted. Solution: Disable IPSG in the VLAN to which the uplink interface belongs. 4. DHCP snooping is disabled or a DHCP snooping trusted interface is configured on the uplink interface or in the VLAN to which the uplink interface belongs. If DHCP snooping if disabled on an interface using the dhcp snooping disable command, or if a DHCP snooping trusted interface is configured on the interface using the dhcp snooping trusted command, the IPSG function on the interface or in the VLAN to which the interface belongs does not take effect. 5. Hardware ACL resources are insufficient. The hardware ACL resources are used by IPSG and other services. If the ACL resources are insufficient, IPSG cannot take effect. For example, you can run the display dhcp static user-bind all verbose command to view the IPSG status corresponding to static binding entries. If the value of IPSG Status is ineffective, IPSG of this entry does not take effect. The possible cause is that hardware ACL resources are insufficient. 6. A QoS traffic policy conflicts with IPSG. This situation may only occur in V1R6C05. When a QoS traffic policy conflicts with IPSG, the traffic behavior in the QoS traffic policy takes effect. In this situation, you need to modify service configurations.

Reasons why users cannot obtain IP addresses after DHCP Snooping is configured on S series switch
After DHCP snooping is enabled, all interfaces on S series switches are untrusted by default. DHCP Discover packets, however, must be forwarded from a trusted interface on the switch. Therefore, you must configure the interface connected to the DHCP server as a trusted interface to ensure that users connected to the switch can obtain IP addresses.

DHCP clients on S series switch cannot detect IP address conflicts
Before a DHCP client binds an obtained IP address to a VLANIF interface, it proactively sends a gratuitous ARP packet to check for IP address conflict. The VLANIF interface does not have an IP address, so its protocol status cannot go Up. When the physical interface in the corresponding VLAN receives the gratuitous ARP packet with the conflicting IP address, it cannot send the packet to the CPU. As a result, the DHCP client cannot detect IP address conflict. To resolve this problem, configure the dhcp server ping function on the DHCP server to check for IP address conflict. When there is a large number of DHCP clients, this function requires a high cost, so you need to decide whether to use this function after thorough consideration.

If you have more questions, you can seek help from following ways:
To iKnow To Live Chat
Scroll to top