16 de febrero de 2014

El comando network

En el mundo Cisco, la configuración básica de un protocolo de enrutamiento IPv4 es relativamente simple:
Router#configure terminal
Router(config)#router [protocolo]
Router(config-router)#network [ID de red]
Router(config-router)#end
El proceso del protocolo de enrutamiento se activa en el momento en el que se ingresa el primer comando network. Si no hay comandos network, no se activa el protocolo de enrutamiento.
Pero esta configuración básica tiene algunas limitaciones primarias que deben ser tenidas en cuenta:
  • Aplica exclusivamente a protocolos de enrutamiento interior (RIP, EIGRP, OSPF). No aplica de la misma forma a la configuración de BGP.
  • No aplica a la configuración de enrutamiento IPv6.
Con estas salvedades, los protocolos de enrutamiento interior IPv4 se configuran esencialmente de igual manera. Pero en esa configuración el comando network tiene un rol particular que debemos comprender, y que no es exactamente idéntico en todos los protocolos.
El comando network es el que se utiliza para definir en todos los casos qué interfaces del dispositivo participan del proceso de enrutamiento. Los efectos prácticos del comando son 3:
  • Identifica las interfaces a través de las cuáles se publica información del protocolo de enrutamiento hacia los dispositivos vecinos.
  • Identifica las interfaces a través de las cuáles se recibe información del protocolo de enrutamiento publicada por los dispositivos vecinos.
  • La red o subred a la que está asociada la interfaz va a ser incluida en el proceso del protocolo de enrutamiento.
Tengamos presente entonces: el comando network define las interfaces del dispositivo que participan del proceso del protocolo de enrutamiento.
Dado que hay particularidades respecto del uso de este comando en cada uno de los protocolos de enrutamiento interior, voy a tomar como base la configuración de un dispositivo (un router 2911), y luego revisaremos la utilización del comando en un entorno de enrutamiento RIP, en uno EIGRP y en uno OSPF.
Las interfaces de nuestro dispositivo de pruebas:
Router#show ip interface brief
Interface             IP-Address       OK? Method Status Protocol
GigabitEthernet0/0    192.168.1.1      YES manual  up       up
GigabitEthernet0/1    192.168.1.129    YES manual  up       up
GigabitEthernet0/2    172.16.1.1       YES manual  up       up
Serial0/0/0           192.168.100.1    YES manual  up       up
Serial0/0/1           192.168.100.5    YES manual  up       up

Uso de network en RIP
En el caso de RIP no es posible identificar subredes (en nuestro ejemplo tenemos varias), pudiéndose declarar únicamente las redes completas según clase.
En nuestro caso, la configuración es:
Router#configure terminal
Router(config)#router rip
Router(config-router)#network 192.168.1.0
Router(config-router)#network 192.168.100.0
Router(config-router)#network 172.16.0.0
Router(config-router)#end
No hay límite respecto de la cantidad de networks que se pueden declarar. Si una interfaz no está incluida en esta configuración, la red asociada a ese interfaz no será publicada por el protocolo.

Uso de network en EIGRP
En el caso de EIGRP es posible utilizar, opcionalmente, una máscara de wildcard para definir con mayor precisión cuáles son las interfaces que participan del proceso de este protocolo de enrutamiento.
En el caso de nuestro ejemplo, supondré que no deseamos incluir en el proceso de EIGRP la interfaz Serial 0/0/1 que utiliza una subred de la misma red que la interfaz Serial 0/0/0; por lo que utilizaré máscara de wildcard para incluir solamente la interfaz Serial 0/0/0.
Router(config)#router eigrp 1
Router(config-router)#network 192.168.1.0
Router(config-router)#network 172.16.0.0
Router(config-router)#network 192.168.100.1 0.0.0.3
Router(config-router)#end
En este caso, es posible utilizar el comando para incluir una o varias interfaces según se prefiera. El router sólo establecerá relación de vecindad con dispositivos que sean accesibles a través de las interfaces incluidas en el proceso del protocolo.
Dado que podemos utilizar máscaras de wildcard, en EIGRP un comando network puede incluir un host en particular, una subred o conjunto de subredes, o incluso un conjunto de redes. Cuando no se aplica la máscara de wildcard el comando se comporta de modo similar a como lo hace en RIP.

Uso de network en OSPF
En OSPF, el comando network no sólo define las interfaces que participan del proceso del protocolo, sino que también se utiliza para asignar la interfaz a un área OSPF específica. En este caso, el uso de la máscara de wildcard es obligatorio; pero el conjunto ID de red + wildcard puede identificar un host, una interfaz o un conjunto de ellas, mientras que las interfaces comprendidas pertenezcan a la misma área.
En el caso de nuestro ejemplo, incluiré las interfaces Serial 0/0/0 y 0/0/1 como pertenecientes al área 0 utilizando una única sentencia.
Router(config)#router ospf 1
Router(config-router)#network 192.168.1.0 0.0.0.127 area 1
Router(config-router)#network 192.168.1.128 0.0.0.127 area 1
Router(config-router)#network 172.16.1.0 0.0.0.255 area 1
Router(config-router)#network 192.168.100.0 0.0.0.7 area 0
Router(config-router)#end
No hay límite respecto de la cantidad de comandos network que se pueden declarar. Se debe tener presente que cada interfaz puede estar asociada a una única área OSPF.

Enlaces con documentación de referencia


14 comentarios:

  1. Una pregunta Oscar. He visto una red en la que los routers se conectan a un switch (toplogia metrolan real) son de un mismo cliente y cada uno representa una sucursal, enrutar por rip las interfaces lan, pero no la WAN, es decir, no doy de alta en rip las interfaces que se conectan directamente al switch, pero si las de la LAN de las sucursales. La tabla de rutas se rellena y hay conectividad pero si lo pruebo en packet tracert no funciona necesito dar de alta en RIP las interfaces WAN, a pesar de que los pines entre las interfaces directamente conectadas si funcionan.No entiendo la razón, por la que en la red que he visto funciona pero en la simulación de packet tracert hasta que no doy de alta las interfaces de WAN no se intercambian los paquetes de rip.

    ResponderBorrar
    Respuestas
    1. Esta situación puede tener varias respuestas.
      La primera y más evidente, es que Packet Tracer es un simulador y solamente puede representar aquellas situaciones para las que ha sido diseñadas, no cualquier configuración posible. No estás trabajando sobre IOS sino sobre un programa que simula la operación de IOS.
      La segunda posible, es que se trate de una red Metro de capa 2, en la que todos los puertos WAN se encuentran operando en capa 2 y conectados a una única VLAN. En este caso, no hay enrutamiento sobre los puertos WAN ya que todos operan como un gran switch capa 2.

      Borrar
    2. Efectivamente Oscar se trata de una red Metrolan, ¿entonces funcionaria de la misma forma en otras redes, por ejemplo ADSL? Porque al final todas las redes WAN excepto las punto a punto fisicas se conectan a un switch, como un switch frame relat o un switch ATM. Muchas gracias.

      Borrar
    3. No es tan así.
      En primer lugar porque la principal tecnología WAN actual, que es MPLS, en la mayor parte de los servicios opera en capa 3.
      En segundo, porque no hay que confundir la tecnología con su implementación. En el caso de Frame Relay que mencionas, la red del SP es efectivamente de capa 2, pero la mayor parte de las implementaciones por parte del cliente supone que las interfaces que se conectan a la red FR operan en capa 3. Es decir, si bien la red FR es capa 2, las interfaces del cliente utilizan direccionamiento IP y enrutamiento sobre la red FR.

      Borrar
  2. Hola Oscar,
    Se podría usar el siguiente comando para publicar todas las interfaces menos la GigabitEthernet 0/2 tanto en Ospf como en Eigrp.
    #router (protocolo de enrutamiento) 1
    (Config-router)#network 192.168.0.0 0.0.255.255 area 0 ====> sin área 0 en el caso de eigrp.
    Es decir este comando activaría el protocolo en las interfaces 192.168.xx.xx y además las publicaría a otros ruters con la máscara correspondiente que tiene cada una en su interfaz.

    ResponderBorrar
    Respuestas
    1. Muky
      Ese comando efectivamente haría que todas las interfaces de la red 192.168.0.0/16 participen del proceso de enrutamiento que definas.
      Ahora bien, no se si eso excluye específicamente la interfaz Gi0/2 porque no conocemos su configuración.
      Por otra parte, si bien es tentador a veces reducir la cantidad de comandos al configurar, hay que analizar si eso luego, en el tiempo, favorece o dificulta la gestión y el diagnóstico de fallos.

      Borrar
  3. Buenas Óscar me refería a la misma configuración que indicas en el post.
    GigabitEthernet0/2 172.16.1.1 YES manual up up

    Es la una interfaz que no es 192.168.x.x/25

    Muchísimas gracias por tu rápida respuesta y sobre todo por tu genial blog que me ha ayudado mucho a lo largo de mi viaje por cisco.

    Un saludo

    ResponderBorrar
  4. Me gustaría saber si hay alguna forma de saber en OSPF lo que estas anunciando al resto de la red,algo parecido a lo que pasa en BGP,dado que el comando network da de alta una interfaz en el proceso OSPF, no se anuncia una red de forma explicita ¿Hay alguna forma similar a lo que sucede en BGP con el show ip bgp neighbor X.X.X.X advertise routers? Y supongo que de ser así será similar también en EIGRP.

    ResponderBorrar
    Respuestas
    1. En primer lugar, si bien en OSPF lo que se declaran son las interfaces que participan del enrutamiento hay que tener en claro que lo que se publica es la red asociada a cada una de las interfaces que están asociadas al proceso.
      En segundo lugar, lo que se puede verificar en este caso es el SLA tipo 2 que se publica en la tabla topológica.
      No puede haber un comando similar al de BGP pues en BGP lo que se publican son prefijos IP mientras que en OSPF son anuncios de estado de enlaces. Lo que OSPF anuncia son enlaces, no prefijos.

      Borrar
    2. Lo de que OSPF anuncia son enlaces y no prefijos es algo que no había leído nunca de esta forma, si sabía que se dan de alta interfaces en el proceso de OSPF pero nunca lo había visto de la manera que afirmas.

      Borrar
    3. Pues, es propio de todo protocolo de estado de enlace.
      Lo que se publica en estos protocolos son LSAs, es decir, Link State Advertisement, no Route Advertisement.
      Cada dispositivo almacena esos LSAs en su base de datos topológica y a partir de allí calcula la topología de la red y la mejor ruta posible a cada destino.

      Borrar
    4. Si los protocolos de estado de enlace anuncian enlaces y BGP (vector camino sino me equivoco? anuncia prefijos, los de vector distancia ¿que anuncian? ¿la distancia hacia un destino? Pero al final el destino en cualquier protocolo de routing tiene que ser una red ip si hablamos de tcp/ip y en una tabla de routing se instalan prefijos.

      Borrar
    5. Me expresé mal en la primera respuesta.
      Prefijos IP hay siempre, porque el prefijo IP es el identificador de un enlace o red IP.
      La diferencia es entre enlaces y rutas. Se anuncian enlaces, o se anuncian rutas.
      Los protocolos de estado de enlace basan su operación en que todos los integrantes de un dominio de enrutamiento tienen la misma información topológica, la que se construye a partir del intercambio de información sobre enlaces. Enlaces, no rutas.
      Para verificar esto simplemente verificá la table topológica de OSPF y verás que no encontrás rutas.
      Los protocolos de vector distancia, en cambio, se dice que "intercambian sus tablas de enrutamiento", es decir, que intercambian rutas, no enlaces.
      El resultado final, por supuesto, es siempre el mismo: una ruta a un destino específico, en la tabla de enrutamiento. Lo que es diferente es la información a partir de la cual se construye esa ruta y el modo en que se obtiene, que es la diferencia entre protocolos de vector distancia y estado de enlace.

      Borrar

Gracias por tu comentario.
En este blog los comentarios están moderados, por lo que su publicación está pendiente hasta la revisión del mismo.