Navigacija
Lista poslednjih: 16, 32, 64, 128 poruka.

Mikrotik u Wireless ISP-ovima

[es] :: Wireless :: Mikrotik :: Mikrotik u Wireless ISP-ovima
(TOP topic, by djricky)

[ Pregleda: 2847 | Odgovora: 15 ] > FB > Twit

Postavi temu Odgovori

Autor

Pretraga teme: Traži
Markiranje Štampanje RSS

dragansar
Sarajevo

Član broj: 84903
Poruke: 612
*.customer.blic.net.

Sajt: https://nf-tel.com


+22 Profil

icon Mikrotik u Wireless ISP-ovima15.10.2018. u 12:54 - pre 66 meseci
Pozdrav Mikrotik-netork forumaši
Evo jedan vodič za sve one koji još guraju svoje lokalne Wireless provajdere na Mikrotik platformi i kako stvari stoje, manje sredine će još neko vrijeme sigurno i koristiti usluge Wireless provajdera. Iz iskustva vidim da neki provajderi još rade i pružaju usluge u Bridge-ovanim mrežama sto je jako loša varijanta za bilo kakav stabilan rad i uopšte rad , a neki rade u konbinaciji servisa o kojima će biti riječi ispod.Nekome će sigurno biti od koristi da uporedi svoju infrastrukturu sa ovim, a možda će neke kolege i nešto novo dodati kao prijedlog na temu. Ja sam prije 4-5 godina radio u manjem provajderu koji je bio „bridžovan“ i posle ove reforme mreže stvari su stvarno radile super i zadovoljavajuće tako da iz iskustva predlažem ovaj model. Neki korisnici će možda misliti da je ovo previše informacija na gotovo, ali onaj ko hoće da nauči nešto svakako će to učiniti i bez ovoga, bitna je želja...ovde će samo dobiti smjernice i možda neke nove stvari koji nisu znali...a ostali nesebični će se možda nadovezati sa svojim iskustvima vezano za temu
Ja sam svakako kroz vrijeme dobio puno informacija sa ovog foruma od dobrih ljudi, pa red je da se odužim svakako.

Kad se pomene termin ISP prvo na šta me asocira je neki državni telekom, DSLAM, telefonska parica i ADSL ili kablovski operater, DOCSYS i ostalo...iza toga Cisco/Juniper switcing i routing infrastruktura....BGP, MPLS, OSPF...uglavnom Enterprise network i milioni opreme...naravno ima se i moze se
Inace praksa velikih ISP-ova je bila da vremenom kupuju manje provajdere i uvlače ih u svoju infrastrukturu (ovo sam i licno preživio) i bio sam mišljenja da su skoro već sve pokupovali, ali koliko vidim da još postoji zavidan broj tih nazovi manjih provajdera kojima će ovaj post predpostavljam možda biti od koristi.
Kroz rad i iskustvo sa vlasinicima ovakvih ISP-ova često sam primjetio da ljudi pokušavaju da zarade nešto sredstava za život i bolju egzistenciju i krenuli su sa tim poslom, neki sami, nekima je neko pomogao pa su nastavili...ali je u većini slučajeva rađena neka jednostavna varijanta mreže koja je posle nadograđivana...pa je bila mijenjana vremenom na bolje...koliko je ko uspio da se angažuje i edukuje u međuvremenu.I ja sam uz određenu edukaciju sam prošao ovaj put i razmjenio iskustava sa korisnicima ovog foruma, sa nekim i danas sarađujem...pa sam mišljenja da mogu u nekoj mjeri pomoći ekipama koje guraju i dan danas ISP na Mikrotiku! Mišljenja sam i da je MT idealno riješenje za ovako manje mreže korisnika...tj razruđenje mreže gdje se vi probijate Wireless linkovima kroz manja naselja, sela, planine i slično jer korisnika interneta kao što vidimo ima svugdje.Mislim da je na ovu temu napisano puno različitih postova što se tiče same konfiguracije i problematike vezano za istu temu, ali ja ću pokušati da napravim jedan presjek svega i iskomentarišem šta je po meni dobro a sta loše i zašto bi trebali neke stvari da koristimo a zašto ne. Naravno malo sam pretražio dali postoji slična tema i nisam uspio naći , znam isto kada sam ja tražio i sklapao sliku da nisam nikad imao ništa na gotovo, nego sam morao kroz muku da guram dalje, testiram i na kraju dolazim do idealne postavke i logike...naravno neću pominjati konfiguraciju nego samo bitne stvari.
Da definisem samo pojam koji ću često pominjati L2 domen tj Layer 2 OSI-modela ili Data Link Layer; Tj isti brodcast domain u mreži ili isti Bridge.

BRIDGE

Većina mreža kod Wireless provajdera je počinjala sa jednom baznom stanicom i onda se širila dalje postepeno...kako se širila tako se i bridžovalo sve sa svim u nedogled
Ako neko pita zašto nam uopšte treba taj bridge ili ti L2 komunikativnost?...razlog je naravno PPPoE (Point-to-Point Protocol over Ethernet), jer da bi klijent mogao da dobije IP parametre sa kojima će moći da izađe na internet potrebna nam je L2 komunikativnost klijenta i PPPoE servera.
E sad šta je loše kod veće mreže koja je sva u bridge-u? Loše je što nema nikakve segmentacije na tom L2 domen tj svi hostovi su istom bridg-u i ponašaju kao da su prikopčani na jeden veliki switch! Pošto slika govori 1000 riječi evo jedan primjer ispod na slici:

Imamo npr 4 bazne stanice na koje su prikopčana po 4 wireless korisnika i recimo gledamo samo šta se dešava kada korisnik 1 i korisnik 2 pokušaju da iniciraju komunikaciju sa PPPoE serverom, tehnički klijent koji inicira PPPoE sesiju prvo što će da uradi je da pošalje brodcast paket PADI (PPPoE Active Discovery Initiationu) u čitavu mrežu u nadi da će naći server i da će mu on odgovoriti...naravno pošto on ne zna putanju gdje se taj server nalazi...paket će se poslati na sve strane i doće do svih! Ovde je samo naškraban pokušaj komunikacije 2 host-a u plavoj i roze boji. Svaki Brodcast koji se pojavi se zavrti ovako po čitavoj mreži i ne možemo da ga kontrolišemo jer dolazi sa svih strana jer se naravno širi u istoj L2 domeni.Koje su npr loše stvari u ovakvoj situaciji...evo par primjera:
*Neko od korisnika može da lažira svoj PPPoE server i onda će se korisnici koji su bliži njemu pokušati na njega da konektuju tj uće u priču sa njim.
*Korisnici na različitim djelovima mreže mogu da sebi definisu IP adrese iz istog opsega i naravno komuniciraju...tj koriste vaše resurse mreže bez problema...igraju igrice, razmjenjuju fajlove
*Naravno vjerovatno će u windows-ima vidjeti neighbors kompjutere
*Kad imate neki problem na mreži nemate mogućnost praćenja putanje i segmentiranja lokacije problema, jer sve je nazovi u jednom. Ovo sam samo naveo par banalnih primjera...da ne ulazimo sad u dalje u security mreže koji u ovoj varijanti i ne postoji...tj neki klinjo vam može sa par programčića i par klikova oboristi mrežu  Ovo sad sve izgleda kao vraćanje u prošlost ali ja znam provajdere koji još rade u ovakvom okruženju...nije mi jasno kako ali rade! Pitanje je sad naravno šta treba uraditi?...paaa trebalo bi segmentirati mrežu na L2 nivou, tj napraviti više „bridge-eva“

RUTIRANJE STATIČKO ILI DINAMIČKO?

Što se tiče adresiranja, kada smo imali mrežu u bridge-u onda je sve bilo u jednoj mreži, npr 192.168.0.0/20 (4096 adresa iskoristivih) i nije bilo potrebno rutiranje...sada kada mrežu počnemo segmentirati, svaki segment će imati svoju podmrežu.Naravno sve te mreže bi trebalo da budu dostupne između sebe i potrebna nam je rutiranja mreža.
Sledeća nedoumica je dali raditi statičko ili dinamičko rutiranje? Iz perspektive rutera njemu je bitno da ima rutu do destinacije, pa sad dali će ona biti dinamička ili statična bitno je da ima  ali iz vaše perspektive...ako uzmemo u obzir da su ovakve mreže rađene po principu da vi linkove postavljate svuda, i da se probijate po raznim oblastima, brdima i slično...pa se onda negdje trasa odvaja lijevo i desno po potrebama...onda zamislite da morate svaku rutu definisati ručno...i svakom ruteru govoriti gdje mu se koja mreža nalazi...mislim da je ovo jako bolno i nepotrebno...u praksi vidim da neki ljudi imaju problema sa određenim linkovima, tj da im određene rute pucaju kada koriste dinimičke ruting protokole, pa u takvim slucajevima koriste statičke rute...ali ovde mislim da bi prije trebalo razlog problema tražiti u samom linku. Rezime je da su ljudi da bi nam olakšali čitavu priču napravili dinamičke ruting protokole i ne vidim razlog zašto ih nebi koristili...tj treba da ih koristimo! Za interni ruting protokol je svakako najbolja opcija OSPF (Open Shortest Path First); MT može raditi i sa Eksternim ruting protokolima kao sto su BGP, ali u većini slučajeva manji provajderi su Customer-i od nekog većeg nadprovajdera koji je statički usmjerio određen broj javnih IP adresa prema nama i to je jedini izlaz prema internetu i tu se priča završava...što je u neku ruku i dobro jer ne moramo da se brinemo i o toj infrastrukturi koja je svakako malo zahtjevnija u svakom smislu.

OSPF

OSPF (Open Shortest Path First) je Link State ruting protokol (kao i Cisco IS-IS) tj prati stanje linka u slobodnom prevodu u odnosu na Distanc Vector kao sto su RIP gdje se prati vektor udaljenosti. OSPF je svakako priča za sebe i treba se upoznati sa njim kako radi i zašto...ali pokušaću u kratkim crtama presjek napraviti.

OSPF ima isto svoju segmentaciju tj svoje areje. Area0 ili backbone area je centralna i svi ruteri u njoj imaju rute svih destinacija u čitavoj topologiji (crvena na slici), ostale areje su naslonjene na nju i ako su tipa STUB one će imati samo rute svoje Areje (Ljubičasta area20 i plava area10)
tj u praksi, ako npr imamo jedan krak mreže koji se probija preko brda i dolina kroz nekoliko hop-ova to će biti Area10 i ruteri u tom kraku će imati samo rute iz svoje Area10 (172.16.0.0/24) i default rutu putanje prema svojoj Backbone areji (tj ruter 8 prema izlazu rutera 7 a ruter 7 prema izlazu rutere 2)...samim tim rutere u area10 ne opterećujemo njihove ruting tabele sa nepotrebnim rutama ostalih area...jer u većini slučajeva ćemo u tom segmentu mreže imati hardwer koji treba malo da prištedimo i svakako nema potreba da ima pojedinačne rute ostalih mreža. Ako planiramo dizajnom da svaka area u svom daljem grananju ima mrežu /24 tj ako nam je dovoljno 256 adresa onda možemo na tačkama A i B uraditi sumiranje ruta, tj da ruteri 1 i 2 imaju jednu sumarnu rutu npr 172.16.0.0/24 za Area10 umjesto x pojedinačnih ruta koje se nalaze u njoj (dobra optimizacija ruting tabele na ruteru 2)
OSPF-u je potrebno da na svakom ruteru samo definišemo koje su to rute koje su direktno spojene na njega (na slici uvećana topologija rutere 7...172.16.0.0/30; 0.4/30; 0.8/30 i 0.16/30) i on će ostalo da odradi sam...tj te rute da propagira svima dalje u mreži. Mislim da je ovo mnogo lakše i elegantnije nego da moramo mi ručno definisati rute za svaku mrežu + kad se desi promjena toplogije OSPF će skoro sve uraditi sam...skoro
Dobra stvar gdje još možemo iskorititi OSPF na efektan način u praksi je ako npr imamo lokaciju koja nam je jako bitna i zahtjeva puno protoka kao napr na slici ispod tj ruter 6; možemo postaviti 2 linka od rutera1 tj A i B + C i D...ovde će po defaultu OSPF da radi Load Balansing, tj da ravnomjerno rasporedjuje saobraćaj na obadva link-a...ovo iskorištavamo kao duplo povećanje linka i imamo Failover, tj ako neki od linkova otkaže npr A i B automaki sav saobraćaj preuzimaju C i D.
Isto možemo u topologiji mreže praviti redurancije gdje god nam to treba i osigurati reduranciju čitave mreže. Uglavnom OSPF može svašta da radi...ali ga svakako treba detaljno izučiti 


CENTRALNI PPPoE

Neki wireless provajderi podižu na svakoj lokaciji tj baznoj stanici PPPoE server i tu se korisnici autentifikuju, ako to radimo onda dodatno hardwerski opterećujemo tu tačku (ovo zavisi kako limitiramo korisnike dali samo simple queues ili jos dodatno koristimo i burst)...ako koristimo NAT onda još dodatno tereta...a ako koristimo javne IP adrese onda uvijek moramo imati određen broj adresa rezervisanih samo za tu tačku...plus moramo rutirati dodatno javnim IP adresama i samu baznu stanicu...kad sve bacimo na papir trošimo puno javnih IP adresa koje nam danas daju na kašičicu...jedina pozitivna stvar ovde je sto imamo L2 domenu na samoj baznoj stanici koja nam je potrebna za PPPoE.
Mnogo bolja varijanta je da radimo centralni PPPoE server, jedan ili više njih zavisno od topologije mreže i potreba, gdje ćemo imati uvijek ekonomičnu raspodjelu javnih IP adresa...imaćemo jedan jači i ozbilljniji ruter, nekada neka 1000 serija a danas neki CCR. Naravno da bi PPPoE radio moramo imati isti L2 domen izmedju korisnika i PPPoE servera. U praksi to bi značilo da na svakoj fizičkoj lokaciji imamo jedan MT router koji ima neki L2 tunel sa PPPoE koncetratorom i kroz taj tunel korisnici ostvaruju pppoe broadband konekciju i dobijaju javnu IP adresu. Praksa je da neki provajderi NAT-uju korisnike, sto i nije baš dobra opcija i za korisnika a i za provajdera...provajder mora dodatno da koristi resurse da NAT-uje svakog korisnika, a korisnik nema javnu IP adresu sto mu dalje prouzrokuje niz ograničenja. Obično ISP ovi koji uzimaju UP-LINK od ozbiljnijih nadprovajdera uvijek i dobiju dovoljan broj javnih IP adresa.

L2 TUNELI

Kao što smo rekli gore, da bi PPPoE radio potreban mu je isti L2 domen. Ako imamo rutiranu mrežu i bazne stanice onda svakako nemamo L2 komunikaciju sa centralim PPPoE koncetratorom i treba da je napravimo  Prvi izbor bi svakako bio EoIP (Ethernet over IP) tunel, to je Mikrotikov protokol koji kreira Ethernet tunel između 2 rutera koristeći IP protokol.Jednostavo ga je konfigurisati i sa strane koncetratora na njemu podignemo PPPoE i sa strane bazne stanice stavimo u isti bridge njega i kartice od baznih stanica i korisnici će se uredno konektovati. Isto možemo uraditi i sa bilo kojim L2 tunelom, kao sto je npr L2TP ili ti VPLS. Detaljnije o VPLS-u u nastavku. Još jedna važna napomena, kada podignemo L2 tunel sa strane koncetratora on se završava direktno na njemu...a sa strane bazne stanice on će se završiti recimo u bridge-u PPPoE...dalje ćemo u taj bridge ubaciti WLAN kartice od bazne stanice i sve portove koji treba kroz koje dolaze korisnici...i ovde obavezno trebamo koristiti bridge filter koji će samo da propusti pppoe-discovery i pppoe-sesion na IN strani...a zabranimo ostale protokole kao što su IP, ARP...tako da dobijemo od korisnika do PPPoE koncetratora čistu liniju kojom može samo proci PPPoE protokol i to je to...sve ostalo što bi se pokušalo se odbija odmah na tom bridge-u i naš core dio mreže je zastićen!

MPLS/VPLS

Kada se pomene termin MPLS (Multi Protocol Label Switching) znamo da se radi o Enterprise network-u. Kada se pojavio na MT-u nisam bas primjetio da ga je neko koristio kod nas. Ja sam prije 5-6 godina radio u jednom ISP-u i testirao sam razliku između EoIP tunela i VPLS tunela i stvarno bio prezadovoljan dobijenim rezultatima. Posle toga je čitava mreža prebačena na MPLS koji je osnovica za VPLS tunele i stvari rade super i mnogo bolje. Napredniji korisnici i ISP-ovi ove vrste vidim da su počeli koristiti isto. I super je stvar da se MPLS može koristiti na MT-u mimo Cisco-a i Junipera.
Da razjasnimo malo priču oko MPLS-a
Ako gledamo po OSI modelu kako se odvija komunikacija vidimo:
LAYER2 (Data Link) ili nivo na kojem radi switc i bridge, na tom nivou je podatak FRAMES i switc jako brzo preusmjerava Frejmove, tj imamo veliku brzinu ali taj domen ne može da bude veliki...jer tad nailazimo na probleme velike L2 domene kao što je problem u wifi mrežama koji smo pominjali gore.
LAYER3 (Network) ili nivo na kojem rade ruteri i svi L3 interefejsi (tj oni koji imaju IP adresu)...na ovom nivou je podatak PACKET...Paket se sporije preusmjerava od Frejmova jer mora da prođe kroz svaki ruter, da se raspakuje, da se pogleda ruting tabela gdje ide, pa da se dalje zapakuje i pošalje dalje...ali prednost u odnosu na Frejm je što paket možemo poslati daleko dalje kroz IP mrežu.
Idealna konbinacija je kada bi imali varijantu koja bi konbinovala prednosti obadvoje, što u stvari i jeste MPLS, tj on radi između LAYER2 i LAYER3 OSI Modela i može se reći da je LAYER2.5 Tj on koristi IP na koji kači svoje LABEL-e i na osnovu njih preusmjerava saobraćaj, tj za svaku rutu napravi label i onda kada paket dođe on ne gleda ruting tabelu nego odmah ima label spreman za nju i preusmjeri paket tamo gdje treba. Poenta svega je da koristeći MPLS dobijem preusmjeravanje paketa brzinom skoro identičnom kao kod brzine preumjeravanja Frejmova na Data Link nivou tj LAYER2...
VPLS je L2 tunel koji radi na MPLS mreži i korištenjem njega dobijamo mnogo brže usmjeravanje paketa nego korištenjem običnog EoIP tunela. Naravno da bi koristili VPLS potreban nam je MPLS, a da bi koristili MPLS potrebna nam je rutirana mreža tj u našem slučaju OSPF.

RADIUS

Mislim da bi svaki radius trebao da odradi posao, ali jedna od free varijanti koja radi super je daloRADIUS i to u konbinaciji sa Debian Linux-som na kojem radi najstabilnije, sta sam god zamislio da uradim sa njiim može i radi. Još se puno koristi i DMA Labsoft (plaća se licenca nesto oko 100 dolara) Ako vam radius npr nema riješeno da kada isključite korisnika koji ne plaća da dobije poruku...možete to uraditi na način da podignete na PPPoE koncetratoru web proxy, da podesite profil na radiusu da ti isključeni dobijaju adrese iz određenog pool-a koji ćete posle podesiti da je dostupan po IP-ju na vašem PPPoE i uraditi da se sve stranice koje se otvore preumjeravaju na vaš page na tom koncetratoru gdje će pisati...UPLATI INTERNET!!! Možete i preurediti taj index koji se pojavljuje tipa da stavite neku grafiku i konvertujete ga u image base64 code pošto Mikrotik nema http na sebi da prikaže i slike. Dobro je naravno da vas korisnici ne zovu i deru se na vas misleći da je kvar a u stvari su dužni 

LOG-ovi

Sigurno će doći trenutak kada će vam nadležni organi tražiti podatke o korištenju određene IP adrese u nekom intervalu, što im po zakonu svakako morate obezbjediti i u određenom intervalu čuvati logove od svih konekcija. Sada još mimo toga (u BIH) prave varijantu da se sav saobraćaj može presretati i nadgledati u svakom trenutku i pritežu provajdere da moraju i to implementirati. Zavisno od radius-a i Billing-a koji imate, tj dali je on podešen da čuva određene logove, svakako nije loša stvar prebaciti taj dio posla na poseban server koji će samo to da radi...jer nije baš dobro radius zatrpavati sa tim stvarima koje su sekundarne u odnosu na ono sto radius radi...pogotovo ako se prate i NAT-ovani korisnici. Vidim da ljudi koriste Dude kao syslog server i na njega šalju log-ove ali ni dude nije pravljen da primarno radi kao sys log nego kao monitoring i sve logove pakuje lokalno u fajl pa onda imamo problem što ti fajlovi veoma brzo postanu veliki i potrebno ih je stalno negdje skladištiti...posle im se malo teže pristupa i sl...Riješenje koje je dobro je Rsyslog koji radi na Linux-su i koji dalje puni MySql bazu. Te logove dalje možemo pregledati sa LogAnalyzer-om koji je web interfejs za njega. Potreban nam je još apache i php. Sa koncetratora šaljemo Account-logove i to je to. Što se tiče praćenja NAT-ovanih korisnika tu je malo priča komplikovanija, pošto oglašavamo više korisnika preko jedne javne IP i sam NAT će raditi translaciju svake konekcije sa kačenjem random port-a, da bi posle znao u povratku koju će konekciju gdje da vrati unutar NAT-a. Ovde već moramo na MT-u pratiti connection tracking pa onda to kao info log slati na Syslog...uglavnom 1000 i više veći log kod NAT korisnika nego kod korisnika koji imaju javnu IP. Sa NAT-om je uvijek problem :/

BACKUP

Kako vam mreža postaje komplikovanija sa više setup-a na ruterima + ako imate AccessListe na AP-ovima sa komentarima za korisnike i naravno PPPoE koncetratore...onda je svakako dobro da imate backup i exsport od tih ruter-a...jer desiće se da nešta od opreme prestane sa radom i mora se zamjeniti. Najbolja varijanta je da napravite Scheduler koji ce praviti exsport i backup svaki dan (ili svakih 7 dana). Podignete FTP servis, kreirate user-a koji može samo FTP koristiti i imate onda sa strane kupite te backupe periodično. Ja sam to nekad radio sa Linux Batch Scrpt-om, da se kačim u određeno vrijeme na baznu FTP-om i povlačim fajlove i dalje arhiviram i skladištim...možete i na jednostavan način koristiti Cobian Backup mali win program kojem napravite isto Scheduler za svaku baznu stanicu i on će sam kupiti backup-e.

MONITORING

Ako nas zove korisnik i žali se na problem onda je to loša opcija...dobra opcija je ako mi prije korisnika saznamo da postoji problem i naravno riješimo ga...to možemo samo ako imamo dobro organizovan Monitoring. Naravno ako koristimo Mikrotik onda je neizbježno da koristimo i njihov Dude, što je svakako i oke opcija. Doduše malo su ga traljavo uradili, ova zadnje verzija je još uvijek beta, tako da je stara 3.6 sasvim oke. Povukli su ga kao paket na rutera što je bila zgodna stvar da tu stoji pa da se klijenti kače...nezgodno je kada je instaliran samo kao klijent na win računaru, pa posle uvijek neke reinstalacije i sl...ja sam to riješavao da podignem na nekom od servera virtuelnu mašinu sa windows-om samo za njega i da se ostali klijenti kače...i to je bilo dobro konbinovano riješenje. Nervira me i jako je neuredno kada u Dude samo onako nabacamo bazne slučajnim redosledom...i tu treba neko da se snađe?! Ja sam uvijek ispod kao sliku imao mapu lokacije pa preko nje dodavao uređaje...rutete označim drugim ikonicama, linkove i AP-ove isto. Dobro je koristiti i SNMP da sve linkove ubacite na praćenje...da im date limite...pa da kada ima određeno protoka taj link crveni i slično...dodavao sam i ICMP na rutere u slučaju većeg odziva su mijenjali boju...tako da sa samim ulaskom u 2-3 sekunde mogu da vidim dali je sve oke i gdje treba da obratim pažnju.
Naravno nećemo nikada sjediti pored računara i čekati da nešto pocrveni da bi reagovali, tako da je potrebno i da imamo info u realnom vremenu ako se desi neki ispad bazne ili lokacije. Pomoću mikrotikovog Netwatch-a možemo pratiti sve bitne lokacije i u slučaju nekog ispada ili vraćanja u mrežu možemo pokrenuti skriptu koja će nam dalje poslati mail sa porukom šta je DOWN ili UP. Dalje taj mail preko raznih opcija Email to SMS možemo poslati SMS tako da u svakom momentu imamo info o eventualnom ispadu...predpostavka je da se ne odvajamo od mobilnih telefona 
Često se dešava da korisnici pomjere svoju klijentsku antenu ili je vjetar pomjeri i sl...na svakom AP-u (ako je Mikrotik naravno) možemo skriptom definisati minimalne signale i ako neko od korisnika pređe taj prag da skripta pošalje mail i mi odemo kod korisnika i namjestimo antenu.
Veoma bitan faktor je koliko protoka ide na koju stranu i koliko su nam određeni linkovi opterećeni...radi daljeg planiranja, proširenja i slično. Za ovu svrhu mislim da je najbolji izbor Cacti, koji će preko SNMP-a da prati sve interefejse koje mu kažemo, da crta grafike i da imamo tu stanje tačno za pregled. Još što je bitno da možemo na isti način da pratimo i latencije lokacija...i ostale parametre MT-a...u biti sve možemo pratiti  Dobra opcija monitoringa je i Nagios za one naprednije ko ima vremena i znanja da se upusti i u njega 

Toliko od mene, nadam se da će post nekome pomoći, razjasniti određene stvari i možda nekoga natjerati da počne razmišljati o prekonfiguraciji mreže.





Šaka
 
Odgovor na temu

bmarkovic06

Član broj: 301412
Poruke: 716



+66 Profil

icon Re: Mikrotik u Wireless ISP-ovima15.10.2018. u 14:22 - pre 66 meseci
Svaka cast kolega, sve si ok napisao :).

Posle duzeg vremena rada i razgovora sa kolegama primetio sam da niko osim nas dvojice (barem jos nisam upoznao provajdera manjeg obima) ne koristi MPLS a ja i ti smo to radili koliko se secam i pre 5-6 godina. Mislim ja sam celu ideju prepisao od tebe :).

Eto posle toliko godina MPLS radi smo bolje i bolje. Odlicna stvar da ne trosite javne adrese, za lakse sirenje i odrzavanje same mreze.

Uz malo organizacije dodavanje novih cvorova, raditi TA i ostale zajebancije postaju cisto zadovoljstvo.


 
Odgovor na temu

bachi
Vladimir Vučićević
System administrator
Beograd, Srbija

Član broj: 17912
Poruke: 5316

Sajt: www.bachi.in.rs


+2826 Profil

icon Re: Mikrotik u Wireless ISP-ovima15.10.2018. u 16:38 - pre 66 meseci
U je, sad bar znam koliko ne znam.
... Vladimir Vučićević aka. Bachi
~~~ www.bachi.in.rs <<<<>>>> [email protected]
>>> It's nice to be important, but it's more important to be nice...
 
Odgovor na temu

DynDNS
Beograd

Član broj: 274168
Poruke: 118
*.dynamic.sbb.rs.

Sajt: juniper.net


+4 Profil

icon Re: Mikrotik u Wireless ISP-ovima15.10.2018. u 17:06 - pre 66 meseci
Pre tridesetak dana sam ovde postavio pitanje ako neko ima iskustva kako radi vpls kampella na mikrotiku u mpls mreži i niko se nije javio sem jednog dečka iz hrvatske.



Podelite sa nama iskustva za ovaj vpls pošto vidim da ga mikrotik podržava a i komforniji je od martinija.


Edit: Vrlo koristan post.

[Ovu poruku je menjao DynDNS dana 15.10.2018. u 18:33 GMT+1]

[Ovu poruku je menjao DynDNS dana 15.10.2018. u 18:34 GMT+1]
 
Odgovor na temu

bmarkovic06

Član broj: 301412
Poruke: 716



+66 Profil

icon Re: Mikrotik u Wireless ISP-ovima15.10.2018. u 20:14 - pre 66 meseci
Pa pisao sam ti ja, imas odgovor na tvoje pitanje. Samo sto ja koristim Martini tip ne Kampella. Odnosno ja koristim Ldp za signaling i distribuciju labela a ne iBgp.
 
Odgovor na temu

bachi
Vladimir Vučićević
System administrator
Beograd, Srbija

Član broj: 17912
Poruke: 5316

Sajt: www.bachi.in.rs


+2826 Profil

icon Re: Mikrotik u Wireless ISP-ovima15.10.2018. u 20:38 - pre 66 meseci
Dajte neki OSPF tutorial ali onako napisan baš za tupsone?
... Vladimir Vučićević aka. Bachi
~~~ www.bachi.in.rs <<<<>>>> [email protected]
>>> It's nice to be important, but it's more important to be nice...
 
Odgovor na temu

dragansar
Sarajevo

Član broj: 84903
Poruke: 612
*.static.corp.blic.net.

Sajt: https://nf-tel.com


+22 Profil

icon Re: Mikrotik u Wireless ISP-ovima15.10.2018. u 21:08 - pre 66 meseci
Citat:
DynDNS:
Pre tridesetak dana sam ovde postavio pitanje ako neko ima iskustva kako radi vpls kampella na mikrotiku u mpls mreži i niko se nije javio sem jednog dečka iz hrvatske.



Podelite sa nama iskustva za ovaj vpls pošto vidim da ga mikrotik podržava a i komforniji je od martinija.


Edit: Vrlo koristan post.

[Ovu poruku je menjao DynDNS dana 15.10.2018. u 18:33 GMT+1]

[Ovu poruku je menjao DynDNS dana 15.10.2018. u 18:34 GMT+1]

Pozdrav @DynDNS
Kompella koristi BGP za signalizaciju za L2 P2P, tako da nije predmet ove teme i generalno sam BGP zaobišao jer većina provajdera ove vrste imaju samo jedan Up Link sa nadprovajderom i nadprovajder statički rutira date rute prema samo jednom smjeru, tj nisam još vidio da je neko podizao BGP peer sa nadprovajderom i da ima više izlaza ili UpLinkova sa istim...naravno jer customera-a tj nas u ovom slučaju to dođe skuplje jer moramo imati jači hardwer da pokupimo sve rute od BGP-a i sl...u biti ja nisam koristio Mikrotik sa MPLS-om u konbinaciji sa BGP-om i ne znam dali bi se i usudio :)
A Martini koristi LDP za signalizaciju i to sam svakako koristio u izvedbi VPLS tunela zajedno sa internim protokolom OSPF-om kao L2 tunel i to svakako radi jako dobro :)
Nadam se da je odgovor kompletan ;)
Šaka
 
Odgovor na temu

dragansar
Sarajevo

Član broj: 84903
Poruke: 612
*.static.corp.blic.net.

Sajt: https://nf-tel.com


+22 Profil

icon Re: Mikrotik u Wireless ISP-ovima15.10.2018. u 21:16 - pre 66 meseci
Citat:
bachi:
Dajte neki OSPF tutorial ali onako napisan baš za tupsone?

Pa najbolje ti je možda da kreneš sa CCNA :) i to sa Jeremy, biće ti jako interesantno ;)



Šaka
 
Odgovor na temu

bachi
Vladimir Vučićević
System administrator
Beograd, Srbija

Član broj: 17912
Poruke: 5316

Sajt: www.bachi.in.rs


+2826 Profil

icon Re: Mikrotik u Wireless ISP-ovima15.10.2018. u 21:17 - pre 66 meseci
Više imam na umu vezano za Mikrotik implementaciju.
... Vladimir Vučićević aka. Bachi
~~~ www.bachi.in.rs <<<<>>>> [email protected]
>>> It's nice to be important, but it's more important to be nice...
 
Odgovor na temu

dragansar
Sarajevo

Član broj: 84903
Poruke: 612
*.static.corp.blic.net.

Sajt: https://nf-tel.com


+22 Profil

icon Re: Mikrotik u Wireless ISP-ovima15.10.2018. u 21:21 - pre 66 meseci
Citat:
Više imam na umu vezano za Mikrotik implementaciju.

@bachi
Ja sam ga naučio na Cisco-u a na Mikrotiku samo nakliktao :-) Ali ako se zaroviš po netu mislim da ćeš naći dobrog materijala svakako.
Šaka
 
Odgovor na temu

Mile-Lile
Beograd

Član broj: 269936
Poruke: 1176
*.ptt.rs.



+79 Profil

icon Re: Mikrotik u Wireless ISP-ovima16.10.2018. u 09:16 - pre 66 meseci
koga zanima ddwrt akoro dodao frr routing https://frrouting.org/

https://svn.dd-wrt.com/changeset/37309
 
Odgovor na temu

bmarkovic06

Član broj: 301412
Poruke: 716



+66 Profil

icon Re: Mikrotik u Wireless ISP-ovima19.10.2018. u 19:07 - pre 66 meseci
Ko ima ovaj video neka ukljuci seed da ja preuzmem pa cu ga ja seedovati do besvesti:

magnet:?xt=urn:btih:71B83BC13A616F6BA1FE0CFBBB87DC385D092A73&dn=MUM_US13__MPLS_for_ISPs_.mp4&tr=http%3a%2f%2ftracker.mikrotik.com%2f
 
Odgovor na temu

nkrgovic
Nikola Krgović
Beograd

Član broj: 3534
Poruke: 2807

ICQ: 49345867
Sajt: https://www.twinstarsyste..


+655 Profil

icon Re: Mikrotik u Wireless ISP-ovima19.10.2018. u 19:19 - pre 66 meseci
Cisto napomenica: IS-IS nije Cisco protokol, i RIP i OSPF i BGP i IS-IS su otvoreni standardi, sve ih podrzava i Quagga - kome se igra, moze sa par VM-ova da istestira sta hoce. Jedino sto je Cisco proprietary (vise-manje) je EIGRP.
Please do not feed the Trolls!

Blasphemy? How can I blaspheme? I'm a god!'
 
Odgovor na temu

DynDNS
Beograd

Član broj: 274168
Poruke: 118
*.dynamic.sbb.rs.

Sajt: juniper.net


+4 Profil

icon Re: Mikrotik u Wireless ISP-ovima24.02.2019. u 21:45 - pre 61 meseci
Grešiš za bgp.

Sa bgp-em možeš bukvalno sve . Niko te ne tera da preko bgp-a učiš ceo internet. Bgp može da se koristi i za druge stvari.
Ti kao provajder interneta možeš na primer jedan interfejs pe rutera nekog provajdera na filipinima ili nekog provajdera u zemlju u kojoj radiš da učlaniš u svoj broadcast domen pppoe servera a da pritom ne razmenjujete tablele rutiranja.
Na taj interfejs nakačiš svoj wifi ap i proširiš svoju provajdersku mrežu.

MPLS je carrier protokol a ne enterprise.
 
Odgovor na temu

dragansar
Sarajevo

Član broj: 84903
Poruke: 612
*.static.corp.blic.net.

Sajt: https://nf-tel.com


+22 Profil

icon Re: Mikrotik u Wireless ISP-ovima25.02.2019. u 22:02 - pre 61 meseci
Pa nisam bas siguran da mozes bas sve :) Zna se gdje ide BGP i zasto...on je eksterni ruting protokol, gdje se god koristi obicno ispod njega je neki interni ruting protokol tipa OSPF, EIGRP, IS-IS... i kao sto pomenuh gore vecina ISP-jeva na MT-u su manji i obicno imaju jedan UpLink sa nadprovajderom tako ga i nisam uzimao u obzir u ovom postu...ali ako mislis da bi se u ovakvom okruzenju mogao iskoristiti svakako pisi :)
Šaka
 
Odgovor na temu

DynDNS
Beograd

Član broj: 274168
Poruke: 118
*.dynamic.sbb.rs.

Sajt: juniper.net


+4 Profil

icon Re: Mikrotik u Wireless ISP-ovima19.07.2019. u 18:54 - pre 57 meseci
Nisi siguran jer razmisljas kao enterprise administrator. Drugacije stvari funkcionisu na carrier opremi.
Jedina slicnost u logici funkcionalnosti enterprise i carrier rutera je vrf lite servis na enterprise ruterima.
Inace stize nam zamena za VPLS kao EVPN koj radi samo na BGP-u a funkcionalniji je od VPLS-a.



EVPN vs VPLS

EVPN vs VPLS – Signaling Protocols
VPLS features two kinds of signaling protocols: LDP and BGP. EVPN, however, adopts BGP as the only one service signaling protocol.

EVPN vs VPLS – CE Multihoming
VPLS only implements single-active solutions. EVPN implements two CE multihoming solutions: single-active (one active, N standby) and all-active (with known uni-cast per-flow load balancing).

EVPN vs VPLS – MAC Learning
VPLS only supports data-plane MAC learning on its local Attachment Circuit (AC), which can easily lead to stale forwarding state. EVPN also performs data-plane MAC learning on its local AC, but it relies on control-plane MAC learning between PEs. This will reduce unknown uni-cast flooding and implement a flush mechanism in BGP.

[Ovu poruku je menjao DynDNS dana 20.07.2019. u 10:58 GMT+1]
 
Odgovor na temu

[es] :: Wireless :: Mikrotik :: Mikrotik u Wireless ISP-ovima
(TOP topic, by djricky)

[ Pregleda: 2847 | Odgovora: 15 ] > FB > Twit

Postavi temu Odgovori

Navigacija
Lista poslednjih: 16, 32, 64, 128 poruka.