Create a Post
cancel
Showing results for 
Search instead for 
Did you mean: 
Alex-
Advisor
Advisor

Issue with 12000, VSX, VSWITCH & R80.30

I will open a case for this but I wonder if someone has seen this already.

I upgraded a 12600 VSX cluster from R80.20 Take 47 to R80.30. All went well but there was a strange issue afterwards.

Two VS talk to each other via a "front" VSWITCH used for inter-VS communication. These VS also have "back" VSWITCH for the networks which are located behind them. I'd rather use tagged interfaces but it's another story and there's a reason why they're present.

After upgrade to Take 19, some traffic never makes it through a backend LAN on VS-A to the backend of VS-B. 

In Smart Console, the traffic is seen as accepted. With fw monitor, the traffic is seen but stays in the "i" part on VS-B.

The weird thing is that only specific protocols didn't go through, for the other ones we could see the full "iI-oO" and they worked normally. Failing protocols were RDP & HTTPS, but maybe there were others (no HTTPS inspection blade runs on any of the VS, and this is internal traffic only).

Now the interesting bit: uninstalling Take 19 actually solves the issue. We tried with the second cluster member which exhibited the exact same behaviour: OK with R80.30.0, fails with R80.30.19.

We're now in full production on both systems with R80.30 and no Take. I guess I will need to replicate issue with TAC but it's challenging as we need to install the Take on a production system and take live traces which isn't always easy to arrange, so I thought I'd check if anyone here would have seen that kind of behavior and had an idea.

The chassis themselves are all OK in terms of CPU, RAM, I/O and so on so I think it's really a software issue.

0 Kudos
5 Replies
This widget could not be displayed.

Leaderboard

Epsum factorial non deposit quid pro quo hic escorol.

Upcoming Events

    CheckMates Events