top.tipText = new Array(); var isLayers = 0; var isAll = 0; var isID = 0; function init() { if (document.getElementById) { isID = 1; } else if (document.all) { isAll = 1; } else { isLayers = 1; } if (isLayers == 1) { var tipArray; } else { top.frames['tip_frame'].document.open(); top.frames['tip_frame'].document.write(""); top.frames['tip_frame'].document.close(); } } function findDOM(objectID,withStyle) { if (withStyle == 1) { if (isID) { return (document.getElementById(objectID).style); } else if (isAll) { return (document.all[objectID].style); } else { return (document.layers[objectID]); } } else { if (isID) { return (document.getElementById(objectID)); } else if (isAll) { return (document.all[objectID]); } else { return (document.layers[objectID]); } } } function getWidth() { if (window.innerWidth != null) { return window.innerWidth; } else if (document.body.clientWidth != null) { return document.body.clientWidth; } return (null); } function showTip(evt,framename,objectID) { dm = findDOM(objectID,0); ds = findDOM(objectID,1); setText(dm, framename); var width = getWidth(); if (dm.offsetWidth) { objWidth = dm.offsetWidth; } else if (dm.clip.width) { objWidth = dm.clip.width; } if (evt.y || evt.pageY) { if (evt.pageY) { topVisibility = evt.pageY + 20; leftVisibility = evt.pageX - (objWidth/4); } else { topVisibility = evt.y + 20 + document.body.scrollTop; leftVisibility = evt.x - (objWidth/4) + document.body.scrollLeft; } if (leftVisibility < 2) { leftVisibility = 2; } else if (leftVisibility + objWidth > width) { leftVisibility -= objWidth/2; } ds.left = leftVisibility; ds.top = topVisibility; } ds.visibility = "visible"; } function hideTip(objectID) { ds = findDOM(objectID,1); visibility = ds.visibility; ds.visibility = "hidden"; } function setText(dm,framename) { var tmpArray; var frameFound = false; for (var i=0; i=4) this.ns4 = (this.b=="ns" && this.v==4) this.ns5 = (this.b=="ns" && this.v==5) this.ie = (this.b=="ie" && this.v>=4) this.ie4 = (navigator.userAgent.indexOf('MSIE 4')>0) this.ie5 = (navigator.appVersion.indexOf('MSIE 5.0')>0) this.ie55 = (navigator.appVersion.indexOf('MSIE 5.5')>0) if (this.ie5) this.v = 5 this.min = (this.ns||this.ie) } // automatically create the "is" object is = new BrowserCheck() if (document.getElementById || document.all) { document.write(""); } else { document.write(""); } document.write(abs_rlo_pos) RIP document.write(abs_rio_pos); Zagadnienia związane z� konfigurowaniem protokołu RIP Na tej stronie znajdują się informacje o metodach redukcji pętli routingu. Routery RIP otrzymują niektóre typy informacji o� sieci od routerów sąsiednich. Takie działanie jest często określane terminem �śroutowanie przez plotkę" (ang. routing by rumor). Protokół RIP korzysta z� algorytmu routingu z wykorzystaniem wektora odległości. We wszystkich protokołach routingu działających z wykorzystaniem wektora odległości występują problemy spowodowane głównie wolną zbieżnością. Stan zbieżności polega na tym, że wszystkie routery w� sieci dysponują tymi samymi informacjami o� routingu. Jednym z� tych problemów są pętle routingu i� odliczanie do nieskończoności. Są one wynikiem niespójności będących rezultatem rozprzestrzeniania się w sieci komunikatów aktualizujących zawierających nieprawidłowe trasy. W celu redukcji pętli routingu i odliczania do nieskończoności w protokole RIP używane są następujące techniki: split horizon, poison reverse, liczniki przetrzymania, wyzwalane aktualizacje. Niektóre spośród tych metod wymagają konfigurowania. W protokole RIP maksymalna liczba przeskoków jest równa 15. Każdy cel, który jest odległy o� więcej niż 15 przeskoków, jest oznaczony jako niedostępny. Maksymalna liczba przeskoków znacznie ogranicza użycie protokołu RIP w� dużych intersieciach, ale zapobiega odliczaniu do nieskończoności i powstawaniu nieskończonych pętli routingu. Reguła split horizon opiera się na założeniu, że nie warto wysyłać wiadomości o� trasie w� kierunku, z� którego informacje te nadeszły. W przypadku niektórych konfiguracji sieci może być konieczne wyłączenie metody split horizon. GAD(config-if)#no ip split-horizon Innym mechanizmem, który może wymagać skonfigurowania, jest zegar przetrzymania. Zegary przetrzymania zapobiegają odliczaniu do nieskończoności, ale także zwiększają czas zbieżności. Domyślną wartością czasu przetrzymania dla protokołu RIP jest 180 sekund. Metoda ta zapobiega aktualizacji przy użyciu gorszych tras, ale może również uniemożliwić zainstalowanie trasy alternatywnej. Czas przetrzymania można skrócić w� celu przyspieszenia zbieżności, ale należy czynić to ostrożnie. W idealnym przypadku zegar powinien być nastawiony na wartość nieco dłuższą niż najdłuższy możliwy czas aktualizacji w� intersieci. W przykładzie na rysunku pętla składa się z� czterech routerów. Jeśli każdy router ma czas aktualizacji równy 30 sekund, najdłuższa pętla ma długość 120 sekund. Stąd też wartość zegara przetrzymania powinna wynosić nieco więcej niż 120 sekund. Wykonaj następujące polecenie w celu zmiany czasu przetrzymywania (holddown), jak również czasów uaktualniania (update), unieważniania (invalid) oraz usuwania (flush): Router(config-router)#timers basic� update invalid� holddown� flush� [sleeptime] Innym czynnikiem, który wpływa na czas zbieżności, jest interwał aktualizacji. Domyślną wartością interwału aktualizacji w� protokole RIP dla systemu Cisco IOS jest 30 sekund. Wartość tę można zwiększyć, aby zaoszczędzić pasmo, lub zmniejszyć, aby skrócić czas zbieżności. Innym problemem związanym z� protokołami routingu jest niepożądane ogłaszanie aktualizacji routingu przy użyciu konkretnego interfejsu. Po wydaniu polecenia network dla danej sieci protokół RIP rozpocznie natychmiast wysyłanie ogłoszeń z wszystkich interfejsów należących do określonego zakresu adresów sieci. Administrator sieci może użyć polecenia passive-interface, aby wyłączyć aktualizacje routingu dla określonych interfejsów. � Ponieważ RIP jest protokołem rozgłoszeniowym, może zaistnieć potrzeba takiej jego konfiguracji, aby informacje o� routingu mogły być wymieniane w� sieci, w� której rozgłaszanie nie jest stosowane, na przykład w� sieci Frame Relay. W przypadku sieci tego typu protokół RIP musi posiadać informacje o� sąsiednich routerach RIP. Aby ustawić te informacje, należy użyć polecenia neighbor pokazanego na rysunku . System Cisco IOS domyślnie odbiera pakiety protokołu RIP w wersji 1 i� wersji 2, ale wysyła tylko pakiety wersji 1. Administrator sieci może skonfigurować router tak, aby odbierał i� wysyłał tylko pakiety wersji 1 lub aby wysyłał tylko pakiety wersji 2. Aby skonfigurować router do wysyłania i� odbierania pakietów wyłącznie jednej wersji protokołu, należy użyć poleceń pokazanych na rysunku . Aby kontrolować sposób przetwarzania pakietów odbieranych przez interfejs, należy użyć poleceń pokazanych na rysunku . Następna strona zawiera opis weryfikacji konfiguracji protokołu RIP. Łącza WWW