Virtualizált routerek

Virtualizáció

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?

( NagyZ v | 2020. 05. 19., k – 00:02 )

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.

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)

( Vamp | 2020. 05. 19., k – 00:41 )

Szerkesztve: 2020. 05. 19., k – 00:43

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.

( ollnx | 2020. 05. 19., k – 01:09 )

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

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.

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

( Vamp | 2020. 05. 19., k – 10:59 )

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

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

( debtamas88 | 2020. 05. 19., k – 14:05 )

Szerkesztve: 2020. 05. 19., k – 14:06

Egy másik topikban IOMMU/SR-IOV megoldás helyett írtam egy alternatív megoldásról:

https://hup.hu/comment/2481876#comment-2481876

Lényegében a fizikai (loopback) kártyán megjáratjuk a forgalmat - így nem a CPU fog dolgozni, hanem a hálókártya ASIC/SOC-ja, így közel 10G duplex sebesség elérhető.
Legjobban 4portos NIC-kártya esetén működhetne, mert akkor uplink is ugyan azon menne át.

 

Akinek van ideje/hardvere azt tesztelhetné :)

( debtamas88 | 2021. 04. 10., szo – 02:03 )

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
 

( nsandoragy | 2021. 04. 10., szo – 16:57 )

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

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.

OpenStack alatt én ezeket tartom számon:

  • élő migráció nem támogatott
  • nincs security group támogatás
  • a QoS opciók limitáltak
  • számos VNF/router nem támogatja ellentétben a virtIO interfésszel

Emellett van még két dolog ami nálunk a gyakorlatban jött elő, nem biztos hogy ez mindenkinek gond:

  • Néhány enterprise virtual router (mondjuk cisco ~2 éve) nem tudja a trust módot amiről a videóban beszélnek, ennek az a következménye hogy hiába teszed L2 port-channel-be a két virtuális interfészed a router-en és mappolod ki két külün fizikai NIC-re, NIC/kábel hiba esetén nem megy le a virtuális port a router-en. L3 ECMP-vel vagy IP SLA-val lehet szórakozni, de egy nagy takony lesz belőle.
  • Ha van sok SR-IOV és nem SR-IOV virtuális eszközöd egyszerre, akkor a gyakorlat azt mutatja hogy érdemes lehet fenntartani külön AZ-t mondjuk 2-2 géppel az SR-IOV only gépeknek, ami drágitja a megoldást, mi legalábbis nem találtunk eddig jobb megoldást, mert OpenStack-ben nem nagyon van BW aware scheduling. Ha pl. van 25G bandwidth a gépen és oda kitol a nova 5 * 5G virtuális router-t, akkor elfogyott a BW, de RAM meg CPU meg bőven van még kisebb sávszél-igényű gépeknek, amiből resource competition lesz. Hasonlót csinálhat Azure meg AWS, mert ha nagy sávszéligényű gépet akarsz kiválasztani azt más flavor-re akarja tenni. Erről itt beszélgettünk: https://hup.hu/node/172364

( ggallo | 2021. 04. 11., v – 11:40 )

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!

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

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

"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!"

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.

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

?

admin@danos01# set routing routing-instance VRF1 instance-type

Possible Completions:
   vrf  VRF lite


admin@danos01:~$ show interfaces routing-instance VRF1
Codes: S - State, L - Link, u - Up, D - Down, A - Admin Down
Interface       IP Address                        S/L  Speed/Duplex  Description
---------       ----------                        ---  ------------  -----------
dp0p225p1       10.1.1.1/24                       u/u  a-10g/a-full


admin@danos01:~$ show interfaces routing-instance VRF2
Codes: S - State, L - Link, u - Up, D - Down, A - Admin Down
Interface       IP Address                        S/L  Speed/Duplex  Description
---------       ----------                        ---  ------------  -----------
dp0p256p1       10.1.1.1/24                       u/u  a-10g/a-full

admin@danos01:~$ show ip route routing-instance VRF2
Codes: K - kernel route, C - connected, S - static, R - RIP,
       O - OSPF, I - IS-IS, B - BGP, E - EIGRP, N - NHRP,
       T - Table, v - VNC, V - VNC-Direct, A - Babel, D - SHARP,
       F - PBR, f - OpenFabric,
       > - selected route, * - FIB route, q - queued route, r - rejected route

VRF vrfVRF2:
C>* 10.1.1.0/24 is directly connected, dp0p256p1, 00:02:34


admin@danos01:~$ show ip route routing-instance VRF1
Codes: K - kernel route, C - connected, S - static, R - RIP,
       O - OSPF, I - IS-IS, B - BGP, E - EIGRP, N - NHRP,
       T - Table, v - VNC, V - VNC-Direct, A - Babel, D - SHARP,
       F - PBR, f - OpenFabric,
       > - selected route, * - FIB route, q - queued route, r - rejected route

VRF vrfVRF1:
C>* 10.1.1.0/24 is directly connected, dp0p225p1, 00:02:52

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

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

2. An l3mdev FIB rule directs lookups to the table associated with the device.
   A single l3mdev rule is sufficient for all VRFs. The VRF device adds the
   l3mdev rule for IPv4 and IPv6 when the first device is created with a
   default preference of 1000. Users may delete the rule if desired and add
   with a different priority or install per-VRF rules.

   Prior to the v4.8 kernel iif and oif rules are needed for each VRF device:
       ip ru add oif vrf-blue table 10
       ip ru add iif vrf-blue table 10

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

$> ip rule show

<context default
0:    from all lookup local
32766:    from all lookup main
32767:    from all lookup default

<context vrf red
0:    from all lookup local
32766:    from all lookup main
32767:    from all lookup default

<context vrf blue
0:    from all lookup local
32766:    from all lookup main
32767:    from all lookup default

<context vrf green
0:    from all lookup local
32766:    from all lookup main
32767:    from all lookup default
A VRF alatt független "instance"-kat értek ( ne kelljen már ilyen table id-kat állítgatni ).
Tehát akkor félreértjük egymást ki mit ért "VRF" működése alatt.

Az én olvasatomban akkor mondok egy másik megjelölést "VDC: Virtual Device Context":

https://www.cisco.com/c/en/us/td/docs/switches/datacenter/nexus7000/sw/vdc/config/cisco_nexus7000_vdc_config_guide_8x/overview.html

 

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)

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
 

VRF megoldása Linux alatt:

	eth1.100 -> access-vlan 100
	eth1.200 -> access-vlan 200
	eth1.300 -> access-vlan 300
	...
	eth2     -> transit / route-leaking

( VRF domain L3 )
	$> ip netns add vrf100
	$> ip netns add vrf200
	$> ip netns add vrf300

( macvlan subinterface )
	$> modprobe macvlan
	$> ip link add vrf1vlan100 link eth1.100 type macvlan mode bridge
	$> ip link add vrf2vlan200 link eth1.200 type macvlan mode bridge
	$> ip link add vrf3vlan300 link eth1.300 type macvlan mode bridge
	#
	$> ip link add vrfbridge100 link eth2 type macvlan mode bridge
	$> ip link add vrfbridge200 link eth2 type macvlan mode bridge
	$> ip link add vrfbridge300 link eth2 type macvlan mode bridge

( bind interface to VRF )
	$> ip link set dev vrf1vlan100 netns vrf100
	$> ip link set dev vrfbridge100 netns vrf100
	#
	$> ip link set dev vrf2vlan200 netns vrf200
	$> ip link set dev vrfbridge200 netns vrf200
	#
	$> ip link set dev vrf3vlan300 netns vrf300
	$> ip link set dev vrfbridge300 netns vrf300
	#

( VRF config )	
	$> ip netns exec vrf100 bash
	   ...
	$> ip netns exec vrf100 bash -c "iptables-restore < /etc/iptables/vrf100/rules.v4"
	$> ip netns exec vrf200 bash -c "iptables-restore < /etc/iptables/vrf200/rules.v4"
	$> ip netns exec vrf300 bash -c "iptables-restore < /etc/iptables/vrf300/rules.v4"
	...

Ez így már VRF :)

Egy kérdés maradt, hogy a hálózati teljesítmény ( throughput ) mekkora - tesztelnem kell.