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>
--------
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Howdy.
We're conducting a statistical overview of peering sessions for a research paper. The paper we produce will be input into OECD guidelines on national communications regulatory frameworks, so we'd very much like it to accurately reflect the diversity of peering agreements out there in the world. At the same time, if we ask for too much data, people will be reluctant to answer our questions, so we've tried to keep the data we're collecting as simple as possible.
Specifically, for each other Autonomous System you peer with, we'd be interested in knowing the following five pieces of information:
Your ASN
Your peer's ASN
Whether a written and signed peering agreement exists (the alternative being that it's less formal, like a "handshake agreement")
Whether the terms are roughly symmetric (the alternative being that it describes an agreement with different terms for each of the two parties, like one paying the other, or one receiving more or fewer than full customer routes)
If a jurisdiction of governing law is defined
The easiest way for us to take the information is as a tab-text file or spreadsheet, consisting of rows as follows:
Your ASN: Integer
Peer ASN: Integer
Written agreement: Boolean
Symmetric: Boolean
Governing Law: ISO 3166 two-digit country-code, or empty
For instance:
42 <tab> 715 <tab> false <tab> true <tab> us <cr>
42 <tab> 3856 <tab> true <tab> true <tab> us <cr>
The ASNs are just there so we can avoid double-counting a single pair of peers, when we hear from both of them. As soon as we've collated the data, we'll strip the ASNs to protect privacy, and only the final aggregate statistics will be published in any case. We've currently got about 10,000 sessions documented, and would love to have as many more as possible. We'd like to finish collecting data by the end of the second week of April, two weeks from now.
If you're able to help us, please email me the data in whatever form you can. If you need a non-disclosure, we're happy to sign one.
Thanks for considering this,
-Bill Woodcock
Research Director
Packet Clearing House
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (Darwin)
iEYEARECAAYFAk2UqpYACgkQGvQy4xTRsBGvowCgzXIkFOEfqj9BCgGkqhiv8AgF
xGwAoLl69OQ8giYmnT6S7zwLBBu7XeYZ
=D38f
-----END PGP SIGNATURE-----
Hi there
mhs.ch ist looking to extend the tech team. Job description is available (in german) at: http://www.mhs.ch/unternehmen/Jobs/Jobs_techniker.shtml
Best wishes,
Matthias
_________________________________________
mhs @ internet AG
Zürcherstrasse 204, CH - 9014 St. Gallen
Phone +41 71 274 93 93, Fax +41 71 274 93 94
http://www.mhs.ch
_________________________________________
Vor einiger Zeit ging ja eine Mail herum, dass die globalen Nameserver
fuer .in-addr.arpa aendern werden, dass dies aber keine Auswirkungen
auf den taeglichen Betrieb haben wuerde. Nun, es hatte...
Wer auf seinen Nameservern bislang den folgenden Code drin hatte, um
reverse Lookups zu beschleunigen, kann seit der Umstellung keine
reverse Lookups mehr ausfuehren:
zone "." {
type slave;
file "slave/root.slave";
masters {
192.5.5.241; // F.ROOT-SERVERS.NET.
};
notify no;
};
zone "arpa" {
type slave;
file "slave/arpa.slave";
masters {
192.5.5.241; // F.ROOT-SERVERS.NET.
};
notify no;
};
zone "in-addr.arpa" {
type slave;
file "slave/in-addr.arpa.slave";
masters {
192.5.5.241; // F.ROOT-SERVERS.NET.
};
notify no;
};
Dieser Bereich ist standardmaessig auf aktuellen FreeBSD Servern
auskommentiert, es wird in einem Kommentar aber empfohlen, ihn fuer
Nameservern mit hohem Verkehrsaufkommen zu aktivieren. Nach der
Umstellung der in-addr.arpa Zonen funktioniert das Slaving _NICHT_
mehr, auch nicht von den neuen Servern. Resultat: Reverse-Lookup
funktioniert nicht mehr.
Wer Mailserver betreibt, die auf einem gueltigen Reverse-Lookup
bestehen fuer eine einkommende Verbindung, wird ohne Anpassung seiner
Nameserver nun beginnen (je mehr gecachte Zonen expiren desto mehr)
einkommende Verbindungen abzuweisen, und dieses Abweisen wird zumindest
bei unserm Setup mit "Relaying temporarily denied. Cannot resolve PTR
record for x.x.x.x" begruendet.
Eventuell sind die vor kurzem beschriebenen Probleme, dass bluewin
seine eigenen Adressen nicht akzeptiert (mit "relay denied") auf das
gleiche Problem zurueckzufuehren...
LG,
Markus
Hi
One of our customers got a .255 IPv4 address assigned by sunrise. I know
that this can be a valid host address with a netmask of /23 or greater,
but the strange thing is, that he can't reach any of our Windows Server
2003 hosts with this IP. Windows Server 2008 Servers in the same subnet
are no problem...
Does anybody know of such a problem? Mr. Google couldn't give me any
satisfactory results... :-)
Cheers,
Mike
--
Mike Kellenberger | Escapenet GmbH
www.escapenet.ch
+41 52 235 0700/04
Skype mikek70atwork
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
Hi,
kann mal bitte einer von bluewin sich die Mailinfrastruktur ansehen.
Alle Mails an Bluewin, selbst die an postmaster(a)bluewin.ch kommen als
Bounce zurück, das relaying denied währe. (Alle über mxbw.bluewin.ch.)
Gruß
Klaus Ethgen
- --
Klaus Ethgen http://www.ethgen.ch/
pub 2048R/D1A4EDE5 2000-02-26 Klaus Ethgen <Klaus(a)Ethgen.de>
Fingerprint: D7 67 71 C4 99 A6 D4 FE EA 40 30 57 3C 88 26 2B
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
iQEVAwUBTZNq65+OKpjRpO3lAQrg1Af/Y3X7HLYunSVM5f8dycgX/4dQFL0CVukm
m5DN6/eolJlTRq/CUhbuAz9cVXhl4n3A/G8ESmjCYXDvi5LPzozcyDNWLaDWHqDg
8iXd9PHdop01M2yKyKthpE27VamM+7lD5efQkcA/q/Mr9iHqZCkgbR5sEXBEKdWa
tq3vAcZEHoLFhjrr++1XmoQoZJFw8gz7rjWs+uDAhwTGwI8QsoUD+FjHFXy4ClvJ
fuTDFwHK/Lo6GMwmY+XDWBr5/sOsjrKvYlesBZLlnIWKnEi6uy4I2dR1LmKna9nB
Ztfnk2zTAPpynPrCTuP/F4HUkY2Eryv+cTe4F335zs11XEupWHqZog==
=xNjA
-----END PGP SIGNATURE-----
IN-ADDR.ARPA NAMESERVER CHANGE COMPLETE
This is a courtesy notification of the completion of a change to
the nameserver set for the IN-ADDR.ARPA zone.
There is no expected impact on the functional operation of the DNS
due to this change.
There are no actions required by DNS server operators or end users.
For more information about this work, please see
<http://in-addr-transition.icann.org/>.
DETAIL
The IN-ADDR.ARPA zone is used to provide reverse mapping (number
to name) for IPv4. The servers which now provide authoritative DNS
service for the IN-ADDR.ARPA zone are as follows:
A.IN-ADDR-SERVERS.ARPA (operated by ARIN)
B.IN-ADDR-SERVERS.ARPA (operated by ICANN)
C.IN-ADDR-SERVERS.ARPA (operated by AfriNIC)
D.IN-ADDR-SERVERS.ARPA (operated by LACNIC)
E.IN-ADDR-SERVERS.ARPA (operated by APNIC)
F.IN-ADDR-SERVERS.ARPA (operated by RIPE NCC)
All root servers dropped the IN-ADDR.ARPA zone according to the
schedule posted earlier, and all root servers now respond to queries
under IN-ADDR.ARPA with an appropriate referral.
Note that as part of this transition, the IN-ADDR.ARPA zone is now
signed with DNSSEC and a complete chain of trust now exists from
the root zone to the IN-ADDR.ARPA zone. IP6.ARPA, the corresponnding
zone for IPv6 reverse mapping, was signed similarly some time ago.
Regards,
Joe Abley
Director DNS Operations
ICANN
hi everybody
the registration website for SwiNOG #22 is open!
https://register.swinog.ch
The agenda is not yet ready, but we might be able to publish some sneak-preview/draft the next week.
If you're a speaker please wait until we've confirmed / published the agenda.
Confirmed speakers WILL receive a VOUCHER so please do NOT register before receiving the voucher.
If you register, you will have to pay but you will get a voucher for the next SwiNOG event.
Greetings
-steven
SwiNOG Core-Team
The 22nd meeting of the Swiss Network Operators Group (SwiNOG) will be held in Berne on top of the Gurten on March 9th 2011.
Important Dates for SwiNOG#22
---------------------------------------------------
17.03.2011 Announcement of Meeting
17.03.2011 Call for Papers
24.03.2011 Registration opens
18.04.2011 Call for Papers closing
25.04.2011 Final publication of agenda
01.05.2011 Registration closes
05.05.2011 Deadline for all slides
09.05.2011 Meeting day
Topics for Presentations/Talks
---------------------------------------------------
The number and length of presentations per session is not fixed, although due to time constraints we would prefer the length of the presentations to be between 10 to 45 minutes.
However proposals for longer/shorter presentations or presentations whose subject falls outside of the topics below are also welcome; please do not hesitate to submit them.
Here is a non-exhaustive list of typical SwiNOG meeting topics:
- Security - DDOS Mitigation - AntiSpam
- IPv6
- Open Source tools
- International view of the internet (incidents, outages, measurements)
- Routing
- Server applications (DNS, Web, etc.)
- Legal issues (BÜPF, etc.)
- Telecommunication polictics (Net Neutrality, Incumbent monopoly, etc.)
Language of Slides and Talks
---------------------------------------------------
The whole day will be held in English, therefore we kindly ask you to produce your presentation in English.
Submission Guidelines
---------------------------------------------------
All submissions must have a strong technical bias and must not be solely promotional for your employer.
Please remember that your presentations should be suitable for a target audience of technicians from varied backgrounds, working for companies whose sizes may vary considerably.
To submit a proposal for a presentation, we request that you provide the following information to <swinog-core(a)swinog.ch>:
* the name of the presenter (and if applicable your affiliation)
* a working email address
* the name and number of the topic which will contain the presentation
* the title of the presentation
* its expected length (in minutes)
* a short abstract of the presentation (so we know what it is about)
We also welcome suggestions for specific presentations which you feel would be valuable to the SwiNOG community.
Please be aware that your presentation will be published on the SwiNOG website after the event. We can publish modified slides if requested - it might be that some confidential data will be presented by you which are not intended for publication on the internet.
Greetings,
Pascal Gloor
SwiNOG Core Team
General Information (SwiNOG Community)
---------------------------------------------------
The Swiss Network Operators Group (SwiNOG) is an informal group of people who are concerned with engineering and operation of the Swiss Internet.
SwiNOG exists to enhance the quality of Internet services available in Switzerland. It does this by fostering the free exchange of technical ideas and information between different companies and organisations.
SwiNOG is a community for professionals who are operating, designing or researching the Internet. It provides a technical forum where those working on, with and for the Internet can come together to solve problems with every aspect of their (net)work.
The meeting is designed to provide an opportunity for the exchange of information among network operators, engineers, researchers and other professionals close to the network community.
More information about SwiNOG can be found at http://www.swinog.ch/
Information about the meeting will be published at http://www.swinog.ch/meetings/swinog22/
General Information (SwiNOG Organisation)
---------------------------------------------------
The SwiNOG Organisation Association is a non-profit association under article 60 and further of the swiss civil law. It manages the SwiNOG community ressources (domain, web, mailing-lists, etc..) and organises SwiNOG meetings.
Contact:
SwiNOG Organisation
8000 Zurich
Switzerland