zkušenosti BGP/VPLS na mikrotiku?

[Majklik]

super, ale má to háček, že žádná gw co mám není primární ani sekundární, je to tak že mám právě pomocí toho cost rstp uvedeno jaká brána je pro koho primární a pro koho sekundární... takže zjevně bez rstp to nepůjde.

jinak je to tak že vpls tunely jsou z každé lokality jdou dva vpls každej na jednu bránu a potom ty brány jsou vzájemně propojeny uzavřeny do trojúhelníku pocí jednoho tunelu pro všechny lokality...

Nepropadej depresi (už ani ty deprese nejsou, co bejvaly). I tohle jde řešit, pokud chci mít vždy jednu GW jako master pro půlku sítě, jenom místo manipulací s RSTP costy to udělám tak, že na každé GW si uděláš dva bridge, nad každá pustíš jeden PPPoE server, kde jeden bude mít pado-delay a uděláš si dvě sady BGP VPLS tunelů, jedna propojená na bridge-master a druhá na bridge-backup a v APčkách jen říkáš na jaký z těch dvou VPLS se má napojit patřičným route-distinguisher, export-route-targets, import-route-targets, takže používám dvě číslovací řady 166:x a 266:x, kde je každá spojena s jendou sadou bridgů:

Kód: Vybrat vše

/interface vpls bgp-vpls
add bridge=bridge-pppoe-master bridge-cost=0 bridge-horizon=3 export-route-targets=166:11 \
  import-route-targets=166:21,166:31,166:171,..... name=vpls-pppoe-master route-distinguisher=166:10 site-id=11
add bridge=bridge-pppoe-backup bridge-cost=0 bridge-horizon=3 export-route-targets=266:11 \
  import-route-targets=266:22,266:32,266:172,..... name=vpls-pppoe-backup route-distinguisher=266:10 site-id=11


Na druhé GW je to stejné v bledě modrém:

Kód: Vybrat vše

/interface vpls bgp-vpls
add bridge=bridge-pppoe-backup bridge-cost=0 bridge-horizon=3 export-route-targets=166:12 \
  import-route-targets=166:21,166:31,166:171,..... name=vpls-pppoe-backup route-distinguisher=166:10 site-id=12
add bridge=bridge-pppoe-master bridge-cost=0 bridge-horizon=3 export-route-targets=266:12 \
  import-route-targets=266:22,266:32,266:172,..... name=vpls-pppoe-master route-distinguisher=266:10 site-id=12


A na AP pak napojuji buď na ty 166: nebo 266:, čímž určím, kde má mít master, jak bylo výše.

[okoun]

nu ač nerad, tak přeci bych tam našel trhlinku
a to jest návrat sítě do normálního stavu tedy pppoe účty tam kde mají být, tak pokud neudělám nějaký hromadný disconnect tak toho bez toho rstp nedocílím, že?

[pgb]

správně, klient zůstane připojený tam kde je dokud na něj nesáhneš

[Majklik]

Jo, ta ukázka výše toto neřeší, aby po oživení masteru se vrátili klienti na master z backupu. Jde ot udělat několika ojebávkama, ale to je zas ejebávání toho, jak je PPPoE server nedodělek, že ROS nepodporuje clusterování PPPoE serverů, které se spolu domluví už při připojení, kdo převezme klienta neumí si ho předat (jde to ojebat skriptováním, jak nám v nějaké MUM prezentaci předváděli, včetně automatického load balancingu).

Apropo, jak ti to řeší to RSTP? Pokud k tomu nepřidáš nějakou další opičárnu, tak také nijak. Chcíplne mi gwA, otevře ti RSTP VPLS tunel gwB-AP, lidi nalezou na PPPoE_B a jsou tam, až ti Ačko naskočí, tak se nahodí k němu VPLS, stejně tak VPLS propoj gwA-gwB a RSTP ti zavře přímý propoj gwB-AP, ale je otevřená cesta AP-gwA-gwB, kterou ti to klidně může téci oklikou pořád na PPPoE_B do chvíle, dokud tam lidi nějak nesejmeš (takže musíš k tomu přilepit ještě něco a např blokovat forward PPPoE provozu na tom bridge_gwA, pak lidi vychcípou a vrátí se ti na Ačko).

[pgb]

2 majklik - a všimnul jsi si super stavu, kdy máš dva pppoe servery (na různých strojích) v kombinaci s ospf a minimální pado delay a neprovede se správně redistribuce v routovací tabulce při návratu ze záložního pppoe na hlavní bez padlo? Případně pokud to popisuji příliš zmateně, tak to půjdu odlaborovat na poslední 6.40 a popsat lépe.

[okoun]

Jo, ta ukázka výše toto neřeší, aby po oživení masteru se vrátili klienti na master z backupu. Jde ot udělat několika ojebávkama, ale to je zas ejebávání toho, jak je PPPoE server nedodělek, že ROS nepodporuje clusterování PPPoE serverů, které se spolu domluví už při připojení, kdo převezme klienta neumí si ho předat (jde to ojebat skriptováním, jak nám v nějaké MUM prezentaci předváděli, včetně automatického load balancingu).

Apropo, jak ti to řeší to RSTP? Pokud k tomu nepřidáš nějakou další opičárnu, tak také nijak. Chcíplne mi gwA, otevře ti RSTP VPLS tunel gwB-AP, lidi nalezou na PPPoE_B a jsou tam, až ti Ačko naskočí, tak se nahodí k němu VPLS, stejně tak VPLS propoj gwA-gwB a RSTP ti zavře přímý propoj gwB-AP, ale je otevřená cesta AP-gwA-gwB, kterou ti to klidně může téci oklikou pořád na PPPoE_B do chvíle, dokud tam lidi nějak nesejmeš (takže musíš k tomu přilepit ještě něco a např blokovat forward PPPoE provozu na tom bridge_gwA, pak lidi vychcípou a vrátí se ti na Ačko).

ano děkuji za dobrou otázku
docela jsem si na tom zlámal zoubek než jsem na to přišel ale potom jsem si ulevil dal jsem na ten propoj mezi GW1 a GW2 do filteru L2 pravidélko že tam nesmí lozit Vlany což mi zajistí že tam neproteče ani paket dat z pppoe protože mám VPLS lokality -> VLAN sektoru -> PPPoE

[Majklik]

Základem je správně položit otázku, nejlépe na kterou znáš odpověď předem.
Já tohle řešil třeba pomocí VRRP, které sejmulo backup PPPoE server ve chvíli, kdy klienti viděli zase primární, ale také je to obezlička. Nu, také by mohl Mikrotik zapracovat na doplnění PPPoE helperu, aby jsi nemusel dělat obezličku s VLANama pro identifikaci odkud PPPoE klient příchází, protože helper na APčku by ti do přihlašovacího paketu doplnil ID APčka a wlany (slíbeno, ale prý to bude na dlouho).

2 majklik - a všimnul jsi si super stavu, kdy máš dva pppoe servery (na různých strojích) v kombinaci s ospf a minimální pado delay a neprovede se správně redistribuce v routovací tabulce při návratu ze záložního pppoe na hlavní bez padlo? Případně pokud to popisuji příliš zmateně, tak to půjdu odlaborovat na poslední 6.40 a popsat lépe.

Jako IP klienta, který odpadl z backup serveru a připojl se na primární, tak stále je propagován do OSPF, že visí na tom záložním? Tohle si moc u IPv4 nevbavuji, že bych potkal. IPv6 to dělalo, ale odhaduji, že někdy v průběhu 6.3x to bylo snad opraveno (tam bylo i víc bugů spojených s dynamickým DHCPv6-PD nad PPPoE).

[pgb]

Jako IP klienta, který odpadl z backup serveru a připojl se na primární, tak stále je propagován do OSPF, že visí na tom záložním? Tohle si moc u IPv4 nevbavuji, že bych potkal. IPv6 to dělalo, ale odhaduji, že někdy v průběhu 6.3x to bylo snad opraveno (tam bylo i víc bugů spojených s dynamickým DHCPv6-PD nad PPPoE).

Testováno na 6.38.x
Ano, tak nějak ... hlavní s pado 0 a záložní pado 2 ...... klient je připojen z nějakého důvodu na záložní, záložní propaguje ospf /32 na hlavní, vykopneš klienta, díky pado 0 se připojí na hlavní téměř okamžitě s světe div se, na záložní už se ten samý rozsah z hlavního nespropaguje. Řešením je dát na hlavním pado 6 záložním pado 8 a pak se ty tabulky stíhají vyčistit, ale nepřijde mi to moc korektní.

Otestuji to dnes na 6.40

EDIT: opraveno /30 na /32 => chyba při psaní

[Majklik]

To dáváš na PPPoE linky prefixy /30, např 198.51.100.4/30, kdy PPPoE sever má 198.51.100.5 a klient 198.51.100.6?, Takže pro každého klienta je IP adresa na straně PPPoE serveru jiná a stěhuje se na PPPoE server, co ji obsluhuje?
Běžnější je dávat na PPPoE linky jen /32 s adresou zákazníka a PPPoE server má jednu stejnou IP na všech PPPoE linkách. Takže server má pořád třeba 198.51.100.1 a zákaznické linky postupně 198.51.100.2/32, .3/32, ..., ten druhý PPPoE server má pak na svoji straně jinou IP/32 (třeba 198.51.100.254/32) a klienti fasuji ty jejich/32 pořád stejně z Radiusu nebo okdud je dáváš. Jen se jim mění v lince IP protitrany dle toho, jaký PPPoE server je obsluhuje.
Co popisuješ bude souviset primárně s OSPF a přetahováním segmentu /30, kdy segment primár ohlásí dříve, než na sekundáru ještě odpadne.

[pgb]

promiň, při psaní jsem to popletl, samozřejmě /32 (moc vedro). Klienti dostávají z radiusu pořád stejnou /32 a díky koncepci sítě potřebují obě GW vědět, kde je který klient. Neboj, tisíc rout mi neutíká do celé sítě.

Co popisuješ bude souviset primárně s OSPF a přetahováním segmentu /30, kdy segment primár ohlásí dříve, než na sekundáru ještě odpadne.

Ano, ale dělá to i při /32. Večer to zkusím na 6.40

[Majklik]

Trochu to okounovi przníme jiným tématem, aby nám z toho neleknul.

Nu, právě kdyby jsi přehazoval celé /30, kdy PPPoE server má na obou stranách stejnou IP, tak tak tam bych tušil, proč by to mělo dělat, co popisuješ. IMHO 6.40 bude na tom stejně.
Pokud to máš jako test na stole, tak ze srandy počkej 30 minut, zda se to při LSA resync na backupu napraví (i když se s routou nic nemění, tak každých 30 minut se odešle znova, viz age u LSA zánamů, nebudou starší jak 1800 sec). Ale chápu, že v reálu to není ono (pokud ti ten PPPoE server dělá zároveň i GW do inetu s BGP). Bylo by hezké se podívat, co pár sekund po té chíli, jak se vrátí klient na master, je v LSA databázích na masteru, backupu a na nějakém dalším routeru vedle (/routing ospf lsa print detail where id=<IP PPPoE přesunutého klienta>).

[pgb]

PPPoE klient(192.168.15.2) je připojen skrz bridge do dvou vpls tunelů, jeden vede na master(192.168.22.100) a druhý na backup(192.168.22.200). Ty mají mezi sebou ospf s jednou instancí + oba mají zapsaný network 192.168.22.0/24 pro komunikaci mezi nimi + podsíť 192.168.15.0/24 pro pppoe klienty. Interface je přidaný jako all.

Funkční stav - PPPoE klient 1připojen k master a výpis lsa z jeho strany

instance=default area=backbone type=router id=192.168.22.100 originator=192.168.22.100 sequence-number=0x8000000F age=8 checksum=0x8132 options="E" body=

flags=
link-type=Stub id=192.168.15.2 data=255.255.255.255 metric=10
link-type=Transit id=192.168.22.200 data=192.168.22.100 metric=10

Krok jedna, zakáži pppoe server, klient se přepojí na backup (192.168.22.200), v routovací tabulce dojde ke změne cíle 192.168.15.2 z pppoe tunelu na backup. Ping na klienta neběží, traceroute neukáže ani první skok? WTF?

instance=default area=backbone type=router id=192.168.22.200 originator=192.168.22.200 sequence-number=0x8000000B age=132 checksum=0x7515 options="E" body=

flags=
link-type=Stub id=192.168.15.2 data=255.255.255.255 metric=10
link-type=Transit id=192.168.22.200 data=192.168.22.200 metric=10

Krok dva, klienta z backupu vykopnu (nebo mu nastavím delší pado delay) a vše začne fungovat

instance=default area=backbone type=router id=192.168.22.200 originator=192.168.22.200 sequence-number=0x8000000D age=20 checksum=0x7117 options="E" body=

flags=
link-type=Stub id=192.168.15.2 data=255.255.255.255 metric=10
link-type=Transit id=192.168.22.200 data=192.168.22.200 metric=10

To celé se opakuje i při cestě zpátky. Můžu sem dát i konfiguraci, ale prostě to nechápu. Routovací tabulky se změní, lsa se posílají, ale icmp neprojde. Řešení to má v podobě nastavení zpožnění PADO na master i backup. Asi to není potřeba řešit, spíše je to taková zajímavost

[pgb]

Poznatek, tato situace vyskytuje pouze, pokud mám přidaný LDP interface (lsr+transport u mpls mám nastaven správně)

EDIT 1: .... takže vlastně dobře že jsem si toho všiml, tohle mi uniklo, LDP by posílalo hromadu /32 do sítě zbytečně. Stačí správně nastavit filtry, snad.

EDIT 2: omlouvám se a stydím se za svou neschopnost, stačí nastavit LDP advertise filter na podsíť s pppoe s advertise=no a vše běhá jak má. Moje chyba.

EDIT 3: ale stejně by to dělat nemuselo, skoro bych to považoval za chybku, akorát není v ospf, ale v kombinaci ldp/pppoe a konkrétního stavu.

[Majklik]

Ano, ty LSA jsou OK.
Napadlo mě také, že možná nefiltruješ generování MPLS značek jen pro transportní/loopback adresy, to by se pak mohlo dít, co popisuješ, že by to byl další bod, pokud OSPF bude vypdat OK.
Obecně má třeba problém kombinace, pokud jeden box dělá NAT a LSR funkci. Rozhodně, pokud se IP balí přímo do MPLS (ať už IP akcelerace nebo IP přímo uvnitř TE), tak aby daný router pokud možno pro tyto IP nedělal NAT/IPsec/queue, občas se to může pobít (což se asi dělo u tebe pro chybu v těch filtrech). A není to specifické jen pro LDP/PPPoE, ale jak se pobijí různé priority zpracování paketů v jednotlivých vrstvách při balení a vybaloaní z MPLS (podobný problém je třeba i při mixu IPsec a NAT na jednom boxu, pokud IP mám zároveň NATovat i cpát do IPsecu).
U LDP paranoidně nastavuji jak advertise, tak i accept filtry. Za určitých případů to může souviset i s L2MTU v síti, pokud není úplně správně nastaveno (VPLS se umí s tím vyrovnat, holé MPLS ne).
Jinak může to případně i souviset s nastavením LDP voleb distribute-for-default-route a use-explicit-null, oboje by pro tvůj případ mělo stačit na no.
Apropo, pokud se budeš nudit, hledám dobrovolníky, co by občas prskali na Mikrotik, že by i LDP vrstva mohla být schopna používat BFD.

[okoun]

aha, zajímavá informace, tedy já mám box kde mám vše v jednom tedy: NAT GW, OSPF, iBGP, MPLS, VPLS koncentrátor, PPPOE koncentrátor, takže to mám blbě když mám v mpls nastaveno jen interface backbonu a vyšší all interfaces mtu?
divný že to funguje ale