Resumen
- TSBG Hosting Ltd. se presenta como un operador de infraestructura búlgaro fundado en 2006, con ofertas de colocación, servidores cloud, servidores dedicados, hosting compartido, streaming y servicios gestionados en su propio sitio.
- Las afirmaciones operativas más sólidas de la empresa son físicas, no puramente virtuales: varias instalaciones de centros de datos neutrales en cuanto a operador en Bulgaria, cuatro centros de datos, diseño orientado a TIA-942, alimentación A/B, monitorización, manos remotas, detección de incendios, refrigeración y acceso escoltado.
- La señal de red pública actual es débil.RIPE RDAPidentifica AS43112 como tsbg_hosting y registra a TSBG Hosting Ltd. como titular, peroel estado de enrutamiento de RIPEstatmostró cero espacio anunciado IPv4 o IPv6 visible para AS43112 el 2026-07-12.
- El recurso 193.3.63.0/24 de TSBG sigue siendo relevante porqueRIPE RDAP para el prefijoidentifica BG-TSBGHOSTING-20200902, yla validación RPKI de RIPEstatvalidó a AS43112 como autorizado para ese prefijo. Autorización no es lo mismo que accesibilidad en vivo.
- El registro de instalación de TSBG Hosting en PeeringDBañade una pista física de Haskovo/Svilengrad, mientras quelos datos de red-instalación de PeeringDBvinculan la conexión listada a AS47288/FixNET en lugar de AS43112. Esto respalda la necesidad de verificar los límites del operador antes de confiar en cualquier afirmación de resiliencia.
- El grado de evidencia es Débil. El sitio oficial proporciona afirmaciones de servicio detalladas, pero la evidencia de enrutamiento público actual no prueba de forma independiente tráfico de clientes activo en AS43112, conmutación por error multisitio, diversidad de tránsito, capacidad de reserva o portabilidad de datos.
Una factura cloud aún aterriza en una sala de máquinas búlgara
TSBG Hosting Ltd. no es un nombre que pueda evaluarse por reconocimiento de marca. Debe evaluarse rastreando el servicio hasta el equipo y las personas que mantendrían a un cliente en línea. La empresa vende servicios que parecen elásticos: servidores cloud, planes VPS, servidores dedicados, hosting compartido, streaming, colocación y soporte gestionado. Pero todos esos servicios tienen un inventario físico detrás. Un servidor virtual necesita capacidad de host, almacenamiento, conmutación, alimentación y refrigeración. Un servidor dedicado necesita un chasis específico y un plan de sustitución.
La colocación necesita un rack, un presupuesto de energía, rutas de cable, control de acceso y manos remotas. El streaming necesita capacidad de ingreso, transcodificación o entrega y suficiente ancho de banda de salida para soportar a la audiencia cuando la demanda aumenta.
El hecho útil sobre TSBG es que la empresa no se describe a sí misma solo en un lenguaje vago de cloud. Lapágina de inicio oficialcomercializa colocación, servidores dedicados, servidores virtuales, streaming y colocación de antenas satelitales. La misma página describe cuatro centros de datos neutrales en cuanto a operador y dieciséis años de experiencia, y dice que TSBG puede soportar cloud privada, sitios de recuperación ante desastres, acceso dedicado a Internet, direcciones IPv4, suministro de corriente continua y enlace descendente satelital. Esas afirmaciones dan al comprador una lista concreta para probar: edificios, racks, dominios de energía, fibras, proveedores upstream, servidores, recursos de direcciones y acuerdos de soporte.
El riesgo es que el detalle del marketing público aún puede superar la evidencia operativa verificable. Un proveedor puede tener racks pero subcontratar algunas rutas de red. Puede tener un ASN válido pero no anunciarlo actualmente. Puede publicar un menú de servicios mientras que los planes individuales dependen del stock disponible, del soporte de proveedores o de una instalación de terceros. Puede ofrecer un sitio de recuperación mientras que el contrato del cliente deja los objetivos de recuperación vagos.
Para TSBG, el registro público contiene exactamente esa mezcla: una historia de servicio específica, una identidad búlgara específica, un número AS específico, y una brecha entre el registro de recursos numéricos y la originación de rutas visible en la fecha de publicación.
Esa brecha no hace que TSBG no sea confiable. Cambia la carga de la prueba. Un cliente no debe tratar la lista de precios web o el ASN como un informe de aseguramiento. El cliente debe preguntar qué instalación aloja la carga de trabajo, qué frontera de red anuncia el servicio, qué proveedor tiene tránsito con capacidad de ruta por defecto, cuánta energía y hardware de repuesto están reservados, y cómo los datos abandonan la plataforma si el servicio debe ser movido.
Qué se puede identificar con confianza
La identidad de la empresa es más sólida de lo que sugería la instantánea inicial del directorio. El sitio de TSBG dice que la empresa fue fundada en 2006, está constituida bajo la ley búlgara, indica el número de IVA europeo BG175059953, nombra a Ivan Shishkov como director general y da una dirección de oficina en Sofía, en 8 Racho Dimchev Street. Lapágina de contactorepite la dirección de Sofía, el número de teléfono y el correo de ventas.RIPE RDAP para AS43112identifica el nombre del objeto como tsbg_hosting e incluye a TSBG Hosting Ltd. como entidad organizativa con una dirección en Sofía.Los datos whois de RIPEstatregistran aut-num 43112, as-name tsbg_hosting, organización ORG-THL32-RIPE, estado ASSIGNED y maintainer mnt-bg-tsbghosting-1.
Esos registros son suficientes para evitar un error común en la investigación de hosting: tratar un nombre de servicio como una etiqueta flotante sin un titular responsable. Aquí, el titular puede vincularse a una identidad empresarial búlgara, una superficie de contacto, un registro de recursos numéricos y un sitio de servicio visible. Eso es más útil que una página de revendedor sin dirección y sin registro de enrutamiento.
El alcance del servicio también es específico. Lapágina de colocaciónde TSBG anuncia paquetes de una unidad de rack, cuarto de rack, medio rack y rack completo, con potencias declaradas que van desde 35 W para una unidad de rack hasta 1500 W para un rack completo. La página también dice que la empresa puede proporcionar conectividad a Internet, direcciones IPv4 y servicios LIR. Lapágina de servidores cloudenumera planes VPS, almacenamiento SSD, protección RAID10, Internet compartido de 1 Gbit/s y copias de seguridad opcionales. Lapágina de servidores dedicadosdescribe fuentes de alimentación redundantes, RAID 1 o RAID 10, dos controladores de red y redundancia de switches top-of-rack. Lapágina de hostingcubre hosting compartido y hosting VPS, incluida la ayuda para la migración.
Esa combinación indica un proveedor que vende infraestructura en varios niveles de abstracción. Los clientes pueden alquilar una porción de una plataforma compartida, una máquina virtual, un servidor físico, espacio en rack, conectividad o soporte. El problema económico es que los productos de nivel superior heredan las restricciones de los niveles inferiores. Si el rack pierde energía, los planes de servidores dedicados y VPS asociados a ese sitio se ven afectados. Si el borde de la red pierde un proveedor o se retira un objeto de ruta, un plan de hosting aparentemente separado aún puede fallar al mismo tiempo que el servicio de colocación.
Si el soporte es gestionado por el mismo equipo pequeño que realiza la sustitución de hardware, un incidente concurrido puede convertir una promesa de "manos remotas gratuitas" en una cola.
El registro de recursos numéricos está activo, pero el borde público estaba silencioso
El hecho de red más importante no es halagador, pero es preciso.La descripción general de AS43112 de RIPEstatidentificó al titular como tsbg_hosting TSBG Hosting Ltd., pero marcó el ASN como no anunciado para la consulta del 2026-07-12.El estado de enrutamiento de RIPEstatinformó que la primera ruta vista fue 77.246.240.0/20 el 2007-06-14 y la última ruta vista fue 193.3.63.0/24 el 2025-08-15, mientras que la visibilidad actual era cero de 325 pares IPv4 y cero de 322 pares IPv6.Los prefijos anunciados de RIPEstatno devolvieron prefijos actuales para AS43112 en el período del 2026-06-28 al 2026-07-12.
Eso no borra las afirmaciones de servicio de TSBG. Dice algo más limitado: los recolectores de rutas públicas no vieron a AS43112 transportando espacio anunciado en vivo en la fecha de publicación. Un cliente no puede usar AS43112 solo como prueba de servicio de Internet actual, diversidad de tránsito o tráfico de clientes. Si los servicios actuales se entregan a través de un ASN diferente, un bloque de direcciones asignado por el operador, una red de proveedor, un interconector privado o un acuerdo de upstream gestionado, eso debe declararse y probarse directamente.
El borde público inactivo también cambia la forma de leer la evidencia anterior.El historial de enrutamiento de RIPEstatmuestra una larga actividad histórica para 77.246.240.0/20, 77.246.240.0/21 y 193.3.63.0/24, con la ruta 193.3.63.0/24 ampliamente visible durante gran parte de 2022 a 2025 antes de caer a una visibilidad mínima después de mediados de agosto de 2025. El historial es útil para la identidad y la continuidad. No es capacidad actual. Si los mismos clientes siguen siendo atendidos, ahora pueden ser atendidos a través de otro diseño de red. Si el prefijo se retiró porque los servicios se movieron, la ruta de migración importa. Si se retiró porque el servicio se pausó, un comprador necesita saberlo antes de encargar capacidad.
RPKI añade un matiz más.La validación RPKI de RIPEstat para 193.3.63.0/24 y AS43112devolvió válido. Esa es una evidencia administrativa positiva: AS43112 está autorizado para originar el prefijo. Pero la autorización de origen de ruta válida no es lo mismo que el anuncio. Un detector de humos puede estar instalado en una habitación que actualmente está vacía; una ROA puede existir para una ruta que no es visible en BGP. El derecho de plano de control existe, mientras que la ruta operativa aún necesita confirmación en vivo.
El sitio afirma tener instalaciones sólidas, pero el mapa está incompleto
La historia pública más sólida de TSBG es su historia de instalaciones físicas. Lapágina de historia del centro de datosdice que la empresa fue fundada en 2006, completó su primer centro de datos en septiembre de 2006, completó un segundo proyecto de colocación en julio de 2007, completó un tercer centro de datos como sitio de recuperación ante desastres con el primer equipo instalado en julio de 2008, y completó un cuarto centro de datos en octubre de 2008. También dice que desde 2014 TSBG se ha centrado en la colocación, el hosting, el alquiler de servidores y los servicios gestionados.
Lapágina de centros de datosamplía la afirmación sobre las instalaciones. Dice que los sitios de TSBG están diseñados según TIA-942, que las ubicaciones se seleccionan cuidadosamente, que la empresa garantiza el 100 % de disponibilidad de energía, que la energía está diseñada en una configuración A/B completamente diversificada, que la refrigeración es redundante por capacidad nominal y que la seguridad física incluye sitios vigilados, videovigilancia y acceso escoltado. Dice que la monitorización cubre la carga del servidor, la memoria, los discos, el tráfico de los puertos, el estado del equipo, la temperatura, la humedad, la corriente eléctrica, el consumo de energía, el aire acondicionado y el rendimiento de la red óptica.
Esas son afirmaciones serias. También requieren que un comprador solicite evidencia específica de la instalación. "Cuatro centros de datos" es un punto de partida útil solo si el cliente puede identificar cuál de los cuatro alojará su carga de trabajo, si el sitio de recuperación está activo o en espera, si los sitios comparten el mismo upstream, si el almacenamiento de respaldo se encuentra en un dominio de fallo separado y qué objetivo de recuperación contractual se aplica cuando un sitio está aislado. Las páginas públicas describen principios y capacidades.
No nombran cada edificio, fuente de alimentación, contrato de combustible, punto de encuentro de operadores, inventario de repuestos ni resultado de recuperación probado.
La afirmación geográfica también necesita un manejo cuidadoso. TSBG dice que sus edificios están en Bulgaria y están distribuidos geográficamente, a más de 150 km de distancia, en zonas seleccionadas para reducir los riesgos de inundaciones, incendios, tráfico, industriales y de actividad humana. Supublicación del blog de 2023 sobre Bulgaria como ubicación de centros de datosdice que Bulgaria se encuentra en rutas importantes entre Europa, Turquía y Oriente Medio, y dice que TSBG puede proporcionar enlaces protegidos de Capa 2 e IP a través de rutas diversas a Estambul, Sofía, Bucarest y redes europeas. Esa es una tesis regional valiosa, especialmente para clientes con necesidades de latencia en los Balcanes, hacia Turquía o entre Europa y Oriente Medio. Pero la ventaja de ubicación no sustituye a la evidencia de rutas en vivo. Un buen corredor aún necesita operadores contratados, conductos diversos, cross-connects funcionales y suficiente capacidad después de que falle un enlace.
PeeringDB añade una pista de Haskovo y una advertencia sobre límites del operador
PeeringDB da a la historia de las instalaciones una pista pública separada.La API de instalaciones de PeeringDB para la instalación 13672enumera "TSBG Hosting" en Haskovo, Bulgaria, con dirección1 "Byalo More 3 Kapitan Andreevo," provincia Svilengrad, país BG, un campo de sitio webtsbg.eu, teléfono y correo electrónico de ventas y técnico, y servicio de voltaje disponible 480 VAC. El registro se creó el 2023-05-19 y se actualizó el 2025-09-26. Eso es útil porque está fuera del propio sitio de TSBG y apunta a una superficie de instalación específica con nombre en el sur de Bulgaria, cerca del contexto de la frontera entre Turquía y Grecia enfatizado por el sitio de TSBG.
Pero los mismos datos de PeeringDB crean un problema de límite.Los datos de netfac de PeeringDB para la instalación 13672muestran una entrada de red adjunta denominada TSBG Hosting en Haskovo con ASN local 47288.La red 26850 de PeeringDBidentifica esa red como FIXNET TELEKOM LTD. STI., ASN 47288, con ámbito de tráfico Europa, política de peering abierta, siete instalaciones y tres conexiones de intercambio.La descripción general de AS47288 de RIPEstatidentifica al titular como FIXNET Telekomunikasyon Limited Sirketi y marca el ASN como anunciado.El estado de enrutamiento de RIPEstat para AS47288vio actividad IPv4 e IPv6 en vivo el 2026-07-12, con 18 prefijos IPv4 y un prefijo IPv6 en el espacio anunciado en la capa de estado de enrutamiento.
Esto no prueba que FixNET opere los servicios de cliente de TSBG. Lo que demuestra es que la conexión pública de instalación de PeeringDB no debe ser leída casualmente como presencia de AS43112. Para un comprador, esa distinción es central. Si TSBG vende colocación en una instalación donde el ASN de otro operador es la conexión de red visible, el contrato debe explicar si TSBG, FixNET, otro operador o el cliente proporciona el servicio de Internet por defecto.
Si TSBG vende VPS o servidores dedicados utilizando conectividad upstream en lugar de su propia ruta AS43112 visible, el cliente debe saber quién puede cambiar el enrutamiento, quién abre tickets de upstream y cuyo calendario de mantenimiento afecta la accesibilidad.
La cuestión del límite del operador no es académica. Durante un incidente, el primer respondedor puede ser el soporte de TSBG, el propietario de la instalación, un operador, un proveedor de manos remotas o el proveedor de red. El cliente necesita la cadena de escalación antes del fallo. Un registro de instalación que nombra a TSBG y un registro de red que nombra a AS47288 pueden ser ciertos ambos, mientras que dejan al cliente expuesto si el contrato de servicio no asigna los roles con claridad.
La economía del rack determina cuánto del servicio es real
TSBG publica precios de colocación y paquetes de rack inusualmente detallados. Lapágina de servicio de colocaciónenumera una unidad de rack, un cuarto de rack, medio rack y rack completo, con asignaciones de potencia y características de rack opcionales. La página también dice que TSBG puede proporcionar 48 VDC como opción estándar, alimentación A/B desde salas de energía y sistemas UPS separados, medidores de potencia y conmutadores ATS bajo pedido, monitorización, soporte 24/7 y acceso a Internet. Esto da a los clientes un carrito de compras visible para un servicio de instalación que normalmente se oculta detrás de llamadas comerciales.
El peligro es que el precio visible del rack no es lo mismo que la capacidad resiliente utilizable. Una sola unidad de rack con 35 W es una dependencia muy diferente de un rack completo con 1500 W. Un cliente que utiliza equipos de telecomunicaciones puede necesitar alimentación de CC, PDU duales y acceso de manos remotas; un cliente que utiliza computación puede necesitar más potencia, refrigeración y sustitución de hardware.
Una lista de precios no puede mostrar si la energía de reserva está reservada, si el trabajo de cross-connect es rápido, si las manos remotas pueden cambiar un dispositivo durante una tormenta regional, o si la ruta de red restante puede transportar tráfico cuando un proveedor está fuera de servicio.
La economía del pequeño proveedor es importante aquí. TSBG dice abiertamente en su sitio que no es el mayor operador de centros de datos y que no tiene megavatios de potencia ni terabits por segundo de capacidad de Internet. Esa honestidad es útil. Indica a los compradores que busquen adecuación, no un teatro de escala. Un sitio pequeño puede ser exactamente adecuado para un negocio local, un proyecto de telecomunicaciones de ruta fronteriza, un armario de recuperación ante desastres o un servicio balcánico de baja latencia.
También puede ser inadecuado para una carga de trabajo que asume fondos de repuesto de hiperescala, APIs de cloud globales o sustitución instantánea de hardware.
Por lo tanto, el comprador debe traducir las etiquetas de los paquetes en matemáticas de fallos. Si falla una fuente de alimentación de un armario, ¿tiene el equipo del cliente fuentes de alimentación duales y PDU duales? Si falla un switch top-of-rack, ¿están ambos NIC del servidor cableados a switches independientes? Si un upstream está caído, ¿tiene el otro camino suficiente compromiso de pago? Si se pierde un centro de datos, ¿son utilizables las copias de seguridad sin el sitio perdido? Si una persona de soporte debe viajar a un sitio remoto, ¿cuál es el reloj de reparación real?
La economía del rack se convierte en economía del riesgo una vez que comienza un fallo.
Los VPS y los servidores dedicados heredan todas las capas inferiores
Las páginas de VPS y servidores dedicados de TSBG son lo suficientemente detalladas como para mostrar de dónde proviene el valor para el cliente. Lapágina de servidores clouddice que los planes VPS se basan en Proxmox, utilizan hardware redundante, almacenamiento RAID10, red redundante y servidores host con fuente de alimentación redundante, Internet compartido de 1 Gbit/s y copias de seguridad opcionales. Enumera planes desde uno pequeño de 512 MB de RAM hasta planes más grandes de múltiples núcleos. Lapágina de servidores dedicadosdice que los servidores tienen fuentes de alimentación redundantes, RAID 1 o RAID 10, controladoras RAID por hardware, dos controladores de red y diferentes switches top-of-rack. También menciona instalación gratuita de SO, monitorización, helpdesk 24/7 y manos remotas.
Esas características son significativas. También crean una agenda de verificación. Un cliente que alquila capacidad VPS debe preguntar si RAID10 es local a un host, compartido en un clúster de almacenamiento, replicado en otro sitio o respaldado fuera de banda. Debe preguntar si la copia de seguridad opcional se almacena en la misma instalación, si la velocidad de restauración está medida y si las copias de seguridad incluyen imágenes del sistema, datos a nivel de archivo, metadatos y estado del panel de control. Debe preguntar qué sucede cuando la máquina host falla y si la migración en vivo está disponible.
Debe preguntar si la contención de recursos puede estrangular la recuperación cuando muchos clientes se ven afectados a la vez.
Un cliente de servidor dedicado tiene un problema diferente. Las fuentes de alimentación redundantes ayudan solo si cada fuente llega a una ruta de alimentación independiente. Dos controladores de red ayudan solo si están cableados a switches independientes y enrutados a través de capacidad upstream independiente. RAID protege contra un fallo de disco, pero no contra un error del controlador, una reconstrucción errónea, ransomware o un evento total del sitio. Las manos remotas gratuitas son útiles solo si las piezas están almacenadas y el personal puede entrar en la instalación rápidamente.
La brecha de ruta pública hace que estas preguntas sean más importantes. Si AS43112 no es visible actualmente, el servicio de Internet orientado al cliente de TSBG puede depender de rutas asignadas por el proveedor, un socio de tránsito, otro ASN o un diseño privado no visible en los recolectores públicos. Ese acuerdo puede ser perfectamente legítimo. Simplemente debe ser revelado al cliente que está comprando "acceso a Internet" como parte de un plan de servidor. El cliente necesita saber qué borde falla cuando falla el operador.
Las afirmaciones de potencia, refrigeración y monitorización necesitan evidencia probada
Las páginas de instalaciones se apoyan fuertemente en la potencia y la monitorización. TSBG dice que la energía del centro de datos está diseñada en una configuración A/B completamente diversificada, comenzando desde salas de energía, tableros de distribución, sistemas UPS y cableado a racks separados. Dice que cada rack tiene dos o más PDU, una para el circuito A y otra para el circuito B. Dice que el aire acondicionado utiliza una configuración redundante 1+1 o n+1, y que las salas de equipos se mantienen alrededor de 22 grados C con una humedad relativa entre el 40% y el 60%.
Dice que la detección de incendios utiliza un sistema de muestreo de aire y supresión por gas. Dice que la monitorización cubre un amplio conjunto de parámetros ambientales, del servidor, de puertos y de la red óptica.
Esos son exactamente los dominios adecuados para publicar. La cuestión es si las afirmaciones se prueban al mismo nivel en que los clientes dependen de ellas. La alimentación A/B no se demuestra con dos cables si ambos circuitos dependen de un panel upstream, un acuerdo de combustible o un proveedor de mantenimiento. La redundancia de refrigeración no se demuestra con la capacidad nominal si un pasillo caliente, un fallo del sensor o un cambio en el flujo de aire pueden eliminar el margen. La monitorización no se demuestra teniendo sensores si la propiedad de las alertas, los umbrales y los permisos de emergencia no están claros.
El contenido del blog de TSBG da pistas útiles sobre la seriedad operativa. Lapublicación sobre el mantenimiento del generador diéselhabla sobre el aceite, los filtros, el refrigerante, las baterías y la preparación para el invierno. Lapublicación sobre la monitorización de la temperaturahabla sobre SNMP, Zabbix, sensores de un solo cable, monitorización distribuida y diseño de alarmas. Lapublicación sobre la ubicación del edificio del centro de datoshabla sobre la selección del sitio, los riesgos de desastres, la construcción de hormigón, el diseño del techo y el acceso a las telecomunicaciones. Estas publicaciones no son certificaciones, pero muestran una familiaridad con el dominio que es más específica que el texto genérico de hosting.
El siguiente paso del cliente debe ser la evidencia, no la admiración. Preguntar por la fecha de la última prueba del generador, la carga probada, la autonomía del combustible, la evidencia de mantenimiento de los UPS, la evidencia de mantenimiento del sistema contra incendios, el plan de respuesta ante fallos de refrigeración, una muestra de la escalación de la monitorización y las notas posteriores a cualquier incidente real. Preguntar si los cuatro sitios tienen la misma madurez. Preguntar qué sitio aloja el servicio específico del cliente. Preguntar qué falla de forma conjunta.
Así es como el lenguaje amplio sobre instalaciones se convierte en garantía operativa.
La resiliencia de la red depende de contratos upstream, no solo de un ASN
Las propias páginas de TSBG dicen que la empresa ejecuta su propio sistema autónomo y tiene sesiones BGP con proveedores cuidadosamente seleccionados. Los registros RIPE identifican AS43112, y las observaciones de whois de RIPE mencionan upstreams y centro de datos, con una importación de AS47964 y una exportación a AS47964.La consistencia de enrutamiento AS de RIPEstatmostró 193.3.63.0/24 en whois de RIPE pero no en BGP el 2026-07-12, y mostró la importación/exportación AS47964 en whois pero no en BGP.Los vecinos ASN de RIPEstat para AS43112no mostraron vecinos observados en la fecha de publicación.
Esa combinación le dice al comprador que separe tres cosas. La primera es la intención del registro: el ASN, el objeto de ruta, la ROA y las relaciones whois muestran lo que el operador está preparado o autorizado a hacer. La segunda es el enrutamiento en vivo: los recolectores públicos muestran si la ruta es actualmente visible y a través de quién. La tercera es el enrutamiento del servicio: la carga de trabajo de un cliente puede usar un upstream o un plan de direcciones diferente no obvio solo por el ASN de TSBG. La resiliencia depende de la tercera, pero el registro público ilumina principalmente las dos primeras.
La evidencia de PeeringDB AS47288 también es útil sin ser sobreinterpretada. FixNET, la red AS47288 conectada al registro de instalación de TSBG Hosting, estaba activa enel estado de enrutamiento de RIPEstaty tenía conexiones de intercambio de PeeringDB en NetIX, TurkIX Sofia y RegPEX. Eso muestra una superficie de red cercana activa vinculada al registro de la instalación. No prueba que el tráfico del cliente de TSBG use esa superficie, que TSBG la controle o que sea lo suficientemente diversa para un cliente determinado.
La prueba del cliente es sencilla. Pedir a TSBG que identifique los ASN, los prefijos y los upstreams que transportarán el servicio contratado. Preguntar si esas rutas son capaces de ser la ruta por defecto, si usan entradas físicas separadas, si terminan en el mismo par de routers, si los filtros de ruta están actualizados y si la Validación de Origen de Ruta está configurada. Comparar la respuesta con herramientas públicas comoBGP.tools para AS43112,Hurricane Electric para AS43112,Cloudflare Radar routing para AS43112y RIPEstat. Si el ASN público está intencionadamente silencioso, eso es aceptable solo si la ruta de servicio en vivo está documentada.
El soporte es parte del activo, no una página de ayuda
TSBG destaca repetidamente el soporte. El sitio menciona soporte de helpdesk 24/7, manos remotas, correo electrónico, mensajería Viber y WhatsApp, monitorización y asistencia gratuita para la sustitución de hardware. En un servicio de hosting o colocación, el soporte no es un extra suave. Es el canal a través del cual las dependencias invisibles se convierten en acciones de reparación. Un router puede ser redundante, pero alguien aún tiene que identificar qué ruta está rota. Una matriz de discos puede estar protegida, pero alguien tiene que decidir si reconstruir, restaurar o conmutar por error.
Un cliente puede ser dueño del servidor, pero las manos remotas pueden ser la única forma de pulsar un botón, volver a colocar una tarjeta o leer una consola.
La cuestión del soporte es particularmente importante para un proveedor más pequeño con varios sitios geográficamente dispersos. Las propias páginas de TSBG dicen que el equipo es pequeño pero eficiente, y que los socios seleccionados ayudan con el trabajo y el mantenimiento necesarios. Eso puede ser una fortaleza cuando el cliente necesita una atención directa flexible. Puede convertirse en una debilidad si un incidente afecta a varios clientes, un sitio requiere acceso físico y las mismas personas se encargan de la monitorización, la comunicación, el hardware y la escalación con los proveedores.
Por lo tanto, los clientes deben contratar el soporte como infraestructura. Deben preguntar qué cuenta como una emergencia, quién puede declararla, qué canal de respuesta funciona si el portal está caído, si la escalación telefónica o por mensajería está garantizada, si las manos remotas tienen límites de tiempo y si las piezas se almacenan en el sitio. Deben preguntar si un cliente de colocación puede autorizar el trabajo con antelación. Deben preguntar si un cliente de VPS obtiene ayuda de restauración durante un incidente de la plataforma o solo soporte al mejor esfuerzo.
Deben preguntar si el registro de soporte nombra el sitio, upstream, rack o capa de servicio afectados, en lugar de solo describir una interrupción genérica.
La facturación pertenece a la misma categoría. Un servicio puede fallar por una cuenta inhabilitada, un plazo de servicio vencido, un panel de control bloqueado o una responsabilidad poco clara por el tráfico adicional. Un cliente que utiliza TSBG para un pequeño sitio de recuperación ante desastres debe asegurarse de que el contacto, la facturación, la renovación y el acceso fuera de banda sigan estando disponibles durante el evento exacto que hace necesario el sitio de recuperación.
La localidad de los datos no se resuelve con una etiqueta búlgara
La región de asignación es BG, y la propia historia de TSBG es fuertemente búlgara. La empresa está constituida en Bulgaria, enumera una oficina en Sofía, describe sitios búlgaros y comercializa Bulgaria como una ubicación estratégica de tránsito de telecomunicaciones. Para los clientes con necesidades de conectividad europea, balcánica, hacia Turquía o hacia Oriente Medio, esa es una afirmación de posicionamiento significativa. Puede reducir la latencia, mantener el equipo bajo una relación de proveedor búlgaro y proporcionar una alternativa a las regiones de cloud más grandes de Europa Occidental.
Pero la soberanía de los datos no es solo un código de país. Un cliente debe identificar dónde residen los datos primarios, las copias de seguridad, los registros, los registros del panel de control, los tickets de soporte, los datos de monitorización y los registros de facturación. Un plan VPS podría colocar el disco virtual en una instalación búlgara y la copia de seguridad en otra. Un plan de hosting compartido podría usar herramientas cPanel, servicios de certificados de terceros y DNS externo.
Un servicio de streaming podría ingerir la señal de rutas satelitales o terrestres y entregarla a través de una mezcla de tránsito local e internacional. Un cliente de colocación podría ser dueño del hardware pero depender de TSBG para el acceso remoto y el servicio IP.
Las páginas públicas de TSBG no publican una matriz de colocación completa. Dicen que la empresa opera varios centros de datos en Bulgaria, que los sitios están geográficamente dispersos y que puede proporcionar enlaces protegidos a Estambul, Sofía, Bucarest y redes europeas. Esos son buenos datos de partida. No responden si una copia de seguridad específica cruza fronteras, si un proveedor de soporte puede acceder a los sistemas del cliente, si los registros se conservan en un sistema separado, o cómo un cliente recibe una copia utilizable de los datos durante una disputa o interrupción.
La portabilidad de los datos es, por lo tanto, parte de la revisión de resiliencia. Un comprador debe probar cómo abandonar el servicio. Para el hosting compartido, ¿puede el cliente recuperar archivos, buzones de correo, registros DNS, bases de datos y registros TLS de forma limpia? Para VPS, ¿puede exportar una imagen o solo archivos? Para servidores dedicados, ¿está disponible el acceso a la consola remota si la red es inestable? Para la colocación, ¿quién controla la renumeración IP, la liberación del cross-connect y la retirada del hardware? El mejor momento para probar la portabilidad es antes de que el servicio se vuelva crítico.
Las señales no oficiales pueden sugerir pistas, no conclusiones
Los sujetos de infraestructura con poca información a menudo dejan rastros en agregadores comerciales, páginas antiguas de BGP, páginas de precios, resultados de búsqueda, publicaciones en foros, perfiles sociales y directorios de instalaciones. TSBG no es una excepción. Los agregadores de enrutamiento público comola página AS43112 de IPinfo,BGP.tools,Hurricane ElectricyCloudflare Radarson útiles para una comprobación cruzada rápida. PeeringDB es útil para pistas de instalaciones e interconexión. El sitio oficial es útil para las afirmaciones de servicio y la información de contacto.
Esas señales no deben tratarse por igual. RIPE RDAP y RIPEstat son sólidos para la identidad de los recursos numéricos y la observación de rutas públicas. PeeringDB es valioso pero autogestionado y puede estar desactualizado. El sitio oficial es autoritativo para lo que TSBG dice que vende, pero no es una prueba independiente de que un rack, una ruta de fibra o una copia de seguridad determinados existan hoy. Las páginas de los agregadores son buenas para la triangulación, pero pueden estar desactualizadas o representar los datos de manera diferente. Las publicaciones del blog muestran pensamiento técnico, no un certificado operativo en vivo.
La distinción es más importante cuando la evidencia pública entra en conflicto. Las páginas de servicio oficiales de TSBG dicen repetidamente que la empresa ejecuta su propio AS con sesiones BGP. Los registros RIPE identifican AS43112 y existe una ROA válida para 193.3.63.0/24. Sin embargo, RIPEstat no vio a AS43112 anunciado en la fecha de publicación. Eso no es algo que se deba suavizar. Es el hallazgo principal. O bien el ASN público está actualmente inactivo, o los servicios actuales se entregan a través de otra ruta de red, o los recolectores públicos no detectaron un anuncio limitado.
Cada posibilidad tiene consecuencias diferentes para el cliente.
¿Qué lo resolvería? Una vista actual del looking-glass de TSBG, una tabla de rutas que muestre los prefijos de los clientes, una lista de upstreams, una IP de prueba para el servicio contratado, un resultado de traceroute y diversidad de rutas, una página de estado actual, una descripción del servicio específica de la instalación y un lenguaje contractual que nombre a las partes responsables. Hasta que eso esté disponible, la postura editorial correcta es la cautela.
Cómo un comprador debería probar TSBG antes de colocar una carga de trabajo crítica
La primera prueba es la identidad y la adecuación del servicio. Pedir a TSBG que confirme qué entidad jurídica firma el contrato, qué sitio alojará el servicio, qué capa de producto se aplica y si el servicio utiliza AS43112, AS47288, un bloque de direcciones de proveedor de tránsito u otro acuerdo de enrutamiento. Comparar la respuesta conRIPE RDAP para AS43112,RIPE RDAP para 193.3.63.0/24y las observaciones BGP públicas. Si la respuesta es que el ASN público no se utiliza actualmente, preguntar por qué y qué lo reemplaza.
La segunda prueba es la prueba de las instalaciones. Para la colocación, preguntar por el nombre del sitio, la posición del rack, el diseño de la alimentación, el consumo máximo, las opciones de cross-connect, las condiciones de las manos remotas, el procedimiento de acceso y las reglas de notificación de mantenimiento. Para VPS o servidores dedicados, preguntar qué instalación aloja el hardware, si el sitio de recuperación está activo, si las copias de seguridad están fuera del host fallido y si la capacidad está reservada para la conmutación por error. Pedir un resultado reciente de una prueba de potencia, refrigeración o generador. Lapágina de centros de datosde TSBG da una lista sólida de dominios de instalaciones; el cliente necesita la versión específica del sitio.
La tercera prueba es la independencia de la red. Preguntar por los upstreams actuales, los filtros de ruta, el estado RPKI, la diversidad de entrada física, la velocidad de la interfaz, el compromiso de pago, la exposición a DDoS y el comportamiento de conmutación por error. Preguntar si la afirmación de conectividad a Internet del 99.999% se aplica al producto del cliente y cómo se calculan los créditos. Utilizar herramientas públicas para comprobar si el estado del ASN y del prefijo coinciden con la respuesta, pero no depender solo de las herramientas públicas si el servicio utiliza una ruta privada o de un socio.
La cuarta prueba es la recuperación. Realizar una pequeña restauración. Exportar una imagen VPS o reconstruir a partir de la copia de seguridad. Pedir a las manos remotas que realicen una tarea de consola o de inventario no disruptiva. Probar el contacto fuera de banda. Confirmar quién puede autorizar cambios de emergencia. Confirmar si un bloqueo de cuenta, una factura impagada, un problema de dominio o una disputa sobre el derecho al soporte puede detener el trabajo de recuperación. El material público describe a un operador pequeño capaz; el trabajo del cliente es demostrar esa capacidad bajo su propio escenario de fallo.
Quién se ve afectado cuando el sistema falla
La población afectada depende del producto de TSBG que el cliente compre. Un cliente de hosting compartido está expuesto a fallos a nivel de plataforma: cPanel, DNS, correo, almacenamiento y la vía de soporte del proveedor. Un cliente de VPS está expuesto a los dominios del host, almacenamiento, red y copia de seguridad. Un cliente de servidor dedicado está expuesto al stock de hardware, al borde de la red, a las fuentes de alimentación, a las manos remotas y a cualquier capa de servicio gestionado.
Un cliente de colocación es dueño de más partes de la pila, pero sigue dependiendo de TSBG para la alimentación, la refrigeración, la seguridad física, el acceso remoto y, a veces, el tránsito a Internet.
Para un negocio local, el fallo puede significar tiempo de inactividad del sitio web o del correo electrónico. Para un operador de telecomunicaciones o TI que utiliza espacio en rack, el fallo puede afectar a los clientes posteriores, la monitorización, el backhaul, un sistema de antena o un plan de recuperación ante desastres. Para un cliente de medios o streaming, el fallo puede interrumpir la entrega a la audiencia. Para una empresa que utiliza un sitio búlgaro como alternativa a una región de cloud más grande de Europa Occidental, el fallo puede eliminar la misma redundancia geográfica que el cliente pretendía comprar.
La superficie de soporte también crea efectos de segundo orden. Si la misma persona de contacto se encarga de las ventas, el soporte y la escalación técnica, los clientes pueden recibir atención personalizada durante las operaciones normales y una respuesta lenta durante un evento amplio. Si interviene una vía de proveedor, TSBG puede depender del reloj de reparación de otro operador. Si el servicio utiliza una ruta no visible bajo AS43112, los clientes pueden monitorizar el borde público equivocado y no detectar el dominio de fallo real.
Por eso la conclusión del artículo no es "evitar TSBG", sino "no compre la abstracción sin mapear las dependencias". El material público de TSBG es inusualmente operativo para un proveedor pequeño. La prueba que falta es la accesibilidad actual y la conmutación por error probada para la ruta específica del cliente.
El grado de evidencia
TSBG Hosting Ltd. obtiene un grado de evidencia de red Débil para este artículo. La calificación no es un juicio sobre la satisfacción del cliente o la habilidad de ingeniería. Es un juicio sobre lo que la evidencia pública puede probar el 2026-07-12. El sitio oficial presenta afirmaciones de servicio sólidas y específicas de la empresa: cuatro centros de datos, colocación, VPS, servidores dedicados, hosting compartido, alimentación A/B, monitorización, manos remotas, seguridad, detección de incendios, refrigeración y posicionamiento de tránsito búlgaro.
Los registros RIPE dan una identidad real de recursos numéricos de TSBG: AS43112, ORG-THL32-RIPE y 193.3.63.0/24. RPKI valida la autorización de origen de 193.3.63.0/24 para AS43112.
La degradación proviene del borde actual. RIPEstat no vio a AS43112 anunciado, no vio prefijos actuales de AS43112 y no vio vecinos actuales de AS43112. La entrada de instalación de TSBG Hosting en PeeringDB añade una pista física, pero su conexión de red visible apunta a AS47288/FixNET en lugar de a AS43112. Eso puede representar un acuerdo de socio o upstream válido; no prueba de forma independiente el enrutamiento en vivo de los clientes de TSBG.
La conclusión práctica es limitada. TSBG parece ser un operador real de hosting y colocación búlgaro con afirmaciones detalladas de infraestructura física. Un comprador debe tratar esas afirmaciones como comprobables, no como resueltas. Antes de colocar cargas de trabajo críticas, debe obtener evidencia de ruta actual, evidencia de instalaciones específicas del sitio, límites de upstream y soporte, evidencia de copia de seguridad o migración probada, y un mapa escrito de quién restaura el servicio cuando se produce un fallo en el rack, el upstream, el stock de hardware, el soporte, la facturación, la migración o el contrato con el proveedor.