Ruteo Inter-VLAN en un Router Cisco utilizando Router-on-a-stick

Una VLAN es técnicamente un dominio de broadcast diferente, por lo que de forma predeterminada no pueden comunicarse entre sí, salvo se usen diferentes técnicas de ruteo inter-vlan cada una de los cuales tiene sus ventajas y sus desventajas, a continuación mostraré un ejemplo de una técnica llamada “Router-on-a-stick”, que en resumen consiste en configurar una interfaz física de un Router para operar como un enlace troncal en el puerto de un switch, el Router efectua el ruteo intervlan de forma interna mediante el uso de subinterfaces, una subinterfaz es una interfaz virtual(vía software) que se crea en una interfaz física, por lo que se asocia cada subinterfaz con un número de VLAN, asi que podemos tener varias subinterfaces creadas en una misma interfaz física, lo cual presenta ventajas y desventajas que enumeramos a continuación.

Ventajas
  • Fácil de implementar solo se requiere crear una subinterfaz por cada VLAN en el Router.
  • Mucho más económica que tener un Router por VLAN.
  • Mucho mejor latencia que tener un Router por VLAN.
Desventajas
  • Los Routers son más lentos que los switches para ruteo inter-VLAN, lo ideal es tener un switch multicapa.
  • Si se necesita incrementar el número de puertos, entre más puertos requiera un Router más costoso resulta.
  • Estamos expuestos al buen funcionamiento de una sola interfaz física en el Router, esto es un único punto de fallo.

A continuación ejemplificaremos esta técnica con una práctica, los dispositivos son:

  • 4 PC’s
  • 2 switches
  • 1 router
  • 1 access point
  • 1 laptop

Al colocarlos en el WorkSpace del Packet Tracer debe ver más o menos como en la siguiente imagen:

Para la creación de las VLAN es conveniente el empleo de VTP para no teclear doblemente la configuración,asi que utilizamos el switch 1 (SW1,el que va unido al Router) como servidor y el switch 2 (SW2 el que tiene el access point) como cliente, empezamos la configuración en el SW1, con los siguientes comandos:

Comandos para el switch 1

En el SW2 tecleamos los mismos comandos para crear las troncales, la variante es la forma en que obtenemos las VLAN’s creadas en el SW1 por VTP.

Comandos para el switch 2

Para finalizar tecleamos los siguientes comandos en el router.

Comandos para el router


En la configuración IP de cada PC, debe de ponerse como gateway la ip de cada subinterfaz asociada a la VLAN dentro de la cual se encuentre configurada la PC.
Por ejemplo si una PC su ip es:192.168.20.2 y se encuentra en la VLAN 20 su gateway sera la IP 192.168.20.1 la cual se asigno a una subinterfaz asociada con la VLAN 20, como se muestra en las siguientes imágenes:

Igualmente si una PC su IP 192.168.30.2 es perteneciendo a la VLAN 30, entonces su gateway es la IP 192.168.30.1 que se asigno a la subinterfaz asociada con la VLAN 30

Aquí se muestra la comunicación inter-VLAN’s.

Descarga el archivo para packet tracer 5.3.2

Descarga los scripts con los comandos

¿Qué es el análisis postmortem en un proyecto de software?

En el contexto de los proyectos de desarrollo de software, un análisis Postmortem es el proceso de revisar la historia del proyecto para entender cómo cada uno de los eventos contribuyo al éxito o fracaso del proyecto.

En resumen: es el análisis retrospectivo realizado por todos los miembros del equipo de trabajo una vez que el proyecto concluye, sea exitosa o no esta conclusión.

Al realizar este análisis se busca identificar los aspectos positivos aplicados en el proyecto para que puedan repetirse, así como plantear soluciones y mejoras de los aspectos negativos, asimilando la experiencia para que no vuelvan a repetirse. Todo ello se conoce de forma simple como Lecciones Aprendidas.

Beneficios

Realizar un análisis de las experiencias buenas y malas adquiridas en el proyecto, es necesario para:

  • Identificar los aspectos que pueden mejorarse en proyectos futuros.
  • Obtener las experiencias de todos los involucrados en el proyecto, concentrando opiniones , puntos de vista y generando conclusiones en grupo.
  • Formar una base de conocimientos de “Lecciones Aprendidas” para que sean conocidas, revisadas y consideradas en otros proyectos con características similares.
  • Si hay un proyecto nuevo los recursos nuevos que tengan acceso a las lecciones aprendidas no tendrán justificación para repetir los mismos errores que se cometieron en sus proyectos anteriores.
  • Aplicar las lecciones aprendidas al proceso de estimación de un proyecto de software proporciona un par de beneficios, en principio, ayuda a la organización a prevenir desarrollar proyectos que no generan ganancias. Segundo, se orilla a que la estimación sea más precisa y exacta ya que la organización podría emplear un presupuesto inflado. Cuando la organización tiene confianza en sus estimaciones, es una organización más competitiva.

Actividades

  1. Aplicar cuestionario Postmortem.
  2. Realizar la reunión Postmortem.
  3. Registrar lecciones aprendidas.

Aplicar cuestionario Postmortem esta actividad se realiza para obtener las experiencias de los recursos que participan en algún momento en el proyecto y que por algún motivo salen antes de que este concluya. En la ejecución de esta actividad participan: el responsable del proyecto quien se asegura de que todos los recursos que salen antes de que el proyecto concluya, apliquen el cuestionario y el miembro del equipo de trabajo que sale del proyecto se requiere que conteste el cuestionario.
Los cuestionarios que se recopilen serán revisados por el responsable del proyecto para concentrar las experiencias obtenidas y resumirlas en la presentación Postmortem.

Realizar la reunión postmortem Los datos del proyecto que deben considerarse en esta presentación, son:

  • Datos generales del proyecto
  • Evaluación del alcance
  • Evaluación de la planeación
  • Evaluación de la capacitación
  • Evaluación de la calidad
  • Evaluación del proceso
  • Oportunidades y conocimientos adquiridos
  • Evaluación de la percepción del cliente

Registrar lecciones aprendidas: aquí se obtiene un resumen de las lecciones identificadas por todos los miembros del equipo de trabajo para clasificarlas y registrarlas en el repositorio de lecciones aprendidas de la organización.Registrar lecciones aprendidas: aquí se obtiene un resumen de las lecciones identificadas por todos los miembros del equipo de trabajo para clasificarlas y registrarlas en el repositorio de lecciones aprendidas de la organización.

Consideraciones

Al ejecutar esta actividad es muy importante tomar en cuenta los siguientes aspectos:

  • Planear las actividades necesarias para ejecutar el proceso postmortem en todos los proyectos.
  • La reunión postmortem debe ejecutarse inmediatamente al concluir el proyecto.
  • Es necesario contar con las aportaciones de todos los recursos que en algún momento se vieron involucrados en el proyecto.
  • Deben exponerse los aspectos positivos y negativos registrados en el proyecto.
  • Calificar al proyecto, no a las personas.
  • Realizar recomendaciones que complementen las lecciones aprendidas.
  • Los datos obtenidos en la presentación postmortem son utilizados en la presentación de cierre del proyecto.

Cuestionario Postmortem

La recopilación de las experiencias adquiridas por todos los recursos que participaron en algún momento en el proyecto se realiza a partir de la aplicación del cuestionario Postmortem en el caso de los recursos que participaron hasta el cierre del proyecto.
A continuación un ejemplo de las secciones de un cuestionario Postmortem

1.Datos generales

[Aquí describe tu participación dentro del proyecto]

  1. Nombre completo:
  2. Rol:
  3. Periodo de participación: [Total o parcial, especifique el periodo en el que permaneció en el proyecto, este será total si participo en todas las fases del proyecto, será parcial si solo participo en una fase del proyecto]
  4. Jefe inmediato/ Rol:[Especifique el nombre del jefe inmediato y su participación]

2. Evaluación de la planeación

[Sección dedicada a describir la percepción respecto a la planeación de actividades en el proyecto, poner las razones en cada respuesta]

  1. ¿Existieron diferencias entre el número planeado de artefactos/productos contra el real?
  2. ¿Se presentó alguna diferencia entre el tiempo planeado contra el real?
  3. ¿Existe alguna diferencia entre las disciplinas en las que se tiene planeada
    tu participación y en las que realmente participaste?

3. Evaluación de la Capacitación

[Aquí se pone la percepción respecto a las actividades de entendimiento del negocio]

  1. ¿Recibiste la capacitación técnica necesaria para realizar tus funciones?
  2. ¿Consideras que recibiste la capacitación necesaria del conocimiento del negocio de acuerdo a
    tu perfil?

4. Evaluación de la calidad

[Aquí indica los productos que fueron generados durante el proyecto, pudiendo ser documentos, código, modelos o diagramas]

5. Evaluación del Proceso

[Sección dedicada a evaluar el proceso de desarrollo de software]
En un proyecto similar, qué acciones, actitudes y decisiones tendrían que ser diferentes y cuáles podrían repetirse en cuanto a:

  1. La capacitación para el proyecto.
  2. Las disciplinas ejecutadas en el proyecto.
  3. Las herramientas utilizadas para el proyecto.
  4. La infraestructura con la que contó el proyecto.
  5. La administración del proyecto.

NOTA: Hay que tener en cuenta que los cuestionarios Postmortem pueden variar de acuerdo a la organización o a la metodología que se utilice.

La navaja de Ockham o principio KISS en el desarrollo de software

La navaja de Ockham o el principio de parsimonia es el principio metodológico ideado por William of Ockham (1285-1347) filósofo nominalista que se utiliza para “cortar” o “rasurar” todo aquel conocimiento que no provenga de los datos de los sentidos, es decir invalidar los conceptos que no sean comprobables por la experiencia misma.

La formulación correcta de Ockham es:

No hay que multiplicar los entes sin necesidad (entia non sunt multiplicanda praeter necessitaem).

La navaja funciona de la siguiente manera: cuando se nos ofrecen dos o más hipótesis en igualdad de circunstancias para explicar un determinado fenómeno, es razonable aceptar la hipótesis más simple o sea la que incluye menos supuestos no probados.

En otros campos del conocimiento la navaja de Ockham se utiliza para eliminar objetos o tipos de objetos que no aportan o cambian en nada las particularidades efectivas de las cosas.
En informática a la navaja de Ockham se le conoce como el principio KISS, siglas que significan:

Keep It Simple, Stupid! (Mantenlo simple, estúpido)

Aplicando el KISS al desarrollo de software tenemos que pequeño y sencillo es mejor que grande y complejo. En pocas palabras, entre más pequeño sea el número de componentes o de código involucrado en un proyecto menor será la cantidad de errores o problemas asociados al mantenimiento. Lo que incrementa la probabilidad de una entrega exitosa a tiempo.

Hay un principio de la filosofía UNIX que ejemplifica la aplicación de un principio KISS:

*“En lugar de tener pocos programas grandes, cada uno tratando de hacer muchas cosas, el sistema UNIX proporciona muchas herramientas simples que pueden combinarse para realizar un amplio rango de cosas.”

*Rosen Kenneth, Rosinki Richard, UNIX System V release 4. An introduction. Second Edition, Mc Graw Hill

Algunos ejemplos del KISS en el desarrollo de software son:

  • No intentes complicar el modelo de base de datos agregando entidades que nada aportan al negocio funcional. Solo agrega las entidades que requieren una persistencia.
  • No toda la persistencia necesita estar en una base de datos, hay ocasiones en que los archivos de texto plano son la mejor opción para el rendimiento.
  • No requieres un RDBMS para guardar una agenda de contactos.
  • No intentes optimizarlo si ni siquiera funciona o no esta terminado.
  • La complejidad de los algoritmos o el número de capas que se agreguen a una arquitectura son inútiles si estos no resuelven los requerimientos funcionales, y al serán ignorados por los usuarios finales.
Hay una frase que también es un claro ejemplo de este principio:

Premature optimization is the root of all evil. (la optimización prematura es la raíz de todos los males)

–Sir Charles Anthony Richard Hoare, inventor del algoritmo Quicksort.

Hay que aclarar que la navaja de Ockham no sostiene que la hipótesis más simple sea la correcta, sino sencillamente que es la que tiene más probabilidades de ser la correcta.

Overriding Methods in C#

In addition to producing a new class based on an old one by adding additional features, you can modify existing behavior of the parent class.

If a method is defined in a derived class so that the name, return type, and argument list match exactly those of a method in the parent class, then the new method is said to override the old one.

The keyword virtual

In C#, a class can declare virtual methods, properties, and indexers, and derived classes can override the implementation of these function members.

The keyword virtual allows programmers to specify methods that a derived class can override, C# methods are non-virtual by default and must be explicitly declared as virtual.

The implementation of a non-virtual method is invariant: The implementation is the same whether the method is invoked on an instance of the class in which it is declared or an instance of derived class. In contrast, the implementation of a virtual method can be changed by derived classes.

The keyword override

To override a base-class method definition, a derived class must specify that the derived-class method overrides the base-class method with keyword override in the method header.

If the override modifier is not used, the new member hides the inherited member, and a compiler warning occurs. If a derived class attempts to override a non-virtual inherited member, a compiler error will occur.
The following examples illustrate the using of virtual and override keywords.

Fig 1. Class diagram for Employee and Manager using Inheritance.

Listing 1: Sample code for Employee class

Listing 2: Sample code for Manager class

Consider these sample methods in the Employee and Manager classes:
Fig 2. The GetDetails method of the Employee class.

Fig 3. The GetDetails method of the Manager class.

The Manager class has a GetDetails method by definition because it inherits one from the Employee class. However, the original method has been replaced, or overridden, by the derived class’s version.

Listing 3 A simple program to demonstrate how method overriding works.

Fig 4 The output of executing this program is the following.

Download the source code.

Understanding abstract classes with C#

The C# programming language enables a class designer to specify that a base class declares a method that does not supply an implementation. This is called an abstract method. The implementation of this method is supplied by the derived classes. Any class with one or more abstract method is called an abstract class.

Fig 1 UML model of the abstract class.

The purpose of an abstract class is primarily to provide an appropriate base class from which other classes can inherit and thus share a common design.
However, abstract classes can have data attributes, concrete methods, and constructors. For example, the Vehicle class might include load and maxLoad attributes and a constructor to initialize them.
Not all inheritance hierarchies contain abstract classes. However, programmers often write client code that uses only abstract base class types to reduce the client code’s dependencies on a range of specific derived class types.
The C# compiler always prevents you form instantiating an abstract class, for example the following statement is illegal.

 Vehicle v = new Vehicle(); // this is illegal and the compiler generates an error.

Although we cannot instantiate objects of abstract base classes, we will see that we can use abstract base classes to declare variables that can hold references to objects of any concrete classes derived from those abstract classes.

The employee abstract class: A example using Polymorphism through inheritance

What is polymorphism?

The term polymorphism refers to the ability of two or more objects belonging to different classes to respond to exactly the same message (method call) in different class-specific ways, thus polymorphism enables us to “program in the general” rather than “program in the specific”.

Polymorphism allows:

  • Different behavoirs from the same type.
  • Runtime polymorphism is done via overriding.
  • Compile time polymorphism is done via method overloading.
  • Invoke methods of a derived class through a base class.

I think the best way to learn about this concept is through an example, so I wrote a set of examples using an inheritance hierarchy containing types of employees in a company.

Fig 2 Employee hierarchy UML class diagram.

We use abstract class Employee to represent the general concept of an employee. The classes that inherit from Employee are: CommissionEmployee, PieceEmployee and HourlyEmployee.

1. I use abstract class Employee to represent the general concept of an employee. The classes that inherit from Employee are: CommissionEmployee, PieceEmployee and HourlyEmployee.

Listing 1. Abstract base class Employee

In this example, class Employee will provide two methods Earnings and Details, and properties that manipulate an Employee’s instance variables, the method Earnings certainly applies generally to all employee’s, but each earnings calculation depends on the derived employee’s class. So these two methods must be abstract in the Employee class because an implementation does not make sense there, so each derived class must override those methods with an appropriate implementation.

2. I wrote three concrete classes: HourlyWorker, CommissionWorker and PieceWorker. Such classes provide implementations of the abstracts methods declared in our abstract class, because abstract base classes are too general to create real objects.

Listing 2. Concrete derived class HourlyEmployee

Listing 3. Concrete derived class CommissionEmployee

Listing 4. Concrete derived class PieceWorker

To test our example, the following program creates an array of our abstract base class Employee, then assigns the four instances of our concretes classes to the array variable. Finally, the program iterates through array Employee and polymorphically invokes methods Earnings and Details to display the output of each of these methods.

Listing 5. Test program for our example.

Fig 3. The output for our example.

Note: Those examples were based on the examples included in: Deitel’s developer series C# 2010 for programmers.

Download the source code.

Understanding Bitwise Logical Operators with C#

Bit manipulation operations, including logical and shift operations, perform low-level operations directly on the binary representations used in integers. The ability to operate directly on binary might save large amounts of memory, might enable certain computations to be performed very efficiently, and can greatly simplify operations on collections of bits, such as data read form or written to parallel I/O ports.

The C# programming language supports bitwise operations on both numeric and boolean data types. These are represented as the operators ~, &, ^, and | for the bitwise operations of NOT (bitwise complement), bitwise AND, bitwise XOR, and bitwise OR, respectively.
The operators work in parallel on all bits of the operands and never cause overflow, even in a checked context.

Unsigned integers are normally used with the bitwise operators.

Bitwise NOT (complement)

The bitwise complement or NOT is used to flip the bits of a value, this operator is unary and inverts the bit value. Since this operator is a unary operator it cannot be combined with the = sign.

Fig 1 Example of bitwise NOT operator

Bitwise XOR

When combining two values with the logical XOR bitwise operator, you get the following result: if both bits are the same, the result is 0 else if 1 bit is 0 and the other is 1, the result is 1

Fig 2 Example of bitwise XOR Operator

Bitwise OR

When combining 2 byte values results in the following: if both bits are 0, the result is 0. If either or both bits are 1, the result is 1.

Fig 3 Example of bitwise OR operator

Bitwise AND

The bitwise AND operator produces a one in the output bit if both input bits are one; otherwise it produces a zero.

Fig 4 Example of bitwise AND operator

When using the bitwise operator, it’s useful to display values in binary to show the precise effects of these operators.
The following example demonstrate the use of the bitwise operators, it uses the method PrintBits (implemented in class Util) to print the unsigned int values.

The full sample is shown below:

Listing 1 Source code for Util class

Listing 2 Source code for the main program class

Fig 5 Running the sample

Fig 6 Output of the complete example


Download source code