OSPF na páteři

co je na síti

OSPF na páteři

Příspěvekod vaclavd » čtv 03. zář 2015 17:48:59

Při vypínání serverů na páteři docházelo k tomu, že se páteř rozpojila a servery nekomunikovaly do internetu. Takto to opravdu funguje. Rozpojí-li se OSPF broadcast síť na dva segmenty, v každé části se nakonfiguruje jeden Designated router (DR) a komunikuje jen jedna část. Pokud se v nekomunikující části nachází router do internetu (rum), nekomunikuje nikdo. Na páteři je nyní 16 serverů, od Marxáků do všech částí Čelákovic a výpadek každé části toto může způsobit. Funguje to jak má. Vyrobil jsem si ve Virtualboxu síť 6 Mikrotiků a testoval výpadky OSPF, disablováním bridge na M5. Jak vypadá routování při výpadku se můžete podívat na routy v sekci code.

  • Proč máme páteř - protože máme tímto L2 spojení mezi servery 1Gbit. Bez páteře L2 bychom 1Gbit všude neuroutovali
  • Páteř se nesmí rozpojovat!! Musí se páteř zaokrohovat a do páteře nedávat nic, co tam nepatří. Vzdálené servery připojit jako peer.
  • Nastaví li-se priorita pro DR/BDR na všech serverch na 0, nechá se jen Rum do internetu a Gin jako záloha, část do internetu bude pořád komunikovat. Ostatní jsou stejně rozpojeni a nemůžou komunikovat. Ti co mají spojení na Rum komunikují.
  • Pokud se nastaví PTMP( point to multipoint) na páteři, místo broadcast, jak chtěl Honza, routování není na síť ale na hosty. Broadcast přidá jednu síť do rout, PTMP všechny servery, tj. 16. Tímto funguje komunikace, po rozpojení sítě. Přidá se ale 16 nových rout, viz výpisy routování v sekci code.
  • Musíme omezit počet rout nakonfigurováním nových OSPF area

Obrázek

Kód: Vybrat vše
##### OSPF broadcast na 192.168.10.0/24
##### Normalni stav ###################

[admin@M5] > /ip route print
Flags: X - disabled, A - active, D - dynamic,
C - connect, S - static, r - rip, b - bgp, o - ospf, m - mme,
B - blackhole, U - unreachable, P - prohibit
 #      DST-ADDRESS        PREF-SRC        GATEWAY            DISTANCE
 0 ADo  10.93.0.2/32                       192.168.56.12           110
 1 ADo  10.93.0.3/32                       192.168.56.13           110
 2 ADo  10.93.0.4/32                       192.168.56.13           110
                                           192.168.56.12     
 3 ADC  10.93.0.5/32       10.93.0.5       dummy                     0
 4 ADo  10.93.0.6/32                       192.168.20.6            110
 5 ADo  192.168.10.0/24                    192.168.56.13           110
                                           192.168.56.12     
 6 ADC  192.168.20.0/24    192.168.20.5    ether4                    0
 7 ADo  192.168.22.0/24                    192.168.56.12           110
 8 ADo  192.168.23.0/24                    192.168.56.13           110
 9 ADo  192.168.24.0/24                    192.168.56.13           110
                                           192.168.56.12     
10 ADC  192.168.56.0/24    192.168.56.15   ether1                    0
[admin@M5] >

####### Rozpojeni ##################

[admin@M5] > /ip route print
Flags: X - disabled, A - active, D - dynamic,
C - connect, S - static, r - rip, b - bgp, o - ospf, m - mme,
B - blackhole, U - unreachable, P - prohibit
 #      DST-ADDRESS        PREF-SRC        GATEWAY            DISTANCE
 0 ADo  10.93.0.1/32                       192.168.56.12           110
 1 ADo  10.93.0.2/32                       192.168.56.12           110
 2 ADo  10.93.0.3/32                       192.168.56.13           110
 3 ADC  10.93.0.5/32       10.93.0.5       dummy                     0
 4 ADo  10.93.0.6/32                       192.168.20.6            110
 5 ADo  192.168.10.0/24                    192.168.56.12           110
 6 ADC  192.168.20.0/24    192.168.20.5    ether4                    0
 7 ADo  192.168.21.0/24                    192.168.56.12           110
 8 ADo  192.168.22.0/24                    192.168.56.12           110
 9 ADo  192.168.23.0/24                    192.168.56.13           110
10 ADC  192.168.56.0/24    192.168.56.15   ether1                    0
[admin@M5] >

[admin@M5] > /ping 192.168.10.1 count=1 
  SEQ HOST                                     SIZE TTL TIME  STATUS             
    0 192.168.10.1                               56  64 2ms 
    sent=1 received=1 packet-loss=0% min-rtt=2ms avg-rtt=2ms max-rtt=2ms

[admin@M5] > /ping 192.168.10.2 count=1
  SEQ HOST                                     SIZE TTL TIME  STATUS             
    0 192.168.10.2                               56  64 0ms 
    sent=1 received=1 packet-loss=0% min-rtt=0ms avg-rtt=0ms max-rtt=0ms

[admin@M5] > /ping 192.168.10.3 count=1
  SEQ HOST                                     SIZE TTL TIME  STATUS             
    0 192.168.10.3                                            timeout           
    sent=1 received=0 packet-loss=100%

[admin@M5] > /ping 192.168.10.4 count=1
  SEQ HOST                                     SIZE TTL TIME  STATUS             
    0 192.168.10.4                                            timeout           
    sent=1 received=0 packet-loss=100%

[admin@M5] >


######## PMTP ############

########### při rozpojení i normálně stejné routy

[admin@M5] > /ip route print
Flags: X - disabled, A - active, D - dynamic,
C - connect, S - static, r - rip, b - bgp, o - ospf, m - mme,
B - blackhole, U - unreachable, P - prohibit
 #      DST-ADDRESS        PREF-SRC        GATEWAY            DISTA
 0 ADo  10.93.0.1/32                       192.168.56.12           
 1 ADo  10.93.0.2/32                       192.168.56.12           
 2 ADo  10.93.0.3/32                       192.168.56.13           
 3 ADo  10.93.0.4/32                       192.168.56.13           
 4 ADC  10.93.0.5/32       10.93.0.5       dummy                   
 5 ADo  10.93.0.6/32                       192.168.20.6           
 6 ADo  192.168.10.1/32                    192.168.56.12           
 7 ADo  192.168.10.2/32                    192.168.56.12           
 8 ADo  192.168.10.3/32                    192.168.56.13           
 9 ADo  192.168.10.4/32                    192.168.56.13           
10 ADC  192.168.20.0/24    192.168.20.5    ether4                 
11 ADo  192.168.21.0/24                    192.168.56.12           
12 ADo  192.168.22.0/24                    192.168.56.12           
13 ADo  192.168.23.0/24                    192.168.56.13           
14 ADo  192.168.24.0/24                    192.168.56.13           
15 ADC  192.168.56.0/24    192.168.56.15   ether1                 

####### Rozpojeni #########

[admin@M5] > /ping 192.168.10.1 count=1
  SEQ HOST                                     SIZE TTL TIME  STATUS             
    0 192.168.10.1                               56  64 1ms 
    sent=1 received=1 packet-loss=0% min-rtt=1ms avg-rtt=1ms max-rtt=1ms

[admin@M5] > /ping 192.168.10.2 count=1
  SEQ HOST                                     SIZE TTL TIME  STATUS             
    0 192.168.10.2                               56  64 1ms 
    sent=1 received=1 packet-loss=0% min-rtt=1ms avg-rtt=1ms max-rtt=1ms

[admin@M5] > /ping 192.168.10.3 count=1
  SEQ HOST                                     SIZE TTL TIME  STATUS             
    0 192.168.10.3                               56  64 1ms 
    sent=1 received=1 packet-loss=0% min-rtt=1ms avg-rtt=1ms max-rtt=1ms

[admin@M5] > /ping 192.168.10.4 count=1
  SEQ HOST                                     SIZE TTL TIME  STATUS             
    0 192.168.10.4                               56  64 2ms 
    sent=1 received=1 packet-loss=0% min-rtt=2ms avg-rtt=2ms max-rtt=2ms

[admin@M5] >
  • 0

vaclavd
 
Příspěvky: 960
Registrován: stř 31. črc 2013 16:00:35
Reputace: 16

Re: OSPF na páteři

Příspěvekod naj.satah » čtv 03. zář 2015 20:08:53

Hezke, zde je par veci:

  • priority 0 z podruznych routeru uz neni akorat na pivu, to jsem zatim nechtel schodit
  • nejcasteji pada switch v K70 (kotelna stankovskeho) a pak elektrika na 1581 cimz je postizen i backup router GIN
  • chce to zmensit L2 a to dost dramaticky, v zasade vsechny routery jsou zapojeny do switchu a provoz jde zbytecne nekolikrat pres ne...
    Viz treba hlavni linka O2 -> Switch K360 -> BGP CCR1009 -> Switch K360 -> Rum -> Switch K360 -> vsichni ostatni
  • 0

Attachments
pater.png
Zapojeni patere
pater.png (175.95 KiB) Zobrazeno 3779 krát
Ať je Únor nebo Leden, Naj Satah je jenom jeden.
Uživatelský avatar
naj.satah
 
Příspěvky: 1366
Registrován: pon 29. črc 2013 22:07:09
Reputace: 8

Re: OSPF na páteři

Příspěvekod tencl » čtv 03. zář 2015 20:28:02

vaclavd píše:...Musíme omezit počet rout nakonfigurováním nových OSPF area...


Area mají své pevné hranice. Vše co z okolních area někam jde, tak jen přes centrální area a jen přes přeshraniční spoj. Ty musí být všechny dostatečně kapacitní na provoz celé area, tedy žádné 5GHz peery. Například když by Zadráha byla samostatná area, tak jeden hraniční spoj bude optika, druhý rádio od Davida, ty kapacitu mají, ostatní přeshraniční spoje se zruší.

A nevím, zda je snadné nějaký hraniční spoj upřednostnit v obou směrech toku dat, to může být problém.

Každá area musí mít spojení s centrální area, to také komplikuje návrh sítě, nelze aby tok šel do jiné než centrální area. Požadavek spojení do centrální area si vynucuje zálohu, aby v případě výpadku přeshraničního spoje do area 0 data měla kudy jít - tedy každá area musí mít nejméně dva vysocekapacitní spoje do area 0.

Area přináší komplikace, které u dnešního routování zatím nemáme.

Jedna věc ale použitelná je - stub area. To je slepá ulice, která má právě jednu cestu do area 0 a nikdy mít druhou cestu nebude. Nebo když bude, bude třeba to na všech routerech předělat. Nicméně zkušenosti jsou smíšené, a do stovek rout jsem četl názor area nedělat.
  • 0

tencl
 
Příspěvky: 6220
Registrován: sob 16. lis 2013 16:02:18
Reputace: 100

Re: OSPF na páteři

Příspěvekod naj.satah » čtv 03. zář 2015 21:11:57

tencl píše:Area mají své pevné hranice. Vše co z okolních area někam jde, tak jen přes centrální area a jen přes přeshraniční spoj. Ty musí být všechny dostatečně kapacitní na provoz celé area, tedy žádné 5GHz peery. Například když by Zadráha byla samostatná area, tak jeden hraniční spoj bude optika, druhý rádio od Davida, ty kapacitu mají, ostatní přeshraniční spoje se zruší.

A nevím, zda je snadné nějaký hraniční spoj upřednostnit v obou směrech toku dat, to může být problém.


Nic se rusit nemusi, jen se costy pocitaji v kazde area zvlast. Priorizovat to jses schopen, takze nemusis rusit 5GHz.

tencl píše:Každá area musí mít spojení s centrální area, to také komplikuje návrh sítě, nelze aby tok šel do jiné než centrální area. Požadavek spojení do centrální area si vynucuje zálohu, aby v případě výpadku přeshraničního spoje do area 0 data měla kudy jít - tedy každá area musí mít nejméně dva vysocekapacitní spoje do area 0.


Jo i ne. Muzes mit i nozovou zalohu 5GHz, proste to chce jen spravne nacostovat z pohledu obou area :)

tencl píše:Area přináší komplikace, které u dnešního routování zatím nemáme.


Resime vsak jine.

tencl píše:Jedna věc ale použitelná je - stub area. To je slepá ulice, která má právě jednu cestu do area 0 a nikdy mít druhou cestu nebude. Nebo když bude, bude třeba to na všech routerech předělat. Nicméně zkušenosti jsou smíšené, a do stovek rout jsem četl názor area nedělat.

[/quote]

Stub area nepotrebujem, to je jednodussi to nahradit statickym routovanim.

Nejvetsi vyhoda area by byla pri agregaci rout. Napr:
Area 0 = 10.93.0.0/19 (10.93.0.0-10.93.31.255)
Area 1 = 10.93.32.0/19 (10.93.32.0-10.93.63.255)
Area 2 = 10.93.64.0/19 (10.93.64.0-10.93.95.255)
Area 3 = 10.93.96.0/19 (10.93.96.0-10.93.127.255)

Cimz by Area 0 vlastne znala z ostatnich jen 3 routy navic a ostatni by znali maximalne sousedni /19 a zbytek by hnali default routou na 0. V nasem pripade vsak nic nezagregujes = area 0 bude znat vse jako doposud a jen ty periferie budou odhlehceny (i o zalohy).

Tohle ale vynikne asi az s IPv6 kdy se predpoklada ze kazdy clovek bude mit vlastni /64 subnet.
  • 0

Ať je Únor nebo Leden, Naj Satah je jenom jeden.
Uživatelský avatar
naj.satah
 
Příspěvky: 1366
Registrován: pon 29. črc 2013 22:07:09
Reputace: 8

Re: OSPF na páteři

Příspěvekod vaclavd » pát 04. zář 2015 8:24:34

naj.satah píše:
tencl píše:Area mají své pevné hranice. Vše co z okolních area někam jde, tak jen přes centrální area a jen přes přeshraniční spoj. Ty musí být všechny dostatečně kapacitní na provoz celé area, tedy žádné 5GHz peery. Například když by Zadráha byla samostatná area, tak jeden hraniční spoj bude optika, druhý rádio od Davida, ty kapacitu mají, ostatní přeshraniční spoje se zruší.

A nevím, zda je snadné nějaký hraniční spoj upřednostnit v obou směrech toku dat, to může být problém.


Nic se rusit nemusi, jen se costy pocitaji v kazde area zvlast. Priorizovat to jses schopen, takze nemusis rusit 5GHz.

tencl píše:Každá area musí mít spojení s centrální area, to také komplikuje návrh sítě, nelze aby tok šel do jiné než centrální area. Požadavek spojení do centrální area si vynucuje zálohu, aby v případě výpadku přeshraničního spoje do area 0 data měla kudy jít - tedy každá area musí mít nejméně dva vysocekapacitní spoje do area 0.


Jo i ne. Muzes mit i nozovou zalohu 5GHz, proste to chce jen spravne nacostovat z pohledu obou area :)

tencl píše:Area přináší komplikace, které u dnešního routování zatím nemáme.


Resime vsak jine.

tencl píše:Jedna věc ale použitelná je - stub area. To je slepá ulice, která má právě jednu cestu do area 0 a nikdy mít druhou cestu nebude. Nebo když bude, bude třeba to na všech routerech předělat. Nicméně zkušenosti jsou smíšené, a do stovek rout jsem četl názor area nedělat.



Stub area nepotrebujem, to je jednodussi to nahradit statickym routovanim.

Nejvetsi vyhoda area by byla pri agregaci rout. Napr:
Area 0 = 10.93.0.0/19 (10.93.0.0-10.93.31.255)
Area 1 = 10.93.32.0/19 (10.93.32.0-10.93.63.255)
Area 2 = 10.93.64.0/19 (10.93.64.0-10.93.95.255)
Area 3 = 10.93.96.0/19 (10.93.96.0-10.93.127.255)

Cimz by Area 0 vlastne znala z ostatnich jen 3 routy navic a ostatni by znali maximalne sousedni /19 a zbytek by hnali default routou na 0. V nasem pripade vsak nic nezagregujes = area 0 bude znat vse jako doposud a jen ty periferie budou odhlehceny (i o zalohy).

Tohle ale vynikne asi az s IPv6 kdy se predpoklada ze kazdy clovek bude mit vlastni /64 subnet.[/quote]

Tvoje poznámky ohledně area jsou opravdu mimo realitu. Vezmu konkrétní příklad Zadráha. Calé Zadráha může komunikovat přes 3 routery, jeden hlavní (David) a dva záložní (Dějnická, Požáry?). Celou Zadráhu routuje teď David. Pokud si nakonfigurujeme Zadráhu jako area, tak Zadráhu bude stejně jako teď routovat David (+2), jen nám zmizí v síti těch asi 20 rout, které se nebudou propagovat. Area je standardní věc v OSPF, řekni prosím, jaký konkrétní problém nám to může přinést.
  • 0

vaclavd
 
Příspěvky: 960
Registrován: stř 31. črc 2013 16:00:35
Reputace: 16

Re: OSPF na páteři

Příspěvekod tencl » pát 04. zář 2015 9:44:09

Počet rout si nemyslím, že je náš problém. Redukce počtu považuju spíš za optické zlepšení, ostatně světové routovací tabulky jsou enormně větší a funguje to taky.

Ad area : však já jsem kdysi area taky navrhoval, na papíře to vypadá báječně, ale když jsem slyšel praktické zkušenosti, tak jsem od toho ustoupil. Aktuální informace jsem četl podobné, tak jsem místo inovátora mírný skeptik k téhle "novince". Počet rout je prý problém až ve stovkách, tedy máme-li problém dřív, tak máme spíš něco v nastavení špatně typu dead a hello interval, malý počet statických rout, nebo máme nevhodný hardware.

Jenže to jsou už konkrétní řešení, šel bych na to raději směrem od popisu problému než od návrhu řešení a optimalizoval nejdřív naše ospf bez dalších area s pomocí někoho, kdo má praktické zkušenosti s chováním středně velké sítě. Když se ukáže, že jsme narazili na meze ospf (problémy trvají), tak pak teprve hledat jiná řešení, včetna rozdělení sítě na area. Z mého pohledu by plné ospf mělo být jen tam, kde je "křižovatka" alias volba cesty do centra. Statickou routu si myslím že lze agregovat. Samozřejmě je k diskuzi i "area bez arey": redukce switchované páteře na řekněme pět switchů (Učiliště - Stankovského - Na Stráni - CMC - Falcon) a ostatní oddělit routerem a přečíslovat.

Satahu, můžeš prosím tě popsat zásadní problémy, které nám vadí a chceme vyřešit ?
Matěji, můžeš prosím tě zjistit jaká konkrétní řešení užívají větší sítě než my včetně použitých programů a konfigurací ?
  • 0

tencl
 
Příspěvky: 6220
Registrován: sob 16. lis 2013 16:02:18
Reputace: 100

Re: OSPF na páteři

Příspěvekod naj.satah » pát 04. zář 2015 10:36:10

vaclavd píše:Tvoje poznámky ohledně area jsou opravdu mimo realitu. Vezmu konkrétní příklad Zadráha. Calé Zadráha může komunikovat přes 3 routery, jeden hlavní (David) a dva záložní (Dějnická, Požáry?). Celou Zadráhu routuje teď David. Pokud si nakonfigurujeme Zadráhu jako area, tak Zadráhu bude stejně jako teď routovat David (+2), jen nám zmizí v síti těch asi 20 rout, které se nebudou propagovat. Area je standardní věc v OSPF, řekni prosím, jaký konkrétní problém nám to může přinést.


Moje poznamky nejsou mimo realitu.

Takze aktualne pres pivo jde 46 rout. Vcetne jeho dummy a spojovaciho subnetu, coz +- bude finalni stav.

Kód: Vybrat vše
najsatah@amalka:~$ ip r | grep 10.93.253.203
10.93.0.18 via 10.93.253.203 dev eth0.253  proto zebra  metric 37
10.93.0.24 via 10.93.253.203 dev eth0.253  proto zebra  metric 47
10.93.0.25 via 10.93.253.203 dev eth0.253  proto zebra  metric 47
10.93.0.26 via 10.93.253.203 dev eth0.253  proto zebra  metric 37
10.93.0.30 via 10.93.253.203 dev eth0.253  proto zebra  metric 31
10.93.0.35 via 10.93.253.203 dev eth0.253  proto zebra  metric 57
10.93.0.41 via 10.93.253.203 dev eth0.253  proto zebra  metric 37
10.93.0.58 via 10.93.253.203 dev eth0.253  proto zebra  metric 37
10.93.0.62 via 10.93.253.203 dev eth0.253  proto zebra  metric 137
10.93.0.63 via 10.93.253.203 dev eth0.253  proto zebra  metric 47
10.93.0.67 via 10.93.253.203 dev eth0.253  proto zebra  metric 37
10.93.0.68 via 10.93.253.203 dev eth0.253  proto zebra  metric 37
10.93.0.203 via 10.93.253.203 dev eth0.253  proto zebra  metric 21
10.93.0.204 via 10.93.253.203 dev eth0.253  proto zebra  metric 27
10.93.1.120/30 via 10.93.253.203 dev eth0.253  proto zebra  metric 57
10.93.1.232/29 via 10.93.253.203 dev eth0.253  proto zebra  metric 37
10.93.2.36/30 via 10.93.253.203 dev eth0.253  proto zebra  metric 21
10.93.2.48/29 via 10.93.253.203 dev eth0.253  proto zebra  metric 24
10.93.2.68/30 via 10.93.253.203 dev eth0.253  proto zebra  metric 17
10.93.18.128/25 via 10.93.253.203 dev eth0.253  proto zebra  metric 37
10.93.24.0/24 via 10.93.253.203 dev eth0.253  proto zebra  metric 47
10.93.25.0/26 via 10.93.253.203 dev eth0.253  proto zebra  metric 537
10.93.25.64/26 via 10.93.253.203 dev eth0.253  proto zebra  metric 537
10.93.25.128/26 via 10.93.253.203 dev eth0.253  proto zebra  metric 537
10.93.25.192/27 via 10.93.253.203 dev eth0.253  proto zebra  metric 47
10.93.25.224/27 via 10.93.253.203 dev eth0.253  proto zebra  metric 47
10.93.26.0/23 via 10.93.253.203 dev eth0.253  proto zebra  metric 37
10.93.30.0/24 via 10.93.253.203 dev eth0.253  proto zebra  metric 31
10.93.35.0/24 via 10.93.253.203 dev eth0.253  proto zebra  metric 57
10.93.41.0/25 via 10.93.253.203 dev eth0.253  proto zebra  metric 37
10.93.49.0/26 via 10.93.253.203 dev eth0.253  proto zebra  metric 37
10.93.49.64/26 via 10.93.253.203 dev eth0.253  proto zebra  metric 37
10.93.56.0/24 via 10.93.253.203 dev eth0.253  proto zebra  metric 37
10.93.58.0/24 via 10.93.253.203 dev eth0.253  proto zebra  metric 37
10.93.59.0/26 via 10.93.253.203 dev eth0.253  proto zebra  metric 137
10.93.59.64/26 via 10.93.253.203 dev eth0.253  proto zebra  metric 137
10.93.59.128/26 via 10.93.253.203 dev eth0.253  proto zebra  metric 137
10.93.59.224/30 via 10.93.253.203 dev eth0.253  proto zebra  metric 127
10.93.63.0/26 via 10.93.253.203 dev eth0.253  proto zebra  metric 47
10.93.63.204/30 via 10.93.253.203 dev eth0.253  proto zebra  metric 37
10.93.63.208/29 via 10.93.253.203 dev eth0.253  proto zebra  metric 127
10.93.63.216/30 via 10.93.253.203 dev eth0.253  proto zebra  metric 31
10.93.63.240/28 via 10.93.253.203 dev eth0.253  proto zebra  metric 27
10.93.65.0/30 via 10.93.253.203 dev eth0.253  proto zebra  metric 527
10.93.67.0/24 via 10.93.253.203 dev eth0.253  proto zebra  metric 37
10.93.68.0/24 via 10.93.253.203 dev eth0.253  proto zebra  metric 37


Kdyz jak ty rikas tyhle routy zmizi z area 0, tak jak pak muze area 0 vedet kam posilat data pro 10.93.58.xyz kdyz ho nebude znat? Area 1 (Zadraha) to bude mit jednoduche, bude mit svuj pisecek o tehle 46 routach a zbytek posle na hranicni router.

Bez precislovani se da na hranicnim routeru udelat sumarizace rout kdy se z 46 stane 36 a ty uz area 0 znat proste musi. Pokud bude v area vice navazujicich rout, jsi schopen se dostat az k naprosto idealni jedne route o ktere jsem tu uz mluvil.

Tim by efektivita area byla maximalni.

Zde je hezka sumarizacni kalkulacka - http://www.netmatics.net/FreeTools/IPv4 ... pernetCalc
  • 0

Ať je Únor nebo Leden, Naj Satah je jenom jeden.
Uživatelský avatar
naj.satah
 
Příspěvky: 1366
Registrován: pon 29. črc 2013 22:07:09
Reputace: 8


Zpět na Topologie a obsah sítě

Kdo je online

Uživatelé procházející toto fórum: Žádní registrovaní uživatelé a 2 návštevníků

cron
Reputation System ©'