Re: [lms] Paczka lms, Tom 64, Numer 10
W dniu 2013-04-07 22:37, lms-request@lists.lms.org.pl pisze:
Wysyłanie wiadomości na listę lms: lms@lists.lms.org.pl
Zapisanie lub wypisanie się przez stronę WWW: http://lists.lms.org.pl/mailman/listinfo/lms
Zapisywanie lub wypisanie się przez email (wyslij wiadomość ze słowem 'help' na adres): lms-request@lists.lms.org.pl
Opiekun listy: lms-owner@lists.lms.org.pl
Odpowiadając na tę wiadomość, zmień jej tytuł na inny niż "Re: Paczka lms...".
Dzisiejsze tematy:
1. Re: zlece napisanie skrypciku generujacego dane z lms do mt (Tomasz Chiliński) 2. Re: Zatwierdzanie danych zmienionych przez panel klienta (Grzegorz Chwesewicz) 3. Re: Zatwierdzanie danych zmienionych przez panel klienta (Piotr Polok) 4. Re: Zatwierdzanie danych zmienionych przez panel klienta (Marcin) 5. Re: Zatwierdzanie danych zmienionych przez panel klienta (Piotr Polok) 6. Re: squid 3 powiadomienia (LoLe) 7. Re: squid 3 powiadomienia (Łukasz Czerepuk) 8. Raport SIISv3 (Sławomir Paszkiewicz)
Message: 1 Date: Sat, 06 Apr 2013 12:48:57 +0200 From: Tomasz Chiliński tomasz.chilinski@chilan.com To: lms@lists.lms.org.pl Subject: Re: [lms] zlece napisanie skrypciku generujacego dane z lms do mt Message-ID: 4e68cdef400855ccda4816e0db090ef9@chilan.com Content-Type: text/plain; charset=UTF-8; format=flowed
W dniu 06.04.2013 12:34, Jan Łukasz Ciećko napisał(a):
Dnia 05-04-2013 o 11:51:42 Tomasz Chilinski tomasz.chilinski@chilan.com napisał(a):
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
W dniu 05.04.2013 10:29, Jan Łukasz Ciećko pisze:
Dnia 04-04-2013 o 21:46:58 Andrzej Banach lms@net-komp.net.pl napisał(a):
Witam; Z uwagi ze robie przesiadke z debiana na mt na glownym routerze/sheaperze szukam osobki, ktora napisze/zaktualizuje nam skrypcik wyciagajacy dane z lms'a i automatycznie aktualizujacy wpisy na mt.
Zalozenia: - brak radiusa - do komunikacji uzywamy raczej api - mozemy generowac daemonem potrzebne dane do plikow lub wyciagac bezposrednio z bazy
Skrypt w locie ma w mt generowac regulki: - dhcp - firewall - qos - routing
Wole dac komus zarobic niz przerabiac swoje obecne skrypty na "like mt". Prosilbym o kontakt z oferta zainteresowane osobki.
pozdrawiam
wiekszosc tych skrypcikow mam gotowych z tym ze ich ladowanie nie jest po api a po ssh
I prawidłowo, bo api nie daje pełnych możliwości w stosunku do cli. Api jest po prostu niedokończonym produktem.
Pozdrawiam Tomasz Chiliński, Chilan
Kolejna sprawa ktora warto poruszyc jest to iz na dzien dzisiejszy nie obsluguje architektury x64 czyli widzi max 2GB ramu a przy zaawansowanym qos routingu i calej reszcie i odpowiedniej ilosci klientow i lacza naprawde nie wystarcza wiem bo testowalem
Uuu to bardzo poważna wada. Dlatego RouterOS-a zostawmy tam gdzie jego miejsce - na lepszych mydelniczkach ;-)
Wersja 6.X obsługuje architekturę x64, ale pytanie po co Wam więcej niż 2GB ramu skoro MT z dwoma pełną tablicami BGP i 5k kolejek zużywa 870 Mb ram ? Poza tym ostatnie Routerbordy na procesorach tile (64bit) spokojnie zastąpią PC i bierze to max 40W.
W dniu 08.04.2013 09:53, Sebastian napisał(a):
Wersja 6.X obsługuje architekturę x64, ale pytanie po co Wam więcej niż 2GB ramu skoro MT z dwoma pełną tablicami BGP i 5k kolejek zużywa 870 Mb ram ? Poza tym ostatnie Routerbordy na procesorach tile (64bit) spokojnie zastąpią PC i bierze to max 40W.
Mikrotik ma 2 zalety Winbox i trochę mniejsze zużycie mocy niż PC. Puszczam tu również maila z małym podsumowaniem niedoskonałości RouterOS i CCR, którego napisałem komuś prywatnie:
Przede wszystkim pisałem o doświadczeniach z nowy routerboardem nazywanym przez Mikrotika "CCR". Lista problemów: 1) Możliwe straty na interfejsach sieciowych widziane jako TX drops. 2) Niestabilny dostęp przez ssh. Trzeba szeregować odwołania do RouterOS-a przez ssh. 3) API nie obsługuje tych wszystkich funkcji co SSH i dlatego trzeba albo używać tylko SSH, albo liczyć się z tym, że trzeba będzie obsługiwać i jedno i drugie. 4) Niestabilne OSPF - przy sąsiedztwie typu broadcast działa jak chce i często, mimo sąsiedztwa, znikają całe trasy routingu. Z OSPF jest cała masa problemów. Na forach ludzie dochodzą do wniosku, że lepiej uznać, że OSPF w ogóle nie ma, 5) Często to co widzi się w Winbox nie do końca jest zgodne z tym jak RouterOS rzeczywiście ma ustawioną konfigurację.
Teraz bardziej ogólnie: 6) Address-list-y to mocno zubożone ipset. Ipset pozwala na trzymanie nie tylko adresów IP, ale i portów, maków oraz różnych kombinacji ip,portów,maków. Poza tym podmianę zawartości zbiorów w ipset można realizować poprzez ipset swap zbior1 zbior2. Tego RouterOS nie obsługuje i trzeba czyścić address-listę i wypełniać ją na nowo, co może skutkować np. przerwami w dostępie. 7) W którejś z wersji 3.x wycofali obsługę broute przez co nie można jawnie decydować, jaki ruch jest bridge-owany, a jaki routowany.
Ogólnie to myślałem już o rozpoczęciu pisania bloga antyrouterosowego, ale pewnie by czasu brakowało na to ;-) Zaletą byłoby to, że żaden problem z routerboardami, a zwłaszcza z CCR nie zostałby przeze mnie zapomniany czy przeoczony. Na dzień dzisiejszy CCR to bardzo ryzykowne rozwiązanie. Jest szansa, że w prostej konfiguracji będzie jakoś działał. Nie daje jednak takiej elastyczności jak linux, który można dostosować do tego, że choćby w przypadku ataków DDoS odpowiednio zareaguje.
uczestnicy (2)
-
Sebastian -
Tomasz Chiliński