IPv6 felkapcsolás az Adatparkokban

IPv6

A 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.
Szakembereink 2011.06.03-án, a Magyar Telekom telephelyén, a Budapest, Asztalos Sándor utca 13. szám és Budapest, Petőfi Sándor utca 17. szám alatti géptermeiben az IPv4-es címek mellett elérhetővé teszik az IPv6 címeket.

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.
Regisztráció: http://rendezveny.telekom.hu/rendezveny/ipv6workshop2.reg
Első előadás anyaga: http://rendezveny.telekom.hu/ipv6workshop/

  • 10503 megtekintés

( dragi v | 2011. 06. 03., p – 08:17 )

Lemaradtam a konzultáció elejéről, valamilyen dokumentáció került ki erről az adatpark oldalára?

( ScOut3R | 2011. 06. 03., p – 09:38 )

Tartalomra itt a lehetoseg. Csak "kereslet" nem lesz ra addig, amig lakossagi oldalon nem lesz elerheto nativ IPv6 szolgaltatas.

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

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.

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-ip…
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

( cabal v | 2011. 06. 03., p – 11:28 )

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

( tovis v | 2011. 06. 03., p – 11:58 )

+subscribe

* Én egy indián vagyok. Minden indián hazudik.

( dragi v | 2011. 06. 03., p – 16:24 )

Nem mac addresből generált címet hogyan kell igényelni?

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

( Adatpark | 2011. 06. 21., k – 17:33 )

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

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.

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

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

( bajnokk | 2011. 06. 23., cs – 16:34 )

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