Virtuální spojovací pole verze 2

Z VirtlabWiki

Přejít na: navigace, hledání

Obsah

Základní princip

Propojování Ethernet linek (access i trunk)

Jednotlivá rozhraní laboratorních prvků (reálných i simulovaných) jsou přivedena na různé fixní VLAN (buďto nastavením fyzického portu C3560 do VLAN nebo trunkem od XEN a jiných serverů). Na portech C3560 připojujících reálná zařízení je konfigurován QinQ. Bylo prověřeno, že QinQ tunelem procházejí i netagované rámce. VLANy jsou ukončeny na tunelovacím serveru, který podle konfigurace bridguje veškerý provoz mezí Ethernet rozhraními síťových prvků lokality, resp. jej posílá do cizích lokalit v UDP přes Internet.

K tunnel serveru přicházejí z C3560 data z laboratorních zařízení trunkem, který nese

  • single-tagged rámce, je-li laboratorní zařízení připojeno access linkou
  • double-tagged rámce, je-li laboratorní zařízení připojeno trunkem

V každém případě tag nalepuje port, kterým do C3560 rámec od uživatelského zařízení vstoupil. Tunelovací server nerozlišuje, zda přemosťuje single-tagged nebo double-tagged rámce, orientuje se podle vnějšího tagu a případný vnitřní ho nezajímá. Jen je třeba nastavit větší MTU (1508 B).

Podle požadované topologie se automaticky konfigurují jen tunelovací servery; konfigurace C3560 (příp. C1900) jsou pevné - jedná se o přiřazení jednotlivých portů do QinQ VLAN a vytvoření všech VLAN v lokalitě (kvůli bridgeování v řetězu C3560 vytváříme všude všechny VLAN použité v lokalitě).

Propojování sériových linek

Propojování sériových linek se obsluhuje "klasicky", tj. generováním konfigurace pro jednotlivé ASSSK. Je předpokládáno, že se v topologii požadují pouze spoje mezi sériovými rozhraními laboratorních prvků připojených do téhož ASSSK, tj. že mapovací algoritmus správně pracuje s connectivity groups.

Paralelní zpracování rezervací

Generování a aktivace konfigurací se musí vypořádat s tím, že aktivátor konfigurací (atd) může chtít generátor konfigurací spustit paralelně vícekrát, pokud se sejde více rezervací vyžádaných danou lokalitou na stejný čas. Generátor konfigurací je proto reentrantní a generuje pro jednotlivá spuštění nezávislé sady souborů (vždy přípona RESID za každým, ta se pak jako parametr také předává uploaderu konfigurací do konfiguračního serveru). Také se může stát, že konfiguraci lokality bude chtít (přes Konfigurační server) modifikovat více lokalit naráz (ať už při aktivci nebo daktivaci) a nahrávané konfigurace (do Tunserveru nebo ASSSK) se nesmí během uploadu pomíchat (=musí se serializovat). Serializaci vyřešíme zatím tak, že konfigurační server bude současně přijímat jen 1 TCP spojení.

Poznámka:

  • Předpokládáme, že CONNECT timeout na klientech je řádově 1 minuta, za kteroužto dobu se jistě předchozí jedno TCP spojení vyřídí (nejpomalejši je upload konfigurace do ASSSK, kde se mezi znaky čeká 100ms, ale zato jsou konfigy krátké).
  • Všechny hodnoty pro TCP spojení jsou v /proc/sys/net/netfilter/, prip. v /proc/sys/net/ipv4/*tcp* (tcp_syn_retries), lze i nastavit zápisem do příslušného souboru.
    • Viz http://www.mjmwired.net/kernel/Documentation/networking/ip-sysctl.txt
    • Modernější způsob přístupu ke konstantám: sysctl. Debian Etch má soubor /etc/sysctl.conf který je pro to určený a příkazem sysctl -p lze aktivovat změny. Jinak po startu zajistuje natazeni toho (/etc/sysctl.conf) souboru link v /etc/rcS.d/procps.sh (ukazujici na /etc/init.d/prospc.sh). Takze nejlepsi je nahodit prislusny radek do /etc/systl.conf a aktivovat nastaveni pres "sysctl -p". Po restartu se natahne automaticky.


Na straně klienta konfiguračního serveru je třeba později trochu vylepšit obsluhu timeoutu z connect() - může se stát, že by v určitou hodinu chtělo nalévat konfiguraci do téže lokality velmi mnoho klientů a v rámci defaultního connect() timeoutu by se to nestihlo.

Konfigurační soubory

tunservers.conf

Mapuje jména lokalit na IP adresy jejich tunelovacích serverů. Syntaxe jako ve staré verzi spojovače:

jmeno_lokality ip_adresa_tunelovaciho_serveru

Nová syntaxe spoje.conf

Ve všech lokalitách je tentýž soubor, obsahující definici připojení laboratorních prvků ve všech lokalitách. To je nutné proto, že konfigurace pro všechny umí generovat kterákoli z lokalit (vždy lokalita, která je "zdrojem" rezervace).

Je zavedena konvence, že jména lokalit, laboratorních prvků a jejich rozhraní píšeme v konfiguračních souborech malými písmeny.


Syntaxe spoje.conf:

device@site:interface VLAN vlan_number
device@site:interface ASSSK asssk-name@site port


Rozhraní laboratorních prvků, které nepodporují trunking, mohou být do řetězu přepínačů připojeny přes port C1900 (ten je k C3560 připojen přes ISL trunk)


Příklad:

r1@ostrava:ethernet0 VLAN 1000
r1@ostrava:ethernet1 VLAN 1001
uml1@ostrava:eth0 VLAN 2000
r1@ostrava:serial0 ASSSK asssk1@ostrava 1
r1@ostrava:serial1 ASSSK asssk1@ostrava 2

ra@karvina:fastethernet0/0 VLAN 300
ra@karvina:fastethernet0/1 VLAN 301
uml1@karvina:eth0 VLAN 400
ra@karvina:serial0 ASSSK asssk1@karvina 1
ra@karvina:serial0 ASSSK ASSSK1@karvina 2

Soubor s popisem topologie

Syntaxe podobná jako v první verzi spojovače, pouze s ohledem na implicitní použití QinQ se řádky neukončují znakem ";" nebo "&"

r1@site1:interface1,r2@site2:interface2

Programy

POZOR: Pro zjednodušení programy předpokládají správnou syntexi konfiguračních souborů a souboru s požadovanou topologií. V budoucnu bude implementován syntax checker (patrně externě).

make-conn-tun-conf.pl - Generátor konfigurací pro aktivaci/deaktivaci vituální topologie

Konfigurace: veškerá se provádí nastavením proměnných na začátku skriptu.

Spuštění: jediným parametrem je resid souboru s topologií, např.: /opt/virtlab/spojovac/make-conn-tun-conf.pl 30@ostrava Na jeho základě je vyhledán soubor resid.dat v adresáři $residpath="/opt/virtlab/data/act-server".

Na základě souborů $spojeconffile="/etc/virtlab/spoje.conf" a $tunserversfile="/etc/virtlab/tunservers.conf" :

V adresáři $destdir="/opt/virtlab/data/vlanstore" vytvoří následující strukturu: Soubory označené * nemusejí vzniknout!

$destdir
 |
 +--- <resid>
       |
       +--- activate
       |    +---tunscfg@<site>*      # příkazy pro tunelovací server
       |    +---<assskname>@<site>*  # příkazy pro jednotlivé tatabazmeky... není jasné, co všechno převzít z make-conn-configs, takže soubor obsahuje pouze dvojici portů a 
       |    +---downs*               # seznam portů, které mají jít při aktivaci dolů... v současné době s nedodělanou syntaxí, je třeba dořešit
       |
       +--- deactivate
            +---tunscfg@<site>
            +---<assskname>@<site>

Uploader konfigurací tunelovacích serverů a ASSSK a tunelovací servery při aktivaci vituální topologie

Uploader konfigurací tunelovacích serverů a ASSSK a tunelovací servery při deaktivaci vituální topologie

SNMP ovladani spojovace

tento odstavec resi nahazovani/zhazovani portu na C3550/C3560 pomoci snmp verze 2c
potrebne nastaveni do switche
snmp-server community xxx RO
snmp-server community yyy RW
snmp-server ifindex persist
pouziti skriptu snmpport.sh
umisteni <<SVN>>/DISTR/src/spojovac/snmpport.sh
pozor! nejsou osetreny cisla portu, tedy je mozno si uriznout vetev pod vlastnim zadkem
#nahozeni portu 1 na switchi 10.0.0.10
snmpport.sh 10.0.0.10 up 1
#zhozeni portu 1 na switchi 10.0.0.10
snmpport.sh 10.0.0.10 down 1
#zobrazeni stavu portu 1
snmpport.sh 10.0.0.10 show 1
#zobrazeni stavu vsech portu
snmpport.sh 10.0.0.10 show all


Aktivace/deaktivace konfigurací (Cron)

Virtlab:Komponenty/Náhrada aktivačního serveru

TODO

  • Zjistit, co se přesně stane, když na jednom ze spojených rozhraní laboratorních prvků uživatel nastaví trunk a na druhém access. Pro případ spojení v rámci lokality i přes tunel.
  • Shazovat/nahazovat porty C3560 na začátku, resp. konci rezervace pomocí SNMP
Osobní nástroje