Loop-Free Alternative (LFA)

Transkript

1 Loop-Free Alternative (LFA) Vojtěch Oczka OCZ0004 Abstrakt: Cílem této práce je nejdříve ověřit podporu Technologie Loop-Free Alternative ve virtualizačním prostředí IOS-XR. Následně provést implementaci této technologie, změřit dobu přepnutí a poté porovnat získané výsledky. Klíčová slova: Loop-Free Alternative, LFA, OSPF, Cisco, IOS-XR, Virtualizační prostředí leden /19

2 1 Úvod Loop-Free Alternative (LFA) Popis Výhody Nevýhody Emulátor systému IOS-XR Obecně Zapojení v laboratořích Topologie virtuálního zapojení směrovačů Použita topologie zapojení Konfigurace prvků Měření a porovnání výsledků Pomocí pingu Pomocí debugu Porovnání výsledků Výpisy debugů OSPF Klasika OSPF s Loop-Free Alternative Závěr Použité zdroje Zdroje Obrázky Přílohy Konfigurace prvků Kompletní výpisy debugů...18 leden /19

3 1 Úvod V rámci projektu jsem měl za úkol vyzkoušet technologii Loop-Free Alternative na emulátoru IOS XR. Tento emulátor běžel celkem na 4 počítačích, kde na každém byli 4 směrovače s IOS XR. Pro ověření této technologie jsem si vystačil s jedním počítačem a třemi směrovači. Úkolem bylo nejdříve ověřit podporu na emulátoru. Toto jsem vyřešil prakticky vyzkoušením povolení této technologie na jednom ze směrovačů. Následně jsem implementoval tuto technologii, změřil dobu přepnutí pomocí pingu a debugu a porovnával výsledky. leden /19

4 2 Loop-Free Alternative (LFA) 2.1 Popis LFA je zdánlivě jednoduchá, ale účinně rychle směrující konvergenční technologie nazývaná Loop-Free Alternative (LFA) vytvořená firmou Cisco. Jinými slovy lze říci že se jedná o technologii, která nabízí vytvoření náhradní trasy rychleji, než běžné směrující technologie. LFA automaticky poskytuje kompletní konvergenční negarantovaný čas přepnutí na náhradní cestu 50 milisekund. Tento čas přepnutí nenabízí žádná jiná vylaďovací technologie, která byla dosud vyvinuta. Dokonce v některých literaturách se zmiňují o času přepnutí na záložní trasu kolem 25 milisekund. Běžné distribuované směrovací algoritmy pracují na principu jakmile se něco stane, tak začni reagovat. Princip spočívá v tom, že jakmile se daný směrovač dozví, že spojení nebo router selhal, tak teprve začnou vypočítávat záložní trasu. Potřebná doba pro výpočet se nazývá směrovací přechod. Dokud ještě výpočet není hotov, tak daná cesta k cíli není dostupná. Z čehož plyne že dochází ke krátkému výpadku, který není žádaný a který bychom chtěli mít co nejkratší, nebo v ideálním případě žádný. Proto vznikla technologie Loop-Free Alternative, která tuto dobu snižuje na co nejkratší čas, jak již bylo řečeno výše, tak tento na negarantovaný čas přepnutí je 50 milisekund. Ve zkratce řečeno, tento protokol funguje tak, že dopředu vypočítavá náhradní cestu pro případ selhání. Jestliže se pak směrovač dozví o selhání dané trasy, tak jenom jednoduše přepne na záložní trasu. Díky tomuto postupu, se dosahuje doby po - třebné pro přepnutí mnohonásobně nižší. LFA pracuje s Link-state routovacími protokoly jako je OSPF a IS-IS. Může být nastaven na jednom routeru a pracuje na základě vypočítávání náhradní záložní cesty dané smyčky pro každý prefix. Tuto záložní cestu dané smyčky pak přidá do Základní routovací tabulky (RIB). Tato tabulka poskytuje místní obnovu cesty v případě poruchy primární cesty. Prefix je nezávislý z důvodu deterministické doby konvergence a neměnících se závislostí na parametrech mezi které patři velikost směrovací tabulky nebo odkaz na stav databáze. Obrázek níže znázorňuje ukázkovou topologii s použitím technologie LFA na malé síti. LFA je nakonfigurovaná na směrovači A, který má v základní routovací tabulce RIB předkonfigurovanou náhradní cestu přes router C. Mezi primární cestou routerů A a B nastala nějaká chyba, kterou router A mohl zjistit pomocí technologie ztráty spojení nebo Detekce přímého směrování BFD. Proto router A mohl rychle obnovit datový tok přes router C získaný z tabulky RIB. Obrázek 1 Ve shrnutí je LFA jednoduše konfigurovatelná na routeru pomocí jednoho příkazu. Vypočítavá všechno automaticky a doplňuje další rychlé routovací konvergenční techniky. Pracuje z 70-85% pomocí prefixu a nic nerozbíjí. Jediná menší nevýhoda této technologie je, že delší routovací tabulky mohou způsobit větší spotřebu paměti. Dále mohou přidat zvýšení vytíženosti procesoru, které ale bude minimální z důvodu výpočtu záložní trasy po primárních trasách. leden /19

5 2.2 Výhody Rychlejší reakce na chybu v síti a následný výběr nové cesty. Většinou do 50ms. IS-IS implementace je poměrně primitivní Implementace OSPF umožňuje zadat řadu alternativních kritérií pro výběr cesty. Například, můžete dát přednost alternativní cesty, které jdou přes stejné rozhraní LAN, nebo prostřednictvím next-hop směrovače. 2.3 Nevýhody Použití v OSPF nebo IS-IS Pouze 3 vrstva VPN je podporována IPv4 multicast není podporovaný IPv6 není podporovaná Pouze rozhraní fyzické a fyzický port kanálů jsou chráněny. Pod rozhraní, tunely, a virtuální rozhraní, nejsou chráněny. IS-IS nebude počítat LFA pro předpony, jejichž hlavním rozhraní je tunel. leden /19

6 3 Emulátor systému IOS-XR 3.1 Obecně IOS-XR je operační systém, který lze emulovat na počítači s dostatečným výkonem a pamětí RAM. Každé nastavení v konfiguraci se musí commitnout pro provedení změn. V laboratořích byl emulátor na 4 počítačích, kde na každém běželi 4 směrovače. Tyto 4 směrovače byly propojeny každý s každým (Fullmesh). Každý virtuální směrovač měl vyveden jeden interface přes VLAN. Pro ověření této technologie jsem využil jeden pc a tři směrovače. 3.2 Topologie virtuálního zapojení směrovačů Obrázek 2 leden /19

7 4 Použita topologie zapojení Pro ověření technologie jsem použil následující topologii. leden /19

8 5 Konfigurace prvků Každý virtuální směrovač měl nastavený svůj hostname, ip adresy na jednotlivých interface a OSPF area 1. Na směrovači Right běžel ntp server pro synchronizaci času a na ostatních byl nastaven ntp client. Na router-switchi RS1 byl nastaven trunk a jednotlivé vlany pro dané porty. 5.1 Postup konfigurace Nejdříve jsem začal konfiguraci pojmenováním jednotlivých prvků pomocí hostname. Následně jsem pokračoval přiřazením IP adresy a masky pro jednotlivé rozhraní na všech prvcích. Poté jsem nastavil na každý router OSPF s area 1. Další konfigurací nasledovalo přidání NTP serveru na jeden router jako master a na ostatní jako klient. Díky tomuto nastavení jsem mohl získávat přesný čas při testování neboli měření. Jako poslední krok bylo povolení technologie Fast-Reroute Loop free alternate na daných rozhraní, pro která se měla vytvořit záložní cesta. 5.2 Základní nastavení Všechny nastavení jsou v konfiguračním rozhraní. Vykřičník znamená návrat o jedno rozhraní zpět. Červeným rámečkem je ohraničený příkaz pro povolení záložní trasy pomocí technologie Fast-Reroute Loop free alternate. hostname left interface GigabitEthernet0/0/0/0 ipv4 address router ospf 1 area 1 interface GigabitEthernet0/0/0/0 ntp fast-reroute per-link server Nastavení označení prvku Ukázka nastavení ip adresy a masky pro 1 interface Ukázka nastavení ospf pro 1 interface. Příkaz povolení technologie Fast-Reroute Loop free alternate je ohraničen červeným rámečkem. Povolení ntp na daném prvku. Zde lze vidět nastavení klienta. Rozdíl mezi ntp serverem je pouze místo server zadat master a číslo priority. 5.3 Nastavení pro povolení debugu Pro povolení výpisu debugu do konzole je potřeba zadat příkaz logging console debugging v konfiguračním rozhraní. Poté se již začnou zobrazovat debug zprávy. Z debugu jsem ještě využil příkaz debug cef ipv4 events při testování pomocí pingu. Tento příkaz se zadává v privilegovaném režimu. 5.4 Nastavení access listu Access list byl nastaven při testovaní debugu pro ping, aby se zobrazovali pouze pakety přicházející do sítě Nastavení access listu lze vidět níže. ipv4 access-list 1 10 permit ipv any leden /19

9 6 Měření a porovnání výsledků Měření doby přepnutí jsem prováděl dvěma způsoby a to pomocí pingu a debugových zpráv. Měření jsem provedl nejdříve na klasickém OSPF a pak jsem přidal technologii Loop-Free Alternative. 6.1 Pomocí pingu Toto měření jsem provedl pouze na klasickém OSPF bez zaplé technologie Loop-Free Alternative. Toto měření jsem již neopakoval s technologií Loop-Free Alternative protože nebylo příliš přesné. Měření pomocí pingu má hlavní nevýhodu a to tu, že na routeru jsem nebyl schopen rozeznat o který ICMP paket se jedná a proto jsem nemohl zjistit přesný čas. Podařilo se mi ale zjistit, že během přepnutí na novou cestu se ztratí 1 ICMP paket nebo žádný. Záleželo jak se daný ICMP paket trefil do intervalu. 6.2 Pomocí debugu Toto měření probíhalo takovým způsobem, že si na routeru right nastavil ACL list pro pakety přicházející pouze do sítě Následně jsem si na routeru nastavil debug pro všechny pakety. Ze sítě jsem posílal ping do sítě Na routeru Left jsem shodil rozhraní G 0/0/0/0. Následně jsem na routeru Right snažil něco vyčíst, ale to se mi moc nepovedlo. Pro měření jsem nakonec využil jiné možnosti a to OSPF zprávy, které jsou automaticky posílány při změně rozhraní. Z těchto zpráv jsem vyčetl následující údaje a vypsal jsem je přehledně do tabulky níže. OSPF Čas [ms] Shození rozhraní 33 * Znovu nahození rozhraní 5 * OSPF s Loop-Free Alternative 6.3 Porovnání výsledků Jak lze vidět z tabulky výše, tak doba pro klasické OSPF mi vyšla při shození rozhraní 33s a nahození 5s. Tyto údaje jsou podle mě nesmyslné, protože kdyby platili, tak by tento výsledek byl zřejmý a šel by vidět na pingu, kde by vypadlo více paketu, což se ale nestalo. Při tomto měření jsem musel udělat někde chybu. U měření OSPF s Loop-Free Alternative mi vyšli údaje při shození rozhraní 160ms a nahození 130s jak lze vidět v tabulce. Tento čas je podle mě delší než 50ms a to proto, že tento čas přepnutí není garantovaný a také protože se jednalo o virtualizační prostředí. leden /19

10 7 Výpisy debugů 7.1 OSPF Klasika Shození interface Left router shutdown RP/0/0/CPU0:left(config-if)#commit Mon Jan 12 13:05: UTC Right router RP/0/0/CPU0:Jan 12 13:05: : ospf[1014]: %ROUTING-OSPF-5-ADJCHG : Process 1, Nbr... Nahození interface Left router no shutdown commit... RP/0/0/CPU0:left(config-if)#RP/0/0/CPU0:Jan 12 13:01: : ifmgr[226]: %PKT_INFRA- LINK-3-UPDOWN : Interface GigabitEthernet0/0/0/0, changed state to Up Right router RP/0/0/CPU0:right#debug ospf 1 monitor RP/0/0/CPU0:Jan 12 13:01: : ospf[1014]: %ROUTING-OSPF-5-ADJCHG : Process 1, Nbr on GigabitEthernet0/0/0/1 in area 1 from LOADING to FULL, Loading Done, vrf default vrfid 0x OSPF s Loop-Free Alternative Shození interface Left router shutdown RP/0/0/CPU0:left(config-if)#commit Mon Jan 12 13:19: UTC Right router RP/0/0/CPU0:right#RP/0/0/CPU0:Jan 12 13:19: : ospf[1014]: sched dijkstra: Schedule SPF in area 1 Change in LS ID , LSA type R,... Nahození interface Left router interface gigabitethernet 0/0/0/0 RP/0/0/CPU0:left(config-if)#no shutdown RP/0/0/CPU0:left(config-if)#commit Mon Jan 12 13:21: UTC RP/0/0/CPU0:Jan 12 13:21: : ifmgr[226]: %PKT_INFRA-LINK-3-UPDOWN : Interface GigabitEthernet0/0/0/0, changed state to Down... Right router RP/0/0/CPU0:right#RP/0/0/CPU0:Jan 12 13:21: : ospf[1014]: sched dijkstra: Schedule SPF in area 1 Change in LS ID , LSA type R,... leden /19

11 8 Závěr Loop-Free Alternative je zajímavá technologie, která se určitě vyplatí implementovat všude tam, kde lze. To proto, že snižuje čas výpočtu alternativní cesty při výpadku a jenom přepne na záložní spojení, které má již připraveno. Toto přepnutí je téměř okamžité. Ikdyž se mi nepodařilo času 50ms dosáhnout, tak myslím, že 160ms taky není špatný výsledek. Díky tomuto projektu jsem si vyzkoušel technologii Loop-Free Alternative a práci s debugem na směrovačích. Dále jsem si zkusil práci na virtualizovaných routerech s IOS-XR. Při měření na klasickém OSPF jsem nejspíše udělal chybu a to tu, že jsem změřil něco jiného. Načeš tyto výsledky nelze brát vážně. Díky tomu, že OSPF s technologií Loop-Free Alternative běžela jako virtualizovaná služba a čas přepnutí není garantovaný, tak doba změřeného času není špatná. leden /19

12 9 Použité zdroje 9.1 Zdroje [1] IPv4 Loop-Free Alternate Fast Reroute. [online]. [cit ]. Dostupné z: [2] Základní informace k použití na učebně. [online]. [cit ]. Dostupné z: %C3%AD_na_EB429 [3] loop-free-alternate-routes. [online]. [cit ]. Dostupné z: Obrázky Obrázek 1. [fotografie]. Cisco [online]. [cit ]. Dostupné z: Obrázek 2. [fotografie]. VSB [online]. [cit ]. Dostupné z: leden /19

13 10 Přílohy 10.1 Konfigurace prvků Left Mon Jan 12 13:30: UTC Building configuration... IOS XR Configuration Last configuration change at Mon Jan 12 13:21: by cisco hostname left ntp interface MgmtEth0/0/CPU0/0 interface GigabitEthernet0/0/0/0 interface GigabitEthernet0/0/0/1 interface GigabitEthernet0/0/0/2 interface GigabitEthernet0/0/0/3 interface GigabitEthernet0/0/0/4 interface GigabitEthernet0/0/0/5 interface GigabitEthernet0/0/0/6 server interface GigabitEthernet0/0/0/0 ipv4 address interface GigabitEthernet0/0/0/2 ipv4 address interface GigabitEthernet0/0/0/3 ipv4 address router ospf 1 area 1 interface GigabitEthernet0/0/0/0 fast-reroute per-link interface GigabitEthernet0/0/0/2 interface GigabitEthernet0/0/0/3 end leden /19

14 Right Mon Jan 12 13:31: UTC Building configuration... IOS XR Configuration Last configuration change at Mon Jan 12 13:14: by cisco hostname right logging console debugging ntp interface MgmtEth0/0/CPU0/0 interface GigabitEthernet0/0/0/0 interface GigabitEthernet0/0/0/1 interface GigabitEthernet0/0/0/2 interface GigabitEthernet0/0/0/3 interface GigabitEthernet0/0/0/4 interface GigabitEthernet0/0/0/5 interface GigabitEthernet0/0/0/6 master 9 ipv4 access-list 1 10 permit ipv any interface GigabitEthernet0/0/0/0 ipv4 address interface GigabitEthernet0/0/0/1 ipv4 address interface GigabitEthernet0/0/0/3 ipv4 address router ospf 1 area 1 interface GigabitEthernet0/0/0/0 fast-reroute disable interface GigabitEthernet0/0/0/1 fast-reroute per-link interface GigabitEthernet0/0/0/3 end leden /19

15 Cent Mon Jan 12 13:33: UTC Building configuration... IOS XR Configuration Last configuration change at Mon Jan 12 11:49: by cisco hostname centr ntp interface Loopback0 interface MgmtEth0/0/CPU0/0 interface GigabitEthernet0/0/0/0 interface GigabitEthernet0/0/0/1 interface GigabitEthernet0/0/0/2 interface GigabitEthernet0/0/0/3 interface GigabitEthernet0/0/0/4 interface GigabitEthernet0/0/0/5 interface GigabitEthernet0/0/0/6 server interface GigabitEthernet0/0/0/1 ipv4 address interface GigabitEthernet0/0/0/2 ipv4 address router ospf 1 router-id area 1 interface GigabitEthernet0/0/0/1 interface GigabitEthernet0/0/0/2 end leden /19

16 RS1 Current configuration : 1616 bytes Last configuration change at 01:34:18 UTC Mon Mar version 15.0 no service pad service timestamps debug datetime msec service timestamps log datetime msec no service password-encryption hostname RS1 boot-start-marker boot-end-marker no aaa new-model system mtu routing 1500 vtp mode transparent spanning-tree mode pvst spanning-tree extend system-id vlan internal allocation policy ascending vlan 100 name uplink vlan 201 name izolovany vlan 202 name komunitni vlan 204 name mgmt vlan interface FastEthernet0/1 switchport access vlan 801 switchport mode access interface FastEthernet0/2 switchport access vlan 802 switchport mode access interface FastEthernet0/3 switchport trunk encapsulation dot1q switchport mode trunk interface Vlan1 no ip address leden /19

17 ip http server ip http secure-server line con 0 line vty 5 15 end no debug ospf 1 events leden /19

18 10.2 Kompletní výpisy debugů OSPF Klasika Shození interface Left router shutdown RP/0/0/CPU0:left(config-if)#commit Mon Jan 12 13:05: UTC RP/0/0/CPU0:left(config-if)# Right router RP/0/0/CPU0:Jan 12 13:05: : ospf[1014]: %ROUTING-OSPF-5-ADJCHG : Process 1, Nbr on GigabitEthernet0/0/0/1 in area 1 from FULL to DOWN, Neighbor Down: dead timer expired, vrf default vrfid 0x Nahození interface Left router commit Mon Jan 12 13:01: UTC RP/0/0/CPU0:Jan 12 13:01: : ifmgr[226]: %PKT_INFRA-LINK-3-UPDOWN : Interface GigabitEthernet0/0/0/0, changed state to Down RP/0/0/CPU0:left(config-if)#RP/0/0/CPU0:Jan 12 13:01: : ifmgr[226]: %PKT_INFRA- LINK-3-UPDOWN : Interface GigabitEthernet0/0/0/0, changed state to Up Right router RP/0/0/CPU0:right#debug ospf 1 monitor RP/0/0/CPU0:Jan 12 13:01: : ospf[1014]: %ROUTING-OSPF-5-ADJCHG : Process 1, Nbr on GigabitEthernet0/0/0/1 in area 1 from LOADING to FULL, Loading Done, vrf default vrfid 0x OSPF s Loop-Free Alternative Shození interface Left router shutdown RP/0/0/CPU0:left(config-if)#commit Mon Jan 12 13:19: UTC Right router RP/0/0/CPU0:right#RP/0/0/CPU0:Jan 12 13:19: : ospf[1014]: sched dijkstra: Schedule SPF in area 1 Change in LS ID , LSA type R, RP/0/0/CPU0:Jan 12 13:19: : ospf[1014]: reset throttling to 50 ms RP/0/0/CPU0:Jan 12 13:19: : ospf[1014]: Schedule SPF: area 1spf_time wait_interval RP/0/0/CPU0:Jan 12 13:19: : ospf[1014]: Begin Dijkstra for area 1 at RP/0/0/CPU0:Jan 12 13:19: : ospf[1014]: End Dijkstra at , Total elapsed time RP/0/0/CPU0:Jan 12 13:19: : ospf[1014]: %ROUTING-OSPF-5-ADJCHG : Process 1, Nbr on GigabitEthernet0/0/0/1 in area 1 from FULL to DOWN, Neighbor Down: dead timer expired, vrf default vrfid 0x RP/0/0/CPU0:Jan 12 13:19: : ospf[1014]: reset throttling to 50 ms RP/0/0/CPU0:Jan 12 13:19: : ospf[1014]: reset throttling to 50 ms RP/0/0/CPU0:Jan 12 13:19: : ospf[1014]: sched dijkstra: Schedule SPF in area 1 Change in LS ID , LSA type R, RP/0/0/CPU0:Jan 12 13:19: : ospf[1014]: sched dijkstra: Schedule SPF in area 1 leden /19

19 Change in LS ID , LSA type N, RP/0/0/CPU0:Jan 12 13:19: : ospf[1014]: reset throttling to 50 ms RP/0/0/CPU0:Jan 12 13:19: : ospf[1014]: Schedule SPF: area 1spf_time wait_interval RP/0/0/CPU0:Jan 12 13:19: : ospf[1014]: Begin Dijkstra for area 1 at RP/0/0/CPU0:Jan 12 13:19: : ospf[1014]: End Dijkstra at , Total elapsed time Nahození interface Left router interface gigabitethernet 0/0/0/0 RP/0/0/CPU0:left(config-if)#no shutdown RP/0/0/CPU0:left(config-if)#commit Mon Jan 12 13:21: UTC RP/0/0/CPU0:Jan 12 13:21: : ifmgr[226]: %PKT_INFRA-LINK-3-UPDOWN : Interface GigabitEthernet0/0/0/0, changed state to Down RP/0/0/CPU0:left(config-if)#RP/0/0/CPU0:Jan 12 13:21: : ifmgr[226]: %PKT_INFRA- LINK-3-UPDOWN : Interface GigabitEthernet0/0/0/0, changed state to Up Right router RP/0/0/CPU0:right#RP/0/0/CPU0:Jan 12 13:21: : ospf[1014]: sched dijkstra: Schedule SPF in area 1 Change in LS ID , LSA type R, RP/0/0/CPU0:Jan 12 13:21: : ospf[1014]: reset throttling to 50 ms RP/0/0/CPU0:Jan 12 13:21: : ospf[1014]: Schedule SPF: area 1spf_time wait_interval RP/0/0/CPU0:Jan 12 13:21: : ospf[1014]: Begin Dijkstra for area 1 at RP/0/0/CPU0:Jan 12 13:21: : ospf[1014]: End Dijkstra at , Total elapsed time RP/0/0/CPU0:Jan 12 13:21: : ospf[1014]: %ROUTING-OSPF-5-ADJCHG : Process 1, Nbr on GigabitEthernet0/0/0/1 in area 1 from LOADING to FULL, Loading Done, vrf default vrfid 0x RP/0/0/CPU0:Jan 12 13:21: : ospf[1014]: reset throttling to 50 ms RP/0/0/CPU0:Jan 12 13:21: : ospf[1014]: initialize throttling to 50 ms RP/0/0/CPU0:Jan 12 13:21: : ospf[1014]: sched dijkstra: Schedule SPF in area 1 Change in LS ID , LSA type N, RP/0/0/CPU0:Jan 12 13:21: : ospf[1014]: reset throttling to 50 ms RP/0/0/CPU0:Jan 12 13:21: : ospf[1014]: Schedule SPF: area 1spf_time wait_interval RP/0/0/CPU0:Jan 12 13:21: : ospf[1014]: sched dijkstra: Schedule SPF in area 1 Change in LS ID , LSA type R, RP/0/0/CPU0:Jan 12 13:21: : ospf[1014]: Begin Dijkstra for area 1 at RP/0/0/CPU0:Jan 12 13:21: : ospf[1014]: End Dijkstra at , Total elapsed time RP/0/0/CPU0:Jan 12 13:21: : ospf[1014]: wait_interval 200 ms next wait_interval 400 ms RP/0/0/CPU0:Jan 12 13:21: : ospf[1014]: Schedule SPF: area 1spf_time wait_interval RP/0/0/CPU0:Jan 12 13:21: : ospf[1014]: sched dijkstra: Schedule SPF in area 1 Change in LS ID , LSA type R, RP/0/0/CPU0:Jan 12 13:21: : ospf[1014]: Begin Dijkstra for area 1 at RP/0/0/CPU0:Jan 12 13:21: : ospf[1014]: End Dijkstra at , Total elapsed time RP/0/0/CPU0:Jan 12 13:21: : ospf[1014]: wait_interval 50 ms next wait_interval 400 ms leden /19