Hey all
A friend just told me that Cybernet told him there is a Switzerlandwide Internet Problem.
Does anybody know something?
Cheers
Michele
--------
Online Consulting AG, Michele Capobianco, System Administrator, Weststrasse 38, CH-9500 Wil
Phone +41 (0)71 913 31 31, Fax +41 (0)71 913 31 32
http://www.online.ch, michele.capobianco(a)online.ch<mailto:michele.capobianco@online.ch>
--------
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
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
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
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
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
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...)
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
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
>
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