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

Known issues with R80.40 Take 102?

I've installed Take 102 and got the following issues in different environments:

- DHCP relay new services  would stop with messages in drop debug: @;98963267;[kern];[tid_26];[fw4_0];fw_log_drop_ex: Packet proto=17 0.0.0.0:68 -> 255.255.255.255:67 dropped by fwmultik_handle_no_match Reason: Drop template (inbound);

Switching to the Take 94 node and everything works again

- Traffic to Internet via gateway running all TP blades would become jittery, solved by failing over to machine still in Take 94 and uninstalling the Take so the upgraded node also goes back to Take 94. Then everything is OK again on both nodes. 

- Some traffic would apparently stop after upgrade from R80.40 base to Take 102 when upgrading machine via clean install (all routes and interfaces imported and checked, ARP entries, policy install successful and so on). Not much time to troubleshoot as highly impacting, had to switch back to other appliance still in R80.30. But did similar upgrades in the same environment (multiple clusters in the same SMS) on other clusters but with lower takes and never had an issue.

0 Kudos
1 Solution

Accepted Solutions
PhoneBoy
Admin
Admin

Believe there is a known issue under investigation with R80.40 JHF 102.
I recommend a TAC case if you you don’t have one already.

View solution in original post

0 Kudos
5 Replies
PhoneBoy
Admin
Admin

Believe there is a known issue under investigation with R80.40 JHF 102.
I recommend a TAC case if you you don’t have one already.

0 Kudos
Alex-
Advisor
Advisor

Thanks @PhoneBoy. I'll stick with 94 for now and wait for the next HF, as it's all production environments it's a bit difficult to leave the issue on for investigation.

0 Kudos
Nicolas_Vanhoek
Participant
Participant

Do we know if Tac got to the bottom of this?

I have looked at the list of fixes for R80.40 GA Take_118 , there is no reference of DHCP relay problem, or problem with t_112

0 Kudos
rdevarak
Employee
Employee

Current issue shows up in /var/log/messages as ""dst_release: dst:ffff88052d4c68c0 refcnt:-480". It is coming from Linux stack.

0 Kudos
Alex-
Advisor
Advisor

Thanks, if it's just the issue under investigation I will try anyway to replicate and make a TAC case in case it would be something else.

0 Kudos

Leaderboard

Epsum factorial non deposit quid pro quo hic escorol.

Upcoming Events

    CheckMates Events