Mikrotik BGP problémák

 ( akoscomp | 2019. október 10., csütörtök - 8:49 )

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?

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

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

Kikapcsoltam a connection trackinget, de nem segít. Opnsens-en frr-el (quagga fork) próbáltam beállítani a bgp-t, de nem sikerült. Utánanézek a bird-nek...

~10 éve BGP-zek mikrotikkel, semmi gond nem volt vele... (és nem vagyok egyedül)
Az mondjuk biztos, hogy a BGP routeren semmi egyéb funkció nincs. Pláne nem conntrack.

és hány peered van, hány route/prefixe al ?
Valami statisztikát tolhatnál milyen vason stb.

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.

nálam 2 peer van, összesen ~240K prefixet kapok tőlük.
Intel server vas, i3 CPU, server NIC.
Mikrotik x86 verzió. Ennél ugye 2G RAM a limit.

Még élesítés előtt asztalon próbáltam, ~2 millio pps-el nem volt gondja.

ACL-ek vannak ?

Fedora 30, Thinkpad x220

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

"amikor garantáltan nincs aszimmetrikus routing." - ezt nem tudom értelmezni. hogyan tudod garantálni,hogy egynél több peer esetén ne legyen aszimetrikus routing ?

Pongyolán fogalmaztam, ténylegesen garantálni nyilván nem lehet.

s/garantáltan/jó eséllyel/g

é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)

Amióta itt lóg egy csokornyi üvegszál vége, azóta a sávszélesség nem nagyon szempont. A tartalékolásra csak azért van szükség, mert néha a környéken járhat a nagy sárga Caterpillar kábelkereső gép...

Ezeket érdemes elolvasni, egészen jól magyarázza az inbound és outbound BGP traffic engineeringet alapszinten.

https://www.noction.com/knowledge-base/multihoming
https://www.noction.com/knowledge-base/bgp-inbound-traffic-engineering

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:)

Elméletileg azért egy CCR-nek le kéne tudnia kezelni a 4 full view-t is, bár azt se mondta, hogy full view-t kap.
Mondjuk az eszköz típusát én is meg akartam kérdezni :-)

CCR1009-7G-1C-1S+ és RB1100AHx2 mikrotik-en próbáltam. Nincs full view, csak nemzeti tábla, ami 5000-50000 között mozog szolgáltató függvényében, de full view-t is elvitt a router.

sub

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

Mikrotik default config, kikapcsolt connection tracking-el. Más rejtett beállítás lehet, de nem valószínű. Az rp_filtert ellenőriztem még, az ki van kapcsolva.

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.

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

Ha nem lenne meg, szerintem probléma lenne akkor is, ha csak egy szolgáltató aktív. Miközben egy aktív szolgáltatóval tökéletesen megy mindegyik.

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