HPE 1920S inter VLAN routing only working partially

[to_at]

Hi,

I am running a HPE OfficeConnect Switch 1920S 24G 2SFP JL381A.

I got 3 custom VLAN's 101 (192.168.0.0/32), 200 (192.168.200.0/30) and 201 (192.168.201.0/30). The VLAN 1 is just a stub and not used at all. 101 is my management VLAN and contains my global default gateway address. I did enable routing and admin mode on all VLAN's.

From VLAN 101 (management VLAN) I can access all other VLAN's.

But 200 and 201 can only access each other not 101. Strange thing is that devices in e.g. VLAN 200 can ping the ip address of the switch but none of the devices in VLAN 101.

Am I missing someting? Is there a special treatment for the management VLAN?

The routing table also looks fine to me:

Network Address / Subnet Mask / Protocol / Next Hop IP Address / Next Hop Interface / Best Route

0.0.0.0 0.0.0.0 Default 192.168.0.1 VLAN- 101 Best

192.168.0.0 255.255.255.0 Local 192.168.0.2 VLAN- 101 Best

192.168.200.0 255.255.255.252 Local 192.168.200.1 VLAN- 200 Best

192.168.201.0 255.255.255.252 Local 192.168.201.1 VLAN- 201 Best

[Ivan_B]

Hi!

0.0.0.0 0.0.0.0 Default 192.168.0.1 VLAN- 101 Best
192.168.0.0 255.255.255.0 Local 192.168.0.2 VLAN- 101 Best

It seems you have a router in VLAN 101 with IP 192.168.0.1 and it's not 1920s. I think chances are your hosts in VLAN101 use that router as default gateway. Please, check that. If it is so, then your router 192.168.0.1 should know how to reach 192.168.200.0/30 and 192.168.201.0/30. Maybe you need to set in that router a static route for those subnets with next-hop 192.168.0.2 (your 1920s). Alternative solution - set static routes on each of your VLAN 101 hosts.

[to_at]

Hi!

No this is not the case. The default gateway of the machine is the switch, IP address of the switch in the current VLAN (e.g. 192.168.200.1).

If that would be the case then I would be able to ping my router with the IP address 192.168.0.1 - which is not working.

Additionally ping does not even work from within the switch diagnostics.

Regards

[Ivan_B]

I am talking about machines in vlan 101, not about your machines in vlans 200 and 201. What default gateway they have configured?

"192.168.0.0 255.255.255.0 Local 192.168.0.2 VLAN- 101 Best"
This route record means Vlan 101 IP of your switch is 192.168.0.2, not 192.168.0.1. Could you double check the IP?

"If that would be the case then I would be able to ping my router with the IP address 192.168.0.1 - which is not working."
If 192.168.0.1 router doesn't have route to vlans 200 and 201 how do you think it can return icmp reply to a host in vlan 200, for example?

"Additionally ping does not even work from within the switch diagnostics."
What exactly doesn't work from switch diagnostic? Ping to which IP?

BTW, what IP addresses did you assign to hosts in Vlan 200 and 201? With /30 I see no alternatives to 192.168.200.2 and 192.168.201.2, but let's verify that. Also, verify subnet mask you have assigned to these hosts.

If IPs and mask assigned to these hosts are correct, let's take a host in vlan200 with ip 192.168.200.2 and perform following tasks:

1. ping 192.168.200.1
2. ping 192.168.0.2 (I suppose it is Vlan 101 IP of the 1920s)

Also, please, let me know the firmware version installed in the 1920s, I need it in case if I decide to try this in my lab.

[to_at]

Hi Ivan,

I'll try to be as specific as possible. My comments are point by point to your comment.

Yes, the IP address of my switch in VLAN 101 is 192.168.0.2. The address 192.168.0.1 belongs to my internet router which has no knowledge about my other VLAN's.

Got me. You are correct, pinging my router from VLAN 200 and 201 can't work. BUT: I expected that pinging my desktop PC (vlan 101) with 192.168.0.11 which has default gateway 192.168.0.2 should work. I can successfully reach 192.168.200.2 (vlan 200) and 192.168.201.2 (vlan 201) from my desktop PC. Connected via putty, everything fine. In my opinion this means that the packages know the way - at least between those hosts.

I mean pinging in the diagnostics in the Web UI of the switch. For instance: I choose as destination my desktop PC (192.168.0.11) and as source VLAN 201 I get "destination port unreachable". But when I ping 192.168.200.2 from VLAN 101 it works as expected ~~ 2ms

You are correct with your assumption of my VLAN's 200 and 201. They host a single machine. I plan to isolate those.

The task you asked for I did already answer before, therefore I just summarize it:

1. working

2. working (and you suppose correct)

3. ping 192.168.0.11 - not working (this is my desktop PC with default GW 192.168.0.2 and this machine can putty 192.168.200.2

my switch:

HPE OfficeConnect Switch 1920S 24G 2SFP JL381A, PD.02.14, Linux 3.6.5, U-Boot 2012.10-00118 (Oct 11 2016 - 15:39:54)

I just saw that there is a newer firmware but the release notes state that the changes are not relevant to me.

I appreciate your help because I am really puzzled.

[Ivan_B · Accepted solution]

Hi @to_at !

Yeah, you are not the only one who's puzzled here, I am feeling the same, but thanks to your tests and observations seems like this puzzle slowly arranges to something more clear... 

Let's take the PC with IP 192.168.0.11 that uses 1920s as a default gateway and confirm the following:

1. You can successfully reach 192.168.200.2 (vlan 200) and 192.168.201.2 (vlan 201) from my desktop PC, it means that if you initiate a connection from your PC to those two hosts in vlans 200 and 201 everything works as expected.
2. Ping from switch UI to 192.168.0.11 using 192.168.0.2 as source IP works fine
3. Ping from switch UI to 192.168.0.11 using either 192.168.200.1 or 192.168.201.1 fails
4. Ping from 192.168.200.2 or from 192.168.200.2 to 192.168.0.2 works (it has nothing to do with 192.168.0.11, but I decided to include this to the list)
5. Ping from 192.168.200.2 or from 192.168.201.2 to 192.168.0.11 fails.

If all that points are correct, it looks like a firewall  issue on 192.168.0.11. Two facts point us to this root cause:

1. You can successfully reach hosts in VLANs 200 and 201 when initiate bi-directional connection (you mentioned PuTTY, so it must be either telnet or ssh connection to 192.168.200.2, nothing was mentioned about 192.168.201.2 though, but I guess it won't be the issue) from 192.168.0.11. So it looks like it can't be routing or uni-directional routing issue, as neither telnet nor ssh would be able to establish.
2. Ping to 192.168.0.11 from switch UI with source IP 192.168.201.1 fails with error  "destination port unreachable". This error means that 192.168.0.11 got the ICMP echo from 192.168.201.1 and replied back with this error and this packet reached 192.168.201.1. It looks like routing works fine, but the destination simply rejects those echo requests. Here is what RFC 792 says:

If, in the destination host, the IP module cannot deliver the datagram because the indicated protocol module or process port is not active, the destination host may send a destination unreachable message to the source host.

In order to completely exclude routing from the list of possible trouble-makers, I suggest you to run Wireshark (or tcpdump) on 192.168.0.11 and on 192.168.200.2 (it won't hurt if you run it on 192.168.201.2 as well) and try to ping 192.168.0.11 again. Normally packet capturing software can see packets before they got rejected by software firewall, so chances are if you ping again 192.168.0.11 from either 192.168.201.1 or 192.168.201.2 or even 192.168.200.2 in the capture running on 192.168.0.11 you will see incoming ICMP requests from those hosts and then reply from your PC - "destination unreachable (port unreachable)"

[to_at]

Hi Ivan,

I am such a fool. Thank you for pushing my head to the answer. I am checking all possible forums and suggestions for a month now. No solution found. Everything I found says my setup should work.

It is all about a stupid mistake in my firewall rules! Your point made me thinking:

>> 2. Ping from switch UI to 192.168.0.11 using 192.168.0.2 as source IP works fine

It did not work! Then I started thinking... but this must work?!?!

Thank you so much! I was really desperate. Stupid me...

[Ivan_B]

I am glad my answer was useful to you and finally you got the issue resolved!