OSPF mapa

Desktopová aplikace v Javě, která vytváří mapu topologie sítě OSPF routrů.

Adresa: http://lab.hkfree.org/ospfmap/

Vývoj v rámci 3. etapy (a dále) bude probíhat na http://code.google.com/p/ospf-visualiser/

Realizováno jako bakalářká/diplomová práce na FIM UHK.

Cíle pro 3. etapu

• rozsirit uzivatelskou zakladnu
  • umistit na code.google.com / sf.net / github.com
  • udelat dvojjazycny: cestina/anglictina
  • umoznit pripojeni pres telnet konzoli do libovolne quaggy (odpadne 100% nutnost serverove casti; + moznost pridat IP/hostname DNS serveru, ktery umi reverzne resolvovat nazvy routru na jmena), casem do snmp (viz nize)

• zlepsit UX
  • projit si aplikaci "nezavislyma ocima", navrhnout dilci vylepseni v pouzitelnosti/intuitivnosti (vic "nabizet" postup v ramci aplikace)
    • zname problemy usability:
      • problematicky vyber historickeho stavu ze stromu
      • pri zobrazeni mapy v ni clovek tehko hleda konkretni router - doplnit vyhledavaci policko i nad mapu a vyhledany router nejak docasne vvyraznit (napr. animaci zobrazeni soustrednych kruznic se stredem v routru od velke k mensim - jakoby "terc" ukazujici na vyhledany router)
      • zapamatovat si nektera nastaveni (aby uzivatel nemusel vyplnovat znovu), napr. v property file v nejakem podadresari v domovskem adresari uzivatele
    • zvazit pouziti jine/rychlejsi vykreslovaci knihovny (JUNG vypada dost pomaly)

• opravy chyb

• dalsi rozsireni
  • testovat, na čem je daný router založen: Quagga/Linux, Mikrotik, L3 switch,... (snmp + asi nějaké heuristiky typu co tam běží na portu 80, případně nějaký network fingerprint mechanismus přes p0f atp.)
  • pridat nacitani ospf databaze z snmp
  • propojit s lokalnimi topologiemi sesbiranymi na okrajich site pomoci LLTD, ARP, traceroute/tracenet (http://itom.utdallas.edu/) nebo jinych technik

Pripominky Paul

1) nacit tech zipu vic (resp. jen zadat casovy roszah a zipy si to samo najde) a tak mit moznost ukazat linky, ktere maji za cas X vetsi casovy vypadek nez Y (idealne s volbou odkud to chci merit - alias dostupnost) - v case i %, s volitelnym X a Y 1a) "video" v danem casovem rozsahu

2) IPv6

2a) ukazat kde je jen v4, jen v6, oboje ... kde se to lisi (trasa, costy)

3) oznaceni, kde je koncova sit (tj. typicky pripojenci), ale neni tam nastaveno passive-interface

4) pomoci cytoscape vytvaret cloudovou mapu (sdruzovat routery do AP oblacku - podle router-ID 10.107.89.x)

5) potom co zmacknu "load data" tak by to chtelo nejakou hlasku, ze teda neco provadi ... nez se zobrazi vystup z toho ZIPu

6) jak to zobrazi nejkratsi cestu, tak by se mohly zvyraznit taky ty costy 6a) a co druha nejkratsi cesta (a rozdil od nejkratsi)

7) nevim, jestli to je mym systemem (SUSE), ale u tech asymetrickych linek ta modra je skoro stejna jak ta cerna

8) GPS all lehce poladit

9) do Help dat odkaz na dokumentaci ... neprislo mi uplne jak pro blby co znamenaji ty failure

Pozn. zkousel jsem na ospf3.0.1jar, network design z lab.hkfree.org v2012-03-03--23-55.zip, java 1.6.0_26-b03.

Další náměty pro 3. etapu

• ziskani aktualni mapy pomoci telnetu primo z bezici quaggy a pres DNS online dohledat nazvy (obecne "odhadnout" suffix a ten odstranit, napr. pokud 70% ma ten suffix, ted je tam "zadratovan" .hkfree.org)

• opravit dialog pro vyber "cela mapa / od uzlu xy" v linuxu (vypada rozpadle)

• zapracovat na user experience
  • spatne se klika na spoje - napr. pri operaci "zakazani uzlu" - jsou tenke a nejde se do nich trefit (da se udelat cara jen "virtualne" tlustsi pro kliknuti?)
  • vic propojit rezimy (historie vs. aktualni stav - mozna by na to slo jedno univerzalni okno)
  • moznost hledani v graficke mape (jen opticky mnohdy nemuzu najit uzel, ktery hledam)
  • zefektivnit nacitani "zdroju" dat (napr. nacitat po mesicich, aby to netrvalo tak dlouho, nabidnout primou cestu pro zobrazeni poslednich dat z archivu)

• vyhledavani podle IP - zadam ip a najde mi to router, ktery distribuuje subnet, ze ktereho dana IP je

• podpora vice area (v rezimu priopjeni pres telnet i automatickem stahovani do suoboru - nutna uprava i serverove casti)

• automaticky navrhu doporuceni zmen v topologii (zvyseni dostupnosti uzlu, resp. cesty ke korenu) - nejaky ten "expertni system" ;-)

• evaluace dalsich moznych knihoven (ten JUNG rozvrhuje nejak dost pomalu)

• bug: (minimalne ve windows 7) kdyz chci otevrit NML, tak v dialogu nevidim adresare a tudiz se nemuzu do jineho adresare, nez vychoziho nebo nadrazenych (asi nejak spatne nastaveny filtr)

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
• moznosti vizualizace L2 topologie (tu je mozno ziskat vzdy lokalne pomoci LLTD, LLDP, CDP)

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)

Export

• zvazit moznost exportu do http://www.yworks.com/en/products_yed_about.html

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)
• 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. Potvrzeno vice uzivateli.
• Když mám zobrazen jen segmet sítě a chci použít funkci zobrazení sousedů, přesto, že mám zastaveno rozvrhování grafu, mě funkce zobrazení sousedů sousedy rozvrhuje, abych pohyb zastavil musím rozvrhování zapnout/vypnout a tím se mi ručně rozložený graf zase rozhází.