SlarWinds Technical Reference New t Netwrking Vlume 2 The Basics f Cisc IP SLA Sectin 1 The Case fr Prxy Testing (IP SLA)... 1 Sectin 2 Hw IP SLA Wrks... 3 Sectin 3 The Respnder (Wasn t that a Steven Segal mvie?)... 5 Sectin 4 - What D IP SLA Operatins and Rabbits Have in Cmmn?... 6 Sectin 5 IP SLA Deplyment Strategies.. 8 Sectin 6 Review... 9 Related SlarWinds Prducts... 10 Abut SlarWinds... 12 Abut the Authr... 12 This paper examines Cisc s IP SLA technlgy with an emphasis n netwrk and device impacts as well as deplyment strategies. It is intended fr the user wh is new t IP SLA. netwrk management simplified - slarwinds.cm
Cpyright 1995-2009 SlarWinds. All rights reserved wrldwide. N part f this dcument may be reprduced by any means nr mdified, decmpiled, disassembled, published r distributed, in whle r in part, r translated t any electrnic medium r ther means withut the written cnsent f SlarWinds. All right, title and interest in and t the sftware and dcumentatin are and shall remain the exclusive prperty f SlarWinds and its licensrs. SlarWinds Orin, SlarWinds Cirrus, and SlarWinds Tlset are trademarks f SlarWinds and SlarWinds.net and the SlarWinds lg are registered trademarks f SlarWinds All ther trademarks cntained in this dcument and in the Sftware are the prperty f their respective wners. SOLARWINDS DISCLAIMS ALL WARRANTIES, CONDITIONS OR OTHER TERMS, EXPRESS OR IMPLIED, STATUTORY OR OTHERWISE, ON SOFTWARE AND DOCUMENTATION FURNISHED HEREUNDER INCLUDING WITHOUT LIMITATION THE WARRANTIES OF DESIGN, MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL SOLARWINDS, ITS SUPPLIERS OR ITS LICENSORS BE LIABLE FOR ANY DAMAGES, WHETHER ARISING IN TORT, CONTRACT OR ANY OTHER LEGAL THEORY EVEN IF SOLARWINDS HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. Micrsft and Windws 2000 are either registered trademarks r trademarks f Micrsft Crpratin in the United States and/r ther cuntries. Graph Layut Tlkit and Graph Editr Tlkit 1992-2001 Tm Sawyer Sftware, Oakland, Califrnia. All Rights Reserved. Prtins Cpyright CmpnentOne, LLC 1991-2002. All Rights Reserved. Dcument Revised: 09/03/2009
The Basics f Cisc IP SLA 1 Sectin 1 The Case fr Prxy Testing (IP SLA) Let s start ff by taking a lk at a typical netwrk management system (NMS) and hw it perates. An NMS perates as a center-f-the-universe fr netwrk management. It keeps an inventry f devices and regularly tests thse devices fr availability and perfrmance. The NMS als stres the results f these tests in a database and makes them available fr viewing and reprt creatin. These are the three cre functins f an NMS: Data cllectin Data strage Data presentatin There are a cuple f ways an NMS cllects infrmatin abut the netwrk, including: Perfrming tests directly; fr example, the NMS can ICMP Ech (ping) devices n the netwrk. Cllecting infrmatin frm a device by either: Actively requesting the infrmatin frm a device (plling) Examples are SNMP plling and WMI plling Passively listening fr data sent t the NMS (receiving) Examples are SNMP trap receptin and NetFlw data receptin Cnsider the fur-site netwrk depicted belw. Figure 1 A fur-site hybrid netwrk
2 The Basics f Cisc IP SLA The NMS is installed in Site 1 and it uses ping t mnitr the availability and delay f cmmunicatins t the remte sites. The netwrk pictured uses a simple ruting prtcl that will always chse the least number f hps t get frm ne site t anther. This means if the NMS sends ut a ping test t Site 4, the test will always take Link D if Link D is peratinal. Here is hw that test wuld ccur. 1. NMS (10.1.1.5) sends ut ping requests t 10.1.1.4. 2. The remte ruter receives the ping requests and sends a ping reply back t the NMS at 10.1.1.5. 3. The NMS receives the ping reply. This reply can cntain a lt f infrmatin, but fr ur purpses, we ll just fcus n tw pieces f data. Reachability - The successful ping reply frm the remte ruter. Perfrmance - The Rund Trip Time (RTT), r hw lng it tk the ping respnse t be received by the NMS after the NMS sent the riginal ping request. Assuming the ping test was successful, we nw knw that the remte ruter 10.1.1.4 is reachable frm the NMS and we als knw hw many millisecnds it takes t send packets rund trip between the NMS and the remte ruter. If we repeat this test t the ther ruters we have a gd measure f the availability and perfrmance f the netwrk frm the perspective f the NMS. This is why I referred t the NMS as a center-f-the-universe. At this pint, all the NMS knws is what the netwrk lks like frm where it is installed. Nw, let s say Link C becmes 95% saturated with data fr a prlnged perid f time. This saturatin will eventually result in slwer respnse times between Sites 3 and 4, and this culd be measured by ping tests between Sites 3 and 4. Nw here s the prblem: the NMS is at Site 1 and s can nly test frm Site 1. Assuming Link D is healthy, NMS ping tests wuld reprt delay t Site 4 as minimal. But, the users at Site 3 cnnecting t devices at Site 4 wuld be experiencing delay characterized in the belw graph. Disruptive Minimal 0% Traffic 100% Figure 2 Delay as a functin f traffic
The Basics f Cisc IP SLA 3 The traffic wuld prbably flw faster by ruting thrugh Link E and then link D but ur ruting prtcl decides the best rute by least number f hps nly. What we need is t measure the respnse between site 3 and site 4, and we need t find a way t get that infrmatin back t the NMS. This is what is knwn as prxy testing. IP SLA is a Cisc technlgy built int mst Cisc devices fr prxy testing. In the next sectin we ll lk int the gears f IP SLA a bit. Sectin 2 Hw IP SLA Wrks Cisc engineers recgnized the need fr prxy testing early n and released a feature called Respnse Time Reprter r RTR. This name sld the functinality shrt, as yu ll see later, and the letters RTR were already well used in the industry as shrt hand fr ruter. D h!! Cisc later named the functin Service Assurance Agent (SAA). This name was shrt-lived, and in 2004 Cisc renamed it again t IP SLA, r Internet Prtcl Service Level Agreement, a much mre descriptive name. Here we ll examine the mechanisms behind IP SLA. First, let s get the nmenclature ut f the way. In IP SLA a Surce is a device that creates and inserts IP SLA packets int the netwrk. The Target is the ultimate destinatin f the packets. An Operatin is the type f test being perfrmed. Lking at Figure 1 again, the NMS can directly measure availability and ping respnse time t all three remte sites but has nt direct methd fr testing the quality f the links thrughut the netwrk. Cnsider again the case where link C becmes heavily cngested. The NMS can detect this high traffic level using SNMP plling f the interfaces at site 3 and site 4, but wuld be unable t determine if the cngestin was causing perfrmance impacts frm site 3 t site 4. T d this, we need smething at site 3 (r 4)t test the perfrmance between the sites. We ll place an IP SLA peratin n the Site 3 ruter targeting the site 4 ruter. Here s a cnfig fr the site 3 ruter (12.4(T) IOS), which will make the site 3 ruter the surce, the site 4 ruter the target, and will implement the ICMP ech (ping) peratin. Ruter3 (cnfig)# ip sla mnitr 1 Ruter3 (cnfig-ip-sla-mnitr)# type ech prtcl ipicmpech 10.1.1.4 Ruter3 (cnfig-ip-sla-mnitr)# frequency 300 Ruter3 (cnfig-ip-sla-mnitr)# exit Ruter3 (cnfig)# ip sla mnitr schedule 10 life frever start-time nw S here s what we just did: 1. Entered cnfig ip sla mnitr cnfig mde and assigned a number t the peratin. (Each peratin n a device needs a unique number, s I assigned this ne as peratin 1.) 2. Assigned the ICMP ech test type and target f 10.1.1.4. 3. Set the test frequency t 300 secnds. 4. Returned t base cnfig mde. 5. Specified the peratin schedule(never g away and start right away).
4 The Basics f Cisc IP SLA With this cnfiguratin in place, the ruter at site 3 will test ping perfrmance t site 4 every 300 secnds. We can examine the results f the peratin using the shw ip sla mnitr statistics cmmand directly ff f the site 3 ruter in CLI. This will shw us the last ping test result as seen belw: Figure 3 Screen utput f IP SLA ping test I have cnfigured this peratin between tw Cisc ruters but fr an ICMP ech peratin yu can use anything that will respnd t a ping as the target. Sme peratins are Cisc target specific and sme are nt. Fr a detailed explanatin f each peratin see http://www.cisc.cm/en/us/dcs/is/12_4/ip_sla/cnfiguratin/guide/hsla_c.html Nw we have the test running, but hw d we get the infrmatin t the NMS? IP SLA capable devices stre the results f the IP SLA peratins in a Management Infrmatin Base (MIB) n the surce device, the RTTMON MIB. The NMS uses SNMP plling t retrieve the test results frm the RTTMON in the device and stre them in the NMS database. Nw we can use the NMS t view reprts abut the delay frm the NMS t each remte site, using the NMS sent pings and the delay between site 3 and 4 (and the ther sites) using the results f the IP SLA ICMP peratin. Here is what we might see: Site Availability and Delay (Frm NMS sent pings) Site Availability Delay Site 2 100% 21ms Site 3 100% 19 ms Site 4 100% 22 ms IP SLA Results Surce Destinatin Operatin RTT User Status Site 1 Site 2 Ping 21ms Happy Site 1 Site 3 Ping 21ms Happy Site 1 Site 4 Ping 25ms Happy Site 3 Site 2 Ping 26ms Happy Site 3 Site 4 Ping 910ms Red-faced
The Basics f Cisc IP SLA 5 Here we have a much mre accurate picture f the netwrk than if we had relied n NMS pings nly. The saturated link (C) has a delay f almst a full secnd! As yu can see, this is well ver the level required t cause red-faced users. Many applicatins will either becme unreasnably slw r just plain fail. And real-time applicatins, like VIP, will be dead in the water. This is a rather simple example f IP SLA testing. There are a lt mre peratin types t lk at, and sme math t discuss alng the way. But first there is ne mre piece f IP SLA t discuss. Sectin 3 The Respnder (Wasn t that a Steven Segal mvie?) Ping tests are very simple and lw-level. On many systems the jb f replying t pings is left t the netwrk interface card r the frwarding plane f a ruter. The target s peratin system desn t have t be invlved in prcessing each ping request. This means that the prcessing time at the target is minimal and the ping RTT is a fairly gd measure f the time-in-flight f the ping request and respnse. If we were t cnfigure the UDP Ech peratin, we are asking the target device t pen a particular UDP prt. This actin invlves mre sphisticated prcessing than ping and requires cntrl plane and OS interactin. The prcessing time n the target device may be significant and if we are trying t measure nly netwrk delay it will skew the results. The IP SLA Respnder was made t remve the target prcessing time frm the final test value. Figure 6 belw depicts this interactin. Figure 6 IP SLA Prcessing The time t send the UDP ech, prcess the request at the target and return the result is T 1 +T 2 + T 3. If we apply the IP SLA respnder t r2, the UDP Ech IP SLA peratin results at r1 fr will be T 1 + T 3, subtracting ut the prcessing time n r2. IP SLA respnders can nly be implemented n Cisc devices. Sme peratins will nt use a respnder, sme require it and fr thers it is ptinal. Fr mre infrmatin n the respnder see http://www.cisc.cm/en/us/technlgies/tk648/tk362/tk920/technlgies_white_paper09186a00802d5ef e.html
6 The Basics f Cisc IP SLA Sectin 4 - What D IP SLA Operatins and Rabbits Have in Cmmn? It has t d with numbers. Yu knw hw rabbits can get ut f hand well, s can IP SLA peratins. The trick is t deply peratins with sme planning. Befre we get int the planning strategies we ll take a lk at hw the numbers fr IP SLA peratins wrk. Cnsider the belw netwrk tplgies. Figure 3 Hub and spke netwrk Figure 4 Hybrid netwrk Figure 5 Full mesh netwrk
The Basics f Cisc IP SLA 7 Each f these tplgies has a different number f cnnectins between sites. The hub-and-spke and full mesh netwrks are predictable in the fllwing ways: in a hub and spke, the main site (hub) is directly cnnected t each remte site (spke).this is typical f a retail netwrk where each pint-f-sale stre is a spke, and the crprate headquarters is the hub. In the mesh netwrk, each site is directly cnnected t all ther sites. This is typical f a high-perfrmance netwrk using VIP and vide between sites. Hybrid netwrks can be arranged in any fashin that best fits the needs f the netwrk services, and s there is n predictable pattern fr the number f cnnectins required. Here is hw yu can calculate the number f links in hub-and-spke and full mesh netwrks where L = number f links and N = number f sites. Hub and spke: L = N -1 Full mesh: L= N(N-1)/2 S fr the five site hub and spke abve we have L=5-1=4 Fr the full mesh we have L = 5(5-1)/2 = 5*4/2=10 If we add ne mre site t the hub and spke we have 5 ttal links. If we add ne mre site t the full mesh we have 15 ttal links. If we were t then add ne mre site t the mesh we have 21 links! Full mesh is the rabbit f netwrk tplgies. It is als the fastest grwing f the WAN tplgies due mstly t the ability t virtualize the cnnectins at each site (s yu dn t need a physical WAN cnnectin t each site), and the ppularity f MPLS. When we apply an IP SLA test like the ping test we lked at earlier, we are testing the active path between tw sites. S t test all the paths in ur 7 site full mesh we need t cnfigure 21 peratins amng the 7 ruters. Because the ping test tests the path rund trip time, we can assume that site A t site B rund trip delay is equal t site B t site A rund-trip delay. This is where the /2 part f the full mesh equatin cmes frm. We culd deply these peratins in a reasnable amunt f time and the peratins wuld have a minimal impact n the devices and the netwrk. But IP SLA ffers several peratin types. Here is a list f sme cmmn peratins yu culd apply: ICMP ech (ping) UDP ech UDP Jitter TCP cnnect VIP UDP Jitter DHCP HTTP DNS FTP What if we deplyed ping, UDP jitter, TCP cnnect, and UDP ech in each path f a seven site full mesh? We already knw that fr ping we wuld need 21 peratins. Fr these fur peratin types t be tested thrughut the mesh, we need t cnfigure 21*4, r 84 peratins. Nw let s take a lk at a typical midsized netwrk with 30 sites. Here is the arithmetic: L=30*29/2 = 435 Ttal peratins = 435*4 = 1740
8 The Basics f Cisc IP SLA As yu can see the numbers get rabbit-like very quickly. Hw abut a large netwrk with 180 sites? L=180*179/2 = 16,110 Ttal peratins = 16,110*4 = 64,400! Obviusly we need t step back frm the muse at sme pint and think abut what we are measuring and why. By cntinuing t add peratins, especially in a full mesh netwrk, yu culd kill the netwrk perfrmance in the name f testing perfrmance. This is where IP SLA strategies cme int play. Sectin 5 IP SLA Deplyment Strategies Besides the pssibility f burdening the netwrk with test packets as we saw abve, there are a few ther things t cnsider abut a large number f tests: Data strage requirements: several thusand test results stred every five minutes can create a large database affecting ther services n the NMS database. Viewing the results: chances are mst f the histrical results will never be examined. Plling engine: adding thusands f tests culd add a significant burden t the SNMP pller. S IP SLA can be dangerus when imprperly implemented. Here are strategies t avid these issues. 1. Keep lcal tests lcal. (Test lcally, reprt glbally!) Nt all test types are used t test WAN services. Take DHCP fr example. A large netwrk may have several distributed DHCP servers. If each site has a lcal DHCP server, users at that site wuld receive IP addresses frm the lcal server if it is available. Fr 40 sites yu culd accmplish DHCP testing by deplying an peratin frm the each site s lcal switch r ruter t the site s lcal DHCH server. 40 tests, 40 results t pll and stre. Yu might als add tests fr sme secndary DHCP servers and have 50 r s ttal tests. If yu added all DHCP testing t all sites t all servers yu wuld have apprximately 40 2 (1600) tests. Mst f these tests are fr DHCP requests t remte sites which will never actually be what the users request when btaining an IP address. 2. Test paths nly fr traffic they are expected t supprt. Let s take the case f UDP jitter, a cmmn IP SLA test. On an MPLS, 40-site netwrk, we ll implement the UDP jitter peratin between the 5 sites that use UDP t deliver vide cnferencing. Since vide cnferencing is sensitive t netwrk jitter and delay, it makes sense t implement jitter peratins between these sites. Using the frmula fr a full mesh netwrk (MPLS is always full mesh), we need t setup 10 peratins. What if we just hit the Full Mesh buttn and deplyed the tests between all sites. We wuld have 40*39/2=780 tests and nly 1.3% f the tests wuld be fr valid vide paths! Here we can see that a custm deplyment f the peratins is the wise thing t d. 3. Cnsider decreasing the test frequency when pssible. The math n this is very straightfrward. Decreasing the test frequency frm 300 secnds t 360 secnds will lessen the test impact n the surce device and netwrk ten percent. Increasing the frequency t 150 secnds will increase the lad ne hundred percent.
The Basics f Cisc IP SLA 9 4. Avid verlapping tests. We culd deply a DNS test t an internal DNS server, an HTTP test t an intranet page, a ping test t the HTTP server, and a TCP cnnect t the HTTP server frm a lcal switch. While we have fur individual tests testing fur services, we actually have three arguably redundant tests. The HTTP peratin des the fllwing: 1. Reslves the URL t an IP address using the DNS server. 2. Makes a TCP prt 80 request t the HTTP server. 3. Requests the HTTP and detects a successful page lad. 4. Recrds the DNS reslve time, TCP pen time and page lad time. S with the HTTP test we can eliminate the ther three tests and still get the same results. Sectin 6 Review Frm tp t bttm, here is an verview f the imprtant cncepts frm the previus sectins. If yu have skipped the rest and started here, shame n yu! IP SLA is a feature built int Cisc IOS IP SLA tests (Operatins) are initiated frm Cisc devices (Surce) t measure the service quality f the path t anther device (Target). Targets may be Cisc device r ther types f devices. The target type may depend n the peratin. Fr example, HTTP peratins must be target at an HTTP server, Jitter peratins must be targeted at a Cisc device, ping can target anything that will respnd t ping. IP SLA respnders (an IOS cmmand) can be deplyed t eliminate target prcessing time frm a peratin result. Applying peratins t a netwrk (especially a full-mesh WAN) must be dne with cautin! The number f peratins created n an entire full-mesh is apprximately ne-half f the number f sites squared r N(N-1)/2. Applying peratin nly where required is wise. Other measures that can be taken t minimize impact n the netwrk include Applying tests fr lcal resurces, like DHCP, nly n lcal ruters/switches Decreasing test frequency Avid deplying test with verlapping results Fr example, HTTP and DNS tests. I hpe this has been helpful and that yu will sn be taking advantage f IP SLA in yur netwrk!
10 The Basics f Cisc IP SLA Related SlarWinds Prducts SlarWinds Slutins fr IP SLA Mnitring Nw that yu ve gt a slid understanding f Cisc IP SLA technlgy, we wanted t intrduce a cuple great slutins t help yu begin using IP SLA n yur netwrk. Hey, yu didn t think we d miss ut n the pprtunity t shw ff ur cl IP SLA tls, did yu? Take a peek at these ppular tls: Orin IP SLA Manager Orin IP SLA Manager evlved frm ur previus Orin VIP Mnitr t deliver a pwerful slutin fr identifying site-specific and WAN-related netwrk perfrmance issues. This mdule identifies which devices n yur netwrk supprt IP SLA peratins and autmatically sets up peratins, eliminating any guesswrk. Finally, yu can mnitr key WAN applicatins by analyzing the perfrmance f the underlying netwrk prtcls, including DNS lkups, FTP, HTTP, TCP cnnect, and UDP jitter. Of curse, yu can als cntinue t mnitr VIP call paths t ensure quality f service fr yur vice traffic. Orin IP SLA Manager Highlights: Mnitr WAN netwrk perfrmance using IP SLA technlgy that s already built int yur existing Cisc ruters Visualize site-t-site netwrk perfrmance n a clickable, drill-dwn map Discver and autmatically setup Cisc IP SLA-capable netwrk devices with specific IP SLA peratins Quickly review WAN perfrmance t determine the impact n key applicatins View at-a-glance WAN perfrmance with the Tp 10 IP SLA dashbard Mnitr VIP perfrmance statistics, including MOS, jitter, netwrk latency, and packet lss Fr mre infrmatin abut Orin IP SLA Manager, please visit: http://www.slarwinds.cm/prducts/rin/ip_sla_mnitring/
The Basics f Cisc IP SLA 11 SlarWinds IP SLA Mnitr Free Tl Analyze perfrmance between a Cisc IP SLA-enabled device and ther remte devices Mnitr cmmn IP SLA peratins, including UDP ech, ICMP path ech (ping), TCP cnnect time, DNS reslutin, and HTTP respnse Create and exprt a Universal Device Pller (UnDP) t mnitr path-specific IP SLA perfrmance in Orin Netwrk Perfrmance Mnitr Verify and mnitr quality f service (QS) View IP SLA peratin details, including frequency, surce and target, peratin type, and Type f Service (TS) settings Prevent perfrmance degradatin by watching threshld-specific indicatrs t visually alert yu when a perfrmance prblem ccurs Fr mre infrmatin abut IP SLA Mnitr, please visit: http://www.slarwinds.cm/prducts/freetls/ip_sla_mnitr/
12 The Basics f Cisc IP SLA Abut SlarWinds SlarWinds is rewriting the rules fr hw cmpanies manage their netwrks. Guided by a glbal cmmunity f netwrk engineers, SlarWinds develps simple and pwerful sftware fr managing netwrks, small r large. Our cmpany culture is defined by passin fr innvatin and a philsphy that netwrk management can be simplified fr every envirnment. SlarWinds prducts are used by mre than ne millin netwrk engineers t manage IT envirnments ranging frm ten t tens f thusands f netwrk devices. Cmprised f fault and perfrmance management prducts, cnfiguratin and cmpliance prducts, and tls fr engineers, the SlarWinds prduct family is trusted by rganizatins arund the glbe t design, build, maintain, and trublesht cmplex netwrk envirnments. SlarWinds is headquartered in Austin, Texas, with sales and prduct develpment ffices arund the wrld. Jin ur nline cmmunity f experts at thwack.cm! Abut the Authr Andy McBride is a Technical Specialist fr SlarWinds fcusing n making knwledge f netwrking and netwrk management accessible t custmers and prspects f all levels. The New t Netwrking series is specifically written fr an audience with limited prir expsure t these technlgies. Andy s technical backgrund includes seven years at Internatinal Netwrk Services (INS) as a Netwrk Engineer and Managing Cnsultant, three years as a Nvell Certified Instructr and five years as a Netwrk Perfrmance Prducts Manager with BT-Infnet. Prir t entering technlgy, Andy wrked in aerspace n prjects such as the SR-71, F-117, F-22, L-1011, F-18 and the space shuttle main engine. Andy has a degree in Chemistry but was wise enugh t never wrk in that field.