[swinog] Re: IPv6, Gateway settings in datacenter/server

[Nico Schottelius via swinog]

Hey Urs,

at ungleich everything physical is RA based. Many networks even with two active
routers. Static assignments only for routers themselves. VMs have their
own IPAM and are inside static, but practically speaking mimicking
EUI64.

No need for DHCPv6 for our equipment, but if you want to do netboot, you
might want to consider it.

HTH & Best regards,

Nico

Mueller Urs SBB CFF FFS via swinog  writes:

> Hello
>
>
>
> Curious about the «best practice» you use for IPv6 gateways in server config 
> / datacenter.
>
>
>
> Votes for static gateway settings on servers? Or do you use IPv6 nd/ra? Or 
> perhaps DHCPv6?
>
>
>
> Regards, Urs
>
>
>
> SBB AG
>
> Cyber Security
>
> Cyber Defense Center
>
> Poststrasse 6, 3072 Ostermundigen
>
> Mobil +41 79 433 21 67
>
> urs.bf.muel...@sbb.ch / www.sbb.ch
>
> ___
> swinog mailing list -- swinog@lists.swinog.ch
> To unsubscribe send an email to swinog-le...@lists.swinog.ch


--
Sustainable and modern Infrastructures by ungleich.ch
___
swinog mailing list -- swinog@lists.swinog.ch
To unsubscribe send an email to swinog-le...@lists.swinog.ch

[swinog] Re: Contact: geoiplookup.net

[Nico Schottelius]

Benoit,

I have to say it's a frightening story to see. Essentially a third party
company (the SIP provider) locked themselves into another third party
provider (Maxmind/geoiplookup) and now it's your job to fix the latter's
mistake?

Besides being a tricky situation to cleanup for two third parties, it
shows how critically centralised the Internet has become.

If a single private party can render your services unusable, the
distribution of weights in the Internet is completely out of balance.

Best regards,

Nico


--
Sustainable and modern Infrastructures by ungleich.ch
___
swinog mailing list -- swinog@lists.swinog.ch
To unsubscribe send an email to swinog-le...@lists.swinog.ch

[swinog] Re: SwiNOG #38 - 01.09.2022 - Cancellation

[Nico Schottelius via swinog]

Ciao Simon,

very sorry to hear that, but wanted to reach out to you: for the
Hack4Glarus summer edition, we had a very similar feedback. "Our crowd"
is probably much more informed and overall more cautious than other
crowds.

I've the feeling it will take 1-2 more years in which Corona does not
dominate our daily life until most are "back to normal".

In this regard: looking forward to the next Swinog event.

Best regards,

Nico


Simon Ryf via swinog  writes:

> Dear SwiNOG Community,
>
>
>
> Sadly we have to cancel SwiNOG #38 / 01.09.2022.
>
> Despite the efforts in the last weeks we could neither find enough sponsors 
> nor enough content/speeches to organize a full day meeting
> at the quality you are used to. We were working hard to find solutions, but 
> today we had to make the difficult decision to cancel the event.
>
>
>
> We appologize for this sad announcement and will communicate a new date for 
> spring 2023 as soon as possible. In the meantime we are
> disucssing how we can improve the process internally and motivate more 
> sponsors and speakers for SwiNOG. Of course we would be very
> happy for input from the community as in the end: this is your event.
>
>
>
> Thank you for your understanding and thank you to all that tried their best 
> to make the event happen.
>
>
>
> Best Regards
>
> SwiNOG Core Team
>
> ___
> swinog mailing list -- swinog@lists.swinog.ch
> To unsubscribe send an email to swinog-le...@lists.swinog.ch


--
Sustainable and modern Infrastructures by ungleich.ch
___
swinog mailing list -- swinog@lists.swinog.ch
To unsubscribe send an email to swinog-le...@lists.swinog.ch

Re: [swinog] Problems accessing Sunrise networks?

[Nico Schottelius]

Hey Tobi,

we've got a peering with sunrise and do not see any problem on our link
nor on peering IP reachability from inside or outside our network.

Cheers,

Nico

Tobi  writes:

> Anyone seeing issues connecting to IPs belonging to sunrise? Started
> about 15min ago. I'm not the bgp expert but all AS numbers of Sunrise I
> found so far do not publish any bpg routes atm (ex
> https://bgp.he.net/AS5426)
>
>
> ___
> swinog mailing list
> swinog@lists.swinog.ch
> http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog


--
Modern, affordable, Swiss Virtual Machines. Visit www.datacenterlight.ch


___
swinog mailing list
swinog@lists.swinog.ch
http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog

Re: [swinog] Announcement of 'china government' routes 125.208.4[567].0/24 forbidden?

[Nico Schottelius]

Hey Benoit,

we get them both via Netstream and Sunrise:

[17:29] router1.place5:~# birdc show route 125.208.45.0/24
BIRD 2.0.7 ready.
Table master4:
125.208.45.0/24  unicast [sunrise_1_v4 12:29:14.872] * (100) [AS24151?]
via 193.192.225.72 on bond0.101
 unicast [router1_place6_ungleich_ch_v4 2020-07-05] (100) 
[AS24151?]
via 147.78.195.251 on bond0.8
 unicast [router2_place6_ungleich_ch_v4 2020-07-05] (100) 
[AS24151?]
via 147.78.195.252 on bond0.8
[17:29] router1.place5:~#

HTH,

Nico

Benoit Panizzon  writes:

> Hi List
>
> A customer complained, he cannot reach the website of chinese embassy in
> Switzerland.
>
> CH.CHINA-EMBASSY.ORG
>
> The DNS Servers are hosted under 125.208.4[567].0/24 and none of our
> peers do announce those routes to us.
>
> The all, according to the looking glasses, seem to get those routes
> announced from AS24406 CNNIC but do not redistribute them.
>
> Do others also see this issue?
>
> Mit freundlichen Grüssen
>
> -Benoît Panizzon-


--
Modern, affordable, Swiss Virtual Machines. Visit www.datacenterlight.ch


___
swinog mailing list
swinog@lists.swinog.ch
http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog

Re: [swinog] COVID-19 Monitoring Hackathon

[Nico Schottelius]

Hey Gregor,

thanks a lot for the pointer, I have just shared it in the covid-19
matrix channel [0]. If anyone is interested in discussing latest
development, feel free to join it [1].

So far we focused in the chat on exchange with international members to
see how the situation is everywhere in the world.

Sunny greetings from Glarus,

Nico


[0] https://matrix.to/#/#covid-19:ungleich.ch
[1] https://ungleich.ch/u/blog/work-from-home-work-remote-with-matrix/

Gregor Riepl  writes:

> Here's another project that is looking for volunteers:
> https://db.schoolofdata.ch/event/7
>
> In particular, some of you may be able (and willing!) to contribute to
> the "Daten zur Netzauslastung" topic?
> -> https://db.schoolofdata.ch/project/67
>
>
> ___
> swinog mailing list
> swinog@lists.swinog.ch
> http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog


--
Modern, affordable, Swiss Virtual Machines. Visit www.datacenterlight.ch


___
swinog mailing list
swinog@lists.swinog.ch
http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog

Re: [swinog] Telegram group

[Nico Schottelius]

Hello .*,

I was waiting for the chat system discussion to start,
it's good that we IT communities are so predictable :-).

My 4.99 rounded Rappen:

1) I fully understand Massimiliano's approach to "just do it" and not to
   think too much about the medium
2) IRC has the "disconnect/no history issue"
3) If I was to have an opinion on a chat system (hehe) I'd say we should
   go with matrix, as it is IRC with
   history+images+end-to-end-encryption,
   however I might not have an opinion here
4) I'm waiting for the person pointing out XMPP is the same principle
5) There is matterbridge [0] which we heavily use at ungleich, which can
   bridge almost anything to anything. In case we want to bridge irc to
   telegram to matrix to xmpp to slack and whatsapp, it's an easy thing
   to do.

Simon, you made my evening!

Best regards,

Nico

[0] https://github.com/42wim/matterbridge

p.s.: This email was written in emacs.
pps: https://xkcd.com/1782/

Simon Leinen  writes:

> Ralph Krämer writes:
>> why telegram and not signal or threema?
>
> Why not all! And fivema and sixma as well!!
>
> Seriously, what was wrong with irc.swinog.ch?
>
> Is IRC considered a boomer thing that millenials won't touch?
>
> Just curious - I'm happy to follow everyone everywhere, but not
> everybody does, and I worry about fragmenting the community.
>
> Cheers,


--
Modern, affordable, Swiss Virtual Machines. Visit www.datacenterlight.ch


___
swinog mailing list
swinog@lists.swinog.ch
http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog

Re: [swinog] Strange IPv6 scans from big networks

[Nico Schottelius]

Hey Klaus,

I am surprised you are surprised.

Why would one *not* want to scan your particular home network?

IPv6 is on the rise and scanning networks / IPs is a standard thing in
the IPv4 world. So it would be a surprise to me, why people would not
want to at least try to find devices in IPv6 based networks.

Best,

Nico


Klaus Ethgen  writes:

> Hi,
>
> Currently I see day long IPv6 scans from networks of Akamai
> (2a02:26f0:f3::/48), Google (2a00:1450:4000::/37), Apple
> (2a01:110::/31), Microsoft (2a01:b740::/29), Swisscom (2001:918::/32)
> and Init7 (2001:1620::/32) to my Network @HOME. They all try to
> enumerate hosts and ports in 2a02:168:4e82:0:* that does not and never
> have exists.
>
> The net is a fiber7 port.
>
> Anybody an idea what is going on here? On request I can provide more
> informations like pcaps.
>
> The scans are sourced from all over that mentioned networks above.
>
> While I have no scruples to block Apple, Microsoft, Akamai or other bad
> behaving networks, I do not want to block Swisscom or Init7 if not
> needed.
>
> Needless to say that I do not have any public service behind my fiber7
> port.
>
> Gruß
>Klaus


--
Modern, affordable, Swiss Virtual Machines. Visit www.datacenterlight.ch


___
swinog mailing list
swinog@lists.swinog.ch
http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog

[swinog] Decentralisation vs. centralisation [was: new project: DHCP Protect]

[Nico Schottelius]

Good evening,

Gregor Riepl  writes:

> [...] you should even put the project on a public collaboration platform to
> allow for easy pull/merge requests. ;)

Gregor, if I understand you correctly, you are implicitly saying "please
put your stuff on one of the big sites like github/gitlab/bitbucket".

I personally think that this is the wrong direction to move, as it
makes the Internet more dependent on a few entities. That makes it less
robust, as we have seen in the censorship case at github related to nationality.

Instead I recommend to decentralise and actually provide your code
from your own system.

I understand your point that it should be easy to contribute, but maybe
it is a more sustainable way to fire up your own git service and have
your code pulled in from your machine, preferable via IPv6?

Just my 5 Rappen,

Nico

--
Modern, affordable, Swiss Virtual Machines. Visit www.datacenterlight.ch


___
swinog mailing list
swinog@lists.swinog.ch
http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog

Re: [swinog] SBB partially reachable via IPv6

[Nico Schottelius]

Good late morning,

All fixed by now - I was notified that ipv6/https was unreachable due to
maintenance at SBB last night.

curl -6 -I -v https://sbb.ch as well as a real browser now work again.

Thanks everyone for the fast response!

Sunny greetings from Glarus,

Nico

p.s.: MTU on my test boxes was 9000 and 1500, both had the same issue yesterday.


Müller Urs (IT-OM-SDP-SDN)  writes:

> Hello everybody
>
> We are still having issues with the MTU detection.
> At the moment, we are translating on our Internet-Router and internal 
> Loadbalancers are unaware or unable to talk back to the webserver, if the MTU 
> is smaller than usual.
> This happens usually with Tunnelbrokers or some (self built) Firewall/Routers.
>
> Hope, we will bring IPv6 deeper into our network until Q2/2020 and fix that 
> nasty issue with that.
>
> If Nico could try to look into his MTU and perhaps share it's hardware specs?
>
> I am connecting with EdgeRouter Pro and through INIT7/Fiber7.
>
> :~$ curl -6 -l -v https://sbb.ch
> * Rebuilt URL to: https://sbb.ch/
> *   Trying 2a00:4bc0::::c296:f58e...
> * TCP_NODELAY set
> * Connected to sbb.ch (2a00:4bc0::::c296:f58e) port 443 (#0)
> * ALPN, offering h2
> * ALPN, offering http/1.1
> * successfully set certificate verify locations:
> *   CAfile: /etc/ssl/certs/ca-certificates.crt
>   CApath: /etc/ssl/certs
> * SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384
> * ALPN, server accepted to use http/1.1
> * Server certificate:
> *  subject: jurisdictionC=CH; jurisdictionST=Bern; 
> serialNumber=CHE-102.909.703; businessCategory=Private Organization; C=CH; 
> ST=Bern; L=Bern; O=Schweizerische Bundesbahnen SBB; OU=IT; CN=www.sbb.ch
> *  start date: Jul 25 14:52:45 2019 GMT
> *  expire date: Jul 25 14:52:45 2021 GMT
> *  subjectAltName: host "sbb.ch" matched cert's "sbb.ch"
> *  issuer: C=CH; O=SwissSign AG; CN=SwissSign EV Gold CA 2014 - G22
> *  SSL certificate verify ok.
>
> Regards, Urs
>
> Urs Müller
> Schweizerische Bundesbahnen SBB
> Senior Architekt
> IT Operations Management - Service Design
> Lindenhofstrasse 1 - Worblaufen, 3000 Bern 65
> urs.bf.muel...@sbb.ch / www.sbb.ch
>
>
>
>
> -Ursprüngliche Nachricht-
> Von: swinog-boun...@lists.swinog.ch  Im 
> Auftrag von Silvan M. Gebhardt
> Gesendet: Montag, 21. Oktober 2019 09:59
> An: Benoit Panizzon 
> Cc: swinog 
> Betreff: Re: [swinog] SBB partially reachable via IPv6
>
> SBB is a test case for proper MTU. Check your MTU ;)
>
>
> - Ursprüngliche Mail -
> Von: "Benoit Panizzon" 
> An: "swinog" 
> Gesendet: Montag, 21. Oktober 2019 07:40:15
> Betreff: Re: [swinog] SBB partially reachable via IPv6
>
> Works for me:
> $ telnet sbb.ch https
> Trying 2a00:4bc0::::c296:f58e...
> Connected to sbb.ch.
>
> $ openssl s_client -connect sbb.ch:https
> CONNECTED(0003)
> depth=2 C = CH, O = SwissSign AG, CN = SwissSign Gold CA - G2 verify return:1
> depth=1 C = CH, O = SwissSign AG, CN = SwissSign EV Gold CA 2014 - G22 verify 
> return:1
> depth=0 jurisdictionC = CH, jurisdictionST = Bern, serialNumber = 
> CHE-102.909.703, businessCategory = Private Organization, C = CH, ST = Bern, 
> L = Bern, O = Schweizerische Bundesbahnen SBB, OU = IT, CN = www.sbb.ch 
> verify return:1
> ---
> Certificate chain
>  0 s:jurisdictionC = CH, jurisdictionST = Bern, serialNumber = 
> CHE-102.909.703, businessCategory = Private Organization, C = CH, ST = Bern, 
> L = Bern, O = Schweizerische Bundesbahnen SBB, OU = IT, CN = www.sbb.ch
>i:C = CH, O = SwissSign AG, CN = SwissSign EV Gold CA 2014 - G22
>  1 s:C = CH, O = SwissSign AG, CN = SwissSign EV Gold CA 2014 - G22
>i:C = CH, O = SwissSign AG, CN = SwissSign Gold CA - G2
>
> Mit freundlichen Grüssen
>
> -Benoît Panizzon-


--
Modern, affordable, Swiss Virtual Machines. Visit www.datacenterlight.ch


___
swinog mailing list
swinog@lists.swinog.ch
http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog

[swinog] SBB partially reachable via IPv6

[Nico Schottelius]

Hello everyone,

if anyone from SBB reads the swinog ml: it's very cool that you added an
 record to sbb.ch. However it seems that only the HTTP, but not the
HTTPS port is open via IPv6. Logs are attached below.

Best regards from Glarus,

Nico


[20:31] diamond:~% curl -6 -I -v https://sbb.ch
*   Trying 2a00:4bc0::::c296:f58e:443...
* TCP_NODELAY set
* Connected to sbb.ch (2a00:4bc0::::c296:f58e) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
*   CAfile: /etc/ssl/certs/ca-certificates.crt
  CApath: none
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
^C

[20:33] diamond:~% curl -6 -I -v http://sbb.ch
*   Trying 2a00:4bc0::::c296:f58e:80...
* TCP_NODELAY set
* Connected to sbb.ch (2a00:4bc0::::c296:f58e) port 80 (#0)
> HEAD / HTTP/1.1
> Host: sbb.ch
> User-Agent: curl/7.66.0
> Accept: */*
>
* Mark bundle as not supporting multiuse
< HTTP/1.1 301 Moved Permanently
HTTP/1.1 301 Moved Permanently
< Date: Sun, 20 Oct 2019 18:32:39 GMT
Date: Sun, 20 Oct 2019 18:32:39 GMT
< Server: Apache
Server: Apache
< Location: https://sbb.ch/
Location: https://sbb.ch/
< Content-Type: text/html; charset=iso-8859-1
Content-Type: text/html; charset=iso-8859-1

<
* Connection #0 to host sbb.ch left intact


--
Modern, affordable, Swiss Virtual Machines. Visit www.datacenterlight.ch


___
swinog mailing list
swinog@lists.swinog.ch
http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog

Re: [swinog] SBB.ch / IPv6 MTU / fragmentation problem

[Nico Schottelius]

Hey Silvia,

thanks a lot for the insight! I did not expect this answer when asking
this morning.

I am currently doing my master thesis [0] about IPv6 in fully programmable
P4 switches (my hardware platform will be Barefoot Tofino in the end) -
I assume this might be rather interesting for SBB, as it potentially can
solve all problems [tm] in the network. Also I hear the 6.5 TBit/s
switches are not that crazy expensive anymore.

If you could get me in touch with the right people at SBB, this would
be very interesting to talk about their network.

Best,

Nico


[0] https://gitlab.ethz.ch/nicosc/master-thesis


Silvia Hagen  writes:

> Hi guys
>
> Here's some info from SBB (I was working with them and just spoke with them 
> today).
>
> . They are aware of the problem.
> . The problem only happens when someone uses smaller packet sizes (often when 
> using some tunnelling techniques).
> . Currently the webserver is in an IPv4 zone, the Internet router is a Cisco 
> box which does 64 Translation. The packets go through an F5 LB to reach the 
> webserver.
> . When the packets go out and the Cisco box asks for fragmention, it sends 
> the ICMP packet to the webserver. The F5 box has a bug, something with the 
> checksum goes wrong and the F5 discards the ICMP packet.
> . They have had a neverending incident with F5 and F5 does not seem to be 
> able to fix that. SBB has given up on this incident.
>
> The plan:
> . SBB is currently enabling IPv6 on the routing layer, plan to be 
> accomplished by summer 2019.
> . Next step on the plan is to enable v6 out to the datacenter, with priority 
> on the webserver zone. So with that the problems should go away.
>
> SBB was attending the last swinog event in Switzerland. They will also come 
> again and they offered to have a talk if desired. I can connect to the right 
> person if you are interested.
>
> Thanks, Silvia
>
>
> -Ursprüngliche Nachricht-
> Von: swinog-boun...@lists.swinog.ch [mailto:swinog-boun...@lists.swinog.ch] 
> Im Auftrag von Nico Schottelius
> Gesendet: Dienstag, 12. März 2019 10:33
> An: swinog@lists.swinog.ch
> Betreff: [swinog] SBB.ch / IPv6 MTU / fragmentation problem
>
>
> Good morning,
>
> is anyone from sbb.ch reading here?
>
> https://sbb.ch does not load on IPv6 for us.
> It seems that packets > 1420 bytes are dropped inside the SBB network,
>
> Local PMTU / fragmentation seems to work, my local outgoing MTU is 1420. MTR 
> below.
>
> Best,
>
> Nico
>
>
> [10:23] line:~% mtr -w -c1 -s 1500 sbb.ch
> Start: 2019-03-12T10:24:17+0100
> HOST: lineLoss%   Snt   Last   Avg  Best  Wrst StDev
>   1.|-- 2a0a:e5c1:111:111::420.0% 1   11.2  11.2  11.2  11.2   0.0
>   2.|-- ??? 100.0 10.0   0.0   0.0   0.0   0.0
>   3.|-- 2a0a:e5c0:2:12::70.0% 1   69.8  69.8  69.8  69.8   0.0
>   4.|-- 2a0a:e5c0:1:1::9 0.0% 1   74.3  74.3  74.3  74.3   0.0
>   5.|-- 2001:1620:20e6::10.0% 1   69.4  69.4  69.4  69.4   0.0
>   6.|-- r1zrh2.core.init7.net0.0% 1   69.1  69.1  69.1  69.1   0.0
>   7.|-- r1olt2.core.init7.net0.0% 1   58.0  58.0  58.0  58.0   0.0
>   8.|-- r1brn1.core.init7.net0.0% 1   62.8  62.8  62.8  62.8   0.0
>   9.|-- r2brn1.core.init7.net0.0% 1   65.4  65.4  65.4  65.4   0.0
>  10.|-- r1epe1.core.init7.net0.0% 1   75.2  75.2  75.2  75.2   0.0
>  11.|-- r1qls1.core.init7.net0.0% 1   78.4  78.4  78.4  78.4   0.0
>  12.|-- r1gva3.core.init7.net0.0% 1   81.0  81.0  81.0  81.0   0.0
>  13.|-- gw-sunrise.init7.net 0.0% 1   64.4  64.4  64.4  64.4   0.0
>  14.|-- 2001:1700:1:7:120::2 0.0% 1   84.4  84.4  84.4  84.4   0.0
>  15.|-- 2001:1700:4d00:2::2  0.0% 1   81.3  81.3  81.3  81.3   0.0
>  16.|-- 2a00:4bc0::ff00::1d  0.0% 1   67.0  67.0  67.0  67.0   0.0
>  17.|-- ??? 100.0 10.0   0.0   0.0   0.0   0.0
> [10:24] line:~% mtr -w -c1 -s 1400 sbb.ch
> Start: 2019-03-12T10:24:35+0100
> HOST: line   Loss%   Snt   Last   Avg  Best  Wrst 
> StDev
>   1.|-- 2a0a:e5c1:111:111::42   0.0% 13.2   3.2   3.2   3.2   
> 0.0
>   2.|-- 2a0a:e5c1:100::10.0% 1   69.0  69.0  69.0  69.0   
> 0.0
>   3.|-- 2a0a:e5c0:2:12::7   0.0% 1   74.7  74.7  74.7  74.7   
> 0.0
>   4.|-- 2a0a:e5c0:1:1::90.0% 1   69.9  69.9  69.9  69.9   
> 0.0
>   5.|-- 2001:1620:20e6::1   0.0% 1   60.5  60.5  60.5  60.5   
> 0.0
>   6.|-- r1zrh2.core.init7.net   0.0% 1   75.3  75.3  75.3  75.3   
> 0.0
>   7.|-- r1olt2.core.init7.net   0.0% 1   70.7  70.7  70.7  70.7   
> 0.0
>   8.|-- r1b

[swinog] SBB.ch / IPv6 MTU / fragmentation problem

[Nico Schottelius]

Good morning,

is anyone from sbb.ch reading here?

https://sbb.ch does not load on IPv6 for us.
It seems that packets > 1420 bytes are dropped inside the SBB network,

Local PMTU / fragmentation seems to work, my local outgoing
MTU is 1420. MTR below.

Best,

Nico


[10:23] line:~% mtr -w -c1 -s 1500 sbb.ch
Start: 2019-03-12T10:24:17+0100
HOST: lineLoss%   Snt   Last   Avg  Best  Wrst StDev
  1.|-- 2a0a:e5c1:111:111::420.0% 1   11.2  11.2  11.2  11.2   0.0
  2.|-- ??? 100.0 10.0   0.0   0.0   0.0   0.0
  3.|-- 2a0a:e5c0:2:12::70.0% 1   69.8  69.8  69.8  69.8   0.0
  4.|-- 2a0a:e5c0:1:1::9 0.0% 1   74.3  74.3  74.3  74.3   0.0
  5.|-- 2001:1620:20e6::10.0% 1   69.4  69.4  69.4  69.4   0.0
  6.|-- r1zrh2.core.init7.net0.0% 1   69.1  69.1  69.1  69.1   0.0
  7.|-- r1olt2.core.init7.net0.0% 1   58.0  58.0  58.0  58.0   0.0
  8.|-- r1brn1.core.init7.net0.0% 1   62.8  62.8  62.8  62.8   0.0
  9.|-- r2brn1.core.init7.net0.0% 1   65.4  65.4  65.4  65.4   0.0
 10.|-- r1epe1.core.init7.net0.0% 1   75.2  75.2  75.2  75.2   0.0
 11.|-- r1qls1.core.init7.net0.0% 1   78.4  78.4  78.4  78.4   0.0
 12.|-- r1gva3.core.init7.net0.0% 1   81.0  81.0  81.0  81.0   0.0
 13.|-- gw-sunrise.init7.net 0.0% 1   64.4  64.4  64.4  64.4   0.0
 14.|-- 2001:1700:1:7:120::2 0.0% 1   84.4  84.4  84.4  84.4   0.0
 15.|-- 2001:1700:4d00:2::2  0.0% 1   81.3  81.3  81.3  81.3   0.0
 16.|-- 2a00:4bc0::ff00::1d  0.0% 1   67.0  67.0  67.0  67.0   0.0
 17.|-- ??? 100.0 10.0   0.0   0.0   0.0   0.0
[10:24] line:~% mtr -w -c1 -s 1400 sbb.ch
Start: 2019-03-12T10:24:35+0100
HOST: line   Loss%   Snt   Last   Avg  Best  Wrst StDev
  1.|-- 2a0a:e5c1:111:111::42   0.0% 13.2   3.2   3.2   3.2   
0.0
  2.|-- 2a0a:e5c1:100::10.0% 1   69.0  69.0  69.0  69.0   
0.0
  3.|-- 2a0a:e5c0:2:12::7   0.0% 1   74.7  74.7  74.7  74.7   
0.0
  4.|-- 2a0a:e5c0:1:1::90.0% 1   69.9  69.9  69.9  69.9   
0.0
  5.|-- 2001:1620:20e6::1   0.0% 1   60.5  60.5  60.5  60.5   
0.0
  6.|-- r1zrh2.core.init7.net   0.0% 1   75.3  75.3  75.3  75.3   
0.0
  7.|-- r1olt2.core.init7.net   0.0% 1   70.7  70.7  70.7  70.7   
0.0
  8.|-- r1brn1.core.init7.net   0.0% 1   69.1  69.1  69.1  69.1   
0.0
  9.|-- r2brn1.core.init7.net   0.0% 1   54.6  54.6  54.6  54.6   
0.0
 10.|-- r1epe1.core.init7.net   0.0% 1   75.9  75.9  75.9  75.9   
0.0
 11.|-- r1qls1.core.init7.net   0.0% 1   78.8  78.8  78.8  78.8   
0.0
 12.|-- r1gva3.core.init7.net   0.0% 1   79.8  79.8  79.8  79.8   
0.0
 13.|-- gw-sunrise.init7.net0.0% 1   69.9  69.9  69.9  69.9   
0.0
 14.|-- 2001:1700:1:7:120::20.0% 1   77.5  77.5  77.5  77.5   
0.0
 15.|-- 2001:1700:4d00:2::2 0.0% 1   59.3  59.3  59.3  59.3   
0.0
 16.|-- 2a00:4bc0::ff00::1d 0.0% 1   70.1  70.1  70.1  70.1   
0.0
 17.|-- ???100.0 10.0   0.0   0.0   0.0   
0.0
 18.|-- ???100.0 10.0   0.0   0.0   0.0   
0.0
 19.|-- ???100.0 10.0   0.0   0.0   0.0   
0.0
 20.|-- ???100.0 10.0   0.0   0.0   0.0   
0.0
 21.|-- ???100.0 10.0   0.0   0.0   0.0   
0.0
 22.|-- ???100.0 10.0   0.0   0.0   0.0   
0.0
 23.|-- ???100.0 10.0   0.0   0.0   0.0   
0.0
 24.|-- ???100.0 10.0   0.0   0.0   0.0   
0.0
 25.|-- 2a00:4bc0::::c296:f58e  0.0% 1   58.3  58.3  58.3  58.3   
0.0
[10:24] line:~%

[10:25] line:~% mtr -w -c1 -s 1420 sbb.ch
Start: 2019-03-12T10:25:44+0100
HOST: line   Loss%   Snt   Last   Avg  Best  Wrst StDev
  1.|-- 2a0a:e5c1:111:111::42   0.0% 1   16.3  16.3  16.3  16.3   
0.0
  2.|-- 2a0a:e5c1:100::10.0% 1   77.0  77.0  77.0  77.0   
0.0
  3.|-- 2a0a:e5c0:2:12::7   0.0% 1   67.0  67.0  67.0  67.0   
0.0
  4.|-- 2a0a:e5c0:1:1::90.0% 1   66.7  66.7  66.7  66.7   
0.0
  5.|-- 2001:1620:20e6::1   0.0% 1   78.8  78.8  78.8  78.8   
0.0
  6.|-- r1zrh2.core.init7.net   0.0% 1   64.5  64.5  64.5  64.5   
0.0
  7.|-- r1olt2.core.init7.net   0.0% 1   68.3  68.3  68.3  68.3   
0.0
  8.|-- r1brn1.core.init7.net   0.0% 1   74.9  74.9  74.9  74.9   
0.0
  9.|-- r2brn1.core.init7.net   0.0% 1   73.6  73.6  73.6  73.6   
0.0
 10.|-- r1epe1.core.init7.net   0.0% 1   62.2  62.2  62.2  62.2   
0.0
 11.|-- r1qls1.core.init7.net   0.0% 1   74.3  74.3  74.3  74.3  

Re: [swinog] Do ISP still offer outgoing smtp relaying services to business customers with own smtp server?

[Nico Schottelius]

Hey Benoit,

in short: yes, we do, for customers with high technial experience
(i.e. we can trust that they are by default doing the right thing [tm].)

Best,

Nico


Benoit Panizzon  writes:

> Dear List
>
> We sometimes get requests from business customers, with own mailserver,
> which directly receives email via smtp, for an outgoing smtp-relay.
>
> I then argue with:
>
> * Their server is absolutely capable of sending emails directly
> * They have better control of the sending process.
> * They can look for problem them self in their logs.
> * Anti-Spam thresholds aimed at end users, not companies.
> * They are not affected if another customer is spaming and therefore the
>   IP of the relay blacklisted.
>
> But still, I then often get an "BUT... you are our ISP, isn't it your
> duty to offer such a relay service? Other ISP do this!"
>
> rly? Do other ISP still offer smtp relaying services to business
> customers with own email infrastructure?
>
> Mit freundlichen Grüssen
>
> -Benoît Panizzon-


--
Your Swiss, Open Source and IPv6 Virtual Machine. Now on www.datacenterlight.ch.


___
swinog mailing list
swinog@lists.swinog.ch
http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog

Re: [swinog] mirror.switch.ch to be closed down

[Nico Schottelius]

Wow, I am surprised! Thanks for pointing out, Fredy.

We are currently running a Devuan & OpenNebula mirror on
https://mirror.datacenterlight.ch/ and are already planning to add
support for Ubuntu, Debian and CentOS in the near future, as we want
to have

As we operate this mirror anyway, we would be open to mirror other
sources, too and take care of maintenance as well as disk space.

We would only have to talk to our provider about the bandwidth, which
happens to be Init7.

Best,

Nico


Fredy Kuenzler  writes:

> SWITCH announced that they plan to close down mirror.switch.ch. See
> announcement http://mirror.switch.ch/
>
> I personally think this is very sad. In the name of the community I
> would like to thank SWITCH for their support over all these years.
>
> However I would like to start the discussion how we can keep
> mirror.switch.ch alive as a community effort.
>
> Can the decision makers at SWITCH please explain the preconditions?
> Funding for new hardware? Throw in some bandwidth? Colocation? Server
> management?
>
> Please discuss.


--
Your Swiss, Open Source and IPv6 Virtual Machine. Now on www.datacenterlight.ch.


___
swinog mailing list
swinog@lists.swinog.ch
http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog

[swinog] Battery powered wifi link (20km, multihop)

[Nico Schottelius]

Hey Swinog,

does anyone have experiences with long distance (~20km) wifi powered
by battery?

With have the situation that we basically want to connect Schwanden to
Linthal by wifi for at least 12 hours.

The idea is to go via several hops, some of them not having any power
resource.

So my questions to the list are:

- What kind of equipment have you used for similar cases or can you recommend?
- Are there any battery recommendations?
- Other creative ideas on how to get a direct link with >= 100 Mbit/s
  connectivity?

Best,

Nico




--
Your Swiss, Open Source and IPv6 Virtual Machine. Now on www.datacenterlight.ch.


___
swinog mailing list
swinog@lists.swinog.ch
http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog

Re: [swinog] are you also seeing more ssh attacks ?

[Nico Schottelius]

Good morning,

Manuel Schweizer  writes:

> Hey Tobi
>
> Not seeing what you are seeing, but I can really recommend Fail2Ban if
> you are not using it already.

while the idea of fail2ban is good, I would actually recommend sshguard
instead of fail2ban.
If you are not using a recent version of fail2ban, it does
not handle IPv6 at all and thus does not throttle IPv6 based attacks.

For that reason we switched to sshguard, a smaller and leaner dynamic
blocker that fully supports IPv6 and has a variety of backends,
including nftables.

Best,

Nico


--
Your Swiss, Open Source and IPv6 Virtual Machine. Now on www.datacenterlight.ch.


___
swinog mailing list
swinog@lists.swinog.ch
http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog

[swinog] IPv6 Run Event

[Nico Schottelius]

Good morning Swinog,

we are planning our first IPv6 focused event this year.

The main topic of the event is, how well the IPv6 deployment of
Switzerland has come and to discuss the action points to reach
100% IPv6 coverage.

Thus I would like to invite you to join and...

... showcase how and where you enabled sites with IPv6
... show difficulties and solutions for IPv6 only networks
... meet players from industry to discuss your needs with others
... get a tasty Adler Bräu beer

We are at an early planning stage, but wanted to begin to spread the
word already (i.e. date to be defined, Website & CfP coming in the next
weeks).

The format will likely be a 1-2 day event, with talks during the day,
discussion in the late afternoon and a networking event in the evening.

To decide on the exact format, I would like to ask you to give me a
heads up, if you are interested in this event and if you are interested
in showcasing something.

A simple "+1" or "+1 +talk_about_x" suffices.

Depending on the feedback, we will plan for either a 1 or 2 day event.

Thanks a lot and have a great snowy Sunday,

Nico

--
Modern, affordable, Swiss Virtual Machines. Visit www.datacenterlight.ch


___
swinog mailing list
swinog@lists.swinog.ch
http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog

Re: [swinog] google.ch high latency

[Nico Schottelius]

Hey Adrian,

various E-Mails are delayed from our site today and also latency to
google is a bit higher than usual:

[18:05] feder:~% ssh mirror.datacenterlight.ch " ping -c3 www.google.ch; ping 
-c3 euler.ethz.ch"
PING www.google.ch (216.58.205.99) 56(84) bytes of data.
64 bytes from mil04s26-in-f3.1e100.net (216.58.205.99): icmp_seq=1 ttl=54 
time=23.1 ms
64 bytes from mil04s26-in-f3.1e100.net (216.58.205.99): icmp_seq=2 ttl=54 
time=23.3 ms
64 bytes from mil04s26-in-f3.1e100.net (216.58.205.99): icmp_seq=3 ttl=54 
time=23.2 ms

--- www.google.ch ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2002ms
rtt min/avg/max/mdev = 23.159/23.245/23.308/0.139 ms
PING euler.ethz.ch (129.132.71.59) 56(84) bytes of data.
64 bytes from hpc-euler-lb.ethz.ch (129.132.71.59): icmp_seq=1 ttl=50 time=7.28 
ms
64 bytes from hpc-euler-lb.ethz.ch (129.132.71.59): icmp_seq=2 ttl=50 time=7.84 
ms
64 bytes from hpc-euler-lb.ethz.ch (129.132.71.59): icmp_seq=3 ttl=50 time=7.36 
ms

--- euler.ethz.ch ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2003ms
rtt min/avg/max/mdev = 7.281/7.498/7.846/0.248 ms
[18:05] feder:~%

Best,

Nico


Kägi Adrian  writes:

> Hi all
> We’re face high latency of google.ch (and other European tlds) from our 
> AS203732
> $ ping www.google.ch 95ms
> $ ping www.google.fr 80ms
> $ ping www.google.de 90ms
>
>
> -> % traceroute www.google.ch
> traceroute to www.google.ch (216.58.205.131), 30 hops max, 60 byte packets
> 1  192.168.11.1 (192.168.11.1)  0.116 ms  0.151 ms  0.124 ms
> 2  dvbnre01-po8-2g.dvbern.ch (185.125.164.2)  0.456 ms  0.568 ms  0.889 ms
> 3  i64beb-011-ten0-2-0-2x136.bb.ip-plus.net (193.247.169.41)  1.622 ms  1.312 
> ms  1.354 ms
> 4  i64beb-010-ten2-5.bb.ip-plus.net (138.187.157.36)  1.179 ms 
> i64beb-000-ten2-5.bb.ip-plus.net (138.187.157.22)  1.057 ms 
> i64beb-010-ten2-5.bb.ip-plus.net (138.187.157.36)  0.877 ms
> 5  i79zhb-005-ten0-5-0-4-7.bb.ip-plus.net (138.187.130.46)  3.332 ms 
> i62bsw-025-ten0-1-0-5.bb.ip-plus.net (138.187.130.44)  5.882 ms 
> i79zhb-005-ten0-5-0-4-7.bb.ip-plus.net (138.187.130.46)  3.312 ms
> 6  i00mil-005-ae1.bb.ip-plus.net (138.187.129.27)  7.605 ms 
> i00dcx-005-hun2-0-0.bb.ip-plus.net (138.187.129.83)  6.340 ms 
> i00mil-005-ae1.bb.ip-plus.net (138.187.129.27)  6.922 ms
> 7  de-cix.fra.google.com (80.81.192.108)  8.945 ms google.mix-it.net 
> (217.29.66.96)  45.949 ms de-cix.fra.google.com (80.81.192.108)  8.862 ms
> 8  108.170.251.208 (108.170.251.208)  8.786 ms 108.170.251.144 
> (108.170.251.144)  16.055 ms 108.170.252.19 (108.170.252.19)  8.986 ms
> 9  108.170.229.168 (108.170.229.168)  9.417 ms 209.85.242.79 (209.85.242.79)  
> 9.364 ms 216.239.42.13 (216.239.42.13)  56.092 ms
> 10  mil04s27-in-f131.1e100.net (216.58.205.131)  58.975 ms  59.013 ms 
> 209.85.254.61 (209.85.254.61)  14.983 ms
>
> Providers: Swisscom, UPC, Cyberlink
>
> Does anyone facing same issues?
>
> Cheers Adrian
>
> Adrian Kägi
> Senior System Engineer
>
> DV Bern AG | Nussbaumstrasse 21 | Postfach 106 | CH-3000 Bern 22
> T +41 31 378 24 24 | D +41 31 378 24 60
> www.dvbern.ch
>
> ___
> swinog mailing list
> swinog@lists.swinog.ch
> http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog


--
Modern, affordable, Swiss Virtual Machines. Visit www.datacenterlight.ch


___
swinog mailing list
swinog@lists.swinog.ch
http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog

Re: [swinog] URGENT: Looking for 2-4x Arista transceiver

[Nico Schottelius]

Thanks everyone for your help - we found a solution!

It's great to see how many awesome people can help in emergency cases!

Best,

Nico /* underslept */

Nico Schottelius <nico-swino...@schottelius.org> writes:

> Hello,
>
> we are in the urgent need of at least 2 (better 4) RJ45 1 Gbit/s transceiver 
> that
> are compatible with Arista switches.
>
> If anyone has some lying around, please contact me off list.
>
> Best,
>
> Nico


--
Werde Teil des modernen Arbeitens im Glarnerland auf www.digitalglarus.ch!
Lese Neuigkeiten auf Twitter: www.twitter.com/DigitalGlarus
Diskutiere mit auf Facebook:  www.facebook.com/digitalglarus


___
swinog mailing list
swinog@lists.swinog.ch
http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog

[swinog] URGENT: Looking for 2-4x Arista transceiver

[Nico Schottelius]

Hello,

we are in the urgent need of at least 2 (better 4) RJ45 1 Gbit/s transceiver 
that
are compatible with Arista switches.

If anyone has some lying around, please contact me off list.

Best,

Nico


--
Werde Teil des modernen Arbeitens im Glarnerland auf www.digitalglarus.ch!
Lese Neuigkeiten auf Twitter: www.twitter.com/DigitalGlarus
Diskutiere mit auf Facebook:  www.facebook.com/digitalglarus


___
swinog mailing list
swinog@lists.swinog.ch
http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog

[swinog] Internetanbindung Glarus (Schwanden)

[Nico Schottelius]

Salut zusammen,

ich suche jemanden, der uns zu einem vernünftigen Preis eine
100/100 oder 1G/1G Leitung (inklusive IP) nach Schwanden (Kanton Glarus)
legen kann.

Hat jemand eine Empfehlung oder ein Angebot in der Richtung?

Viele Grüsse,

Nico


--
Werde Teil des modernen Arbeitens im Glarnerland auf www.digitalglarus.ch!
Lese Neuigkeiten auf Twitter: www.twitter.com/DigitalGlarus
Diskutiere mit auf Facebook:  www.facebook.com/digitalglarus


___
swinog mailing list
swinog@lists.swinog.ch
http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog

[swinog] TR-069 & Security / Swisscom Router

[Nico Schottelius]

Hello Swinog,

we've recently audited a small network and found that the customer
configured devices were relatively secure configured. However the
Swisscom Router/WiFi device (Zylex P-870HN-53b) seems to have the old
uPNP exploit with a firmware that is not being updated anymore (upnp was
disabled though - so this is hopefully not a big issue).

However, when scanning the router from outside, the port 7547 is openly
reachable from the internet, which turns out to be TR 069 [0].

My question to the list is, if anyone can comment on the security of
TR-069? And if it is a potential or real security problem to have the
port open world wide?

We have never used TR-069 it so far, but my assumption would be that
this port should only be reachable from a Swisscom admin network,
however it is open world wide. As far as I can see the communication on
port 7547 is plain http with http auth, which doesn't look very safe to
me.

Does anyone here use TR-069 and if so, what is your the default policy
for accessing the port?

Thanks a lot for your help and greetings from the last snow!

Nico


[0] https://en.wikipedia.org/wiki/TR-069

-- 
Werde Teil des modernen Arbeitens im Glarnerland auf www.digitalglarus.ch!
Lese Neuigkeiten auf Twitter: www.twitter.com/DigitalGlarus
Diskutiere mit auf Facebook:  www.facebook.com/digitalglarus


___
swinog mailing list
swinog@lists.swinog.ch
http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog

Re: [swinog] Reliable + Good quality VoIP Provider (US, Switzerland, Korea)

[Nico Schottelius]

Thanks a lot everyone for the (offlist) feedback. 

We also got feedback from Telephoenix (the world is small) and 
will test other codecs.

For those who didn't hear back from me - I am about to shrink my queue,
you will hear from me tomorrow.

Cheers,

Nico

Stanislav Sinyagin [Mon, Jan 26, 2015 at 09:20:32AM +0100]:
 Nico,
 
 you may (and may not) get some improvement in voice quality if you
 select a network-optimized codec, such as speex, iLBC, SILK, and so
 on.
 
 Most VoIP providers don't offer these codecs, because of their
 complexity and required CPU power.
 
 So, your best choice would be to install one or several VPS'es around
 the globe, set up some VoIP server software, like FreeSWITCH or
 Asterisk, and control the full communication between them and your
 clients. Then these VPS'es would hand over the traffic to some local
 PSTN providers.
 
 So, this needs some engineering, customization, tests = $$$ :)
 
 cheers,
 stan
 
 
 On Sun, Jan 25, 2015 at 4:14 PM, Nico Schottelius
 nico-swino...@schottelius.org wrote:
  Good morning Swinog,
 
  we are looking for a new VoIP hoster that actually offers decent voice
  quality, preferable even over hspa(+) based networks, working in the US,
  Switzerland and South Korea.
 
  Working := can receive / make phone calls well enough for daily use (I
  am aware that VoIP should work everywhere, but in practice the quality
  either in Switzerland or abroad or both is too poor to talk for long).
 
  So far we are using telephoenix.com (reseller of $provider), but have
  huge problems in terms of voice quality (even via wifi via dsl / cable).
 
  I was wondering, if anyone can recommend a provider and also has tested
  reachability in East Asia and North America?
 
  Cheers,
 
  Nico
 
  --
  New PGP key: 659B 0D91 E86E 7E24 FD15  69D0 C729 21A1 293F 2D24
 
 
  ___
  swinog mailing list
  swinog@lists.swinog.ch
  http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog
 
 
 
 -- 
 Stanislav Sinyagin
 Senior Consultant, CCIE #5478
 ssinya...@k-open.com
 +41 79 407 0224
 
 
 ___
 swinog mailing list
 swinog@lists.swinog.ch
 http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog

-- 
New PGP key: 659B 0D91 E86E 7E24 FD15  69D0 C729 21A1 293F 2D24


___
swinog mailing list
swinog@lists.swinog.ch
http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog

[swinog] Reliable + Good quality VoIP Provider (US, Switzerland, Korea)

[Nico Schottelius]

Good morning Swinog,

we are looking for a new VoIP hoster that actually offers decent voice
quality, preferable even over hspa(+) based networks, working in the US,
Switzerland and South Korea.

Working := can receive / make phone calls well enough for daily use (I
am aware that VoIP should work everywhere, but in practice the quality
either in Switzerland or abroad or both is too poor to talk for long).

So far we are using telephoenix.com (reseller of $provider), but have
huge problems in terms of voice quality (even via wifi via dsl / cable).

I was wondering, if anyone can recommend a provider and also has tested
reachability in East Asia and North America?

Cheers,

Nico

-- 
New PGP key: 659B 0D91 E86E 7E24 FD15  69D0 C729 21A1 293F 2D24


___
swinog mailing list
swinog@lists.swinog.ch
http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog

Re: [swinog] .ch registrars : goodbye nic.ch, but where to go then ?

[Nico Schottelius]

Great Idea Oli! 

Thanks a lot for transferring it into something legible!


Oli Schacher [Fri, Nov 28, 2014 at 09:03:01AM +0100]:
 I've copied the registrar list from this thread into a spreadsheet - if
 you are willing to put in the feature set from the registrars you know
 hopefully we can get a decent overview.
 
 https://docs.google.com/spreadsheets/d/1UWK6ijLCiLXSIuTT4sS_h0zCqPMCjjhry0byQprysts/edit?usp=sharing
 
 Feel free to edit/add features. If gets abused I'll set to read-only or
 remove it.
 
 Best regards
 Oli
 
 -- 
 message transmitted on 100% recycled electrons
 
 
 ___
 swinog mailing list
 swinog@lists.swinog.ch
 http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog

-- 
New PGP key: 659B 0D91 E86E 7E24 FD15  69D0 C729 21A1 293F 2D24


___
swinog mailing list
swinog@lists.swinog.ch
http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog

Re: [swinog] Looking for used 19 rack

[Nico Schottelius]

Hey .*,

Many, many, many thanks everybody for the offers, you are
all great!

We will collect a rack this/next week from someone in Glattbrugg 
(not sure if it is ok to say who it is, so just naming the location),
but the reactions on my mail were just awesome!

It is great to read all of you again and I look forward meeting
you in person soon again!

Cheers,

Nico

p.s.: I will pay for a round at the next meeting I attend! 
If you want to join me for a drink before, my location 
is nearby 서울 for some time.

-- 
New PGP key: 659B 0D91 E86E 7E24 FD15  69D0 C729 21A1 293F 2D24


___
swinog mailing list
swinog@lists.swinog.ch
http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog

[swinog] Looking for used 19 rack

[Nico Schottelius]

Hey .*,

do you by chance have a 19 rack you don't need anymore
(maybe even nearby Zurich)?

A customer of mine needs something, because of some regulations
to put in two (!) units from Swisscom. And it should be a full height
(not like 21 units) rack.

Just wondering - please reply offlist, if you have something
you want to get rid of.

Cheers,

Nico

-- 
New PGP key: 659B 0D91 E86E 7E24 FD15  69D0 C729 21A1 293F 2D24


___
swinog mailing list
swinog@lists.swinog.ch
http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog