Mostrando entradas con la etiqueta serial. Mostrar todas las entradas
Mostrando entradas con la etiqueta serial. Mostrar todas las entradas

lunes, 30 de enero de 2017

3 recomendaciones al construir el registro SOA en DNS

Hola, 
  En el presente artículo solo quiero mencionar 3 consejos que al parecer son difíciles de conseguir en Internet pero que son importantes..., hay MUCHOS otros consejos que se pueden dar, repito, voy a mencionar los que quizás no son tan conocidos y a su vez pueden traer problemas operacionales.

Recordando el fomato del registro SOA:
  Un pequeño ejemplo de un registro SOA sería (tomado de una instalación de Bind):
@ IN SOA localhost. root.localhost. (
     1 ; Serial
604800 ; Refresh
 86400 ; Retry
2419200 ; Expire
604800 ) ; Negative Cache TTL

   De manera muy breve y explicándolo de manera muy entendible: 
El serial: se debe incrementar con cada modificación de la zona. Recordemos que este valor será revisado por los servidores DNS secundarios para identificar si existe algún cambio en la zona
Refresh: Cada cuando tiempo el servidor DNS secundario debe ir al servidor primario y revisar si hubo cambios (¿el valor de Serial es mayor? 
Retry: En caso de que el servidor secundario intentó comunicarse al primario y NO pudo (por la razón que fuese), cada cuanto lo vuelvo a intentar
Expire: Supongamos que el servidor secundario tiene N cantidad de tiempo "N=Expire" sin haber contactado al primario debería dejar de responder. Esto sale del principio que hace mucho que el secundario no contacta al servidor primario y la información que tenga ya puede haber cambiado, el servidor DNS secundario prefiere no dar respuesta que dar información errónea y/o desactualizada. Es decir, el servidor DEJA DE RESPONDER A LA ZONA
Negative Cache TTL: Hace referencia a cachear respuestas DNS negativas...., por ejemplo NXDOMAIN
Revisando lo anterior, nótese que los valores son casi exclusivamente utilizados por los servidores DNS Secundarios que desean hacer zone-transfer.

Consejo 1:
  El Serial nunca debería ser 0. El RFC 2136 indica en la sección 7: "Design, Implementation, Operation, and Protocol Notes". 
  7.11. A zone's SOA SERIAL should never be set to zero (0) due to
   interoperability" ...............

Consejo 2: 
  El valor de Retry no debería ser mayor a Refresh. La razón es bastante lógica, es casi como no tener valor de Retry.., primero ocurre el refresh. Adicionalmente Retry significa contactar el servidor primario para hacer el zone transfer SI NO se pudo contactar antes, con el Retry se buscar mantener la zona actualizada. RFC 1912 indica: ...... "Retry: If a secondary was unable to contact the primary at the
          last refresh, wait the retry value before trying again.  This
          value isn't as important as others, unless the secondary is on
          a distant network from the primary or the primary is more
          prone to outages.  It's typically some fraction of the refresh
          interval."

Consejo 3:
   El Expire no debe ser menor al Refresh. Similar al consejo 2 pero incluso este lo considero más importante. Si yo tengo un Expire menor que el Refresh significa que el servidor secundario va a dejar de responder la zona antes de que un intento de actualización (Refresh). Obviamente esto no es lo que se quiere. En el RFC 1912 se lee: "Expire: How long a secondary will still treat its copy of the zone
          data as valid if it can't contact the primary.  This value
          should be greater than how long a major outage would typically
          last, and must be greater than the minimum and retry
          intervals"

Referencias:
- Libro: Cookbook for IPv6 Renumbering in SOHO and
Backbone Networks "https://hal.inria.fr/inria-00000888/file/D3.6.1.pdf"  página 50 indica:  "retry should be smaller than refresh"
- Guia: "Check Point™ Meta IP User’s Guide" pagina 114 indica: "Slave Refresh must be lower than Slave Data Expire and Zone Default TTL"
- Sobre el serial no debería ser 0:  https://mxtoolbox.com/problem/dns/dns-soa-serial-number-format y https://www.digitalocean.com/community/questions/soa-serial-number-format-is-invalid  (sin embargo algunos software de DNS lo aceptan)

The best Buy vps bitcoin from eldernode.com
Where to order pain Relief without prescription
you can buy bitcoin vps from eldernode

Host your website on the fastest servers in Chicago, USA. Hundreds of features you need. Chicago Shared Hosting Easy On-boarding & Simple Website Transfer to our Platform
카지노사이트

lunes, 27 de septiembre de 2010

Ejemplos de manipulacion de port forwarding utilizando NAT en routers Cisco

Situacion: 
 Tengo una granja de servidores (ejemplo Web, Mail y SSH) y tengo solo una direccion publica en mi router de borde. 

Escenario: 
    {Internet} --- {RTR con IP publica} ------- {Granja de Servidores} 
IP Publica: 11.12.13.14 
Mail Server: 192.168.1.5 Web Server: 192.168.1.4 
SSH: 192.168.1.6 
IP WAN: 11.12.13.14/30 
IP LAN: 192.168.1.1/24 
  
Solucion: 
 La solucion es configurar en el router Cisco NAT de tal manera de que al momento de recibir un paquete TCP al puerto destino correspondiente sepa a donde enviarlo. En este sentido, es necesario que el router re-envie los paquetes (port forwarding) de la siguiente manera: Paquetes destinados al IP 11.12.13.14 al puerto destino 25 lo envie al Mail Server (192.168.1.5) Paquetes destinados al IP 11.12.13.14 al puerto destino 80 lo envie al Web Server (192.168.1.4) Paquetes destinados al IP 11.12.13.14 al puerto destino 22 lo envie al SSH Server (192.168.1.6) 

Procedimiento: 
 La configuracion del router seria la siguiente: 
  ! ESTA ES LA INTERFAZ QUE DA HACIA LA GRANJA DE SERVIDORES 
interface FastEthernet0 
description Mi granja de servidores 
ip address 192.168.1.1 255.255.255.0 
ip nat inside 
! ! ESTA ES LA INTERFAZ QUE DA HACIA INTERNET 
interface Serial0 
description Hacia Internet 
ip address 11.12.13.14 255.255.255.252 
ip nat outside 
! !En la siguiente linea se indica que todo lo que apunte al IP 11.12.13.14 al puerto 80 lo envie al !servidor web 
ip nat inside source static tcp 192.168.1.4 80 11.12.13.14 80 extendable 
!En la siguiente linea se indica que todo lo que apunte al IP 11.12.13.14 al puerto 25 lo envie al !servidor mail 
ip nat inside source static tcp 192.168.1.5 25 11.12.13.14 25 extendable 
!En la siguiente linea se indica que todo lo que apunte al IP 11.12.13.14 al puerto 22 lo envie al !servidor ssh 
ip nat inside source static tcp 192.168.1.4 22 11.12.13.14 22 extendable 

Tips:
  Un dato muy interesante que es que se puede manipular el puerto. Por ejemplo, supongamos que tenemos un servidor web "escondido" podemos manejarlo con un puerto diferente al 80. Digamos que queremos que la gente desde Internet acceda a nuestro servidor Web utilizando el puerto 61234 podemos hacer lo siguiente: !El usuario desde Internet debe acceder a http://11.12.13.14:61234 ip nat inside source static tcp 192.168.1.4 80 11.12.13.14 61234 extendable Lo anterior es muy util para escoder servicios, ahorrar direcciones IP y darle seguridad a la red. Espero haya sido de tu utilidad, Suerte!

miércoles, 24 de junio de 2009

Conectando back2back routers Cisco. Frame Relay, HDLC y PPP

En estos dias he estado montando un laboratorio de CCNA y he tenido que realizar diferentes conexiones Back2Back entre diferentes routers Cisco. En fin les doy un pequeno resumen. Espero sea util:

1) Back2Back con enlaces seriales
Lo primero que necesitas son dos cables seriales: Uno debe ser DTE (generalmente con conector macho) y el otro debe ser DCE (generalmente con conector hembra)

a) Conectando HDLC (mas facil)
Configuracion del lado donde hayas colocado el cable DCE:

interface Serial0
ip address 10.0.0.1 255.255.255.252
clockrate 64000
no cdp enable

Configuracion del lado donde hayas colocado el cable DTE:

interface Serial1
ip address 10.0.0.2 255.255.255.252
no cdp enable


Notese que la configuracion del cable donde se encuentra el cable DCE debe tener el comando clockrate. Esto es muy necesario porque el router con el cable DTE necesito recibir el reloj porque son enlaces sincronos y es necesario un dispositivo que entregue el reloj a la red.

troubleshooting
#show controller s0
#ping 10.0.0.1
#ping 10.0.0.2
#show interface s0

b) Conectando utilizando Frame Relay (mi recomendacion en caso de un Laboratorio)
El motivo porque recomiendo esta configuracion sobre todo para un laboratorio de Cisco es que te permite crear varios enlaces (PVCs) entre los dos routers lo que te dara mas flexibilidad para tus configuraciones (protocolos de enrutamiento dinamico, suspender un enlace para una prueba, etc)

Configuracion del lado donde hayas colocado el cable DCE:
!
interface Serial0
no ip address
encapsulation frame-relay
no keepalive
clock rate 64000
!
interface Serial0.1 point-to-point
ip address 10.0.01 255.255.255.252
frame-relay interface-dlci 101


Configuracion del lado donde hayas colocado el cable DTE:
!
interface Serial0
no ip address
encapsulation frame-relay
no keepalive
!
interface Serial0.1 point-to-point
ip address 10.0.0.2 255.255.255.252
frame-relay interface-dlci 101


Notese que donde se encuentra el cable DCE tuvo que colocarse nuevamente el comando clockrate para que dicho router diera reloj a la red. En esta oportunidad adicionalmente hubo que colocar el comando no keepalive el cual deshabilita el procesamiento de LMI. Por ultimo, notese que se crearon subinterfaces point-to-point. A pesar de que la configuracion se puede realizar dentro de la interfaz madre (S0) aconsejo realizarlo dentro de la subinterfaz para ganar flexibilidad (por ejemplo, crear nuevas subinterfaces como s0.2, s0.3)

Troubleshooting:
#show interface
#show frame-relay pvc
#show frame-relay map
#ping
#show controller


2) Utilizando las interfaces Aux
Si te encuentras construyendo un Lab seguramente deseeas tener muchas conexiones para realizar muchas pruebas. Algo que puede ser muy util es conectar dos routers back2back utilizando el cable de consola entre dos routers en sus puertos Aux. La configuracion seria la siguiente:

Primo debes averiguar en cada router el numero de la interfaz Async, recomiendo que entres en modo configuracion global e intentes configurar la interfaz async1 a la async5.

En ambos routers lleva una configuracion como esta (ojo con los IPs). Esta configuracion permite IP, protocolos de enrutamiento, etc. Es muy importante que el txspeed en un router sea el rxspeed en el otro y viceversa.

interface Async1
ip address 192.168.10.1 255.255.255.0
encapsulation ppp
async default routing
async mode dedicated
!
line aux 0
modem InOut
transport input all
rxspeed 38400
txspeed 38400
flowcontrol hardware

Troubleshooting:
#show line
#ping


3) Utilizando enthernet

Tan solo es necesario un cable cruzado entre los puertos ethernet de los routers


Suerte y espero haya sido util esta informacion

Una mejora práctica en el Transporte DNS sobre UDP en IPv6

Por Hugo Salgado y Alejandro Acosta Introducción y planteamiento del problema En el presente documento queremos discutir sobre un draft (bor...