.NET Framework hoy y mañana

En ciertas ocasiones, más habituales de lo que uno desearía, te encuentras en la obligación de interactuar con componentes antiguos... muy antiguos... si hablamos de un COM en Visual Basic 6 nos remitimos 20 años atrás. Si la evolución del software y hardware cada 6 meses puede ser notable, en algunos ámbitos la adopción de ciertos hitos tecnológicos lleva décadas.

Existe una mejora y facilidad de uso entre los Common Language Runtime (CLR), aunque Microsoft le encanta cambiar y variar los nombres (Project K, vNext...) , intentaremos resumir...

Actualmente la definición de .NET Standard intenta facilitar a los desarrolladores una API común para aplicaciones de escritorio, móvil, juegos y cloud, tenemos por un lado Full Framework y por otro lado Core Framework, dos ramas con diferentes propósitos.

  • Full Framework es monolítica, instalas todo o nada solo para Windows
  • Core Framework es modular, puedes referenciar solo las partes que utilices para entorno Windows, Linux o Mac, además es Open Source y con web/Cloud en mente inicialmente.
  • Dejamos Xamarin como multiplataforma a partir de la evolución de Mono (Linux) cuando Microsoft no quería llevar .NET fuera de Windows (eran otros tiempos sin iOS ni Android...)

A futuro Microsoft parece querer unificar toda su tecnología sobre C# en .NET Core: Entity (ORM), WPF, MVC, SignalR, MVC, Web API... pero hasta entonces tenemos largos años de Full Framework todavía ¿cuantos?

 


Voz IP VLAN + Akuvox

A la hora de planificar el despligue de una infraestructura de telefonía sobre voz ip dentro de una red local, una de las recomendaciones básica pasa por separar en una red diferencia. No hablamos de IP fijas en otro rango, subnetting ni similares; sino de una separación totalmente diferenciada.

Segmentar nos ayudará a tener mayor control y trazabilidad frente a eventuales problemas:

  • Autoprovisionamiento controlado mediante Organizationally unique identifier (OUI) tanto para el envio de configuración a los terminales, como para la asignación de VLANs en la eletrónica de red. Utilizando la parte inicial de la MAC del fabricante (habitualmente el mismo en un despliegue).
  • Seguridad adicional, una mayor restricción a la hora de conectar cualquier aparato en cualquier toma. Limita y dificulta pero no impide.
  • Priorizar tráfico mediante políticas QoS, necesitaremos que entre los puntos de comunicación todos los dispositivos dispongan de esta posibilidad.

En este caso concreto con terminales Akuvox, con una configuración previa funcional con otro fabricante, los equipos se quedan permanentemente "Obteniendo dirección IP". Finalmente parece tratarse de un error en el firmware del propio fabricante, en el cual no se añade correctamente el etiquetado de los paquetes...

Firmware afectado: 55.0.6.134

Firmware funcional sin problemas en VLAN: 55.203.6.230