Tor being blocked by mayor ISP in Mexico?

I've been running an exit relay for about 2 years. Since new year's day, I noticed that my relay went down and was no longer listed in Globe or Atlas. Just like Fabian Bustillos Vega reported here:
https://lists.torproject.org/pipermail/tor-relays/2016-January/008491.html a few days ago.

Software version at the time: (was running without problems for almost five months)
Tor: 2.6.10
openSSL: 1.0.1i
libevent: 2.0.21
running on Linux

At first, I thought it was a configuration error, so I double checked the TORRC file manually and with software (Vidalia and ARM). Everything was OK.

I check the log file and found something very unusual, when trying to connect to the Tor network, there were several openSSL connection errors. Eventually after a while and several attempts, Tor connection was successful.
Here's the error:
[warn] 8 connections died in state connect()ing with SSL state (No SSL object)
[warn] 1 connections died in state handshaking (Tor, v3 handshake) with SSL state SSL negotiation finished successfully in OPEN
[warn] Problem bootstrapping. Stuck at 50%: Loading relay descriptors. (Connection timed out; TIMEOUT; count 11; recommendation warn; host 7BE683E65D48141321C5ED92F075C55364AC7123 at 193.23.244.244:443)
This happened for other host as well.
Link to complete log. *See note at bottom.

I thought maybe some Tor's Directories went down or my router was dropping packets for some reason.
Several hours later I restarted my router and tried to connect again. I got the same error.

I went to the tor project website and read the release notes, I found that new versions were using a new elliptic-curve Diffie-Hellman function, so I decided to update Tor to version 2.7.6.
The error appeared once again.

I tried with The Tor Browser and again, it took a while to establish a connection. I had to abort and reconnect several times in order to establish a successful connection.
With these results I tried some other software; TAILS (Linux distro), Fire.Onion (Android browser).
Both got stuck as well while bootstrapping.
TAILS with no intervention is able to connect after a long long while, just like my Relay.
Fire.Onion just like the Tor Browser are unable to connect unless I abort and reconnect several times.

Back to my Relay... When it finally connects:
[notice] Bootstrapped 90%: Establishing a Tor circuit
[notice] Tor has successfully opened a circuit. Looks like client functionality is working.
[notice] Bootstrapped 100%: Done
[notice] Now checking whether ORPort XXX.XXX.XXX.XXX:9001 and DirPort XXX.XXX.XXX.XXX:9030 are reachable... (this may take up to 20 minutes -- look for log messages indicating success)
[notice] Self-testing indicates your DirPort is reachable from the outside. Excellent.
[notice] Self-testing indicates your ORPort is reachable from the outside. Excellent. Publishing server descriptor.
[notice] Performing bandwidth self-test...done.

So I Waited a couple of hours and check in Atlas and Globe again. No luck.
In the log I also get:
[notice] Heartbeat: It seems like we are not in the cached consensus.

The DIR and ONION ports are open as showed by the log, I also manually checked them using port scanners.
I used other people's networks, the Tor Browser and TAILS to connect to my XXX.XXX.XXX.XXX:9030 port. In every case I got the DirPortFrontPage (html) served by Tor.
As indicated by the log I have client connectivity and the Relay seems to be in order but in reality the Relay is dead.

It is also worth mentioning that after a successful connection the openSSL errors no longer appear in the Relay's log. Maybe Tor is skipping those (previously faulty) servers. I can only guess.
A similar thing happen with the Tor Browser, if I open it frequently, it connects fast (after a successful connection), but if is not used in days, when I launch it, it gets stuck while bootstrapping.
Since TAILS is a “live” distro I can't reproduce this behavior.

My Relay, the Tor Browser and Fire.Onion have a higher possibility to get stuck while bootstrapping at 0, 5, 20%. Once passed the 50~60% it get faster.
My assumption is that my ISP is blocking or at least randomly dropping packets to and from well known Tor Authorities (IP blocking).
I don't suspect DPI, as client functionality is working.
Using bridges was not necessary when trying client functionality. I was able to connect (abort and retry). As reported by Fabian Bustillos as well.

Other Observations:
Tor Project website, TAILS website and other Tor related pages are visible without tor.
Once connected the Tor Browser is able to fetch updates.
Instead of ports 9001 and 9030 I also tried 443 (OR) and 80 (DIR).
*For the log, I deleted the Data directory in order to reproduce all the errors, this includes; keys, logs and cached* files.