UZA Networks operates an eyeball broadband network (FTTH and fixed wireless) in northeastern Guanajuato, Mexico. We keep an open peering policy at Internet exchanges and evaluate private interconnects case by case. Our PeeringDB record is the authoritative source for facilities, IX presence, prefix counts and contacts; this document covers what PeeringDB does not.
1. Quick facts
ASN
AS270160
AS-SET
RADB::AS270160:AS-CONE (also mirrored in LACNIC IRR)
We accept every bilateral session request at PIT MX and we peer with both route servers. Content and CDN networks: please set up bilateral sessions with us in addition to the route servers. Direct sessions let us size per-peer limits for you and give you control over what you announce to us.
2.2 Private interconnection — KIO Querétaro 1 (QRO1)
Ports: 10G (LR) or 100G (LR4), single-mode. Two ports on separate line cards are available for redundancy on request.
We currently operate PNIs at QRO1 with Google (AS15169) and Meta (AS32934), 100G each.
PNI is considered when mutual traffic reaches 1 Gbps sustained, or when an IX path is not available for the network.
Cross-connects: each party covers the cost on its side of the meet-me room.
Process: PeeringDB-verified request → LOA exchanged → cross-connect ordered → BGP turn-up. Typical time from LOA to session up: 10 business days.
3. Peering requirements
We ask peers to meet the following. We meet them ourselves.
A current and accurate PeeringDB record, including an IRR AS-SET.
Route objects for all announced prefixes in an IRR mirrored by NTT/RADb (RIPE, ARIN, APNIC, LACNIC, AFRINIC, RADB, ALTDB…), reachable from the AS-SET published in PeeringDB. Downstream customers you announce must be members of that AS-SET.
RPKI ROAs for the prefixes you originate.
A consistent set of announcements at every interconnection point, unless agreed otherwise.
No default route, no routes learned from other peers or upstreams, nothing longer than /24 (IPv4) or /48 (IPv6).
A 24×7 NOC contact that can act on routing incidents.
Dual-stack: IPv4 and IPv6 sessions on the same interconnection.
MD5 is optional and available on request.
4. Routing and filtering
What we announce. Our own address space and the space of our BGP customers, exactly as described by RADB::AS270160:AS-CONE, with identical announcements at every point of interconnection. Every prefix we originate is covered by a valid ROA. Set your max-prefix for our sessions to 1000 IPv4 / 500 IPv6 (published in PeeringDB); today we announce 9 and 3.
How we filter what you send us.
Max-prefix is set from your PeeringDB record plus headroom. Reaching the limit tears down the session; it is restored automatically after an idle period.
Rejected unconditionally: default routes, bogons and private space, our own prefixes, private or reserved ASNs in the path, prefixes longer than /24 or /48, and routes whose AS-path traverses our upstream carriers (we do not accept transit paths over peering).
Routing security.
All our prefixes are ROA-signed (LACNIC TAL) and all route objects are registered in RADB; our own LACNIC resources are also registered in LACNIC IRR.
BCP38 source-address validation is enforced on every customer-facing interface.
We honour the GRACEFUL_SHUTDOWN well-known community (RFC 8326) on peer sessions: routes tagged 65535:0 are depreferenced before you take a session down.
5. Embedded cache hosting
We host embedded caches from content networks at our aggregation sites. This is a factual description of what is available; qualification depends on each program's own thresholds.
Provided with every deployment: dedicated IPv4 and IPv6 addressing, cache-fill capacity over our transit, remote hands at our sites, and 24×7 NOC. Requests to peering@uza.mx with the program's requirements; we answer with site data within 5 business days.
6. Operations
Response times. Peering requests are answered within 2 business days; sessions are configured on our side within 5 business days of agreement.
Planned maintenance affecting a peer is notified at least 72 hours in advance to the contacts on the peer's PeeringDB record. Emergency changes are notified within 1 hour after the event.
Incidents.noc@uza.mx and +52 442 492 4665, 24×7. Please include the session addresses and timestamps in UTC.
Public visibility. Our routes are visible in the usual public collectors (RIPE RIS, RouteViews) and in the Qrator Radar collector (AS197068).
7. Network profile
Eyeball access network: FTTH (GPON) and fixed wireless in San Luis de la Paz, San José Iturbide, Victoria, Doctor Mora, Xichú and surrounding municipalities of Guanajuato.
Traffic is inbound-heavy (~90:10). Aggregate peak in the 20–50 Gbps range (2026).
Upstream transit from two carriers; content is delivered through PNIs at KIO QRO1, PIT MX peering and embedded caches.
Rewrite: quick facts, filtering practices, PNI guidelines, max-prefix values, cache hosting as a specification, response times, revision history. AS-SET published with IRR source.
1.1
2026-07-15
Added PIT MX public peering and PNI sections.
1.0
2026-05-13
First publication.
Version 2.0 · Last updated 2026-09-03
UZA Networks — Política de Peering (AS270160)
Versión 2.0 · Última actualización 2026-09-03
UZA Networks opera una red de acceso residencial (FTTH e inalámbrico fijo) en el noreste de Guanajuato, México. Mantenemos una política de peering abierta en puntos de intercambio y evaluamos interconexiones privadas caso por caso. Nuestro registro en PeeringDB es la fuente autoritativa de instalaciones, presencia en IX, conteo de prefijos y contactos; este documento cubre lo que PeeringDB no captura.
1. Datos rápidos
ASN
AS270160
AS-SET
RADB::AS270160:AS-CONE (con copia espejo en LACNIC IRR)
Aceptamos toda solicitud de sesión bilateral en PIT MX y tenemos sesión con ambos route servers. Redes de contenido y CDN: pidan sesiones bilaterales con nosotros además de los route servers. Las sesiones directas nos permiten dimensionar límites por peer y les dan control sobre lo que nos anuncian.
2.2 Interconexión privada — KIO Querétaro 1 (QRO1)
Puertos: 10G (LR) o 100G (LR4), monomodo. Dos puertos en tarjetas distintas disponibles para redundancia bajo solicitud.
Operamos PNIs en QRO1 con Google (AS15169) y Meta (AS32934), de 100G cada uno.
Se considera PNI cuando el tráfico mutuo alcanza 1 Gbps sostenido, o cuando la red no está disponible por un IX.
Cross-connects: cada parte cubre el costo de su lado del meet-me room.
Proceso: solicitud verificada en PeeringDB → intercambio de LOA → orden de cross-connect → activación BGP. Tiempo típico de LOA a sesión arriba: 10 días hábiles.
3. Requisitos de peering
Pedimos a los peers lo siguiente. Nosotros lo cumplimos.
Registro en PeeringDB vigente y exacto, incluyendo un AS-SET de IRR.
Route objects de todos los prefijos anunciados en un IRR replicado por NTT/RADb (RIPE, ARIN, APNIC, LACNIC, AFRINIC, RADB, ALTDB…), alcanzables desde el AS-SET publicado en PeeringDB. Los clientes downstream que anuncien deben ser miembros de ese AS-SET.
ROAs RPKI para los prefijos que originan.
Anuncios consistentes en todos los puntos de interconexión, salvo acuerdo distinto.
Sin ruta default, sin rutas aprendidas de otros peers o upstreams, nada más largo que /24 (IPv4) o /48 (IPv6).
Un contacto de NOC 24×7 con capacidad de actuar ante incidentes de enrutamiento.
Doble pila: sesiones IPv4 e IPv6 sobre la misma interconexión.
MD5 opcional, disponible bajo solicitud.
4. Enrutamiento y filtrado
Qué anunciamos. Nuestro espacio propio y el de nuestros clientes BGP, exactamente como lo describe RADB::AS270160:AS-CONE, con anuncios idénticos en todos los puntos de interconexión. Cada prefijo que originamos está cubierto por una ROA válida. Configuren el max-prefix de nuestras sesiones en 1000 IPv4 / 500 IPv6 (publicado en PeeringDB); hoy anunciamos 9 y 3.
Cómo filtramos lo que nos envían.
El max-prefix se toma de su registro en PeeringDB más holgura. Alcanzar el límite tira la sesión; se restablece sola tras un periodo de espera.
Se rechaza siempre: rutas default, bogons y espacio privado, nuestros propios prefijos, ASNs privados o reservados en el path, prefijos más largos que /24 o /48, y rutas cuyo AS-path pase por nuestros carriers de tránsito (no aceptamos tránsito por peering).
Seguridad de enrutamiento.
Todos nuestros prefijos están firmados con ROA (TAL de LACNIC) y todos los route objects están en RADB; nuestros recursos LACNIC también están en LACNIC IRR.
Validación de dirección origen BCP38 en toda interfaz hacia clientes.
Respetamos la comunidad conocida GRACEFUL_SHUTDOWN (RFC 8326) en sesiones de peering: las rutas marcadas 65535:0 se despriorizan antes de que bajen una sesión.
5. Alojamiento de cachés embebidos
Alojamos cachés embebidos de redes de contenido en nuestros sitios de agregación. Esta es una descripción factual de lo disponible; la calificación depende de los umbrales de cada programa.
Sitio
Ubicación
Disponible
San Luis de la Paz (SL)
Guanajuato
1 rack de 45 RU, energía A+B, uplinks 10G/100G a nuestro edge
San José Iturbide (SJI)
Guanajuato
1 rack de 45 RU, energía A+B, uplinks 10G/100G a nuestro edge
Con cada despliegue: direccionamiento IPv4 e IPv6 dedicado, capacidad de llenado de caché sobre nuestro tránsito, manos remotas en nuestros sitios y NOC 24×7. Solicitudes a peering@uza.mx con los requisitos del programa; respondemos con datos del sitio en 5 días hábiles.
6. Operación
Tiempos de respuesta. Las solicitudes de peering se contestan en 2 días hábiles; las sesiones se configuran de nuestro lado en 5 días hábiles a partir del acuerdo.
Mantenimiento planeado que afecte a un peer se notifica con al menos 72 horas de anticipación a los contactos de su registro en PeeringDB. Los cambios de emergencia se notifican dentro de la hora siguiente al evento.
Incidentes.noc@uza.mx y +52 442 492 4665, 24×7. Incluyan las direcciones de la sesión y marcas de tiempo en UTC.
Visibilidad pública. Nuestras rutas son visibles en los colectores públicos habituales (RIPE RIS, RouteViews) y en el colector de Qrator Radar (AS197068).
7. Perfil de red
Red de acceso residencial: FTTH (GPON) e inalámbrico fijo en San Luis de la Paz, San José Iturbide, Victoria, Doctor Mora, Xichú y municipios vecinos de Guanajuato.
Tráfico mayormente entrante (~90:10). Pico agregado en el rango de 20–50 Gbps (2026).
Tránsito de dos carriers; el contenido se entrega por PNIs en KIO QRO1, peering en PIT MX y cachés embebidos.
Reescritura: datos rápidos, prácticas de filtrado, lineamientos de PNI, valores de max-prefix, alojamiento de cachés como especificación, tiempos de respuesta, historial de revisiones. AS-SET publicado con fuente IRR.
