VSX Internal Comm Network Issues

[SCSupport]

Hi all,

I have some issues with building and putting some VS's into product.

We are moving physical existing firewalls to VSX.

All config is the same and the policy used on the existing firewalls is being pushed to the VS (with the relevant parts of the rulebase changed)

I have this intermittent issue I cant get my head around - I have followed every SK on this I can find too.

Once the VS is live and policy is pushed to the firewalls, no logs are being received.

The internal network is a 10.0.0.0/8 and there is a route for this.

The mgmt server and log server are on an IP address within 10.66.xx.xx 

From the firewall, I can ping and traceroute to a jump server with the IP of 10.66.something.something.

Infact I can get to everywhere within the 10.0.0.0 range APART from the the mgmt and log server.

TCPDUMP's from the wrp interface (that leads to a vswitch) shows traffic to the mgmt and log server originating on the 192.168.200.0 range (I changed it from 192.168.196.0) - this is the internal vsx comms network.

Why isnt the NAT being applied properly and the src address not the cluster?

i have looked at every SK and non of the symptoms match this issue.

I am looking to see if anyone has any obvious pointers. 

One thing that makes me uncomfortable is that these are R80.40 VSX gateways managed by R80.20 mgmt server. 

I don't know if this could cause any issues, there seems to be non reported but it makes me uncomfortable and something I am looking to get the customer to upgrade ASAP before attempting the change again. But I'd be doing this out of running out of options of what this issue is.

Without any logs, we can't get any of the other bits of traffic flows to work as we have no visibility.

Thanks all

[Sigbjorn]

Hi,

All management of virtual systems, including logging, should happen between the management server and the VSX Gateway itself. So you should debug that traffic, instead of the wrp interface on the VS. (If I understood you correctly.)

If you do a "netstat -na | grep 257" on vs0, you should see that the VSX is connected to each CMA. (If using MDS)

[SCSupport]

See my response below 🙂

thank you 

[Wolfgang]

@SCSupport 

are you running your VSX in DMI or none-DMI configuration (DMI => Dedicated Management Interface) ?

With VSX I always prefer to use a dedicated interfaces for the management connections to the SMS/MDS. 

Connections to your SMS/MDS are coming from VS0, you have to debug this way.

Wolfgang

[SCSupport]

Good morning to you both.

some good points made here which had slipped my mind at 1am

we are using DMI, so VS0 should be doing this.

A question I have then.

with the VS0 policy, when should this be pushed apart from when making a policy change to VS0?

I added the VS and changed some of the interfaces around so new wrp interfaces were being created and deleted.

is it recommended to push VS0 out when making changes to a seperate VS?

[Sigbjorn]

We hardly ever push policy to vs0.

It should not be necessary  afaik, we create new virtual systems and do interface and routing changes quite often, but never touch vs0.

Do you see any tcp/257 connections from vs0, and do the vsx itself send logs to the management?

[SCSupport]

Whats strange is that I have 2 other VS's on the same gateway that pass logs fine.

This one was passing logs, but then stopped randomly after changing a default gateway IP address.. which makes no sense when logs are passed from VS0.

So now I have 3 VS's - 2 pass logs and 1 doesn't! 

And each VS is set to send logs to the correct places as per the cluster object settings.

[Chris_Atkinson]

Can you please confirm that the latest jumbo is applied to these machines?

[NunoAlves]

Same problem here. Were you able to find the reason?

Thanks guys.

[_Val_]

@NunoAlves this post is 2 years old. Please open a new discussion if you need community assistance with your issue. Please mention the configuration details, such as the version and type of VSX deployment.