diff --git a/app/blog/2015/01/25/.gitattributes b/app/blog/2015/01/25/.gitattributes
new file mode 100644
index 0000000000000000000000000000000000000000..b851ce540b28d239850493b793b49724a739a955
--- /dev/null
+++ b/app/blog/2015/01/25/.gitattributes
@@ -0,0 +1 @@
+*.{jpg,JPG,png,PNG,JPEG,jpeg,gif,GIF,webp,pdf,svg,SVG,mp4,pdf} filter=lfs diff=lfs merge=lfs -text
\ No newline at end of file
diff --git a/app/blog/2015/01/25/halozati-atalakitas.md b/app/blog/2015/01/25/halozati-atalakitas.md
new file mode 100644
index 0000000000000000000000000000000000000000..f282d49a00622f872d90cc57e0e6c1f570834fae
--- /dev/null
+++ b/app/blog/2015/01/25/halozati-atalakitas.md
@@ -0,0 +1,73 @@
+---
+slug: halozati-atalakitas
+title: Hálózati átalakítás
+authors: kovax
+tags: []
+---
+
+A január 30-i hétvégén egy nagyobb méretű átalakítást tervezünk a Schönherz hálózatában. Az átalakítás célja, hogy növeljük a hálózat teherbírását és rendelkezésre állását. Ebben a cikkben bemutatjuk az átalakítás okait és későbbi hatásait – Kovács Dániel, a Netikai Bizottság elnökének cikke.
+
+<!--truncate-->
+
+Első lépésként tekintsük át a jelenlegi hálózati eszközparkunkat és topológiánkat. Egy nagyobb telephely, épület vagy irodaház hálózatának tervezését bizonyos konvenciók mellett szokás végezni. A Cisco (aki az eszközeink túlnyomó többségének gyártója) egy ún. Enterprise Campus architektúrát ajánl, amelyben 3 réteget különböztet meg: Core, Distribution és Access. Az Access rétegben találkozik a felhasználó a hálózattal, a Distribution és Core layer pedig aggregálja és megfelelő helyre osztja el a forgalmat. Mivel a Schönherz hálózati szempontból – legalábbis nagyvállalati szemmel nézve – nem nagy, ezért ennek az architektúrának egy speciális változatát, az ún. Collapsed Core architektúrát használjuk, amely azt jelenti, hogy a Core és Distribution layereket ugyanazon eszköz szolgálja ki.
+
+A rövid bevezetés után térjünk rá a tényleges hálózatunkra, először az eszközpark ismertetésére.
+
+## Core és Distribution eszközök (a KSZK-ban találhatóak)
+
+rtr-1
+
+Egy Catalyst 6504-E tipusú Layer3-as switch (ami azt jelenti, hogy egy router feladatait is el tudja látni). Rajta keresztül egy 10GBit/s-os, egymódusú üvegkábelen keresztül érjük el a BMENET-et és azon keresztül a külvilágot. Legnagyobb terhelés mellett 5000W-ot fogyaszt. Ezt a verziót 2005 májusában kezdték el árulni. 18 db 10Gbit/s-os optikai csatlakozója van, illetve 3 db 1Gbit/s-os Ethernet a management számára.
+
+rtr-2
+
+Egy Catalyst 6506-os eszköz, 1999-ben kezdték gyártani, 36 db 1Gbit/s-os portja van. Jelenleg ez szolgál backup routerként, a Schönherz és a BMENET között két darab 1Gbit/s-os egymódusú üvegkábellel.
+
+sw-tk
+
+Egy 3560E-24PD eszköz. A 3500-as széria a 4500 és 6500 mellett a legkisebb L3-as switch. 28db 1Gbit/s-os Ethernet porttal és 2 db 10Gbit/s-os multimódusú optikával rendelkezik.
+
+## Access eszközök (a szinti rendezőkben találhatóak)
+
+sw-{02,05,08,11,14,17} (azaz három szintenként egy)
+Catalyst 4506-E tipusú switchek. Egyenként 244 db 1Gbit/s-os Ethernet portot tartalmaznak, amelyekre a kollégisták csatlakozhatnak a fali aljzatokon keresztül, van továbbá 2 db 10Gbit/s-os multimódusú optikai portjuk. A switchek 2 db 10 Gbit/s-os optikán csaltakoznak rtr-1-hez, illetve 2 db 1Gbit/s-os rézkábelen rtr-2-höz.
+
+## Szervertermi eszközök
+
+sw-server-{01,02}
+
+2960S-48TD-L-es switchek, 48 db 1Gbit/s-os Ethernet porttal és 2 db multimódusú, 10Gbit/s-os optikával.
+
+Tekintsük ezután a topológiát
+![](topology_b.jpg)
+_Jelenlegi topológia (piros: elsődleges, zöld: backup)_
+
+A jelenlegi topológiának több hibája is van. Nem mindenhol követi a szabványos kialakítást, emiatt vannak olyan eszközök, amelyek nincsenek redundánsan összekötve. A következő átalakításokat szeretnénk elvégezni:
+
+- Mivel rtr-2 egy igen régi eszköz, gyengébb, mint sw-tk, ezért rtr-2-t szeretnénk sw-tk vasával kicserélni. sw-tk eddig főleg a telefonközpontban található eszközöket (szervereket, wifi AP-kat, telefonokat) látta el, ezért még nyáron beszereltük sw-kszk-t, ami egy szinti 4500-öshöz hasonló switch, de egy kicsit régebbi változat. 4\*48 db 1Gbit/s-os porttal rendelkeik, így sw-tk-t megfelelően tudja helyettesíteni.
+- sw-kszk elsődleges linkje rtr-2 felé legyen, a backup linkje pedig rtr-1 felé. Felmerülhet a kérdés, hogy miért nem fordítva: azért nem, mert rtr-1-ben már csak 1 db 1 Gbit/s-os optikai port maradt, rtr-2-n keresztül viszont sokkal nagyobb sávszélességet tudunk elérni.
+- sw-salgo-rack és sw-salgo esetében szeretnénk, ha nem egymásba lennének kötve (elkerülve a daisy chaininget), illetve jó lenne, ha mindegyiknek lenne egy backup linkje is. Mivel rtr-1 ben már nincs szabad csatlakozás, rtr-2-be pedig nem érdemes kötni, mert spagetti architektúra jönne létre, ezért sw-server-01-be és sw-server-02–be fogjuk őket csatlakoztatni.
+- Végül szeretnénk sw-server-01-et és sw-server-02–t összekötni egy 1 Gbit/s-os ethernet kábellel. Áramszünet esetén rtr-1 és rtr-2 szünetmentes tápja körülbelül 10 percet bír, viszont a szervertermi szünetmentesek akár 30-40 percet is, így a két switch közti kommunikáció akkor sem szakad meg, ha a teljes telefonközpont leáll.
+
+Ha mindent megfelelően kötöttünk át, akkor egy sokkal átláthatóbb, magasabb rendelkezésreállású és hierarchikus hálózatot fogunk kapni:
+
+![](topology_a-1024x665.jpg)
+_Új topológia (piros: elsődleges, zöld: backup) – itt rtr-2 szerepét már a régi sw-tk vasa tölti be_
+
+A topológia rendberakása mellett szeretnénk a jelenlegi STP beállításokat is szinkronizálni az eszközök között. Az STP (Spanning Tree Protocol) felel azért, hogy a hálózatban ne alakulhasson ki kör, például ha egy kollégista összeköt két feliportot, akkor az STP segítségével a switch az egyik portot letiltja, így nem döglik le a hálózat.
+
+A következőkhöz vezessük be a VLAN-ok fogalmát. A VLAN-ok segítségével el tudjuk különíteni az egyes hálózatokat, úgy, hogy azok mégis egy eszközön futnak, egy fizikai hálózaton mennek keresztül. Ez mind biztonsági szempontból, mind a teljesítmény szempontjából hasznos, hiszen ahelyett, hogy a teljes kollégium egy hálózaton lenne, a VLAN-ok segítségével külön alhálózatokra lehet bontani. Többek között ezzel kerüljük el, hogy a broadcast forgalom legyilkolja a kollégisták által üzemeltett AP-kat. Egy ilyen VLAN például a 182-es VLAN, ahol a 15.-en és 16.-on lakó kollégisták vannak, IP címük pedig 152.66.182.XYZ formájú.
+
+Mivel jelenleg több mint 50 VLAN található a hálózatban, ezért az STP az eszközökben legalább 50 feszítőfát építene ki feleslegesen. Ennek megoldására az STP egyik összetettebb változatát, az MSTP-t használjuk (Multiple Spanning Tree Protocol). Ennek fő funkciója, hogy csoportosítani lehet vele a VLAN-okat, így végül 3 nagy csoportot hozunk létre:
+
+- kollégista VLAN-ok, amik csak az épület felső (lakó) részében,
+- szervertermi VLAN-ok, amik csak a szerverteremben,
+- vegyes VLAN-ok, amik mind a két helyen megtalálhatóak.
+
+Így, a VLAN-okat 3 nagy csoportra osztva, végülis csak 3 fára van szükség: egy a kollégistáknak, egy a szerverteremnek, és egy azoknak a VLAN-oknak, amelyek mindkét helyen megtalálhatóak.
+
+A jelenlegi MSTP beállításainak optimalizálásával elérhetjük, hogy ha a topológia valamilyen okból kifolyólag változna (akár link hiba, akár szándékos megszakítás miatt), akkor csak a szükséges VLAN-okhoz tartozó feszítőfákat kelljen újraszámolni.
+
+Hogyan fog mindez zajlani? Pénteken délelőtt kezdünk: behúzzuk a szükséges extra kábeleket, kifejtjük, véget szerelünk. A szervertermi rackek kábelezését kicsit átdolgozzuk, hogy szebben nézzen ki, illetve ugyanígy rendbe rakjuk a salgós gépeket is. Következő lépésként beállítjuk az eszközökön az MSTP-t, hogy az átalakítás során a kábelek ki-be húzkodása a lehető legkisebb kieséssel járjon. Ezzel párhuzamosan megkezdődhet rtr-2 kiszerelése és sw-tk beszerelése, majd konfigurálása.
+
+Igen sok feladatunk lesz, de várhatóan szombat estére végzünk a nagyjával. Mindig szívesen fogadjuk az érdeklődőket, illetve a segítő kezeket a Schönherz 105-ös szobájában.
diff --git a/app/blog/2015/01/25/topology_a-1024x665.jpg b/app/blog/2015/01/25/topology_a-1024x665.jpg
new file mode 100644
index 0000000000000000000000000000000000000000..5d6631238f24ecc216a14b6df17a989602b0a317
--- /dev/null
+++ b/app/blog/2015/01/25/topology_a-1024x665.jpg
@@ -0,0 +1,3 @@
+version https://git-lfs.github.com/spec/v1
+oid sha256:2f5a4f69562ff6c11e3893911de2eca3d24c7d00683726b440329bb50d2be6de
+size 135065
diff --git a/app/blog/2015/01/25/topology_b.jpg b/app/blog/2015/01/25/topology_b.jpg
new file mode 100644
index 0000000000000000000000000000000000000000..1e7c637c9501d74e40d987bc8a0dda7d855e811f
--- /dev/null
+++ b/app/blog/2015/01/25/topology_b.jpg
@@ -0,0 +1,3 @@
+version https://git-lfs.github.com/spec/v1
+oid sha256:230fbafff6b1bd32082b7f47fd85779d4e96b3a85821da2cecec22a07d1b418c
+size 101366