cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
2403
Views
45
Helpful
4
Replies

ESA: SBRS stopped working ("SBRS None" for all senders)

HSmith82556
Level 1
Level 1

Dear experts,

 

on our cluster of two ESA

(C100V - 11.1.0-131)

SBRS stopped working suddenly (March 1st ~20:35 UTC+1)

Since then, all incoming connections show 

"SBRS None country None" and are not filtered by senderbase reputation.

 

Some debug output:

senderbasestatus

SenderBase Host Status
Status as of:                    Wed Mar 02 15:07:28 2022 CET
Host success/fail:               success

SBRS Status
Status as of:                    Wed Mar 02 15:07:28 2022 CET
Host success/fail:               success

SenderBase Network Participation Status
Time of last SenderBase upload:  never
repengstatus

  Component                   Last Update                     Version
  Reputation Engine           Never updated                   1.2.0-079
  Reputation Engine Tools     Never updated                   1.2.0-079


After

repengupdate force:

repengstatus

  Component                   Last Update                     Version
  Reputation Engine           02 Mar 2022 13:23 (GMT +00:00)  1.2.0-079
  Reputation Engine Tools     02 Mar 2022 13:23 (GMT +00:00)  1.2.0-079

Also restarted the service via

DIAGNOSTIC
SERVICES
SBRS
RESTART

status of service is now:

[]> sbrs


Choose the operation you want to perform:
- RESTART - Restart the service
- STATUS - View status of the service
[]> status

Reputation Engine has been up for 2h 17m 56s.

What else could I try to debug or revive SBRS?

Thank you very much.

 

1 Accepted Solution

Accepted Solutions

HSmith82556
Level 1
Level 1

Replying to self as problem was solved with help of TAC.

It was a DNS problem. Resolving 'senderbase.org' worked. But the special queries that are generated to check incoming connections suddenly stopped being handled by our ISPs DNS.

They are TXT-queries, asking for

1-12341234123412341234123412341234.200.200.200.200.v1x2s.rf-xyzxyzxyz.senderbase.org

("200.200.200.200" would be the IP of the server trying to send mails.

"1234..." and "xyz..." are some random looking numbers which I don't now the meaning of, so I've masked them for this post).

 

Reply by server was "NXDOMAIN".

The secondary and tertiary servers (lower priority) were basically never triggered. After changing the priority and now mainly using the DNS of another vendor, SBRS started working immediately.

TAC connected remotely to the appliance, collected network-dumps and recognized the DNS problems in the dumped replies.

View solution in original post

4 Replies 4

Udupi Krishna.
Cisco Employee
Cisco Employee

I dont see any ongoing issues with our global system that is meant for processing SBRS requests - https://urgentnotices.statuspage.io/

This does look like a local problem. If there were connectivity issues, message tracking would logically return "unable to retrieve".

 

If you are instead seeing none for all senders. Would be a good idea to contact TAC and get their feedback.

Thank you for your message and the link to the status page, didn't know that one.

TAC ticket is opened.

doverture
Level 1
Level 1

Hi, we are having the same issue: we was forced to improve the rate for envelope senders limits.

Are you sure is a local problem? Can you suggest some troubleshooting?

 

regards

HSmith82556
Level 1
Level 1

Replying to self as problem was solved with help of TAC.

It was a DNS problem. Resolving 'senderbase.org' worked. But the special queries that are generated to check incoming connections suddenly stopped being handled by our ISPs DNS.

They are TXT-queries, asking for

1-12341234123412341234123412341234.200.200.200.200.v1x2s.rf-xyzxyzxyz.senderbase.org

("200.200.200.200" would be the IP of the server trying to send mails.

"1234..." and "xyz..." are some random looking numbers which I don't now the meaning of, so I've masked them for this post).

 

Reply by server was "NXDOMAIN".

The secondary and tertiary servers (lower priority) were basically never triggered. After changing the priority and now mainly using the DNS of another vendor, SBRS started working immediately.

TAC connected remotely to the appliance, collected network-dumps and recognized the DNS problems in the dumped replies.