China Telecom AS140903 (AS-NAME: CHINANET-HEBEI-ZHANGJIAKOU-MAN) announced some smaller routes through AS4134 backbone to the Internet; but AS140903 seems did not announce them to AS4809.
This leads to AS4809 has no route to these smaller subnet destinations. The packets to all these destinations will go through the AS4134 backbone because BGP will always choose a smaller subnet as the best choice.
In the alternative language: The packets to these destinations will not go through AS4809, CN2 GIA network right now.
DMIT already report this to China Telecom GNOC and GCSC.
Please wait for further notices.
This leads to AS4809 has no route to these smaller subnet destinations. The packets to all these destinations will go through the AS4134 backbone because BGP will always choose a smaller subnet as the best choice.
In the alternative language: The packets to these destinations will not go through AS4809, CN2 GIA network right now.
DMIT already report this to China Telecom GNOC and GCSC.
Please wait for further notices.
DMIT found there is a long-time BGP Flapping on Any2IX Internet Exchange last night during 5 AM ~6 AM EST.
We already put BGP Flap Damping on the Any2IX peering session to avoid the flap damage our RIB and FIB. This is not the first time Any2IX continuously BGP flapping damage our FIB/RIB.
DMIT is now considering replace the Any2IX with Equinix IX Los Angles which is much BETTER than Any2IX. The reason we don't do it even we are in the same building with Equinix LA1 is that Digital Realty charges us 1.5kUSD to connect with Equinix LA1 by X-C in same building. Our NOC will try to find a cost-effective way to connect with Equinix.
We already put BGP Flap Damping on the Any2IX peering session to avoid the flap damage our RIB and FIB. This is not the first time Any2IX continuously BGP flapping damage our FIB/RIB.
DMIT is now considering replace the Any2IX with Equinix IX Los Angles which is much BETTER than Any2IX. The reason we don't do it even we are in the same building with Equinix LA1 is that Digital Realty charges us 1.5kUSD to connect with Equinix LA1 by X-C in same building. Our NOC will try to find a cost-effective way to connect with Equinix.
We found there is a major network issue in NTT(AS2914) tonight in the Hong Kong 🇭🇰 region. It seems a major network issue in the NTT APAC network. Update later.
/var/log/DMIT-NOC.log
We found there is a major network issue in NTT(AS2914) tonight in the Hong Kong 🇭🇰 region. It seems a major network issue in the NTT APAC network. Update later.
Nope~. It’s the network fault in AS58453.
We saw the traffic drop because some clients use HKG.Lite to connect with AS58453 / AS9808.
For this, we have no solution to solve it because it happens in the CMI network. Our NOC will try but no guarantee.
the 4th and 5th hop has ICMP rate limited. It's the NTT Juniper equipment.
As check with NTT, there is a congestion but it's still acceptable.
We saw the traffic drop because some clients use HKG.Lite to connect with AS58453 / AS9808.
For this, we have no solution to solve it because it happens in the CMI network. Our NOC will try but no guarantee.
the 4th and 5th hop has ICMP rate limited. It's the NTT Juniper equipment.
As check with NTT, there is a congestion but it's still acceptable.
/var/log/DMIT-NOC.log
China Telecom AS140903 (AS-NAME: CHINANET-HEBEI-ZHANGJIAKOU-MAN) announced some smaller routes through AS4134 backbone to the Internet; but AS140903 seems did not announce them to AS4809. This leads to AS4809 has no route to these smaller subnet destinations.…
As CTG CSC update. This has been solved.
/var/log/DMIT-NOC.log
DMIT found there is a long-time BGP Flapping on Any2IX Internet Exchange last night during 5 AM ~6 AM EST. We already put BGP Flap Damping on the Any2IX peering session to avoid the flap damage our RIB and FIB. This is not the first time Any2IX continuously…
We are going to disconnect with Any2IX soon. Due to the shitty quality.
This is not a simple BGP interrupt or route refresh. When the Any2IX is interrupted, and heir RS(Routing Server) still keep work. So they will announced some unreachable routes to send to us.
For example, their RS has a route from Apple, they will send to us, but we cannot connect with Apple via Any2IX Switching/Data Plane due to the network fault at their end (In IX design, traffic will not go thought RS)
This is not a simple BGP interrupt or route refresh. When the Any2IX is interrupted, and heir RS(Routing Server) still keep work. So they will announced some unreachable routes to send to us.
For example, their RS has a route from Apple, they will send to us, but we cannot connect with Apple via Any2IX Switching/Data Plane due to the network fault at their end (In IX design, traffic will not go thought RS)
/var/log/DMIT-NOC.log
We are going to disconnect with Any2IX soon. Due to the shitty quality. This is not a simple BGP interrupt or route refresh. When the Any2IX is interrupted, and heir RS(Routing Server) still keep work. So they will announced some unreachable routes to send…
Done, We already disconnect with both Any2IX RS in IPv4 and IPv6.
/var/log/DMIT-NOC.log
We are going to disconnect with Any2IX soon. Due to the shitty quality. This is not a simple BGP interrupt or route refresh. When the Any2IX is interrupted, and heir RS(Routing Server) still keep work. So they will announced some unreachable routes to send…
Any2IX dead again after we disconnect with RS.
Our NOC is trying to contact the networks in Any2IX to set up the private peering. The private peering session will shut down when the peer is unreachable.
The route will be deleted from FIB when the session is down. There are only a few seconds of impact during the update.
Due to there is a damping policy in our Peering BGP session, the routes will not become available immediately. It will go live once the route stable for a while
The image shows the traffic is low because we only peer few networks in Any2IX right now.
Our NOC is trying to contact the networks in Any2IX to set up the private peering. The private peering session will shut down when the peer is unreachable.
The route will be deleted from FIB when the session is down. There are only a few seconds of impact during the update.
Due to there is a damping policy in our Peering BGP session, the routes will not become available immediately. It will go live once the route stable for a while
The image shows the traffic is low because we only peer few networks in Any2IX right now.
Web maintenance notice:
Feb 2, 4:00PM~6:00PM EST
Impact: dmit.io temporarily inaccessible;
Duration: 3h Max;
Please be prepared in advance.
Feb 2, 4:00PM~6:00PM EST
Impact: dmit.io temporarily inaccessible;
Duration: 3h Max;
Please be prepared in advance.
/var/log/DMIT-NOC.log pinned «Web maintenance notice: Feb 2, 4:00PM~6:00PM EST Impact: dmit.io temporarily inaccessible; Duration: 3h Max; Please be prepared in advance.»
/var/log/DMIT-NOC.log
Web maintenance notice: Feb 2, 4:00PM~6:00PM EST Impact: dmit.io temporarily inaccessible; Duration: 3h Max; Please be prepared in advance.
First Stage is Completed.
The website might be very slow right now since the database is in Los Angles and the website is in Taipei.
The final stage is to move the website to Los Angles. We will proceed later tonight.
The website might be very slow right now since the database is in Los Angles and the website is in Taipei.
The final stage is to move the website to Los Angles. We will proceed later tonight.
/var/log/DMIT-NOC.log
First Stage is Completed. The website might be very slow right now since the database is in Los Angles and the website is in Taipei. The final stage is to move the website to Los Angles. We will proceed later tonight.
Done. Please wait for the DNS flush if you cannot access the site.
The connection of sPro was temporarily disconnected because of some problems in our connection with CFMT.
/var/log/DMIT-NOC.log
DMIT.io is under sPro routing profile.
There is maintenance in our circuit vendor.
We just ignored this..
We do have a backup circuit between CFMT, but we are trying to figure out why the traffic didn't detour to that one.
We just ignored this..
We do have a backup circuit between CFMT, but we are trying to figure out why the traffic didn't detour to that one.
Even we as an enterprise client of Cloudflare, they give nothing help when we call them. The ticket has never been replied by CF during this hour.
The prefixes have already been withdrawal from Cloudflare 10 minutes ago. We will ask to advise it once everything is fixed include the primary and backup link.
The prefixes have already been withdrawal from Cloudflare 10 minutes ago. We will ask to advise it once everything is fixed include the primary and backup link.
DMIT received a CHILD ABUSE taken down notice for 154.17.0.52
Please NOTE: DMIT has a zero-tolerance policy for children's abuse and pornography.
Once we received related notices:
- Your account information and payment information will be shared with the related US. Dept
- Your payment account, DMIT account, DMIT Credit, all DMIT services will be terminated or banned in DMIT Inc.
DMIT Inc.
Please NOTE: DMIT has a zero-tolerance policy for children's abuse and pornography.
Once we received related notices:
- Your account information and payment information will be shared with the related US. Dept
- Your payment account, DMIT account, DMIT Credit, all DMIT services will be terminated or banned in DMIT Inc.
DMIT Inc.
/var/log/DMIT-NOC.log
Even we as an enterprise client of Cloudflare, they give nothing help when we call them. The ticket has never been replied by CF during this hour. The prefixes have already been withdrawal from Cloudflare 10 minutes ago. We will ask to advise it once everything…
Cloudflare didn't finish the configuration on their side for 2 backup links. They are working on it.
We will announce the route via CFMT ASAP once they finished.
We will announce the route via CFMT ASAP once they finished.