OSPF mapa

Desktopová aplikace v Javě, která vytváří mapu topologie sítě OSPF routrů. Adresa: http://10.107.12.1/ospf

Náměty na rozšíření

• vizualizacni moznosti knihovny (animace, zvyrazneni apod.)

• interaktivni pruzkum mapy: zobrazim jen samotny zvoleny router, po najeti na nej se zobrazi (docasne) jeho sousedi, pokud prejedu na nejaky z nich a kliknu, zustane v mape zobrazen stale - cely proces lze opakovat a tim si do mapy "dokreslovat" dalsi uzly.

• dynamicky prubeh zmen topologie (animace?)

1. dumpy ze 2 a vice casu
2. snifovat sitovy provoz
3. parsovat logy z Quaggy

• vic userfriendly (provazanost vyberu routru v jednotlivych listech, v listech moznost "fulltextoveho" vyhledavani IP i textu - mysleno pri vyberu routru a pod.)

• moznost navrhovat ceny spoju (jako ve VisualOSPF, ukazka napr. zde: [[1]]), visualizovat

nejkratsi cesty (Dijkstra), vymyslet vizualizaci asymetrickych cest

• rozsirit o moznost geografickeho urceni polohy uzlu na mape

• "metriky" site - vypadek kolika hran/uzlu rozpadne sit na vic casti,

pravdepodobnosti techto vypdaku vzhledem ke spolehlivosti spoju (viz. casovy prubeh - flappovani), nalezeni oblasti uzlu se spatnou spolehlivosti, identifikace zpusobujiciho spoje

• "metriky jednolivych uzlu" - vypadek kolika uzlu/hran (a kterych)

zpusobi vypadek dostupnosrti uzlu z korenoveho uzlu, pravdepodobnost takoveho vypadku (vzhledem ke spolehlivoasti spoju)

• moznost automatickeho navrhu doporuceni zmen v topologii (zvyseni

dostupnosti uzlu, resp. cesty ke korenu)

• PeS: Jeste by stalo za to zvazit optimalizaci. Pri zobrazeni grafu a prepnuti do rucniho rozvrzeni se viditelne nic neprekresluje, ale presto to zere nechutne mnoho CPU cyklu, na mem T9600 to je pres 50%... Tipuji to na neustale prekreslovani grafu i kdyz v nem nedoslo ke zmene rozlozeni.

• Paul: vybrat si uzel, pak vsechny linky z daneho uzlu do urcite hloubky ... nasledne mit moznost na hranach prepisovat costy a treba klikem na nejaky uzel by se ukazal strom z daneho uzlu ... nasledne mit moznost nejakou hranu na chvili odebrat a zase mit moznost se podivat na nejaky uzel a jeho strom
  • (tohle v podstate delam "rucne" kdyz navrhuju costy pro jih - nejak zvolim costy a pak se snazim z kazdeho AP podivat kudy potece =strom a jak potece kdyz vypadne nejaka linka ... v podstate na tohle by se dal udelat nejaky algoritmus - jde o to v urcite oblasti odebirat hrany a divat se vzdy z kazdeho uzlu, nastavit costy tak, aby byla co nejvetsi propustnost ke vsem AP a zaroven co nejvetsi propustnost behem nejakych "statisticky realnych" vypadku ... k tomu by bylo potreba jeste odnekud natahnout rychlost te linky - to by se hodilo dat do nejakeho IS, protoze tuhle hodnotu potrebuje i weathermap, cloudova mapa, tak aby se to udrzovalo na jednom miste)

• z logu quaggy tezit vypadky linek (prozkoumat zda je tam videt jak vypadek tak nahozeni) (pavkriz - udelat export)
• otazka databaze linek s rychlostma (problem ze logicke linky v OSPF nemusi odpovidat 1:1 fyzickym spojum)
• najit vhodne vypovydajici metriky, resp. jejich zobrazeni (kde jsou nejslabsi mista a pod), nezapomenout zakomponovat cetnost vypadku (pro nas) udelat evaluaci jak se lisi OSPF mapa od fyzicke mapy
• korelace mezi jevy v prostredi a vypadky spoju (obecne ale neprecenit, nejaka chyba dokaze mit zrejme mnohem vetsi vliv)
  • udaje z chmi.cz (srazky, resp. srazky+teplota [rozliseni deste a snehu])
  • casove udaje v dlouhem horizontu (rocni obdobi -> olisteni stromu)
  • ruseni/zatizeni (asi neumime u wifi uplne odlisit) - zrejme jen trendy, vymyslet nejake modely (ruseni linearne nebo jinak trvale stoupa [pripadne najit nejake zdroje udaje o ruseni, resp. EMG smogu] + denni/tydeni cykly, zatizeni taky trvale stoupa+cykly - dalo by se mozna rict, ze ruseni v okoli roste rychleji nez zatizeni vlastni site [to je otazka, ale muze to tak byt, zvlaste v pripade saturace vytizeni site])
  • -> odhad citlivosti spoju (a tim i spolehlivosti) v zavislosti na prostredi (odhad charakteru spoje - 2.4g, 5g, FSO,... najit nejake modelove charakteristiky")
• korelace mezi vypadky jednotlivych linku (muze napovidat, ze dva logicke linky mohou vest skrz spolecny fyzicky spoj, proto pokazde vypadnou najednou)
• srovnani charakteru vypadku (detekovanych pres LSA) dvou ruznych spoju muze byt problematicke kvuli rozdilnym nastavenim hello/dead intervalum na spojich

Upresneni

Prozkoumavani topologie

(motivace: soucasne varianty "zobrazeni cele site" nebo "od uzlu do urcite hloubky" nejsou dostatecne, je potreba jemneji vybirat, co chci videt)

• dva mozne zpusoby jak "zacit" (zbytek ovladani a chovani by mel byt uz pak spolecny) - bud si nechat zobrazit cely graf (a mozno jej pozdeji "umazavat") nebo zobrazit jeden zvoleny uzel (a mozno dal "dokreslovat" uzly)
• zobrazovani/skryvani uzlu ("cerny uzel" - trvale zobrazeny)
  • kliknu na cerny uzel, zobrazi se sedive vsichni sousedi (znovu kliknutim zase zmizi ti sedivi)
  • kliknutim na sedivy uzel (="docasne zobrazeny") se z nej stane cerny a uz tam zustane zobrazen porad (resp. pravym tlacitkem pres kontextove menu uzlu pujde skryt i cerny uzel - viz napr. pri redukci zobrazeni puvodne celeho grafu site)
  • pres kontextove menu pujde uzel explicitne "zcernat" (stejna funkce jako kliknutim)
  • pres kontextove menu uzlu pujde expandovat sousedy do urcene hloubky (podobne soucasne funkci)
  • zvazit, zda kontextove menu otvirat pravym tlacitkem (neintuitivni, uzivatele mohou tyto funkce prehlednout) nebo zobrazenim nejakeho symbolu "lakajiciho" ke kliknuti, cimz se menu zobrazi (viz. napr. ikonka zorazujici provedenou automatickou opravu ve Wordu, pres kterou lze opravu odvolat)
  • pokud to nebude ergonomicky nebo technicky problem, tak se bude graf site stale dynamicky rozvrhovat behem zobrazovani/skryvani uzlu (ergonomicky by bylo sikovne, kdyby v miste, kde jsem mysi, nebo aspon v pripade ze jsem nad uzlem, bylo rozvrhovani grafu pomalejsi, nebo se pro dany uzel zastavilo, aby uzel "neutikal" uzivateli - zvazit)

Analyza smerovacich cest

• v zobrazenem grafu (nebo casti) zvolit koren (obvykle si asi clovek vybere IGW) a zobrazit (treba silnejsimi carami) minimalni kostru grafu ("strom"), tj. kudy budou data smerovana
  • asymetrie na costech ignorovat (jen zvyraznit, ze je tam neco "spatne", pocitat costy jako by byly symetricke - jeden vybrat; zobrazeni asymetrickych cest by to zrejme moc komplikovalo, pripadne zvazit moznosti, pekne by bylo to opravdu zobrazovat, ale zda to nebude na ukor pouzitelnosti?!
  • min. kostru je treba pocitat z kompletniho grafu (i kdyz mam zobrazenou jen cast)! (svazit, jak zobrazovat, kdyz z uzlu, ktery mam zobrazen vede nejkratsi cesta do korene pres uzly, ktere zobrazene nemam - napada me napr. zobrazit nejaky novy symbol, predstavujicu "skrytou cestu", ktery by se dal rozkliknout a tim by se cesta zobrazila)

Rezim navrhu site

• mit moznost "odemknout" si aktualni graf a zacit ho upravovat (poradi dle priorit)

1. menit costy
2. vypinat a pak zas opetovne zapinat uzly = simulace vypadku uzlu (asi neni vhodne to visualizovat jako odebrani uzlu, spis ho nejak skrtnout nebo tak neco, nebo udelat carkovane)
3. vypinat a pak zas opetovne zapinat spoje = simulace vypadku spoje (opet asi carkovanim)
4. nejnizsi priorita (bude asi slozitejsi): pridavat nove uzly a nove hrany, s tim souvisi i potreba je skutecne odebirat (ne jen "vypinat" jako viz vyse)

• behem editace se predpoklada, ze napr. analyza smerovacich cest se bude odpovidajicim zpusobem aktualizovat
• implementacne bude zrejme vyhovujici, pokud budou zmeny provadeny primo do OSPF modelu

Ukladani

• mit moznost si celou praci ulozit a pozdeji zase nacist (tj. idealne ulozit stav aplikace tak, abych si ji pak otevrel a pokracoval) - tj. ulozeni celeho modelu, vseho co jsem si tam pozmenil, idealne i rozvezeni zobrazeneho grafu
• vyzadovany otevrene formaty (asi by stacila serializace do XML, napr. pres Apache XML Beans nebo java.beans.XMLEncoder)

Známé chyby

• nezobrazuje souběžné (paralelní) spoje i multispoje - opraveno
• v momente generovani dat na serveru (nejakou dobu to trva, probiha kazdych 5 minut) muze aplikace hlasit nemoznost nacteni dat (reseni: na serveru pripravit v jinem adresari a "atomicky" prekopirovat uz pripravena data, pripadne distribuovat formou zip archivu - muze se hodit do budoucna pro podporu pribehu v case - vice zipu)