This discussion has been locked.

You can no longer post new replies to this discussion. If you have a question you can start a new discussion

SD RED 60 Traffic issue

Christopher Rettig over 4 years ago

Before the traffic issue the RED SD 60 was disconnects severla times the morning, only a power off solves this issue

I got a customer with a issue depending thr traffic and connection.

He uses a RED SD 60 and XG Firewall

Typ: XG230

SFOS 18.0.4 MR-4

RED is running on 3.0.004 As an example over the weekend the customer only had 100 KB traffic available through the red, no more...this is really bad performance.

Any ideas? We already replaced the RED device two times through Sophos Support bit it did not changed the isse...Only pull off the power helpf solving this issue temporerarily

Kind Regards

Christopher

This thread was automatically locked due to age.

Parents

0 FormerMember over 4 years ago

Hi Christopher Rettig,

Thank you for reaching out to the Community!

Could you please provide the support case numbers by sending a private message?

Did this issue start after the firmware update on your firewall?

Please share the red logs from your firewall around the time frame the issue occurred.

Thanks,
Cancel
Vote Up 0 Vote Down

Cancel
0 Christopher Rettig over 4 years ago in reply to FormerMember

Hi,

the device hangs several times a day, sometimes only in the monring.

Here are some log excerpts from 23rd february where a disconnect happened at 03:16pm

red.log

+++

Reading REDv2 key from STDIN:
Tue Feb 23 15:15:56 2021 REDD INFO: Red devices: Connected: 14 Disconnected 2 Enabled: 16 Disabled: 0
Reading REDv2 key from STDIN:
Tue Feb 23 15:20:57 2021 REDD INFO: Red devices: Connected: 13 Disconnected 3 Enabled: 16 Disabled: 0
Tue Feb 23 15:22:47 2021 REDD ERROR: server: Can not do SSL handshake on Socket accept from '62.216.204.46': SSL accept attempt failed because of handshake problems
Tue Feb 23 15:22:49 2021 REDD INFO: server: New connection from 62.216.204.46 with ID R60001W24MH67C3 (cipher ECDHE-RSA-AES256-GCM-SHA384), rev1

+++

syslog.log

+++

Feb 23 15:16:23 (none) user.warn kernel: [3396671.669614] skbuff: IMQ: kfree_skb: skb->nf_queue_entry != NULL
Feb 23 15:16:24 (none) user.warn kernel: [3396672.690743] skbuff: IMQ: kfree_skb: skb->nf_queue_entry != NULL
Feb 23 15:16:25 (none) user.warn kernel: [3396673.714730] skbuff: IMQ: kfree_skb: skb->nf_queue_entry != NULL
Feb 23 15:16:26 (none) user.err kernel: [3396674.738685] mm_skb_destructor: it should be called only in case of skb purging on arp failure
Feb 23 15:16:26 (none) user.err kernel: [3396674.738697] mm_skb_destructor: it should be called only in case of skb purging on arp failure
Feb 23 15:16:26 (none) user.err kernel: [3396674.738704] mm_skb_destructor: it should be called only in case of skb purging on arp failure
Feb 23 15:16:30 (none) user.warn kernel: [3396678.704051] skbuff: IMQ: kfree_skb: skb->nf_queue_entry != NULL
Feb 23 15:16:31 (none) user.warn kernel: [3396679.734738] skbuff: IMQ: kfree_skb: skb->nf_queue_entry != NULL
Feb 23 15:16:32 (none) user.warn kernel: [3396680.754763] skbuff: IMQ: kfree_skb: skb->nf_queue_entry != NULL
Feb 23 15:16:33 (none) user.err kernel: [3396681.778697] mm_skb_destructor: it should be called only in case of skb purging on arp failure
Feb 23 15:16:38 (none) user.warn kernel: [3396686.707907] skbuff: IMQ: kfree_skb: skb->nf_queue_entry != NULL
Feb 23 15:16:39 (none) user.warn kernel: [3396687.730761] skbuff: IMQ: kfree_skb: skb->nf_queue_entry != NULL
Feb 23 15:16:40 (none) user.warn kernel: [3396688.758799] skbuff: IMQ: kfree_skb: skb->nf_queue_entry != NULL
Feb 23 15:16:41 (none) user.err kernel: [3396689.778723] mm_skb_destructor: it should be called only in case of skb purging on arp failure
Feb 23 15:16:48 (none) user.warn kernel: [3396697.385791] red_rx_crypto: 25 callbacks suppressed
Feb 23 15:16:48 (none) user.err kernel: [3396697.385791] RX: decryption failed
Feb 23 15:16:48 (none) user.err kernel: [3396697.385793] reds9: red_rx_done: Decryption failed
Feb 23 15:16:49 (none) user.info kernel: [3396698.142717] reds16: auto-removing peer 62.216.204.46:45364
Feb 23 15:16:50 (none) user.warn kernel: [3396698.994704] red_tx_skb: 9 callbacks suppressed
Feb 23 15:16:50 (none) user.err kernel: [3396698.994705] no peer (tx)
Feb 23 15:16:50 (none) user.err kernel: [3396698.994706] no peer (tx)
Feb 23 15:16:50 (none) user.err kernel: [3396699.058706] no peer (tx)
Feb 23 15:16:50 (none) user.err kernel: [3396699.058711] no peer (tx)
Feb 23 15:16:50 (none) user.err kernel: [3396699.058714] no peer (tx)

++++

The hanging state at this time took round about six minutes, if i check the syslog.lol at 03:22 (six minutes later) i can see the following:

+++

Feb 23 15:22:47 (none) user.err kernel: [3397055.959199] mm_skb_destructor: it should be called only in case of skb purging on arp failure
Feb 23 15:22:47 (none) user.err kernel: [3397056.105508] no peer (tx)
Feb 23 15:22:51 (none) user.warn kernel: [3397060.211184] red_tx_skb: 116 callbacks suppressed
Feb 23 15:22:51 (none) user.err kernel: [3397060.211185] no peer (tx)
Feb 23 15:22:51 (none) user.err kernel: [3397060.211189] no peer (tx)
Feb 23 15:22:51 (none) user.err kernel: [3397060.211193] no peer (tx)
Feb 23 15:22:51 (none) user.err kernel: [3397060.211197] no peer (tx)
Feb 23 15:22:51 (none) user.err kernel: [3397060.211201] no peer (tx)
Feb 23 15:22:51 (none) user.err kernel: [3397060.211204] no peer (tx)
Feb 23 15:22:51 (none) user.err kernel: [3397060.211208] no peer (tx)
Feb 23 15:22:51 (none) user.err kernel: [3397060.211211] no peer (tx)
Feb 23 15:22:51 (none) user.err kernel: [3397060.211215] no peer (tx)
Feb 23 15:22:52 (none) user.warn kernel: [3397060.894044] skbuff: IMQ: kfree_skb: skb->nf_queue_entry != NULL
Feb 23 15:22:52 (none) user.err kernel: [3397060.909566] no peer (tx)
Feb 23 15:22:53 (none) user.warn kernel: [3397061.907237] skbuff: IMQ: kfree_skb: skb->nf_queue_entry != NULL
Feb 23 15:22:54 (none) user.warn kernel: [3397062.935214] skbuff: IMQ: kfree_skb: skb->nf_queue_entry != NULL
Feb 23 15:22:55 (none) user.err kernel: [3397063.955196] mm_skb_destructor: it should be called only in case of skb purging on arp failure
Feb 23 15:22:55 (none) user.err kernel: [3397064.346764] RX: decryption failed
Feb 23 15:22:55 (none) user.err kernel: [3397064.346766] reds16: red_rx_done: Decryption failed
Feb 23 15:22:56 (none) user.info kernel: [3397064.857950] Autoadd peer 0
Feb 23 15:22:56 (none) user.info kernel: [3397064.857954] reds16: Auto-adding peer 0 (from 62.216.204.46:45397 to 62.204.174.121:3410)
Feb 23 15:24:34 (none) user.warn kernel: [3397163.329240] skbuff: IMQ: kfree_skb: skb->nf_queue_entry != NULL
Feb 23 15:24:35 (none) user.warn kernel: [3397164.339400] skbuff: IMQ: kfree_skb: skb->nf_queue_entry != NULL

+++

I asked the customer/partner if there has been a firmeare upgrade, but i dont think so.

Kind regards

Christopher
Cancel
Vote Up 0 Vote Down

Cancel

Reply

0 Christopher Rettig over 4 years ago in reply to FormerMember

Hi,

the device hangs several times a day, sometimes only in the monring.

Here are some log excerpts from 23rd february where a disconnect happened at 03:16pm

red.log

+++

Reading REDv2 key from STDIN:
Tue Feb 23 15:15:56 2021 REDD INFO: Red devices: Connected: 14 Disconnected 2 Enabled: 16 Disabled: 0
Reading REDv2 key from STDIN:
Tue Feb 23 15:20:57 2021 REDD INFO: Red devices: Connected: 13 Disconnected 3 Enabled: 16 Disabled: 0
Tue Feb 23 15:22:47 2021 REDD ERROR: server: Can not do SSL handshake on Socket accept from '62.216.204.46': SSL accept attempt failed because of handshake problems
Tue Feb 23 15:22:49 2021 REDD INFO: server: New connection from 62.216.204.46 with ID R60001W24MH67C3 (cipher ECDHE-RSA-AES256-GCM-SHA384), rev1

+++

syslog.log

+++

Feb 23 15:16:23 (none) user.warn kernel: [3396671.669614] skbuff: IMQ: kfree_skb: skb->nf_queue_entry != NULL
Feb 23 15:16:24 (none) user.warn kernel: [3396672.690743] skbuff: IMQ: kfree_skb: skb->nf_queue_entry != NULL
Feb 23 15:16:25 (none) user.warn kernel: [3396673.714730] skbuff: IMQ: kfree_skb: skb->nf_queue_entry != NULL
Feb 23 15:16:26 (none) user.err kernel: [3396674.738685] mm_skb_destructor: it should be called only in case of skb purging on arp failure
Feb 23 15:16:26 (none) user.err kernel: [3396674.738697] mm_skb_destructor: it should be called only in case of skb purging on arp failure
Feb 23 15:16:26 (none) user.err kernel: [3396674.738704] mm_skb_destructor: it should be called only in case of skb purging on arp failure
Feb 23 15:16:30 (none) user.warn kernel: [3396678.704051] skbuff: IMQ: kfree_skb: skb->nf_queue_entry != NULL
Feb 23 15:16:31 (none) user.warn kernel: [3396679.734738] skbuff: IMQ: kfree_skb: skb->nf_queue_entry != NULL
Feb 23 15:16:32 (none) user.warn kernel: [3396680.754763] skbuff: IMQ: kfree_skb: skb->nf_queue_entry != NULL
Feb 23 15:16:33 (none) user.err kernel: [3396681.778697] mm_skb_destructor: it should be called only in case of skb purging on arp failure
Feb 23 15:16:38 (none) user.warn kernel: [3396686.707907] skbuff: IMQ: kfree_skb: skb->nf_queue_entry != NULL
Feb 23 15:16:39 (none) user.warn kernel: [3396687.730761] skbuff: IMQ: kfree_skb: skb->nf_queue_entry != NULL
Feb 23 15:16:40 (none) user.warn kernel: [3396688.758799] skbuff: IMQ: kfree_skb: skb->nf_queue_entry != NULL
Feb 23 15:16:41 (none) user.err kernel: [3396689.778723] mm_skb_destructor: it should be called only in case of skb purging on arp failure
Feb 23 15:16:48 (none) user.warn kernel: [3396697.385791] red_rx_crypto: 25 callbacks suppressed
Feb 23 15:16:48 (none) user.err kernel: [3396697.385791] RX: decryption failed
Feb 23 15:16:48 (none) user.err kernel: [3396697.385793] reds9: red_rx_done: Decryption failed
Feb 23 15:16:49 (none) user.info kernel: [3396698.142717] reds16: auto-removing peer 62.216.204.46:45364
Feb 23 15:16:50 (none) user.warn kernel: [3396698.994704] red_tx_skb: 9 callbacks suppressed
Feb 23 15:16:50 (none) user.err kernel: [3396698.994705] no peer (tx)
Feb 23 15:16:50 (none) user.err kernel: [3396698.994706] no peer (tx)
Feb 23 15:16:50 (none) user.err kernel: [3396699.058706] no peer (tx)
Feb 23 15:16:50 (none) user.err kernel: [3396699.058711] no peer (tx)
Feb 23 15:16:50 (none) user.err kernel: [3396699.058714] no peer (tx)

++++

The hanging state at this time took round about six minutes, if i check the syslog.lol at 03:22 (six minutes later) i can see the following:

+++

Feb 23 15:22:47 (none) user.err kernel: [3397055.959199] mm_skb_destructor: it should be called only in case of skb purging on arp failure
Feb 23 15:22:47 (none) user.err kernel: [3397056.105508] no peer (tx)
Feb 23 15:22:51 (none) user.warn kernel: [3397060.211184] red_tx_skb: 116 callbacks suppressed
Feb 23 15:22:51 (none) user.err kernel: [3397060.211185] no peer (tx)
Feb 23 15:22:51 (none) user.err kernel: [3397060.211189] no peer (tx)
Feb 23 15:22:51 (none) user.err kernel: [3397060.211193] no peer (tx)
Feb 23 15:22:51 (none) user.err kernel: [3397060.211197] no peer (tx)
Feb 23 15:22:51 (none) user.err kernel: [3397060.211201] no peer (tx)
Feb 23 15:22:51 (none) user.err kernel: [3397060.211204] no peer (tx)
Feb 23 15:22:51 (none) user.err kernel: [3397060.211208] no peer (tx)
Feb 23 15:22:51 (none) user.err kernel: [3397060.211211] no peer (tx)
Feb 23 15:22:51 (none) user.err kernel: [3397060.211215] no peer (tx)
Feb 23 15:22:52 (none) user.warn kernel: [3397060.894044] skbuff: IMQ: kfree_skb: skb->nf_queue_entry != NULL
Feb 23 15:22:52 (none) user.err kernel: [3397060.909566] no peer (tx)
Feb 23 15:22:53 (none) user.warn kernel: [3397061.907237] skbuff: IMQ: kfree_skb: skb->nf_queue_entry != NULL
Feb 23 15:22:54 (none) user.warn kernel: [3397062.935214] skbuff: IMQ: kfree_skb: skb->nf_queue_entry != NULL
Feb 23 15:22:55 (none) user.err kernel: [3397063.955196] mm_skb_destructor: it should be called only in case of skb purging on arp failure
Feb 23 15:22:55 (none) user.err kernel: [3397064.346764] RX: decryption failed
Feb 23 15:22:55 (none) user.err kernel: [3397064.346766] reds16: red_rx_done: Decryption failed
Feb 23 15:22:56 (none) user.info kernel: [3397064.857950] Autoadd peer 0
Feb 23 15:22:56 (none) user.info kernel: [3397064.857954] reds16: Auto-adding peer 0 (from 62.216.204.46:45397 to 62.204.174.121:3410)
Feb 23 15:24:34 (none) user.warn kernel: [3397163.329240] skbuff: IMQ: kfree_skb: skb->nf_queue_entry != NULL
Feb 23 15:24:35 (none) user.warn kernel: [3397164.339400] skbuff: IMQ: kfree_skb: skb->nf_queue_entry != NULL

+++

I asked the customer/partner if there has been a firmeare upgrade, but i dont think so.

Kind regards

Christopher
Cancel
Vote Up 0 Vote Down

Cancel

Children

0 Christopher Rettig over 4 years ago in reply to Christopher Rettig

Case numbers has been sent via private message
Cancel
Vote Up 0 Vote Down

Cancel
0 FormerMember over 4 years ago in reply to Christopher Rettig

Hi Christopher Rettig,

Thank you for the update.

I've added an internal note on your current support case, and your case has been escalated to the escalation team.

Thanks,
Cancel
Vote Up 0 Vote Down

Cancel