Neuer Rekord: Ihr dürft euch auf 5 Stunden IP Routing II mit Clemens freuen. Und das Beste: Wenn ihr das ietf-Netz in seiner ganzen Pracht und BGP sehen wollt, habt ihr noch bis zum 01. April 2017 Zeit. Im Podcast erklärt, und in den Shownotes verlinkt, findet ihr die Tools, mit denen man sich in der großen weiten Welt der autonomen Systeme zurechtfindet. Wer Lust hat, kann dann gleich mal üben und herausfinden, welches Management-Netz in Chicago beim ietf-Meeting verwendet wird. Lösungsvorschläge per Twitter an @rfc_podcast oder per Mail an mail at annle dot de.
Und wie immer: Über Feedback in den Kommentaren freue ich mich sehr. Sagt mal kurz, wie ihr diesmal den Schnitt um die technischen Schwierigkeiten herum empfunden habt. Das wäre hilfreich.
Über iTunes Bewertungen freue ich mich natürlich auch.
Da sich die Shownotes gerade weigern angezeigt zu werden:
Tools im Web:
- “Sicht des Providers” bgp.he.net
- Looking glasses
- RIPE DB
| Feed | Enclosure |
|---|---|
| Podcast Feed: Request for Comments (Request for Comments (MPEG-4 AAC Audio)) | MPEG-4 AAC Audio |
| Podcast Feed: Request for Comments (Request for Comments (MP3 Audio)) | MP3 Audio |
| Podcast Feed: Request for Comments (Request for Comments (Opus Audio)) | Opus Audio |
| Podcast Feed: Request for Comments (Request for Comments (Ogg Vorbis Audio)) | Ogg Vorbis Audio |
[shownotes mode=”block”]
Hallo aus der Zukunft, da ich aus der Elektrotechnik komme, höre ich immer wieder nette Ausdrücke, die als englisches Fachwort bei euch auftauchen, auf deutsch aber auch bei uns. Beispiel bei 3Stunden 15: „Route Flap Dampening“ heißt bei uns einfach „Flattersperre“ und beschreibt eine Sperre für instabile Pegel. Grüße und weiter so!
Eine kleine Erweiterung der FF02::1 Tips:
Der “ping6 FF02::1%en0” Trick hat mir heute viele Stunden gespart. Leider haben sich alle meine Browser geweigert auf http://[fe80::xxxx:xxxx:xxxx:xxxx%en0] zuzugreifen.
Gerettet hat mich dann die Shell via: “ssh -L ‘8888:[fe80::xxxx:xxxx:xxxx:xxxx%en0]:80’ localhost” und dann hatte ich die Fritz GUI per http://localhost:8888 wieder.
Musste heute leider die gleiche Erfahrung machen, als ich einen Ubiquity Edge Router (Wirklich geile Geräte, danke für die “Nicht”empfehlung Clemens) konfigurieren wollte. Was mich tatsächlich wundert, weil ich genau das als Use-Case für die link-local Adressen im Kopf hatte
Das funktioniert leider nicht mit den Großen (Chrome*,Firefox,webkitbasierenden).
Auch die unbekannteren großen wie Konqueror/Falkon
könnens nicht :(
Netsurf kanns, jedoch kann dieser kein JS.
Die Konsolenbrowser könnens fast alle, aber ebenfalls kein JS.
Die Fritzbox reagiert direkt mit Rebind-Schutz, wenn man es mal mit ner fe80:: auf die Web-UI schafft :D
Wie das Gerücht vermutlich zu Stande kam:
Firefox hatte früher die Funktion und konnte ordentlich auflösen, jedoch war es anscheinend buggy und wurde daher lieber entfernt, statt gefixt.
Kleine Ergänzung.
War wieder mal seit langem an ner Windowskiste.
Internet Explorer und Edge könnens ordentlich!
Ehre wem Ehre gebürt.
Und das RFC 6874, wenn mehr Leute Browserhersteller nerven möchten.
Wirklich guter Podcast :) Clemens ist halt einfach der Boss ich finde es echt gut, dass du da noch so folgen kannst. Clemens erklärt das alles sehr gut aber es ist ja doch Thematisch immer sehr viel.
Weiter so :) bin noch am durchhören, da die Folgen ja doch immer recht lang sind :D ich finde übrigens nicht, dass du Clemens unbedingt ausbremsen musst. Dann geht es halt noch ne halbe Stunde länger das macht es dann auch nicht mehr :) solange ihr nicht vor Müdigkeit vom Stuhl fallt.
Super Podcast. Höre ich sehr gerne auf Zugfahrten. Auch wenn das Live testen mit he.net dank fehlendem WLAN im IC Flach fällt. Den Schnitt an den technisch problematischen Stellen finde ich so problemlos und vermutlich die beste Lösung.
Gibt es die von Clemens erwähnten Listen mit denen er bei IETF Meetings das Netz testet (Stichwort: Indonesian AirForce) irgendwo öffentlich?
Tolle Sendung! Großes Lob an beide! Toll, dass es den Podcast gibt.
VG
Alex
Moin,
nun muss ich ach mal schreiben. Super vielen Dank für diesen Podcast ich bin Ausbilder bei uns im Betrieb für Fachinformatiker. @Clemens In der Berufschule (Wohl gemerkt Cisco Akademy Mitglied) wird auch noch schon Class A,B,C und Subnetting IPV4 hoch und runter beigebracht. Ich habe versucht mit eurem Podcast mal gegenzuwirken und diesen in der Klasse ein wenig verteilt. Er ist auf begeisterung gestossen und hilft somit mal aktuelles Wissen weiterzugeben und dieses in eurer klasse Art und Weise bitte macht so weiter Ihr 2. vielen vielen Dank dafür.
und grüße aus dem hohen Norden
Ha! Das freut mich! Vielen lieben Dank!
Vielleicht infiltrieren wir Cisco irgendwann ja nachhaltig. Ich weiß zumindest aus sicherer Quelle, dass Cisco’s uns auch zuhören. ;)
Als Empfehlung meinerseits (für die Klasse): CRE Folge über IPv6. Da räumt Clemens auch IPv4 nochmal auf.
Aus eigenem Interesse kommt IPv6 aber in ‘request for comments’ nochmal im Detail!
Clemens begründet BCP38 damit, dass Datenpakete ohne gültigen Absender nicht beantwortet werden können, und daher keinen legitimen Zweck erfüllen. Meiner Ansicht nach ist dieses Argument genau falsch herum aufgezogen.
Es gibt durchaus legitime Anwendungen, in denen Datenpakete versendet werden, obwohl keine Antwort erwartet wird.
Zum Beispiel arbeiten viele Sensor-Netzwerk so, dass die Sensor-Knoten regelmäßig UDP-Pakete an einen Server senden, der diese einsammelt, aber nicht beantwortet. Wenn ein paar Messwerte dabei verloren gehen, werden diese meist nicht einmal nachgefordert, weil das den Aufwand nicht wert ist.
Ein anderes Beispiel sind Anzeigetafeln, die durch UDP-Pakete angesteuert werden, und das Ergebnis einfach nur anzeigen, ohne Rückmeldung an den Absender. So funktioniert etwa das Mate-Light in der c-base, oder auch das ehemalige Bahn-Anzeigefeld im CCCB (zumindest funktionierte das noch vor einigen Jahren so).
Das Argument sollte daher lauten:
Es ist egal, ob man Antwort-Pakete erwartet. So oder so spricht nichts dagegen, den korrekten Absender in seine Datenpakete zu schreiben. Entweder man erwartet eine Antwort, dann ist das zwingend notwendig. Oder man erwartet keine Antwort, dann spricht aber ebenfalls nichts gegen einen korrekten Absender.
Sehr gute Episode danke dafür.
Kann es sein das Clemens unterschlagen hat wie er die BGP Konfiguration im Swissotel für Comcast in Bezug auf das Subnetz welches nur im Fairmont verfügbar ist gemacht hat?
Meines Verständnis nach hat Clemens folgendes annonciert:
Swissotel
ATT: 2001:DB8::/32
Comcast: 2001:DB8::/32
Fairmont
ATT: 2001:DB8:ABCD::/48
Gut nachdem ich mir das jetzt so aufgeschrieben habe ist es mir auch klar das Comcast das /48 von ATT bevorzugt weil es einen längeren prefix hat.
Aber vielleicht hilfts wem anderen es besser zu verstehen.
sg
Harald
Das Schmakerl klappt prima. Ich habe es aber leider nicht geschafft mit der link-local Adresse das Webinterface von meinem frischen, unkonfigurierten Edgerouter zu erreichen. Stattdessen will der dusselige Browser danach googeln. Ich hab mal etwas rumgesucht aber nur alte Bugtrackereinträge und Co gefunden. Wie muss man das in welchen Browser eingeben damit es klappt?
Mit eckigen Klammern drum rum :)
Dasselbe Problem habe ich auch:
http://[fe80::f29f:c2ff:fe0d:f014%25en7]
http://[fe80::f29f:c2ff:fe0d:f014%en7]
http://[fe80::f29f:c2ff:fe0d:f014]
keiner der URLs funktioniert auf einem der drei großen Browser. nc zeigt mir aber das der Router auf dem Port lauscht und mit SSH funktioniert das Ganze auch wunderbar….
Sehr schöner Podcast, da ich immer 1,3 fache Geschwindigkeit höre auch nicht zu lang.
Insbesondere auch danke fürs tiefer gehen und abschweifen. Da bleibt doch immer noch extra was hängen.
Tom
Guter Podcast mit vielen Infos :-)
aber hallo!
Bei Position 2h10m redet ihr über “Route-Server” – da wäre es vllt. sinnvoll gewesen, einmal explizit die Schreibweise zu erwähnen, und darauf hinzuweisen, dass *nicht* “Root-Server” gemeint sind. Eventuell wäre an der Stelle auch die “Südstaaten-Aussprache” von “Route” auch hilfreich gewesen, damit man den Unterschied hört/verinnerlicht.
Euer Opus-File ist kaputt (lässt sich zwar abspielen, aber ist signifikant größer als das M4A-File und offensichtlich völlig übersteuert – die Höhen knistern und knacken ohne Ende). Das M4A-File tut dagegen ohne Probleme.
Hi,
Du meinst Ogg? Ja, das Encoding macht das File immer größer als die anderen. Ich hör mir das die Tage mal an und frage dann bei Auphonic nach.
Nee, ich meine schon das Opus-File (171MB groß). Normalerweise sollte das File nen Ticken kleiner als das AAC-File (116MB) sein, weil Opus eigentlich bei gleicher Qualität nen Ticken effizienter ist als AAC.
Das ist aber natürlich nur ein unwichtiges Randdetail, das kaputte Audio ist deutlich nerviger. Was auffällt: Das Opus-File ist nur Mono und mit 48kHz encoded, das AAC-/M4A-File dagegen in Stereo und mit 44,1kHz.
Weiteres interessantes Detail: Das Opus-File wurde mit ner Ziel-Bitrate von 64kBit/s encoded – das erklärt die im Vergleich zu AAC “zu große” Datei. Eigentlich sollten für zu AAC vergleichbare Audioqualität in diesem Fall max. 48kBit/s ausreichen.
Ok, wait. :D
Also Opus ist Mono und AAC stereo? Ich verstehe von audio Encoding zugegebenermaßen wenig, aber das kaputte Audio ist wahrscheinlich für auphonic interessant. Ich kann mich auch nicht erinnern, an den Einstellungen was geändert zu haben… Kannst Du mir dazu mal ne Mail schreiben? mail@annle.com
Hi,
erst mal danke für den Podcast, den ich allerdings noch richtig hören muss.
Dummerweise habe ich beim Zugang – und es ist mir peinlich das zu erwähnen, da es wohl direkt zum Android bashing führen wird ;-) – ein Problem.
Immerhin hat mein Handy nun ein Android 7 update bekommen, allerdings mit dem Problem dass ich den https geschützten feed nun nicht mehr erreichen kann.
Grund ist dass bei Android 7 (und nur da, mit Android 7.1.1 ist das wieder behoben) nur prime256 Kurven benutzt werden können, siehe hier:
https://community.letsencrypt.org/t/warning-android-7-0-clients-not-browsers-can-only-use-curve-prime256v1/23212
Der Feed benutzt wohl eine prime384 Kurve, so dass Android Nutzer mit Android 7 den feed im Catcher (ich hatte jetzt Podcast Addict und AntennaPod probiert) nicht verwenden können. Der Feed ist per Browser lesbar, aber das liegt daran dass die ihren eignen TLS Stack mitbringen.
Es wäre sicher vermessen darum zu bitten Deinen Webserver neu zu konfigurieren, aber vielleicht hilft die Botschaft anderen, die dasselbe Problem haben. Man kann sich das ja auch händisch runterladen.
Das Problem könnte auch auf client Seite behoben werden und ich werden den Podcast Addict Entwickler noch mal kontaktieren, ob er die von Dir verwendete Cipher-Suite einbindet.
Beste Grüße, Tom
Ha!!! Wow, danke! Das Thema kommt bei mir echt jedes mal an und ich habe kein Android Gerät und rate jedes mal…
Also nein, Webserver konfigurieren geht eher nicht, denn requestforcomments.de wird dort netterweise gehostet und administriert (in RFCE011 auch mal gewürdigt). Warum geht denn updaten auf Android 7.1.1 nicht? ;)
LG
Das mit dem Updaten auf 7.1.1 wäre wunderbar, gäbe es selbiges für mein Gerät 😁. Ist hier alles noch so einfach, aber runterladen geht ja problemlos. Muss halt Twitter im Auge behalten.
Der Entwickler von Podacst Addict hat probiert das Problem zu beheben, es aber auf die Schnelle nicht hinbekommen.
Dass mit den Android Updates hatte ich nicht auf dem Schirm 😏. Tut mir schon leid gerade, aber ich hab das kurz mit @danimo (dankenswerterweise Server-Admin) besprochen und agreed: Kein TLS downgrade.
Gib mir mal Dein Twitterhandle, dann gibt’s vielleicht ne Sondermention ;)
Ich vermute mal, weil der Hersteller das erforderliche Update (noch) nicht bereitgestellt hat. :(
Großen Dank dafür, daß Ihr nicht aus vermeintlichem Zeitdruck an der Oberfläche geblieben seid, sondern extra tief gebohrt habt. Genau dafür sind Podcasts da.
Die technischen Schwierigkeiten hättet ihr nach meinem Geschmack ruhig noch aggressiver rausschneiden dürfen. Es hat nicht sehr gestört, aber die Skype-Sounds oder “jetzt gab es wieder einen Glitch” Ansagen bringen auch keine Mehrinformation.
Aber schon klar, das ist ein großer Aufwand, alles zu polieren.
Shownotes werden sehnlich erwartet ;-)
Danke fürs Feedback.
Das sind keine Skype Sounds und Skype wird auch nicht verwendet. ;) Den Glitch rausschneiden geht halt nicht, weil das was gesagt wurde, eben mit Glitch gesagt wurde und nicht zu reparieren ist.
Ich bin selbst immer irritiert, wenn ich sowas in Podcasts höre und es kommentarlos ignoriert zu werden scheint. Deshalb hab ich mich nicht rausgeschnitten.
Mal schauen, ich behalte Deinen Hinweis mal im Hinterkopf. Danke.
Shownotes…hör RFCE011. Ist ein leidiges Thema.
Generell, eines vorne weg, super Sendung, schon wieder!
Ein kleines Detail auf das ich mich schon gefreut hatte, als ich in den Kapetelmarken Load Balancer gelesen hab, ist dann doch nicht gekommen. Und zwar wie funktioniert das Netzwert/Routing bei ADSL/LTE Hybid Anschlüssen wie wird da entschieden was über LTE gefunkt wird und was durchs Kupfer geht.
Wegen der technischen Schwierigkeiten hab ich persönlich kein Problem, ich hab da aber auch eine sehr hohe Toleranzgrenze und bin damit nicht so der richtige Vergleich.
Super fand ich auch das Schmankerl. Das wäre generell eine gute Idee einen Ausprobier oder Schmankerl Teil als ein Kapitel zu manchen. Weil ich höre Podcasts irgendwo unterwegs und ein Ausprobierteil wäre dann gut zum nochmal nachhören daheim am Rechner. Besonders bei langen Sendungen ist ansonsten das spätere Raussuchen aus 5h etwas mühsam.
meh, mein Provider (Telecolumbus) vergeben, seit sie v6 eingeführt haben, nur ein /64 – hab ihnen schon vor Jahren den Link zum entspr. RFC geschickt mit der Bitte um ein /56 und bin seitdem anscheinend auf der ignore-Liste :(
oh cool, gerade ein neues Draft empfohlen bekommen, gleich mal weiterleiten :)
https://www.sinog.si/docs/draft-IPv6pd-BCOP-v1.pdf