Web and Unmanaged
1752292 Members
4821 Online
108786 Solutions
New Discussion

HP v1910 IPv4 routing

 
kooper
Occasional Advisor

HP v1910 IPv4 routing

Hi all

This is sort-of a follow-up to this question: https://community.hpe.com/t5/Web-and-Unmanaged/Yet-another-question-about-HP-VLANs/m-p/6913588#M2572

Background: I've been tasked with configuring a VLAN on a switch at our premises. The info provided to me was the following: Use VLAN 25 and IP subnet 10.10.25.10/30

So I configured the switch accordingly, marking the port where the link connects as a Trunk port, tagged with VLAN 25.

I've got another port that's a hybrid with tagged VLAN 25, and untagged VLAN 5 (private LAN), VMWare sitting on the other side of that connection with a vSwitch port group configured with VLAN 25.

Now VLAN 25 works just fine. I can ping the destination IP of 10.10.25.9/30 at the remote site perfectly.

Here's where things get tricky for me. On our side, the IP 10.10.25.10/30 has been assigned directly to the device we need to be able to communicate, in this case being a VM with a NIC assigned to it belonging to the aforementioned VLAN 25.

On the other end though, they have a device on a totally different subnet, specifcally 192.168.78.10. We need to be able to reach this device over VLAN 25, so in other words from our device 10.10.25.10/30 to 10.10.25.9/30 (remote site), then from there to their device 192.168.78.10.

I've tried all sorts of different ways to get this in place, from adding a static route on the device itself (read VM) specifying this:

route add 192.168.78.10 mask 255.255.255.255 10.10.25.9 if ETH_DEV_VLAN25

 

That doesn't seem to work. Then I tried configuring a VLAN interface on the v1910 switch instead, IP being 10.10.25.10/30. At this point, I can once again ping 10.10.25.9 just fine from my v1910 switch.

Then I tried adding a static IPv4 route on the v1910, specifically as follows:

Destination IP address: 192.168.78.10

Mask: 32 (255.255.255.255)

Next Hop: 10.10.25.9

Interface: Vlan-Intercace25

Preference: 10

 

This however does not seem to work. If I do a traceroute from the v1910 to 192.168.78.10, all hops seemingly time out. Surely I should at least see 10.10.25.9 as a next hop?

That, and if I do get this to work, I'm not entirely sure how to route from there. The 30 CIDR only leaves room for two IPs, meaning I cannot add a NIC on the VM belonging to VLAN 25. This means that I will have to somehow route this from our VLAN 5 to our VLAN 25 right? If I'm on the right track here, I'm not entirely sure how to add a route that would direct traffic hitting the switch on VLAN 5 to go to VLAN 25. My best guess is (EDIT: just to add, I tried the below already, but doesn't seem like it's a valid route - error message is that the next hop address is invalid):

Destination IP address: 192.168.78.10

Mask: 32 (255.255.255.255)

Next Hop: 10.10.25.10 (VLAN 25 IP address on my v1910)

Interface: Vlan-Intercace5

Preference: 10


Sorry for the many questions, but I'm really struggling to wrap my head around all of this.

1 REPLY 1
kooper
Occasional Advisor

Re: HP v1910 IPv4 routing

This has sort-of been resolved. Instead of assigning an IP on the switch with a VLAN Interface, I removed the VLAN interface (and the routing as a result).

Instead, I assigned the IP directly to a VM, added a route in the OS (Windows in this case), and tested that way. Using Wireshark, we could see that the traffic reaches the remote site successfully, at least 10.10.25.9/30. It does not reach 192.168.78.10, but even if we try pinging 192.168.78.10, the traffic still reaches the remote device 10.10.25.9/30.

To me, it at least proves that my routing was probably correct on the switch. The trouble came in in not being able to prove it easily.

 EDIT: Just to add, the intended connectivity between 10.10.25.10 (my side) and 192.168.78.10 (remote device) still isn't working, but I am at the very least now able to prove that the problem is at the remote site and not with my config. I suspect that it's either a routing issue between 10.10.25.9 and 192.168.78.10, or too-strict FW rules at the remote site, or both.

 

Thanks to marctxk and Mikhail Khirgiy over on serverfault.com for the assistance.