Zase ten NAT 1:1 - může to fungovat i z vnitřní sítě?

[pgb]

díky, už to tu začíná být krásně ucelené, abych to mohl zkusit nasazovat.

[okoun]

Hle, člověk si odskočí na pár hodin do hospody a jak se to tu rozvine.
K popisu od loopie, také je dobré nezapomenout na filtraci protokolů, a to co nejblíže k zákazníkovi filtr, co do toho L2 pustí jen Ethernet rámce patřící pro PPPoE, to hned zahodí bordel od zákazníka, pokud tam pustí něco jiného. Umí slušnější switche a i bridge firewall v ROSu.

K otázce přihlašování jménem a heslem. Existuje funkce PPPoE Intermediate Agent, což je obdoba DHCP option 82. Některé switche to umí, pak mi switch v baráku do procházejícího PPPoE přihlašování vloží idnetifikci switche a ID linky z které to přichází. Zákazníka pak dle toho ověřím v RADIUS serveru bez ohledu na to, co si tam dá z jméno/heslo stejně, jak dělá O2 na xDSL (nebo jméno/heslo beru v potaz a navíc i kontoluji, zda je to použito na správné lince a ne u souseda).
Řvěte na Mikrotik, už před časem mi odkejvali, že je to naprosto legitimní požadavek, aby byla funkce PPPoE helperu součástí bridge, aby to šlo dát třeba do koncového SXT před router zákazníka nedo do CSR switche v baráku, takže funkci doplní, když bude o ni větší zájem.
https://www.broadband-forum.org/technic ... TR-101.pdf Chapter 3.9.2 PPPoE Intermediate Agent

jen by mě zajímalo kolik výkonu sežere ten l2 filtr? předpokládám, že to zapnu na apčku a tam bych s výkonem moc neplácal

[pgb]

univerzální odpověď, podle počtu pravidel, druhu toku a podle toho jak na kterém RB ... na to se prostě nedá odpovědět

[okoun]

univerzální odpověď, podle počtu pravidel, druhu toku a podle toho jak na kterém RB ... na to se prostě nedá odpovědět

obávám se že právě to bude jinak než u ip firewallu

[pgb]

Po víkendu udělám lehké testy pomocí btestu mezi 2x ccr1009 skrze gigabitový hex v bridge s l2 filtry.

edit: moment, špatně .....
moment

[Dalibor Toman]

Mikrotik tvrdi, ze ten Hex zvladne pres 1.5gbps pri 25 pravidlech v bridge (1 promile ztratovost). CPU bylo na stropu?
https://routerboard.com/RB960PGS

[pgb]

A kde jinde nežli na 100% by to mělo být ? Moje metodika je jasně popsaná a každý si ji může odzkoušet. Mimochodem jejich metodika je jiná, jak změříš 1,5gbps na 1Gbps portu ?

[radik]

- pouzij filter v bridge a ne funkci firewallu v bridge
- staci pouzit 1 stream na TCP (i kdyz tady je to sporny, protoze se muze stat, ze nebude stihat generovat provoz), takze i UDP (je to podstatne lehci na generovani)
- do filteru dej pouze povoleni PPPoE session a discovery + jako posledni pravidlo discard vseho

[pgb]

upravuji výsledky testu

- filtr v bridge používám, ale nečekal jsem že položka zapnutí "use ip firewall" to tak sejme a nenapadlo mě, že to jede bez ní, pardon chyba (síť mám v L3, tak tam mi to naštěsní nevadí)
- 1 stream ok, odzkouším
- pravidla odzkouším a edituji příspěvek s testy

edit: bez use ip firewall nefunguje použít packet mark a dát qos na L2

[pgb]

Tak test 2 dle vylepšeného zadání od radika

CCR1009 + PPPoE cli ---- RB960PGS (br0 eth2+eth3, bridge filter 3 pravidla (PPPoE session,discovery,drop)) --- CCR1009 + PPPoE server

test v pppoe tunelu udp 810Mbps/ tcp 470Mbps
test přímo bez pppoe udp 960Mbps / tcp 880Mbps

počet pravidel v bridge firewall neměl vliv na propustnost (děkuji za trpělivost)

počet pravidel začne mít vlil při zapnutí funkce use ip firewall

[radik]

S tim filtrem na bridge se funguje trochu jinak nez s klasickym firewallem. Bere se primo pozice v bytu (u firewallu tohle tak jednoduse udelat nejde, tak je to pomalejsi o neco).
Ono vseobecne nema smysl zapinat pouziti firewallu do bridge (jen pokud clovek potrebuje skutecne neco specifickyho a musi vedet ze to skutecne pouziva, jinak se bude divit ze mu neco nejde).

Se toho PPPoE totiz vsichni hrozne bojite

[Dalibor Toman]

Se toho PPPoE totiz vsichni hrozne bojite

btw: jak je to na dnesnich wifi radiich s citlivosti na ztratovost? Kdysi jsme pppoe pouzivali (v dobach, kdy existovali jen 2.4ghz radia a nejvyssi modulace byla 11mbps a utekli jsme od ni z nekolika duvodu : mtu, slozitejsi cfg na strane zakaznika, slozitejsi hledani problemu a hlavne velka citlivost na pripadny packet loss. Na stejnem pripojeni bez pppoe si zakaznik nestezoval zakaznik, kdezto v pppoe modu volal stale dokola.

[radik]

btw: jak je to na dnesnich wifi radiich s citlivosti na ztratovost? Kdysi jsme pppoe pouzivali (v dobach, kdy existovali jen 2.4ghz radia a nejvyssi modulace byla 11mbps a utekli jsme od ni z nekolika duvodu : mtu, slozitejsi cfg na strane zakaznika, slozitejsi hledani problemu a hlavne velka citlivost na pripadny packet loss. Na stejnem pripojeni bez pppoe si zakaznik nestezoval zakaznik, kdezto v pppoe modu volal stale dokola.

Pokud radio ztratuje tak je linka nekvalitni a PPPoE se skutecne muze rozpadnout (ale muselo by to ztratovat hodne), coz jde pak videt na strane radiusu, protoze klient prestal komunikovat. Kdyz to pak muzu vyfiltrovat z radiusu, tak muzu problem opravit a vyresit (u cistyho IP reseni se to ani nedozvis a myslis si jak ti to krasne funguje).
Dneska vetsina zarizeni se po rozpojeni navaze skoro hned (mikrotik to dela v podstate okamzite), takze klient nic nepozna. Jediny problem co jsem pozoroval tak byl s TPLinkem (ale ne vsechny), ze sice navazali PPPoE session, ale trvalo cca 30 sekund, nez zacne byt funkcni.
Zkus nasadit na lince co ztratuje nejak rozumne a uvidis.

Po nasazeni PPPoE se neozval nikdo, ze by zacal fungovat hur. A kdyz nekdo ztratoval tak moc, ze se rozpadalo PPPoE kvuli tomu (coz bylo uz opravdu hodne), tak by to poradne nefungovalo ani bez PPPoE. Jenze tady je ta vyhoda, ze je to zalogovany.

Situace co se stavali driv, kdyz se pouzilo pouze IP:
- klient zavolal, ze mu to nefungovalo tehdy a tehdy (na to se da odpovedet, ze musi zavolat az mu to dela problem, protoze se zpetne opet toho moc nedohleda)
- klient zavola, ze mu to chodi posledni tyden spatne (na to se dalo odpovedet leda, ze od nas je vsechno v poradku, protoze v tu chvili kdy vola vse jelo a zpetne nikdo nic nedohleda)

s PPPoE se mrknu do logu a vidi, ze tehdy a tehdy se mu rozpadla session a nebo to vubec nebylo prohlaseny, tak vim, ze skutecne byl nejaky problem a nefungoval. Pripadne se podivam a vidim, ze za posledni tyden se mu PPPoE navazuje 100x za den (no tak to je pak jasny, ze mu to moc nepojede a ztratuje to, tak se musi resit nejak).
Pak jeste (coz se tady nebude tykat asi skoro nikoho) se muze jednoduse premigrovat na callcentrum (nerozpatlavat), s tim, ze operator vidi hnedka jestli funguje/nefunguje, jestli mel problem a muze okamzite predat dal do planu na technika, ktery bude resit opravu -> setri naklady, ze musi nekdo technicky linky extremne proverovat.

Jak tohle treba resite ostatni, aby jste vedeli, ze klient skutecne fungoval a nebo mel problemy (podle grafu dat se to udelat neda), snad leda podle odezvy a pak kdyz je zvetsena porovnat s grafem dat (ale zase potreba lidsky a vypocetni zdroje pro system).

[Dalibor Toman]

Jak tohle treba resite ostatni, aby jste vedeli, ze klient skutecne fungoval a nebo mel problemy (podle grafu dat se to udelat neda), snad leda podle odezvy a pak kdyz je zvetsena porovnat s grafem dat (ale zase potreba lidsky a vypocetni zdroje pro system).

smokeping, uptime, logy z MT, ...

[basty]

Mne treba vadi takto dalsi prvek o ktery se musim starat a bez kterého to "nepojede" radius. Mel bych tedy mit 2 na jinych mistech a ty 2 musim patricne synchronizovat, zalohovat (+ co se tyce napajeni) a spravovat. Co se tyce dokazovani jestli klient jel nebo ne... Stejne je vetsina problemu zpusobena u nej doma a tam vam to pppoe nijak nepomuze. Pokud je to kokot a bude se s vami hadat, tak stejne i kdyz mu to ukazete, tak stejne plati: "zakaznik ma vzdy pravdu". U normalniho zakaznika to nebudete potrebovat. Pokud bych se chtel hadat ve smyslu vymahani penez... tak stejne vetsina lidi nejde az tak do dusledku a data z pignu nebo radiusu jsou svym zpusobem rovnocena. Nic neni nijak oficialne prokazatelny, obe hodnoty si muzes nakraslit nebo udelat jak chces.