buenas tardes, piden stacking en cualquier puerto y a cualquier velocidad + stacking de larga distancia, pero la compra es de 1 solo switch y notamos una incongruencia: no hay HA real con un único equipo; el stacking LD es específico de algunos fabricantes (IRF/VC/MC-LAG/VSX), no “cualquier puerto/velocidad”
buenas tardes, piden stacking en cualquier puerto y a cualquier velocidad + stacking de larga distancia, pero la compra es de 1 solo switch y notamos una incongruencia: no hay HA real con un único equipo; el stacking LD es específico de algunos fabricantes (IRF/VC/MC-LAG/VSX), no “cualquier puerto/velocidad”
El requisito de stacking en cualquier puerto y a cualquier velocidad, así como la capacidad de stacking de larga distancia, se establece para garantizar que los equipos adquiridos puedan integrarse en arquitecturas de alta disponibilidad y expansión futura, considerando posibles ampliaciones de la red y la interoperabilidad con otros switches del mismo modelo o familia. Si bien en la compra actual solo se solicita un equipo, la especificación permite que la Entidad planee futuras configuraciones redundantes sin depender de puertos o módulos específicos, y asegura compatibilidad con las tecnologías de stacking utilizadas por distintos fabricantes (IRF, VC, MC-LAG, VSX). Consideramos que es técnicamente justificado, proporcionar flexibilidad operativa futura y no limitar la participación de oferentes, permitiendo la adquisición de equipos que cumplan con los estándares de alta disponibilidad planificados. Por tanto, favor remitirse a lo establecido en el Pliego de Bases y Condiciones
2
posible obsolescencia
Buenas tardes, en cuanto a una de los puntos del item 1, exigen Telnet (incluso v6), GVRP, SLP, y un listado masivo de RFCs de capa de aplicación (SMTP/HTTP/…) las cuales no corresponden a un switch core moderno con gestión endurecida (solo SSH/HTTPS/SNMPv3).
Buenas tardes, en cuanto a una de los puntos del item 1, exigen Telnet (incluso v6), GVRP, SLP, y un listado masivo de RFCs de capa de aplicación (SMTP/HTTP/…) las cuales no corresponden a un switch core moderno con gestión endurecida (solo SSH/HTTPS/SNMPv3).
Las especificaciones técnicas incluidas, que contemplan diversos protocolos y RFCs, responden al objetivo de garantizar la compatibilidad e interoperabilidad con equipos y sistemas actualmente en operación dentro de la infraestructura institucional. Si bien algunos protocolos como Telnet, GVRP o SLP pueden considerarse obsoletos en entornos modernos, su inclusión busca asegurar la flexibilidad del equipamiento propuesto frente a distintos escenarios de integración y administración. Por tal motivo, favor remitirse a lo establecido en el Pliego de Bases y Condiciones.
3
Consulta sobre item 1 - Uplinks 100 GbE
buenos días, solicitamos amablemente a la convocante que se admita el cumplimiento con puertos de 40 GbE (QSFP+) o superiores, sin requerir de manera obligatoria los 100 GbE. Existen equipos de clase datacenter ampliamente utilizados que cuentan con 40 GbE uplinks y cumplen con todas las demás funcionalidades de alto desempeño. De esta forma se garantiza mayor concurrencia de marcas y modelos en la licitación.
buenos días, solicitamos amablemente a la convocante que se admita el cumplimiento con puertos de 40 GbE (QSFP+) o superiores, sin requerir de manera obligatoria los 100 GbE. Existen equipos de clase datacenter ampliamente utilizados que cuentan con 40 GbE uplinks y cumplen con todas las demás funcionalidades de alto desempeño. De esta forma se garantiza mayor concurrencia de marcas y modelos en la licitación.
La velocidad de 100 GbE permite asegurar el soporte adecuado para la interconexión de múltiples enlaces de agregación, la operación simultánea de servicios críticos y la proyección de crecimiento de la red institucional. Por tal motivo, favor remitirse a lo establecido en el Pliego de Bases y Condiciones.
4
Consulta sobre item 1 - Capacidad de VRF
Solicitamos amablemente a la convocante ajustar este requerimiento a un valor más estándar en equipos de 1U de alto desempeño, por ejemplo ≥128 o ≥256 VRF, ya que el umbral de 600 es característico de equipos de chasis de gran porte. La reducción permitirá mayor concurrencia de oferentes sin afectar la funcionalidad requerida para segmentación de redes.
Solicitamos amablemente a la convocante ajustar este requerimiento a un valor más estándar en equipos de 1U de alto desempeño, por ejemplo ≥128 o ≥256 VRF, ya que el umbral de 600 es característico de equipos de chasis de gran porte. La reducción permitirá mayor concurrencia de oferentes sin afectar la funcionalidad requerida para segmentación de redes.
El valor definido responde a la arquitectura de red proyectada para el entorno del Centro de Datos, donde se prevé una alta densidad de segmentación lógica y múltiples instancias de enrutamiento independientes para distintas áreas y servicios críticos. El umbral de 600 VRF fue establecido para garantizar la escalabilidad y la continuidad operativa a mediano y largo plazo, evitando limitaciones en futuras ampliaciones o integraciones de servicios. Por tal motivo, favor remitirse a lo establecido en el Pliego de Bases y Condiciones.
5
Consulta sobre ítem 1 - Stacking
Sobre el punto Stacking “en cualquier puerto y a cualquier velocidad”, consultamos si podrían modificar a: “El equipo deberá soportar tecnologías de alta disponibilidad o stacking equivalentes (VSX, IRF, VSS, MC-LAG u otras tecnologías propietarias del fabricante) que permitan redundancia y operación continua.” Esto asegura la interoperabilidad con diferentes arquitecturas líderes del mercado.
Sobre el punto Stacking “en cualquier puerto y a cualquier velocidad”, consultamos si podrían modificar a: “El equipo deberá soportar tecnologías de alta disponibilidad o stacking equivalentes (VSX, IRF, VSS, MC-LAG u otras tecnologías propietarias del fabricante) que permitan redundancia y operación continua.” Esto asegura la interoperabilidad con diferentes arquitecturas líderes del mercado.
El requisito fue definido para garantizar flexibilidad total en la configuración, escalabilidad y redundancia del Switch Core, permitiendo que la interconexión entre equipos no dependa de módulos o puertos específicos, lo que facilita la expansión de la red y reduce tiempos de recuperación ante fallas. Por tal motivo, favor remitirse a lo establecido en el Pliego de Bases y Condiciones.
6
Consulta sobre item 1 - Protocolos obsoletos (Telnet, GVRP, SLP)
En las especifivaciones técnicas del ítem 1, se listan múltiples RFCs y protocolos que incluyen Telnet, GVRP, SLP, etc., solicitamos retirar de las exigencias los protocolos obsoletos o inseguros, limitando la exigencia a los protocolos actuales de gestión segura (SSH, HTTPS, SNMPv3) y funciones de monitoreo (sFlow/NetFlow). Esto fortalece la seguridad de la solución y amplía la concurrencia.
26-09-2025
09-10-2025
Consulta sobre item 1 - Protocolos obsoletos (Telnet, GVRP, SLP)
En las especifivaciones técnicas del ítem 1, se listan múltiples RFCs y protocolos que incluyen Telnet, GVRP, SLP, etc., solicitamos retirar de las exigencias los protocolos obsoletos o inseguros, limitando la exigencia a los protocolos actuales de gestión segura (SSH, HTTPS, SNMPv3) y funciones de monitoreo (sFlow/NetFlow). Esto fortalece la seguridad de la solución y amplía la concurrencia.
La inclusión de los distintos protocolos y RFCs, incluyendo algunos considerados de uso limitado o legado, tiene como objetivo garantizar la interoperabilidad total con los equipos existentes en la infraestructura actual de la Institucion, así como la compatibilidad con sistemas y dispositivos de distintas generaciones que aún se encuentran en operación. Por tal motivo, favor remitirse a lo establecido en el Pliego de Bases y Condiciones.
7
Consulta sobre ítem 2 - WAF y Email Protection dentro del mismo appliance
Sobre el punto “El firewall deberá incluir la funcionalidad y licenciamiento para WAF y Email Protection dentro del mismo appliance por 36 meses.”, solicitamos admitir que las funciones de WAF y protección de correo electrónico puedan ser provistas mediante módulos, licencias o appliances/VM dedicados del mismo fabricante e integrados con el firewall. La exigencia de todo “dentro del mismo appliance” excluye a múltiples fabricantes líderes y reduce la competitividad.
26-09-2025
09-10-2025
Consulta sobre ítem 2 - WAF y Email Protection dentro del mismo appliance
Sobre el punto “El firewall deberá incluir la funcionalidad y licenciamiento para WAF y Email Protection dentro del mismo appliance por 36 meses.”, solicitamos admitir que las funciones de WAF y protección de correo electrónico puedan ser provistas mediante módulos, licencias o appliances/VM dedicados del mismo fabricante e integrados con el firewall. La exigencia de todo “dentro del mismo appliance” excluye a múltiples fabricantes líderes y reduce la competitividad.
Este requisito busca garantizar la integración nativa, administración centralizada y operación unificada de los servicios de seguridad del Firewall, WAF y la Protección de Correo, dentro de una misma plataforma física, optimizando el mantenimiento, la gestión de licencias y el soporte técnico. Existen en el mercado diversas soluciones que integran nativamente estas funciones dentro de un mismo dispositivo de seguridad unificado, por lo que el requisito no limita la libre competencia y se considera técnicamente justificado. Por tal motivo, favor remitirse a lo establecido en el Pliego de Bases y Condiciones.
8
Consulta sobre item 2 - Integración con Endpoint del mismo fabricante
En cuanto a la exigencia “La solución deberá garantizar la integración con el Endpoint Protection del mismo fabricante.”, solicitamos amablemente a la convocante modificar a: “La solución deberá permitir integración con soluciones de Endpoint Protection/EDR mediante APIs, IOC feeds, Syslog u otros conectores estándar.” Esto evita dependencia de una sola marca y permite mayor concurrencia.
26-09-2025
09-10-2025
Consulta sobre item 2 - Integración con Endpoint del mismo fabricante
En cuanto a la exigencia “La solución deberá garantizar la integración con el Endpoint Protection del mismo fabricante.”, solicitamos amablemente a la convocante modificar a: “La solución deberá permitir integración con soluciones de Endpoint Protection/EDR mediante APIs, IOC feeds, Syslog u otros conectores estándar.” Esto evita dependencia de una sola marca y permite mayor concurrencia.
Este requisito tiene como objetivo asegurar la compatibilidad completa, soporte nativo y operación confiable entre el Equipo de Seguridad de Red y el Endpoint Protection del mismo fabricante, garantizando la detección coordinada de amenazas, visibilidad centralizada y respuesta automática a incidentes. Permitir la integración genérica mediante APIs o conectores estándar podría no garantizar el mismo nivel de compatibilidad ni soporte técnico directo, lo que podría afectar la efectividad de la solución, la respuesta ante incidentes y la continuidad operativa de la red. Dado que existen múltiples fabricantes que ofrecen esta integración nativa sin restricciones de competencia, la exigencia se considera técnicamente justificada y alineada con los objetivos de seguridad y eficiencia de la contratación. Por tal motivo, favor remitirse a lo establecido en el Pliego de Bases y Condiciones.
9
Consulta sobre ítem 2 - Interfaces 2.5 GbE
Sobre el punto “El equipo debe contar con 4×GbE cobre, 4×2.5 GbE cobre y 4×10 GbE SFP+.”
Consultamos si podrían aceptar que los puertos exigidos puedan ser equivalentes o superiores, por ejemplo puertos 1G y 10G SFP+/cobre, ya que la interfaz 2.5 GbE no es un estándar extendido en firewalls de clase datacenter. Con esto se garantiza funcionalidad sin limitar la concurrencia.
Sobre el punto “El equipo debe contar con 4×GbE cobre, 4×2.5 GbE cobre y 4×10 GbE SFP+.”
Consultamos si podrían aceptar que los puertos exigidos puedan ser equivalentes o superiores, por ejemplo puertos 1G y 10G SFP+/cobre, ya que la interfaz 2.5 GbE no es un estándar extendido en firewalls de clase datacenter. Con esto se garantiza funcionalidad sin limitar la concurrencia.
La exigencia de interfaces específicas responde a la capacidad mínima de conectividad y rendimiento requerido para soportar la infraestructura de red actual de la Institución, considerando el tráfico previsto, segmentación de redes y redundancia. Por tal motivo, favor remitirse a lo establecido en el Pliego de Bases y Condiciones.
10
Consulta sobre item 2 - VPN SSL ilimitadas sin costo
En las especificaciones técnicas de ítem 2 solicita: “La solución deberá permitir VPN SSL ilimitadas sin costo adicional.” Solicitamos ajustar éste punto a: “La solución deberá permitir la creación de VPN SSL concurrentes suficientes para cubrir la necesidad de la convocante, con posibilidad de ampliación mediante licencias.” Esto se ajusta a los modelos comerciales habituales de los fabricantes y amplía la oferta.
26-09-2025
09-10-2025
Consulta sobre item 2 - VPN SSL ilimitadas sin costo
En las especificaciones técnicas de ítem 2 solicita: “La solución deberá permitir VPN SSL ilimitadas sin costo adicional.” Solicitamos ajustar éste punto a: “La solución deberá permitir la creación de VPN SSL concurrentes suficientes para cubrir la necesidad de la convocante, con posibilidad de ampliación mediante licencias.” Esto se ajusta a los modelos comerciales habituales de los fabricantes y amplía la oferta.
El requerimiento tiene por objeto garantizar la disponibilidad total de conexiones seguras (VPN SSL) para usuarios remotos o sedes dependientes de la Institución, sin generar costos adicionales por licenciamiento o ampliación futura. Modificar el requisito a un número limitado o condicionado a la adquisición de licencias adicionales podría generar dependencia de costos futuros, restricciones operativas y limitaciones de crecimiento, contrarias a los objetivos de continuidad operativa y eficiencia presupuestaria de la Institución. Por tal motivo, favor remitirse a lo establecido en el Pliego de Bases y Condiciones.