On Sat, 05 Jan 2008 15:08:22 +0100, widynek wrote
> > Co zrobic by automagicznie zmieniac MT'ekom max bandwitch w zaleznosci
> > od uzycia glownego lacza? Oczywiscie najprosciej miec tyle lacza by
> > rurka do netu zawsze sie nudzila, ale chyba nie o to chodzi:)
> >
> > --
> > pozdrawiam
> > Andrzej Banach
>
> Stad wlasnie nie rozumiem, gdzie znajduje sie przewaga QOS na wielu
> routerach... Zarzadzac jest tym na pewno trudniej (bo zdalnie). Co do wymagan
> maszyny... stosujac filtry hashujace mozna naprawde wiele osiagnac -
> przynajmniej ja tak do odebralem, gdy po wdrozeniu obciazenie procka spadlo mi
> z 30-40% na 10%. Siec nie jest co prawda duza (ok 250 hostow, 20Mb lacza - ale
> fullem nie idzie), ale jakos nie sadze, ze szybko braknie mi mocy obliczeniowej...
>
> Moze po prostu ustawic na routerze brzegowym klasy dla poszczegolnych
> podsieci... dac im gwarancje po rowno, natomiast "max-limit" z duzym zapasem
> (np dla rurki 50Mb i 5 routerow kazdemu dac po 25Mb max-limit). Potem
> definiujemy klase-rodzica jak zwykle - do pojemnosi rurki. Powinno sobie chyba
> poradzic ?
>
> pozdrawiam,
> widynek
QoS to co innego jest niż ustawianie gwarantowanej przepustowości. Z reguły QoS jest
realizowany w warsywie drugiej (L2) urzadzenia wspierajace QoS rozpoznaja pakiety
ethernetowe i przerabiają je zgodnie ze zdefiniowana polityką np real time (rtps) ,
(be)best effor czyli jak sie uda itd, potrafia rozrózniać po nagłowkach typ ruchu
voip, video, itd. Aby to miało sens wszystkie urzadzenia powinny gadac ze soba zgodnie
ze standardami QoS potrafi cos takiego np z radiowych sprzęt Tsunami Proxima, oraz
wszystkie sprzeta wimaxowe, QoS maja też np lepsze switche, QoS działa z reguły
niezaleznie od przyznanych klientowi predkosci gwarantowanych i maksymalnych, dzieki
QoS działaja usługi ktore potrzebuja przetwarzanie w czasie rzeczywisty
Bez QoS nie ma co mażyc zeby voipy działały w sieci i nic nie pomoże gwarantowanie
predkosci w punkcie centralnym jak stacje bazowe nie beda miały w warstwie drugie
właczony o dobrze skonfigurowany QoS.
Dariusz Kowalczyk
_______________________________________________
lms mailing list
lms(a)lists.lms.org.pl
http://lists.lms.org.pl/mailman/listinfo/lms
> Co zrobic by automagicznie zmieniac MT'ekom max bandwitch w zaleznosci
> od uzycia glownego lacza? Oczywiscie najprosciej miec tyle lacza by
> rurka do netu zawsze sie nudzila, ale chyba nie o to chodzi:)
>
> --
> pozdrawiam
> Andrzej Banach
Stad wlasnie nie rozumiem, gdzie znajduje sie przewaga QOS na wielu routerach... Zarzadzac jest tym na pewno trudniej (bo zdalnie). Co do wymagan maszyny... stosujac filtry hashujace mozna naprawde wiele osiagnac - przynajmniej ja tak do odebralem, gdy po wdrozeniu obciazenie procka spadlo mi z 30-40% na 10%. Siec nie jest co prawda duza (ok 250 hostow, 20Mb lacza - ale fullem nie idzie), ale jakos nie sadze, ze szybko braknie mi mocy obliczeniowej...
Moze po prostu ustawic na routerze brzegowym klasy dla poszczegolnych podsieci... dac im gwarancje po rowno, natomiast "max-limit" z duzym zapasem (np dla rurki 50Mb i 5 routerow kazdemu dac po 25Mb max-limit). Potem definiujemy klase-rodzica jak zwykle - do pojemnosi rurki. Powinno sobie chyba poradzic ?
pozdrawiam,
widynek
_______________________________________________
lms mailing list
lms(a)lists.lms.org.pl
http://lists.lms.org.pl/mailman/listinfo/lms
On Sat, 05 Jan 2008 14:46:24 +0100, Andrzej Banach wrote
> Dariusz Kowalczyk pisze:
> > On Sat, 5 Jan 2008 10:02:16 +0100, Mariusz Barczyk w
> >
> >> Tylko zastanawiam sie nad taka sytuacja:
> >>
> >> Mamy jakies x lacze podlaczone do jednego punktu. Przychodza jakies
> >> swieta i bardzo duzy szczyt no i lacze sie zaczyna zapychac. Ludzie
> >> maja w regulkach gwarancje y i max limit z. Kiedy zaczyna sie
> >> zapychac lacze to htb bedzie rowno schodzilo z z do y.
> >>
> >> Jak to sie odbywa z zdecentralizowanej sieci? Mozna dac limity
> >> koncentratorom, ale wtedy istnieje duze prawdopodobienstwo, ze
> >> podzial nie bedzie sprawiedliwy, bo na jednym beda sami ssacze i
> >> zapchaja w momencie, a na drugim bedzie jeszcze luz. Stosowanie
> >> podwojnych regulek na koncentratorach i routerze nie ma najmniejszego
> >> sensu.
> >>
> >
> > przeczytaj mój wcześniejszy post na ten temat
> >
> >
> >
> Powiem szczerze ze ja niemoge doszukac sie odpowiedzi na to pytanko.
> Moze uproszcze i zobrazuje pytanie:
> Mamy rurke do sieci Internet 50Mbps.
>
> W sieci podzial na 5 podsieci z czego kazda ma swojego MT'eka, ktory
> wykonuje qos (gwarantowane pasmo po 10Mbps na kazdego MT). To oczywiscie
> sie sprawdza bo zarowno w szczycie jak i poza glowna rurka do sieci
> Internet nie bedzie zapchana.
>
> Zalozmy teraz ze chcemy przyjac jakis "overboking" tak by glowne lacze
> do sieci Internet sie nie "marnowalo". W sytuacji jak MT'ekom
> poprzydzielamy np. po 20Mbps to w momencie szczytu glowne lacze nam sie
> zapcha. Jak tego uniknac?
>
> Co zrobic by automagicznie zmieniac MT'ekom max bandwitch w zaleznosci
> od uzycia glownego lacza? Oczywiscie najprosciej miec tyle lacza by
> rurka do netu zawsze sie nudzila, ale chyba nie o to chodzi:)
>
> --
> pozdrawiam
> Andrzej Banach
>
> _______________________________________________
> lms mailing list
> lms(a)lists.lms.org.pl
> http://lists.lms.org.pl/mailman/listinfo/lms
gwarantowane dajesz 10Mbps a 20Mbps jako maksymalne wtedy jak bedzie z czego dawac to
przydzieli 20Mbps a jak nie da to co gwarantowane takie cos potrafi przeciez linux
Dariusz Kowalczyk
_______________________________________________
lms mailing list
lms(a)lists.lms.org.pl
http://lists.lms.org.pl/mailman/listinfo/lms
Dariusz Kowalczyk pisze:
> On Sat, 5 Jan 2008 10:02:16 +0100, Mariusz Barczyk w
>
>> Tylko zastanawiam sie nad taka sytuacja:
>>
>> Mamy jakies x lacze podlaczone do jednego punktu. Przychodza jakies
>> swieta i bardzo duzy szczyt no i lacze sie zaczyna zapychac. Ludzie
>> maja w regulkach gwarancje y i max limit z. Kiedy zaczyna sie
>> zapychac lacze to htb bedzie rowno schodzilo z z do y.
>>
>> Jak to sie odbywa z zdecentralizowanej sieci? Mozna dac limity
>> koncentratorom, ale wtedy istnieje duze prawdopodobienstwo, ze
>> podzial nie bedzie sprawiedliwy, bo na jednym beda sami ssacze i
>> zapchaja w momencie, a na drugim bedzie jeszcze luz. Stosowanie
>> podwojnych regulek na koncentratorach i routerze nie ma najmniejszego
>> sensu.
>>
>
> przeczytaj mój wcześniejszy post na ten temat
>
>
>
Powiem szczerze ze ja niemoge doszukac sie odpowiedzi na to pytanko.
Moze uproszcze i zobrazuje pytanie:
Mamy rurke do sieci Internet 50Mbps.
W sieci podzial na 5 podsieci z czego kazda ma swojego MT'eka, ktory
wykonuje qos (gwarantowane pasmo po 10Mbps na kazdego MT). To oczywiscie
sie sprawdza bo zarowno w szczycie jak i poza glowna rurka do sieci
Internet nie bedzie zapchana.
Zalozmy teraz ze chcemy przyjac jakis "overboking" tak by glowne lacze
do sieci Internet sie nie "marnowalo". W sytuacji jak MT'ekom
poprzydzielamy np. po 20Mbps to w momencie szczytu glowne lacze nam sie
zapcha. Jak tego uniknac?
Co zrobic by automagicznie zmieniac MT'ekom max bandwitch w zaleznosci
od uzycia glownego lacza? Oczywiscie najprosciej miec tyle lacza by
rurka do netu zawsze sie nudzila, ale chyba nie o to chodzi:)
--
pozdrawiam
Andrzej Banach
_______________________________________________
lms mailing list
lms(a)lists.lms.org.pl
http://lists.lms.org.pl/mailman/listinfo/lms
On Sat, 5 Jan 2008 10:02:16 +0100, Mariusz Barczyk w
>
> Ja tez jestem zdania, ze centralnie sterowana siec od pewnej liczby
> klientow staje sie problematyczna i tez mam zamiar zrezygnowac z
> mocnej centralnej maszyny na rzecz wielu routerow.
>
> Tylko zastanawiam sie nad taka sytuacja:
>
> Mamy jakies x lacze podlaczone do jednego punktu. Przychodza jakies
> swieta i bardzo duzy szczyt no i lacze sie zaczyna zapychac. Ludzie
> maja w regulkach gwarancje y i max limit z. Kiedy zaczyna sie
> zapychac lacze to htb bedzie rowno schodzilo z z do y.
>
> Jak to sie odbywa z zdecentralizowanej sieci? Mozna dac limity
> koncentratorom, ale wtedy istnieje duze prawdopodobienstwo, ze
> podzial nie bedzie sprawiedliwy, bo na jednym beda sami ssacze i
> zapchaja w momencie, a na drugim bedzie jeszcze luz. Stosowanie
> podwojnych regulek na koncentratorach i routerze nie ma najmniejszego
> sensu.
przeczytaj mój wcześniejszy post na ten temat
Dariusz Kowalczyk
_______________________________________________
lms mailing list
lms(a)lists.lms.org.pl
http://lists.lms.org.pl/mailman/listinfo/lms
Witam Wszytkich z listy LMS
Szukam osoby, ktora podejmie się instalacji na nowo LMS i skonfigurowania. POnizej opisuje problem.
W tym monecie jest zainstalowany LMS 1.10.0 Urgo sytsem debian. Userow jest 52 urzadzen 61.
Siec sklada sie z dwoch czesci jedna z przewodeowej druga z bezprzewodwej.
Niby internet jest, ale dzienie sie zachowuje.
Wczesniej jak nie bylo STM musialem po karzsym przeladowaniu LMS na nowo restartowac niceshapera, poniewz jak tego nie zrobilem usrzy dostawali na swoje kompy cale pasmo lacza, poprostu nie bylo ograniczenia,a procesor w serwerze byl obciazony w 100%, pamiec rowniez w 100% byla obcizona. Teraz STM zmienil sytuacje bo niceshaper jest wylaczony i wydaje sie wszytko ok.
Moim zadniem nie dziala rowniez zabezpieczenie mac adres IP --- uwazam dlatego bo userzy zmnieja IP a interent nadal maja, kolejna sprawa jest ze ludzie samowolnie podlaczaja routery bezprzewodowe (nie umia tego skonfigurowac - maja wlaczone dhcp i sa konflikty w sieci) Szukam osoby kotra umie rozwiazac te problemy. Prosze o kontakt osobby kotre chca podjac sie zadania, oferty tylko z cena i czasem reazliacji. Dodam ze jeszcze nie dziala wysylanie komunikatow i blokowanie. Pozdrawiam i czekam na odpwedz.
_______________________________________________
lms mailing list
lms(a)lists.lms.org.pl
http://lists.lms.org.pl/mailman/listinfo/lms
-----Original Message-----
From: lms-bounces+bsflip=gmail.com(a)lists.lms.org.pl
[mailto:lms-bounces+bsflip=gmail.com@lists.lms.org.pl] On Behalf Of Dawid
Widyna
Sent: Friday, January 04, 2008 9:35 PM
To: lista użytkowników LMS
Subject: Re: [lms] [OT] MT<-> lms
jpk napisał(a):
> Możesz mi zdradzić z grubsza w jaki sposób importujesz filtry i inne
> rzeczy na MT ?
>
>
Ja "eksportuję" z serwera z LMS za pośrednictwem SSH. Przy przeładowaniu
LMS'a tworzą się skrypty bashowe dla wybranych MT (w lms.ini mam sekcję
z ich IP, Loginami/passłami oraz sieciami, które obsługują).
Przykład:
#!/usr/bin/expect -f
#konfiguracja systemu MT - wykonywana za pomoca EXPECT
#
set timeout 5
spawn ssh admin(a)192.168.200.1
match_max 100000
expect "*?assword:*"
send -- "haslo_mt\r"
expect -re ".*"
send "\r"
expect "] >"
##Interfejs ether1
send "/ ip dhcp-server lease\r"
expect "lease>"
send "remove \[find server=dhcp-ether1\]\r"
expect ">"
send "\r"
send "/ ip firewall filter\r"
expect "filter>"
send "remove \[find in-interface=ether1\]\r"
expect ">"
send "\r"
send "/ ip dhcp-server lease\r"
expect "lease>"
send "add address=192.168.104.16 mac-address=00:19:E0:64:2A:71
server=dhcp-ether1 comment=STR17-5\r"
expect "lease>"
send "/ ip dns static\r"
expect "static>"
send "add name=STR17-5 address=192.168.104.16 ttl=1d\r"
expect "static>"
send "/ ip firewall filter\r"
expect "filter>"
send "add chain=forward action=drop src-address=192.168.104.16
src-mac-address=!00:19:E0:64:2A:71 in-interface=ether1 comment=STR17-5
disabled=no\r"
expect "filter>"
send "quit\r"
Nie jest to może zbyt eleganckie, ale jak to pisałem, to nie miałem
czasu szukać bardziej eleganckich rozwiązań na MT (tzn takich, które coś
zmieniają, a nie usuwają stare-tworzą nowe). Można też generować config
a potem wysyłać go przez FTP na MT i tam zdalnie odpalać... tyle, że w
obecnej sytuacji mam podgląd, jeśli coś pójdzie nie tak przy zmianie
konfiguracji.
Śliczne nie jest, ale działa od kilku miesięcy. Jeśli komuś odpowiada
takie rozwiązanie, to mogę podesłać na grupę fragment lms.ini oraz sam
skrypt, który generuje skrypt EXPECTA (uprzedzam, że perla znałem
jeszcze mniej niż teraz, więc nic ślicznego).
pozdrawiam,
widynek
_______________________________________________
lms mailing list
lms(a)lists.lms.org.pl
http://lists.lms.org.pl/mailman/listinfo/lms
Ja bym radził to bardziej uprościć i łączyć się za pomocą kluczy DSA.
http://wiki.mikrotik.com/wiki/Use_SSH_to_execute_commands_%28DSA_key_login%2
9
Potem tylko sprzężyć lms-mgc do generowanie regułek dla kolejek QUEUES
Przykład.
[mgc:mikrotik]
outfile = /etc/rc.d/mikrotik
outfile_perm = 755
networks = net
header_file = /etc/rc.d/dzien
allexistnodes = add name="%NAME_dzien" target-addresses=%IP/32
dst-address=0.0.0.0/0 interface=all parent=dzien direction=both priority=8
queue=default-small/default-small limit-at=%UPCEIL000/%DOWNRATE000
max-limit=%UPCEIL000/%DOWNRATE000 total-queue=default-small
w header_file mam
ssh -l admin -i /root/.ssh/id_dsa 192.168.1.200 " /queue simple remove
[/queue simple find parent=dzien]
/queue simple remove dzien
/queue simple
add name="dzien" target-addresses=192.168.0.0/16 dst-address=0.0.0.0/0
interface=all parent=none direction=both priority=1
queue=default-small/default-small limit-at=0/0 max-limit=0/0
total-queue=default-small
Ja to stosuje do taryf dziennych I wieczornych dla ludzi z sieci WIFI dużo
jeszcze mi brakuje w lms-sie jak możliwość generowania regułek dla
odpowiednich grup przez lms-mgc.
Czy wykorzystanie nowo dodane typy taryf w wersji 1.11.1 Talus.
Można tez użyć Perla a dokładnie jego moduł EXPECT i tez stworzyć skrypt
#!/usr/bin/perl
use Net::SSH::Expect;
my $ssh = Net::SSH::Expect->new (
host => "host",
port => "22",
password=> 'haslo,
user => 'admin',
raw_pty => 0
);
my $login_output = $ssh->login();
$ssh->send("/interface pppoe-server print without-paging\r");
while ( defined ($line = $ssh->read_line()) ) {
print $line . "\n";
}
Tylko to już więcej kombinowania :D
Powodzenia
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.5.516 / Virus Database: 269.17.13/1209 - Release Date: 2008-01-04
12:05
_______________________________________________
lms mailing list
lms(a)lists.lms.org.pl
http://lists.lms.org.pl/mailman/listinfo/lms
Witam
On Jan 4, 2008, at 3:52 PM, Michał Gacek wrote:
> Ja uzywam polaczenia lmsa + wlasnie mikrotik i zrozumcie ze dobra
> siec to
> taka ktora jest ZDECENTRALIZOWANA, gdzzie shaping odbywa sie na
> k"koncentratorach
Ja tez jestem zdania, ze centralnie sterowana siec od pewnej liczby
klientow staje sie problematyczna i tez mam zamiar zrezygnowac z
mocnej centralnej maszyny na rzecz wielu routerow.
Tylko zastanawiam sie nad taka sytuacja:
Mamy jakies x lacze podlaczone do jednego punktu. Przychodza jakies
swieta i bardzo duzy szczyt no i lacze sie zaczyna zapychac. Ludzie
maja w regulkach gwarancje y i max limit z. Kiedy zaczyna sie
zapychac lacze to htb bedzie rowno schodzilo z z do y.
Jak to sie odbywa z zdecentralizowanej sieci? Mozna dac limity
koncentratorom, ale wtedy istnieje duze prawdopodobienstwo, ze
podzial nie bedzie sprawiedliwy, bo na jednym beda sami ssacze i
zapchaja w momencie, a na drugim bedzie jeszcze luz. Stosowanie
podwojnych regulek na koncentratorach i routerze nie ma najmniejszego
sensu.
Ja wiem, ze powinno sie miec lacze tak zeby ludzie tego nie zapchali,
ale z drugiej strony placic za cos czego sie przez wiekszosc roku nie
uzyje jest troche nieekonomiczne. Jak ludzie w swieta beda mieli o 5%
mniejszy transfer przy rownym rozlozeniu to nawet nie zauwaza.
Moze zdardzisz nam cos wiecej na temat swojego szkieletu?
Pozdrawiam, Mariusz Barczyk
--
_______________________________________________
lms mailing list
lms(a)lists.lms.org.pl
http://lists.lms.org.pl/mailman/listinfo/lms
> Witam,
>
> mozliwe, ze w nowszej wersji jest to juz poprawione, ale na wszelki wypadek zapytam - czy w zakladce "lista taryf" sredni miesieczny przychod z taryfy nie powinien uwzgledniac faktu przydzielenia rabatow klientowi ?
> Przyklad:
> 2 klientow z taryfa powiedzmy za 200pln. Kazdy z nich ma rabat w wysokosci 50%. Sredni miesieczny przychod (faktyczny):200pln, sredni miesieczny przychod (w mysl lms): 400pln
>
> Przepraszam za brak pliterek.
>
> pozdrawiam,
> widynek
Wydaje mi sie, ze w ten sposob powinno byc OK. Przyklad dla zobowiazan rozliczanych miesiecznie:
Dla wersji lms 1.9.8, linia 1939
WHEN '.MONTHLY.' THEN tariffs.value*((100-assignments.discount)/100)
pozdrawiam,
widynek
_______________________________________________
lms mailing list
lms(a)lists.lms.org.pl
http://lists.lms.org.pl/mailman/listinfo/lms
Witam,
mozliwe, ze w nowszej wersji jest to juz poprawione, ale na wszelki wypadek zapytam - czy w zakladce "lista taryf" sredni miesieczny przychod z taryfy nie powinien uwzgledniac faktu przydzielenia rabatow klientowi ?
Przyklad:
2 klientow z taryfa powiedzmy za 200pln. Kazdy z nich ma rabat w wysokosci 50%. Sredni miesieczny przychod (faktyczny):200pln, sredni miesieczny przychod (w mysl lms): 400pln
Przepraszam za brak pliterek.
pozdrawiam,
widynek
_______________________________________________
lms mailing list
lms(a)lists.lms.org.pl
http://lists.lms.org.pl/mailman/listinfo/lms
