Ma tot oftic ca nu l-am prins cand era la IMAX, ca este super mega cool.
Category Archives: diverse
usi
Cu toate arestarile si perchezitiile in zori de ziua de tot scria presa, ma gandeam la o chestie: astia de tin chestii in casa sunt complet imbecili. Adica toti au usi care se deschid spre interior si pe care daca le dai cu berbecul de multe ori pana la urma cedeaza, iar cele mai multe cedeaza aproape instant. Si e o practica comuna, ceea ce ma face sa ma gandesc ca pe langa faptul ca’s imbecili, mai sunt si zgarciti.
Adica sa-si ia o usa care se dechise spre exterior (cam cum sunt alea de seif ca idee) si fara locuri unde ai putea baga levier/ranga s-o poti deschide. Daca faci o combinatie si la geamuri in cam acelasi stil, poti scapa de probe in linisite si dupa aia deschizi usa si zici “Am auzit zgomot pe hol, este totul in ordine, domnilor ofiteri?”.
irony
Azi fusei la Laser Tag cu niste oameni, printre care si niste israelieni. Si cei din urma fumatori. Locatia avea camera dedicata pentru fumatori ca sa nu miroasa a fum peste tot. Si pe usa de la camera aia era un afis: Camera de Gazare.
the immigrant
“internet” paralel (2)
Se pare ca la partea cu un singur ASN puneam problema gresit:
Initial aveam asa pe vpn-hub spre vpn-gw-a:
route-map A permit 1 match origin igp set ip next-hop 192.168.168.1
route-map-ul era aplicat asa:
neighbor 192.168.168.2 route-map A out
Care teoretic ar fi trebuit sa schimbe next-hop din anunturi in ce i-am zis io mai sus.
Cu un hint de la gabim ca nu trebuie sa fac match pe nimic ci doar sa setez ip next-hop, asa ca am lasat doar varianta cu set ip next-hop. Dar tot fara noroc.
Ma mai scarpinai un pic si ajunsei la alta combinatie care se pare ca merge: pun route-map pe in pe gateway-uri si nu mai fac nimic pe vpn-hub, lucru care se pare ca merge. Plus bonus points ca setand next-hop ca peer-address ma doare la bachetzi cine e peer-ul, deci pot sa fac template.
route-map set-nh permit 1 set ip next-hop peer-address
Care se aplica asa:
neighbor 192.168.168.1 remote-as 4200000000 neighbor 192.168.168.1 route-map set-nh in
Iar pe vpn-hub arata in felul urmator:
neighbor 192.168.168.2 remote-as 4200000000 neighbor 192.168.168.2 route-reflector-client
Pentru confirmare ca functioneaza treaba:
vpn-gw-a# sh ip bgp 172.16.3.0/24 BGP routing table entry for 172.16.3.0/24 Paths: (1 available, best #1, table Default-IP-Routing-Table) Not advertised to any peer Local 192.168.168.1 (metric 1) from 192.168.168.1 (192.168.168.10) Origin IGP, metric 0, localpref 100, valid, internal, best Originator: 192.168.168.10, Cluster list: 192.168.168.9 Last update: Sat Mar 21 21:55:27 2015
zebra instaleaza ruta corect:
[root@vpn-gw-a ~]# ip r l 172.16.3.0/24 172.16.3.0/24 via 192.168.168.1 dev to-hub proto zebra
Ping:
[root@vpn-gw-a ~]# ping 172.16.3.1 -I172.16.1.1 -c3 PING 172.16.3.1 (172.16.3.1) from 172.16.1.1 : 56(84) bytes of data. 64 bytes from 172.16.3.1: icmp_seq=1 ttl=63 time=1.99 ms 64 bytes from 172.16.3.1: icmp_seq=2 ttl=63 time=1.37 ms 64 bytes from 172.16.3.1: icmp_seq=3 ttl=63 time=1.37 ms --- 172.16.3.1 ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 2006ms rtt min/avg/max/mdev = 1.376/1.582/1.993/0.290 ms
De asta imi place mie BGP-ul, ca poti sa-l violezi in cele mai oribile moduri (ca ce-am facut mai sus e viol cu perversiuni) si tot functioneaza bine :))
Pe vpn-hub pot sa pun un peer-group imens in care ii strang pe toti, iar pe gateway-uri peer-address. Asa iti vin ideile, facand stuff :)
Teoretic, ar fi mers route-map-ul si pe vpn-hub cum il pusesem inainte, insa se pare ca implementare de quagga nu face stuff cand pui route-map pe out. Dar bine ca merge pe in.
Asa ca pot folosi un singur ASN indiferent de cati neighbor-i am. Acum as putea sa-mi pun un pahar de vin ca am intuit ca se poate, doar ca a durat ceva pana m-am prins si cum.
“internet” paralel (1)
In mod traditional pentru schimbul de informatii considerate sensibile intre doua companii, indiferent de aplicatie, se stabileste o conexiune IPSec (da, stiu ca mai exista si OpenVPN dar nu se pune ca nu este suportat comercial pentru interoperare). Si treaba asta merge OK cand ai nu numar rezonabil de parteneri, dupa aia nu mai este chiar asa distractiv.
Cand ai o companie mare cu multe locatii, atunci se ajunge la configuratii de tipul Hub-and-Spoke fie configurate manual fie automat folosind DMVPN/GETVPN in functie de necesitati si situatie individuala.
Acum, cum impaci capra cu varza, sa ai o configuratia din asta dar intre companii, un fel de serviciu de IPSec-as-a-Service, ceva de genul:
Unde VPN HUB este un la “provider” iar gateway-urile de VPN sunt la “clienti”. Si asta se poate extinde pana terminam alfabetul si o luam cu VPN Gateway AA pana la VPN Gateway ZZZZZ.
Cum ar functiona toata treaba asta fara sa se strice si sa fie scalabila? Teoretic ar fi in felul urmator:
- IPSec intre capete
- GRE over IPSec
- BGP over GRE
- se accepta doar adrese de IP sau subnet-uri “publice”
De ce BGP? Pai pentru ca:
- permite o filtrare mult mai buna a rutelor si a anunturilor, astfel incat sa nu se poata anunta prefixe inexistente sau sa se poata face hijacking
- pot anunta sau importa selectiv prefixe
- pot folosi si pentru IPv4 cat si pentru IPv6
- este mult mai scalabil decat OSPF care este folosit in mod traditional pentru “route based VPNs”
Ideea de baza ar fi in felul urmator:
- Vreau sa comunic securizat cu un numar oarecare de entitati cu care am treaba insa nu vreau sa fac tunele VPN cu fiecare in parte
- Prefer sa am un singur tunel facut care sa-mi dea acces la restul de tunele
- Sa pot publica servicii “secure only” accesibile doar celor din clubul asta
- Sa fie greu de detectat de catre o entitate ostila cine cu cine discuta si cat de mult
Pentru validare mi-am facut un setup de test care arata cam asa:
Setarile sunt facute astfel:
- vpn-hub
- eth0: 10.15.0.1/24
- internet-router
- eth0: 10.16.0.1/24
- eth1: 10.15.0.2/24
- vpn-gw-a
- eth0: 10.16.0.2/24
- eth1: 172.16.1.1/24
- vpn-gw-b
- eth0: 10.16.0.3/24
- eth1: 172.16.2.1/24
- vpn-gw-c
- eth0: 10.16.0.4/24
- eth1: 172.16.3.1/24
internet-router este o masina care sa simuleze “internetul” in sensul de un hop intermediar intre gateway-urile de VPN si concentrator.
Prima oara am setat tunele VPN (pentru test le-am facut cu PSK ca e mai usor):
- vpn-hub /etc/ipsec.conf
conn to-vpn-gw-a authby=secret auto=start type=transport left=10.15.0.1 leftnexthop=10.15.0.2 right=10.16.0.2 rightnexthop=10.16.0.1
conn to-vpn-gw-b authby=secret auto=start type=transport left=10.15.0.1 leftnexthop=10.15.0.2 right=10.16.0.3 rightnexthop=10.16.0.1
conn to-vpn-gw-c authby=secret auto=start type=transport left=10.15.0.1 leftnexthop=10.15.0.2 right=10.16.0.4 rightnexthop=10.16.0.1
- vpn-hub /etc/ipsec.secrets
10.15.0.1 10.16.0.2: PSK "supersecret" 10.15.0.1 10.16.0.3: PSK "supersecret" 10.15.0.1 10.16.0.4: PSK "supersecret"
- vpn-gw-a /etc/ipsec.conf
conn to-vpn-hub authby=secret auto=start type=transport left=10.16.0.2 leftnexthop=10.16.0.1 right=10.15.0.1 rightnexthop=10.15.0.2
- vpn-gw-a /etc/ipsec.secrets
10.16.0.2 10.15.0.1: PSK "supersecret"
- vpn-gw-b /etc/ipsec.conf
conn to-hub authby=secret auto=start type=transport right=10.15.0.1 rightnexthop=10.15.0.2 left=10.16.0.3 leftnexthop=10.16.0.1
- vpn-gw-b /etc/ipsec.secrets
10.16.0.3 10.15.0.1: PSK "supersecret"
- vpn-gw-c /etc/ipsec.conf
conn to-hub authby=secret auto=start type=transport right=10.15.0.1 rightnexthop=10.15.0.2 left=10.16.0.4 leftnexthop=10.16.0.1
- vpn-gw-c /etc/ipsec.secrets
10.16.0.4 10.15.0.1: PSK "supersecret"
- vpn-hub ipsec status
stats db_ops: {curr_cnt, total_cnt, maxsz} :context={0,0,0} trans={0,0,0} attrs={0,0,0}
"to-vpn-gw-a": 10.15.0.1<10.15.0.1>[+S=C]---10.15.0.2...10.16.0.1---10.16.0.2<10.16.0.2>[+S=C]; erouted; eroute owner: #2
"to-vpn-gw-a": myip=unset; hisip=unset;
"to-vpn-gw-a": ike_life: 3600s; ipsec_life: 28800s; rekey_margin: 540s; rekey_fuzz: 100%; keyingtries: 0; nat_keepalive: yes
"to-vpn-gw-a": policy: PSK+ENCRYPT+PFS+UP+IKEv2ALLOW+SAREFTRACK+lKOD+rKOD; prio: 32,32; interface: eth0;
"to-vpn-gw-a": dpd: action:clear; delay:0; timeout:0;
"to-vpn-gw-a": newest ISAKMP SA: #16; newest IPsec SA: #2;
"to-vpn-gw-a": IKE algorithm newest: AES_CBC_128-SHA1-MODP2048
"to-vpn-gw-b": 10.15.0.1<10.15.0.1>[+S=C]---10.15.0.2...10.16.0.1---10.16.0.3<10.16.0.3>[+S=C]; erouted; eroute owner: #7
"to-vpn-gw-b": myip=unset; hisip=unset;
"to-vpn-gw-b": ike_life: 3600s; ipsec_life: 28800s; rekey_margin: 540s; rekey_fuzz: 100%; keyingtries: 0; nat_keepalive: yes
"to-vpn-gw-b": policy: PSK+ENCRYPT+PFS+UP+IKEv2ALLOW+SAREFTRACK+lKOD+rKOD; prio: 32,32; interface: eth0;
"to-vpn-gw-b": dpd: action:clear; delay:0; timeout:0;
"to-vpn-gw-b": newest ISAKMP SA: #18; newest IPsec SA: #7;
"to-vpn-gw-b": IKE algorithm newest: AES_CBC_128-SHA1-MODP2048
"to-vpn-gw-c": 10.15.0.1<10.15.0.1>[+S=C]---10.15.0.2...10.16.0.1---10.16.0.4<10.16.0.4>[+S=C]; erouted; eroute owner: #11
"to-vpn-gw-c": myip=unset; hisip=unset;
"to-vpn-gw-c": ike_life: 3600s; ipsec_life: 28800s; rekey_margin: 540s; rekey_fuzz: 100%; keyingtries: 0; nat_keepalive: yes
"to-vpn-gw-c": policy: PSK+ENCRYPT+PFS+UP+IKEv2ALLOW+SAREFTRACK+lKOD+rKOD; prio: 32,32; interface: eth0;
"to-vpn-gw-c": dpd: action:clear; delay:0; timeout:0;
"to-vpn-gw-c": newest ISAKMP SA: #17; newest IPsec SA: #11;
"to-vpn-gw-c": IKE algorithm newest: AES_CBC_128-SHA1-MODP2048
#2: "to-vpn-gw-a":500 STATE_QUICK_I2 (sent QI2, IPsec SA established); EVENT_SA_REPLACE in 19862s; newest IPSEC; eroute owner; isakmp#1; idle; import:admin initiate
#2: "to-vpn-gw-a" [email protected] [email protected] ref=0 refhim=4294901761
#16: "to-vpn-gw-a":500 STATE_MAIN_I4 (ISAKMP SA established); EVENT_SA_REPLACE in 211s; newest ISAKMP; lastdpd=-1s(seq in:0 out:0); idle; import:admin initiate
#4: "to-vpn-gw-b":500 STATE_QUICK_I2 (sent QI2, IPsec SA established); EVENT_SA_REPLACE in 19643s; isakmp#3; idle; import:admin initiate
#4: "to-vpn-gw-b" [email protected] [email protected] ref=0 refhim=4294901761
#15: "to-vpn-gw-b":500 STATE_MAIN_R3 (sent MR3, ISAKMP SA established); EVENT_SA_REPLACE in 393s; lastdpd=-1s(seq in:0 out:0); idle; import:not set
#7: "to-vpn-gw-b":500 STATE_QUICK_R2 (IPsec SA established); EVENT_SA_REPLACE in 20348s; newest IPSEC; eroute owner; isakmp#6; idle; import:not set
#7: "to-vpn-gw-b" [email protected] [email protected] ref=0 refhim=4294901761
#18: "to-vpn-gw-b":500 STATE_MAIN_R3 (sent MR3, ISAKMP SA established); EVENT_SA_REPLACE in 3022s; newest ISAKMP; lastdpd=-1s(seq in:0 out:0); idle; import:not set
#10: "to-vpn-gw-c":500 STATE_QUICK_R2 (IPsec SA established); EVENT_SA_REPLACE in 21719s; isakmp#9; idle; import:not set
#10: "to-vpn-gw-c" [email protected] [email protected] ref=0 refhim=4294901761
#17: "to-vpn-gw-c":500 STATE_MAIN_I4 (ISAKMP SA established); EVENT_SA_REPLACE in 1169s; newest ISAKMP; lastdpd=-1s(seq in:0 out:0); idle; import:admin initiate
#11: "to-vpn-gw-c":500 STATE_QUICK_I2 (sent QI2, IPsec SA established); EVENT_SA_REPLACE in 21348s; newest IPSEC; eroute owner; isakmp#8; idle; import:admin initiate
#11: "to-vpn-gw-c" [email protected] [email protected] ref=0 refhim=4294901761
type=transport din /etc/ipsec.conf pentru fiecare conexiune in parte inseamna ca o “conexiune” IPSec se va stabili doar intre IP-urile gateway-urilor.
Acum ca totul e OK la partea de criptare, se seteaza tunelele GRE intre gatewa-uri si hub:
- vpn-gw-a
ip tunnel add to-hub mode gre remote 10.15.0.1 local 10.16.0.2 ttl 255 ip addr add 192.168.168.2/30 peer 192.168.168.1/30 dev to-hub ip link set to-hub up
- vpn-gw-b
ip tunnel add to-hub mode gre remote 10.15.0.1 local 10.16.0.3 ttl 255 ip addr add 192.168.168.2/30 peer 192.168.168.1/30 dev to-hub ip link set to-hub up
- vpn-gw-c
ip tunnel add to-hub mode gre remote 10.15.0.1 local 10.16.0.4 ttl 255 ip addr add 192.168.168.2/30 peer 192.168.168.1/30 dev to-hub ip link set to-hub up
- vpn-hub
ip tunnel add to-gw-a mode gre remote 10.16.0.2 local 10.15.0.1 ttl 255 ip addr add 192.168.168.1/30 peer 192.168.168.2/30 dev to-gw-a ip link link set to-gw-a up ip tunnel add to-gw-b mode gre remote 10.16.0.3 local 10.15.0.1 ttl 255 ip addr add 192.168.168.5/30 peer 192.168.168.6/30 dev to-gw-b ip link link set to-gw-b up ip tunnel add to-gw-c mode gre remote 10.16.0.4 local 10.15.0.1 ttl 255 ip addr add 192.168.168.9/30 peer 192.168.168.10/30 dev to-gw-c ip link link set to-gw-c up
Tunelele GRE sunt necesare pentru a putea ruta peste orice avem nevoie fara a crea SA-uri suplimentare in IPSec pentru fiecare subnet sau adresa IP individuala si abstractizeaza partea de transport. Din punct de vedere IP un gateway are conexiune directa cu hub-ul si atat.
Ultima partea este configurarea Quagga pentru a avea partea de BGP functionala.
- vpn-hub /etc/quagga/bgpd.conf
router bgp 4200000000 bgp router-id 192.168.168.9 neighbor 192.168.168.2 remote-as 4200000001 neighbor 192.168.168.2 next-hop-self neighbor 192.168.168.10 remote-as 4200000003 neighbor 192.168.168.10 next-hop-self
- vpn-gw-a /etc/quagga/bgpd.conf
router bgp 4200000001 bgp router-id 192.168.168.2 network 172.16.1.0/24 neighbor 192.168.168.1 remote-as 4200000000
- vpn-gw-c
router bgp 4200000003 bgp router-id 192.168.168.10 network 172.16.3.0/24 neighbor 192.168.168.9 remote-as 4200000000
Configurarea de pe vpn-gw-b lipseste ca mi-am dat seama in timp ce scriam ca de fapt este OK de demonstrat si cu doar doua gateway-uri :)
- vpn-gw-c sh ip bgp
BGP table version is 0, local router ID is 192.168.168.10 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, r RIB-failure, S Stale, R Removed Origin codes: i - IGP, e - EGP, ? - incomplete Network Next Hop Metric LocPrf Weight Path *> 172.16.1.0/24 192.168.168.9 0 4200000000 4200000001 i *> 172.16.3.0/24 0.0.0.0 0 32768 i Total number of prefixes 2
- vpn-gw-a sh ip bgp
BGP table version is 0, local router ID is 192.168.168.2 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, r RIB-failure, S Stale, R Removed Origin codes: i - IGP, e - EGP, ? - incomplete Network Next Hop Metric LocPrf Weight Path *> 172.16.1.0/24 0.0.0.0 0 32768 i *> 172.16.3.0/24 192.168.168.1 0 4200000000 4200000003 i Total number of prefixes 2
- vpn-hub sh ip bgp
BGP table version is 0, local router ID is 192.168.168.9 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, r RIB-failure, S Stale, R Removed Origin codes: i - IGP, e - EGP, ? - incomplete Network Next Hop Metric LocPrf Weight Path *> 172.16.1.0/24 192.168.168.2 0 0 4200000001 i *> 172.16.3.0/24 192.168.168.10 0 0 4200000003 i Total number of prefixes 2
Daca de pe vpn-gw-a dau un ping spre vpn-gw-c (ping 172.16.3.1 -I172.16.1.1) in tcpdump pe vpn-hub am sa vad urmatoarele:
20:03:55.112851 IP 10.16.0.2 > 10.15.0.1: ESP(spi=0xbe68e78f,seq=0x338), length 132 20:03:55.112906 IP 10.15.0.1 > 10.16.0.4: ESP(spi=0xac29a868,seq=0x30f), length 132 20:03:55.113404 IP 10.16.0.4 > 10.15.0.1: ESP(spi=0xfdb78f7d,seq=0x2b7), length 132 20:03:55.113434 IP 10.15.0.1 > 10.16.0.2: ESP(spi=0xc07aaa19,seq=0x370), length 132
Adica ajunge pachetul de la vpn-gw-a la vpn-hub, vpn-hub il trimite la vpn-gw-c, vpn-gw-c raspunde la vpn-hub si vpn-hub da mai departe la vpn-gw-a.
Adica merge cum trebuie toata jucaria :)
Ce mai am de studiat, ca inca mi-o iau in freza:
- sa folosesc un singur ASN. Am incercat tot felul de combinatii sa fac gateway-urile RR Client pentru vpn-hub insa n-a vrut sa schimbe next-hop nici batut. Nici macar pus in mod explicit cu neighbor X:X:X:X next-hop-self. Ca sa nu incalec ce este acum, am dat-o pe ASN-uri de 32biti reservate, ca alea ar ajunge sa conectez tot internetul la un mega VPN :))
- sa trec prin IPSec doar GRE, dar din pacate ii da cu virgula lui OpenSWAN daca ii zic rightprotoport=47 (cu asta nu vrea nici batut) sau rightprotoport=47/%any (moare cu un mesaj dubios legat de “unable to route”)
Alte chestii mai putin importante:
- sa vad cum trebuie salvate setarile corect cum vrea CentOS pentru toate optiunile (interfete, GRE, OpenSWAN, Quagga)
- trecut pe certificate digitale pentru autentificarea gateway-urilor si IKEv2 pentru schimbul de chei cu niste algoritmi de criptare bine definiti
- experimentat si un pic cu IPSec pentru IPv6, dar la cum arata acum parca vad ca o sa trec IPv6-le peste GRE-ul deja existent si scap usor (sper)
- sa conving o multime de oameni sa-mi dea bani sa le fiu broker de VPN :))
PS:
- am uitat o caruta de chestii, ma uitam (si in continuare ma uit) ca vaca la OpenSWAN si nu mai stiam (stiu) de unde sa-l iau
- ce misto e sa ai mult RAM in laptop, poti sa-ti faci maisini virtuale pana te ia plictisul
Dupa ce-o sa-mi treaca durerea de cap de o am, o sa sap mai cu talent in OpenSWAN sa vad cum il fac sa mearga cat mai sigur si cat mai simplu, eventual automatizat un pic.
nufar
Ieri, dupa ce m-am plimbat toata ziua cu blugii patati de cafea prin oras, am aflat de Nufar, un fel de fas-fas de scos pete. Io l-am luat de la Mega, arata cam ca alea de curatat geamuri, dai pe pete, lasi un pic sa-si faca magia si dupa aia pui la spalat.
Si m-am dus io sa-l iau, am aruncat bucuros toate hainele de pe mine, am dat cu crap din ala pe blugi si i-am pus la spalat. Si atunci m-a pocnit, n-am detergent.
Asa ca m-am apucat sa caut haine prin masina in care sa ma imbrac, alti blugi prin casa si din nou la magazin dupa detergent. Si iar acasa la bagat totul la spalat.
Anyway, long story short, acu am blugi ca noi, a mers Nufarul sa scoata petele. Urmatorea provocare: sa vad daca scoate si petele galbene de pe tricouri, poate scap de o tura de cumparaturi.
focus
– Why did you come up here if you were on to us?
– Professional curiosity, and I like boobs, so I considered it was a win win.
cafenea la purtator (2)
Cum ziceam eu ca-mi place mirosul de cafea proaspata in masina, azi dimineata ma dusei sa imi iau cafea si cum m-am pus pe scaun cum am dat-o pe mine. Noroc cu reflexele mele de ninja ca altfel aveam parte si de Paste. Asa m-am ars doar un pic pe un picior.
Pe de alta parte, acum miroase si mai bine a cafea :))
Daca scot cafeaua din blugi o sa fie bine, daca nu ma gandeam io ca as putea sa-mi fac o oala de cafea sa-i bag sa aiba culoare uniforma si poate inventez o noua moda: blugi cafe :)
cisco connect 2015
Azi ma scapai la Cisco Connect sa mai invat si io niste stuff de networking :)
Primul discurs a fost tinut de un tip de cica e director general la Cisco Romania, dar prieteneste ii sfatuiesc sa nu-l mai lase sa vorbeasca un public. N-are deloc carisma si nici abilitati de prezentare. A fost plictisitor chiar daca a incercat sa sa mai anime un pic sala.
Dupa aia a fost un nene neamt de a vorbit de FOG computing si cum vede Cisco Internet of {Things, Everything} si ce proiecte mai au prin alte tari. FOG computing asta, explicat de nenea are mai multa logica decat articolele de marketing ale lui Cisco: pe scurt, o mare parte din computing se muta la “edge” astfel incat anumite decizii se pot lua local iar in “cloud” ajung fie date agregate pentru metrics/analytics sau doar alea pentru deciziile importante, in felul asta reducand latenta operatiilor, scade latimea de banda utilizata (care conteaza mult in M2M pe link-uri proaste sau un zone greu accesibile).
Dupa aia a avut un nene de la Romtelecom o prezentare in care a inceput sa se laude ce tare e Romtelecomul in Romania. Am plecat de la prezentare ca nu am inteles de ce au simtit nevoia sa se laude.
Dupa aia a fost o prezentare de UCS asta nou si ce unelte de administrare si configurare centralizata are pentru el. Am fost partial atent ca vorbea nenea ala foarte monoton, de parca era in Speed: nici prea tare, nici prea incet ca altfel explodeaza bomba.
Pauza de masa cu o coada imensa si mancare nu chiar grozava. Dar eram nehalit de la 7 de dmineata si era 14 si mi-era foame, asa ca n-am comentat prea tare. Dupa aia au ramas fara cafea si au dat apa si cola din sticle de 2L, sa faca economie.
Dupa-masa au fost sesiuni paralele si m-am dus sa vad o prezentare tinuta de Datanet despre cum s-a apucat Cisco sa integreze SourceFire in ASA pe de o parte si o prezentare de SourceFire in general pe de alta parte. A fost okish, cam prea romglezita prezentarea, cu multe detalii tehnice pe care le-ar cunoaste doar aia de s-au dat un pic cu produsele (norocul meu ca m-am dat cu amandoua – ASA si SourceFire un pic) sa pricep ce vroiau sa zica. Pe de alta parte am facut poze sa ma ajute sa castig si io vreo 2 CPE-uri la CEH si CISSP :))
Microsoft a avut o prezentare despre Hyper-V 2012 R2 in combinatie cu Cisco UCS si System Center ca si modalitate de management software/hardware. Se pare ca indianul ala de e acu sef la MS s-a imprietenit cu Linuxul ca acu Hyper-V stie Debian, RedHat, Ubuntu, Suse si pe langa asta stie si de FreeBSD si culmea, alea stiu de Hyper-V si au driverele care trebuie.
Dupa aia am vrut sa ajung la o sesiune de Network Design Failures de la Cronus da pana m-am orientat am ajuns ajuns cu 5 minute inainte de inchidere si am inteles fix o pula. Sper sa pot sa produc prezentarea ca era chiar misto din ce-am dedus io din cele 2 slide-uri de le-am prins :)
Ultima pe lista era o prezentare de Unified Datacenter care de fapt s-a dovedit a fi o prezentare cu focus pe ACI si despre cum iti poti face Software Defined {Datacenter, Networking} cu Cisco si Puppet/Chef si despre ce inventie mare e ACI asta si despre ce nasol era cu applet-uri EMM pe switch-uri si routere pentru automatizare de operatiuni. Moment in care mi-am bagat picioarele si am taiat-o.
Nu stiu daca Cisco Connect asta e acelasi lucru cu Cisco Expo, dar sper sa nu fie si sa fi fost ceva asa separat, ca altfel s-a dus pulii de suflet si conferinta asta: multa vorba fara sa zica nimic prea concret.