Tolerancia a fallos
Disclaimer: Todas las pruebas se realizaron en un ambiente simulado por GNS3 en su versión 2.2.46. La imagen de los switches es la “Vios_l2-ADVENTERPRISEK9-M - 15.2(20200924:215240)” y de los routers es “VIOS-ADVENTERPRISEK9-M - 15.9(3)M6”. Con el único motivo de continuar mi aprendizaje.
Con el objetivo de mostrar cómo la red se comporta ante las incidencias, simulé diferentes problemas a lo largo de una comunicación desde el PC de la oficina de administración hacia un servidor en internet. Ahora bien, cuando el PC se enciende, este busca un servidor DHCP disponible enviando un mensaje de descubrimiento. El switch B-00-SW01 que posee la configuración de DHCP relay agent, enviará estas solicitudes al servidor pasando por uno de los switches de core.
Ahora bien, tanto el switch de core A-00-SW01 como A-00-SW02 aprenden por OSPF una ruta sumarizada al data center, como al edificio B. Por lo tanto, ambos switches han aprendido las mismas redes, por el mismo protocolo, y además, comparten la misma métrica al destino. Por consiguiente, el equipo desempeña balanceo de carga entre ambos caminos, Equal-cost multipath (ECMP). Seguido, Cisco Express Forwarding (CEF) está encargado de la selección de ese camino. Por defecto, utiliza pre-destination sharing, reenviando un flujo de paquetes origen-destino por la misma interfaz. El siguiente cuadro muestra lo antes mencionado y el camino seleccionado por CEF para la PC de administración con destino el servidor DHCP.
A-00-SW01#show ip route 1.1.2.1
Routing entry for 1.1.2.0/24
Known via "ospf 109", distance 110, metric 21, type inter area
Last update from 192.168.0.38 on GigabitEthernet0/2, 00:03:38 ago
Routing Descriptor Blocks:
* 192.168.0.46, from 1.1.1.8, 00:46:04 ago, via GigabitEthernet0/3
Route metric is 21, traffic share count is 1
192.168.0.38, from 1.1.1.7, 00:03:38 ago, via GigabitEthernet0/2
Route metric is 21, traffic share count is 1
A-00-SW01#show ip cef 1.1.2.1 detail
1.1.2.0/24, epoch 0, per-destination sharing
nexthop 192.168.0.38 GigabitEthernet0/2
nexthop 192.168.0.46 GigabitEthernet0/3
A-00-SW01#show ip cef exact-route 10.0.100.20 1.1.2.1
10.0.100.20 -> 1.1.2.1 =>IP adj out of GigabitEthernet0/2, addr 192.168.0.38
A-00-SW01#show cef state
—----- texto omitido —--------
IPv4 CEF Status:
CEF enabled/running
universal per-destination load sharing algorithm, id F81E2C26
Es importante destacar que, para evitar la polarización de las rutas, es decir, el uso constante de las mismas rutas para el mismo par de origen y destino, cada equipo tiene asignado un ID universal. Este ID garantiza diferentes resultados en el algoritmo, lo que se traduce en distintos caminos para el mismo par de origen y destino . Este mismo principio se aplicará únicamente en capa 3 para los routers, NATs, VPN, servidores y switches de distribución.
Dicho esto, pasemos a examinar los escenarios… Escenario 1 - Datacenter: Supongamos que ocurriera una falla en el enlace que une al switch A-03-SV01 con el servidor DHCP, como se puede apreciar en la siguiente imagen. Como mencioné anteriormente, debido a la configuración del datacenter en otra área OSPF que el core, los problemas dentro del bloque no influyen en otras áreas. Por ende, los switches de core, siguen viendo una ruta sumarizada a los servicios. A-03-SV01 es el único afectado por tener un enlace directo al servidor DHCP. Luego de la convergencia, OSPF añade una nueva ruta a su destino en la tabla de enrutamiento por medio del PortChannel Po1. Es de suma importancia que ese portchannel sea L3, ya que de lo contrario se produciría un blackhole. Esto significa que el core tiene una ruta al servidor DHCP por el switch SV01, pero éste, no tiene una ruta al servidor en su tabla de enrutamiento. Por otro lado, si la comunicación se hubiera efectuado por medio de A-03-SV02, no habría sufrido ningún inconveniente. El siguiente cuadro muestra la ruta inicial y la ruta que la reemplaza después del fallo.
A-03-SV01#show ip route 1.1.2.1
Routing entry for 1.1.2.1/32
Known via "ospf 109", distance 110, metric 11, type intra area
172.22.32.5, from 1.1.2.1, 00:41:30 ago, via GigabitEthernet3/0
Route metric is 11, traffic share count is 1
A-03-SV01#
*Apr 17 16:43:40.624: %BFDFSM-6-BFD_SESS_DOWN: BFD-SYSLOG: BFD session ld:1 handle:1, is going Down Reason: ECHO FAILURE
*Apr 17 16:43:40.634: %BFD-6-BFD_SESS_DESTROYED: BFD-SYSLOG: bfd_session_destroyed, ld:1 neigh proc:OSPF, handle:1 act
*Apr 17 16:43:40.635: %OSPF-5-ADJCHG: Process 109, Nbr 1.1.2.1 on GigabitEthernet3/0 from FULL to DOWN, Neighbor Down: BFD node down
*Apr 17 16:43:41.788: %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet3/0, changed state to down
*Apr 17 16:43:42.683: %LINK-3-UPDOWN: Interface GigabitEthernet3/0, changed state to down
A-03-SV01#show ip route 1.1.2.1
Routing entry for 1.1.2.1/32
Routing Descriptor Blocks:
* 172.22.32.2, from 1.1.2.1, 00:00:09 ago, via Port-channel1
Route metric is 16, traffic share count is 1
A-03-SV02#show ip route 1.1.2.1
Routing entry for 1.1.2.1/32
Routing Descriptor Blocks:
* 172.22.32.9, from 1.1.2.1, 00:41:29 ago, via GigabitEthernet3/0
Route metric is 11, traffic share count is 1
Para ver todas las pruebas de fallas realizadas en el data center y como la red responde ante ellas, haz clic aquí, y luego dirígete al apartado “NETWORKING - Building A - Data Center”. La siguiente imagen muestra dos flujos de datos que tiene como destino el servidor DHCP.
Siguiendo con el ejemplo, nuestra PC ya tiene una dirección IP y está lista para navegar en internet. Para establecer una comunicación a internet, éste envía el tráfico a su puerta de enlace por defecto, 10.0.100.1, que en este diseño corresponde a B-00-SW01. Es importante destacar que el switch B-00-SW01 es el maestro del dominio VRRP, y tiene una interfaz virtual con la IP mencionada y su correspondiente MAC virtual. El siguiente cuadro muestra lo antes mencionado.
B-00-SW01#show vrrp
Vlan100 - Group 100
State is Master
Virtual IP address is 10.0.100.1
Virtual MAC address is 0000.5e00.0164
B-01-SW01#sho mac address-table dynamic interface g0/0
Mac Address Table
-------------------------------------------
Vlan Mac Address Type Ports
---- ----------- -------- -----
100 0000.5e00.0164 DYNAMIC Gi0/0
1000c94.7ab2.0002DYNAMIC Gi0/0
vlan100-ADM> show arp
00:00:5e:00:01:64 10.0.100.1 expires in 112 seconds
Ahora bien, todos los switches de acceso tienen enlaces redundantes a la capa de distribución. Por ende, en caso de que alguno falle, RSTP se encargaría de habilitar un camino alternativo. Tener en cuenta, que en realidad estamos utilizando el protocolo de Cisco rapid-pvst, lo que implica que estamos utilizando RSTP por VLAN.
Escenario - 2 - Edificio B: Supongamos que el switch de distribución B-00-SW01 falla y deja de funcionar. El tráfico asociado a él, o sea, las primeras ocho redes de usuarios, se verían afectadas. Esto quiere decir que habrá un pequeño downtime hasta que RSTP converja habilitando un nuevo camino para el tráfico y VRRP cambie de Backup a Maestro en el switch B-00-SW02.
B-01-SW01#
*Apr 18 10:53:19.023: %LINK-5-CHANGED: Line protocol on Interface GigabitEthernet0/0, changed state to down
*Apr 18 10:53:20.024: %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet0/0, changed state to down
B-01-SW01#show spanning-tree inter g0/0
no spanning tree info available for GigabitEthernet0/0
B-01-SW01#show spanning-tree inter g0/1
Vlan Role Sts Cost Prio.Nbr Type
------------------- ---- --- --------- --------
VLAN0100 Root FWD 4 128.2 P2p
VLAN0101 Root FWD 4 128.2 P2p
VLAN0102 Root FWD 4 128.2 P2p
VLAN0103 Root FWD 4 128.2 P2p
VLAN0104 Root FWD 4 128.2 P2p
VLAN0105 Root FWD 4 128.2 P2p
VLAN0106 Root FWD 4 128.2 P2p
VLAN0107 Root FWD 4 128.2 P2p
VLAN0108 Root FWD 4 128.2 P2p
VLAN0109 Root FWD 4 128.2 P2p
VLAN0110 Root FWD 4 128.2 P2p
VLAN0111 Root FWD 4 128.2 P2p
VLAN0112 Root FWD 4 128.2 P2p
VLAN0113 Root FWD 4 128.2 P2p
VLAN0114 Root FWD 4 128.2 P2p
VLAN0115 Root FWD 4 128.2 P2p
VLAN0116 Root FWD 4 128.2 P2p
En esta imagen se puede apreciar que al fallar B-00-SW01, B-01-SW01 pierde la conectividad por su interfaz G0/0. Luego, todas las redes que administra, cambian su relación STP ante el nuevo root bridge que es B-00-SW02. En la siguiente imagen, los logs muestran que ante una falla de B-00-SW01, B-00-SW02 se convierte en el Master de todas las redes.
*Apr 18 10:53:06.936: %VRRP-6-STATECHANGE: Vl105 Grp 105 state Backup -> Master
*Apr 18 10:53:06.878: %VRRP-6-STATECHANGE: Vl101 Grp 101 state Backup -> Master
*Apr 18 10:53:06.990: %VRRP-6-STATECHANGE: Vl102 Grp 102 state Backup -> Master
*Apr 18 10:53:07.016: %VRRP-6-STATECHANGE: Vl108 Grp 108 state Backup -> Master
*Apr 18 10:53:07.056: %VRRP-6-STATECHANGE: Vl104 Grp 104 state Backup -> Master
*Apr 18 10:53:07.208: %VRRP-6-STATECHANGE: Vl106 Grp 106 state Backup -> Master
*Apr 18 10:53:07.349: %VRRP-6-STATECHANGE: Vl100 Grp 100 state Backup -> Master
*Apr 18 10:53:07.445: %VRRP-6-STATECHANGE: Vl107 Grp 107 state Backup -> Master
*Apr 18 10:53:07.509: %VRRP-6-STATECHANGE: Vl103 Grp 103 state Backup -> Master
B-00-SW02#show vrrp brief
Interface Grp Pri Time Own Pre-State Master addr Group addr
Vl100 100 100 3609 Y Master 10.0.100.253 10.0.100.1
Vl101 101 100 3609 Y Master 10.0.101.253 10.0.101.1
Vl102 102 100 3609 Y Master 10.0.102.253 10.0.102.1
Vl103 103 100 3609 Y Master 10.0.103.253 10.0.103.1
Vl104 104 100 3609 Y Master 10.0.104.253 10.0.104.1
Vl105 105 100 3609 Y Master 10.0.105.253 10.0.105.1
Vl106 106 100 3609 Y Master 10.0.106.253 10.0.106.1
Vl107 107 100 3609 Y Master 10.0.107.253 10.0.107.1
Vl108 108 100 3609 Y Master 10.0.108.253 10.0.108.1
Vl109 109 150 3414 Y Master 10.0.109.253 10.0.109.1
Vl110 110 150 3414 Y Master 10.0.110.253 10.0.110.1
Vl111 111 150 3414 Y Master 10.0.111.253 10.0.111.1
Vl112 112 150 3414 Y Master 10.0.112.253 10.0.112.1
Vl113 113 150 3414 Y Master 10.0.113.253 10.0.113.1
Vl114 114 150 3414 Y Master 10.0.114.253 10.0.114.1
Vl115 115 150 3414 Y Master 10.0.115.253 10.0.115.1
Vl116 116 150 3414 Y Master 10.0.116.253 10.0.116.1
Una vez que esto suceda, B-00-SW02 enviará el tráfico de las primeras ocho redes de usuarios al NAT1 por medio del túnel 1 gracias a una política de ruteo. Mientras que, de las ocho redes restantes, van a ser enviadas al NAT02 por medio del túnel 2, gracias a una ruta por defecto. Cabe destacar que ambos switches de distribución poseen una política de ruteo para distribuir el tráfico a su correspondiente router NAT en caso que uno de ellos falle. En caso de que además del switch B-00-SW01, el router NAT01 tenga un problema, todo el tráfico con destino a internet que pase por B-00-SW02 se redirigirá al router NAT02 y viceversa.
vlan100-ADM> trace 172.16.100.1
trace to 172.16.100.1, 8 hops max, press Ctrl+C to stop
1 10.0.100.253 54.190 ms 19.268 ms 38.097 ms -> B-00-SW02 (VLAN100)
2 192.168.0.74 32.571 ms 29.612 ms 40.322 ms -> A-00-NAT01 (Tu2)
3 192.168.0.61 95.986 ms 62.079 ms 42.644 ms -> A-00-SW01 (G1/3)
4 192.168.0.1 43.666 ms 42.091 ms 54.275 ms -> A-00-RT01 (G0/0)
5 192.168.255.2 54.545 ms -> ISP10
vlan116-AAL> tracer 172.16.100.1
trace to 172.16.100.1, 8 hops max, press Ctrl+C to stop
1 10.0.116.253 19.649 ms 24.897 ms 37.691 ms -> B-00-SW02 (VLAN116)
2 192.168.0.90 28.649 ms 29.373 ms 27.539 ms -> A-00-NAT02 (Tu2)
3 192.168.0.77 46.313 ms 39.938 ms 43.738 ms -> A-00-SW01 (G2/0
4 192.168.0.13 53.058 ms 59.646 ms 65.481 ms -> A-00-RT02 (G0/1)
5 192.168.254.2 64.714 ms -> ISP10
Para ver todas las pruebas de fallas realizadas en el Edificio B y como la red responde ante ellas, haz clic aquí, y luego dirígete al apartado “NETWORKING - Building B”.
Continuando con la trayectoria del flujo de datos a internet, estos van a ser encapsulados por el protocolo GRE y de esa forma el tráfico viaja como si fuera dentro de un túnel. Como se puede ver en la imagen, la nueva cabecera IP agregada, contiene las direcciones IP de los equipos extremos, 1.1.1.6 que corresponde al switch B-00-SW02 y 1.1.1.16 al router NAT02.
A-00-NAT01#show ip nat translations
Pro Inside global Inside local Outside local Outside global
udp 192.168.139.3:33729 10.0.100.20:33729 172.16.100.1:33730 172.16.100.1:33730
A-00-NAT02#show ip nat translations
Pro Inside global Inside local Outside local Outside global
udp 192.168.139.67:1393 10.0.116.20:1393 172.16.100.1:1394 172.16.100.1:1394
Nota: Si bien se recomienda evitar la fragmentación de paquetes, la creación de túneles puede generar fragmentación. Para mitigar esto, se configuró el ajuste de MSS para el tráfico TCP y se habilitó "path-mtu-discovery" para el tráfico UDP. Cabe destacar, que al momento los túneles son necesarios para alcanzar a los routers NAT, dado que aún no he encontrado una solución para ello y que, además, garantice la redundancia.
Al utilizar las IP de loopback en la configuración de los túneles, los switches de core pueden enviar los paquetes aun cuando uno de los enlaces de los router NATs tenga un problema ya que están redundados y eso nos lleva a un nuevo escenario.
Escenario - 3 - Edificio A (Core): Supongamos que en la trayectoria del tráfico desde el switch A-00-SW02 hacia el router NAT02 , el enlace que los une contempla una falla. Tras una convergencia de OSPF el switch dispone de un nuevo camino para alcanzar a NAT02. Este es a través del switch SW01 por medio del Port Channel Po1. La siguiente imagen muestra como después del problema en la interfaz G2/0, la ruta hacia NAT02 cambia por el Port-Channel1.
A-00-SW02#show ip route 1.1.1.16
Routing entry for 1.1.1.16/32
Known via "ospf 109", distance 110, metric 11, type intra area
Last update from 192.168.0.82 on GigabitEthernet2/0, 00:02:33 ago
Routing Descriptor Blocks:
* 192.168.0.82, from 192.168.139.65, 00:02:33 ago, via GigabitEthernet2/0
Route metric is 11, traffic share count is 1
*Apr 19 07:07:33.159: %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet2/0, changed state to down
*Apr 19 07:07:34.154: %LINK-3-UPDOWN: Interface GigabitEthernet2/0, changed state to down
A-00-SW02#show ip route 1.1.1.16
Routing entry for 1.1.1.16/32
Known via "ospf 109", distance 110, metric 14, type intra area
Last update from 192.168.0.33 on Port-channel1, 00:04:10 ago
Routing Descriptor Blocks:
* 192.168.0.33, from 192.168.139.65, 00:04:10 ago, via Port-channel1
Route metric is 14, traffic share count is 1
Escenario - 4 - Edificio A (Core): Supongamos que el switch A-00-SW02 tiene un problema y deja de funcionar. Los usuarios del edificio B van a enviar su tráfico al switch de distribución B-00-SW02 ya que B-00-SW01 sigue con problemas (escenario 2). Este, de igual manera, va a formar los túneles para el tráfico a internet. El tráfico va a viajar encapsulado por el switch A-00-SW01 hasta los router NAT01 y NAT02 respectivamente, y luego, de vuelta al switch SW01 para ser enrutado a internet.
*Apr 19 13:01:21.571: %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet1/0, changed state to down
*Apr 19 13:01:22.580: %LINK-3-UPDOWN: Interface GigabitEthernet1/0, changed state to down
B-00-SW02#show ip inter bri | e una
Interface IP-Address OK? Method Status Protocol
GigabitEthernet1/0 192.168.0.26 YES NVRAM down down
GigabitEthernet1/1 192.168.0.22 YES NVRAM up up
Loopback0 1.1.1.6 YES NVRAM up up
Tunnel1 192.168.0.73 YES NVRAM up up
Tunnel2 192.168.0.89 YES NVRAM up up
—----- Resto del texto omitido —--------
B-00-SW02#sho ip cef 1.1.1.15
1.1.1.15/32
nexthop 192.168.0.21 GigabitEthernet1/1
B-00-SW02#sho ip cef 1.1.1.16
1.1.1.16/32
nexthop 192.168.0.21 GigabitEthernet1/1
A-00-SW01#sho ip cef 1.1.1.15
1.1.1.15/32
nexthop 192.168.0.62 GigabitEthernet1/3
A-00-SW01#sho ip cef 1.1.1.16
1.1.1.16/32
nexthop 192.168.0.78 GigabitEthernet2/0
A-00-NAT01#show ip nat translations
Pro Inside global Inside local Outside local Outside global
icmp 192.168.139.3:43644 10.0.100.20:43644 172.16.100.1:43644 172.16.100.1:43644
A-00-NAT02#show ip nat translations
Pro Inside global Inside local Outside local Outside global
icmp 192.168.139.67:48508 10.0.116.20:48508 172.16.100.1:48508 172.16.100.1:48508
La imagen muestra la secuencia de todo lo antes mencionado. Inicialmente, desde la perspectiva de B-00-SW02, cuando cae la interfaz G1/0 que lo vincula con A-00-SW02. Seguido, de su siguiente salto hacia los routers NATs, que ahora es a través del switch A-00-SW01 únicamente. Luego, desde la perspectiva del switch de core A-00-SW01, el siguiente salto a los NATs, y finalmente, la traducción de las IPs privadas a las públicas.
Una vez que cada router NAT haga la traducción de IP privada a pública, es el momento de enviar los paquetes a internet. Como mencioné en la descripción general, para mantener el tráfico lo más simétrico posible, los switches de core tienen un política de enrutamiento aplicada al tráfico proveniente de routers NATs. O sea, que el tráfico proveniente del router NAT02, independientemente si llega al switch SW01 o SW02, es enviado al router de internet RT02. De igual manera, también aplica para el tráfico proveniente del NAT01 que es enviado al router RT01. La siguiente imagen muestra la política de ruteo en el switch A-00-SW01 y una traza desde el PC de administración a Internet.
A-00-SW01#show access-lists net13964-to-rt02
Extended IP access list net13964-to-rt02
10 permit ip 192.168.139.64 0.0.0.31 any (9 matches)
A-00-SW01#show route-map nat02-to-rt02
route-map nat02-to-rt02, permit, sequence 10
Match clauses:
ip address (access-lists): net13964-to-rt02
Set clauses:
ip next-hop 192.168.0.13 192.168.0.34
Policy routing matches: 9 packets, 954 bytes
vlan116-AAL> tracer 172.16.100.1
trace to 172.16.100.1, 8 hops max, press Ctrl+C to stop
1 10.0.116.253 31.674 ms 33.395 ms 20.900 ms -> B-00-SW02 (Vlan116)
2 192.168.0.90 37.280 ms 41.506 ms 38.027 ms -> A-00-NAT02 (Tu2)
3 192.168.0.77 48.460 ms 87.700 ms 54.934 ms -> A-00-SW01 (G2/0)
4 192.168.0.13 45.858 ms 44.470 ms 51.764 ms -> A-00-RT02 (G0/1)
5 *192.168.254.2 43.102 ms -> ISP10
Escenario 5 - Edificio A (core): Para el siguiente ejemplo el router A-00-RT01 presenta un problema. Por consiguiente, el router A-00-RT02 se va a encargar de todas las comunicaciones que van a internet. Como se puede apreciar en la imagen anterior la política de ruteo en el switch de core A-00-SW01 solo afecta al tráfico con IP pública proveniente del router NAT02, mientras que el tráfico proveniente del router NAT01 utiliza la ruta por defecto. Cabe destacar que esta situación también aplica a SW02 pero en sentido contrario.
Ahora bien, A-00-SW01 tiene configurado una ruta estática flotante, esto quiere decir que si la ruta principal tiene un problema, o sea la ruta por defecto al router A-00-RT01, esta ruta secundaria se instala en la tabla de ruteo. La siguiente imagen, muestra la configuración de las rutas estáticas, y como la ruta flotante se ha instalado en la tabla de ruteo ya que RT01 ha tenido un problema.
A-00-SW01#show run | section ip route
ip route 0.0.0.0 0.0.0.0 1.1.1.1
ip route 0.0.0.0 0.0.0.0 1.1.1.2 5
ip route 10.2.100.0 255.255.255.0 192.168.0.53
A-00-SW01#show ip route static
—-- Se han omitido los Codes —------
Gateway of last resort is 1.1.1.2 to network 0.0.0.0
S* 0.0.0.0/0 [5/0] via 1.1.1.2
10.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
S 10.2.100.0/24 [1/0] via 192.168.0.53
Por lo tanto, el tráfico proveniente del router NAT01, o sea de las ocho primeras vlans, llegará como corresponde al switch de core A-00-SW01. Pero este, al no tener conectividad con el router de internet A-00-RT01 va a enviar el tráfico por su ruta estática flotante al router RT02 y luego a internet.
vlan100-ADM> tracer 172.16.100.1
trace to 172.16.100.1, 8 hops max, press Ctrl+C to stop
1 10.0.100.253 53.306 ms 26.391 ms 24.632 ms -> B-00-SW02 (Vlan116)
2 192.168.0.74 32.571 ms 29.612 ms 40.322 ms -> A-00-NAT01 (Tu2)
3 192.168.0.61 53.695 ms 44.801 ms 41.136 ms -> A-00-SW01 (G1/3)
4 192.168.0.13 46.678 ms 49.756 ms 39.173 ms -> A-00-RT02 (G0/1)
5 *192.168.254.2 37.886 ms (ICMP type:3, code:3, Destination port unreachable)
Un punto importante del diseño es que las direcciones IP públicas están asignadas a los routers NAT y no a los routers de internet. De esta manera, los routers A-00-RT01 y RT02 las aprenden por OSPF y luego las publican por BGP a los ISP. Para el escenario 5, el router RT01 dejará de anunciarse y el router del proveedor ISP10 recalculará cómo llegar a la red 192.168.139.0/27. Que, a fin de cuentas, es a través de RT02. Por otro lado, si el problema se presenta en uno de los routers NAT, por ejemplo NAT01, éste dejaría de anunciar la red por OSPF y los router de internet dejarían de aprenderla. Por ende, de anunciar por BGP. La siguiente imagen muestra los log del proveedor ISP10 al fallar el router RT01 y la nueva ruta al destino. Por otro lado, también muestra el proveedor ISP20 y las rutas al destino.
ISP01#
*Apr 19 15:05:48.256: %BGP-3-NOTIFICATION: sent to neighbor 192.168.255.1 4/0 (hold time expired) 0 bytes
*Apr 19 15:05:48.262: %BGP-5-NBR_RESET: Neighbor 192.168.255.1 reset (BGP Notification sent)
*Apr 19 15:05:48.282: %BGP-5-ADJCHANGE: neighbor 192.168.255.1 Down BGP Notification sent
*Apr 19 15:05:48.283: %BGP_SESSION-5-ADJCHANGE: neighbor 192.168.255.1 IPv4 Unicast topology base removed from session BGP Notification sent
ISP01#show ip route bgp
—-- Se han omitido los Codes —------
Gateway of last resort is not set
192.168.139.0/27 is subnetted, 2 subnets
B 192.168.139.0 [20/21] via 192.168.254.1, 00:39:01 -> A-00-RT02 (G0/2)
B 192.168.139.64 [20/21] via 192.168.254.1, 01:57:57 -> A-00-RT02 (G0/2)
AS-20#show ip route bgp
—-- Se han omitido los Codes —------
Gateway of last resort is not set
192.168.139.0/27 is subnetted, 2 subnets
B 192.168.139.0 [20/21] via 192.168.252.1, 00:04:14 -> A-00-RT02 (G0/3)
B 192.168.139.64 [20/21] via 192.168.252.1, 00:04:14 -> A-00-RT02 (G0/3)
Escenario 6 - Internet: El router A-00-RT01 no funciona al momento y uno de nuestros proveedores, ISP20, ha fallado también. Por ende, y gracias a la conexión dual multi-homed, la única alternativa es por el proveedor ISP10 via el router de internet A-00-RT02. La siguiente imagen muestra las notificaciones del problema del proveedor ISP20 y la nueva tabla de ruteo de RT02.
A-00-RT02#
*Apr 19 15:42:08.495: %BGP-3-NOTIFICATION: sent to neighbor 192.168.252.2 4/0 (hold time expired) 0 bytes
*Apr 19 15:42:08.501: %BGP-5-NBR_RESET: Neighbor 192.168.252.2 reset (BGP Notification sent)
*Apr 19 15:42:08.511: %BGP-5-ADJCHANGE: neighbor 192.168.252.2 Down BGP Notification sent
*Apr 19 15:42:08.512: %BGP_SESSION-5-ADJCHANGE: neighbor 192.168.252.2 IPv4 Unicast topology base removed from session BGP Notification sent
A-00-RT02#show running | s ip route
ip route 0.0.0.0 0.0.0.0 192.168.252.2
ip route 0.0.0.0 0.0.0.0 192.168.254.2 5
A-00-RT02#show ip route bgp
—-- Se han omitido los Codes —------
Gateway of last resort is 192.168.254.2 to network 0.0.0.0
172.16.0.0/24 is subnetted, 2 subnets
B 172.16.98.0 [20/0] via 192.168.254.2, 00:48:06
B 172.16.100.0 [20/0] via 192.168.254.2, 04:38:31
Para concluir, la siguiente imagen muestra todos los escenarios formulados en la red y los flujos de datos representados por distintos colores. Si estás interesado en ver todas las pruebas de fallas realizadas en el diseño y como la red responde antes ellas, haz click aquí.
