- This topic is empty.
-
Posts
-
I have a system running ZS beta16. There are multiple VLANS on an ethernet port:
VLAN 1: 10.1.0.1/16
VLAN 2: 10.2.0.1/16
VLAN 3: 10.3.0.1/16This system is connected to a Cisco switch that is interfaced to the ZS system over a trunk port. Other ports on the switch are configured to be access ports with native VLAN membership configured on a port by port basis.
I have another device that has 2 ethernet ports, with one port in VLAN 2 and one port in VLAN 3.
eth0: 10.2.1.1
eth1: 10.3.1.1
It is configured with a default route to 10.2.0.1 via eth0/VLAN 2. Let’s call this system the “Target”Case 1:
Ping 10.3.1.1 from 10.2.2.2 (some device in VLAN 2, gateway is 10.2.0.1):
10.2.2.2 sends [Ping 10.3.1.1 Request From 10.2.2.2] to 10.2.0.1
ZS routes this request to VLAN 3
10.3.0.1 sends [Ping 10.3.1.1 Request From 10.2.2.2] to 10.3.1.1
Target receives Ping request and recognizes that it has an interface in the sender’s VLAN and responds from that interface
10.2.1.1 sends [Ping 10.3.1.1 Reply To 10.2.2.2] to 10.2.2.2
So that works fine.Case 2:
Ping from 10.1.2.2 (some device in VLAN 1, gateway is 10.1.0.1):
10.1.2.2 sends [Ping 10.3.1.1 Request From 10.1.2.2] to 10.1.0.1
ZS routes this request to VLAN 3
10.3.0.1 sends [Ping 10.3.1.1 Request From 10.1.2.2] to 10.3.1.1
Target receives Ping request, but does not have an interface in VLAN 1, so it responds via its default gateway
10.2.1.1 sends [Ping 10.3.1.1 Reply To 10.1.2.2] to 10.2.0.1
ZS should route the reply to VLAN 1, but it does not. The reply gets dropped!Why does this happen? Is it because the reply is from a source IP address in VLAN 3, but is arriving from VLAN 2? This should be allowed!
- You must be logged in to reply to this topic.