swinog

swinog@lists.swinog.ch

1 participants
2934 discussions

Dell MD3000i controller urgent
by Romeo Benzoni 19 Apr '14

19 Apr '14

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

1 0

Re: [swinog] 84.253.0.0/19 (bluewin, old cybernet space) badly routed
by Jeroen Massar 16 Apr '14

16 Apr '14

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

2 2

Re: [swinog] 84.253.0.0/19 (bluewin, old cybernet space) badly routed
by Jeroen Massar 16 Apr '14

16 Apr '14

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

1 0

Re: [swinog] 84.253.0.0/19 (bluewin, old cybernet space) badly routed
by Jeroen Massar 16 Apr '14

16 Apr '14

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

1 0

84.253.0.0/19 (bluewin, old cybernet space) badly routed
by Jeroen Massar 16 Apr '14

16 Apr '14

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

1 0

Re: [swinog] www.bluewin.ch not on DNS. Monitored from 2 locations. Anyone else?
by Matthias Hertzog 06 Apr '14

06 Apr '14

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 >

1 0

SwiNOG-BE131 - Beer Event 131 @ Restaurant TANK (Niederdörfli) / ZH
by Steven Glogger 06 Apr '14

06 Apr '14

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

1 0

www.bluewin.ch not on DNS. Monitored from 2 locations. Anyone else?
by Matthias Hertzog 06 Apr '14

06 Apr '14

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

2 1

Re: [swinog] www.bluewin.ch not on DNS. Monitored from 2 locations. Anyone else?
by Matthias Hertzog 06 Apr '14

06 Apr '14

Not as far as i know. However, removing the bluewin.ch domain from DNS would be a very strange way of maintenance. Matthias > nicola(a)swissvoiptel.ch <mailto:nicola@swissvoiptel.ch> > 6. April 2014 03:06 > maintenance window? > > Il giorno 06/apr/2014, alle ore 02:48, Matthias Hertzog > <m.hertzog(a)mhs.ch <mailto:m.hertzog@mhs.ch>> ha scritto: > >> Hi there! >> >> $ ping www.bluewin.ch >> ping: cannot resolve www.bluewin.ch: Unknown host >> >> The authoritative nameserver do not answer: >> >> adnso1.bluewin.ch <http://adnso1.bluewin.ch> [195.186.196.180] >> adnso2.bluewin.ch <http://adnso2.bluewin.ch> [195.186.196.190] >> adnsz1.bluewin.ch <http://adnsz1.bluewin.ch> [195.186.145.180] >> adnsz2.bluewin.ch <http://adnsz2.bluewin.ch> [195.186.145.190] >> >> Matthias >> >> >> >> _______________________________________________ >> swinog mailing list >> swinog(a)lists.swinog.ch <mailto:swinog@lists.swinog.ch> >> http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog > Matthias Hertzog <mailto:m.hertzog@mhs.ch> > 6. April 2014 02:48 > 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 > >

1 0

Swisscom in trouble?
by Matthias Hertzog 06 Apr '14

06 Apr '14

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

swinog