Diplomado de Profundización CISCO CCNP
Paso 3: Actividad colaborativa 2
Presentado por:
MARILIN VELASCO VELEZ
Presentado a:
GERARDO GRANADOS ACUÑA
Grupo colaborativo:
208014-1
Universidad Nacional Abierta y a Distancia
Vicerrectoría Académica y de Investigación
TABLA DE CONTENIDO
PAGINA N° DE PÁGINA
1.
Introducción 3
2.
Objetivos 4
3.
Desarrollo de la actividad 5
4.
Conclusión 181
5.
Bibliografía 182
INTRODUCCIÓN
Los laboratorios utilizan un modelo de Internet para analizar datos reales sin afectar el
desempeño de la red. Actividades en el software Packet Tracer ayudan a analizar la operación
de la red y de diferentes protocolos, además de construir pequeños ambientes simulados de
redes. Como estudiantes construimos topologías LAN aplicando los conceptos básicos de
cableado, realizando configuraciones en dispositivos como switches y routers, así como la
implementación de esquemas de direccionamiento.
Este trabajo tiene la aplicación de la teoría de CCNP ROUTE en los diferentes laboratorios
en donde se puede evidenciar el funcionamiento de los diferentes protocolos tanto a nivel de
IPv6 como IPv4.
OBJETIVOS
Objetivo general:
Identificar problemas de conectividad en entornos corporativos y residenciales
Objetivos específicos:
•
Implementar Path Control
•
Implementación de una solución Border Gateway Protocolo (BGP) para conectividad ISP
•
Implementación de instalaciones de enrutamiento para sucursales y trabajadores móviles
•
Implementación de IPv6 en la red empresarial
DESARROLLO DE LA ACTIVIDAD
CCNPv7 ROUTE FABIAN BERMUDEZ
Chapter 5 Lab 5-1, Configure and Verify Path Control Using PBR
Topology
Objectives
Configure and verify policy-based routing.
Select the required tools and commands to configure policy-based routing operations. Verify the configuration and operation by using the proper show and debug commands.
Background
You want to experiment with policy-based routing (PBR) to see how it is implemented and to study how it could be of value to your organization. To this end, you have interconnected and
configured a test network with four routers. All routers are exchanging routing information using EIGRP.
Note: This lab uses Cisco 1941 routers with Cisco IOS Release 15.2 with IP Base. Depending on the router or switch model and Cisco IOS Software version, the commands available and output produced might vary from what is shown in this lab.
Required Resources
4 routers (Cisco IOS Release 15.2 or comparable) Serial and Ethernet cables
Step 1: Configure loopbacks and assign addresses.
a. Cable the network as shown in the topology diagram. Erase the startup configuration, and reload each router to clear previous configurations.
b. Using the addressing scheme in the diagram, create the loopback interfaces and apply IP addresses to these and the serial interfaces on R1, R2, R3, and R4. On the serial interfaces connecting R1 to R3 and R3 to R4, specify the bandwidth as 64 Kb/s and set a clock rate on the DCE using the clock rate 64000 command. On the serial interfaces connecting R1 to R2 and R2 to R3, specify the bandwidth as 128 Kb/s and set a clock rate on the DCE using the clock rate 128000 command.
You can copy and paste the following configurations into your routers to begin.
Note
: Depending on the router model, interfaces might be numbered differently than
those listed. You might need to alter them accordingly.
Router R1
hostname R1
!
interface Lo1
description R1 LAN
ip address 192.168.1.1 255.255.255.0
!
interface Serial0/0/0
description R1 --> R2
ip address 172.16.12.1 255.255.255.248
clock rate 128000
bandwidth 128
no shutdown
!
interface Serial0/0/1
description R1 --> R3
ip address 172.16.13.1 255.255.255.248
bandwidth 64
no shutdown
!
end
Router R2
hostname R2
!
interface Lo2
description R2 LAN
ip address 192.168.2.1 255.255.255.0
!
interface Serial0/0/0
description R2 --> R1
ip address 172.16.12.2 255.255.255.248
bandwidth 128
no shutdown
interface Serial0/0/1
description R2 --> R3
ip address 172.16.23.2 255.255.255.248
clock rate 128000
bandwidth 128
no shutdown
!
end
Router R3
hostname R3
!
interface Lo3
description R3 LAN
ip address 192.168.3.1 255.255.255.0
!
interface Serial0/0/0
description R3 --> R1
ip address 172.16.13.3 255.255.255.248
clock rate 64000
bandwidth 64
no shutdown
!
interface Serial0/0/1
description R3 --> R2
ip address 172.16.23.3 255.255.255.248
bandwidth 128
no shutdown
!
interface Serial0/1/0
description R3 --> R4
ip address 172.16.34.3 255.255.255.248
clock rate 64000
bandwidth 64
no shutdown
!
end
Router R4
hostname R4
!
interface Lo4
description R4 LAN A
ip address 192.168.4.1 255.255.255.128
!
interface Lo5
description R4 LAN B
ip address 192.168.4.129 255.255.255.128
!
interface Serial0/0/0
description R4 --> R3
ip address 172.16.34.4 255.255.255.248
bandwidth 64
no shutdown
!
end
c. Verify the configuration with the show ip interface brief, show protocols, and show interfaces description commands. The output from router R3 is shown here as an example.
R3#
show ip interface brief | include up
Serial0/0/0
172.16.13.3
YES manual up
up
Serial0/0/1
172.16.23.3
YES manual up
up
Serial0/1/0
172.16.34.3
YES manual up
up
Loopback3
192.168.3.1
YES manual up
up
R3#
R3#
show protocols
Global values:
Internet Protocol routing is enabled
Embedded-Service-Engine0/0 is administratively down, line
protocol is down
GigabitEthernet0/0 is administratively down, line protocol is
down
GigabitEthernet0/1 is administratively down, line protocol is
down
Serial0/0/0 is up, line protocol is up
Internet address is 172.16.13.3/29
Serial0/0/1 is up, line protocol is up
Internet address is 172.16.23.3/29
Serial0/1/0 is up, line protocol is up
Internet address is 172.16.34.3/29
Serial0/1/1 is administratively down, line protocol is down
Loopback3 is up, line protocol is up
Internet address is 192.168.3.1/24
R3#
R3#
show interfaces description | include up
Se0/0/0
up
up
R3 -->
R1
Se0/0/1
up
up
R3 -->
R2
Se0/1/0
up
up
R3 -->
R4
Lo3
up
up
R3 LAN
R3#
Step 3: Configure basic EIGRP.
a. Implement EIGRP AS 1 over the serial and loopback interfaces as you have configured it for the other EIGRP labs.
b. Advertise networks 172.16.12.0/29, 172.16.13.0/29, 172.16.23.0/29, 172.16.34.0/29, 192.168.1.0/24, 192.168.2.0/24, 192.168.3.0/24, and 192.168.4.0/24 from their respective routers.
You can copy and paste the following configurations into your routers.
Router R1
10
router eigrp 1
network 192.168.1.0
network 172.16.12.0 0.0.0.7
network 172.16.13.0 0.0.0.7
no auto-summary
Router R2
router eigrp 1
network 192.168.2.0
network 172.16.12.0 0.0.0.7
network 172.16.23.0 0.0.0.7
no auto-summary
Router R3
router eigrp 1
network 192.168.3.0
network 172.16.13.0 0.0.0.7
network 172.16.23.0 0.0.0.7
network 172.16.34.0 0.0.0.7
no auto-summary
Router R4
router eigrp 1
network 192.168.4.0
network 172.16.34.0 0.0.0.7
no auto-summary
You should see EIGRP neighbor relationship messages being generated.
Step 4: Verify EIGRP connectivity.
a. Verify the configuration by using the show ip eigrp neighbors command to check which routers have EIGRP adjacencies.
R1#
show ip eigrp neighbors
EIGRP-IPv4 Neighbors for AS(1)
H
Address
Interface
Hold Uptime
SRTT
RTO
Q
Seq
(sec)
(ms)
Cnt Num
1
172.16.13.3
Se0/0/1
10 00:01:55
27 2340 0 9
0
172.16.12.2
Se0/0/0
13 00:02:07
8 1170 0 11
R1#
R2#
show ip eigrp neighbors
EIGRP-IPv4 Neighbors for AS(1)
H
Address
Interface
Hold Uptime
SRTT
RTO
Q
Seq
(sec)
(ms)
Cnt Num
1
172.16.23.3
Se0/0/1
12 00:02:15
12 1170 0 10
0
172.16.12.1
Se0/0/0
11 00:02:27
9 1170 0 13
R2#
R3#
show ip eigrp neighbors
EIGRP-IPv4 Neighbors for AS(1)
H
Address
Interface
Hold Uptime
SRTT
RTO
Q
Seq
(sec)
(ms)
Cnt Num
2
172.16.34.4
Se0/1/0
12 00:02:14
44 2340 0 3
1
172.16.23.2
Se0/0/1
11 00:02:23
10 1170 0 10
0
172.16.13.1
Se0/0/0
10 00:02:23
1031 5000 0 12
11
R3#
R4#
show ip eigrp neighbors
EIGRP-IPv4 Neighbors for AS(1)
H
Address
Interface
Hold Uptime
SRTT
RTO
Q
Seq
(sec)
(ms)
Cnt Num
0
172.16.34.3
Se0/0/0
10 00:02:22
37 2340 0 11
R4#
Did you receive the output you expected?
Yes
b. Run the following Tcl script on all routers to verify full connectivity.
R1#
tclsh
foreach address {
172.16.12.1
172.16.12.2
172.16.13.1
172.16.13.3
172.16.23.2
172.16.23.3
172.16.34.3
172.16.34.4
192.168.1.1
192.168.2.1
192.168.3.1
192.168.4.1
192.168.4.129
} { ping $address }
12
You should get ICMP echo replies for every address pinged. Make sure to run the Tcl script
on each router.
Step 5: Verify the current path.
Before you configure PBR, verify the routing table on R1.
a. On R1, use the show ip route command. Notice the next-hop IP address for all networks discovered by EIGRP.
R1#
show ip route | begin Gateway
Gateway of last resort is not set
172.16.0.0/16 is variably subnetted, 6 subnets, 2 masks
C
172.16.12.0/29 is directly connected, Serial0/0/0
L 172.16.12.1/32 is directly connected, Serial0/0/0
C 172.16.13.0/29 is directly connected, Serial0/0/1
L 172.16.13.1/32 is directly connected, Serial0/0/1
D 172.16.23.0/29 [90/21024000] via 172.16.12.2,
00:07:22, Serial0/0/0
D 172.16.34.0/29 [90/41024000] via 172.16.13.3,
00:07:22, Serial0/0/1
192.168.1.0/24 is variably subnetted, 2 subnets, 2
masks
C
192.168.1.0/24 is directly connected, Loopback1
L
192.168.1.1/32 is directly connected, Loopback1
D
192.168.2.0/24 [90/20640000] via 172.16.12.2, 00:07:22,
Serial0/0/0
D
192.168.3.0/24 [90/21152000] via 172.16.12.2, 00:07:22,
Serial0/0/0
192.168.4.0/25 is subnetted, 2 subnets
D
192.168.4.0 [90/41152000] via 172.16.13.3, 00:07:14,
Serial0/0/1
D
192.168.4.128 [90/41152000] via 172.16.13.3,
00:07:14, Serial0/0/1
R1#
13
b. On R4, use the traceroute command to the R1 LAN address and source the ICMP packet from R4 LAN A and LAN B.
Note:
You can specify the source as the interface address (for example 192.168.4.1) or the
interface designator (for example, Fa0/0).
R4#
traceroute 192.168.1.1 source 192.168.4.1
Type escape sequence to abort.
Tracing the route to 192.168.1.1
VRF info: (vrf in name/id, vrf out name/id)
1 172.16.34.3 12 msec 12 msec 16 msec
2 172.16.23.2 20 msec 20 msec 20 msec
3
R4#
172.16.12.1 24 msec * 24 msec
R4#
traceroute 192.168.1.1 source 192.168.4.129
Type escape sequence to abort.
Tracing the route to 192.168.1.1
VRF info: (vrf in name/id, vrf out name/id)
1 172.16.34.3 12 msec 16 msec 12 msec
2 172.16.23.2 28 msec 20 msec 16 msec
3 172.16.12.1 24 msec * 24 msec
R4#
Notice that the path taken for the packets sourced from the R4 LANs are going through R3
--> R2 --> R1.
Why are the R4 interfaces not using the R3 --> R1 path?
Debido a que las interfaces serie entre los routers R1 y R3 se han configurado con un ancho de banda inferior de 64 Kb / s, dándole una métrica más alta. Todas las demás interfaces serie utilizan el ajuste de ancho de banda de 128 Kb / s. R3 elige enviar todos los paquetes a R2 debido a su métrica inferior.
c. On R3, use the show ip route command and note that the preferred route from R3 to R1 LAN 192.168.1.0/24 is via R2 using the R3 exit interface S0/0/1.
R3#
show ip route | begin Gateway
Gateway of last resort is not set
14
172.16.0.0/16 is variably subnetted, 7 subnets, 2 masks
D
172.16.12.0/29 [90/21024000] via 172.16.23.2,
00:10:54, Serial0/0/1
C 172.16.13.0/29 is directly connected, Serial0/0/0
L 172.16.13.3/32 is directly connected, Serial0/0/0
C 172.16.23.0/29 is directly connected, Serial0/0/1
L 172.16.23.3/32 is directly connected, Serial0/0/1
C 172.16.34.0/29 is directly connected, Serial0/1/0
L 172.16.34.3/32 is directly connected, Serial0/1/0
D 192.168.1.0/24 [90/21152000] via 172.16.23.2, 00:10:54,
Serial0/0/1
D 192.168.2.0/24 [90/20640000] via 172.16.23.2, 00:10:54,
Serial0/0/1
192.168.3.0/24 is variably subnetted, 2 subnets, 2
masks
C
192.168.3.0/24 is directly connected, Loopback3
L
192.168.3.1/32 is directly connected, Loopback3
192.168.4.0/25 is subnetted, 2 subnets
D
192.168.4.0 [90/40640000] via 172.16.34.4, 00:10:47,
Serial0/1/0
D
192.168.4.128 [90/40640000] via 172.16.34.4,
00:10:47, Serial0/1/0
R3#
d. On R3, use the show interfaces serial 0/0/0 and show interfaces s0/0/1 commands.
R3#
show interfaces serial0/0/0
Serial0/0/0 is up, line protocol is up
Hardware is WIC MBRD Serial
Description: R3 --> R1
Internet address is 172.16.13.3/29
MTU 1500 bytes, BW 64 Kbit/sec, DLY 20000 usec,
reliability 255/255, txload 1/255, rxload 1/255
15
Encapsulation HDLC, loopback not set
Keepalive set (10 sec)
Last input 00:00:01, output 00:00:00, output hang never
Last clearing of "show interface" counters never
Input queue: 0/75/0/0 (size/max/drops/flushes); Total
output drops: 0
Queueing strategy: fifo
Output queue: 0/40 (size/max)
5 minute input rate 0 bits/sec, 0 packets/sec
5 minute output rate 0 bits/sec, 0 packets/sec
399 packets input, 29561 bytes, 0 no buffer
Received 186 broadcasts (0 IP multicasts)
0 runts, 0 giants, 0 throttles
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0
abort
393 packets output, 29567 bytes, 0 underruns
0 output errors, 0 collisions, 3 interface resets
0 unknown protocol drops
0 output buffer failures, 0 output buffers swapped out
0 carrier transitions
DCD=up DSR=up DTR=up RTS=up CTS=up
R3#
show interfaces serial0/0/0 | include BW
MTU 1500 bytes, BW 64 Kbit/sec, DLY 20000 usec,
R3#
show interfaces serial0/0/1 | include BW
MTU 1500 bytes, BW 128 Kbit/sec, DLY 20000 usec,
R3#
Notice that the bandwidth of the serial link between R3 and R1 (S0/0/0) is set to 64 Kb/s,
while the bandwidth of the serial link between R3 and R2 (S0/0/1) is set to 128 Kb/s.
e. Confirm that R3 has a valid route to reach R1 from its serial 0/0/0 interface using the show ip eigrp topology 192.168.1.0 command.
16
R3#
show ip eigrp topology 192.168.1.0
EIGRP-IPv4 Topology Entry for AS(1)/ID(192.168.3.1) for
192.168.1.0/24
State is Passive, Query origin flag is 1, 1 Successor(s),
FD is 21152000
Descriptor Blocks:
172.16.23.2 (Serial0/0/1), from 172.16.23.2, Send flag is
0x0
Composite metric is (21152000/20640000), route is
Internal
Vector metric:
Minimum bandwidth is 128 Kbit
Total delay is 45000 microseconds
Reliability is 255/255
Load is 1/255
Minimum MTU is 1500
Hop count is 2
Originating router is 192.168.1.1
172.16.13.1 (Serial0/0/0), from 172.16.13.1, Send flag is
0x0
Composite metric is (40640000/128256), route is
Internal
Vector metric:
Minimum bandwidth is 64 Kbit
Total delay is 25000 microseconds
Reliability is 255/255
Load is 1/255
Minimum MTU is 1500
Hop count is 1
Originating router is 192.168.1.1
R3#
17
As indicated, R4 has two routes to reach 192.168.1.0. However, the metric for the route to
R1 (172.16.13.1) is much higher (40640000) than the metric of the route to R2 (21152000),
making the route through R2 the successor route.
Step 6: Configure PBR to provide path control.
Now you will deploy source-based IP routing by using PBR. You will change a default IP routing
decision based on the EIGRP-acquired routing information for selected IP source-to-
destination flows and apply a different next-hop router.
Recall that routers normally forward packets to destination addresses based on information in
their routing table. By using PBR, you can implement policies that selectively cause packets to
take different paths based on source address, protocol type, or application type. Therefore,
PBR overrides the
router’s normal routing behavior.
Configuring PBR involves configuring a route map with
match
and
set
commands and then
applying the route map to the interface.
The steps required to implement path control include the following:
Choose the path control tool to use. Path control tools manipulate or bypass the IP
routing table. For PBR,
route-map
commands are used.
Implement the traffic-matching configuration, specifying which traffic will be
manipulated. The
match
commands are used within route maps.
Define the action for the matched traffic using
set
commands within route maps.
Apply the route map to incoming traffic.
As a test, you will configure the following policy on router R3:
All traffic sourced from R4 LAN A must take the R3 --> R2 --> R1 path.
All traffic sourced from R4 LAN B must take the R3 --> R1 path.
a. On router R3, create a standard access list called PBR-ACL to identify the R4 LAN B network.
R3(config)#
ip access-list standard PBR-ACL
R3(config-std-nacl)#
remark ACL matches R4 LAN B traffic
R3(config-std-nacl)#
permit 192.168.4.128 0.0.0.127
R3(config-std-nacl)#
exit
R3(config)#
b. Create a route map called R3-to-R1 that matches PBR-ACL and sets the next-hop interface to the R1 serial 0/0/1 interface.
R3(config)#
route-map R3-to-R1 permit
R3(config-route-map)#
description RM to forward LAN B traffic
to R1
18
R3(config-route-map)#
match ip address PBR-ACL
R3(config-route-map)#
set ip next-hop 172.16.13.1
R3(config-route-map)#
exit
R3(config)#
c. Apply the R3-to-R1 route map to the serial interface on R3 that receives the traffic from R4. Use the ip policy route-map command on interface S0/1/0.
R3(config)#
interface s0/1/0
R3(config-if)#
ip policy route-map R3-to-R1
R3(config-if)#
end
R3#
d. On R3, display the policy and matches using the show route-map command.
R3#
show route-map
route-map R3-to-R1, permit, sequence 10
Match clauses:
ip address (access-lists): PBR-ACL
Set clauses:
ip next-hop 172.16.13.1
Policy routing matches: 0 packets, 0 bytes
R3#
Note:
There are currently no matches because no packets matching the ACL have passed
through R3 S0/1/0.
Step 7: Test the policy.
Now you are ready to test the policy configured on R3. Enable the
debug ip policy
command
on R3 so that you can observe the policy decision-making in action. To help filter the traffic,
first create a standard ACL that identifies all traffic from the R4 LANs.
a. On R3, create a standard ACL which identifies all of the R4 LANs.
R3#
conf t
Enter configuration commands, one per line. End with CNTL/Z.
R3(config)#
access-list 1 permit 192.168.4.0 0.0.0.255
R3(config)#
exit
19
b. Enable PBR debugging only for traffic that matches the R4 LANs.
R3#
debug ip policy ?
<1-199> Access list
dynamic dynamic PBR
<cr>
R3#
debug ip policy 1
Policy routing debugging is on for access list 1
c. Test the policy from R4 with the traceroute command, using R4 LAN A as the source network.
R4#
traceroute 192.168.1.1 source 192.168.4.1
Type escape sequence to abort.
Tracing the route to 192.168.1.1
1 172.16.34.3 0 msec 0 msec 4 msec
2 172.16.23.2 0 msec 0 msec 4 msec
3 172.16.12.1 4 msec 0 msec *
Notice the path taken for the packet sourced from R4 LAN A is still going through R3 --> R2
--> R1.
As the traceroute was being executed, router R3 should be generating the following debug
output.
R3#
Jan 10 10:49:48.411: IP: s=192.168.4.1 (Serial0/1/0),
d=192.168.1.1, len 28, policy rejected -- normal forwarding
Jan 10 10:49:48.427: IP: s=192.168.4.1 (Serial0/1/0),
d=192.168.1.1, len 28, policy rejected -- normal forwarding
Jan 10 10:49:48.439: IP: s=192.168.4.1 (Serial0/1/0),
d=192.168.1.1, len 28, policy rejected -- normal forwarding
Jan 10 10:49:48.451: IP: s=192.168.4.1 (Serial0/1/0),
d=192.168.1.1, len 28, FIB policy rejected(no match) - normal
forwarding
20
21
Jan 10 10:49:48.471: IP: s=192.168.4.1 (Serial0/1/0),
d=192.168.1.1, len 28, FIB policy rejected(no match) - normal
forwarding
Jan 10 10:49:48.491: IP: s=192.168.4.1 (Serial0/1/0),
d=192.168.1.1, len 28, FIB policy rejected(no match) - normal
forwarding
Jan 10 10:49:48.511: IP: s=192.168.4.1 (Serial0/1/0),
d=192.168.1.1, len 28, FIB policy rejected(no match) - normal
forwarding
Jan 10 10:49:48.539: IP: s=192.168.4.1 (Serial0/1/0),
d=192.168.1.1, len 28, FIB policy rejected(no match) - normal
forwarding
Jan 10 10:49:51.539: IP: s=192.168.4.1 (Serial0/1/0),
d=192.168.1.1, len 28, FIB policy rejected(no match) - normal
forwarding
R3#
Why is the traceroute traffic not using the R3 --> R1 path as specified in the R3-to-R1
policy?
No toma la ruta especificada PBR porque LAN A no cumple con los criterios especificados en la lista de acceso PBR-ACL.
d. Test the policy from R4 with the traceroute command, using R4 LAN B as the source network.
R4#
traceroute 192.168.1.1 source 192.168.4.129
Type escape sequence to abort.
Tracing the route to 192.168.1.1
1 172.16.34.3 12 msec 12 msec 16 msec
2 172.16.13.1 28 msec 28 msec *
Now the path taken for the packet sourced from R4 LAN B is R3 --> R1, as expected.
The debug output on R3 also confirms that the traffic meets the criteria of the R3-to-R1
policy.
R3#
R3#
Jan 10 10:50:04.283: IP: s=192.168.4.129 (Serial0/1/0),
d=192.168.1.1, len 28, policy match
Jan 10 10:50:04.283: IP: route map R3-to-R1, item 10, permit
Jan 10 10:50:04.283: IP: s=192.168.4.129 (Serial0/1/0),
d=192.168.1.1 (Serial0/0/0), len 28, policy routed
Jan 10 10:50:04.283: IP: Serial0/1/0 to Serial0/0/0
172.16.13.1
Jan 10 10:50:04.295: IP: s=192.168.4.129 (Serial0/1/0),
d=192.168.1.1, len 28, policy match
Jan 10 10:50:04.295: IP: route map R3-to-R1, item 10, permit
Jan 10 10:50:04.295: IP: s=192.168.4.129 (Serial0/1/0),
d=192.168.1.1 (Serial0/0/0), len 28, policy routed
Jan 10 10:50:04.295: IP: Serial0/1/0 to Serial0/0/0
172.16.13.1
Jan 10 10:50:04.311: IP: s=192.168.4.129 (Serial0/1/0),
d=192.168.1.1, len 28, policy match
Jan 10 10:50:04.311: IP: route map R3-to-R1, item 10, permit
Jan 10 10:50:04.311: IP: s=192.168.4.129 (Serial0/1/0),
d=192.168.1.1 (Serial0/0/0), len 28, policy routed
Jan 10 10:50:04.311: IP: Serial0/1/0 to Serial0/0/0
172.16.13.1
Jan 10 10:50:04.323: IP: s=192.168.4.129 (Serial0/1/0),
d=192.168.1.1, len 28, FIB policy match
Jan 10 10:50:04.323: IP: s=192.168.4.129 (Serial0/1/0),
d=192.168.1.1, len 28, PBR Counted
Jan 10 10:50:04.323: IP: s=192.168.4.129 (Serial0/1/0),
d=192.168.1.1, g=172.16.13.1, len 28, FIB policy routed
Jan 10 10:50:04.351: IP: s=192.168.4.129 (Serial0/1/0),
d=192.168.1.1, len 28, FIB policy match
Jan 10 10:50:04.351: IP: s=192.168.4.129 (Serial0/1/0),
d=192.168.1.1, len 28, PBR Counted
Jan 10 10:50:04.351: IP: s=192.168.4.129 (Serial0/1/0),
d=192.168.1.1, g=172.16.13.1, len 28, FIB policy routed
Jan 10 10:50:07.347: IP: s=192.168.4.129 (Serial0/1/0),
d=192.168.1.1, len 28, FIB policy match
22
Jan 10 10:50:07.347: IP: s=192.168.4.129 (Serial0/1/0),
d=192.168.1.1, len 28, PBR Counted
Jan 10 10:50:07.347: IP: s=192.168.4.129 (Serial0/1/0),
d=192.168.1.1, g=172.16.13.1, len 28, FIB policy routed
R3#
e. On R3, display the policy and matches using the show route-map command.
R3#
show route-map
route-map R3-to-R1, permit, sequence 10
Match clauses:
ip address (access-lists): PBR-ACL
Set clauses:
ip next-hop 172.16.13.1
Nexthop tracking current: 0.0.0.0
172.16.13.1, fib_nh:0,oce:0,status:0
Policy routing matches: 12 packets, 384 bytes
R3#
Note:
There are now matches to the policy because packets matching the ACL have passed
through R3 S0/1/0.
23
CCNPv7 ROUTE
PABLO FELIPE REYES
Chapter 5 Lab 5-2, Configure IP SLA Tracking and Path Control
Topology
Objectives
Configure and verify the IP SLA feature. Test the IP SLA tracking feature.
Verify the configuration and operation using show and debug commands.
Background
You want to experiment with the Cisco IP Service Level Agreement (SLA) feature to study how it could be of value to your organization.
At times, a link to an ISP could be operational, yet users cannot connect to any other outside Internet resources. The problem might be with the ISP or downstream from them. Although policy-based routing (PBR) can be implemented to alter path control, you will implement the
24
25
Cisco IOS SLA feature to monitor this behavior and intervene by injecting another default route to a backup ISP.
To test this, you have set up a three-router topology in a lab environment. Router R1 represents a branch office connected to two different ISPs. ISP1 is the preferred connection to the Internet, while ISP2 provides a backup link. ISP1 and ISP2 can also interconnect, and both can reach the web server. To monitor ISP1 for failure, you will configure IP SLA probes to track the reachability to the ISP1 DNS server. If connectivity to the ISP1 server fails, the SLA probes detect the failure and alter the default static route to point to the ISP2 server.
Note: This lab uses Cisco 1941 routers with Cisco IOS Release 15.2 with IP Base. Depending on the router or switch model and Cisco IOS Software version, the commands available and output produced might vary from what is shown in this lab.
Required Resources
3 routers (Cisco IOS Release 15.2 or comparable) Serial and Ethernet cables
Step 1: Configure loopbacks and assign addresses.
f. Cable the network as shown in the topology diagram. Erase the startup configuration and reload each router to clear the previous configurations. Using the addressing scheme in the diagram, create the loopback interfaces and apply IP addresses to them as well as the serial interfaces on R1, ISP1, and ISP2.
You can copy and paste the following configurations into your routers to begin.
Note
: Depending on the router model, interfaces might be numbered differently than
those listed. You might need to alter them accordingly.
Router R1
hostname R1
interface Loopback 0
description R1 LAN
ip address 192.168.1.1 255.255.255.0
interface Serial0/0/0
description R1 --> ISP1
ip address 209.165.201.2 255.255.255.252
clock rate 128000
bandwidth 128
no shutdown
interface Serial0/0/1
description R1 --> ISP2
ip address 209.165.202.130 255.255.255.252
bandwidth 128
no shutdown
Router ISP1 (R2)
hostname ISP1
interface Loopback0
description Simulated Internet Web Server
ip address 209.165.200.254 255.255.255.255
interface Loopback1
description ISP1 DNS Server
ip address 209.165.201.30 255.255.255.255
interface Serial0/0/0
description ISP1 --> R1
ip address 209.165.201.1 255.255.255.252
bandwidth 128
no shutdown
interface Serial0/0/1
description ISP1 --> ISP2
ip address 209.165.200.225 255.255.255.252
clock rate 128000
bandwidth 128
no shutdown
Router ISP2 (R3)
hostname ISP2
interface Loopback0
description Simulated Internet Web Server
ip address 209.165.200.254 255.255.255.255
interface Loopback1
description ISP2 DNS Server
ip address 209.165.202.158 255.255.255.255
interface Serial0/0/0
description ISP2 --> R1
ip address 209.165.202.129 255.255.255.252
clock rate 128000
bandwidth 128
no shutdown
interface Serial0/0/1
description ISP2 --> ISP1
ip address 209.165.200.226 255.255.255.252
bandwidth 128
no shutdown
g. Verify the configuration by using the show interfaces description command. The output from router R1 is shown here as an example.
R1#
show interfaces description | include up
Se0/0/0
up
up
R1 -->
ISP1
Se0/0/1
up
up
R1 -->
ISP2
R1#
Lo0
up
up
R1 LAN
All three interfaces should be active. Troubleshoot if necessary.
Step 2: Configure static routing.
The current routing policy in the topology is as follows:
Router R1 establishes connectivity to the Internet through ISP1 using a default static
route.
ISP1 and ISP2 have dynamic routing enabled between them, advertising their
respective public address pools.
ISP1 and ISP2 both have static routes back to the ISP LAN.
Note:
For the purpose of this lab, the ISPs have a static route to an RFC 1918 private
network address on the branch router R1. In an actual branch implementation, Network
Address Translation (NAT) would be configured for all traffic exiting the branch LAN.
Therefore, the static routes on the ISP routers would be pointing to the provided public
pool of the branch office.
h. Implement the routing policies on the respective routers. You can copy and paste the following configurations.
Router R1
R1(config)#
ip route 0.0.0.0 0.0.0.0 209.165.201.1
R1(config)#
Router ISP1 (R2)
ISP1(config)#
router eigrp 1
ISP1(config-router)#
network 209.165.200.224 0.0.0.3
ISP1(config-router)#
network 209.165.201.0 0.0.0.31
ISP1(config-router)#
no auto-summary
ISP1(config-router)#
exit
ISP1(config)#
ISP1(config-router)#
ip route 192.168.1.0 255.255.255.0
209.165.201.2
ISP1(config)#
Router ISP2 (R3)
ISP2(config)#
router eigrp 1
ISP2(config-router)#
network 209.165.200.224 0.0.0.3
ISP2(config-router)#
network 209.165.202.128 0.0.0.31
ISP2(config-router)#
no auto-summary
28
ISP2(config-router)#
exit
ISP2(config)#
ISP2(config)#
ip route 192.168.1.0 255.255.255.0
209.165.202.130
ISP2(config)#
EIGRP neighbor relationship messages on ISP1 and ISP2 should be generated.
Troubleshoot if necessary.
i. The Cisco IOS IP SLA feature enables an administrator to monitor network performance between Cisco devices (switches or routers) or from a Cisco device to a remote IP device. IP SLA probes continuously check the reachability of a specific destination, such as a provider edge router interface, the DNS server of the ISP, or any other specific destination, and can conditionally announce a default route only if the connectivity is verified.
Before implementing the Cisco IOS SLA feature, you must verify reachability to the Internet servers. From router R1, ping the web server, ISP1 DNS server, and ISP2 DNS server to verify connectivity. You can copy the following Tcl script and paste it into R1.
foreach address {
209.165.200.254
209.165.201.30
209.165.202.158
} {
ping $address source 192.168.1.1
}
All pings should be successful. Troubleshoot if necessary.
j. Trace the path taken to the web server, ISP1 DNS server, and ISP2 DNS server. You can copy the following Tcl script and paste it into R1.
foreach address {
209.165.200.254
209.165.201.30
209.165.202.158
} {
trace $address source 192.168.1.1
29
}
Through which ISP is traffic flowing?
Step 3: Configure IP SLA probes.
When the reachability tests are successful, you can configure the Cisco IOS IP SLAs probes.
Different types of probes can be created, including FTP, HTTP, and jitter probes.
In this scenario, you will configure ICMP echo probes.
k. Create an ICMP echo probe on R1 to the primary DNS server on ISP1 using the ip sla
command.
R1(config)#
ip sla 11
R1(config-ip-sla)#
icmp-echo 209.165.201.30
R1(config-ip-sla-echo)#
frequency 10
R1(config-ip-sla-echo)#
exit
R1(config)#
R1(config)#
ip sla schedule 11 life forever start-time now
R1(config)#
The operation number of 11 is only locally significant to the router. The
frequency 10
command schedules the connectivity test to repeat every 10 seconds. The probe is
scheduled to start now and to run forever.
l. Verify the IP SLAs configuration of operation 11 using the show ip sla configuration 11
command.
R1#
show ip sla configuration 11
IP SLAs Infrastructure Engine-III
Entry number: 11
Owner:
Tag:
Operation timeout (milliseconds): 5000
Type of operation to perform: icmp-echo
Target address/Source address: 209.165.201.30/0.0.0.0
Type Of Service parameter: 0x0
Request size (ARR data portion): 28
30
Verify data: No
Vrf Name:
Schedule:
Operation frequency (seconds): 10 (not considered if
randomly scheduled)
Next Scheduled Start Time: Start Time already passed
Group Scheduled : FALSE
Randomly Scheduled : FALSE
Life (seconds): Forever
Entry Ageout (seconds): never
Recurring (Starting Everyday): FALSE
Status of entry (SNMP RowStatus): Active
Threshold (milliseconds): 5000
Distribution Statistics:
Number of statistic hours kept: 2
Number of statistic distribution buckets kept: 1
Statistic distribution interval (milliseconds): 20
Enhanced History:
History Statistics:
Number of history Lives kept: 0
Number of history Buckets kept: 15
History Filter Type: None
R1#
The output lists the details of the configuration of operation 11. The operation is an ICMP
echo to 209.165.201.30, with a frequency of 10 seconds, and it has already started (the
start time has already passed).
m. Issue the show ip sla statistics command to display the number of successes, failures, and results of the latest operations.
R1#
show ip sla statistics
31
IPSLAs Latest Operation Statistics
IPSLA operation id: 11
Latest RTT: 8 milliseconds
Latest operation start time: 10:33:18 UTC Sat Jan 10 2015
Latest operation return code: OK
Number of successes: 51
Number of failures: 0
Operation time to live: Forever
R1#
You can see that operation 11 has already succeeded five times, has had no failures, and
the last operation returned an OK result.
n. Although not actually required because IP SLA session 11 alone could provide the desired fault tolerance, create a second probe, 22, to test connectivity to the second DNS server located on router ISP2.
R1(config)#
ip sla 22
R1(config-ip-sla)#
icmp-echo 209.165.202.158
R1(config-ip-sla-echo)#
frequency 10
R1(config-ip-sla-echo)#
exit
R1(config)#
R1(config)#
ip sla schedule 22 life forever start-time now
R1(config)#
end
R1#
o. Verify the new probe using the show ip sla configuration and show ip sla statistics
commands.
R1#
show ip sla configuration 22
IP SLAs Infrastructure Engine-III
Entry number: 22
Owner:
32
Tag:
Operation timeout (milliseconds): 5000
Type of operation to perform: icmp-echo
Target address/Source address: 209.165.202.158/0.0.0.0
Type Of Service parameter: 0x0
Request size (ARR data portion): 28
Verify data: No
Vrf Name:
Schedule:
Operation frequency (seconds): 10 (not considered if
randomly scheduled)
Next Scheduled Start Time: Start Time already passed
Group Scheduled : FALSE
Randomly Scheduled : FALSE
Life (seconds): Forever
Entry Ageout (seconds): never
Recurring (Starting Everyday): FALSE
Status of entry (SNMP RowStatus): Active
Threshold (milliseconds): 5000
Distribution Statistics:
Number of statistic hours kept: 2
Number of statistic distribution buckets kept: 1
Statistic distribution interval (milliseconds): 20
Enhanced History:
History Statistics:
Number of history Lives kept: 0
Number of history Buckets kept: 15
History Filter Type: None
33
R1#
R1#
show ip sla configuration 22
IP SLAs, Infrastructure Engine-II.
Entry number: 22
Owner:
Tag:
Type of operation to perform: icmp-echo
Target address/Source address: 209.165.201.158/0.0.0.0
Type Of Service parameter: 0x0
Request size (ARR data portion): 28
Operation timeout (milliseconds): 5000
Verify data: No
Vrf Name:
Schedule:
Operation frequency (seconds): 10 (not considered if
randomly scheduled)
Next Scheduled Start Time: Start Time already passed
Group Scheduled : FALSE
Randomly Scheduled : FALSE
Life (seconds): Forever
Entry Ageout (seconds): never
Recurring (Starting Everyday): FALSE
Status of entry (SNMP RowStatus): Active
Threshold (milliseconds): 5000 (not considered if react RTT
is configured)
Distribution Statistics:
Number of statistic hours kept: 2
Number of statistic distribution buckets kept: 1
34
Statistic distribution interval (milliseconds): 20
History Statistics:
Number of history Lives kept: 0
Number of history Buckets kept: 15
History Filter Type: None
Enhanced History:
R1#
R1#
show ip sla statistics 22
IPSLAs Latest Operation Statistics
IPSLA operation id: 22
Latest RTT: 16 milliseconds
Latest operation start time: 10:38:29 UTC Sat Jan 10 2015
Latest operation return code: OK
Number of successes: 82
Number of failures: 0
Operation time to live: Forever
R1#
The output lists the details of the configuration of operation 22. The operation is an ICMP
echo to 209.165.202.158, with a frequency of 10 seconds, and it has already started (the
start time has already passed). The statistics also prove that operation 22 is active.
Step 4: Configure tracking options.
Although PBR could be used, you will configure a floating static route that appears or
disappears depending on the success or failure of the IP SLA.
p. On R1, remove the current default route and replace it with a floating static route having an administrative distance of 5.
R1(config)#
no ip route 0.0.0.0 0.0.0.0 209.165.201.1
R1(config)#
ip route 0.0.0.0 0.0.0.0 209.165.201.1 5
35
R1(config)#
exit
q. Verify the routing table.R1#
show ip route | begin Gateway
Gateway of last resort is 209.165.201.1 to network 0.0.0.0
192.168.1.0/24 is variably subnetted, 2 subnets, 2
masks
C
192.168.1.0/24 is directly connected, Loopback0
L
192.168.1.1/32 is directly connected, Loopback0
209.165.201.0/24 is variably subnetted, 2 subnets, 2
masks
C
209.165.201.0/30 is directly connected, Serial0/0/0
L
209.165.201.2/32 is directly connected, Serial0/0/0
209.165.202.0/24 is variably subnetted, 2 subnets, 2
masks
C
209.165.202.128/30 is directly connected,
Serial0/0/1
L
209.165.202.130/32 is directly connected,
Serial0/0/1
R1#
Notice that the default static route is now using the route with the administrative distance
of 5. The first tracking object is tied to IP SLA object 11.
r. From global configuration mode on R1, use the track 1 ip sla 11 reachability command to enter the config-track subconfiguration mode.
R1(config)#
track 1 ip sla 11 reachability
R1(config-track)#
s. Specify the level of sensitivity to changes of tracked objects to 10 seconds of down delay and 1 second of up delay using the delay down 10 up 1 command. The delay helps to alleviate the effect of flapping objects—objects that are going down and up rapidly. In this situation, if the DNS server fails momentarily and comes back up within 10 seconds, there is no impact.
R1(config-track)#
delay down 10 up 1
S*
0.0.0.0/0 [5/0] via 209.165.201.1
36
R1(config-track)#
exit
R1(config)#
t. To view routing table changes as they happen, first enable the debug ip routing
command.
R1#
debug ip routing
IP routing debugging is on
R1#
u. Configure the floating static route that will be implemented when tracking object 1 is active. Use the ip route 0.0.0.0 0.0.0.0 209.165.201.1 2 track 1 command to create a floating static default route via 209.165.201.1 (ISP1). Notice that this command references the tracking object number 1, which in turn references IP SLA operation number 11.
R1(config)#
ip route 0.0.0.0 0.0.0.0 209.165.201.1 2 track 1
R1(config)#
Jan 10 10:45:39.119: RT: updating static 0.0.0.0/0 (0x0) :
via 209.165.201.1
0 1048578
Jan 10 10:45:39.119: RT: closer admin distance for 0.0.0.0,
flushing 1 routes
Jan 10 10:45:39.119: RT: add 0.0.0.0/0 via 209.165.201.1,
static metric [2/0]
Jan 10 10:45:39.119: RT: updating static 0.0.0.0/0 (0x0) :
via 209.165.201.1
0 1048578
Jan 10 10:45:39.119: RT: rib update return code: 17
Jan 10 10:45:39.119: RT: updating static 0.0.0.0/0 (0x0) :
via 209.165.201.1
0 1048578
Jan 10 10:45:39.119: RT: rib update return code: 17
R1(config)#
Notice that the default route with an administrative distance of 5 has been immediately
flushed because of a route with a better admin distance. It then adds the new default
route with the admin distance of 2.
37
v. Repeat the steps for operation 22, track number 2, and assign the static route an admin distance higher than track 1 and lower than 5. On R1, copy the following configuration, which sets an admin distance of 3.
R1(config)#
track 2 ip sla 22 reachability
R1(config-track)#
delay down 10 up 1
R1(config-track)#
exit
R1(config)#
R1(config)#
ip route 0.0.0.0 0.0.0.0 209.165.202.129 3 track
2
R1(config)#
w. Verify the routing table again.
R1#show ip route | begin Gateway
Gateway of last resort is 209.165.201.1 to network 0.0.0.0
192.168.1.0/24 is variably subnetted, 2 subnets, 2
masks
C
192.168.1.0/24 is directly connected, Loopback0
L
192.168.1.1/32 is directly connected, Loopback0
209.165.201.0/24 is variably subnetted, 2 subnets, 2
masks
C
209.165.201.0/30 is directly connected, Serial0/0/0
L
209.165.201.2/32 is directly connected, Serial0/0/0
209.165.202.0/24 is variably subnetted, 2 subnets, 2
masks
C
209.165.202.128/30 is directly connected,
Serial0/0/1
L
209.165.202.130/32 is directly connected,
Serial0/0/1
R1#
Although a new default route was entered, its administrative distance is not better than 2.
Therefore, it does not replace the previously entered default route.
S*
0.0.0.0/0 [2/0] via 209.165.201.1
38
Step 5: Verify IP SLA operation.
In this step you observe and verify the dynamic operations and routing changes when tracked
objects fail. The following summarizes the process:
Disable the DNS loopback interface on ISP1 (R2).
Observe the output of the
debug
command on R1.
Verify the static route entries in the routing table and the IP SLA statistics of R1.
Re-enable the loopback interface on ISP1 (R2) and again observe the operation of the
IP SLA tracking feature.
x. On ISP1, disable the loopback interface 1.
ISP1(config-if)#
int lo1
ISP1(config-if)#
shutdown
ISP1(config-if)#
Jan 10 10:53:25.091: %LINK-5-CHANGED: Interface Loopback1,
changed state to administratively down
Jan 10 10:53:26.091: %LINEPROTO-5-UPDOWN: Line protocol on
Interface Loopback1, changed state to down
ISP1(config-if)#
y. On R1, observe the debug output being generated. Recall that R1 will wait up to 10 seconds before initiating action therefore several seconds will elapse before the output is generated.
R1#
Jan 10 10:53:59.551: %TRACK-6-STATE: 1 ip sla 11 reachability
Up -> Down
Jan 10 10:53:59.551: RT: del 0.0.0.0 via 209.165.201.1,
static metric [2/0]
Jan 10 10:53:59.551: RT: delete network route to 0.0.0.0/0
Jan 10 10:53:59.551: RT: default path has been cleared
Jan 10 10:53:59.551: RT: updating static 0.0.0.0/0 (0x0) :
via 209.165.202.129
0 1048578
Jan 10 10:53:59.551: RT: add 0.0.0.0/0 via 209.165.202.129,
static metric [3/0]
39
Jan 10 10:53:59.551: RT: default path is now 0.0.0.0 via
209.165.202.129
Jan 10 10:53:59.551: RT: updating static 0.0.0.0/0 (0x0) :
via 209.165.201.1
0 1048578
Jan 10 10:53:59.551: RT: rib update return code: 17
Jan 10 10:53:59.551: RT: updating static 0.0.0.0/0 (0x0) :
via 209.165.202.129
0 1048578
Jan 10 10:53:59.551: RT: updating static 0.0.0.0/0 (0x0) :
via 209.165.201.1
0 1048578
Jan 10 10:53:59.551: RT: rib update return code: 17
R1#
The tracking state of track 1 changes from up to down. This is the object that tracked
reachability for IP SLA object 11, with an ICMP echo to the ISP1 DNS server at
209.165.201.30.
R1 then proceeds to delete the default route with the administrative distance of 2 and
installs the next highest default route to ISP2 with the administrative distance of 3.
z. On R1, verify the routing table.
R1#
show ip route | begin Gateway
Gateway of last resort is 209.165.202.129 to network 0.0.0.0
192.168.1.0/24 is variably subnetted, 2 subnets, 2
masks
C
192.168.1.0/24 is directly connected, Loopback0
L
192.168.1.1/32 is directly connected, Loopback0
209.165.201.0/24 is variably subnetted, 2 subnets, 2
masks
C
209.165.201.0/30 is directly connected, Serial0/0/0
S*
0.0.0.0/0 [3/0] via 209.165.202.129
40
L
209.165.201.2/32 is directly connected, Serial0/0/0
209.165.202.0/24 is variably subnetted, 2 subnets, 2
masks
C
209.165.202.128/30 is directly connected,
Serial0/0/1
L
209.165.202.130/32 is directly connected,
Serial0/0/1
R1#
The new static route has an administrative distance of 3 and is being forwarded to ISP2 as
it should.
aa. Verify the IP SLA statistics.
R1#
show ip sla statistics
IPSLAs Latest Operation Statistics
IPSLA operation id: 11
Latest RTT: NoConnection/Busy/Timeout
Latest operation start time: 11:01:08 UTC Sat Jan 10 2015
Latest operation return code: Timeout
Number of successes: 173
Number of failures: 45
Operation time to live: Forever
IPSLA operation id: 22
Latest RTT: 8 milliseconds
Latest operation start time: 11:01:09 UTC Sat Jan 10 2015
Latest operation return code: OK
Number of successes: 218
Number of failures: 0
Operation time to live: Forever
41
R1#
Notice that the latest return code is
Timeout
and there have been 45 failures on IP SLA
object 11.
bb. On R1, initiate a trace to the web server from the internal LAN IP address.
R1#
trace 209.165.200.254 source 192.168.1.1
Type escape sequence to abort.
Tracing the route to 209.165.200.254
VRF info: (vrf in name/id, vrf out name/id)
1 209.165.202.129 4 msec * *
R1#
This confirms that traffic is leaving router R1 and being forwarded to the ISP2 router.
cc. On ISP1, re-enable the DNS address by issuing the no shutdown command on the loopback 1 interface to examine the routing behavior when connectivity to the ISP1 DNS is restored.
ISP1(config-if)#
no shutdown
Jan 10 11:05:45.847: %LINK-3-UPDOWN: Interface Loopback1,
changed state to up
Jan 10 11:05:46.847: %LINEPROTO-5-UPDOWN: Line protocol on
Interface Loopback1, changed state to up
ISP1(config-if)#
Notice the output of the
debug ip routing
command on R1.
R1#
Jan 10 11:06:20.551: %TRACK-6-STATE: 1 ip sla 11 reachability
Down -> Up
Jan 10 11:06:20.551: RT: updating static 0.0.0.0/0 (0x0) :
via 209.165.201.1
0 1048578
Jan 10 11:06:20.551: RT: closer admin distance for 0.0.0.0,
flushing 1 routes
Jan 10 11:06:20.551: RT: add 0.0.0.0/0 via 209.165.201.1,
static metric [2/0]
Jan 10 11:06:20.551: RT: updating static 0.0.0.0/0 (0x0) :
via 209.165.202.129
0 1048578
Jan 10 11:06:20.551: RT: rib update return code: 17
Jan 10 11:06:20.551: RT: u
R1#pdating static 0.0.0.0/0 (0x0) :
via 209.165.202.129
0 1048578
Jan 10 11:06:20.551: RT: rib update return code: 17
Jan 10 11:06:20.551: RT: updating static 0.0.0.0/0 (0x0) :
via 209.165.201.1
0 1048578
Jan 10 11:06:20.551: RT: rib update return code: 17
R1#
Now the IP SLA 11 operation transitions back to an up state and reestablishes the default
static route to ISP1 with an administrative distance of 2.
dd. Again examine the IP SLA statistics.
R1#
show ip sla statistics
IPSLAs Latest Operation Statistics
IPSLA operation id: 11
Latest RTT: 8 milliseconds
Latest operation start time: 11:07:38 UTC Sat Jan 10 2015
Latest operation return code: OK
Number of successes: 182
Number of failures: 75
Operation time to live: Forever
43
IPSLA operation id: 22
Latest RTT: 16 milliseconds
Latest operation start time: 11:07:39 UTC Sat Jan 10 2015
Latest operation return code: OK
Number of successes: 257
Number of failures: 0
Operation time to live: Forever
R1#
The IP SLA 11 operation is active again, as indicated by the OK return code, and the
number of successes is incrementing.
ee. Verify the routing table.
R1#
show ip route | begin Gateway
Gateway of last resort is 209.165.201.1 to network 0.0.0.0
192.168.1.0/24 is variably subnetted, 2 subnets, 2
masks
C
192.168.1.0/24 is directly connected, Loopback0
L
192.168.1.1/32 is directly connected, Loopback0
209.165.201.0/24 is variably subnetted, 2 subnets, 2
masks
C
209.165.201.0/30 is directly connected, Serial0/0/0
L
209.165.201.2/32 is directly connected, Serial0/0/0
209.165.202.0/24 is variably subnetted, 2 subnets, 2
masks
S*
0.0.0.0/0 [2/0] via 209.165.201.1
44
C
209.165.202.128/30 is directly connected,
Serial0/0/1
L
209.165.202.130/32 is directly connected,
Serial0/0/1
R1#
The default static through ISP1 with an administrative distance of 2 is reestablished.
There are many possibilities available with object tracking and Cisco IOS IP SLAs. As shown in
this lab, a probe can be based on reachability, changing routing operations, and path control
based on the ability to reach an object. However, Cisco IOS IP SLAs also allow paths to be
changed based on network conditions such as delay, load, and other factors.
Before deploying a Cisco IOS IP SLA solution, the impact of the additional probe traffic being
generated should be considered, including how that traffic affects bandwidth utilization, and
congestion levels. Tuning the configuration (for example, with the
delay
and
frequency
commands) is critical to mitigate possible issues related to excessive transitions and route
changes in the presence of flapping tracked objects.
The benefits of running IP SLAs should be carefully evaluated. The IP SLA is an additional task
that must be performed by the
router’s CPU. A large number of intensive SLAs could be a
significant burden on the CPU, possibly interfering with other router functions and having
detrimental impact on the overall router performance. The CPU load should be monitored
after the SLAs are deployed to verify that they do not cause excessive utilization of the router
CPU.
45
Chapter 6 Lab 6-1, Configure NAT Services ALVARO ELIU MELO
Topology
Objectives
Configure dynamic NAT and static NAT on the HQ router. Configure dynamic NAT on the Branch router.
Verify the configuration and operation using show commands.
46
47
Background
The HQ and Branch sites must be configured to support NAT. Specifically, the HQ and Branch routers will be configured to provide inside LAN users with outside public addresses using NAT. The HQ router will also provide static NAT to access the Email server from the outside network.
Note: This lab uses Cisco 1941 routers with Cisco IOS Release 15.2 with IP Base. Depending on the router or switch model and Cisco IOS Software version, the commands available and output produced might vary from what is shown in this lab.
Required Resources
3 routers (Cisco IOS Release 15.2 or comparable) Serial and Ethernet cables
Step 1: Configure loopbacks and assign addresses.
Cable the network as shown in the topology diagram. Erase the startup configuration and
reload each router to clear previous configurations. Using the addressing scheme in the
diagram, apply the IP addresses to the interfaces on the HQ, ISP, and Branch routers.
You can copy and paste the following configurations into your routers to begin.
Note
: Depending on the router model, interfaces might be numbered differently than
those listed. You might need to alter the designations accordingly.
HQ (R1)
hostname HQ
!
interface Loopback0
description Headquarters LAN
ip address 10.10.10.1 255.255.255.0
exit
!
interface Loopback1
description Simulates the Email Server
ip address 10.10.20.238 255.255.255.255
exit
!
interface Serial0/0/0
description Connection to ISP
ip address 209.165.200.226 255.255.255.248
clock rate 128000
no shut
exit
!
end
ISP (R2)
hostname ISP
!
interface Loopback0
description Simulating the Internet
ip address 209.165.202.129 255.255.255.240
exit
!
interface Serial0/0/0
description Connection to HQ
ip address 209.165.200.225 255.255.255.248
no shut
exit
!
interface Serial0/0/1
description Connection to Branch
ip address 209.165.200.241 255.255.255.248
clock rate 128000
no shut
exit
!
ip route 209.165.200.232 255.255.255.248 Serial0/0/0
ip route 209.165.200.248 255.255.255.248 Serial0/0/1
!
end
Branch (R3)
hostname Branch
!
interface Loopback0
description Branch LAN
ip address 192.168.1.1 255.255.255.0
exit
!
interface Serial0/0/1
description Connection to ISP
ip address 209.165.200.242 255.255.255.248
no shut
exit
!
end
a. Verify your configuration by using the show ip interface brief and the show interfaces description command. The output from the Branch router is shown here as an example.
Branch# show ip interface brief | include up
Serial0/0/1 209.165.200.242 YES manual up
up
Loopback0 192.168.1.1 YES manual up
up Branch#
Branch# show interfaces description | include up
Se0/0/1 up up Connection
to ISP
Lo0 up up Branch LAN
Branch#
b. From the Branch router, run the following Tcl script to verify connectivity.
