Create a Post
cancel
Showing results for 
Search instead for 
Did you mean: 
SCSupport
Contributor

VSX Internal Comm Network Issues

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

0 Kudos
7 Replies
Sigbjorn
Advisor

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)

0 Kudos
SCSupport
Contributor

See my response below 🙂

 

thank you 

0 Kudos
Wolfgang
Leader
Leader

@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
Contributor

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?

0 Kudos
Sigbjorn
Advisor

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?

0 Kudos
SCSupport
Contributor

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.

0 Kudos
Chris_Atkinson
Employee
Employee

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

0 Kudos