swinog April 2014

swinog@lists.swinog.ch

15 participants
12 discussions

Lösung für eine SMS-Notfallalarmierung und Statuswebseite

by Andy Christen

Grüezi und hoi Wir suchen für unsere Firma eine Lösung für eine SMS-Notfallalarmierung. Leider haben wir für diese Situation kein passendes öffentliches Angebot finden können, darum gelange ich an die Swinog-Mailingliste und hoffe, dass jemand von Ihnen/euch eine annähernd gleiche Lösung für sich selbst oder Kunden im Einsatz hat. Hier also die Anforderungen die wir haben: Anforderungen: Upload von Natelnummern auf ein Portal/Webseite mit Möglichkeit einer Gruppierung der Einträge. Versand von Info-/Status-SMS an die eingetragenen SMS-Gruppen per Webseite (admin) und/oder SMS-Forward. Status-Webseite öffentlich über dasselbe Portal einfach aufruf- und wartbar - ev. Status mit SMS updatebar Beispiel Inhalt Webseite/Statusseite: 14.04.2014 09:54 E-Mail Service läuft wieder 14.04.2014 08:01 E-Mail läuft nicht. Wir sind dran. 01.04.2014 00:01 Kein Scherz: alle Systeme grün. Vielen Dank schon im voraus und allen schöne und wo möglich ruhige Ostertage. enGruess, Andy Christen -- andreas.christen(a)ergon.ch, +41 44 268 8927, http://www.ergon.ch. Ergon Informatik AG, Kleinstrasse 15, 8008 Zuerich, Switzerland. ________________________________________________________________ e r g o n smart people - smart software

8 years, 7 months

New RIPE NCC contribution to the IANA IPv4 Recovered Address Space registry

by Leo Vegoda

Hi, In April 2014, ICANN updated the IANA IPv4 Recovered Address Space registry to reflect the return of 14 /24 prefixes (5,376 IPv4 addresses) by the RIPE NCC. The updated registry can be found at: https://www.iana.org/assignments/ipv4-recovered-address-space Kind regards, Leo Vegoda ICANN IANA

8 years, 11 months

Dell MD3000i controller urgent

by Romeo Benzoni

Hi all We are having a serious hardware issue with an old MD 3000i Power Vault Storage from Dell. We are very urgently looking for a MD3000i controller as Dell can't deliver one until tuesday. If someone has a working controller for this device please contact me offlist! Thanks a million! regards Romeo

8 years, 11 months

Re: [swinog] 84.253.0.0/19 (bluewin, old cybernet space) badly routed

by Jeroen Massar

On 2014-04-16 11:05 , Chris Welti wrote: > Hi Jeroen, > > I can't follow what you're saying. > As long as the announcements for the /18 and the /19s are valid, there > is no reason for broken connectivity. Of course there is. The /19 has precedence. Thus for sites that receive the /19 they will route over a much longer route than they should. > As far as I can see all anouncements are with origin by AS3303 as they > should be. > Also, connectivity tests via NLNOG ring prove that reachability is > excellent all over the world to e.g. 84.253.0.1: The RING does not cover all locations (yet, at least...) As shown here: https://stat.ripe.net/84.253.0.0%2F19#tabId=routing All the sites that do receive the /19, especially for instance the 40% of the networks that receive it over for instance Sao Paolo, Brazil, or Moscow IX and do not get it more local will take the long trip around. More specifics are evil and give weird routing in various locations. Apparently Swisscom is looking into it though, thus hopefull the more specific will be gone soon and the problem will be gone too. Greets, Jeroen

8 years, 11 months

Re: [swinog] 84.253.0.0/19 (bluewin, old cybernet space) badly routed

by Jeroen Massar

On 2014-04-16 17:34 , Chris Welti wrote: > Am 16/04/14 13:08, schrieb Jeroen Massar: >> On 2014-04-16 11:05 , Chris Welti wrote: >>> Hi Jeroen, >>> >>> I can't follow what you're saying. >>> As long as the announcements for the /18 and the /19s are valid, there >>> is no reason for broken connectivity. >> >> Of course there is. The /19 has precedence. Thus for sites that receive >> the /19 they will route over a much longer route than they should. >> > > I'm aware of that, however that doesn't mean the path is broken, it's > just different :) > You said the connectivity was broken, not that the chosen paths were not > optimal. Pedantic, but okay, it is indeed not "broken" but definitely not "optimal". But because it is not optimal it causes broken connectivity if the latency is 300ms more than it should be... > The reason for this is simple and happens all the time. You mean like Swisscom who internally aggregate all prefixes they receive? :) > Some ISPs will filter more-specific announcements > for policy reasons, some won't update their prefix-filter lists > regularly, someone makes a mistake and so on. > So if an ISP on the "optimal" path filters the /19 you will fall back to > the next best path for the /19. > that is not filtered. That doesn't mean something is wrong per se. And in this case the more specific /19 is the 'non-optimal' path, and the /18 is the correct one. Thus the ISPs that filter these more-specifics are 'winning' while the ones that accept the path are having issues as they are going over the non-optimal path. Note again, that the most-specific (unless config tweaked) wins. And the more-specific, is the issue here... [..] >> As shown here: >> >> https://stat.ripe.net/84.253.0.0%2F19#tabId=routing > > That doesn't show anything about end-to-end connectivity, just the AS > paths. Which clearly shows that various ISPs around the world are receiving the more-specific and thus the non-optimal path... >> All the sites that do receive the /19, especially for instance the 40% >> of the networks that receive it over for instance Sao Paolo, Brazil, or >> Moscow IX and do not get it more local will take the long trip around. > > Nobody forces them to accept the more specifics... ;) But they are being asked to do so; and if you are nice you do and you lose out. Which is affecting connectivity for various folks. > Some of the instances are getting the same path for /18 and /19 and some > have > longer AS path, but that doesn't necessarily mean the path is worse for > all of them. Not all indeed, but there are cases where it is worse. [..] >> More specifics are evil and give weird routing in various locations. > > Don't get me wrong, I'm a fan of getting rid of more-specifics so the > global routing table is not polluted. The "more specifics are evil" is not even because of routing pollution, it is all about the fact that some ISPs do filter and others do not and thus the routing will be indeterminate, one just have to have luck if the path goes well or not. Greets, Jeroen

8 years, 11 months

Re: [swinog] 84.253.0.0/19 (bluewin, old cybernet space) badly routed

by Jeroen Massar

On 2014-04-16 10:33 , Chris Welti wrote: > Hi Jeroen, > > There is a covering /18 also by AS3303 that has full visibility. > There is no need for the more specific /19 anymore. yep, noticed that too, but the /18 gets selected by everybody who still gets it, hence connectivity for that /18 is broken to/from most destinations. Greets, Jeroen (not using that prefix, noticed because a SixXS user had issues...)

8 years, 11 months

84.253.0.0/19 (bluewin, old cybernet space) badly routed

by Jeroen Massar

Ola, Anybody noticed that 84.253.0.0/19 is really badly routed: https://stat.ripe.net/84.253.0.0%2F19#tabId=routing Seems some locations do not get the prefix at all, and if they get it they are routed through Moscow and other strange places. That must give a rather bad experience for the folks in that space... Greets, Jeroen

8 years, 11 months

Re: [swinog] www.bluewin.ch not on DNS. Monitored from 2 locations. Anyone else?

by Matthias Hertzog

Hi Martin Might be, thanks. However, the entire bluewin.ch did not resolve. Shortly after www.swisscom.ch and www.ip-plus.net went down as well - however, by a different reason. It's working again since 3:30. see: http://www.network-status.ch Matthias > Martin Wismer <mailto:martin.wismer@bluewin.ch> > 6. April 2014 11:19 > Hello Matthias, > > On 06.04.14 02:48, Matthias Hertzog wrote: >> >> ping: cannot resolve www.bluewin.ch: Unknown host >> >> The authoritative nameserver do not answer: >> >> adnso1.bluewin.ch [195.186.196.180] >> adnso2.bluewin.ch [195.186.196.190] >> adnsz1.bluewin.ch [195.186.145.180] >> adnsz2.bluewin.ch [195.186.145.190] >> > this are the Auth. NS for bluewin.ch , but not for www.bluewin.ch. > If you ask: > zhbdzgss01.bluewin.ch. > zhbdzgss02.bluewin.ch. > zhhdzgss01.bluewin.ch. > zhhdzgss02.bluewin.ch. > > you will get answer's. > > Enjoy the Sunday, Greetings > Martin.Wismer. > >> Matthias >> >> >> >> >> _______________________________________________ >> swinog mailing list >> swinog(a)lists.swinog.ch >> http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog >

8 years, 11 months

SwiNOG-BE131 - Beer Event 131 @ Restaurant TANK (Niederdörfli) / ZH

by Steven Glogger

Dear SwiNOGers, Last time the meat was good. Another reason to come back! Details for the next event: ----------------------------------------------- Event: SwiNOG-BE131 - Beer Event 131 When? Monday, 14th April 2014 18:30 Where? Restaurant TANK (Niederdörfli) Stüssihofstatt 15, 8001 Zürich http://www.restaurant-tank.ch/ (GoogleMaps Link: http://goo.gl/maps/FRmVc) !! Please sign up if you're really coming - because the seats are limited! !! ----------------------------------------------- Registration: Start: Tuesday, 1st April 2014 - 00:00 Stop: Saturday, 11th October 2014 - 21:00 Reg-URL: http://swinog.be/ ----------------------------------------------- Since we have to make reservations, I need to know who's coming and who not. If you can't attend and you're registered please inform me ASAP (+41 79 277 92 35). greetings -steven

8 years, 11 months

www.bluewin.ch not on DNS. Monitored from 2 locations. Anyone else?

by Matthias Hertzog

Hi there! $ ping www.bluewin.ch ping: cannot resolve www.bluewin.ch: Unknown host The authoritative nameserver do not answer: adnso1.bluewin.ch [195.186.196.180] adnso2.bluewin.ch [195.186.196.190] adnsz1.bluewin.ch [195.186.145.180] adnsz2.bluewin.ch [195.186.145.190] Matthias

8 years, 11 months

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

swinog April 2014