Mikrotik BGP problémák

Hálózatok általános

Van 4 internetszolgáltatónk (Prime Telekom, RDS, Telekom, Nextgen), amelyek egy Mikrotik router-ben BGP-vel vannak beüzemelve. Van saját AS számunk és IP osztályunk.
Két szolgáltató (rds és prime) tökéletesen működik, egyenként és együtt is, de ha bármelyik másik szolgáltatót aktiválom (Telekom, Nextgen), akkor már problémák vannak az interneteléréssel. Egyenként mind a négy szolgáltató tökéletesen működik és az IP osztályunk is elérhető kintről.
A BGP sessoin feláll, átjön a route tábla, tehát BGP szinten látszólag minden tökéletesen működik.

A probléma az interneteléréssel van. Egyes weblapok bejönnek, mások nem. A ping mindenhova megy és mindenhonnan bejön, a traceroute szintén működik. Úgy tűnik minden amihez nem kell kiépüljön kapcsolat megy. A legkézzelfoghatóbb probléma a weblapok elérésében van.
A tűzfalat nézve van kb 10 csomagváltás, és utána semmi. A böngészők mind a TLS kapcsolat felállásánál hasalnak el, mintha valami valahol blokkolná a kapcsolatok felállását. Csak azok a weblapok hasalnak el, ahol az egyik szolgáltatón megy a másikon jön a csomag. Ahol minden egy szolgáltatón megy és jön, az OK. A prime és rds esetén is van ilyen hogy itt megy ott jön, de az megy problémamentesen, ahogy normálisan mennie is kellene.

A probléma előjött 3 mikrotik routeren, az utolsón amin teszteltük, csak bgp volt, semmi más, semmi tűzfal, szűrés stb. egy teljesen tiszta router.

Nekem két tippem van, vagy a két problémás szolgáltató követi a kapcsolatokat és csak established-et enged át vagy a mikrotik kezel valamit hibásan. Mivel a telekom nagy szolgáltató, sok bgp ügyféllel, ezért kis esélyt látok a szolgáltató oldali problémára. Természetesen a szolgáltatók azt mondják, hogy náluk minden rendben van.

Valakinek van ötlete mivel lehet még bgp-t kipróbálni. Eddig egy opnsense-es routerrel próbáltam, de nem áll fel a bgp session és a logok sem túl beszédesek. Jó lenne egy szoftveres BGP megoldás, aminek beszédesek a logjai is.

Valaki találkozott esetleg hasonló jelenséggel?

  • 1922 megtekintés

( _ventura_ v | 2019. 10. 10., cs – 09:07 )

Mikrotikkel sose mertünk BGP-zni :D Esetleg próbáld meg sima linux + quagga vagy bird-el. Mikrotikből én bármit kinézek :D

Esetleg ha lehet kapcsold ki a connection trackinget. BGP routingnak nincsen szüksége rá, mikrotiket meg csak fogja.

Fedora 30, Thinkpad x220

Kb 5 éve nekünk be volt állítva 3 szolgáltató, mind a full táblával egy CCR1009-es Mikrotik-en és simán bírta a router. Ha jól emlékszem 1000000 fölött volt a routeok száma.
Végül lemondtunk a full tábláról, mert sok időbe telt betölteni (30-60s) és nem is láttuk sok értelmét.

( mauzi v | 2019. 10. 10., cs – 09:41 )

> Csak azok a weblapok hasalnak el, ahol az egyik szolgáltatón megy a másikon jön a csomag.

A BGP csak a routing táblát menedzseli, tehát, ha a routing tábla bejegyzései rendben vannak, akkor a probléma nem a BGP oldalán keresendő.

Az vígan lehetséges, hogy valamelyik szolgáltatónál van stateful szűrő és/vagy address translation. Monduk, ha tranzitálnak neked, akkor furcsállom, de lehet, úgy gondolják, hogy csak primary/backup scenarioban akarod őket használni, amikor garantáltan nincs aszimmetrikus routing.

Szerintem sem BGP probléma lesz az indoklásban egyetértek Mauzival. Inkább MTU és ICMP problémát sejtek mögötte. Teszteld azt, hogy különböző méretű csomagokkal pingeled azokat ahol gond van. Ha a kis csomagok átmennek és egy méret fölött meg nem akkor ez lehet a probléma. Velem fordult elő olyan, hogy út közben valaki eldobta a fragmenation needed ICMP üzeneteket melyek felém jöttek és emiatt mágikus módon a rövid teszt emailek átjöttek (belefértek egy kis csomagba) a nagyok nem.

és ezt hogyan tudod?
Nekem pl van két peer-em, egyik sem ad full view-t. Amire nincs route, az ugye megy a def.gw felé (a két def.gw nem azonos súllyal van befelé hírdetve).
Elképzelésem nincsen, hogyan lehetne a fenti esetben megoldani, hogy jó eséllyel NE legyen aszimetrikus routing, hiszen egyikünk se tudja, hogy a másik éppen merre akarja route-olni a csomagokat kifelé...

Mondom, primary/backup scenario. Amíg a primary kapcsolat él, addig az a cél, hogy minden arra menjen. Ennek megfelelően, a backup irányban szép nagy prepend van feltéve, így a gyakorlatban semmi produktív forgalom nem jön befelé azon a kapcsolaton. Hangsúlyozom: jöhetne, semmi garancia nincs rá, hogy nem jön - de nem jön.

OK, így értem. De ennek kb akkor van értelme, ha van egy "elhanyagolható" méretű backup vonalad, amit tényleg csak akkor akarsz használni, ha a másik nem megy.
Pl 100M vs 10M.
Már az 1G fővonalnál sem érné meg "csak vész esetén" használni a 100M másodlagos vonalat. Szerintem.
(hacsak nem forgalom díjas pl)

( NagyZ v | 2019. 10. 10., cs – 10:28 )

nem irtad pontosan hogy milyen mikrotik, de biztos, hogy 4 full feedet tud ez kezelni? 4 upsreamnel mar azert combosabb vasakat szoktak hasznalni, nem mikrotiket:)

( answ | 2019. 10. 10., cs – 12:26 )

"csak bgp volt, semmi más, semmi tűzfal, szűrés "
Ebben egészen biztos vagy?

( wpeople v | 2019. 10. 10., cs – 12:32 )

Több dolog üt szöget a fejembe:
1) a Mikrotik-en semmi nem fut (sem tűzfal, sem conntrack) így nem jönnek be bizonyos oldalak?
packet capture-t csináltál már esetleg a kérdéses kliens gépen, hogy mi lehet a gond? mi a különbség aközött ahol működik, és aközött, ahol nem?

2) ne csak traceroute hanem tracepath-t is használj (ez mutatja az MTU-t és az asymetric route-t is)

3) csodálkoznék, ha a szolgáltató stateful tűzfalat futtatna a BGP tranzithoz kapcsolódóan...

4) megnézném, hogy Telekom, csak Nextgen van, mindkettő működik-e problémamentesen, majd a kettő együtt.
Ugye BGP-n azt is tudod szabályozni, hogy merre küldöd a csomagot (routing szabályok) és hogy merre várod (prepend).
Azaz összerakhatod szándékosan az asymetric routing-ot oda és vissza irányban is. Talán ez segít a hibapont meghatározásában.

Esetleg próbáld még meg a Vyatta OS-t hátha ott könnyebben be tudod állítani a BGP-t mint Quagga-ban.

1. igen, úgy próbáltam, hogy semmi nem futott rajta és egy direkt mögé kötött gépen voltak problémák. Nem csináltam packet capture-t, csak azt figyeltem, hogy mi megy át a tűzfalon:
https://home.datanest.ro/d/11d6488098e042f9a3b8/
Ekkor még be volt kapcsolva a connection tracking.

Kipróbálom, csak mivel levágja a teljes osztályt az internet egy jelentős részéről, elég körülményes a tesztelés.

4. megnéztem és mind a 4 szolgáltató tökéletesen működik egyedül, a telekom és a nextgen együtt szintén nem működik, gondolom azok az oldalak mennek, amelyeknél a csomagok ugyanott mennek és jönnek.
Próbáltam 6x-os prependet betenni telekom-nak, mégis több esetben mégis ott jött vissza a csomag. Ez kicsit furcsa, de nem valószínű, hogy köze van a problémához.

A VyOS is quagga-t használ, de előbb utóbb az is sorra kerül. Most bird-el próbálom beállítani a bgp-t, egyelőre úgy néz ki sikerül is. Éjjel talán ki is tudom próbálni.

( csucsu | 2019. 10. 10., cs – 13:36 )

Nem lehet valamilyen MTU probléma?
Mindegyik szolgáltatónál megvan az 1500 ?

( akoscomp | 2019. 10. 11., p – 07:55 )

Leteszteltem Bird-el is a problémás szolgáltatókat, és így is előjön a hiba. Egyenként mennek a szolgáltatók, de együtt már nem.
Így már egyre valószínűbb, hogy a szolgáltató cseszhet el valamit, a kérdés csak az, hogy mit, figyelembe véve, hogy sok ügyfelük van és valószínű máshol nincs probléma.
A bird configja:

router id 203.0.113.1;
protocol kernel {
scan time 2;
import none;
export all;
}
protocol device {
scan time 2;
}
filter bgp_global_out {
if net = 203.0.113.0/24 then
{
accept;
}
else reject;
}
filter bgp_in {
if bgp_path.last ~ [ 48161, 39737, 8708, 9050 ] then { accept; } reject;
}
protocol bgp isp_nextgen {
local as 60033;
neighbor 192.0.2.1 as 48161;
graceful restart;
import all;
export filter bgp_global_out;
}
protocol static {
route 193.231.103.24/32 via 198.51.100.1;
}
protocol bgp isp_telekom {
local as 60033;
neighbor 193.231.103.24 as 9050;
multihop;
graceful restart;
import all;
export filter bgp_global_out;
}

én a következőt tenném:
elővennék egy munkaállomást (tetszőlegesen win v linux).
indítanék rajta egy full capture-t úgy is, h a problémás szolgáltatók ki vannak kapcsolva, és úgy is, hogy be vannak kapcsolva.
A kettő legyen külön file.
Ha értesz hozzá, nézd át, ha nem, akkor a kérdéses szolgáltató supportjának küldd el. A BGP tranzitot vélhetően nem gombokért kapod, dolgozzanak meg érte, ha el akarják adni a szolgáltatást. Max azt fogják mondani, h felszámolnak pár mérnökórát, de még mindíg előrébb vagy, mintha fizetsz egy havi díjat nekik és nem tudod használni...

( akoscomp | 2019. 10. 18., p – 08:19 )

Hosszú tesztek után, egyre valószínűbb, hogy a szolgáltatónál van a hiba, nem nálunk.
Voltak pillanatok, amikor úgy tűnt megy a pfSense+OpenBGPd illetve egy régi kukázott Cisco 1800-as routeren az internet, de felhúzva 3-4 szolgáltatót, hosszabban tesztelve a kapcsolatot, ismét előjött a kapcsolódási hiba.

Mivel a szolgáltatók cisco pártiak és nem valószínű, hogy másra ránéznek, ezért szükségem lenne egy cisco routerre.

Valaki tud javasolni cisco routert, ami csak BGP-t fog vinni és ezt meg tudja oldani 1 Gbps sebességgel, 4 IPv4 és legalább 2 IPv6 szolgáltatóval (6+ vlan-t kell vigyen).

Én is megelégednék két szolgáltatóval, éveken át annyi is volt, de a next-gen és a telekom, mivel nem akartunk már új szolgáltatót, ingyen adott internetet más szolgáltatások mellé, amiért fizetünk. Így lett 4 szolgáltató, és ha már van, és néha szűkös a két aktív szolgáltató által nyújtott 250 Mbps, akkor miért ne használjuk.
Szolgáltatónként átlag kb 50 euró az internet, összesen 550 Mbps a négy.

Ha egy 20000 Ft-s mikrotikkel is be tudom hozni BGP-n ezt az 550 Mbpst, akkor nem látom értelmét a 10000 eurós routernek, de még egy 1000 eurósnak sem feltétlenül. Inkább veszek 2 darabot, amit amúgy is ajánlott, valamivel olcsóbbat. Persze az világos, hogy nem 20000 Ft-s modellt veszek, hanem mondjuk valamit amiből két darab belefér 1000 euróba.

sokszor le lett már írva, hogy
1) nem a BGP a kunszt, hanem a route táblák feltöltése, pláne 4 feednél, pláne, ha full view-t használsz.
2) a másik dolog, hogyha a peer-jeid a Cisco-t támogatják, akkor vagy megoldod magadnak a problémádat, vagy megfizeted a Cisco-t.
(vagy azt, aki megoldja a problémádat)

Arra pedig, hogy 50EUR-ért megkapod a BGP feed-et nem tudok mit mondani... nyilván itthon ennyiért kb köszönnek neked :-)

Összesen 50000 bejegyzésnél kisebb a tábla. Nem a full-t kérjük a szolgáltatótól, hanem default route+közvetlen kapcsolatok, pont azért, hogy gyorsan menjen. Volt full tábla is, de fizetni soha nem kellett érte pluszba, sőt magáért a BGPért sem fizetünk, csak az internetért.

Én még nézelődnék kicsit, nem értem teljesen a jelenséget.
A jelek arra utalnak, hogy asszimetrikus routingod lesz - ami nem csoda - és valaki az utvonalon ezt nem értékeli.

Első kérdésem, hogy miért kell 4 szolgáltató? 2 szolgáltató, mindegyik 2, nyomvonalban külön álló linken bőven elegendő szerintem. Ha a nyomvonal nem tér el, akkor mindegy mennyi van, nem véd a markológép támadás ellen.

Aztán hogyan hirdeted a különbözű útvonalakat, honnan tudja a külvilág, hogy melyik bejáratot preferálod?
BGP-ben van MED, meg weigth, meg pár hasonló paraméter, de ezek legfeljebb a szomszéd AS-ig mennek, tehát a "távoliak" nem fognak tudni választani.

Ezért az as-path-prepend a szokásos technika:
- a normál utvonalat simán hirdeted
- a tartalék utvonalhoz 3x befűződ a sajat AS-edet, így a távoli routerek "távolabbinak" látják (kicsit egyszerűsítve, a BGP AS hop számot néz első sorban).

Ekkor ha az első kapcsolat elhullik, akkor minden szépen átáll a másodikra. Persze annyi idő kell az átálláshoz, míg mindez bgp-n szépen elterjed.

Azt ,hogy mit lát a nagyvilág, valamilyen looking glass-al tudod megnézni, pl:
https://www.cogentco.com/en/network/looking-glass

Érdemes egyrészt a traceroute, másrészt a bgp-n meg tudod nezni nem csak a legjobbat, hanem hogy milyen alternativakat "hall".

Az 1Gbps nem teljesítmény egy mai routertől, a több full bgp tábla kezelése már igen. Mikrotik után szerintem dobnak egy hátast az NCS vagy ASR ára hallatán.

Nekem jó tapasztalataim vannak az ncs5500-el, bár SPF-eknél válogatós, és néha érzékeny a szemben lévő eszközzel a auto negotiation-ra. De cisco viszonylatban olcsó és combos, ha csak routeolni akarsz, és nem kell egyéb csoda szolgáltatás.

Üdv,
-=Lajbi=-------

> a 4 feednek sincs ertelme, amig egyszem SPOF eszkozben vegzodnek...

Azt mindig tartsd szem előtt, hogy egy esetleges probléma esetén erősen nem mindegy, hogy képes vagy-e saját hatáskörön belül megoldani a problémát, vagy ki vagy szolgáltatva másoknak.

Lehet, hogy a telephelyi router SPOF, de ha képes vagy a helyszínen azonnal, vagy egy nektek elfogadható időablakon belül kicserélni a polcon csücsülő hidegtartalékra, akkor sokkal előrébb vagy, mintha elmarkolják a kábelt a szomszéd utcában, esetlegesen napokba telik, míg a szolgáltató befoltozza, neked meg nincs kellő alternatív peeringed másik irány(ok)ba.

A BGP-nek több paramétére is van, ami a többszörös kijáratokat kezeli:
- WEIGTH: cisco specifikus, a routeren belüli paramétere
- LOCAL_PREF: a nagyobb a preferált kijárat. Ez a paraméter "utazik" az AS-en belül, de nem hagyja el azt. Tehát iBGP-n átadódik, normál (e)BGP-n nem.
- MED, MULTI_EXIT_DISCRIMINATOR: átadódik a _szomszéd_ AS-nek, de tovább nem. Ez akkor lehet hasznos, ha több "kijárat" léteik, de azonos AS-ben van.
- AS_PATH: ezt átmegy minden, mindenki "befűzi" magát, ez jól látszik "messziről" is. Ezért szokás az "as prepend" technika.
A preferalt kijárat AS path-a pl így néz ki: AS1, AS2, AS3, AS4
Ugyan így, AS4-ből a tartalék kijárat: AS1, AS1, AS1, AS1, AS2, AS3, AS4. Ez ugye hosszabb, ezért amig létezik, a másikat fogja választani.

Abban igazad van, hogy a 4 feednek nincs értelme, 2 bőven elég.

A másik az, hogy a BGP memória igényt is erőst lehet csökkenteni. Ha nem akarsz egyszerre mindkét AS-el beszélni, vagy terhelést elosztani, akkor elég, ha a default route hirdetést fogadod el, a többit meg kiszűröd.

Ha van AS2 és AS3 szolgáltatód, és nem akarod, hogy az AS3-ba menő forgalom átmenjen AS2-n, akkor nem csak a default route-ot fogadod el, hanem mondjuk minden, max 1 hosszú as path fogadsz el, pl:
ip as-path access-list fromispa permit ^(ispaas)_
ip as-path access-list fromispb permit ^(ispbas)_

BGP-vel nagyon sok mindent meg lehet csinálni, de nagyon oda kell figyelni. IGP-vel (OSPF, IGRP) elizélheted a saját hálózatodat, de BGP-vel ha "ügyes" vagy, akkor nagy kárt tudsz okozni másnál is :)

Ha nem vagy biztos a dolgodban, akkor virtgépeken (cisco ios esetén pl gns3-al) lehet modellezni, kisérletezni.

Üdv.
-=Lajbi=-------

Fentebb megírtam miért van 4 szolgáltató, röviden, így sikerült.

A négy szolgáltatónak a sebessége hasonló, ezért nem túlzottan érdekel, hogy mi hol megy, ameddig nincs túlterhelve az egyik. Ilyen már volt régen, akkor prepend-el oldottuk meg.

Most egy ASA5506 van kéznél, annál pl 500 Mbps-nek van megadva a throughput. Az ASA tűzfal, tehát nem erre való, és pont emiatt nem kapcsolható ki a statefull tűzfal, ami korlátozza a sebességét, de a jelenlegi tempót elvinné ez is, de hosszabb távon, már kevés lenne. Ezért írtam, hogy vigye az 1 Gbps-t, mert Cisco-ból kinézem, hogy olcsóbb modelleknél korlátozzák a sebességet, csak hogy a drágábbat vedd.

NCS5500-at legolcsóbban 32000$ért találtam. Ebből kiindulva valószínű nekem is jó tapasztalatom lenne vele, de ez talán egy picit sok arra amire nekem kell.

( PunishR v | 2019. 10. 19., szo – 09:06 )

Kicsit hosszú mar ez a topic és lehet én siklottam el felette, de egy összefoglalót írjál kérlek az alábbiakkal.

Uplinkek száma: ahogy láttam talán 4
Link típusa: !G/10G optica/réz akármi
Kapott IPv4 prefixek száma: ?
Kapott IPv6 prefixek száma: ?
Downlink típusa a hálózatod fele: ?

ezekből mar egyszerűen lehet javasolni valami normális, de mára már olcsóvá vált L3 switchet/routert kezdve mondjuk egy 4849E-vel

köszi