Sziasztok,
Routert virtualizálnék. Ha lehet, Mikrotik-et :-)
ProxMox-al próbálkozok, de sajnos komoly limitbe ütközök: ~5gbps-nél nem nagyon akar gyorsabban menni a hálózat két VM, vagy VM és fizikai port között.
A tesztasztalon van 2 mikrotik amik egymás között ~8.5gbps átvitelt produkálnak btest-el, UDP-n.
Ha linuxon (hypervizor szinten) route-olok v bridge-elek, akkor uez a sebesség.
Ha a gépben lévő dual 10G portjait bridge-elem a VM interface-eihez, akkor ~5gbps a sebesség, attól függetlenül, h a VM az linux, ROS chr, v ROS x86
kivéve, ha SR-IOV virtual function-en átadom a kártyát a VM-nek. Akkor mint hypervizor layeren: ~8.5gbps
Sajnálatos módon a Mikrotik ROS nem ismeri az SR-IOV virt.interface-t. Én meg a linux alatti FRR routingot...
Valakinek tipp esetleg? Mit kéne/lehet tuningolni?
Hozzászólások
Sub
nincs nagy meglepetes hogy az SRIOV mukodik megfeleloen: a tobbit elveszted a sok szoftver retegben. sokan megenekeltek mar ezt. egy UDP stream (mint ahogy egy TCP stream) ennyit tud ebben a felallasban. ha tobb streamet tolsz gondolom kijon a 8.5GBps a VMben is.
az frr nem az ordogtol valo, mi hasznaljuk elesben. ha most epitenek valamit, en biztos SRIOV + kedvenc disztrib friss kernellel + frr kore epitenem.
Ez érdekel, az ffr-vel (bgp+vxlan?) hogy hoznád össze az SRIOV-t?
nem biztos, hogy ertem a kerdest. mi koze az frrnek ahhoz, hogy az interfesz amit programoz a kernelen keresztul az milyen szinu/nemu/faju?
Túlkombináltam, újraolvasva már egyértelmű.
Nyilván nem azon lepődök meg, hogy SR-IOV-van működik, hanem azon, hogy a többin nem :-)
Nem, 20-50 stream esetén sem vidámabb az eredmény...
Persze, nem ördögtől való. OSPF-re használom a Quagga-t (és az FRR elvileg quagga fork - inkább a BGP filterek online klikkelős kezelhetősége miatt örvendenék a Mikrotik-nek)
Esetleg a multiqueue-t megpróbálhatod KVM-virtio párossal (én is kíváncsi lennék az eredményre, mert a vége itt is SR-IOV lett).
egy streamen az hogy tud segiteni? a hashing mindig egy queueba fogja dobni a streamet.
Egyen sehogy, te többön talán. De ezek szerint nem sokat azon se (ahogy lentebb olvasom).
próbáltam, nem (sokat) segített
nemide
ezzel hogyan oldhato meg hogy kvm (proxmox) ket vm kozott is meglegyen a 10G? (vm1 eth0 -> host brX -> vm2 eth0)
A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!
Igyvan, sajna ennyit tudnak a paravirtualizalt network interfaceek... Aztan meg maga a routeolas is viszi az eroforrast, hardveres tamogatas nelkul...
Első körben azt feltételeztem, hogy a linux bridge-ben van valami limitáció, de kipróbáltam: abban nincs.
Hypervisor szinten route-olva a NIC 2 lába között 10G forgalmat - szinte meg sem látszik a terhelés.
Egy full view esetén a route-ok beillesztése számolása kb egy teljes magot elvinne - de ezzel sincs gond, mert van belőle bőven.
Általánosságban ez ennyit tud, mert a guest szintről több mem copy-val kerül le a csomag a kártyáig/másik vm-ig.
Erre pár éve a "zerocopy" (pl. vhost-user) volt a megoldás, míg hw irányba a dpdk. Ez egyben egy ovs-dpdk + pmd -vel megugorható (van hátránya is), de a proxmox mintha nem támogatná. Mostanában a AF_XDP + eBPF megoldásokról lehet sokat hallani, de az még ovs szinten is experimental. Sajnos konkrét tapasztalatom nincs ezekkel, csak távolról láttam ezen megoldásokat.
És akkor még a VM-en belüli routing performanciájáról nem is beszéltünk...
ezek szerint marad iránynak az SR-IOV? :-)
Kipróbálhatod még ezt: https://github.com/FRRouting/frr/wiki/Alternate-forwarding-planes:-VPP
Sosem próbáltam, viszont ez VPP (FD.io, DPDK alapú) dataplane + FRR routing és elvileg elég gyors. AF_XDP itt szerintem egyelőre felejtős, iszonyat sok meló lenne benne bármit értelmesen implementálni benne, jelenleg pedig nem ismerek semmit ami működne. Sima XDP eBPF kódból elérni a routing táblát fib helperekkel, így működhet interfészek közti redirect FRR által bekonfigolt route szabályok alapján, viszont erről sem láttam semmi kész szofvert a kernel forrásban lévő sample alkalmazáson kívül.
A DPDK saját KNI-je elég lassú, amit az AF_XDP PMD segít, viszont az meg hardver felé lassabb mint a "default" DPDK. Ellenben 10Gbps tartományt mindkettő képes kiszolgálni. Elméletileg egy OVS-nek csak egy kapcsoló, hogy AF_XDP vagy XDP módban fusson így külön támogatás Proxmox felől (bár sosem használtam) nem hiszem hogy kellene.
Viszont: 8.5Gbps SRIOV-n az bármilyen más virtualizáció mellett sem lenne sokkal több 5Gbps-től, legalábbis nekem ebből az jön le hogy maga a hypervisor a bottleneck.
Az SR-IOV-re referálva mondom, hogy a setup az alábbi:
RB4011_A -> IntelX520 SFP+ port1 (PC) IntelX520 SFP+ port2 -> RB4011_B
Azaz a sebesség 8.5Gbps be és uennyi ki. Hypervisor-on át is.
DPDK-ra alapulo megoldasok isz szoba johetnek. Lasd OVS-DPDK.
De a problema marad. Le kell nyulnia a virtualizalt entitasnak a HW-t. Amigy nincs HW szinten virtualizacio, addig az egeszet. SmartNIC-ek eseten maga a HW ad majd egy szeletet...
SR-IOV + PCI Passthrough megoldással a gond, hogy a VM nem live migrálható, bár igaz routert nem is biztos, hogy kell.
Megnéztem az ovs-dpdk csomag szintjén megjelent a proxmox 6.2-ben, de a vhost-user támogatás még nincs benne, így nem fog menni gányolás nélkül.
Esetleg nézd meg az újonnan bevezetett SDN (ffr-re épül) támogatást - bár még beta - amivel a routolást a host szintjére le tudod vinni. Igaz ez nem oldja meg a VM network performancia problémát.
Ez utóbbit fogom 1-2 hónapon belül tesztelni (bgp-evpn+vxlan), igaz a routing switchen fog megtörténni.
De ha találsz bármi jó megoldást, kérlek oszd meg, mert engem is érdekel. :)
a bgp-evpn+vxlanhoz mi a terv a vtepek keszitesere? milyen orchesztracio fogja megcsinalni?
A proxmox nodeokon a VTEP, VNI, stbket a beépített SDN megoldására bízom (a VM-ek miatt ez a célszerű). Ebbe meg lehet adni external nodokat/gw-ket ami pedig a két fizikai switch lenne. Ez utóbbit talán neutonnal hajtanám meg és később esetleg lehet neutron db->proxmox szinkront, vagy minimalista ml2 drivert hegeszteni hozzá.
De ez egy kis rendszer (5 node), így akár az is lehet, hogy egy egyszerű előredefiniált ip rangek kerülnek vrfbe a switcheken, míg a nodeok felé csak szimpla VLAN. Vagy a másik irány, hogy csak a proxmox SDN-je lesz használva és az L3 routing is ott történik. Szóval megnézem mit lehet kihozni ebből, úgy hogy ne bonyolítsam túl...
Nem teljesen ez a tema, de nekem is van gondom a virtualis routerrel/tuzfallal (OPNSense) 1 Gigabit-es netet routolok, de a CPU-t teljesen felzabalja (Persze ez home server, egy i3-as procival) Ha tudtok valami eroforraskimelo route trukkot OPNsense alatt, azt megkoszonom :)
sub
Rendeltem egy Ryzen 3900X-et 32GB rammal, még várom hogy az alaplap és a memória megjöjjön. Telepítek rá OPNSense + FreeNAS + Kubernetes kombót. Ugyanúgy gigabites netet fogok routolni úgyhogy minden ötletet szívesen fogadnék én is.
nekem egy i3-520 -as 1U intel az ex-bgp routerem. 1G-t simán route-ol, ~2m pps-ig tesztelve asztalon...
Biztos, hogy a routing viszi el a processzoridot, es nem a firewall?
Egy kicsit is bonyolultabb szabalyrendszer is meg tudja fogni a gepet. Nem is beszelve elgy bonyolult (vagy elbonyolitott) megoldasrol, amit nem optimalizalnak megfeleloen.
Ezt mikrotiken könnyű kiszűrni. Ha a firewall a szűk keresztmetszet, akkor ki kell próbálni fasttrack-kel. Viszont ha eddig is be volt kapcsolva a fasttrack, akkor biztos nem az a gond.
egyetlen firewall szabály sincs az egész gépen. sem host,sem guest...
Nincs semmi Extra Firewall rule, kb tiltok mindent es ennyi (talan van 4-5 forward, de ezt nem neveznem bonyolultnak)
CPU problémáról már írtam:
https://hup.hu/comment/2481513#comment-2481513
Igen es neztem is :) De ez idle alatt is jelentkezne nem? Nalam akkor ugrik meg latvanyosan a CPU, ha tenylegesen route-ol. (pl speedtest)
Fogadni merek, hogy PPPOE-t használsz a WAN oldalon :)
Erre nem találtam megoldást én se, csak kerülőmegoldás van.
A probléma hogy a FreeBSD PPPOE program (mpd) csak 1x CPU (1-szál)-t képes használni, tehát hiába adsz hozzá CPU magot a VM-hez, nem növekszik a teljesítmény.
Linux-hoz van (rp-pppoe) program, ami több CPU/több szálat képes használni, tehát ott elméletileg több cpu mag kis terhelése mellett képes a teljes WAN sávszélességet kihasználni.
Kerülőmegoldás, hogy a FreeBSD (pfsense) előtt termináljuk a PPPOE-t, utána sima ethernet kapcsolattal adjuk át a FreeBSD (pfsense)-nek.
Megoldások:
-Virtualizáció (pl.: VyOS): Ebbe rp-pppoe van alapból, és van HA, szép CLI de nincs GUI. (félig fizetős, nightly-build ingyenes)
-Hardveres Router: 1G PPPOE nehéz probléma, ehhez kb. Cisco ASR1000 típusú eszközre van szükség, ami ki is tudja hajtani a sávszélességet.
-Egyéb: Létezik ilyen?
Igen, nem PPPOE WAN, de a szolgáltatónál csak az van :)
Igen, PPPOE van, elotte VyOS-t hasznaltam, de azzal is ugyanez volt, sot OPNSense -el meg jobb is...
Az tisztan latszik amugy top -H -S -nel, hogy az osszes mag ki van hajtva speedtestnel.
Digi 1 Gbps PPPoE-t mezítlábas Asus router-ek kihajtják, mondjuk sok szabály nincs bennük.
https://naszta.hu
Ha virtualizált router, akkor VyOS a legjobb választás. Eleve erre készült.
Egy másik topikban IOMMU/SR-IOV megoldás helyett írtam egy alternatív megoldásról:
https://hup.hu/comment/2481876#comment-2481876
Akinek van ideje/hardvere azt tesztelhetné :)
Témában egy kis frissítés:
SONIC - https://github.com/Azure/SONiC/wiki/Supported-Devices-and-Platforms
Röviden "enterprise" eszközökre Linux-t raknak (debian alapú) és docker-ben futnak az egyes szolgáltatások, van rendes driver különböző eszközökre, ezáltal a L3 router funkciók hardveresen gyorsítottak ~ line rate.
A WAN funkciók ( NAT, PPPOE, stb ) - hardveres gyorsítása ( P4 - DPDK) chipsettől függ: BCM Trident3 , BCM Trident4 , Mellanox Spectrum 2, Mellanox Spectrum 3, Tofino: van hardveres NAT lehetőség a többiben nincs ( kérdés mennyire működik ).
Teszteléshez talán az ARISTA switchek tűnnek a megfelelőnek (pl: 7050QX-32S: BCM Trident2 ) - saját bootloader van (Aboot) nem kell hozzá ONIE.
Itt egy kis bemutató mi is a SONIC:
https://www.youtube.com/watch?v=DvFTCpwnUQ4
engem nem gyozott meg a cumulus utan, foleg, hogy ahhoz kepest irto fapad az egesz.
Elárulod mi a use-case, ahol 10Gbps+ az elvárás virtuális router-től?
Mi évek óta használunk élesben különböző virtuális hálózati eszközöket (többnyire OpenStack-en), de egy-két speciális esettől eltekintve (cloud backup/migráció) nincs ekkora igény sehol és a saját TCO kalkulációink alapján bizonyos sebesség felett (nehéz meghatározni mennyi mert use-case válogatja és vannak kivételek, de kb. 5Gbps) nem nagyon éri meg a virtuális eszköz nagyobb mennyiségben, inkább akkor valami contextesíthető fizikai eszköz ASIC-el.
Ahol kell ott nativ linux alapú hálózati eszközök jól mennek SR-IOV-vel, itt egy jó prezi indián barátainktól mire érdemes figyelni:
https://www.youtube.com/watch?v=pNKQeZwnRCU
MikroTik-el nem teszteltem még, ha azóta van valami új eredményed oszd meg.
Enterprise class router-t (juniper, cisco, etc.) nem használunk SR-IOV-vel, mert a L2 chanelling nem hibatűrő.
Többi helyen VPP tökéletesen működik alacsonyabb sebességeken (5Gbps és alatta), persze megint attól függ ki mire használja. A lenti tanulmányok alapján látható, ha csak sima routing-ra akarod használni a cuccot, akkor az SR-IOV a legjobb megoldás (ha a hátrányait el tudod viselni), viszont ha használtok bármi fancy dolgot például NAT, tűzfal, QoS vagy packet inspection, akkor a VPP nettó ugyanazt tudja nagyobb csomagméret esetén az SR-IOV hátrányai nélkül. Ezeket az eredményeket saját tesztekkel is validáltuk.
https://www.semanticscholar.org/paper/Characterizing-the-Performance-of…
https://www.semanticscholar.org/paper/Multi-VNF-performance-characteriz…
A linkeket holnap tanulmányozom.
nem a 10G+ az elvárás, hanem az 1G+ 10G porton.
Úgy terveztem, h minden BGP Peer be van kötve a switchbe (és nem a router kártyájába) 10G porton (de nyilván közel nem volna ennyi forgalom rajta) és ezek a linkek vannak behúzva a VM-ben futó routerekbe, akik kapcsolódnak a Core routerhez szintén VLAN-on.
tudom, kalapács, meg szeg esete, de a Mikrotik-ben otthon vagyok, FRR-ben pedig (még) nem.
Sajnos Mikrotok v6-ban nem támogatja az SR-IOV-t, Debian-FRR (vagy VyOS) megoldás lehet(ne) ha már akkora "barátok lennénk".
ProxMox+Mikrotik esetén nem csak az a problémám, hogy a bridging átviteli kapacitása ~5G, hanem az, hogy baromira magas mind a host mind a guest CPU terhelése. (uez Linux/SR-IOV esetén nincs)
Gyakorlatilag azért szeretnék virtualizálni, mert
- egy-egy PE router 2x10G porttal most 1 külön rack unit, és ~80-100W fogyasztás (plusz a vas sem ingyen van)
- ehelyett egy 2U serverbe bele tudnék tenni ~6db dualSFP+ kártyát vagy méginkább
- SR-IOV-vel mégtöbb PE routert tudnék 1-1 unitra sűríteni, nem beszélve a még kevesebb áramról
Utóbbi esetben akár 3-4 PE routerre is elég lehetne egy dual SFP+ kártya (amennyiben összesen nem érik el csúcsban sem a 7-8Gbps-t).
Fixme, ha valamit rosszul gondolok :-)
Csak annyi jutott az eszembe, hogyha mindent összehúzol egy vasba, akkor lőttek a redundanciának, ha megáll a vas.
Ez most szempont vagy nem?
...úgyis jönnek...
Komponens redundanciát mindkettő nyújt. SR-IOV-nál NIC1 VIF1 mappol vEth1-re a routeren, NIC2 VIF1 vEth2-re, ebből bond-ot is csinálhatsz és mehet fölötte a BGP. Van pár gotcha, de a fenti videó részletesen kitér erre is.
VPP pedig alapból csinál egy virtual Bond uplink interfészt a két NIC-re és a router-en elég csak egy virtual interfész a VPP router felé. Ha jól belövöd a CPU és NUMA policy-t, storage redundanciát, stb. akkor egy vason belül stabilan redundáns leszel. Ezután pedig a szolgáltatástól függően tudsz csinálni site redundanciát. Maradva a BGP példánál leteszel még egy ugyanilyen szervert ugyanoda, ahol a fizikai router pár is lenne (másik DC, másik szoba, stb.) és BGP AS path prepend és local pref-el szabályozod ki a primary. Metro Ethernet szolgáltatás esetén meg L2-ben látnia kell egymást a két virtuális hálózati eszköznek, akár ugyanazon a dwdm vonalon amin az elosztott storage meg compute cuccok mennek.
Köszönöm a részletes választ.
A több eszközös megoldásra gondoltam, nem a komponens redundanciára a kérdésemben, de ezt is megválaszoltad. :)
...úgyis jönnek...
Ebben az esetben jobbnak tűnik nekem SR-IOV + FRR, ha együtt tudsz élni a hátrányaival.
milyen hátrányai vannak azon kívűl, h még meg kell ismerkedni vele? :-)
OpenStack alatt én ezeket tartom számon:
Emellett van még két dolog ami nálunk a gyakorlatban jött elő, nem biztos hogy ez mindenkinek gond:
Nagyon érdekel a téma, mert én is érintett leszek ilyesmi megoldásban hamarosan, de jelenleg érdemben nem tudok hozzá szólni.
Viszont az eddigi hsz.-ek alapján keresgélve a neten találtam arra hivatkozást, hogy ESXi és Proxmox (pontosabban KVM) alatt a Mikrotik CHR-nek nem túl jó a teljesítménye a virtualizációs megoldások virtuális hálózat kezelési bufferelési módja miatt, amit egyik esetben sem lehet (jelenleg) radikálisan átkonfigurálni. Viszont azt írják, hogy Hyper-V alatt teljesen más a kép, mert az teljesen máshogy kezeli a virtuális hálózati buffereket, és ott nem gond a nagy áteresztő képesség és jumbo frame használat sem.
A másik érdekes amit találtam az a TNSR (https://www.tnsr.com) ami ránézésre szintén Netgate termék, de kifejezetten nagy teljesítményű szoftveres router funkciókra, kifejezetten olyan feladatokra miak itt elhangzottak, és azokkal a technológiákkal, amiket itt javasoltak/felhoztak mások (DPDK, VPP, stb.) Persze a Netgate lehet valakinek nem tetszik mint cég (nekem sem tetszik, én is váltottam OPNsense-re), de ha van olyan megoldásuk, ami az adott feladatra jó, és célszerű váűlasztásnak tűnik, akkor ez van.
Egyébként az nem járható, hogy Proxmox mellett SR-IOV, és PCIe-passthrough-val kapja meg a VM a "natív" hálókártyát? Így ugyan nincs VM migráció, de nem is a KVM virtuális hálózat stack-en megy a forgalom. Ha hülyeséget kérdeztem, mert ilyent nem lehet semmiképp, akkor bocs!
Továbbra is figyelem a topic-ot, mert érdekel nagyon, mire jut az OP a megoldásban!
Nos, láttam olyan videót, ahol a ProxMox alatt, CHR-el 40Gbps sebességet produkáltak... A HyperV esetén állítólag azért jobb a teljesítmény, mert az nem volt támogatott, és meg kellett írni 0-ról. Inkább az MPLS-el merültek fel problémák, de úgy tudom, az is leküzdhető.
SR-IOV nem támogatott RouterOS v6 alatt. v7 beta vmelyik verziótól már igen, de az -szerintem- még minimum 1 év mire production lesz. Most a PCI Passthru-t tesztelem, azzal mire jutok.
Vagy cserélj hypervisort, azzal jobban jársz ...
Fedora 38, Thinkpad x280
meg nem lattam olyan megoldhatatlan gondot, amit a KVM okozott, foleg eleg friss KVM eseten. meselj, mire csereljen, es mit nyer vele...
A mikrotikesek szerint:
performance order: Hyper-V, Xen, VMWare....at the moment... ez 2018ban volt, ismerve a mikrotiket azóta se lett jobb a helyzet.
Én csak KVM + bridge, valamint xcp-ng + openvswitch el teszteltem, de jobb volt a xenes változat.
Fedora 38, Thinkpad x280
KVM VM helyett LXC container router használata is jó sebességet adhat.
LXC vs KVM for Routing: http://article.sciencepublishinggroup.com/pdf/10.11648.j.ajnc.20130204…
--
Légy derűs, tégy mindent örömmel!
Szia!
Mikrotik megoldás helyett néztél más gyártót is?
(lista)
https://www.eve-ng.net/index.php/documentation/howtos/
HPE VSR1000
(A termék ára még nem is annyira vészes mint a többinek - nincsen extra licensz, minden benne van, ennél a VRF-aware-NAT pedig jó dolog, sok más gyártó nem tudja)
https://shoredata.us.com/wp-content/uploads/2016/03/VSR.pdf
Felmerült már sok minden DANOS-ra is megéri vetni egy pillantást. FRR+DPDK alapú. Ez a Vyatta> Brocade> AT&T > DANOS fork.
https://www.danosproject.org/
hasznalod elesben valahol, komolyabb forgalommal?
Ez engem is érdekelne, mi is akarunk PoC-t ezzel. Ha van bármi tapasztalatod vele ne tartsd magadban.
miert akarnal pont ezzel PoColni? mi a use-case?
Komolyabb forgalommal nem használom. Én is csak POC fázisban vagyok.
Az otthoni routeremen már ez megy :)
Érdekes állat egyébként ez a DANOS. Állítólag? a Telco igényeknek akarnak megfelelni bármit is jelentsen ez.
Ami érdekes, hogy komplett IPSEC stack is van benne DPDK DP-vel és Strongswan CP-vel. Továbbá elég erős a stateful firewall része is CGNAT és NDPI támogatással.
Egyébként a DP firewall NPF alapú benne, szóval neked is van némi közöd hozzá, ha jól tudom valamikor commitoltál az NPF-be. :)
jaja, ipv6 tamogatast reszeltem hozza, illetve a stateful tracking ALG-ket. orulok, hogy mashova is kerul belole :)
Szia!
Én néztem, nincs benne normális VRF (VRF-lite) - így nekem ez felejtős.
CLI -ben lehet ez látszik, de az FRR csak egy "hackkel" állítja elő ezt megkötésekkel,
az 1db globális routing-táblát használja "
etc/iproute2/rt_tables.d/
" ugyan úgy, ez nem az FRR hibája hanem a linux-network stack még nem tudja ezt lekezelni rendesen, pár év múlva talán tudja majd, erről egy másik topikban már volt szó:https://hup.hu/index.php/node/169906
https://cumulusnetworks.com/blog/vrf-for-linux/
https://github.com/FRRouting/frr/wiki/Configuring-a-VRF-to-work-properl…
https://docs.cumulusnetworks.com/cumulus-linux-43/Layer-3/VRFs/Virtual-…
Nem értelek.
A DANOS az 5.4-es kernelt használja. De már a 4.19-es kernel óta legalább minden benne van a Linux kernelben ami a VRF-hez kell. Nincs semmilyen hack.
Milyen megkötésre gondolsz?
A linkelt topicban is megírták már ezt. A Cumulus is a Linux natív VRF stackját használja.
Az FRR itt a linux kernelt használja DP-nek ugyanúgy.
Natív ip parancsokkal ez így néz ki:
admin@danos01:~$ ip vrf
Name Table
-----------------------
vrfINT 256
vrfVRF1 257
vrfVRF2 258
Külön routing tábla van minden vrf-nek:
admin@danos01:~$ ip ro show vrf vrfVRF1
unreachable default proto zebra metric 4278198272
10.1.1.0/24 dev dp0p225p1 proto kernel scope link src 10.1.1.1
10.2.2.0/24 via 10.1.1.2 dev dp0p225p1 proto static metric 20
127.0.0.0/8 dev vrfVRF1 proto kernel scope link src 127.0.0.1
admin@danos01:~$ ip ro show vrf vrfVRF2
unreachable default proto zebra metric 4278198272
10.1.1.0/24 dev dp0p256p1 proto kernel scope link src 10.1.1.1
10.3.3.0/24 via 10.1.1.2 dev dp0p256p1 proto static metric 20
127.0.0.0/8 dev vrfVRF2 proto kernel scope link src 127.0.0.1
+1, en sem ertem mire gondol a kolto, teljes vrf tamogatas van a kernelben, teljes frr tamogatassal.
Add ki a routeren ezt a parancsot:
$> ip rule show
0: from all lookup local
1000: from all lookup [l3mdev-table]
32766: from all lookup main
32767: from all lookup default
Ez a problémám.
https://www.kernel.org/doc/Documentation/networking/vrf.txt
nem ertem a problemad.
Le van írva a dokisban minden, itt egy részeletesebb kifejtés:
https://netdevconf.info/1.2/papers/ahern-what-is-l3mdev-paper.pdf
De ha te szeretnél külön ip rule-okat minden VRF-hez megteheted:
https://www.kernel.org/doc/Documentation/networking/vrf.txt
Én ebben koncepcionálisan nem értek egyet "A single l3mdev rule is sufficient for all VRFs."
Visszautalva előzőekre valami ilyesmit kellene látnom:
Rendben, elfogadom hogy jelenleg így működik a "linux vrf".
-Hogyan tudok iptables használva csak az adott VRF-re szabályokat használni (VRF-aware)?
(RAW, MANGLE: MARK - és hasonlókat hadjuk)
A network namespace-eket nézted már?
Igen ez lesz a megoldás: namespace + macvlan
Előjött megint a téma és kutattam a megoldás után, probléma az volt hogy hogyan lehetne hoston lévő fizikai hálókártyát megosztani hogy a hoszton ne kelljen külön bridge vagy iptables/veth foglalkozni erre találtam ezeket:
> ipvlan
> ipvtap
> macvtap
> macvlan
Ez így már VRF :)
Egy kérdés maradt, hogy a hálózati teljesítmény ( throughput ) mekkora - tesztelnem kell.
sub