zkušenosti BGP/VPLS na mikrotiku?

[okoun]

ahoj, má prosím někdo zkušenosti s BGP/VPLS na mikrotiku? případně mi napiště SZ, mám neustálé UP/DOWN tunelů přitom trasy nechybují a dělá to jen jedna strana tunelu, mám jich cca 67 VPLS

[pgb]

Mi jede vpls staticky mezi loopbacky (ospf) a nedělá to problémy.

Když jsem k tomu přidal ještě BGP, tak to sice díky route reflect nastavovalo vpls samo, ale narážel jsem na prapodivné chování RSTP na bridge (i při použití bridge horizon) a ve výsledku to byla hrozná divočina, nějak jsem nepochopil, když jsem bridge horizon použil, proč to různě shazovalo vpls. Jediným řešením v mém případě bylo vypnout RSTP na jenom konci tunelů ..... PS: je mi jasné že to není stejný problém který popisuješ

[okoun]

Nu neni jasne proc by rstp melo zabijet vpls tunely? Rstp by melo akorat prepinat mezi ne provoz ne? Jinak horizon to rstp znici pac tim neuzavres tu smycku, ne?

[pgb]

Znovu opakuji tato situace nevyvolá stav UP/Down tunelů, pouze tudy pak neproudí data a neřeší tvůj problém. Zkus tam ten tunel pustit staticky,

RSTP ty tunely neshazovalo, je to problém jiného charakteru. V mém případě šlo o to, že hlavní R1 navazoval pomocí bgp vpls mezi R1-R2 a R1-R3. Díky BGP s route reflect se vytvořilo i vpls mezi R2-R3 => zde vzniká potenciál na smyčku, proto je nutno použít bridge horizon.

V tuto chvíli dochází k zajímavému stavu, kdy R1,R2 a R3 mají vpls připojené pokaždé do br0, kdy RSTP na br0 si i přes bridge horizon začne vytvářet samostatnou topologii a tato topologie se pak tříská s topologií horizonu a data neproudí. Stačí vypnout RSTP na R2 a R3, všude mít nastavený horizon a vše funguje dobře.

[okoun]

no to se dá řešit pomocí bridge filtru...

[pgb]

jj, řešit to jde různě, jen mě to zaskočilo

[Majklik]

ahoj, má prosím někdo zkušenosti s BGP/VPLS na mikrotiku? případně mi napiště SZ, mám neustálé UP/DOWN tunelů přitom trasy nechybují a dělá to jen jedna strana tunelu, mám jich cca 67 VPLS

Jo, také mi na pár místech dělá VPLS down/up v inervalech (cca 5x za den bez zjevné příčiny/výpadku linek/LDP/OSPF/BGP) z jedné strany, na nic to nemá reálně vliv (a je jedno, zda je tam BGP neb LDP signlizace). Že ti to dává down/up jen z jendé strany je možné. VPLS jsou fakticky dva jednosměrné tunely proti sobě sestavované samostatně, navíc charakteru pevný okruh, takže jakmile MPLS vrstva se rozhodne něco změnit, třeba poslat to výhodnější trasou, tak dojde k down/up eventu, protože se změní prametry sestaveného tunelu (trasa). Nicméně u toho nedojde k ztrátě dat, max pár paketů co je právě v bufrech okruhu a jede se dál.
Pokud to ale nakombinuješ s (R)STP, tak RSTP vrstva ti to výrazně zhorší, protože reaguje na down/up event, hodí port s tunelem do blocking stavu a zkoumá, co je na druhé straně a zabere ji to tak 2-4 sekundy, kdy ti blokuje provoz daným tunelem (a může i blokovat i 15 sekund, pokud to padne do STP režimu learning stavu portu).
Takže bych se snažil zbavit toho RSTP, pokud VPLS smyčkuješ, tak řešit pomocí horizontování, které je k tomu určeno (nebo toho bridge filtru, ale když jsem to zkoušel, tak horizontování bylo méně zatěžující).
Co způobuje to časté down/up je věc druhá. Zde je velký problém ROSu, že stále slova jako logování a debug stavu ve vzthu k MPLS vrstvě je v daleké budoucnosti...

[Majklik]

narážel jsem na prapodivné chování RSTP na bridge (i při použití bridge horizon) a ve výsledku to byla hrozná divočina, nějak jsem nepochopil, když jsem bridge horizon použil, proč to různě shazovalo vpls. Jediným řešením v mém případě bylo vypnout RSTP na jenom konci tunelů

Tak od oka se dá říci, že namixovat RSTP a horizontování nebude dobrý nápad. RSTP vrstva bude ctít horizonty, takže to způsobí blokaci šíření TCN paketů, takže se nemusí dozvědět celá bridge síť o změnách topologie a bude z toho dost na větvi. Pokud něco kombinovat s RSTP, tak leda tak Auto isolate, ale i to je mířeno spíše na metalické/optické porty a ne tunely (u BGP VPLS ani nejde použít).

V mém případě šlo o to, že hlavní R1 navazoval pomocí bgp vpls mezi R1-R2 a R1-R3. Díky BGP s route reflect se vytvořilo i vpls mezi R2-R3 => zde vzniká potenciál na smyčku, proto je nutno použít bridge horizon.

Pak jsi měl ten BGP VPLS blbě nstaven. Pokud nechci, aby mezi R1, R2 a R3 vznikl úplný trojúhelník tunelů, tak to nastvíš pomocí import route targets. Na R1 dáš naimportovat R2 i R3. Na routerech R2 a R3 dáš nimportovat jen target R1. Tím ti vznikne Véčko s vrcholem v R1 a jen dvěma tunely R1-R2 a R1-R3. Pokud na všech třech routerech naimportuješ ID obou zbývajících routerů, tak uděláš trojúhelník s třema tunely a smyčkou.

[okoun]

ahoj, má prosím někdo zkušenosti s BGP/VPLS na mikrotiku? případně mi napiště SZ, mám neustálé UP/DOWN tunelů přitom trasy nechybují a dělá to jen jedna strana tunelu, mám jich cca 67 VPLS

Jo, také mi na pár místech dělá VPLS down/up v inervalech (cca 5x za den bez zjevné příčiny/výpadku linek/LDP/OSPF/BGP) z jedné strany, na nic to nemá reálně vliv (a je jedno, zda je tam BGP neb LDP signlizace). Že ti to dává down/up jen z jendé strany je možné. VPLS jsou fakticky dva jednosměrné tunely proti sobě sestavované samostatně, navíc charakteru pevný okruh, takže jakmile MPLS vrstva se rozhodne něco změnit, třeba poslat to výhodnější trasou, tak dojde k down/up eventu, protože se změní prametry sestaveného tunelu (trasa). Nicméně u toho nedojde k ztrátě dat, max pár paketů co je právě v bufrech okruhu a jede se dál.
Pokud to ale nakombinuješ s (R)STP, tak RSTP vrstva ti to výrazně zhorší, protože reaguje na down/up event, hodí port s tunelem do blocking stavu a zkoumá, co je na druhé straně a zabere ji to tak 2-4 sekundy, kdy ti blokuje provoz daným tunelem (a může i blokovat i 15 sekund, pokud to padne do STP režimu learning stavu portu).
Takže bych se snažil zbavit toho RSTP, pokud VPLS smyčkuješ, tak řešit pomocí horizontování, které je k tomu určeno (nebo toho bridge filtru, ale když jsem to zkoušel, tak horizontování bylo méně zatěžující).
Co způobuje to časté down/up je věc druhá. Zde je velký problém ROSu, že stále slova jako logování a debug stavu ve vzthu k MPLS vrstvě je v daleké budoucnosti...

díky za reakci, ale netuším jak to myslíš s tím horizontováním vpls? možná je to jen tim horkem tady
mám z AP dvě vpls cesty ke dvoum branám, RSTP se stará o to aby v případě výpadku tunelu na bránu se to přehodilo na druhý tunel tedy i bránu. takže vypnu rstp a zapnu horizont? to přeci bude chodit do obou tunelů ne? akorát ty dva tunely nebudou komunikovat spolu no....

[pgb]

V mém případě šlo o to, že hlavní R1 navazoval pomocí bgp vpls mezi R1-R2 a R1-R3. Díky BGP s route reflect se vytvořilo i vpls mezi R2-R3 => zde vzniká potenciál na smyčku, proto je nutno použít bridge horizon.

Pak jsi měl ten BGP VPLS blbě nstaven. Pokud nechci, aby mezi R1, R2 a R3 vznikl úplný trojúhelník tunelů, tak to nastvíš pomocí import route targets. Na R1 dáš naimportovat R2 i R3. Na routerech R2 a R3 dáš nimportovat jen target R1. Tím ti vznikne Véčko s vrcholem v R1 a jen dvěma tunely R1-R2 a R1-R3. Pokud na všech třech routerech naimportuješ ID obou zbývajících routerů, tak uděláš trojúhelník s třema tunely a smyčkou.

Blbě a blbě v rámci testu a laborování je to jedno, učil jsem se a narazil na tohle, že tam jsou import/export route targetx a jak je využít vím, ale to rstp bylo pro mě prostě překvapení

[Majklik]

Blbě a blbě v rámci testu a laborování je to jedno, učil jsem se a narazil na tohle, že tam jsou import/export route targetx a jak je využít vím, ale to rstp bylo pro mě prostě překvapení

Nu, VPLS/MPLS v podání ROSu je jedno velké překvapení (hlavně z pohledu, co vše to ještě neumí). Teď jsme listoval jedním blábolem k RSTP a asi by to ta mohlo být, že pokud RSTP vrstva bude brát ohled na nastané horizonty portů, tak asi nebude předávat notifikci o TC a tak se to celé rozpadne.
Že by ale RSTP vyložene shazovalo VPLS tunely, to jsm nepotkal, že tunel je up a pak netečou data, to je věc jiná (k tomu může dojít i z jiných důvodů, často pokud VPLS jako transport IP použije blbou IP adesu a ne tu lookpackovou). Jinak pád a znovu navázání celého BGP VPLS tunelu dojde ve chvíli, kdy se ti změní číselné označení tunelu, dokud to vplsX má pořád stejné číslo X, tak se signaliačně přes BGP vidí, při změně čísla tunelu, došlo k novému úplnému sestavní tunelu. Down/up eventy jsou pak jednotlivé aktualizace konfigurace tunelu.

[pgb]

Ano, to jsem psal výše, rstp tunely neshazuje, jen tam tudy neproudí data (ve specifických situacích). Číslování tunelů mne zaskočilo, ale na funkčnost to nemá vliv, když mi při laborování naběhl tunel číslo 124 . Vadí mi, že třeba mpls není na ipv6 , alespoň to tak před nějakou dobou bylo.

[Majklik]

díky za reakci, ale netuším jak to myslíš s tím horizontováním vpls? možná je to jen tim horkem tady
mám z AP dvě vpls cesty ke dvoum branám, RSTP se stará o to aby v případě výpadku tunelu na bránu se to přehodilo na druhý tunel tedy i bránu. takže vypnu rstp a zapnu horizont? to přeci bude chodit do obou tunelů ne? akorát ty dva tunely nebudou komunikovat spolu no....

To chce rum, nejlépe rumovou zmrzlinu flambovanou brandy. Sice to nepomůže ale bude ti to aspoň jedno.

Jak to máš uděláno, to máš z gwA, gwB a AP trojúhelník jako smyčku a tu hlídáš pomocí RSTP? Ale těch AP máš tunu, to máš ke každému samostatný trojúhelník nebo máš jen jeden agregační bod gwA a gwB z kterého jdou hromdy VPLS k AP1 až APn? Pokud to druhé, tak chvíli může trval, než ty změny topologie RSTP obkrouží přes těch 60 VPLS linek.

Pokud to nastavíš úplně pomocí horizontování, tak provoz od klienta může jít jen do VPLS a zpět, ale nepůjde provoz mezi VPLS tunely vzájemně (na gw i ap).
Provoz ti normálně nemá jít do obou tunelů na AP, uplatní se bridge a forward tabulka, Takže prvně do obou VPLS tunelů ti jde akorát PPPoE discovery od klienta a až mu některý PPPoE server odpoví, tak pak provoz PPPoE klient-server jde jen tím konkrétním tunelem. Který PPPoE server má být backup, tak ho zpozdíš o sekundu-dvě pomocí pado-delay, aby klientovi prvně došla odpověď od primárního PPPoE, pokud pojede. U toho RSTP a pokud tam máš úplnou smyčku gwA-gwB-AP s tím, že RSTP ti blokuje linku gwB-AP, tak to RSTP přirozeně tvoří zpoždění na úrovni toho pado-delay. U toho RSTP také, pokud je klient spojen na gwA a teoreticky padne tunel gwA-AP, tak může umožnit, by dál jet proti gwA PPPoE druhou trasou přes gwA-gwB-AP. Při úplném horizontování to nepůjde, při ztrátě VPLS gwA-AP to musí přejít na gwB PPPoE server (jde to dokopat, aby to šlo, ale je to už trochu složitější).
Jinak na tom AP s tím horizontováním jsem to myslel cca takto:

Kód: Vybrat vše

/interface bridge
add admin-mac=02:00:00:00:01:71 arp=disabled auto-mac=no mtu=1500 name=bridge-pppoe-forward protocol-mode=none
/interface bridge port
add bridge=bridge-pppoe-forward interface=wlan1 horizon=2
add bridge=bridge-pppoe-forward interface=wlan2 horizon=2
/interface vpls bgp-vpls
add bridge=bridge-pppoe-forward bridge-horizon=1 \
    export-route-targets=166:171 import-route-targets=166:11,166:12 name=vpls-pppoe-forward route-distinguisher=166:10 site-id=171


Tohle by mělo udělat, že ty dva VPLS tunely až s nhodí, přidjí se do bridge s horizon 1, takž mezi nim rpvoz nejde, wlan interfejsy mají horizon 2, takže oěpt wlan mezi ebou se nevidí, ale jde jen prozov mezi vpls<->wlan porty.

[okoun]

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...

[Majklik]

Číslování tunelů mne zaskočilo, ale na funkčnost to nemá vliv, když mi při laborování naběhl tunel číslo 124 . Vadí mi, že třeba mpls není na ipv6 , alespoň to tak před nějakou dobou bylo.

Add číslování - v základu by stačilo, kdyby místo obecného vpls to použilo ten prefix name definovaný u BGP VPLS tunelu jako name, protože pokud mám spojení třeba k 15-ti různým protistranám, několik BGP tunelů k různým účelům, tak pak je chaos dohledávat který tunel je k čemu.
Ohledně MPLS a IPv6 jde o dvě věci, zda má fungovat MPLS přes IPv6 only síť nebo dual stack IPv6+IPv4, což řeší podpora LDPv6. Nebo je požadavek, aby MPLS transportovalo uvnitř sebe přímo i IPv6 provoz (ať jako IPv6 akcelerátor nebo jako TE tunely). ROS neumí ani jedno. Takže jen transport přes IPv4 síť a IPv6 nést uvnitř VPLS, ať už přímo jako Ethernet tunel nebo ještě vnořené PPPoE, jak to má teď okoun.
Ale ta MPLS vstva neumí tunu dalších podsttných věcí, například fast reroute, MPLS ECMP, auto tunely, vícenásobné LSR na router a hlavně žádný debug/log MPLS činnosti, což je při jakémkoliv problému těžká pakárna, když nemáš křšťálovou kouli (ta dle odborníku musí mít průměr minimlně 30 cm a tolerance kulovitosti jen do 0,005 mm, aby "odborníkovi" v ruce fugovala, sežen něco takového, když nemáš rotačku na bankovky ).