Peering Policy — UZA NETWORKS (AS270160)

Our PeeringDB record is the canonical source for ASN, AS-SET, prefixes, traffic profile, ratio, facilities, and policy summary. This page documents what PeeringDB does not capture: detailed technical requirements, routing security posture, our CDN cache hosting program, and operational practices.

Technical Requirements

• BGP-4 dual-stack (IPv4 + IPv6) on the same session pair
• Routes registered in RADB or LACNIC IRR, reachable via AS-SET AS270160:AS-CONE
• RPKI-valid routes preferred; invalids are dropped at ingress
• Max-prefix limits are agreed per session at establishment, sized to the peer's expected announcement profile, with teardown thresholds enforced
• MD5 authentication optional, supported on request
• For prefixes originated by a downstream of yours, a Letter of Authorization (LOA) is required before acceptance

Routing Security

• RPKI: all originated prefixes signed and valid in LACNIC TAL; invalids dropped at ingress
• BCP38 / source-address filtering enforced on all customer-facing interfaces
• AS-SET AS270160:AS-CONE maintained in RADB
• MANRS participation under evaluation; principles already followed operationally

CDN Cache Hosting

We actively welcome embedded content cache deployments at our edge POPs. Our facilities aggregate growing residential broadband traffic in San Luis de la Paz and San José Iturbide, Guanajuato, with additional presence at KIO Querétaro 1 (QRO1). Our infrastructure is engineered to host nodes for:

• Netflix Open Connect Appliance (OCA)
• Google Global Cache (GGC)
• Akamai AANP
• Meta FNA
• Cloudflare ECT
• Equivalents from other content networks

What we provide: Rack space, A+B power, optical uplinks to our edge (10G/100G), dedicated IPv4 + IPv6 allocations, unmetered transit for cache-fill, and 24/7 NOC support.

This is a strategic priority for us — our footprint sits outside the dense CDN hubs in CDMX/QRO, meaning embedded caches materially reduce backhaul costs and dramatically improve subscriber experience.

Contact peering@uza.mx to evaluate a deployment.

What We Do Not Do

• We do not announce or accept default routes to/from peers
• We do not provide transit via peering — peer routes are not re-announced to other peers or upstreams
• We do not accept prefixes longer than /24 (IPv4) or /48 (IPv6) unless explicitly agreed
• We do not peer over unverified layer-2 transport without prior agreement

Operational

• Planned maintenance: notified to active peers at least 72 hours in advance via peering@uza.mx
• Emergency change: post-event notification within 1 hour
• 24/7 NOC for session and reachability issues
• Looking glass: available on request to verified peers
• Public BGP visibility via the Qrator Radar collector (AS197068) and standard public collectors

Contacts

Política de Peering — UZA NETWORKS (AS270160)

Nuestro registro en PeeringDB es la fuente oficial para ASN, AS-SET, prefijos, perfil de tráfico, proporción, instalaciones y resumen de políticas. Esta página documenta lo que PeeringDB no captura: requisitos técnicos detallados, postura de seguridad de enrutamiento, nuestro programa de alojamiento de cachés de CDN y prácticas operativas.

Requisitos Técnicos

• BGP-4 dual-stack (IPv4 + IPv6) en el mismo par de sesiones
• Rutas registradas en RADB o LACNIC IRR, alcanzables a través del AS-SET AS270160:AS-CONE
• Se prefieren rutas RPKI-valid; las inválidas se descartan en el ingreso (ingress)
• Los límites de Max-prefix se acuerdan por sesión al establecerse, dimensionados al perfil de anuncios esperado del par, con umbrales de caída (teardown) aplicados
• Autenticación **MD5** opcional, soportada bajo solicitud
• Para los prefijos originados por uno de sus clientes (downstream), se requiere una Carta de Autorización (LOA) antes de su aceptación

Seguridad de Enrutamiento

• RPKI: todos los prefijos originados están firmados y son válidos en el TAL de LACNIC; los inválidos se descartan
• BCP38 / filtrado de direcciones de origen (source-address) aplicado en todas las interfaces hacia clientes
• AS-SET AS270160:AS-CONE mantenido en RADB
• Participación en MANRS bajo evaluación; los principios ya se siguen operativamente

Alojamiento de Caché CDN (Cache Hosting)

Damos la bienvenida activamente a los despliegues de nodos de caché de contenido en nuestros POPs perimetrales. Nuestras instalaciones agregan un creciente tráfico residencial de banda ancha en San Luis de la Paz y San José Iturbide, Guanajuato, con presencia adicional en KIO Querétaro 1 (QRO1). Nuestra infraestructura está diseñada para alojar nodos de:

• Netflix Open Connect Appliance (OCA)
• Google Global Cache (GGC)
• Akamai AANP
• Meta FNA
• Cloudflare ECT
• Equivalents de otras redes de contenido

Lo que proporcionamos: Espacio en rack, energía A+B, enlaces ópticos hacia nuestro borde (10G/100G), asignaciones dedicadas de IPv4 + IPv6, tránsito no medido para cache-fill, y soporte NOC 24/7.

Esta es una prioridad estratégica para nosotros — nuestra huella de red se encuentra fuera de los densos hubs de CDN en CDMX/QRO, lo que significa que los cachés integrados reducen materialmente los costos de backhaul y mejoran drásticamente la experiencia del suscriptor.

Contacte a peering@uza.mx para evaluar un despliegue.

Lo que NO hacemos

• No anunciamos ni aceptamos rutas por defecto (default routes) hacia/desde pares
• No proveemos tránsito a través de peering — las rutas de nuestros pares no se re-anuncian a otros pares ni a proveedores de tránsito
• No aceptamos prefijos más largos que /24 (IPv4) o /48 (IPv6) a menos que se acuerde explícitamente
• No hacemos peering sobre transporte de capa 2 no verificado sin acuerdo previo

Operativo

• Mantenimiento programado: notificado a los pares activos con al menos **72 horas** de anticipación vía peering@uza.mx
• Cambio de emergencia: notificación post-evento dentro de 1 hora
• NOC 24/7 para problemas de sesión y alcanzabilidad
• Looking glass: disponible bajo solicitud para pares verificados
• Visibilidad BGP pública a través del colector Qrator Radar (AS197068) y colectores públicos estándar

Contactos