Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

Sign In Register

Quick Links


Categories

In this Discussion

› › L.A 100Gbps DDoS Protection from $7 - X4B
New on LowEndTalk? Please Register and read our Community Rules.

All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.

L.A 100Gbps DDoS Protection from $7 - X4B

SplitIceSplitIce Member, Host Rep
edited June 2016 in Offers

Hi All! We're pleased to announce a new L.A. 100Gbps location at extremely affordable pricing. 100Gbps protection Asia optimised protection from $7! Limited Time only, pick one up before they run out, this discount won't be seen again! You won't regret it!

Offer

Location: Los Angeles

Protection: 100Gbps / 100Mpps Guaranteed (All Layers, All Attacks)

Asia / Pacific Optimized: Yes, Including China Unicom / China Telecom

Clean Bandwidth: 25GB

Price: $15/month $6.75/month (55% off) with coupon LET55LA

Order Now

Notes:

  • Additional Clean Bandwidth, Upgrades and Extras available for reasonable prices.
  • Coupon applies to all new L.A 100Gbps services, limit of 2 per customer
  • Coupon Limited to first 50 orders
  • Offer expires: 15th of July, 2016
  • Looking for something else? 10% discount on any other new service. Coupon: LET10

Features

  • Always On Multi-Layer Mitigation solution, filtering down to the last byte.
  • GRE/IP-in-IP/IPSec and Reverse Proxy support (full support provided for Linux and Windows)
  • HTTP Load Balancing & Backup Servers
  • HTTPS & HTTP/2.0 support
  • Extensive Network Monitoring and 24/7 Incident Response.
  • Optimised TCP stack for minimum latency
  • Mature Platform backed by 5 Years of Industry Experience
  • In-house developed comprehensive Layer 7 Mitigation
  • HTTP Resource Caching & HTTPS Optimizations for maximum performance

Questions?

Please feel free to ask any sales related questions through this thread, by emailing [email protected] or by opening a sales ticket. If you require any account or service specific support please open a support ticket.

Test IP: 103.249.71.2

Support: https://www.x4b.net/support

Bonus

Happy with our services? Post an honest testimonial either here, or on any other Forum, Blog or Social Network over the next few months and receive a months credit (to the value of $7). Credit is Bonus Credit which does not expire, bonus credit is non-refundable or transferable.

Honest Reviews Only. Limited Numbers. Contact Support for more information.

All prices expressed in $USD

Thanked by 1Magbanua

Comments

  • qibinghuaqibinghua Member

    Let me try

  • qibinghuaqibinghua Member

    I order one, but China Telecom is through zayo not CT

  • SplitIceSplitIce Member, Host Rep

    @qibinghua Thanks for letting us know. I have made an inquiry with the Network Admin.

    It could be related to mitigation events.

    The CU & CT gateways are online from what I can see, but I am not seeing it outgoing currently. I'll let you know when I know more.

  • SplitIceSplitIce Member, Host Rep

    @qibinghua The Route optimiser will attempt to choose the most optimal route possible. If there is a route via another transit provider (i.e Zayo or HE) that is at the same (similar) latency it may be chosen (for being significantly cheaper).

    If you wish we can possibly source route your network. Or if it is significantly improved via transit with CU/CT look into why it was not routed over that network to begin with. If you have any IPs you wish me to test, shoot me reply, ticket or PM and I'll be right on it.

    Today we have been in-chat with the Network Admin for many hours looking into this. Particularly making sure the most optimal routes are being taken. I think everything is ok, but the Network Admin will be doing some comprehensive analysis of his own later today.

    Thanks.

    Thanked by 1vimalware
  • qibinghuaqibinghua Member
    edited June 2016

    Yes. significantly via transit with CU/CT if you can,now it is via zayo.

    Host Loss% Snt Last Avg Best Wrst StDev
    1. ???
    2. 172.31.10.49 0.0% 8 0.8 0.9 0.8 1.0 0.0
    3. 122.224.220.37 0.0% 8 2.8 3.7 1.8 4.9 0.8
    4. 61.164.21.89 0.0% 8 1.3 1.3 1.3 1.4 0.0
    5. 61.164.22.149 0.0% 8 5.5 6.2 1.9 9.3 2.5
    6. 202.97.92.41 0.0% 7 6.7 5.8 4.2 7.0 1.1
    7. 202.97.35.162 14.3% 7 57.0 55.4 54.0 57.8 1.5
    8. 202.97.91.62 28.6% 7 6.5 6.6 6.5 6.8 0.0
    9. 202.97.51.22 0.0% 7 164.8 166.2 164.7 167.7 1.2
    10. 202.97.49.118 0.0% 7 202.2 201.7 200.5 203.1 0.7
    11. xe-8-1-2.mpr1.lax12.us.zip.zayo.com 28.6% 7 241.8 241.9 241.8 242.0 0.0
    12. et-3-1-1.mpr2.lax12.us.zip.zayo.com 83.3% 7 183.2 183.2 183.2 183.2 0.0
    13. ae0.cr2.lax112.us.zip.zayo.com 33.3% 7 181.8 181.6 181.5 181.8 0.0
    14. ae10.er4.lax112.us.zip.zayo.com 0.0% 7 147.8 147.9 147.7 148.6 0.0
    15. et-0-1-1.zayo.lax.us.AS40676.net 0.0% 7 241.9 214.4 208.0 241.9 12.4
    16. helms-deep-lax.AS40676.net 14.3% 7 171.9 223.0 168.8 312.0 56.5
    17. ???
    18. node-103-249-71-2.reverse.x4b.me 0.0% 7 134.1 134.4 134.0 135.3 0.4

  • SplitIceSplitIce Member, Host Rep

    Hi,

    134ms ping via Zayo? At a glance that looks pretty good.

    Is there an ip address you would like me to test? (feel free to pm it)

  • qibinghuaqibinghua Member

    ping is low,but not stable in fastigium and slowly speed

  • SplitIceSplitIce Member, Host Rep

    @qibinghua Please send through the ip address.

  • qibinghuaqibinghua Member
    edited June 2016

    from 183.131.0.*:

    PING 103.249.71.49 (103.249.71.49) 56(84) bytes of data.

    64 bytes from 103.249.71.49: icmp_seq=1 ttl=51 time=192 ms

    64 bytes from 103.249.71.49: icmp_seq=2 ttl=51 time=193 ms

    64 bytes from 103.249.71.49: icmp_seq=3 ttl=51 time=193 ms

    64 bytes from 103.249.71.49: icmp_seq=4 ttl=51 time=189 ms

    PING 103.249.71.2 (103.249.71.2) 56(84) bytes of data.

    64 bytes from 103.249.71.2: icmp_seq=1 ttl=51 time=133 ms

    64 bytes from 103.249.71.2: icmp_seq=2 ttl=51 time=133 ms

    64 bytes from 103.249.71.2: icmp_seq=3 ttl=51 time=133 ms

    64 bytes from 103.249.71.2: icmp_seq=4 ttl=51 time=133 ms

    64 bytes from 103.249.71.2: icmp_seq=5 ttl=51 time=133 ms

    64 bytes from 103.249.71.2: icmp_seq=6 ttl=51 time=133 ms

    from 116.231.235.*:

    PING 103.249.71.2 (103.249.71.2): 56 data bytes

    64 bytes from 103.249.71.2: icmp_seq=0 ttl=51 time=203.579 ms

    64 bytes from 103.249.71.2: icmp_seq=1 ttl=51 time=196.154 ms

    64 bytes from 103.249.71.2: icmp_seq=2 ttl=51 time=200.609 ms

    64 bytes from 103.249.71.2: icmp_seq=3 ttl=51 time=200.949 ms

    64 bytes from 103.249.71.2: icmp_seq=4 ttl=51 time=201.538 ms

    PING 103.249.71.49 (103.249.71.49): 56 data bytes

    64 bytes from 103.249.71.49: icmp_seq=0 ttl=51 time=210.010 ms

    64 bytes from 103.249.71.49: icmp_seq=1 ttl=51 time=203.022 ms

    64 bytes from 103.249.71.49: icmp_seq=2 ttl=51 time=205.803 ms

    64 bytes from 103.249.71.49: icmp_seq=3 ttl=51 time=211.785 ms

    64 bytes from 103.249.71.49: icmp_seq=4 ttl=51 time=197.223 ms

    64 bytes from 103.249.71.49: icmp_seq=5 ttl=51 time=206.203 ms

  • SplitIceSplitIce Member, Host Rep

    @qibinghua Thank you. I will update you when I know more. I have collected routes and informed the Network Admin.

  • SplitIceSplitIce Member, Host Rep

    @qibinghua

    I have been conducting quite a bit of testing. The IPs provided by you seem to be better now. We got the routing for our /24 optimized a bit more aggressively.

    We will continue working on even more tweaks over the next few weeks as we strive to be the best we can.

    FYI, CU/CT direct isnt always the best.

    root@cn-south-1:/home/splitice# ping *ct-direct-peering* -n
PING *** 56(84) bytes of data.
64 bytes from 45.34.***.***: icmp_seq=1 ttl=48 time=174 ms
64 bytes from 45.34.***.***: icmp_seq=2 ttl=48 time=174 ms
64 bytes from 45.34.***.***: icmp_seq=3 ttl=48 time=174 ms
64 bytes from 45.34.***.***: icmp_seq=4 ttl=48 time=174 ms
64 bytes from 45.34.***.***: icmp_seq=5 ttl=48 time=174 ms
64 bytes from 45.34.***.***: icmp_seq=6 ttl=48 time=184 ms
64 bytes from 45.34.***.***: icmp_seq=7 ttl=48 time=184 ms
^C


root@cn-south-1:/home/splitice# ping 103.249.71.2 -n
PING 103.249.71.2 (103.249.71.2) 56(84) bytes of data.
64 bytes from 103.249.71.2: icmp_seq=1 ttl=48 time=159 ms
64 bytes from 103.249.71.2: icmp_seq=2 ttl=48 time=159 ms
64 bytes from 103.249.71.2: icmp_seq=3 ttl=48 time=162 ms
64 bytes from 103.249.71.2: icmp_seq=4 ttl=48 time=162 ms
64 bytes from 103.249.71.2: icmp_seq=5 ttl=48 time=162 ms
64 bytes from 103.249.71.2: icmp_seq=6 ttl=48 time=162 ms
64 bytes from 103.249.71.2: icmp_seq=7 ttl=48 time=162 ms
^C
--- 103.249.71.2 ping statistics ---
7 packets transmitted, 7 received, 0% packet loss, time 6004ms
rtt min/avg/max/mdev = 159.544/161.837/162.794/1.423 ms

CT -> L.A via comcast on Aliyun, although they might be paying some premium deal with Comcast since they choose that over the shorter CT direct route.
  • MagbanuaMagbanua Member

    Ordered one of this last week. So far so good. I see you're using Psychz, do you use your own firewalls or you use Edge Layer?

    Also, some functions in client area seems not working yet.

  • SplitIceSplitIce Member, Host Rep

    @Magbanua I am unaware of anything that is not working at this time. I don't see any Bugsnag reports either. If you have problems with anything, please open a support ticket. I'll take a look ASAP.

    We have been using our own platform (Layers 3 - 7 filtering, caching, etc) for years. No off the shelf solution here.

  • MagbanuaMagbanua Member

    @SplitIce said:
    @Magbanua I am unaware of anything that is not working at this time. I don't see any Bugsnag reports either. If you have problems with anything, please open a support ticket. I'll take a look ASAP.

    We have been using our own platform (Layers 3 - 7 filtering, caching, etc) for years. No off the shelf solution here.

    Bandwidth usage and filter status seems not reporting any data.

  • SplitIceSplitIce Member, Host Rep
    edited June 2016

    Yes, Bandwidth usage is offline. Relax, that means free bandwidth. Although now that I state this publicly it will be abused. I have to get back to working on fixing it.

    Filter Status Works fine. It displays all the information we have, which varies by location.

  • MagbanuaMagbanua Member

    @SplitIce said:
    Yes, Bandwidth usage is offline. Relax, that means free bandwidth. Although now that I state this publicly it will be abused. I have to get back to working on fixing it.

    Filter Status Works fine. It displays all the information we have, which varies by location.

    Oh I see.

    Is it real-time data?

  • SplitIceSplitIce Member, Host Rep
    edited June 2016

    "varies by location"

    Mitigation information from our platform is close to real-time.
    Upstream mitigation solutions, its close real time (once we get it).

  • qibinghuaqibinghua Member

    @SplitIce said:

    yes.

  • SplitIceSplitIce Member, Host Rep
    edited June 2016

    @qibinghua Glad to help. Sorry it took so long.

    FYI PCCW had better outgoing routes (US->CN) than CT direct. Go figure.

  • joojajooja Member
    edited June 2016

    Bought 2 from L.A and Dallas.
    ddos protection not good for teamspeak

    L.A got packet loss(7-8%) trying with teamspeak / reverse proxy
    Also some downtimes related with DDoS i believe.
    I sent a ticket they are working on it apparently.

  • SplitIceSplitIce Member, Host Rep

    Hi,

    As you have been informed in your ticket. The upstream failed to mitigate an attack for a short while resulting in some port saturation.

    We dropped 100% of the attack traffic (it matched multiple of our static rules, let alone dynamic ones). However we had a port pushing saturation resulting in some packet loss.

    We are still in discussion with Psychz regarding this.

  • joojajooja Member

    @SplitIce said:
    Hi,

    As you have been informed in your ticket. The upstream failed to mitigate an attack for a short while resulting in some port saturation.

    We dropped 100% of the attack traffic (it matched multiple of our static rules, let alone dynamic ones). However we had a port pushing saturation resulting in some packet loss.

    We are still in discussion with Psychz regarding this.

    Ok i am not experienced with this theme, i hope you can found(i still offline) a solution thank you

  • SplitIceSplitIce Member, Host Rep
    edited June 2016

    Yes,

    We are still waiting on a resolution from the upstream. We arent happy either.

    Our ticket has gone 3 hours now without response.

Sign In or Register to comment.