cis 185 ccnp route ch. 5 implementing path control
DESCRIPTION
CIS 185 CCNP ROUTE Ch. 5 Implementing Path Control. Rick Graziani Cabrillo College [email protected] Last Updated: Fall 2011. Materials. Book: Implementing Cisco IP Routing (ROUTE) Foundation Learning Guide: Foundation learning for the ROUTE 642-902 Exam By Diane Teare Book - PowerPoint PPT PresentationTRANSCRIPT
CIS 185 CCNP ROUTECh. 5 Implementing Path Control
Rick Graziani
Cabrillo College
Last Updated: Fall 2011
2
Materials
Book: Implementing Cisco IP Routing
(ROUTE) Foundation Learning Guide: Foundation learning for the ROUTE 642-902 Exam
By Diane Teare Book
ISBN-10: 1-58705-882-0 ISBN-13: 978-1-58705-882-0
eBook ISBN-10: 0-13-255033-4 ISBN-13: 978-0-13-255033-8
Topics
Concepts of Path Control Path Control with Offset Lists Path Control with Cisco IOS IP SLAs Path Control with Policy Based Routing
3
Concepts of Path Control
Path Control is controlling the path that traffic takes through a network when there are: Redundant paths Asymmetric paths (form of redundancy)
Three tools for path control are detailed: Offset lists Cisco IOS IP service level agreements (SLAs) Policy Based Routing (PBR)
4
When a network includes redundancy, other considerations include the following:
Resiliency: The ability to maintain an acceptable level of service when faults occur.
Redundancy does not guarantee resiliency. Redundant links does not automatically result in the backup link being used
if the primary link fails. Availability: The time required for a routing protocol to learn about a
backup path when a primary link fails is the convergence time. Fast-converging routing protocol and tuning parameters. Adaptability: The ability of the network to adapt to changing conditions. Example: A redundant path could be activated when the primary path
becomes congested, not only when it fails. Performance: Improve network performance by tuning routers to load share
across multiple links, making more efficient use of the bandwidth. Support for network and application services: More advanced path
control solutions involve adjusting routing for specific services, such as security, optimization, and quality of service (QoS).
5
Predictability: Need to have the path control solution be deterministic and predictable . Traffic is bidirectional by nature Consider both upstream and downstream traffic
Asymmetric traffic: Traffic that flows one on path in one direction and on a different path in the opposite direction. Not a negative trait Most routing protocols, there are no specific tools to control traffic
direction Border Gateway Protocol (BGP) includes a good set of tools to control
traffic in both directions 6
Asymmetric Traffic
Path Control Tools
A good addressing design: Summarizable address blocks Classless interdomain routing (CIDR) aggregation that align with the
physical topology 10.0.0.0/8 summary is advertised from both routers
More specific route for 10.1.80.0/24 is advertised from the right-hand router, providing direct access to those subnets.
Resulting traffic flows are: Deterministic (you have determined the paths) More resilient (if one path fails the other path will automatically be
used)7
Redistribution and other routing protocol characteristics: The capabilities of the routing protocol used can help implement a path control strategy more effectively
8
Passive interfaces: As we learned previously passive interfaces prevent a routing protocol’s routing updates from being sent through the specified router interface.
Other tools include the following: Distribute lists Prefix lists Administrative distance Route maps Route tagging Offset lists Cisco IOS IP SLAs PBR
9
Using Offset Lists to Control Path Selection
Router configuration command Used to increase incoming or outgoing metrics Offset Lists are only used with distance vector routing protocols Optionally can be implemented using an access list or per interface
10
Router(config-router)# offset-list {access-list-number | access-list-name} {in | out} offset [interface-type interface-number]
The offset value is added to the routing metric. An offset list that specifies an interface is considered to be an extended list
and takes precedence over an offset list that is not extended.
11
Router(config-router)# offset-list {access-list-number | access-list-name} {in | out} offset [interface-type interface-number]
An organization is using RIP and is connected to the Internet service providers (ISP) via edge routers R4 and R5. The metric between routers R2 and R5 is smaller than the metric
between routers R2 and R4 Want R2 to prefer the path toward the edge router R4 for a specific set of
destinations An offset list can be used to accomplish this. 12
s0/0
Adds an offset of 2 to the metric of routes learned from interface serial 0/0 that are permitted by access list 21.
Access list 21 would permit a specific set of routes (172.16.0.0/16 subnets) being learned from R5.
Other routes would be learned but this offset would not be applied.
13
R2(config)# router rip
R2(config-router)# offset-list 21 in 2 serial 0/0
R2(config)# access-list 21 permit 172.16.0.0 0.0.255.255
s0/0
+2 172.16.0.0/16 subnets
Verifying Path Control Using Offset Lists
show ip route show ip eigrp topology debug ip rip debug ip eigrp traceroute
14
Cisco IOS SLAs
15
Using Cisco IOS IP SLAs to Control Path Selection
16
Cisco IOS IP SLAs send simulated data across the network and measures performance between multiple network locations or across multiple network paths.
The information collected includes data about: response time one-way latency jitter (interpacket delay variance) packet loss voice quality scoring network resource availability application performance server response time
Cisco IP SLA
IP SLA, feature of Cisco IOS software allows you to configure a router to send synthetic traffic to: A host computer Router that has been configured to respond (Responder)
17
Edge router: Connected to two ISPs Running NAT and load balancing Using two static default routes
If there is a direct failure on the link to one ISP, the other link can still be used
However, if the infrastructure within of one of the ISPs fails and the link to that ISP remains up, the edge router would continue to use that link; the static default route would still be valid. 18
Router(config)# ip route 0.0.0.0 0.0.0.0 ser0/0
Router(config)# ip route 0.0.0.0 0.0.0.0 ser0/1
There are multiple solutions to this issue. Run a dynamic routing protocol with the ISPs:
Impractical for smaller branch offices Requires additional interaction and integration with the ISPs May be the best solution for critical branch offices or those with large
traffic volumes.
19
Router(config)# ip route 0.0.0.0 0.0.0.0 ser0/0
Router(config)# ip route 0.0.0.0 0.0.0.0 ser0/1
BGP
Use static routes or PBR: Make them subject to reachability tests toward critical destinations, such
as the DNS server within the ISP. If the DNS servers in one of the ISPs go down or are unreachable, the
static default toward that ISP would be removed. These reachability tests can be performed with Cisco IOS IP SLAs:
Frequently probe the DNS servers Static routes attached to the success of these probes
20
Router(config)# ip route 0.0.0.0 0.0.0.0 ser0/0
Router(config)# ip route 0.0.0.0 0.0.0.0 ser0/1
DNSDNSX
In its simplest form, IP SLAs verifies whether a network element is active and responsive for example: IP address on a router interface Open TCP port on a host
Cisco IOS IP SLAs are also accessible using Simple Network Management Protocol (SNMP) Can be used by performance monitoring applications such as
CiscoWorks Internetwork Performance Monitor (IPM). Allows the router to receive alerts when performance drops below a
specified level and when problems are corrected. These thresholds can trigger additional events and actions.
21
For more information on SNMP… http://www.cisco.com/en/US/docs/internetworking/technology/handbook/
SNMP.html
22
IP SLA Operation
IOS IP SLAs measurements perform active monitoring by generating and analyzing traffic to measure performance: Between Cisco IOS Software devices Between a Cisco IOS device and a host
Each of these is a different type of IP SLA operation With the IP SLAs feature enabled, a router sends synthetic traffic to the
other device
23
IP SLAs Operations
There are two types of IP SLAs
operations:
Those in which the target device is
not running the IP SLAs responder
component (such as a web server or
IP host).
Mostly ICMP generated traffic.
Those in which the target device is
running the IP SLAs responder
component (such as a Cisco router).
Measurement accuracy is
improved when the target is a
responder.
Additional statistics can be
gathered.
R1 R2
IP SLAsSource
DNS Server
Generated traffic to measure the network
Generated ICMP traffic to measure network response
R1 R2
IP SLAsSource
IP SLAsResponder
MIB data retrieved via SNMP
IP SLAs responder is a component embedded in the destination Cisco device that allows the system to anticipate and respond to IP SLAs request packets.
The responder provides accurate measurements without the need for dedicated probes.
Only a Cisco IOS device can be a source for a destination IP SLAs Responder
All SLA probes are configured on the SLA Source CLI SNMP
Source sends probe packets to the target25
IP SLAs Operation with Responder
The following sequence of events occurs for each IP SLAs operation that requires a responder on the target… 26
Step 1 At the start of the control phase… IP SLAs source sends a control message with the configured IP SLAs
information to Responder’s control port UDP 1967 Control message includes the protocol, port number, and duration of the
operation. UDP port 2020 is used for the IP SLAs test packets. MD5 authentication can be used
27
IP SLA Source IP SLA Responder
ControlPhase
1Control Message: Ask Receiver toOpen UDP Port 2020
IP SLAs-ControlUDP Port 1967
Step 2 After the responder processes the control message…
Sends an OK message back to the source Listens on the port specified in the control message (2020) for a specific
duration. If the responder cannot process the control message, it returns an error.
If the IP SLAs source does not receive a response from the responder, it tries to retransmit the control message and will eventually time out if it does not receive a response. 28
IP SLA Source IP SLA Responder
ControlPhase
1
2
Control Message: Ask Receiver toOpen UDP Port 2020
IP SLAs-Control
Responder says OK
UDP Port 1967
Step 3 If an OK message is returned… Source IP SLAs operation moves to the probing phase Sends one or more test packets to the responder to compute
response times. The test messages are sent on control port 2020.
29
IP SLA Source IP SLA Responder
ControlPhase
ProbingPhase
1
2
3
Control Message: Ask Receiver toOpen UDP Port 2020
IP SLAs-Control
IP SLAs-Test
Responder says OK
Sending Test Packets…
UDP Port 1967
Start Listening onUDP Port 2020
UDP Port 2020
Step 4 The responder accepts the test packets and responds with time-stamp
information. See section in book on “SLAs with Responder Time Stamps” The responder disables the user-specified port after it responds to the IP
SLAs measurements packet or when the specified time expires. 30
IP SLA Source IP SLA Responder
ControlPhase
ProbingPhase
1
2
3
4
Control Message: Ask Receiver toOpen UDP Port 2020
IP SLAs-Control
IP SLAs-Test
Responder says OK
Sending Test Packets…
Done: Stop Listening
UDP Port 1967
Start Listening onUDP Port 2020
UDP Port 2020
Configuring Path Control using IOS IP SLAs
The following steps are required to configure Cisco IOS IP SLA functionality:
Step 1 Define one or more probes
Step 2 Define one or more tracking objects
Step 3 Define the action on tracking object
Note: Effective with Cisco IOS Release 12.4(4)T, 12.2(33)SB, and 12.2(33)SXI, the ip sla monitor command is replaced by the ip sla command. 31
Router(config)# ip sla operation-number
Step 1 Define one or more probes There are several SLA probes that can be used. We will focus on using the ICMP Echo operation. 32
Router(config)# ip sla monitor operation-number
Router(config-rtr)# icmp-echo {destination-ip-address | destination-hostname} [source-ip {ip-address | hostname} | source-interface interface-name]
or
Router(config-rtr)# type echo protocol ipIcmpEcho {destination-ip-address | destination-hostname} [source-ipaddr {ip-address | hostname} | source-interface interface-name]
R1(config)# ip sla 1R1(config-ip-sla)# ?IP SLAs entry configuration commands: dhcp DHCP Operation dns DNS Query Operation exit Exit Operation Configuration frame-relay Frame-relay Operation ftp FTP Operation http HTTP Operation icmp-echo ICMP Echo Operation icmp-jitter ICMP Jitter Operation path-echo Path Discovered ICMP Echo Operation path-jitter Path Discovered ICMP Jitter Operation slm SLM Operation tcp-connect TCP Connect Operation udp-echo UDP Echo Operation udp-jitter UDP Jitter Operation voip Voice Over IP Operation
R1(config-ip-sla)#
Effective with Cisco IOS Release 12.4(4)T, 12.2(33)SB, and 12.2(33)SXI, the type echo protocol ipIcmpEcho command is replaced by the icmp-echo command.
icmp-echo Command Example
Although many command options exist, the focus of this section will be on frequency and timeout commands.
R1(config-ip-sla)# icmp-echo 209.165.201.30R1(config-ip-sla-echo)# ?
IP SLAs echo Configuration Commands: default Set a command to its defaults exit Exit operation configuration frequency Frequency of an operation history History and Distribution Data no Negate a command or set its defaults owner Owner of Entry request-data-size Request data size tag User defined tag threshold Operation threshold in milliseconds timeout Timeout of an operation tos Type Of Service verify-data Verify data vrf Configure IP SLAs for a VPN Routing/Forwarding in-stance
R1(config-ip-sla-echo)#
icmp-echo Sub-Commands
frequency seconds
Set the rate at which a specified IP SLAs operation repeats.
The seconds parameter is the number of seconds between the IP SLAs operations with the default being 60 seconds.
Router(config-ip-sla-echo)#
timeout milliseconds
Set the amount of time a Cisco IOS IP SLAs operation waits for a response from its request packet.
The milliseconds parameter is the number of milliseconds (ms) the operation waits to receive a response from its request packet.
Router(config-ip-sla-echo)#
35
Router(config)# ip sla monitor operation-number
Router(config-rtr)# icmp-echo {destination-ip-address | destination-hostname} [source-ip {ip-address | hostname} | source-interface interface-name]
Router(config-rtr)# frequency seconds
Router(config-rtr)# timeout millisecond
Schedule an IP SLA Operation Schedule an IP SLA operation.
Router(config)#
ip sla schedule operation-number [life {forever | seconds}] [start-time {hh:mm[:ss] [month day | day month] | pending | now | after hh:mm:ss}] [ageout seconds] [recurring]]
Note: Effective with Cisco IOS Release 12.4(4)T, 12.2(33)SB, and 12.2(33)SXI,
the ip sla monitor schedule command is replaced by the ip sla schedule command.
The ip sla schedule Command ParametersParameter Description
operation-number Number of the IP SLAs operation to schedule.
life forever (Optional) Schedules the operation to run indefinitely.
life seconds (Optional) Number of seconds the operation actively collects information.The default is 3600 seconds (one hour).
start-time (Optional) Time when the operation starts.
hh:mm[:ss] Specifies an absolute start time using hour, minute, and (optionally) second. Use the 24-hour clock notation.
month (Optional) Name of the month to start the operation in. If month is not specified, the current month is used.
day (Optional) Number of the day (in the range 1 to 31) to start the operation on. If a day is not specified, the current day is used.
pending (Optional) No information is collected. This is the default value.
now (Optional) Indicates that the operation should start immediately.
after hh:mm:ss (Optional) Indicates that the operation should start this amount of time after this command was entered.
ageout seconds (Optional) Number of seconds to keep the operation in memory when it is not actively collecting information (default is 0 seconds which means it never ages out).
recurring (Optional) Indicates that the operation will start automatically at the specified time and for the specified duration every day.
Configures the scheduling parameters for a single Cisco IOS IP SLAs probes.
38
Router(config)# ip sla monitor operation-number
Router(config-rtr)# icmp-echo {destination-ip-address | destination-hostname} [source-ip {ip-address | hostname} | source-interface interface-name]
Router(config-rtr)# frequency seconds
Router(config-rtr)# timeout millisecond
Router(config)# ip sla schedule operation-number [life {forever | seconds}] [start-time {hh:mm[:ss] [month day | day month] | pending | now | after hh:mm:ss}] [ageout seconds] [recurring]
Step 2: Configure IP SLA Object Tracking Define tracking objects, to track the state of IP SLAs operations such as is the device
reachable.
Router(config)#
track object-number ip sla operation-number {state | reachability}
Note: Effective with Cisco IOS Release 12.4(20)T, 12.2(33)SXI1, 12.2(33)SRE
and Cisco IOS XE Release 2.4, the track rtr command is replaced by the track ip sla command.
Parameter Description
object-numberObject number representing the object to be tracked. The range is from 1 to 500.
operation-number Number used for the identification of the IP SLAs operation you are tracking.
state Tracks the operation return code.
reachability Tracks whether the route is reachable.
Step 2 Define one or more tracking objects Tracks the state of an IOS IP SLAs operation such as is the device
reachable40
Router(config)# ip sla monitor operation-number
Router(config-rtr)# icmp-echo {destination-ip-address | destination-hostname} [source-ip {ip-address | hostname} | source-interface interface-name]
Router(config-rtr)# frequency seconds
Router(config-rtr)# timeout millisecond
Router(config)# ip sla schedule operation-number [life {forever | seconds}] [start-time {hh:mm[:ss] [month day | day month] | pending | now | after hh:mm:ss}] [ageout seconds] [recurring]
Router(config)# track object-number ip sla operation-number {state | reachability}
or
Router(config)# track object-number rtr operation-number {state | reachability}
track Command Example R1(config)# track 1 ip sla 1 reachabilityR1(config-track)# ?Tracking instance configuration commands: default Set a command to its defaults delay Tracking delay exit Exit from tracking configuration mode no Negate a command or set its defaults
R1(config-track)#
Configure Tracking Delay Specify a period of time to delay communicating state changes of a tracked object. The delay can help alleviate the affect of flapping objects.
Router(config-track)#
delay {up seconds [down seconds] | [up seconds] down seconds}
Parameter Description
up Time to delay the notification of an up event.
down Time to delay the notification of a down event.
seconds Delay value, in seconds.
The range is from 0 to 180 with the default being 0.
Delay - Specifies a period of time to delay communicating state changes of a tracked object.
The delay can help alleviate the affect of flapping objects.
43
Router(config)# ip sla monitor operation-number
Router(config-rtr)# icmp-echo {destination-ip-address | destination-hostname} [source-ip {ip-address | hostname} | source-interface interface-name]
Router(config-rtr)# frequency seconds
Router(config-rtr)# timeout millisecond
Router(config)# ip sla schedule operation-number [life {forever | seconds}] [start-time {hh:mm[:ss] [month day | day month] | pending | now | after hh:mm:ss}] [ageout seconds] [recurring]
Router(config)# track object-number rtr operation-number {state | reachability}
Router(config-track)# delay {up seconds [down seconds] | [up seconds] down seconds}
Step 3 Define the action on tracking object The static route is used to track the object.
Examples coming soon!
44
Router(config)# ip sla monitor operation-number
Router(config-rtr)# icmp-echo {destination-ip-address | destination-hostname} [source-ip {ip-address | hostname} | source-interface interface-name]
Router(config-rtr)# frequency seconds
Router(config-rtr)# timeout millisecond
Router(config)# ip sla schedule operation-number [life {forever | seconds}] [start-time {hh:mm[:ss] [month day | day month] | pending | now | after hh:mm:ss}] [ageout seconds] [recurring]
Router(config)# track object-number rtr operation-number {state | reachability}
Router(config-track)# delay {up seconds [down seconds] | [up seconds] down seconds}
Router(config)# ip route prefix mask {ip-address | interface-type interface-number [ip-address]} [dhcp] [distance] [name next-hop-name] [permanent | track number] [tag tag]
Verifying IP SLAs
Command Description
show ip sla configuration [operation]
Display configuration values including all defaults for all Cisco IOS IP SLAs operations, or for a specified operation.
The operation parameter is the number of the IP SLAs operation for which the details will be displayed.
show ip sla statistics [operation-number | details]
Display the current operational status and statistics of all Cisco IOS IP SLAs operations, or of a specified operation.
These commands will be explained during the examples.
show ip sla configuration Example
Note: • Effective with Cisco IOS Release 12.4(20)T, 12.2(33)SXI1, 12.2(33)SRE and Cisco IOS
XE Release 2.4, the show ip sla monitor configuration command is replaced by the show ip sla configuration command.
R1# show ip sla configuration 1IP SLAs, Infrastructure Engine-II.Entry number: 1Owner:Tag:Type of operation to perform: icmp-echoTarget address/Source address: 209.165.201.30/0.0.0.0Type Of Service parameter: 0x0Request size (ARR data portion): 28Operation timeout (milliseconds): 5000Verify data: NoVrf 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<output omitted>
show ip sla statistics Example
Note: • Effective with Cisco IOS Release 12.4(20)T, 12.2(33)SXI1, 12.2(33)SRE and Cisco IOS
XE Release 2.4, the show ip sla monitor statisitcs command is replaced by the show ip sla statistics command.
R1# show ip sla statisticsIPSLAs Latest Operation Statistics
IPSLA operation id: 1
Latest operation start time: *21:22:29.707 UTC Fri Apr 2 2010Latest operation return code: OKNumber of successes: 5Number of failures: 0Operation time to live: Forever<output omitted>
Tracking Reachability to Two ISPs Example
In this scenario, Customer A is multihoming to two ISPs using R1 which is configured with two default floating static routes.
• The static route to R2 (ISP-1) has been given an administrative distance of 2 making it preferred and therefore the primary default route.
• The static route to R3 (ISP-2) has been given an administrative distance of 3 making it the backup default route.
Primary Path
ISP 1
172.16.1.0R1
R210.1.1.0 .1
Backup Path
Internet
CustomerA
R3
.1ISP 2
10.1.3.3
172.16.3.3
Tracking Reachability to Two ISPs Example
What would happen if a link within the ISP 1 provider infrastructure were to fail?
• The link from R1 to R2 would still remain up and the R1 would continue to use that link because the default static route would still be valid.
The solution to this issue is the Cisco IOS IP SLAs feature.• Configuring IP SLAs to continuously check the reachability of a specific
destination (such as the ISP’s DNS server, or any other specific destination) and conditionally announce the default route only if the connectivity is verified.
Primary Path
ISP 1
172.16.1.0R1
R210.1.1.0 .1
Backup Path
Internet
CustomerA
R3
.1ISP 2
10.1.3.3
172.16.3.3
The first step in this configuration defines the probe.• Probe 11 is defined by the ip sla 11 command. • The test defined with the icmp-echo 10.1.3.1 command specifies that the ICMP echoes are
sent to destination 10.1.3.3 (DNS Server) to check connectivity. • The frequency 10 command schedules the connectivity test to repeat every 10 seconds. • The ip sla schedule 11 life forever start-time now command defines the start and end time
of the connectivity test for probe 11; the start time is now and it will continue forever.
R1(config)# ip sla 11R1(config-ip-sla)# icmp-echo 10.1.3.3R1(config-ip-sla-echo)# frequency 10R1(config-ip-sla-echo)# exitR1(config)# ip sla schedule 11 life forever start-time nowR1(config)# track 1 ip sla 11 reachabilityR1(config-track)# delay down 10 up 1R1(config-track)# exitR1(config)# ip route 0.0.0.0 0.0.0.0 10.1.1.1 2 track 1R1(config)# ip route 0.0.0.0 0.0.0.0 172.16.1.1 3
Primary Path
ISP 1
172.16.1.0R1
R210.1.1.0 .1
Backup Path
Internet
CustomerA
R3
.1ISP 2
10.1.3.3
172.16.3.3
Probe
The second step defines the tracking object, which is linked to the probe from the first step.
• The track 1 ip sla 11 reachability command specifies that object 1 is tracked; it is linked to probe 11 (defined in the first step) so that the reachability of the 10.1.3.3 is tracked.
R1(config)# ip sla 11R1(config-ip-sla)# icmp-echo 10.1.3.3R1(config-ip-sla-echo)# frequency 10R1(config-ip-sla-echo)# exitR1(config)# ip sla schedule 11 life forever start-time nowR1(config)# track 1 ip sla 11 reachabilityR1(config-track)# delay down 10 up 1R1(config-track)# exitR1(config)# ip route 0.0.0.0 0.0.0.0 10.1.1.1 2 track 1R1(config)# ip route 0.0.0.0 0.0.0.0 172.16.1.1 3
Primary Path
ISP 1
172.16.1.0R1
R210.1.1.0 .1
Backup Path
Internet
CustomerA
R3
.1ISP 2
10.1.3.3
172.16.3.3
Probe
TrackingObject
The last step defines an action based on the status of the tracking object.
• The ip route 0.0.0.0 0.0.0.0 10.1.1.1 2 track 1 command conditionally configures the default route, via 10.1.1.1, with an administrative distance of 2, if the result of tracking object 1 is true.
Thus, if 10.1.3.3 is reachable, a static default route via 10.1.1.1 with an administrative distance of 2, is installed in the routing table.
R1(config)# ip sla 11R1(config-ip-sla)# icmp-echo 10.1.3.3R1(config-ip-sla-echo)# frequency 10R1(config-ip-sla-echo)# exitR1(config)# ip sla schedule 11 life forever start-time nowR1(config)# track 1 ip sla 11 reachabilityR1(config-track)# delay down 10 up 1R1(config-track)# exitR1(config)# ip route 0.0.0.0 0.0.0.0 10.1.1.1 2 track 1R1(config)# ip route 0.0.0.0 0.0.0.0 172.16.1.1 3
Primary Path
ISP 1
172.16.1.0R1
R210.1.1.0 .1
Backup Path
Internet
CustomerA
R3
.1ISP 2
10.1.3.3
172.16.3.3
Probe
TrackingObject
Status of Tracking Object
Defining an action based on the status of the tracking object ip route 0.0.0.0 0.0.0.0 10.1.1.1 2 track 1: Conditionally announces the default route, via 10.1.1.2,
with an administrative distance 2 if the result of tracking object 1 is true – if the probe is successful.
To summarize: If 10.1.3.3 is reachable, a static default route via 10.1.1.2 with an administrative distance of 2 is “offered” to the routing table.
Because the default route via R3 has a higher AD of 3, if the path via R2 is available, this path will be the backup path.
R1(config)# ip sla 11R1(config-ip-sla)# icmp-echo 10.1.3.3R1(config-ip-sla-echo)# frequency 10R1(config-ip-sla-echo)# exitR1(config)# ip sla schedule 11 life forever start-time nowR1(config)# track 1 ip sla 11 reachabilityR1(config-track)# delay down 10 up 1R1(config-track)# exitR1(config)# ip route 0.0.0.0 0.0.0.0 10.1.1.1 2 track 1R1(config)# ip route 0.0.0.0 0.0.0.0 172.16.1.1 3
Primary Path
ISP 1
172.16.1.0R1
R210.1.1.0 .1
Backup Path
Internet
CustomerA
R3
.1ISP 2
10.1.3.3
172.16.3.3
Probe
TrackingObject
Status of Tracking Object
If 10.1.1.1 is reachable, a static default route via R2 with an administrative distance of 2, is installed in the routing table
If 172.16.1.1 is reachable, a static default route via R3 with an administrative distance of 3 is “available” to the routing table as a backup path.
R1(config)# ip sla 11R1(config-ip-sla)# icmp-echo 10.1.3.3R1(config-ip-sla-echo)# frequency 10R1(config-ip-sla-echo)# exitR1(config)# ip sla schedule 11 life forever start-time nowR1(config)# track 1 ip sla 11 reachabilityR1(config-track)# delay down 10 up 1R1(config-track)# exitR1(config)# ip route 0.0.0.0 0.0.0.0 10.1.1.1 2 track 1R1(config)# ip route 0.0.0.0 0.0.0.0 172.16.1.1 3
Primary Path
ISP 1
172.16.1.0R1
R210.1.1.0 .1
Backup Path
Internet
CustomerA
R3
.1ISP 2
10.1.3.3
172.16.3.3
Probe
TrackingObject
Status of Tracking Object
Tracking Reachability to Two ISPs Example IP SLA 11 continuously sends ICMP Echo Requests to the DNS server (10.1.3.3) every 10 seconds.
IP SLAs is tracking that object and as long as the DNS server is reachable, the default route to R2
will be in the routing table.
R1(config)# ip sla 11R1(config-ip-sla)# icmp-echo 10.1.3.3R1(config-ip-sla-echo)# frequency 10R1(config-ip-sla-echo)# exitR1(config)# ip sla schedule 11 life forever start-time nowR1(config)# track 1 ip sla 11 reachabilityR1(config-track)# delay down 10 up 1R1(config-track)# exitR1(config)# ip route 0.0.0.0 0.0.0.0 10.1.1.1 2 track 1R1(config)# ip route 0.0.0.0 0.0.0.0 172.16.1.1 3
Primary Path
ISP 1
172.16.1.0R1
R210.1.1.0 .1
Backup Path
Internet
CustomerA
R3
.1ISP 2
10.1.3.3
172.16.3.3
Other Examples
Customer A is multihoming to two ISPs. Customer A is not using BGP with the ISPs; but using static default routes. Two default static routes with different administrative distances are
configured Link to ISP-1 is the primary link Link to ISP-2 is the backup link
The static default route with the lower administrative distance will be preferred and injected into the routing table.
However, if there is a problem within the ISP-1 router or with its connectivity toward the interface but its interface to Customer A is still up, all traffic from Customer A will still go to that ISP
The traffic may then get lost within the ISP. 57
Router(config)# ip route 0.0.0.0 0.0.0.0 fa0/0
Router(config)# ip route 0.0.0.0 0.0.0.0 fa0/1 5fa0/0
fa0/1
172.16.1.1
Example: Network Availability
The solution to this issue is the Cisco IOS IP SLAs functionality Configure the SLAs to:
Continuously check the reachability of a specific destination such as: Provider edge [PE] router interface ISP's DNS server Any other specific destination
Conditionally announce the default route only if the connectivity is verified.
58
fa0/0
fa0/1
172.16.1.1172.16.1.1
Defining the Probe ip sla: defines probe 11 type echo: specifies that the ICMP echoes are sent:
To destination 10.1.1.1 to check connectivity With the source interface of FastEthernet0/0
frequency 10: schedules the connectivity test to repeat every 10 seconds. ip sla monitor schedule 11 life forever start-time now: defines the start
time of now and it will continue forever 59
R1(config)# ip sla monitor 11
R1(config-rtr)# type echo protocol ipIcmpEcho 10.1.1.1 source-interface fa0/0
R1(config-rtr)# frequency 10
R1(config)# ip sla monitor schedule schedule 11 life forever start-time now
R1(config)# track 1 rtr 11 reachability
R1(config)# ip route 0.0.0.0 0.0.0.0 fa0/0 2 track 1
Probe
TrackingObject
Status of Tracking Object
172.16.1.1
Defining the Tracking Object track 1 rtr 11 reachability: Specifies that:
Object 1 is tracked (next step) Linked to probe 11 (defined in the first step) so that the reachability of
the 10.1.1.1 is tracked.
60
R1(config)# ip sla monitor 11
R1(config-rtr)# type echo protocol ipIcmpEcho 10.1.1.1 source-interface fa0/0
R1(config-rtr)# frequency 10
R1(config)# ip sla monitor schedule schedule 11 life forever start-time now
R1(config)# track 1 rtr 11 reachability
R1(config)# ip route 0.0.0.0 0.0.0.0 fa0/0 2 track 1
Probe
TrackingObject
Status of Tracking Object
172.16.1.1
Defining an action based on the status of the tracking object ip route 0.0.0.0 0.0.0.0 fa0/0 2 track 1: Conditionally announces the default
route, out fa0/0, with an administrative distance 2 (could have left it at default of 1) if the result of tracking object 1 is true – if the probe is successful.
To summarize: If 10.1.1.1 is reachable, a static default route out Fa0/0 with an administrative distance of 2, is installed in the routing table. 61
R1(config)# ip sla monitor 11
R1(config-rtr)# type echo protocol ipIcmpEcho 10.1.1.1 source-interface fa0/0
R1(config-rtr)# frequency 10
R1(config)# ip sla monitor schedule schedule 11 life forever start-time now
R1(config)# track 1 rtr 11 reachability
R1(config)# ip route 0.0.0.0 0.0.0.0 fa0/0 2 track 1
Probe
TrackingObject
Status of Tracking Object
172.16.1.1
AD=2
Defining the Probe ip sla: defines probe 22 type echo: specifies that the ICMP echoes are sent:
To destination 172.16.1.1 to check connectivity, With the source interface of FastEthernet0/1
frequency 10: schedules the connectivity test to repeat every 10 seconds. ip sla monitor schedule 22 life forever start-time now: defines the start
time of now and it will continue forever 62
R1(config)# ip sla monitor 22
R1(config-rtr)# type echo protocol ipIcmpEcho 172.16.1.1 source-interface fa0/1
R1(config-rtr)# frequency 10
R1(config)# ip sla monitor schedule 22 life forever start-time now
R1(config)# track 2 rtr 22 reachability
R1(config)# ip route 0.0.0.0 0.0.0.0 fa0/1 3 track 2
Probe
TrackingObject
Status of Tracking Object
172.16.1.1
Defining the Tracking Object track 1 rtr 22 reachability: Specifies that:
Object 2 is tracked (next step) Linked to probe 22 (defined in the first step) so that the reachability of
the 172.16.1.1 is tracked.
63
R1(config)# ip sla monitor 22
R1(config-rtr)# type echo protocol ipIcmpEcho 172.16.1.1 source-interface fa0/1
R1(config-rtr)# frequency 10
R1(config)# ip sla monitor schedule 22 life forever start-time now
R1(config)# track 2 rtr 22 reachability
R1(config)# ip route 0.0.0.0 0.0.0.0 fa0/1 3 track 2
Probe
TrackingObject
Status of Tracking Object
172.16.1.1
Defining an action based on the status of the tracking object ip route 0.0.0.0 0.0.0.0 fa 0/1 3 track 2: Conditionally announces the
default route, exit fa0/1, with an administrative distance 3 if the result of tracking object 1 is true – if the probe is successful.
To summarize: If 172.16.1.1 is reachable, a static default route exit fa0/1 with an administrative distance of 3 is “offered” to the routing table.
Because this default route has a higher AD of 3, if the path via R2 is available, this path will be the backup path.
64
R1(config)# ip sla monitor 22
R1(config-rtr)# type echo protocol ipIcmpEcho 172.16.1.1 source-interface fa0/1
R1(config-rtr)# frequency 10
R1(config)# ip sla monitor schedule 22 life forever start-time now
R1(config)# track 2 rtr 22 reachability
R1(config)# ip route 0.0.0.0 0.0.0.0 fa0/1 3 track 2
Probe
TrackingObject
Status of Tracking Object
172.16.1.1
AD=2
AD=3
65
R1(config)# ip sla monitor 11
R1(config-rtr)# type echo protocol ipIcmpEcho 10.1.1.1 source-interface fa0/0
R1(config-rtr)# frequency 10
R1(config)# ip sla monitor schedule 11 life forever start-time now
R1(config)# track 1 rtr 11 reachability
R1(config)# ip route 0.0.0.0 0.0.0.0 fa0/0 2 track 1
Probe
TrackingObject
Status of Tracking Object
R1(config)# ip sla monitor 22
R1(config-rtr)# type echo protocol ipIcmpEcho 172.16.1.1 source-interface fa0/1
R1(config-rtr)# frequency 10
R1(config)# ip sla monitor schedule 22 life forever start-time now
R1(config)# track 2 rtr 22 reachability
R1(config)# ip route 0.0.0.0 0.0.0.0 fa0/1 3 track 2
Probe
TrackingObject
Status of Tracking Object
172.16.1.1
AD=2
AD=3
If 10.1.1.1 is reachable, a static default route via R2 with an administrative distance of 2, is installed in the routing table
If 172.16.1.1 is reachable, a static default route via R3 with an administrative distance of 3 is “available” to the routing table as a backup path.
Example 2: DNS Reachability
R3 represents a branch office connected to two ISPs. We use Cisco IOS IP SLAs to track the reachability to the DNS servers
(with IP addresses 10.0.8.1 and 10.0.8.2), and tie the results to the static default routes on R3.
If there is a DNS server failure: Then the Cisco IOS IP SLAs probes will fail The static default route to that DNS will be removed All traffic will be rerouted toward the other ISP
66
EIGRP
Step 1 Verify reachability to the DNS servers
67
Track 1SLA 99
Track 2SLA 100
2.2 1.2EIGRP
Step 2 Configure the IOS IP SLAs ip sla monitor: Creates an ICMP echo probe on R3 to the first DNS server
Operation number 99 is locally significant only to the router. Type echo: Create an ICMP echo probe to the DNS server on ISP1 frequency 10: schedules the connectivity test to repeat every 10 seconds.
The probe is scheduled to start now, and to run forever. We similarly create a second probe, 100, to test connectivity to the second
DNS server.
68
R3(config)# ip sla monitor 99
R3(config-rtr)# type echo protocol ipIcmpEcho 10.0.8.1
R3(config-rtr)# frequency 10
R3(config)# ip sla monitor schedule 99 life forever start-time now
R3(config)# ip sla monitor 100
R3(config-rtr)# type echo protocol ipIcmpEcho 10.0.8.2
R3(config-rtr)# frequency 10
R3(config)# ip sla monitor schedule 100 life forever start-time now
Step 3 Verify Cisco IOS SLA Operations Verify the IP SLAs configuration, using the show ip sla monitor Echo operation to 10.0.8.1 With a frequency of 10 seconds that it has already started (the start time
has already passed) 69
- more -
show ip sla monitor statistics display the number of successes, failures, and the results of the latest operations. Operation 99
Succeeded 16 times already No failures Latest operation returned an OK result.
Operation 100 Succeeded 15 times No failures Latest operation returned an OK result 70
Step 4 Configure tracking objects The first tracking object is tied to IP SLA object 99
10 seconds of down delay and 1 second of up delay If the DNS server fails momentarily and comes back up within 10 seconds,
there is no impact.
Step 5 Configure static default routes (or PBR) tied to the tracking object ip route creates a static default route via 192.168.2.2 (R1) that appears or
disappears, depending on the success or failure of the IP SLAs. Reference the tracking object 1, which references IP SLAs op. 99.
71
R3(config)# ip sla monitor 99
R3(config-rtr)# type echo protocol ipIcmpEcho 10.0.8.1
R3(config-rtr)# frequency 10
R3(config)# ip sla monitor schedule 99 life forever start-time now
R3(config)# track 1 rtr 99 reachability
R3(config-track)# delay down 10 up 1
R3(config)# ip route 0.0.0.0 0.0.0.0 192.168.2.2 track 1
R3(config)# ip sla monitor 100
R3(config-rtr)# type echo protocol ipIcmpEcho 10.0.8.2
R3(config-rtr)# frequency 10
R3(config)# ip sla monitor schedule 100 life forever start-time now
R3(config)# track 2 rtr 100 reachability
R3(config-track)# delay down 10 up 1
R3(config)# ip route 0.0.0.0 0.0.0.0 192.168.1.2 track 2
IP SLA object 100 and has a similar configuration
We examine the static routes in the IP routing table This output confirms that both static default routes currently appear in the
routing table.
72
R3(config)# ip route 0.0.0.0 0.0.0.0 192.168.2.2 track 1
R3(config)# ip route 0.0.0.0 0.0.0.0 192.168.1.2 track 2
Step 6 Verify the dynamic operations and routing changes when the tracked objects fail
Shutdown the DNS address on R2
73
debug ip routing
X
The EIGRP route to 10.0.8.2 is immediately deleted; there are now no routes to 10.0.8.2.
This is the object we are tracking with the track 2 command It tracks reachability to IP SLA object 100, which is an ICMP echo to
10.0.8.2. After about 10 seconds, the value specified in the delay command, the
static default route via 192.168.1.2 (R2) is deleted. 74
X
show ip sla statistics On SLA Object 100:
The latest return code is Timeout There have been 11 failures These are failures in the ICMP echo to 10.0.8.2
75
X
We see that only one static default remains, via 192168.2.2 (R1).
76
X
Connectivity to the R2 DNS is restored The EIGRP route to 10.0.8.2 comes up… And almost immediately the default static route via 192.168.1.2 (R2) comes
up
77
R3# debug ip routing
We again examine the routing table and verify that both static default routes are there.
Full connectivity has been restored.
78
One last look at the commands. If there is a DNS server failure:
Then the Cisco IOS IP SLAs probes will fail The static default route to that DNS will be removed All traffic will be rerouted toward the other ISP
79
R3(config)# ip sla monitor 99
R3(config-rtr)# type echo protocol ipIcmpEcho 10.0.8.1
R3(config-rtr)# frequency 10
R3(config)# ip sla monitor schedule 99 life forever start-time now
R3(config)# track 1 rtr 99 reachability
R3(config-track)# delay down 10 up 1
R3(config)# ip route 0.0.0.0 0.0.0.0 192.168.2.2 track 1
R3(config)# ip sla monitor 100
R3(config-rtr)# type echo protocol ipIcmpEcho 10.0.8.2
R3(config-rtr)# frequency 10
R3(config)# ip sla monitor schedule 100 life forever start-time now
R3(config)# track 2 rtr 100 reachability
R3(config-track)# delay down 10 up 1
R3(config)# ip route 0.0.0.0 0.0.0.0 192.168.1.2 track 2
IP SLA object 100 and has a similar configuration
Example 3: Type DNS
To measure the difference between the time taken to send a DNS request and the time a reply is received by a Cisco device, use the IP SLAs DNS operation.
To view and interpret the results of an IP SLAs operation use the show ip sla monitor statistics command.
Checking the output for fields that correspond to criteria in your service level agreement will help you determine whether the service metrics are acceptable.
80
RouterB(config)# ip sla monitor 11 RouterB(config-rtr)# type dns target-addr www.cisco.com name-server 172.20.2.132 RouterB(config-rtr)# frequency 60 RouterB(config-rtr)# exit RouterB(config)# ip sla monitor schedule 11 life forever start-time now
Cisco Internetwork Performance Monitor (IPM) Several Cisco network management applications use IP SLAs One example
is the Cisco Internetwork Performance Monitor (IPM) in CiscoWorks2000 RWAN bundle. 81
Intro to Cisco IP SLA Operations - SolarWinds Video http://www.youtube.com/watch?v=x-fQr24kFKg
82
Network Performance Monitoring: Using IP SLA Monitor with Orion NPM
http://www.youtube.com/watch?v=YKXoexOVsaE&feature=related
83
http://www.cisco.com/en/US/docs/ios/12_4/ip_sla/configuration/guide/hsla_c.html
84
http://www.cisco.com/en/US/technologies/tk648/tk362/tk920/technologies_white_paper09186a00802d5efe.html 85
Policy Based Routing (PBR)
86
Using Policy Based Routing to Control Path Selection
Routers normally forward packets by: Examining the destination IP addresses of the packet Finding the best match in their routing table
By using PBR you can implement policies that selectively cause packets to take different paths based on: source address protocol types application types
PBR overrides the router’s normal routing procedures. PBR is applied to incoming packets PBR also provides a mechanism to mark packets with different types of
service (ToS). Can be used in conjunction with queuing techniques so that certain
kinds of traffic can receive preferential service.87
Source-based transit provider selection— ISPs and other organizations can use PBR to route traffic originating from different sets of users through different Internet connections across policy routers. (later in BGP)
QoS—Can provide QoS to differentiated traffic by setting the ToS values in the IP packet headers in routers and then using queuing mechanisms to prioritize traffic.
Cost savings—Can direct the bulk traffic associated with a specific activity to use a higher-bandwidth, high-cost link for a short time and to continue basic connectivity over a lower-bandwidth, low-cost link for interactive traffic.
Load sharing—In addition to the dynamic load-sharing capabilities managers can implement policies to distribute traffic among multiple paths based on the traffic characteristics.
88
PBR involves configuring a route map with match and set commands and then applying the route map to the interface.
Route maps are like complex access lists that allow some conditions to be tested against the packet or route in question using match commands. If the conditions match:
Actions can be taken to modify attributes of the packet or route These actions are specified by set commands.
BIG difference between route maps and ACLs: Route map can modify the packet or route using set commands
89
Route Map
ACL Prefix List
A single match statement may contain multiple conditions. At least one condition in the match statement must be true for that
match statement to be considered a match Logical OR operation
A route map statement may contain multiple match statements. All match statements in the route map statement must be considered
true for the route map statement to be considered matched. Logical AND operation
90
If {(x or y or z) and (a) match} then {set b and c}
Else
If q matches then set r
Else
Set nothing
If the statement is marked as deny And packet meets the match criteria Then the packet is not policy-based routed
Packet is routed normally If the statement is marked as permit
And packet meets the match criteria Then set commands are applied When the first set command is chosen for the next-hop address or exit
interface is chosen other set commands for changing the destination are ignored.
If no match is found in the route map Packet is routed normally (not dropped)
If you want to drop all packets that do not have a match with a route map statement: Create a route map statement with a set default interface
null 0 (later)91
deny
match ip address Command Used to specify match criteria for a packet’s source address when using a
standard access list An extended access list can be used to specify match criteria based on
source and destination addresses, application, protocol type, and ToS.
92
match ip address {access-list-number| access-list-name | prefix-list prefix-list-name [prefix-list-name}
match length Used to establish criteria based on the packet length between specified
minimum and maximum values in bytes.
93
match length min max
set ip next-hop Provides a list of IP addresses used to specify the adjacent next-hop router
to which the packets should be forwarded. If more than one IP address is specified, the first IP address associated with
a currently up connected interface is used to route the packets. Note: The routing table is only checked to make sure the the next hop can
be reached, not for an explicit route to the packet’s destination address. 94
set ip next-hop ip-address [...ip-address]
set interface Provides a list of exit interfaces through which the packets can be routed. If more than one interface is specified, the first interface that is found to be
up is used to forward the packets. Note: If there no explicit route for the destination address of the packet in
the routing table (unknown address or broadcast), the set interface command has no effect and is ignored. 95
set interface type number [... type number]
set ip default next-hop A packet is routed by the set ip default next-hop command only if there is
no explicit route for the packet’s destination address in the routing table. A default route (0.0.0.0/0) is not considered as an explicit match.
If more than one IP address is specified, the first next hop specified that appears to be adjacent to the router is used. 96
set ip default next-hop ip-address [...ip-address]
Default route
set default interface A packet is routed by the set ip default interface command only If there is
no explicit route for the packet’s destination address in the routing table. A default route (0.0.0.0/0) is not considered as an explicit match.
97
set default interface type number [...type number]
Default route
set ip tos Used to set some of the bits in the IP ToS field in the IP packet.
set ip precedence Enables you to set the 3 IP precedence bits in the IP packet header.
These commands is used when implementing QoS and can be used by other QoS services, such as weighted fair queuing (WFQ) and weighted random early detection (WRED).
98
set ip precedence [number | name]
set ip tos [number | name]
Example: Using Policy-Based Routing When Connecting Two ISPs
Router A provides Internet access for a private enterprise and is connected to two different ISPs.
This router is advertising a 0.0.0.0 default route into the enterprise network to avoid a large Internet routing table.
Thus, when traffic from the enterprise networks 10.1.0.0 and 10.2.0.0 reaches router A, it can go to either ISP A or ISP B.
99
Default route
PBR is implemented on router A to shape, or load balance, traffic from router A to each of the ISPs.
All traffic sourced from the 10.1.0.0 subnet is forwarded to ISP A if there is not a specific route to the destination in the routing table.
All traffic sourced from the 10.2.0.0 subnet is forwarded to ISP B if there is not a specific route to the destination in the routing table.
There is no default route. All traffic not sourced from 10.1.0.0 or 10.2.0.0 will be dropped.
100
101
RA(config)# interface ser 0/0/0
RA(config-if)# ip address 192.168.6.5 255.255.255.0
RA(config)# interface ser 0/0/1
RA(config-if)# ip address 172.16.7.6 255.255.255.0
RA(config)# interface fa 0/0
RA(config-if)# ip address 10.1.1.1 255.255.255.0
RA(config-if)# ip policy route-map equal-access
RA(config)# route-map equal-access permit 10
RA(config-route-map)# match ip address 1
RA(config-route-map)# set ip default next-hop 192.168.6.6
RA(config)# route-map equal-access permit 20
RA(config-route-map)# match ip address 2
RA(config-route-map)# set ip default next-hop 172.16.7.7
RA(config)# route-map equal-access permit 30
RA(config-route-map)# set default interface null0
RA(config)# access-list 1 permit 10.1.0.0 0.0.255.255
RA(config)# access-list 2 permit 10.2.0.0 0.0.255.255
No match command matches all packets.Drops all traffic not sourced from subnet 10.1.0.0 or 10.2.0.0
Match all packets sourced from any host in subnet 10.1.0.0. If there is a match, and if the router has no explicit route for the packet’s destination, it is sent to next-hop address 192.168.6.6 (ISP A’s router).
Match all packets sourced from any host in subnet 10.2.0.0. If there is a match, and if the router has no explicit route for the packet’s destination, it is sent to next-hop address 172.16.7.7 (ISP B’s router).
show ip policy command output, indicating that the route map called equal-access is used for PBR on the router’s FastEthernet 0/0 interface.
show route-map command output, indicating that three packets have matched sequence 10 of the equal-access route map.
102
debug ip policy command output. The output indicates that:
1. Because the source address of 10.1.1.1 matches line 10 of route map equal-access …
2. A packet from 10.1.1.1 destined for 172.19.1.1
3. Has been received on interface FastEthernet 0/0
4. Has been policy-routed on serial 0/0/0 to next hop 192.168.6.6 103
1
2 23
4
Example: Using Policy-Based Routing Based on Source Address
Router A has a policy that packets with a source address of 192.168.2.1 (on the other side of router B) should go out to router C’s interface Serial 0/0/1, 172.17.1.2.
All other packets should be routed according to their destination address.
104
192.168.2.1
Router A’s Serial 0/0/2 interface, where packets from 192.168.2.1 go into router A is configured to do policy routing with the ip policy route-map command.
It tests the IP addresses in packets against access list 1 to determine which packets will be policy-routed (source address of 192.168.2.1)
Packets that match access list 1 are sent to the next-hop address 172.17.1.2, which is router C’s Serial 0/0/1 interface.
All other packets are forwarded normally, according to their destination address
105
RA(config)# interface ser 0/0/2
RA(config-if)# ip address 172.16.1.2 255.255.255.0
RA(config-if)# ip policy route-map test
RA(config)# route-map test permit 10
RA(config-route-map)# match ip address 1
RA(config-route-map)# set ip next-hop 172.17.1.2
RA(config)# access-list 1 permit 192.168.2.1 0.0.0.0
show ip policy It indicates that the route map called test is used for policy routing on the
router’s interface Serial 0/0/2
show route-map Indicates that three packets have matched this route map
106
debug ip policy Shows a packet from 172.16.1.1 destined for 192.168.1.1 was received on
interface Serial 0/0/2 and that it was rejected by the policy on that interface. The packet is routed normally (by destination).
Another packet, from 192.168.2.1 destined for 192.168.1.1, was later received on the same interface, Serial 0/0/2. This packet matched the policy on that interface and therefore was
policy-routed and sent out interface Serial 0/0/1 to 172.17.1.2. 107
FYI - Alternative Solution IP SLAs Configuration Example Using PBR
This section presents an alternative solution to the configuration of the R3 router given earlier in this chapter in the "Path Control using IP SLAs Examples" section. A partial configuration is shown in Example 5-22, providing just the configuration for reachability to the R1 router. Explanatory comments are provided within the configuration. (Configuration for reachability to the R2 router would be similar.) Using PBR allows the configuration to be very granular, to support other options. In this example, PBR points to a next hop address that is tracked via Cisco IOS IP SLAs.
108
If there is a DNS server failure: Then the Cisco IOS IP SLAs probes will fail The static default route to that DNS will be removed All traffic will be rerouted toward the other ISP
109
R3(config)# ip sla monitor 99
R3(config-rtr)# type echo protocol ipIcmpEcho 10.0.8.1
R3(config-rtr)# frequency 10
R3(config)# ip sla monitor schedule 99 life forever start-time now
R3(config)# track 1 rtr 99 reachability
R3(config-track)# delay down 10 up 1
R3(config)# ip route 0.0.0.0 0.0.0.0 192.168.2.2 track 1
R3(config)# ip sla monitor 100
R3(config-rtr)# type echo protocol ipIcmpEcho 10.0.8.2
R3(config-rtr)# frequency 10
R3(config)# ip sla monitor schedule 100 life forever start-time now
R3(config)# track 2 rtr 100 reachability
R3(config-track)# delay down 10 up 1
R3(config)# ip route 0.0.0.0 0.0.0.0 192.168.1.2 track 2
IP SLA object 100 and has a similar configuration
set ip next-hop verify-availability - To configure policy routing to verify that the next hops of a route map is a CDP neighbor before policy routing to that next hop, use the set ip next-hop verify-availability command in route-map configuration mode. CDP must be enabled
Object 1 will be up if the router can ping 10.0.8.1 Enable PBR using route-map IP-SLA c Configure a route-map to set the next-hop verify-availability to verify the
reachability of the next hop of a route map before the router performs PBR to that next hop 110
R3(config)# ip sla monitor 99
R3(config-rtr)# type echo protocol ipIcmpEcho 10.0.8.1
R3(config-rtr)# frequency 10
R3(config-rtr)# timeout 5000
R3(config)# ip sla monitor schedule 99 life forever start-time now
R3(config)# track 1 rtr 99 reachability
R3(config)# interface ser 0/0/2
R3(config-if)# ip address 10.2.8.1 255.255.255.0
R3(config-if)# ip policy route-map IP-SLA
R3(config)# route-map test IP-SLA 10
R3(config-route-map)# set ip next-hop verify-availability 192.168.2.1 track 1
CIS 185 CCNP ROUTECh. 5 Implementing Path Control
Rick Graziani
Cabrillo College