ls -1Itt lakik a HUP
Népszerű témákPartnerünkNépszerű fórum témákÚj felhasználók
|
IPv6 felkapcsolás az AdatparkokbanA tömeges elterjedés eddigi gátja az IPv6-os címek mögötti tartalom hiánya volt. Ennek kezelésére több szolgáltató, köztük a Magyar Telekom is elindította a rendszereinek az átállítását. 2011-05-31-én tartott szakmai konzultáción, hálózatfejlesztőink mondták el a véleményüket, ajánlásaikat az IPv6 használatával kapcsolatban. A konzultáció végén, igényként jelentkezett a fórum létrehozása, amin keresztül a témában érdeklődők beszélhetik meg kérdéseiket. Következő konzultációs időpont: 2011-06-21.
»
|
KeresésNavigációBelépésÁllásajánlatokHWSWFriss blogbejegyzésekHUP napi hírlevélInformációKövess minket! |
Lemaradtam a konzultáció elejéről, valamilyen dokumentáció került ki erről az adatpark oldalára?
Szia!
Még nem ment ki az anyag, hamarosan egy hírlevéllel megkapja mindenki, aki az Adatparkban üzemelteti a szerverét és kapcsolattartóként van bejelentve nálunk.
Gulyás Zoltán
Zoli, nem írtam ugyan erről emailt, de ezúton szeretném megkérni a kedves üzemeltetőket, hogy ne html-only leveleket küldözgessetek. Please.
Plain textben hogy mehetne át a bugyirózsaszín életérzés?
suckIT szopás minden nap! Perl script 11 millió forintért
Sziasztok!
Most mentek ki a levelek, benne az előadás anyagával és a következő konzultációra szóló meghívóval.
Köszi a visszajelzést, beszéltem a srácokkal.
Gulyás Zoltán
hosting termékmenedzser
Tartalomra itt a lehetoseg. Csak "kereslet" nem lesz ra addig, amig lakossagi oldalon nem lesz elerheto nativ IPv6 szolgaltatas.
Mar van elérhető nativ IPv6 szolgálatatás pl pont T-től, de elsőnek externettől volt és van is.
Pilot idoszak van. Nem neveznem hivatalos lakossagi szolgaltatasnak. :)
Externetnél nem. De jó lenne túllépni ezen és akinek van valami LAMP-ja olyan hostingcégnél ahol van lehetőség v6ra beállítaná.
A dolog folyamatban.
[off]
Az otthoni dual-stack-kel amugy meg kuzdok.
[/off]
megis mit csinalna a lakossag, amig a szerver oldal nincs felekszulve? Nyilvanvalo a sorrendje az atallasnak
Mégis miért ölne bele pénzt bárki olyasmibe, amit senki se tud használni, csak talán majd egyszer? :D
1, mert nem fenttarthato fejlesztes nelkul az uzletag
2, mert early adopternek lenni egy olyan technologiaban, ami tetszik vagy nem, de megkerulhetetlen lesz a jovoben nem biztos hogy rossz huzas.
3, mert igeny az lenne ra :)
Tyrael
A fenntarthatóság érdekes kérdés... Sajnos nagyon sok /8 /16 van olyanoknál, akik lecserélhetnék privát címekre, és visszavehető lenne egy rakat cím, de nem, ők az erősebb kutya, sz0pj0n vele e világ, de ők nem akarnak költeni egy centet sem...
jaja:
http://en.wikipedia.org/wiki/List_of_assigned_/8_IPv4_address_blocks
Tyrael
Ahogy az előadásokon is elhangzott, láttuk ezt az ördögi kört mi is.
Vagy a tartalom jelenik meg előbb, vagy a felhasználók, de sokáig mindenki a másikra várt.
Hosszútávon az látszik, hogy lépni kell, ennek csak az ideje volt kérdéses.
- Lehet sietve, kapkodva váltani akkor, amikor már nagyon késő,
vagy
- Lehet innovatívnak lenni és kényelmesen váltani, felkészülten, a célt is támogatva.
Mi ez utóbbit választottuk, mert azt láttuk, hogy rengeteg munkával jár. Fel kellett készíteni a rendszereinket, nyilvántartásainkat, tájékoztatni mindenkit, akit ez érint. Ezt mind nem, vagy nem ilyen gördülékenyen tehettük volna meg, ha az idő nyomása alatt cselekszünk.
Bízom benne, hogy ez minden partnerünk érdekét szolgálta :-).
Gulyás Zoltán
hosting termékmenedzser
Ez a sietve, kapkodva lepni eleg fura 20 evvel azutan, hogy az IPv6 implementalva lett, vagy mierre a kifejezes....
Az IPv4-es címek visszafordíthatatlanul fogynak. Mi a felkapcsolást megcsináltuk most, de biztosan lesznek olyanok, akik az utolsó pillanatra fogják ezt hagyni. A "kapkodást" arra értettem, hogy a későn váltóknak, akkor már a piac nyomása alatt nem, vagy csak korlátozottan lesz lehetőségük a műszaki részletek pontos kidolgozására, kockázatok körbejárására.
Gulyás Zoltán
hosting termékmenedzser
Ok ezt ertem. Szerintem is vannak, lesznek olyanok, akik azt mondjak, jo meg az IPv4 egy darabig. De akkor is furcsa, hogy ez mar a '90es vegen kesz volt es csak most kezdik el felkapcsolni cegek. Szerintem mindenkeppen a szolgaltatok kell megtegyek az elso lepest, mert a user nem fog vele foglalkozni.
Honnan veszed ezt a '90-es évek végén kész volt baromságot? Még ma sincs kész, egy rakás gyártó alap feature-ök (amelyek a v4-nél régóta működnek) implementálásával van elfoglalva.
suckIT szopás minden nap! Perl script 11 millió forintért
Arra probaltam utalni, hogy papiron mar megvolt. A kesz volt kifejezes tenyleg nem helyes. Mint elotte irtam, miplementalva volt, az talan jobb.
Bar 1-2 cikket olvasva, mar hardvereken is volt:
http://hup.hu/cikkek/20091203/per56os_forradalom_ipv6_otthonra
Az IPv6-tal 199x-ben (x>=8, pontosan sajnos már nem emlékszem) találkoztam először. Egy IBM 2210-es routeren jött velem szembe
https://blog.wireshark.org/2011/06/mostly-not-participating-in-world-ipv6-day/
P.S. According to the SCM revision logs IPv6 support was introduced in Wireshark in 1998. Tomorrow’s test is long overdue.
De ez megint, csak oda vezet, hogy a gyartok nagyivben tettek ra.
Az, hogy akkor voltak eszközök, amik már elviekben tudtak valami ipv6-féle dolgot, az az érem egyik oldala - a másik meg az, hogy ez mennyiben volt, mennyiben lett volna alkalmas éles szolgáltatás alá, és menyiben volt "nekünkmárvan" jellegű, brossúrának készült gányolás? Most, hogy jobban elkezdték nyomni a dolgot, most jönnek ki olyan implementációs (meg tervezési (hint: bizottság tervezte...)) problémák, amik az eszközök együttműködésére khm. rossz hatással van.
Egyetértünk, a tartalomszolgáltatás oldalon kell elindítani a folyamatot. Mivel sok esetben ezek épp ti vagytok, mi mint szolgáltatók az infrastruktúrát tudjuk ehhez nektek biztosítani. Ezért is tartom fontosnak, hogy a felkapcsolás ne csak teszt, hanem egy követendő útvonal legyen.
Azonban ahogy lentebb @zeller is említette, a műszaki fejlődésben a géptermünk összes összetevőjénél be kellett várni az IPv6 ready jelzést.
Megtörtént, megtettük :-).
Gulyás Zoltán
hosting termékmenedzser
A szakmai konzultáción elhangzott egy kérdés azzal kapcsolatban, hogy miként lehet ipv6-os névszervereket üzemeltetni? Vagy ez inkább az ISZT hatásköre? Esetleg van itt valaki tőlük?
"A +1 az a proletárlájk."
Adsz AAAA rekordot a névszervernek és automatikusan bekerül a glue rekord a regisztrációnál vagy frissítésnél.
dig -t ns $domain @ns.nic.hu paranccsal tesztelheted is.
Amennyiben nem az ns1-2.$domain a névszerver hanem ns1-2.valamimasdomain.hu akkor csak azoknak adsz AAAA rekordot és működik.
pl.: dig -t ns inet6.hu @ns.nic.hu
Sajnos a regcheck IPv6 only névszervereknél nem fut le:\
Köszi.
"A +1 az a proletárlájk."
+subscribe
* Én egy indián vagyok. Minden indián hazudik.
+1
Tyrael
+1
sub
Nem mac addresből generált címet hogyan kell igényelni?
adatparksales@telekom.hu
Köszi.
Nm. Bar nekem meg nem valaszoltak, de hivatalos uton iranyitottak oda. :)
Azóta megkaptad már a választ?
Nálam többen érdeklődtetek a gépetek IP címe felől, amikre a válaszok ki is mentek.
Gulyás Zoltán
hosting termékmenedzser
Szia!
Bocsanat a valasz elmaradt. Igen, jott valasz, bar azt erzem, hogy az arak tekinteteben meg bizonytalanok vagytok. :) A sales-es kapcsolattartonk azt mondta, hogy hamarosan lesz majd egy hivatalos kozlemeny. Illetve volt meg egy olyan technikai kerdes, hogy ha egy VM-nek nincs kulso IPv4-es laba, de a host-nak van es felhuzzuk a kulso labat, akkor automatikusan kap EUI-64-es cimet. Ilyen esetben kell fizetni ezert a cimert?
Szia!
Regisztrálni kell a MAC címeket és eui-64-t kaphatnak a virtuális gépek. Technikailag számunkra olyan mintha saját switche lenne, egy switchportunkon sok MAC cím fog látszódni.
Itt is érvényes, hogy a MAC címek változásával változik az IP cím is, bár nyilván virtuális szervereknél ennek a kockázata lényegesen kisebb mint egy hálókártyánál.
Akkor lehet ez gond, ha a virtuális gépeket új VLAN-ba költöztetitek.
Ha ezt a kockázatot el akarjátok kerülni, akkor érdemes a statikus IP címet igényelni a virtuális gépekhez.
Gulyás Zoltán
hosting termékmenedzser
signup
+1
színes aláírás
Köszönettel vettük mindenki részvételét a 2. konzultációnkon.
Kérésként elhangzott, hogy a támogató anyag (beállítások) kerüljön ki a portálra, ez a holnapi nappal teljesül.
Gulyás Zoltán
hosting termékmenedzser
Szervusz Zoltan!
Sajnos ma nem tudtam elmenni, ugyhogy a publikalt anyag igen hasznos lesz!
Kaptam a sales kapcsolattartonktol arakat, de az meg nem derult ki, hogy ezek havi dijak? (Gondolom igen.)
Szia!
Igen, ezek havidíjak, természetesen az 1db IPv6 cím/server, karbantartása részünkről továbbra is ingyenes.
Az anyagokat hamarosan kiteszem, a korábbi prezi pedig elérhető a lap tetején lévő linken.
Gulyás Zoltán
hosting termékmenedzser
Ha már így felmerült a dolog. Ez az egy db IPv6-os cím - figyelembe véve pl. azt is, hogy mekkora az IPv6-os tartomány - nem kevés egy kicsit?
Zoltan az EUI-64-es cimre gondolt, amit naluk default kap minden, publikus IPv4-es cimmel rendelkezo gep. Ezen felul kerhetsz sajat cimet egyesevel, vagy komplett tartomanyt. Ez utobbinak az ara igen kedvezo.
Az igen kedvező árat enyhe túlzásnak érzem, mert összemérhető a hosting árával. Bár darabra leosztva nyilván jól néz ki. Csak manapság a gépeken ritkán fut egy darab OS, és ha nem is kell az összesnek IPv6-os cím, azért mégiscsak több kellhet 2-3 darabnál.
Mindegy, már nem érint ez a probléma, csak az érdekel, hogy csak nekem (volt)probléma ez, vagy másnak is.
Ezt most nem ertem. Az igenyelheto tartomanyokban tobb van, mint 2-3 IP cim, es 1 /64-es tartomany havonta annyiba kerul, mint 1 IPv4-es cim atlagosan. Legalabbis en ezt kaptam a sales-es kapcsolattartonktol. En kibekultem ezzel a havidijjal a /64-es tartomanyert cserebe. :)
Amit én kaptam ajánlatot abban kissé más számok szerepeltek. És egy gúnyos kacaj kíséretében küldtem a kukába. Igaz előtte még írtam egy választ, hogy ez így nem frankó, de arra már nem kaptam visszajelzést.
Mi is eleg lassan kapunk valaszt a dolgokra. :) Egy ideje el van havazva a hostingos ugyfelkapcsolat. A nyar vegi koltozesnek meg a KFKI-s atalakulasnak tudom be egyelore a dolgokat. Azert remelem valtozik a helyzet. :)
ja evek ota el vannak havazva...
azert megnyugtato hogy nem csak minket er a megtiszteltetes, hogy magasrol sz..nak rank
Sziasztok!
Ezek az IPv6 igényléssel kapcsolatban felmerülő díjak:
IPv6 IP cím/ MAC Address 0Ft
Statikus vagy "szép" IP cím 500Ft
IPv6 címtartomány (statikus IP-re routeolva) /64-as méretű subnet 1 000Ft/hó
(1 VLAN kezelésére alkalmas)
IPv6 címtartomány (statikus IP-re routeolva) /60-as méretű subnet 4 000Ft/hó
(16 VLAN kezelésére alkalmas)
IPv6 címtartomány (statikus IP-re routeolva) /54-as méretű subnet 10 000Ft/hó
(256 VLAN kezelésére alkalmas)
Gulyás Zoltán
hosting termékmenedzser
Ettől "picit" más számokat kaptam amikor már a végleges(?) ára meg volt a terméknek. Mondjuk már nincs jelentősége, szerencsére van még pár hosting cég.
Gondolom az utolsó az /56 mivel abban van 256 subnet (/64), a /54 ben 1024 subnet van.
Szia!
Tökéletesen igazad van :-), elírtam.
/56-ot adunk.
Köszönöm
Gulyás Zoltán
hosting termékmenedzser
Szívesen:)
Szervusz!
Koszi! :)
Szép cím :-)) Például: C1CA::BABA?
Igen, ez egy szép cím.
Sajnos valójában annyi korlát van jelenleg, hogy a Adatparkokban lévő Cisco switch típusú eszközök jelenleg csak EUI-64 like IPv6 címre képesek szűrni a portokon.
Azaz a fenti mókás, C1CA::BABA, FACE::BOOC, ::FEED és egyéb mókás címek helyett sajnos csak egy egyszerűsített EUI-64 konverzión átesett IPv6 címet lehet használni – az egyszerűsítésen azt értsd, hogy nem tartalmazza a 48 bites mac address-t a címben, mert helyettesítve van pl.: 0-val.
Persze fenntartjuk a lehetőségét ennek is, ha a változik a HW helyzet nem lesz akadálya a fenti beállításoknak, de amíg a Cisco nem tudja, addig marad a generált „szép cím”.
Gulyás Zoltán
hosting termékmenedzser
Tehát FF:FE00 résznek kell benne lenni?
pl.: 2001:db8::FF:FE00:1
Kicsit zavaros a magyarázat. Az IPv6 Compression van bekapcsolva és ez okozza a problémát?
Szia!
Koszonom az infot!
FYI (hátha valakinek segít),
az egyetlen dolog, amit az adatparkos IPv6 felkapcsolás kapcsán megszívtam, az a következő hiba volt a Debian Lenny kernelben: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=511963
Amíg nem kapcsoltam ki a generic segmentation offloadot (ethtool -K eth0 gso off), addig (masszív IPv6 forgalom esetén) borzasztó mennyiségű (többszáz mega) kernel log keletkezett, és egy pillanat alatt betelítette a /var-t.
A hiba csak akkor áll fenn, ha stock Lenny kernel fut, "tg3" hálózati driverrel, és azt hiszem, a bonding is közrejátszott benne. (És a bugreporttal ellentétben nem xenes kernelen jött elő.)
Minden más ment, mint a karikacsapás. (Persze az ipv6-os tűzfalról nem szabad megfeledkezni!)
Az egy dolog, hogy ti elindítottátok, de a szolgáltatók aki bent vannak, azok nem nagyon.
--
Discover It - Have a lot of fun!
Vagy már régóta adnak tunellen át. Ami tesztelgetésre szerintem tökéletesen elég.
Persze, otthon lehet játszani egy tunnelel, teljesen jó, de azért éles szerveren az, hogy esetleg megszakad, nem elérhető, nincs sáv, az nem épp ideális.
--
Discover It - Have a lot of fun!