Debian Squeeze: IPv6 addrconf: prefix with wrong length 48

[DPLuS]

Ik heb een standaard debian squeeze i386 installatie met de volgende netwerkconfiguratie:

code:

patrick@argon:/var/log$ cat /etc/network/interfaces 
auto lo eth0 eth1
iface lo inet loopback

iface eth0 inet static
        address x.x.67.131
        netmask 255.255.255.128
        gateway x.x.67.129

iface eth0 inet6 static
        address x:x:c154:2822::1
        netmask 48
        gateway x:x:c154::1

iface eth1 inet static
        address 10.10.10.1
        netmask 255.255.255.240

Het probleem is dat ik in mijn syslog deze meldingen zie:

code:

Sep 27 09:28:07 argon kernel: [51602.966457] IPv6 addrconf: prefix with wrong length 48
Sep 27 09:28:10 argon kernel: [51605.966073] IPv6 addrconf: prefix with wrong length 48
Sep 27 09:28:13 argon kernel: [51608.964673] IPv6 addrconf: prefix with wrong length 48
Sep 27 09:28:16 argon kernel: [51611.963313] IPv6 addrconf: prefix with wrong length 48
Sep 27 09:28:19 argon kernel: [51614.962887] IPv6 addrconf: prefix with wrong length 48
Sep 27 09:28:22 argon kernel: [51617.961793] IPv6 addrconf: prefix with wrong length 48
Sep 27 09:28:25 argon kernel: [51620.960170] IPv6 addrconf: prefix with wrong length 48
Sep 27 09:28:28 argon kernel: [51623.959832] IPv6 addrconf: prefix with wrong length 48
Sep 27 09:28:31 argon kernel: [51626.959384] IPv6 addrconf: prefix with wrong length 48
Sep 27 09:28:34 argon kernel: [51629.959092] IPv6 addrconf: prefix with wrong length 48
Sep 27 09:28:37 argon kernel: [51632.958681] IPv6 addrconf: prefix with wrong length 48
Sep 27 09:28:40 argon kernel: [51635.958262] IPv6 addrconf: prefix with wrong length 48
Sep 27 09:28:43 argon kernel: [51638.957896] IPv6 addrconf: prefix with wrong length 48
Sep 27 09:28:46 argon kernel: [51641.957530] IPv6 addrconf: prefix with wrong length 48
Sep 27 09:28:49 argon kernel: [51644.957129] IPv6 addrconf: prefix with wrong length 48
Sep 27 09:28:52 argon kernel: [51647.956746] IPv6 addrconf: prefix with wrong length 48
Sep 27 09:28:55 argon kernel: [51650.956357] IPv6 addrconf: prefix with wrong length 48
Sep 27 09:28:58 argon kernel: [51653.955996] IPv6 addrconf: prefix with wrong length 48
Sep 27 09:29:01 argon kernel: [51656.955599] IPv6 addrconf: prefix with wrong length 48
Sep 27 09:29:04 argon kernel: [51659.955211] IPv6 addrconf: prefix with wrong length 48

Ik heb al gezocht en vond deze pagina:
https://www.transip.nl/vr...g-addrconf-prefix-length/
echter werkt dit niet, omdat sysctl.conf blijkbaar geladen wordt, voordat de IPv6 module geladen wordt, zie ook: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=507788

Voor de duidelijkheid moet ik erbij zeggen dat deze syslog meldingen er al waren voordat ik het statische inet6 adres toegevoegd heb.

Dit is de output van ifconfig:

code:

patrick@argon:/var/log$ sudo ifconfig 
eth0      Link encap:Ethernet  HWaddr 00:0c:29:48:f7:da  
          inet addr:x.x.67.131  Bcast:x.x.67.255  Mask:255.255.255.128
          inet6 addr: x:x:c154:2822::1/48 Scope:Global
          inet6 addr: fe80::20c:29ff:fe48:f7da/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:71521 errors:0 dropped:0 overruns:0 frame:0
          TX packets:12012 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:7799599 (7.4 MiB)  TX bytes:12763320 (12.1 MiB)

eth1      Link encap:Ethernet  HWaddr 00:0c:29:48:f7:e4  
          inet addr:10.10.10.1  Bcast:10.10.10.15  Mask:255.255.255.240
          inet6 addr: fe80::20c:29ff:fe48:f7e4/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:4 errors:0 dropped:0 overruns:0 frame:0
          TX packets:12 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:240 (240.0 B)  TX bytes:936 (936.0 B)

lo        Link encap:Local Loopback  
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

Mijn vragen: waar komt die syslog melding vandaan, wat betekent het, en hoe kan ik die meldingen wegwerken?

[GraveR]

IPv6 prefixes zijn meestal subnets van /64. De 48 vervangen door 64 zal hoogstwaarschijnlijk het gewenste resultaat opleveren.

Voor het laden van de ipv6 module voor sysctl zou het voldoende moeten zijn om ipv6 aan /etc/modules toe te voegen.

En die 2 commando's kun je aan /etc/network/interfaces toevoegen:

iface eth0 inet6 static
        address x:x:c154:2822::1
        netmask 48
        gateway x:x:c154::1
        up sysctl -w net.ipv6.conf.all.accept_ra=0
        up sysctl -w net.ipv6.conf.all.autoconf=0

[ Voor 69% gewijzigd door GraveR op 27-09-2011 09:57 ]

[CAPSLOCK2000]

Die sysctl.conf dingen heb je alleen iets aan als je een IPv6 router op je netwerk hebt (en niet op deze computer). Eerlijk gezegd lijken de meldingen daar wel op. Die twee 'echo' commando's uit de gelinkte post kun je op ieder willekeurig moment doen, ook na het booten. (Je moet het wel iedere boot opnieuw (laten) doen).
Probeer dat en laat weten of het helpt.

Ik vind je adres een beetje gek, maar kan niet zeggen dat het fout is.
Het is gebruikelijk om de dubbele dubbelepunt op de subnet-grens te plaatsen. Als ik 'x:x:c154:2822::1' lees, dan zou ik denken dat 2822 bij het netwerkdeel hoort en dat je dus een /64 subnet hebt.
Maar, zoals ik al zei, volgens mij is het technisch gezien toegestaan.
Kun je uitleggen of je hier bewust voor hebt gekozen of niet?

[DPLuS]

Die machine staat colocated bij TransIP en dan krijg je automatisch een IPv6 range toegewezen.
Dit is die range volgens het control panel:
x:x:c154:2822::/64

Als ik dan een IP adres aanmaak, bijvoorbeeld:
x:x:c154:2822::1
dan staat er bij als subnet masker: /48
en als gateway kan ik dan:
x:x:c154::1 gebruiken

Misschien klopt die /48 dan wel niet?
Volgens de documentatie op Transip:

code:

Log in op uw server en configureer het IPv6-adres. Configureer ook de juiste "prefix length" (/48). Deze waarde vindt u terug in de kolom "subnet" in de tabel met actieve IP-adressen op het controlepaneel.

En had ik beter als IPv6 adres het volledige adres kunnen typen:
x:x:c154:2822:0000:0000:0000:0001 ?


edit:

@Graver:

Als ik trouwens als root deze commando's uitvoer:
echo 0 > /proc/sys/net/ipv6/conf/eth0/accept_ra
echo 0 > /proc/sys/net/ipv6/conf/eth0/autoconf

verdwijnen de meldingen in de syslog...


@Capslock2K:

Als ik in het Controlepaneel het volledige IP v6 adres invoer, maakt hij van dit ipv6 adres:
x:x:c154:2822:0000:0000:0000:0001
uiteindelijk toch dit:
x:x:c154:2822::1


Edit2:

Veelgestelde vragen


Waarom zie ik als subnet /48 staan terwijl ik een /64 IPv6-range heb?


Omdat op onze colocated racks een gedeelde /48 range is geconfigureerd staat er als subnet/prefixlen /48 vermeld in het overzicht. Dit is, omdat de default gateway buiten de toegewezen /64 range ligt.
Bij het configureren van het ip-nummer op uw apparatuur dient u er hierom rekening mee te houden om als prefixlen /48 op te geven.

[ Voor 63% gewijzigd door DPLuS op 27-09-2011 12:19 ]

[CAPSLOCK2000]

Dat die twee commando's werken zegt mij dat er een router advertisement daemon actief is.
Een beetje vergelijkbaar met DHCP.
Een router schreeuwt rond "op dit netwerk gebruiken wij ip-range x:y:z" en je server kan die informatie gebruiken om zichzelf een IP-adres. Die link naar TransIP probeert hetzelfde uit te leggen.

Dan vraag ik me wel af waarom TransIP hun radvd niet configureren om de juiste informatie door te geven.

Maar goed, eigenlijk heb je dus geen probleem op wat overbodige logmeldingen na. Graver heeft daar een werkende oplossing voor gegeven.

[DPLuS]

De twee commando's aan /etc/network/interfaces toevoegen werkte niet, ik heb ze nu aan rc.local toegevoegd en het werkt nu.

[Hero of Time]

Er is een bug report hierover bij Debian:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=507788
Misschien vind je er wat nuttigs in. Het in rc.local stoppen werkt uiteraard ook gewoon .
Wat GraveR postte als oplossing zou moeten werken, maar het is mogelijk dat tijdens boot er geen volledige PATH variabele is gezet. Neem daarom het volledige pad, /sbin/sysctl. Werkt dat wel?
Wat ik ook in de bug report lees is dat voor iemand de net.ipv6.conf.all niet werkt, maar net.ipv6.conf.eth0 wel. Een ander gebruikt net.ipv6.conf.default en werkt het voor alle interfaces. De uitleg is dat all werkt op de interfaces die er nu zijn, en default op interfaces die je later nog kan krijgen. Vreemde situatie, maar het kan werken.

Ik vind het wel erg slordig dat ze een /48 advertisen terwijl ze weten dat het deze "problemen" geeft. Omdat het zo vaak voor komt in je log, zal je snel belangrijke dingen missen en je logs worden daarbij gigantisch. Beetje jammer van een professioneel hosting bedrijf.
Toegegeven, om het op een iets nettere manier op te lossen is ook weer zoiets om 65k aan adressen aan je router toe te kennen om iedereen netjes een /64 mask te geven met toch een gateway die bereikbaar is. Maakt het niet echt overzichtelijk en begrijp om deze reden dan ook de beslissing die genomen is.

Voor radvd heb ik tijdens mijn afstudeerproject gemerkt dat je er geen /48 mee kan advertisen. Het weigert te starten. Pas als je /64 gebruikt en niets anders klaagt het niet en doet 't z'n ding. Misschien dat ze andere software gebruiken die 't wel kan.

Voor de notatie van het adres, het schrijven van add:add:0000:0000:0000:add:add:1 is gelijk aan add:add:0:0:0:add:add:1, wat ook weer gelijk is aan add:add::add:add:1. De reeksen met 0-en kunnen worden ingekort en afgebroken met een dubbele dubbele punt. Maar dit mag maar 1 keer. Dit staat allemaal beschreven op Wikipedia.

[CyBeR]

Lang verhaal kort: je kunt geen autoconfig gebruiken door de netwerkset-up van TransIP*. Zet dat uit om die melding weg te krijgen.

Dit moet al genoeg zijn:

echo 0 > /proc/sys/net/ipv6/conf/eth0/autoconf

*) TransIP is overigens niet de enige colo-ISP waar autoconfig niet werkt of niet aan staat. Dat is eerder regel dan uitzondering, zelfs.

[Hero of Time]

Ehm, CyBeR, dat is wat hij al doet

[CyBeR]

Ja, maar jullie maken om de een of andere reden een verhaal van 20 alinea's voor iets wat in drie regels klaar is

Overigens "advertisen" ze geen /48. Dat kan niet. Autoconf werkt alleen met een /64. Dat heeft 'ie niet ingesteld en daarom krijgt 'ie die melding.

[ Voor 40% gewijzigd door CyBeR op 28-09-2011 01:28 ]

[Hero of Time]

Er zou geen topic zijn als hij geen probleem had met Squeeze. Er is een bug waar hij last van heeft en daarom postte hij hier. En tja, ik schrijf nogal uitgebreid, kan ik ook niet veel aan doen .

Vziz wordt er blijkbaar wel een /48, of iig iets, geadvertised. Ik ga het eens in een VM proberen, heb toch een SIxxs tunnel met een subnet die ik kan gebruiken. Is dacht ik ook een /48.

[CyBeR]

Hero Of Time schreef op woensdag 28 september 2011 @ 19:22:
Er zou geen topic zijn als hij geen probleem had met Squeeze. Er is een bug waar hij last van heeft en daarom postte hij hier. En tja, ik schrijf nogal uitgebreid, kan ik ook niet veel aan doen .

Squeeze heeft hier niets mee te maken. Dit zit (al tijden overigens) in de Linux kernel. Mijn Lenny bakken doen 't ook.

Vziz wordt er blijkbaar wel een /48, of iig iets, geadvertised.

Nee, dat kan écht niet, ten eerste. En ten tweede staan router advertisements bij colo-isp's nooit aan, omdat klanten daar geacht worden statische ip's in te stellen.

Wat TransIP doet is een hele zooi klanten in een /48 vlan proppen en elk van die klanten zelf een /64 toebedelen. Hun router zit vervolgens ergens in 't begin in z'n eigen 64'je, daarom moet je als klant op dat moment een /48 op je interface configureren.

[ Voor 15% gewijzigd door CyBeR op 29-09-2011 00:44 ]

[Hero of Time]

CyBeR schreef op donderdag 29 september 2011 @ 00:41:
[...]


Squeeze heeft hier niets mee te maken. Dit zit (al tijden overigens) in de Linux kernel. Mijn Lenny bakken doen 't ook.

Het gaat om de sysctl instellingen die niet werken omdat IPv6 later pas geladen wordt. Wat ze op de website hebben staan werkt dus niet, iets wat de TS al geprobeerd had. Dat je de meldingen in je syslog krijgt, prima, maar dat zou je uit moeten kunnen schakelen via sysctl, wat dus niet werkt: bug.

[...]

Nee, dat kan écht niet, ten eerste. En ten tweede staan router advertisements bij colo-isp's nooit aan, omdat klanten daar geacht worden statische ip's in te stellen.

Wat TransIP doet is een hele zooi klanten in een /48 vlan proppen en elk van die klanten zelf een /64 toebedelen. Hun router zit vervolgens ergens in 't begin in z'n eigen 64'je, daarom moet je als klant op dat moment een /48 op je interface configureren.

Hence dat ik 't in een VM ga proberen. Zoals ik in m'n eerste post hier al zei, radvd kan geen /48 geven, dat kreeg ik niet voor elkaar. En natuurlijk draait het niet, anders had ik hij wel twee IPv6 adressen op z'n eth0 gehad, en niet maar 1 die hij heeft ingesteld. Dat bedenk ik mij nu ook.
Ik ben wat roestig met IPv6, het is alweer anderhalf jaar geleden dat ik er iets mee heb gedaan.

[Hero of Time]

Ok, ik heb eindelijk wat tijd genomen om het te testen in een VM, die volledig los staat van het netwerk. Deze geeft geen meldingen in syslog over de prefix die verkeerd zou zijn, terwijl er wel een /48 op de interface aanwezig is. Als ik er een /64 adres van maak met de /48 prefix, nog steeds niets.
De bug report die ik eerder linkte staat nu als done, de bug is gefixt en is nu alleen nog aanwezig bij custom kernels. Daar kunnen ze niets aan doen. Het is dus zeer goed mogelijk dat door deze bugfix ik het niet zie. De waardes in /proc bij mij staan op 1, oftewel, het accepteert het. Daar ligt het dus niet aan.

Als de TS nog steeds die meldingen krijgt nadat hij alle packages heeft bijgewerkt (en niet de RA en autoconf uit heeft), dan moet er wel een RA draaien, maar wordt op de een of andere reden niet geaccepteerd door het systeem omdat het een /48 is, en geen /64 zoals gebruikelijk.

[CyBeR]

Die melding krijg je ongeacht of er een router advertisement daemon ergens draait. Zodra je subnet anders is dan /64 op een ethernet interface komt 'ie tevoorschijn. IMO ook een bug (in de kernel welteverstaan), aangezien je er niets aan hebt.

[Hero of Time]

Ik krijg 'm niet, dus of het is onlangs aangepast in Squeeze, of het komt wel door RA.