CIS 185 CCNP ROUTE Ch. 5 Implementing Path Control

CIS 185 CCNP ROUTECh. 5 Implementing Path Control

Rick Graziani

Cabrillo College

graziani@cabrillo.edu

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

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

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)

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).

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

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

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

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.

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

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.

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

+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

Cisco IOS SLAs

Using Cisco IOS IP SLAs to Control Path Selection

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)

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

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.

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

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.

For more information on SNMP… http://www.cisco.com/en/US/docs/internetworking/technology/handbook/

SNMP.html

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

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.

IP SLAsSource

DNS Server

Generated traffic to measure the network

Generated ICMP traffic to measure network response

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

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

ControlPhase

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.

ControlPhase

ProbingPhase

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

ControlPhase

ProbingPhase

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]

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)#

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.

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)# track object-number ip sla operation-number {state | reachability}

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.

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!

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

172.16.1.0R1

R210.1.1.0 .1

Backup Path

Internet

CustomerA

.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

172.16.1.0R1

R210.1.1.0 .1

Backup Path

Internet

CustomerA

.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

172.16.1.0R1

R210.1.1.0 .1

Backup Path

Internet

CustomerA

.1ISP 2

10.1.3.3

172.16.3.3

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.

Primary Path

172.16.1.0R1

R210.1.1.0 .1

Backup Path

Internet

CustomerA

.1ISP 2

10.1.3.3

172.16.3.3

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.

Primary Path

172.16.1.0R1

R210.1.1.0 .1

Backup Path

Internet

CustomerA

.1ISP 2

10.1.3.3

172.16.3.3

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.

Primary Path

172.16.1.0R1

R210.1.1.0 .1

Backup Path

Internet

CustomerA

.1ISP 2

10.1.3.3

172.16.3.3

TrackingObject

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.

Primary Path

172.16.1.0R1

R210.1.1.0 .1

Backup Path

Internet

CustomerA

.1ISP 2

10.1.3.3

172.16.3.3

TrackingObject

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.

Primary Path

172.16.1.0R1

R210.1.1.0 .1

Backup Path

Internet

CustomerA

.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

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.

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

TrackingObject

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.

TrackingObject

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

TrackingObject

172.16.1.1

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 schedule 22 life forever start-time now

TrackingObject

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.

TrackingObject

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.

TrackingObject

172.16.1.1

TrackingObject

172.16.1.1

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

Step 1 Verify reachability to the DNS servers

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.

R3(config-rtr)# type echo protocol ipIcmpEcho 10.0.8.1

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.

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

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.

Step 6 Verify the dynamic operations and routing changes when the tracked objects fail

Shutdown the DNS address on R2

debug ip routing

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

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

We see that only one static default remains, via 192168.2.2 (R1).

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

R3# debug ip routing

We again examine the routing table and verify that both static default routes are there.

Full connectivity has been restored.

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

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.

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

Network Performance Monitoring: Using IP SLA Monitor with Orion NPM

http://www.youtube.com/watch?v=YKXoexOVsaE&feature=related

http://www.cisco.com/en/US/docs/ios/12_4/ip_sla/configuration/guide/hsla_c.html

http://www.cisco.com/en/US/technologies/tk648/tk362/tk920/technologies_white_paper09186a00802d5efe.html 85

Policy Based Routing (PBR)

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.

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

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

If {(x or y or z) and (a) match} then {set b and c}

If q matches then set r

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

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.

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.

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.

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).

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.

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.

RA(config)# interface ser 0/0/0

RA(config-if)# ip address 192.168.6.5 255.255.255.0

RA(config)# interface fa 0/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)# set ip default next-hop 172.16.7.7

RA(config-route-map)# set default interface null0

RA(config)# access-list 1 permit 10.1.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.

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

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.

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

RA(config-if)# ip policy route-map test

RA(config)# route-map test permit 10

RA(config-route-map)# set ip next-hop 172.17.1.2

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

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.

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

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-rtr)# timeout 5000

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

graziani@cabrillo.edu

CIS 185 CCNP ROUTE Ch. 5 Implementing Path Control

Documents

Transcript of CIS 185 CCNP ROUTE Ch. 5 Implementing Path Control

CCNP Study Aids© Ray Daugherty CCNP Study Aids: Vines that May Appear on the CCNP exam.

CCNP RS 7 - emprevet.com.veemprevet.com.ve/docs/CCNP.Overview.pdf · CCNP SWITCH: Implementing IP ... Networking Academy CCNP courses align with the three Cisco CCNP certification

ccnp switch

CCNP Study Aids© Ray Daugherty CCNP Study Aids: Shade Trees that May Appear on the CCNP exam.

Configuring OSPF – Part 2 of 2 CIS 185 CCNP ROUTE Rick Graziani Cabrillo College graziani@cabrillo.edu Last Updated: Fall 2010.

CCNP RS 7 - Uczelnia ITuczelnia.it/wp-content/uploads/2016/07/ccnp7present.pdf · NetAcad CCNP Course Cisco CCNP Certification Exam CCNP ROUTE: ... •1 chapter exam per chapter •1

CIS 185 CCNP ROUTE Ch. 4 Manipulating Routing Updates

Cisco CCNP: Troubleshooting Certification - …bpuniversity.com/pdf/cisco/6Cisco-CCNP-Troubleshooting... · Cisco CCNP: Troubleshooting Certification Se recomienda experiencia laboral

CIS 185 CCNP ROUTE Ch. 4 Manipulating Routing Updates Rick Graziani Cabrillo College graziani@cabrillo.edu Last Updated: Fall 2011.

Ccnp route

CCNP SWITCH Workbook - CCNP - ebook.konfigurasi.netebook.konfigurasi.net/Cisco/ccnp-switch-workbook.pdfCCNP SWITCH Workbook - CCNP - Basic Switching Review Lab 1.1 Preliminary Switch

€¦ · XLS file · Web view · 2017-04-24185 1. 185 1. 185 1. 185 2. 185 2. 185 2. 185 3. 185 4. 185 4. 185 4. 185 4. 185 4. 185 4. 185 5. 185 5. 185 5. 185 5. 185 5. 185 5. 185

CIS Cisco Firewall Benchmark - itsecure.hu · CIS Cisco Firewall Benchmark ... 1.11.2 Ensure 'snmp-server user' is set to 'v3 auth SHA' ... CCNP, ITIL, MBA (PM) 10 | P a g e Recommendations

CCNP Self-Study CCNP BCRAN Exam Certiﬁcation … Press - CCNP BCRAN...Cisco Press 800 East 96th Street, 3rd Floor Indianapolis, IN 46240 USA Cisco Press CCNP Self-Study CCNP BCRAN

CIS 185 Advanced Routing Course Introduction Rick Graziani Cabrillo College graziani@cabrillo.edu Fall 2011.

CCNP SWITCH Workbook - CCNP - Basic Switching Review Lab1).pdf · CCNP SWITCH Workbook - CCNP - Basic Switching Review Lab 1.1 Preliminary Switch Configuration Load the CCNP-Switch-Task1-1

CIS 185 CCNP ROUTE Ch. 8 Implementing IPv6 – Part 3

IP Multicasting CIS 185 Advanced Routing CCNP 1 Rick Graziani Fall 2008.

Syllabus CIS 293 Windows Server-Administering · Syllabus – CIS 293 – Windows Server-Administering Cuyamaca College: Spring 2017 Julio Garibay, DBA, MSTSM, BSCS, CCNP Section

CCNP Security | QOS Networking | CCNP Certification