En esta página
Puntos clave
- Describa el servicioPrefijos, protocolos, picos normales y condiciones operativas permiten comparar presupuestos.
- Separe las capacidadesEl transporte, el procesamiento de paquetes y la conexión entregada tienen límites distintos.
- Acuerde la aceptaciónDefina observaciones, escenarios de fallo y responsabilidades de recuperación antes de activar el servicio.
Utilice los mismos requisitos para todas las propuestas
Una solicitud útil empieza por lo que debe seguir disponible. Indique servicios, familias de direcciones, prefijos o extremos públicos protegidos, tráfico habitual en hora punta y procedencia de los usuarios. Aclare si controla un ASN y prefijos, si puede cambiar el enrutamiento y qué organización opera el servidor final. Así el proveedor distinguirá protección de red, proxy específico de un protocolo y software de filtrado en sus equipos.
Mantenga breve el primer intercambio. Para una revisión inicial bastan el tipo de servicio, tráfico aproximado, condiciones de entrega y un contacto. Las políticas de enrutamiento, el inventario y las evidencias de incidentes pueden seguir por un canal acordado. Credenciales, claves privadas y capturas de clientes sin anonimizar no corresponden a un formulario público.
| Requisito | Información útil | Pregunta al proveedor |
|---|---|---|
| Direccionamiento y enrutamiento | ASN, prefijos autorizados, IPv4/IPv6 y proveedores actuales. | ¿Qué puede anunciar y qué se valida antes de la entrega? |
| Tráfico y aplicaciones | Gbit/s y Mpps normales, comportamiento de conexiones y protocolos necesarios. | ¿Qué funciones cubren esta carga y cuáles no? |
| Entrega | Túnel o conexión física, ubicación y condiciones del retorno. | ¿Qué ancho de banda, MTU y parámetros de enrutamiento corresponden a cada camino? |
| Operación | Responsables de routers, servidores, monitorización y guardias. | ¿Quién cambia políticas, confirma la recuperación y revierte una modificación fallida? |
Asocie cada cifra de capacidad a su límite
Una cifra de absorción de red compartida no reserva recursos en su circuito. Un benchmark de servidor no representa todas las configuraciones licenciadas. Una interfaz de 100 Gbit/s no demuestra que el host procese paquetes mínimos con las reglas propuestas. Pregunte dónde se midió el valor, en qué dirección, con qué tráfico y si el límite es físico, licenciado, compartido o contractual.
Si una oferta indica rendimiento, pida la convención de tamaño de trama, tasa de paquetes, distribución del tráfico, funciones activas, hardware y versión de software. Reenviar tramas grandes no demuestra capacidad de filtrado de paquetes pequeños. Tampoco puede deducirse el rendimiento de una cola de recepción a partir del uso medio de CPU. Son preguntas para comparar, no razones para descartar toda una categoría de hardware o software.
Dibuje el tráfico normal, protegido y de retorno
El diagrama debe mostrar dónde se observa el tráfico, dónde se desvía, dónde se descarta y cómo llega el resto al servicio. Incluya el retorno. Una función que comprueba estado puede necesitar ambas direcciones en la misma instancia o una sincronización de estado compatible. Un colector de rutas, un controlador de desvío y un filtro en línea no son componentes intercambiables.
Para una entrega redundante, identifique routers, enlaces, alimentación y upstreams compartidos. Dos túneles pueden usar direcciones diferentes y terminar en el mismo router. Pregunte qué ocurre ante el fallo de una sesión, interfaz o equipo completo. Un respaldo se valida por el ámbito de fallo probado, no por el número de indicadores BGP verdes.
Prepare un plan de aceptación con el proveedor
Elija condiciones de aceptación medibles para su aplicación. Una ruta instalada o un contador de ataques creciente aportan evidencia, pero no demuestran que los usuarios completen sus operaciones. Registre conexiones fallidas, tiempo de respuesta y tráfico esperado junto con los contadores de mitigación.
No ejecute benchmarks de laboratorio que perturben una red de producción. RFC 6815 explica por qué los supuestos de RFC 2544 no encajan en una red compartida en servicio. La aceptación operativa requiere un procedimiento acordado y acotado; la carga destructiva corresponde a un entorno separado.
Compruebe el funcionamiento normal
Registre éxito de la aplicación, latencia, selección de rutas y contadores antes de cambiar la protección.
Pruebe el camino entregado
Verifique familias de direcciones, intercambios pequeños y grandes, comportamiento de MTU y ambas direcciones.
Valide el filtrado en un entorno aislado
Acuerde tráfico autorizado, umbrales y comportamiento legítimo esperado en un entorno de pruebas aislado.
Pruebe la recuperación
Compruebe retirada de rutas, reenvío por respaldo, retorno al camino preferido y responsable de cada reversión.
Lea las condiciones operativas con tanto cuidado como las funciones
Pregunte qué incluye la cuota mensual, qué genera exceso, qué estadísticas se usan y cómo se define el periodo de facturación. Separe tráfico comprometido, velocidad de acceso, ráfagas, direcciones protegidas, capacidad de software y soporte opcional. Un percentil, un pico muestreado y la velocidad de puerto describen cosas distintas.
Un SLA debe identificar servicio cubierto, punto de medición, exclusiones y compensación. Un plazo de respuesta de soporte no garantiza automáticamente la restauración. Pida el proceso de escalado, aprobación de filtros urgentes, tratamiento de falsos positivos y evidencias posteriores. Estos puntos deben constar en la oferta o contrato; un distintivo comercial no los establece.
Compare modelos de despliegue equivalentes
Compare un servicio de red gestionado con su entrega y alcance operativo; compare una licencia con los servidores, interfaces, transporte y personal que necesita. Un precio de componente puede ser razonable y cubrir solo una parte del recorrido. Mantenga detección, orquestación, aplicación del filtrado y capacidad de red en columnas distintas para ver cualquier capa ausente.
En Peeryx, Transit IP protegido, Defense Fabric y Flow Collector cumplen funciones diferentes. Defense Fabric licencia el filtrado en un despliegue compatible; no incluye una asignación dedicada de la capacidad compartida de Peeryx. Flow Collector observa telemetría y puede controlar desvíos autorizados; no filtra paquetes en línea. La entrega Gaming requiere revisar la aplicación compatible.
Anote lo desconocido antes de aprobar la compra
Para cada requisito, registre respuesta del proveedor, documento de apoyo, prueba de aceptación y condición pendiente. Marque como desconocida una medición ausente en lugar de convertirla en una estimación de rendimiento. Así quedan visibles los trabajos técnicos pendientes y ambos equipos disponen de una entrega útil tras la venta.
Un pequeño piloto autorizado puede resolver una cuestión concreta de compatibilidad. No demuestra capacidad ilimitada, todas las familias de ataque ni todos los escenarios de recuperación. Lleve las condiciones no probadas al acta de aceptación en producción, sin tratar implícitamente un piloto satisfactorio como validación completa.
Preguntas antes de firmar
¿Una cifra anunciada de Tbit/s mayor siempre es mejor?
Puede describir más capacidad compartida, pero no establece el ancho de banda entregado, los recursos reservados, la carga de paquetes ni la cobertura de aplicaciones. Compare esos puntos por separado.
¿Qué debe contener una primera consulta mínima?
Indique servicio, tráfico normal, direcciones o modelo de enrutamiento y principal condición de entrega. Añada el inventario detallado tras acordar el alcance inicial.
¿Una prueba sustituye al plan técnico de aceptación?
No. Puede validar condiciones definidas. Las evidencias, escenarios de fallo e incógnitas restantes siguen necesitando documentación.
