- NLNOG - NLNOG

New (2-byte) ASN Allocation for RIPE NCC
by leo.vegoda＠icann.org 10 Sep '08

10 Sep '08

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, This is to confirm that the IANA has allocated one 2-byte ASN block to the RIPE NCC: 48128-49151 Assigned by RIPE NCC whois.ripe.net 2008-09-09 A note of the allocation has been made at: http://www.iana.org/assignments/as-numbers/as-numbers.xml http://www.iana.org/assignments/as-numbers/as-numbers.xhtml http://www.iana.org/assignments/as-numbers/as-numbers.txt Thank you and best regards, Leo Vegoda leo.vegoda at icann.org ******************************************* Internet Assigned Numbers Authority (IANA) 4676 Admiralty Way, Suite 330 Marina del Rey, CA 90292 Phone: +1-310-823-9358 Fax: +1-310-823-8649 ******************************************* -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (Darwin) iD8DBQFIx9suvBLymJnAzRwRAgnkAKDDxJCilYy0aErDQtQQFEcsCKG/QwCgi+Ao 029EI3Ful4LKPXMJEUGKs3g= =7EeD -----END PGP SIGNATURE-----

1 0

GE koper network taps
by arjan＠vanderoest.net 22 Aug '08

22 Aug '08

Heren, Om de stilte maar weer eens te doorbreken: ik had vandaag een niet nader te noemen vendor van een TAP device op bezoek. In eerste instantie werd geclaimed dat het device volledig transparant en failsafe was en dat uitvallen van of defecten aan het apparaat geen enkel effect hadden op de getapte link, we bespraken een GE/koper oplossing. Echter, wat verder in de meeting kwam naar voren dat de oplossing niet zo transparant bleek als ik in eerste instantie voor ogen had. Er van uitgaande dat het ding tussen Dev-A (via tap poort Tap-A) en Dev-B (via tap poort Tap-B) geplaatst zal worden en dat de monitoring device aan poort C komt te hangen was de stelling als volgt: bij een GE link zal Dev-A een master/slave relatie aangaan met Tap-A en Dev-B met Tap-B. Mocht de TAP doos nu falen of zonder spanning komen te zitten dan zal er een failsafe circuit in werking treden waardoor er een fysieke 1:1 connectie tussen Tap-A en Tap-B tot stand komt. Op dat moment moeten Dev-A en Dev-B opnieuw een handshake uitvoeren en een master/slave relatie tot stand brengen. Ergo, bij een failure gaat je getapte link kortstondig down (hoewel hij daarna wel weer snel opkomt via het failsafe mechanisme). De fabrikant in kwestie beweert dat dit niet anders kan bij GE (in tegenstelling tot FE) en dat het niet mogelijk is om Dev-A en Dev-B direct met elkaar te laten negotiaten, wanneer de tapvoorziening actief is. Mijn stelling was dat je op laag-1 gewoon het signaal zou moeten kunnen 'aftappen' en dat het device niets op laag-2 zou moeten/hoeven doen en dat je hiermee dus een down/up schakeling in geval van device-failure mee zou kunnen voorkomen. Volgens de fabrikant was dat echter onmogelijk en was er geen enkele fabrikant die een GE tapdoos bouwde die op deze manier kon werken. Exacte argumenten kon hij me op dit moment niet geven. Iemand hier die hier iets nuttigs over kan zeggen? Arjan

2 5

interessante uitspraak
by sabri＠cluecentral.net 23 May '08

23 May '08

Beste mensen, Ik vond een interessante uitspraak mbt het offline halen van een "beledigende" website door de ISP: http://zoeken.rechtspraak.nl/weekoverzicht/default.aspx?details=true&datum_… Ten aanzien van IS InterNed Services 4.6. IS InterNed Services voert het volgende verweer. Op IS InterNed Services rust in beginsel geen verantwoordelijkheid voor de inhoud van een bericht dat is geplaatst op een website waarvan zij de hosting verzorgt. Zij voert het beleid dat een website direct uit de lucht wordt gehaald, wanneer het gebruik door een klant leidt tot een evident onrechtmatige situatie. De uitingen op de website van A-Group kunnen niet als onmiskenbaar onrechtmatig worden beschouwd. Staat der Nederlanden heeft haar nodeloos in de onderhavige procedure betrokken, nu Staat der Nederlanden uit de met IS InterNed Services gevoerde correspondentie had kunnen afleiden dat IS InterNed Services na ontvangst van een rechterlijk vonnis waarin de gewraakte uitlatingen onrechtmatig worden beoordeeld, onmiddellijk tot het verwijderen van de website zou zijn overgegaan. 4.7. De voorzieningenrechter overweegt als volgt. Op grond van het bepaalde in art. 6:196c lid 4 BW is een serviceprovider niet aansprakelijk voor de opgeslagen informatie, indien hij niet weet van de activiteit of informatie met een onrechtmatig karakter of daarvan niet redelijkerwijs behoort te weten, dan wel - zodra hij daarvan weet of redelijkerwijs behoort te weten - prompt de informatie verwijdert of de toegang daartoe onmogelijk maakt. Blijkens de memorie van toelichting is de enkele kennisgeving van een derde omtrent de aanwezigheid van onrechtmatige informatie onvoldoende voor de conclusie dat de serviceprovider weet of redelijkerwijs behoort te weten dat de informatie een onrechtmatig karakter heeft; dat is echter anders wanneer aan de juistheid van de kennisgeving in redelijkheid niet getwijfeld kan worden, zoals wanneer de informatie op de website onmiskenbaar onrechtmatig is (TK 2001-2002, 28 197, nr. 3, blz. 49). Pas indien op deze gronden tot aansprakelijkheid van de serviceprovider voor de opgeslagen informatie geconcludeerd kan worden, is een - op die onrechtmatige daad gebaseerde - vordering jegens de serviceprovider tot verwijderen of ontoegankelijk maken van de informatie toewijsbaar. 4.8. De voorzieningenrechter overweegt dat in het onderhavige geval niet kan worden gezegd dat aan de juistheid van de inhoud van de in 2.7 bedoelde brief van de Staatssecretaris van Financi?n in redelijkheid niet getwijfeld kon worden. Het betreft immers slechts een reactie van een derde op uitlatingen die zijn geplaatst op een website waarvan IS InterNed Services de hosting verzorgt. IS InterNed Services wist niet, en kon ook niet weten, waarop de uitlatingen waren gebaseerd, zodat zij zich geen oordeel omtrent de juistheid of rechtmatigheid ervan kon vormen. Het feit dat het de Staat der Nederlanden was die deze uitlatingen in voormelde brief als onrechtmatig kenschetste, maakt niet dat IS InterNed Services wist of redelijkerwijs behoorde te weten dat de uitlatingen een onrechtmatig karakter hadden. IS InterNed Services heeft dan ook niet onrechtmatig gehandeld door na ontvangst van de brief van de Staatssecretaris van Financi?n niet onmiddellijk de toegang tot de website van A-Group onmogelijk te maken. Uit de tussen partijen gevoerde correspondentie en de daarop ter zitting gegeven toelichting blijkt dat IS InterNed Services wachtte op de ontvangst van een rechterlijk vonnis waarin de uitlatingen op de website van A-Group als onrechtmatig zouden worden beoordeeld. Hierna zou zij overeenkomstig haar beleid de toegang tot de website terstond hebben geblokkeerd. De Staat der Nederlanden had derhalve kunnen volstaan met het instellen van een vordering jegens A-Group. De voorzieningenrechter gaat er dan ook van uit dat IS InterNed Services op basis van dit vonnis de website van A-Group zoals toegezegd zal blokkeren. Voor zover de vorderingen zich richten tegen IS InterNed Services zullen ze derhalve worden afgewezen. Groeten, -- Sabri

1 0

inkoop van netwerkapparatuur
by maarten＠tepaske.net 15 Apr '08

15 Apr '08

Hopelijk heeft hier iemand tips: Heeft iemand namen van bedrijven die gebruikte netwerkapparatuur inkopen? Iets concreter: we hebben een Alpine 3808 (1x GBIC, 8x GE, 96x FE en 2x PSU) die enkel in de weg staat. Is zo'n ding trouwens sowieso nog iets waard? Groet, Maarten

3 2

'banned' username lijst
by arjan＠vanderoest.net 03 Apr '08

03 Apr '08

All, Ik vraag mij af iemand hier in het bezit is van een soort algemene lijst van usernames die je niet door je klanten zou willen laten registeren, for obvious reasons. Ik kan mij voorstellen dat ik mijn klanten geen usernames als 'sales at dienst.nl' (of helpdesk, info, root, postmaster, etc) wil laten registeren, ook al komen deze usernames op een realm die los staat van de bedrijfsnaam. Ik had hier ook met een collega een discussie over: hoe ver zou je hier in willen gaan? Zou je ook bijvoorbeeld hitler at dienst.nl willen verbieden? En zo ja, polpot at dienst? Gobels? De lijst van zeer bedenkelijke foute mensen is helaas erg groot. En nog een stap verder: wil je zaken als 'kut at dienst.nl" of "lul at dienst" blokkeren? Ergo : hoe gaan de mensen hier (die een automagische online subscription feature zonder menselijke interventie/controle) hiermee om? Arjan

5 5

Nieuwjaarsborrel
by bvisser-nlnog＠xs4all.nl 19 Mar '08

19 Mar '08

> > On Mar 9, 2008, at 13:30 , Sander Steffann wrote: > >> Hi Niels, >> >>> Hallo heren, dames, >>> Hebben er andere mensen hier ook behoefte aan 'n nieuwjaarsborrel? >>> De Bekeerde Suster, vrijdag over twee weken ofzo? >> >> Beetje laat, maar een borrel sla ik niet af :) > > Borrel? Someone say borrel? > > !borrel++ > I'm parsing this to No(t) more borrel ... parser error, wrong language, programmer thinko, or as intended ? Maar goed, elk excuus voldoet, ook al klinkt paasborrel. of (goede) vrijmibo inmiddels beter. Boudewijn

4 3

Nieuwjaarsborrel
by niels.bakker＠ams-ix.net 19 Mar '08

19 Mar '08

Hallo heren, dames, Hebben er andere mensen hier ook behoefte aan 'n nieuwjaarsborrel? De Bekeerde Suster, vrijdag over twee weken ofzo?

6 5

OT: OpenNMS seminar in Nederland
by s.steffann＠computel.nl 15 Mar '08

15 Mar '08

Hoi, Voor het geval dat hier OpenNMS gebruikers zijn even een heads up: op 15 mei is er een 1-day seminar in Nederland: http://blogs.opennms.org/ De locatie zal waarschijnlijk in Apeldoorn zijn. Sander

2 1

Mpls op evpn?
by bvisser-nlnog＠xs4all.nl 13 Mar '08

13 Mar '08

> Boudewijn, > > Dank voor je inside info. Dat de NG dienst transparanter was/zou gaan > worden wist ik ja. Ik was een tijd krap jaar geleden op zoek naar een > dienst die mij een aanzienlijk (in de duizenden) aantal MAC adressen > zou toestaan aan weerszijde en toen werd me door de KPN product > manager al gewezen op het in ontwikkeling zijnde platform, ik meen op > basis van Alcatel spullen. > > Ik heb de info doorgegeven aan de persoon die er om vroeg, ook zijn dank. Graag gedaan. Nog een aanvulling of misschien correctie : Een vandaag ook binnengekomen bericht van nog iemand anders meldt dat "de" (?) MTU van de nortel gebaseerde evpn dienst 1492 is, klantzijdig. Frames tot 1514 zouden dan gefragmenteerd worden. (details over fragmenteren [en reassembly ?] van ethernetframes heb ik niet gehoord) De E-VPN NG informatie acht ik wel betrouwbaar , de wat wisselende antwoorden mbt tot het Nortel platform is mogelijk omdat mensen die antwoorden vanuit bv een dienstbeschrijving voor de klant. Ik zou me zo kunnen voorstellen dat er dan vooral over de pure IP MTU gepraat wordt, eventueel met VPN overhead erbij. (Ik heb dus niet de design specs gezien van de diensten). Zelfs met wat kennissen in de organisatie is het vinden van een techneut die _echt_ begrijpt wat je wilt en kan antwoorden niet simpel... Grote organisaties, zucht. Absoluut een gevalletje voor je kennissen om toch even door te duwen op de accountmanager voor de formele commitments, en niet hun hele plan meteen aan deze informatie op te hangen. Boudewijn > > Arjan > > On 3/12/08, Boudewijn Visser <bvisser-nlnog at xs4all.nl> wrote: >> >> BV schreef eerder : >> > >> > Het zal in elk geval redelijk ongebruikelijk zijn, zelf MPLS over EVPN >> > draaien. >> > Ik heb wat gevraagd onder mensen die bij KPN zitten of zaten; >> > Eerste antwoord is dat de MTU voor het Nortel OM1400 gebaseerde EVPN >> 1514 >> > is; >> > (Er is ook een EVPN-NG (Next Generation) dienst met andere >> apparatuur). >> >> En inmiddels is nog een antwoord binnengedruppeld : >> >> E-VPN NextGen transporteert de frames transparant, en heeft een MTU tot >> 1920 bytes. >> >> Dat zou dan geen probleem moeten zijn met MPLS lijkt me. Bij het nortel >> gebaseerde EVPN zul je zo te zien geen ip mtu van 1500 bytes overhouden >> als je mpls eroverheen legt. >> >> Boudewijn >> >> [knip : je sla's krijg je alleen met een kpn officieel antwoord, >> natuurlijk] >> >> >> >

1 0

Mpls op evpn?
by bvisser-nlnog＠xs4all.nl 13 Mar '08

13 Mar '08

> Ik zet een vraag door van een partij met wie ik veel samen gewerkt > heb, maar zij zitten zelf niet op nlnog :) Volgens zijn zeggen kon KPN > geen uitsluitsel geven. Ik verbaas me nergens over, hoewel het er bij > KPN heel erg aan ligt met wie je praat. Ik heb vroeger wel eens met > evpn gewerkt, maar heb er nooit MPLS over gedaan. Ik verwacht dat met > name de MTU een probleem kan zijn, hoewel ik nog niet stil had gestaan > bij het Ethertype. > > Maar niemand die uit ervaring kan spreken? Het zal in elk geval redelijk ongebruikelijk zijn, zelf MPLS over EVPN draaien. Ik heb wat gevraagd onder mensen die bij KPN zitten of zaten; Eerste antwoord is dat de MTU voor het Nortel OM1400 gebaseerde EVPN 1514 is; (Er is ook een EVPN-NG (Next Generation) dienst met andere apparatuur). Natuurlijk zitten er ook bij KPN best mensen die precies weten wat de specs van een bepaalde dienst zijn; Het enige is dat het enige tijd & moeite kan kosten voordat zo'n vraag ook bij die mensen is beland, via account managers, customer support etc. Voor een formele commitment wat de dienst kan (vs "wat op dit moment werkt") moet je natuurlijk dat pad op. Ik zou dan de vraag niet formuleren als "kan ik mpls doen", maar welke MTU is gegarandeerd, en is de dienst transparant voor alle valide ethernet frames inclusief ethertype 0x8847/0x8848 . (bofh techneut zou op "kan mpls" prima ja kunnen antwoorden, zolang je je IP mtu maar navenant kleiner zet tov de ethernet mtu ...) Boudewijn > > On 3/11/08, Alex Bik <alex at bit.nl> wrote: >> On Tue, 11 Mar 2008, arjan at vanderoest.net wrote: >> >> > Weet iemand of de mtu van kpn evpn toereikend is om er mpls over te >> > doen? Kpn lijkt de vraag vooralsnog niet te kunnen beantwoorden. >> >> Verrassend :D >> >> 't Is toch gewoon een kwestie van MTU? Weten ze dat echt niet? >> >> -- >> Met vriendelijke groet, >> Alex Bik, >> BIT BV >> AB2298-RIPE >> > _______________________________________________ > NLNOG mailing list > NLNOG at nlnog.net > http://mailman.nlnog.net/mailman/listinfo/nlnog >

6 9