swinog

swinog@lists.swinog.ch

1 participants
2939 discussions

Re: [swinog] nic.ch no NS
by Daniel Rechsteiner 07 May '14

07 May '14

> nic.ch is in the ch zone itself. So it's not a zone of its own. > > You will find it in whois so that people see that it's not available > anymore. Thanks. I suspected something like that, so I compared this to other ccTLDs and it's different there, e.g. for nic.fr and denic.de you get NS records: dig @ns1.denic.de denic.de ns dig @ns1.nic.fr nic.fr ns Why is this different for nic.ch? Daniel

2 2

nic.ch no NS
by Daniel Rechsteiner 07 May '14

07 May '14

Hi everyone, nic.ch seems to have dropped out from the .ch root servers: dig @130.59.1.80 nic.ch ns does not give me any nameservers. Also "whois nic.ch" does not show any name servers (although the domain still exists). Daniel

1 0

Swinog BE132 ZRH
by Roger Buchwalder 07 May '14

07 May '14

SwiNOG-BE132 - Beer Event 132 @ Outback Lodge / ZH Dear SwiNOGers, Lets have fun! Details for the next event: ----------------------------------------------- Event: SwiNOG-BE132 - Beer Event 132 When? Monday, 5th May 2014 18:30 Where? Outback Lodge Stadelhoferstrasse 18, 8001 Zürich http://www.outback-lodge.ch/outback-lodge-z%C3%BCrich.html (GoogleMaps Link:http://goo.gl/maps/fGTpM) !! Please sign up if you're really coming - because the seats are limited! !! ----------------------------------------------- Registration: Start: Friday, 2nd May 2014 - 19:25 Stop: Monday, 5th May 2014 - 17: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 rog

6 7

2x Cisco 2821 1GB RAM
by Ralph Krämer 01 May '14

01 May '14

Sali zäme, hab 2 identische Cisco 2821 (revision 53.51) with 1038336K/10240K bytes of memory. 2 Gigabit Ethernet interfaces 1 Virtual Private Network (VPN) Module DRAM configuration is 64 bits wide with parity enabled. 239K bytes of non-volatile configuration memory. 62592K bytes of ATA CompactFlash (Read/Write) übrig. gut geeignet um sich sein eigenes AS aufzubauen inclusive bgp full table abzugeben gegen Gebot hat jemand Interesse? msg me Gruss Ralph

1 0

New RIPE NCC contribution to the IANA IPv4 Recovered Address Space registry
by Leo Vegoda 23 Apr '14

23 Apr '14

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

1 0

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

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