Thanks Rainer. It turned out to be we should NOT try to use the ‘Run_Ping_Test’ from eNAS to ping an external IP from an interface. It looks eNAS doesn’t rely on it when it’s working. that’s a wrong verification method we’re told.
If we try, the issue is still there, the eNAS will put the traffic to default route, then the packet will be dropped as VLAN ID mismatch.
eNAS contains CIFS server, the interface IP is linked to the CIFS server, such as 192.168.10.50. the CIFS server doesn’t have its own gateway set (for example, 192.168.10.1). Like a Windows server, it only has its IP set, but no gateway defined. Gateway is used to forward traffic to another subnet. eNAS does have the gateway connected – it’s on the other side of 802.1Q link between eNAS and switch.
It does make sense to define a default route for local interface/subnet. the traffic flow would be:
192.168.10.50 -> 192.168.10.1 -> 192.168.20.1 (DC’s gateway) -> 192.168.20.50 (DC)
I still don’t know when it needs to start communication to outside, such as DNS, authentication/DC, what source address to be used. I believe it’s not 192.168.10.50. It’s like there is a proxy there for all interfaces to forward the traffic to default route. It’s like on 802.1Q trunk, we have vlan 10, 20, 30, 40, 50, each vlan’s gateway is resided on switch side, but we will only use vlan 30 (192.168.30.1) as the default route for every thing.
I also don’t understand your saying ‘traffic to all IP’s for that subnet 192.168.10.0 – 188.8.131.52 will be sent out through the local interface 192.168.10.50′.
192.168.10.50 is a host IP for CIFS server, it’s supposed to receive nothing but destined to 192.168.10.50. What’s the meaning of the route — 192.168.10.0/24 via 192.168.10.50