FAQs

 

1. What is DHCP Snooping?

DHCP Snooping is a security feature that protects your network from rogue DHCP servers.

When enabled, the switch:

• Allows DHCP reply (OFFER/ACK) messages only from ports you mark as Trusted.
• Blocks DHCP replies from all other (Untrusted) ports.
• Builds a Dynamic DHCP Snooping Table that records which MAC address received which IP, on which VLAN/port, and from which DHCP server.

IGS-5225-8P4S-12V DHCP Snooping prevents an attacker on an access port from handing out fake IP addresses or wrong gateways to clients.

 

2. Example topology:

 

 

• PC (DHCP client) 
  • Connected to SW 1 port 6
• SW1 (IGS-5225-8P4S-12V, Layer 3)
  • Port 6: Access port toward PC
  • Port 8: connection toward the DHCP server
  • Port 7: connection toward the Rogue DHCP server
• DHCP server
  • IP: 192.168.10.254/24
  • DHCP pool: 192.168.10.100~.150 with default gateway 192.168.10.254
  • MAC
• Rouge DHCP server
  • IP: 192.168.10.254/24
  • DHCP pool: 192.168.10.200~.250 with default gateway 192.168.10.254
  • MAC

Goal:

• Enable DHCP Snooping on SW1 so that only replies from the legitimate DHCP server are accepted.

 

3. Enable DHCP Snooping on the IGS-5225:

　3.1 Global settings: Snooping Mod

• Log into the Web UI of SW1 (IGS-5225).
• Go to Security → DHCP Snooping → DHCP Snooping Configuration.
• On the DHCP Snooping Configuration page, set:
  • Snooping Mode = Enabled

 

 

When Snooping Mode is Enabled, the switch forwards DHCP requests from clients toward trusted ports and only allows DHCP reply packets from trusted ports. Replies from untrusted ports are blocked.

• Port Mode per interface:
  • Trusted ports: legitimate sources of DHCP replies. 

 

   

 

• • Untrusted ports: access/user ports; DHCP replies from these ports are blocked.

 

 

• Set the following ports to Trusted on SW1 (IGS-5225):
  • Port 8 – uplink toward the DHCP server.
• Leave all other ports Untrusted:
  • Port 7 (toward Rogue DHCP Server).
  • Any ports facing end-users.

This ensures:

• DHCP DISCOVER/REQUEST from clients (coming from untrusted ports) are forwarded through the switch to the trusted port and then to the DHCP server.
• Only OFFER/ACK coming back via trusted port(s) are allowed through. Any rogue server connected to an untrusted port on SW1 is blocked.

 

4. Click Apply.

 

5. Verify DHCP Snooping:

The IGS-5225 provides a Dynamic DHCP Snooping Table that shows all valid bindings learned while snooping is enabled.

• Go to Security → DHCP Snooping → Dynamic DHCP Snooping Table.

 

 

• You will see entries with:
  • MAC Address – Client MAC
  • VLAN ID – VLAN where DHCP traffic is permitted (e.g. 20)
  • Source Port – Switch port where the client is connected (e.g. port toward SW2)
  • IP Address – Assigned client IP (e.g. 172.16.20.100)
  • IP Subnet Mask – Client subnet mask
  • DHCP Server Address – IP address of the server that provided the lease

This table confirms that:

• DHCP Snooping is enabled and learning bindings correctly, and
• Clients are obtaining IP addresses only from the legitimate DHCP server.

1. What is ARP Inspection?

 

 

ARP Inspection protects your network against ARP spoofing/poisoning.

A malicious or misconfigured host can forge ARP packets to change the IP–MAC mapping in another device’s ARP cache and hijack traffic.

On the IGS-6329-8UP2S4X, ARP Inspection validates ARP requests and replies against a list of trusted IP–MAC–VLAN–port bindings and drops invalid ARP packets. 

When you use DHCP Snooping, those trusted bindings are learned automatically from DHCP exchanges. ARP Inspection then uses that same database to allow only the real owner of an IP address to send ARP traffic.

 

2. Example Topology:

 

 

 

• Switch SW1: IGS-6329-8UP2S4X
  • VLAN 1 used as client VLAN
• PC1 (legitimate client)
  • Connected to port 7 of SW1 (access, VLAN 1)
  • Uses DHCP
• PC2 (attacker or misconfigured host)
  • Connected to port 5 of SW1 (access, VLAN 1)
  • Configured with static IP
• DHCP Server
  • Connected to port 8 of SW1 (VLAN 1 or routed to VLAN 1)
  • Scope: 192.168.10.0/24, default gateway 192.168.10.254
  • SVI for VLAN 1: 192.168.10.254/24 (default gateway)
• DHCP Snooping (already configured)
  • Enabled globally on SW1
  • Port 8 is trusted (toward the DHCP server)
  • All other ports, including 5 and 7, are untrusted

- Behavior before enabling ARP Inspection:

 

　

1. PC1 sends DHCPDISCOVER and legally gets IP 192.168.10.101 from the DHCP server.

2. SW1’s Dynamic DHCP Snooping Table shows a binding:

• IP 192.168.10.101 → MAC(PC1), VLAN 1, port 7.

 

 

 

 

　

3. PC2 is manually configured with IP 192.168.10.101 on port 5.

4. When PC2 pings the gateway 192.168.10.254, it sends ARP replies claiming 192.168.10.101 with PC2’s MAC.

 

 

 

• The DHCP server’s ARP entry for 192.168.10.101 changes from PC1’s MAC to PC2’s MAC → PC2 has effectively stolen PC1’s IP.

 

 

DHCP Snooping alone doesn’t stop this, because it controls DHCP replies, not ARP.

- Behavior after enabling ARP Inspection:

 

 

 

• ARP Inspection is enabled globally and on VLAN 1; all access ports (including 5 and 7) are configured for inspection except port 8.
• SW1 now checks ARP packets against the DHCP Snooping/ARP Inspection bindings:

 

 

 

 

• PC1’s ARP packets (IP 192.168.10.101 + PC1 MAC on port 7) match the binding → permitted.

 

 

 

• PC2’s ARP packets (IP 192.168.10.101 + PC2 MAC on port 5) do not match → dropped.

 

 

• Result:
  • PC2 loses connectivity (its ARP traffic is blocked).
  • PC1 continues to reach the gateway and the DHCP server’s ARP entry for 192.168.10.101 stays mapped to PC1’s MAC.

 

3. How ARP Inspection works on IGS-6329-8UP2S4X

ARP Inspection has three main pieces:

• Global Mode – enable/disable ARP Inspection switch-wide.
• Port Mode Configuration – enable/disable ARP Inspection on individual ports. ARP Inspection is effective on a port only when Global Mode is Enabled AND the port’s Mode is Enabled.
• Check VLAN & Log Type
  • Check VLAN: if Enabled, the “Log Type” is taken from per-VLAN configuration; if Disabled, it uses per-port settings.
  • Log Type: None, Deny, Permit, All (which packets are logged).

In addition, there are two ARP Inspection tables:

• Static ARP Inspection Table – manually configured safe bindings (for devices with static IPs).
• Dynamic ARP Inspection Table – up to 1024 dynamic entries learned automatically (typically from DHCP Snooping).

In this DHCP-based lab, we rely mainly on dynamic bindings from DHCP Snooping.

What IP Source Guard does:

IP Source Guard (IPSG) is a security feature that blocks any IP traffic whose (port, VLAN, IP, MAC) does not match a trusted binding. On IGS-10020PT, these bindings come from:

1. DHCP Snooping Table (dynamic entries learned from DHCP traffic):

 

 

2. Static IP Source Guard entries that you configure manually.

 

 

 

Effectively:

• If a client got its IP via DHCP on an untrusted port → IPSG learns <port, VLAN, IP, MAC> and allows only traffic that matches this binding.
• If a client tries to spoof another host’s IP (change the source IP in packets) → packets no longer match its binding and are dropped at ingress.

This is designed to stop IP spoofing, especially when you use IP-based ACLs as your main access control method.

 

Q1. Why all hosts lose connectivity after IP Source Guard is enabled:

A. IPSG is very strict. If it does not find a valid binding, it will drop all IP packets on that port.

Common reasons everything suddenly goes down:

1. DHCP Snooping is not correctly configured

• DHCP Snooping table is empty → IPSG has no bindings → all IP packets from untrusted ports are dropped.
• If your DHCP or ARP settings are wrong, IPSG will install a default deny ACE without any valid per-host permit entries, causing complete loss of IP connectivity.

2. Clients are using static IP addresses

• IPSG can’t learn static IP addresses from DHCP.
• If you don’t create static IPSG bindings for those hosts → their IP packets are all dropped.

3. Max Dynamic Clients = 0 on the port

• On the IP Source Guard Configuration page, if a port is Enabled but “Max Dynamic Clients” is set to 0, the port will only allow traffic that matches static entries.
• All DHCP clients on that port will be blocked until you either:
  • increase Max Dynamic Clients, or
  • create matching static IP Source Guard entries.

 

Example Topology:

 

 

Topology:

• PC1 – DHCP client, gets IP 192.168.10.100/24, on Port 7.
• PC2 – DHCP client, gets IP 192.168.10.102/24, on Port 6.
• DHCP Server / default gateway – 192.168.10.254/24, pool 192.168.10.100–192.168.10.150, connected to Port 8
• All in VLAN 1(for example).

Pre-configured:

• DHCP Snooping: enabled globally, all ports untrusted except Port 8 (DHCP server).
• ARP Inspection: enabled globally, all ports untrusted except Port 8.

Access list:

 

 

This ACL means:

• ICMP to 192.168.10.254 is denied by default (ACE 2),
• except from 192.168.10.100 (PC1), which is permitted by ACE 1.

Test connectivity

• PC1 ping 192.168.10.254: should succeed (allowed by ACE 1).
• PC2 ping 192.168.10.254: should be blocked by ACE 2 (no ACL permit for 192.168.10.102).

 

 

Bypass IP-based ACL by spoofing PC1’s IP:

A. Let’s look at what happened before IPSG was enabled:

• ACL logic:
  • ACE 1: allow ICMP from 192.168.10.100 to gateway .254
  • ACE 2: deny all other ICMP to .254
• During the test:

1. Normal behavior (no spoofing):

• PC1 (192.168.10.103) → ping .254 → ACE 1 matches, allowed → counter of ACE 1 = 5 (for 5 pings).
• PC2 (192.168.10.105) → ping .254 → ACE 1 does not match, ACE 2 matches → counter of ACE 2 = 5, all packets denied.

2. Spoofing with Scapy on PC2:

• PC2 crafts ping with source IP set to 192.168.10.100.

        

 

• Switch sees a packet with:
  • Source IP = 192.168.10.100.
  • Destination IP = 192.168.10.254.
• ACL has no knowledge of which physical port the packet came from. It just sees IP addresses.
• So the packet matches ACE 1, is permitted, and reaches the gateway.

　　　→ ACE 1 counter increases from 5 to 10 (5 from PC1 + 5 from spoofed PC2 pings).

 

 

Result: PC2 successfully pretended to be PC1 and bypassed your IP-based ACL. ACL alone cannot stop this; it does not verify that the IP belongs to the MAC/port that originally got it.

 

Enable IP Source Guard and block spoofed ping from PC2:

1. Verify DHCP Snooping and ARP Inspection are working

• Confirm that both PC1 and PC2 obtain DHCP addresses normally.
• Check the DHCP Snooping table – you should see:
  • Port 7 → IP 192.168.10.100, MAC of PC1
  • Port 6 → IP 192.168.10.102, MAC of PC2

 

 

• Check Dynamic ARP Inspection table; it should be consistent with DHCP snooping.

 

 

2. Enable Global IP Source Guard

• Set Global Mode: Enable.

3. Enable IP Source Guard on the client ports

• Still in IP Source Guard Configuration:
  • Port 6 (PC2): Mode: Enable, Max Dynamic Clients: 1.
  • Port 7 (PC1): Mode: Enable, Max Dynamic Clients: 1.
  • Port 8 (DHCP server / router): usually disabled for IPSG (it’s a trusted uplink, not an end host).
• Apply and save.

 

 

4. Verify the Dynamic IP Source Guard Table

• You should see entries similar to below:
  • Port 7, VLAN 1, IP 192.168.10.100, MAC = PC1 MAC
  • Port 6, VLAN 1, IP 192.168.10.102, MAC = PC2 MAC

 

 

Now IPSG is correctly configured and does not break normal communication, but it will stop IP spoofing attempts.

Once IPSG is enabled and DHCP Snooping has built the bindings, the switch automatically creates hidden ACEs that look like:

• ipSourceGuard ACE 11 permit source IP 192.168.10.102 (for PC2)
• ipSourceGuard ACE 14 permit source IP 192.168.10.100 (for PC1)
• ipSourceGuard ACE 1 deny all (default deny)

 

 

The important part is that these permit ACEs are tied to specific ports and MACs, not just IP.

Now consider spoofing test again:

1. PC2 (on Port 5) sends packets with:

• Source IP = 192.168.10.100
• Source MAC = PC2’s MAC (different from PC1’s MAC)
• Port = 5

 

 

2. IP Source Guard checks:

• Does Port 5 have a binding for IP 192.168.10.100 and PC2’s MAC?

        → No, Port 5 is bound to IP 192.168.10.102.

3. So the packet matches ipSourceGuard ACE 1 deny all.

• Observation: counter for ipSourceGuard ACE 1 increased to 5.

    

 

• Packets are dropped before they even reach the user ACL.

 

 

Result: IP Source Guard prevents PC2 from using PC1’s IP, even though your IP-based ACL would otherwise have allowed those packets.

  

Q2. Does IP Source Guard replace DHCP Snooping, ARP Inspection, or ACLs?

A. No – they work together:

• DHCP Snooping – builds the trusted IP–MAC–VLAN–port bindings.
• IP Source Guard – uses those bindings to block IP spoofing at Layer 3.
• ARP Inspection – uses the same bindings to block ARP spoofing at Layer 2.
• ACLs – implement your actual policy (“who can talk to what”), but are vulnerable to spoofing if used alone.

A good rule of thumb for access networks:

DHCP Snooping + ARP Inspection + IP Source Guard + IP-based ACLs gives you both strong identity (per IP/MAC/port) and flexible policy control.

Please follow the steps below to enable the SSH function on the switch.

1.　Go to Security → Access Security → Authentication Method. 

     

 

2.　Set the Authentication Method for SSH to“local”, then click the “Apply” button. 

    

 

3.　Go to Security →  Access Security → SSH. 

　　Set the SSH function to“Enabled”, then click the “Apply” button. 

　　

 

4.　Save the configuration to apply the changes permanently. 

　　 

　　After completing the above steps, the user will be able to access the switch via SSH.

Topology:

The fiber ports are used for ERPS Ring, where VLANs 1 to 3 and 3001 pass through the fiber ports. 

 

To achieve the goal, please refer to the steps below:

l   Switch 1:

1. Go to the ERPS page and establish the ERPS ring using the Ring Wizard.

2. Click on the “ERPS” and go to the “ERPS ID”.

 

 3. Go to the VLAN Configuration page. 

4. Click the “Add New Entry” button to add VLANs 2 and 3.

 

5. Go to the Global VLAN Configuration page using the path: Switching → VLAN Port Configuration.

    Add multiple VLANs to the ports of the ERPS ring (ports 9 and 10).

6. Go to the IP Configuration page using the path: System → IP Configuration.

     Assign the IP addresses to the VLAN 2 and 3 interfaces. 

l   Repeat the steps above on Switches 2 and 3. 

    Thus, VLANs 1-3 and 3001 can pass through the fiber ports.

Please refer to the attached calculation to select your PV panel and battery for more understandings, thank you.

PLANET BSP-360 Industrial-grade Renewable Energy PoE+ Managed Switch (BSP-360), built with advanced green technology,

can be charged by renewable energy,making it perfect for remote applications in remote expansive environments such as dams,

national parks, highways and others.

The BSP-360 effectively transfers green energy to PoE power in order to provide electricity to PDs including IP cameras and access

points deployed in the network.

Please refer to the standard application graph with the green power and battery.

Please refer to the standard application graph with the green power, battery,PoE PDs and NMS-360 series.

If there is no green power generator, please refer to this application graph with the PoE PDs and NMS-360 series.

※ The 24V DC power supply must connect to battery DC input terminal block.

NOTE:

1. Please remember to configure all equipment using a different IP address and must in the same subnet.

2. The BSP-360 default IP is 192.168.0.100.

3. The NMS-360 default IP is 192.168.1.100 (https:// 192.168.1.100:8888).