/var/log/DMIT-NOC.log
Confirmed hardware failure. We are ordering new MPC line card; You might experience decreased service level for all services in Hong Kong recently.
HKG line card failure has been resolved. Return to normal service.
/var/log/DMIT-NOC.log
China Telecom is too slow to do investigation and solve the problem. Switching to Softbank in temporary. Will switch back once CTGnet solve the problem.
Return routing (From DMIT to CTGnet) has been resoleved. Please check.
For China (CT/CU) to DMIT, please wait for further update.
There are some unresolved problems on the route from China to DMIT on CTGnet side.
For China (CT/CU) to DMIT, please wait for further update.
There are some unresolved problems on the route from China to DMIT on CTGnet side.
CTGnet initial report: The network failure occurred in their security protection system; part of their system does not received the route we announced, which lead to the traffic cannot be transmitted to DMIT.
CTGnet already esclated this issue to HQ, and pending resolve.
CTGnet already esclated this issue to HQ, and pending resolve.
/var/log/DMIT-NOC.log
CTGnet initial report: The network failure occurred in their security protection system; part of their system does not received the route we announced, which lead to the traffic cannot be transmitted to DMIT. CTGnet already esclated this issue to HQ, and…
China Telecom report problem has been resolved.
RFO(Reason of Outage) from CTGnet will be available soon.
RFO(Reason of Outage) from CTGnet will be available soon.
DMIT is now offering CN2 GIA inbound routing for HKG.EB routing by ‘Route Booster IPv4’.
It offers direct connection for CT and CU for inbound.
Check Black-Friday page for discount.
It offers direct connection for CT and CU for inbound.
Check Black-Friday page for discount.
Dear TYO.Pro clients who has 45.88 IPv4:
Since CTGnet won't able to fix the direct connection issue with China Unicom; and DMIT observed high packet loss and latency when bypassing CTGnet - CUGHK.
DMIT decide to change this subnet to 154.12. It has SHA-TYO direct connection with via 4837-4134-23764(4809) just like 103.117.
This action will start at anytime in 24hours.
You will received an email, and ticket when it's done. Your VM will be rebooted after action completed. The IP will be automatically update if the CloudInit work as expected in your VM.
Since CTGnet won't able to fix the direct connection issue with China Unicom; and DMIT observed high packet loss and latency when bypassing CTGnet - CUGHK.
DMIT decide to change this subnet to 154.12. It has SHA-TYO direct connection with via 4837-4134-23764(4809) just like 103.117.
This action will start at anytime in 24hours.
You will received an email, and ticket when it's done. Your VM will be rebooted after action completed. The IP will be automatically update if the CloudInit work as expected in your VM.
Scheduled maintenance
Location: Hong Kong
Duration: Nov 30 - Dec 3, 2023, Hong Kong Time
Duration:
- Less than 30 minutes per hypervisor;
- Max 1hr for VM. (Due to booting sequence.)
Content: Deploy DMIT Full Layer 3 network enhancements. Block ARP, multicast, broadcast, etc. in the customer's network; and provide additional IP address delivery methods: RADVD (IPv6), DHCP (IPv4).
CloudInit will still be the primary method. The SSH Key injection, password update should be updated by this methold.
At Hong Kong location, it saves about ~5GB per month for you.
Location: Hong Kong
Duration: Nov 30 - Dec 3, 2023, Hong Kong Time
Duration:
- Less than 30 minutes per hypervisor;
- Max 1hr for VM. (Due to booting sequence.)
Content: Deploy DMIT Full Layer 3 network enhancements. Block ARP, multicast, broadcast, etc. in the customer's network; and provide additional IP address delivery methods: RADVD (IPv6), DHCP (IPv4).
CloudInit will still be the primary method. The SSH Key injection, password update should be updated by this methold.
At Hong Kong location, it saves about ~5GB per month for you.
The core reason we have to do this is because of ARP is not suit for public cloud.
at Juniper, all ARP response packets are handled by the RE.
a) The CPU usage growth with the network size. It slow down the BGP/OSPF/MPLS/etc. route calculation, also might leads to crash during high load.
at Juniper, the PFE will send ARP if the target in LAN but not in ARP table on each packet received.
b) During the network scanning to all IPv4 we have, it generate huge number of ARP requests when the target does not existed in our network;
at Juniper, the RE has a internal rule to protect it will not be flooded by ARP; it just a simple rate limit.
c) It means the IP on your VM could lost ARP entity because of aging, and ARP rate-limit. It leads to sudden disconnection. (rarely happened, but could be. during full subnet scanning.)
at Juniper, all ARP response packets are handled by the RE.
a) The CPU usage growth with the network size. It slow down the BGP/OSPF/MPLS/etc. route calculation, also might leads to crash during high load.
at Juniper, the PFE will send ARP if the target in LAN but not in ARP table on each packet received.
b) During the network scanning to all IPv4 we have, it generate huge number of ARP requests when the target does not existed in our network;
at Juniper, the RE has a internal rule to protect it will not be flooded by ARP; it just a simple rate limit.
c) It means the IP on your VM could lost ARP entity because of aging, and ARP rate-limit. It leads to sudden disconnection. (rarely happened, but could be. during full subnet scanning.)
/var/log/DMIT-NOC.log
Extend 3 days
Everything is done;
If you have any issues:
- speed slow
- no network
- no IPv6
Stop the server and start it again. ≠ reboot
For IPv6, please login to the server and check the SLAAC assignment.
If you have any issues:
- speed slow
- no network
- no IPv6
Stop the server and start it again. ≠ reboot
For IPv6, please login to the server and check the SLAAC assignment.
/var/log/DMIT-NOC.log
The core reason we have to do this is because of ARP is not suit for public cloud. at Juniper, all ARP response packets are handled by the RE. a) The CPU usage growth with the network size. It slow down the BGP/OSPF/MPLS/etc. route calculation, also might…
After removing ARP from HKG, the CPU load of RE is significantly reduced.
/var/log/DMIT-NOC.log
The core reason we have to do this is because of ARP is not suit for public cloud. at Juniper, all ARP response packets are handled by the RE. a) The CPU usage growth with the network size. It slow down the BGP/OSPF/MPLS/etc. route calculation, also might…
Additionally, after we posted this message, DMIT received an increasing number of network scans of all the IPs we own.
Thanks for take caring of us.
Thanks for take caring of us.
Scheduled maintenance
Location: Tokyo
Duration: Dec 13 - Dec 19, 2023, Japan Standard Time
Duration:
- Less than 30 minutes per hypervisor;
- Max 30 minutes for VM. (Due to booting sequence.)
Content: Deploy DMIT Full Layer 3 network enhancements.
Location: Tokyo
Duration: Dec 13 - Dec 19, 2023, Japan Standard Time
Duration:
- Less than 30 minutes per hypervisor;
- Max 30 minutes for VM. (Due to booting sequence.)
Content: Deploy DMIT Full Layer 3 network enhancements.
/var/log/DMIT-NOC.log pinned «Scheduled maintenance Location: Tokyo Duration: Dec 13 - Dec 19, 2023, Japan Standard Time Duration: - Less than 30 minutes per hypervisor; - Max 30 minutes for VM. (Due to booting sequence.) Content: Deploy DMIT Full Layer 3 network enhancements.»
/var/log/DMIT-NOC.log
CTGnet initial report: The network failure occurred in their security protection system; part of their system does not received the route we announced, which lead to the traffic cannot be transmitted to DMIT. CTGnet already esclated this issue to HQ, and…
SLA Credit has been added as date; The billing date of all VMs in TYO added 1 month (Include EB and Pro.)