classic.ISPforum.cz

ahoj, potřebuji na jednom bodě redistribuovat connected routy, ale jen ty které dělá pppoe (radius)?
je možné to nějak v routing filtru nastavit? zkoušel jsem to ale moc mi to nejde...

díky

Ahoj, nejlépe v chainu OSPF-out všechno dropnout a povolit distribuci pouze /32 rout. Já to používám spíš opačně - dropuju /32 routy a propaguju pouze sumarni routu (nebo jak se tomu říká).

no to si asi moc nepomohnu, jelikož já potřebuji aby se mi nepropagovali routy, které dělá ppptp a eoip a tam to je také /32 to ppptp

Jasně, to jsem netušil, že jsou tam ještě další podobné routy. Stejně ale určitě máš nějaký pool, ze kterého přiděluješ adresy PPPoE klientům, takže bych ho použil v tom filtru. Něco jako prefix=XX.XX.XX.XX/XX prefix-length=32 action=accept, ostatní drop.

no jestli to jde dle poolu, tak by to bylo dobrý. bylo by možné to nějak probrat IMkem?

Pro nás ostatní, jelikož by se nám to mohlo také hodit, se přimlouvám - probírejte to tady. Nebo alespoň postněte závěr

okoun píše:no jestli to jde dle poolu, tak by to bylo dobrý. bylo by možné to nějak probrat IMkem?

závěr klidně postu, ale právě že jsem filtry nikdy nenastavoval, tak bych potřeboval spíše IM konzultaci aby to tu nedopadlo jako s vláknem o PBM10

Popíšu jak to máme udělané my. Je to trochu něco jiného, ale je no tom myslím docela dobře vidět, jak ty filtry pracují. Tedy, máme dva druhy klientů - dynamická a statická IP. Na každé NASko routuji jeden /26 rozsah, ze kterého se přidělují dynamické adresy(to je ten pool, který jsem zmiňoval výš), statické adresy jsou z jiného subnetu, který je rozprostřený po celé síti. Veškeré routování nastavuje OSPF, které na NASku má nastavené redistribute connected a redistribute static. Abych omezil na minimum updaty OSPFka, tak právě používám filtry - ve skutečnosti je to pouze jeden filtr



Tím se mi distribuuje jenom sumární routa na ten /26 rozsah a ne každá /32 z PPPoE - okoun si tam dá místo discard accept, přidá ještě jeden filtr, kterým discardne ostatní /32 routy a měl by to mít hotové, je to jako nastavovat pravidla ve firewallu. IM v PM

To buhužel nebude platit pro nejčastější případ. A sice, když klient dostává IP adresu přes Framed-IP-Address. U takového systému je 100% roaming, a tím se možnost sumarizace prudce snižuje úměrně k počtu PPPoE koncentrátorů v síti.

Adresy přiděluji přes Framed-IP-Address a každý klient se může připojit na každý koncentrátor. Klienti se statickou IP dostanou vždycky svoji IP, klienti s dynamickou dostanou adresu podle toho na který koncentrátor se hlásí. Klientů s dynamickou adresou je většina, takže se sumarizací mám v routovacích tabulkách cca o 80 procent měně záznamů než bez ní. Jedná se v tomto případě o stoprocentní roaming?

Jedná. A já bych dynamické přidělování IP z poolů zavrhnul k vůli neefektivnímu využívání adres v případě, že je koncentrátorů víc, než prstů na jedné ruce. Pokud se bavíme o veřejných IP.

Když se ještě letmo vrátím k té sumarizaci. Je to bezva věc, a v praxi hůře dosažitelná. Na druhou stranu, mít stovky nebo tisíce záznamů v OSPF není nic strašného. Kdo chce přesto systému odlehčit, použije zpravidla NSSA area.

Ano bavíme se o veřejných IP adresách. Když jsem navrhoval topologii pro PPPoE, tak jsem si sumarizaci určil jako jednu z podmínek (dříve jsem měl s OSPF dost rozporuplné zkušenosti, když bylo hodně routovacích updatů). Vzhledem k tomu, že na koncentrátorech dělám i shaping, není možné aby koncentrátory byly na AP (používáme běžné routerboardy ve všech možných příchutích) kvůli výkonu. Mám tedy čtyři "velké" PPPoE koncentrátory, takže sumarizace není problém. Používám ale sqlippool, který má oproti oproti ippoolu pár šikovných vlastností navíc, takže si dokážu lehce představit desítky PPPoE koncentrátorů se sumarizací rout i s optimálním využitím dostupných IP. Stovky koncentrátorů už si moc představit nedokážu, ale asi by to taky šlo. Tady záleží hodně na tom, jak je síť navržená. Pro okounův poměrně dost specifický případ bych asi skutečně vytvořil NSSA areu.

Díky za popis. Přiznám se, že v případě mého dizajnování sítě, bylo jednou z největších priorit, mít vždy aktuální přehled o vytíženosti wireless sektorů. Díky rovnici wireless sektor = pppoe server tak z SQL accoutingu dokážeme kdykoliv vytáhnout aktuální přehled všech sektorů a jejich zákazníků. Způsobů, jak toho dosáhnout je sice víc, ale žádný není tak elegantní, jako právě tenhle.

Pokud jako AP není RB 1xx nebo 5xx, tak není s využitím CPU žádný problém. Což neznamená, že bych se nebránil posunout PPPoE server dál do "core". V mém případě by se tak mohlo stát pouze za předpokladu, že Mikrotik konečně zapracuje na podpoře injektování identifikátorů do PPPoE paketů (circuit-id). Což zatím pořád neumí.

Nicméně bych se zeptal, jakým způsobem u vás řešíte přemostění L2 mezi klientem a PPPoE koncentrátorem umístěným v core?

Koncentrátory jsou na rozhraní core a backhaulu, PPPoE sevrer je také pro každý bezdrátový sektor v síti. Přemostění L2 je pomocí VLAN - zákazníci se na AP otagují a pak už běží svojí VLANou. Jedna VLANa pro každý sektor, případně FTTB switch. Koncentrátor je vždy x86 ROS + VLAN switch. Mám z toho řešení docela dobrý pocit:), je to setup, který se dá lehce rozšiřovat a škálovat.