El Bidirectional Forwarding Detection (BFD) es un protocolo que provee un mecanismo de keep alive de detección que puede ser utilizado por otros componentes de de red para los cuales el mecanismo es muy lento y/o inapropiado o inexistente, tal puede ser el caso de los protocolos de rute IGP tipo OSPF o EGP tipo BGP.
Usando BFD y OSPF el escenario propuesto para esta práctica es el siguiente:
Con este esquema el DR es R2 y la mejor ruta elegida hacia R4 es a traves de R1, cuando el enlace entre R1 y R4 falla el tiempo de convergencia es menor que sin el uso de BFD.
La configuración es muy simple, basta con habilitar en todos los router BFD dentro de la sección para OSPF
miércoles, 18 de febrero de 2015
VRF lite
El uso de VRF es la capacidad que nos provee un router para dividir a este router y su tabla de enrutamiento en múltiples; de ahí su nombre VRF (Virtual Routing and Forwarding).
Una aplicación para esto podría ser en el caso de un proveedor de servicios (ISP) con múltiples clientes.
Es de esperar que los diferentes clientes no deben de ser accesados por otros clientes, ni deben compartir el medio.
VRF Lite nos permitiría esto ya que cada VRF tendrá su propia tabla de enrutamiento y los clientes en diferentes VRF's no podrán accesar otros clientes en diferentes VRFs.
El escenario planteado es el siguiente:
Bajo este esquema de conectividad propuesto los clientes deben tener acceso uno a uno y no tener visibilidad de ninguno otro cliente, la correspondencia debe ser uno a uno de la siguiente forma.
R1←→R4
R2←→R5
R3←→R6
Una aplicación para esto podría ser en el caso de un proveedor de servicios (ISP) con múltiples clientes.
Es de esperar que los diferentes clientes no deben de ser accesados por otros clientes, ni deben compartir el medio.
VRF Lite nos permitiría esto ya que cada VRF tendrá su propia tabla de enrutamiento y los clientes en diferentes VRF's no podrán accesar otros clientes en diferentes VRFs.
El escenario planteado es el siguiente:
R1←→R4
R2←→R5
R3←→R6
viernes, 6 de febrero de 2015
Características OSPF
Este es un Laboratorio de OSPF que pretende comprender el uso de las aréas y los tipos de LSA que maneja en la configuración.
Está es la topología de red que he usado.
Está es la topología de red que he usado.
lunes, 12 de enero de 2015
Configuraciones para OSPF sobre Frame Relay
Este tema nos permite entender como opera el protocolo OSPF sobre redes non-broadcast permitiendo el envío de mensajes tipo hello a diferencia del entorno ethernet (broadcast) por medio de mensajes unicast, podemos ver como debemos configurarla en un esquema Hub-and-spoke, está técnica fue creada para redes legacy que no soportan transmisión broadcast (HDLC/PPP).
Entrando de lleno en el ejemplo vemos que tenemos una red Frame-Relay donde existen 2 PVC uno entre R1 y R2 y otro entre R2 y R3 pero no tenemos un circuito entre R1 y R3 lo cual puede impedir el intercambio de información de la red cuando R1 y R3 es elegido como DR (o Router designado) por que no hay forma de que envíen paquetes directamente R1 y R3 por que deben pasar por el PVC hacía R2 respectivamente.
El estado de los PVC
Entrando de lleno en el ejemplo vemos que tenemos una red Frame-Relay donde existen 2 PVC uno entre R1 y R2 y otro entre R2 y R3 pero no tenemos un circuito entre R1 y R3 lo cual puede impedir el intercambio de información de la red cuando R1 y R3 es elegido como DR (o Router designado) por que no hay forma de que envíen paquetes directamente R1 y R3 por que deben pasar por el PVC hacía R2 respectivamente.
Para resolver el problema usaremos ip ospf network point-to-point con lo cual no hay elección de DR/BDR router y esto se sustituye por un proceso especial para determinar next-hop como se puede ver en R2 con el comando show ip ospf neightbor.
R2#show ip ospf neighbor
Neighbor ID Pri State Dead Time Address Interface
1.1.1.1 0 FULL/ - 00:00:31 10.10.10.1 Serial2/0
3.3.3.3 0 FULL/ - 00:00:38 10.10.10.6 Serial2/1
R2#SHOW FRAMe-relay PVC SUMMary
Frame-Relay VC Summary
Active Inactive Deleted Static
Local 2 0 0 0
Switched 0 0 0 0
Unused 0 0 0 0
viernes, 9 de enero de 2015
NAT ON STICK
La técnica de Nat on Stick consiste en combinar policy-map y NAT con la finalidad de enviar y recibir datos de diferente segmento por la misma interface, a decir de la documentación oficial de CISCO son pocas las ocasiones en que se utiliza esta técnica en la imagen 1 tenemos el caso básico en el cual aplica y sirve para entender el funcionamiento, en este caso los paquetes entrantes a R1 que procedan la dirección ip 192.168.1.2 serán siempre redirecciovados a la interface Loopback 0 y se hará NAT.
Para comprender como son tratados los paquete habilitamos los debug:
debug ip policy
debug ip nat
En la prueba inicial el R2 manda un traceroute a una ip fuera de su red en este caso 8.8.8.8
R2#traceroute 8.8.8.8
Type escape sequence to abort.
Tracing the route to 8.8.8.8
1 192.168.1.1 40 msec 40 msec 48 msec
2 2.2.2.2 !H !H *
Y el debug muestra que se aplica el policy route-map y el NAT correctamente obviamente no encontramos el destino.
*Dec 27 11:41:20.931: IP: s=192.168.1.2 (FastEthernet0/0), d=8.8.8.8, len 28, policy match
*Dec 27 11:41:20.931: IP: route map LOOP, item 10, permit
*Dec 27 11:41:20.931: IP: s=192.168.1.2 (FastEthernet0/0), d=8.8.8.8 (Loopback0), len 28, policy routed
*Dec 27 11:41:20.935: IP: FastEthernet0/0 to Loopback0 0.0.130.158
*Dec 27 11:41:20.935: NAT: s=192.168.1.2->2.2.2.2, d=8.8.8.8 [298]
*Dec 27 11:41:20.939: NAT: s=2.2.2.2, d=2.2.2.2->192.168.1.2 [64]
Vemos el que el fue NAT aplicado correctamente.
R1#show ip nat translations
Pro Inside global Inside local Outside local Outside global
udp 2.2.2.2:49211 192.168.1.2:49211 8.8.8.8:33437 8.8.8.8:33437
udp 2.2.2.2:49212 192.168.1.2:49212 8.8.8.8:33438 8.8.8.8:33438
jueves, 8 de enero de 2015
Generic Routing Encapsulation (GRE)
Generic Routing Encapsulation (GRE) es un protocolo de túnel que puede encapsular una amplia variedad de protocolo de capa de red tipos de paquetes dentro de un túnel IP , creando un virtual punto de enlace a varios routers en puntos remotos a través de un Protocolo de Internet ( IP) de redes.
En las adyacencias tenemos que el protocolo principal de ruteo es OSPF e interiormente EIGRP para la comunicación del las redes que van por el túnel GRE.
OSPF
R1_GRE#show ip ospf neighbor
Neighbor ID Pri State Dead Time Address Interface
2.2.2.2 1 EXSTART/DR 00:00:36 192.168.20.2 GigabitEthernet1/0
R2_GRE#show ip ospf neighbor
Neighbor ID Pri State Dead Time Address Interface
3.3.3.3 1 FULL/DR 00:00:35 192.168.20.6 GigabitEthernet2/0
1.1.1.1 1 FULL/BDR 00:00:38 192.168.20.1 GigabitEthernet1/0
R3_GRE#show ip ospf neighbor
Neighbor ID Pri State Dead Time Address Interface
2.2.2.2 1 FULL/BDR 00:00:32 192.168.20.5 GigabitEthernet0/0
EIGRP
R1_GRE#show ip eigrp neighbors
EIGRP-IPv4 Neighbors for AS(100)
H Address Interface Hold Uptime SRTT RTO Q Seq
(sec) (ms) Cnt Num
0 192.168.0.2 Tu0 11 00:00:58 44 1434 0 3
EIGRP-IPv4 Neighbors for AS(100)
H Address Interface Hold Uptime SRTT RTO Q Seq
(sec) (ms) Cnt Num
0 192.168.0.1 Tu0 11 00:01:27 48 1434 0 3
Suscribirse a:
Comentarios (Atom)
Pi-hole + OMV
Antecedentes Estos son los pasos para el caso particular, instalar Pi-hole como DNS para nuestra red local en nuestra Raspberry ...
-
Tengo un servicio Infinitum de TELMEX el cuál no me permitia conectar a mi empresa usando el cliente VPN de Cisco (Cisco VPN client), mi mod...
-
Banco de Occidente, 1 Peso, Quezaltenango, Guatemala, 1880 El Banco Internacional de Guatemala, 1 Peso, 1914
-
Banco Internacional de Costa Rica, Especimen 2 Colones, Mona Lisa Banco Internacional de Costa Rica, Especimen 2 Colones, 1937





