New to Log Insight, can't get network to work

[JLoganAllegianc]

I have deployed my first Log Insight appliance, and am running into issues. I am hoping this is something simple, and would appreciate any suggestions:

I provided the IP address on our 10.2.73.x/24 network with a default gateway of 10.2.1.254. This is our standard server vLAN, and is a known-good configuration. Unfortunately, I cannot ping the appliance, and cannot ping the default gateway from the appliance. I can, however, ping another machine on the 10.2.73.x vLAN (that host uses the 10.2.1.254 d.g.) by IP but not name; cannot ping either DNS server.

I am just curious, does the appliance have some shortcoming when dealing with a default gateway on a different subnet? Or is there anything else I should be looking at in troubleshooting?

[Texiwill]

Hello,

Okay, so we know the network is connected, you can ping another device on the same VLAN. Good.

Now, it sounds like a route issue more than anything. You may want to double check the route. Then I would double check the gateway device is allowing the appropriate traffic. Are you using NSX perchance? I would also look in /etc/resolv.conf on the appliance to double check the settings there are correct. It really sounds like a routing issue.

Best regards,
Edward L. Haletky
VMware Communities User Moderator, VMware vExpert 2009-2016

Author of the books 'VMWare ESX and ESXi in the Enterprise: Planning Deployment Virtualization Servers', Copyright 2011 Pearson Education. 'VMware vSphere and Virtual Infrastructure Security: Securing the Virtual Environment', Copyright 2009 Pearson Education.

Virtualization and Cloud Security Analyst: The Virtualization Practice, LLC -- vSphere Upgrade Saga -- Virtualization Security Round Table Podcast

[admin]

At the risk of sounding silly ...I think the gateway and the IP of the LI nodes should be in the same subnet.

So if your LI nodes have IP of 10.2.73.x/24 then your default gateway should be 10.2.73.254 ...no?

[JLoganAllegianc]

Thanks for the reply. We are not using NSX. I moved to the etc directory and did a tail resolve.conf, but it says no such file exists. I also did a find / -iname resolve but found no such file.

[JLoganAllegianc]

It is different, to be sure. However, it has been set up this way long before I started here. It works for all our various Windows servers and appliances in the vmware environment, including vRealize. This is the first time I have encountered an issue with this network configuration.

[Texiwill · Accepted solution]

Hello,

well let us think about this for a moment....

/24 is 255.255.255.0 which means anything in the Class C.

your gateway is OUTSIDE of that class C actually inside a Class B.

Go to one of the working systems and see if the subnet is /24 or something else.... see if there is another route in there that you do not know about. It sounds very much like a routing problem.

Best regards,

Edward L. Haletky

[JLoganAllegianc]

As mentioned, I am new with this company. I agree it makes little sense why traffic is flowing to the gateway with a C mask, but it does indeed do so. I spoke to the gentleman in charge of routing and switching, and beyond pontificating as to how this is by his design, I didn't get a clear answer. In the end, since I had tried both a class B and a class C mask, and had tried a couple different vlans, all to no avail, I blew away the appliance and redeployed the OVF. This time it deployed flawlessly, with the same 10.2.73.x address and the class C mask. Go figure.