Linux-Networking Digest #417, Volume #11 Sat, 5 Jun 99 10:13:31 EDT
Contents:
Re: 3com-ing a netwerk ([EMAIL PROTECTED])
Re: Linux and ADSL with GTE (Mike Bartman)
Re: Help: 3com 3c509B etherlink III: Driver loads but ???? (Green Screen)
Re: Logs with RedHat 6.0 (Joe Halpin)
Re: Linux and ADSL with GTE (Joe Halpin)
Samba Server
Re: 3C509 NIC and RH 5.2 ("Jeffrey S. Kline")
Re: Linux: ICMP Redirect, IP Source Routing unterdruecken (Detlef Bosau)
Re: Linux: ICMP Redirect, IP Source Routing unterdruecken (Detlef Bosau)
Re: Linux: ICMP Redirect, IP Source Routing unterdruecken (Detlef Bosau)
Re: $SOCKS_N Environment (Jim Lowry)
Re: Linux: ICMP Redirect, IP Source Routing unterdruecken (Detlef Bosau)
Re: Linux: ICMP Redirect, IP Source Routing unterdruecken (Detlef Bosau)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED]
Subject: Re: 3com-ing a netwerk
Date: Sat, 05 Jun 1999 11:20:16 GMT
You certainly would hope so, but I would imagine that in the practical
world, some network equipment works slightly better than others with
certain hardware/oses. A microsoft network works different and has
different loads than a standard tcp/ip network.
In article <7j92fj$5v1$[EMAIL PROTECTED]>,
"Jim Scheffler" <[EMAIL PROTECTED]> wrote:
> A hub, switch, router and other network hardware are not OS specific
>
> <[EMAIL PROTECTED]> wrote in message
news:7j8iuj$cab$[EMAIL PROTECTED]...
> > How much do small switches generally cost? Are "they" making
switches
> > with linux?
> >
> > One thing I don't understand about hubs, is exactly what do they do
> > other than server as junction to connect the wires. As I think I
> > understand it, packets are seen by every system connected to a hub,
but
> > switches route packets only to their destination (possibly to
another
> > network), reducing the traffic that could be sniffed from a given
> > machine, which would be good, since I would like to have my firewall
box
> > connected to the internet 24-7.
>
>
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: [EMAIL PROTECTED] (Mike Bartman)
Subject: Re: Linux and ADSL with GTE
Date: Sat, 05 Jun 1999 13:11:35 GMT
Reply-To: [EMAIL PROTECTED]
On 4 Jun 1999 19:53:32 GMT, [EMAIL PROTECTED] (John Strange)
wrote:
>Tell GTE it's going to be a microsoft box,
>get the drop installed, hookup your linux box.
>Call your isp and ask for what you need to know about
>their server (DNS server/news/mail server ip numbers, dhcp, chap/pap,...)
>
>Now, if GTE is also your ISP, get the information and tell
>everyone in the office to forget what your server OS is.
Exactly. The only reason GTE won't support a non-Windows platform is
that they *can't*. They don't know anything else. They've written up
standard questions and problem solving steps for Windows, and if
someone calls with problems on anything else, they won't be able to do
a thing...it's truely "not supported"...but that doesn't mean it won't
work just fine. :^)
All it means is that your friends, or you, will have to provide the
support. Just don't mention the OS when you call for raw data, such
as IP addresses, server addresses, etc. Every OS will need that data
and they can provide it just fine...unless they've got some sort of
stupid Windows-only, automatic, we-send-you-a-floppy-and-you-run-it,
configuration script. If they've got that, just get hold of a windows
machine, run their program, then wander around the dialog boxes
looking it up for yourself.
All they're going to see is data packets, and no matter what platform
generates them they will look the same...or they won't be compliant
with the standards. Microsoft is working on this...as specified in
the Halloween Papers...but they aren't there yet!
-- Mike "nor will they be if we can stop then, right?" Bartman --
================================================================
To reply via e-mail, remove the 'foolie.' from the address.
I'm getting sick of all the spam...
================================================================
------------------------------
From: Green Screen <[EMAIL PROTECTED]>
Subject: Re: Help: 3com 3c509B etherlink III: Driver loads but ????
Date: 5 Jun 1999 12:26:27 GMT
well assuming the driver is working... you need to setup your interface
and route. take a look at /etc/rc.d/rc.inet1
it should be something to this effect:
/sbin/ifconfig eth0 <your IP> broadcast your.C.class.255 netmask 255.255.255.0
/sbin/route add -net your.C.class.0 netmask 255.255.255.0 eth0
and if you have a gateway, do this next, if no gateway, leave it out:
/sbin/route add default gw <gateway IP> netmask 0.0.0.0 metric 1
hope this helps
Lint^^
Vic <[EMAIL PROTECTED]> wrote:
: I have a dual-boot computer with win3.11 and linux.
: During bootup with slackware 3.3 (linux kernel 2.0.30), the driver correctly
: finds the ISA NIC. But the machine is not reachable and cannot ping other
: machines on the network, although it can ping it's own assigned IP address
: but nothing else. The computer works well under win3.11.
: Any ideas?
: Thanks in advance.....
: Alvin
------------------------------
From: Joe Halpin <[EMAIL PROTECTED]>
Subject: Re: Logs with RedHat 6.0
Date: Sat, 05 Jun 1999 07:28:06 -0500
Lim Chee Onn wrote:
> Joe Halpin wrote:
> Add the following lines to /etc/conf.modules
Thanks very much. Was this info online someplace?
Joe
--
I didn't want to be here, where the future is in store
but my name is on the mailbox, and my key fits in the door
- Bob Bennett (the musician, not the lawyer)
------------------------------
From: Joe Halpin <[EMAIL PROTECTED]>
Subject: Re: Linux and ADSL with GTE
Date: Sat, 05 Jun 1999 07:35:49 -0500
John Strange wrote:
>
> Tell GTE it's going to be a microsoft box,
> get the drop installed, hookup your linux box.
> Call your isp and ask for what you need to know about
> their server (DNS server/news/mail server ip numbers, dhcp, chap/pap,...)
That's probably how I'll need to do it.
> Now, if GTE is also your ISP, get the information and tell
> everyone in the office to forget what your server OS is.
No, luckily they have a small ISP, run by one guy, who seems to care
(and the people in the office don't know what a server is).
Thanks.
Joe
--
I didn't want to be here, where the future is in store
but my name is on the mailbox, and my key fits in the door
- Bob Bennett (the musician, not the lawyer)
------------------------------
From: <[EMAIL PROTECTED]>
Subject: Samba Server
Date: 5 Jun 1999 13:31:14 GMT
What must I set in smb.conf in order to access my Samba server as root? I
want to be able to see the whole directory tree on the server from my
Windows client.
================== Posted via SearchLinux ==================
http://www.searchlinux.com
------------------------------
From: "Jeffrey S. Kline" <[EMAIL PROTECTED]>
Crossposted-To: linux.redhat.install
Subject: Re: 3C509 NIC and RH 5.2
Date: Sat, 5 Jun 1999 08:40:08 -0500
If you ran the utility for configuring the card and turned off the
autoconfigure option or set it to some really unusual address and/or IRQ,
then yes, it won't find it. Another possibility is you have another card
using the same address or IRQ as the NIC and hence why you should go back to
step one and turn on the autoconfigure feature on the card. It works and
works well but some folks are afraid of PNP and think it's the same. It's
not...
Jeff
BTRiggs wrote in message <7j8tqm$f8t$[EMAIL PROTECTED]>...
>I am running a 486 DX P120 with a 3Comm 3c509B NIC. When I set up RH 5.0 it
>works fine, if I upgrade to 5.2 or 6.0 it can no longer find the card.
>During the install or upgrade process I try to load the 3C509 drivers and
it
>comes back with "Unable to locate device". During the boot script it reads:
>eth0: delaying initialization
>eth0...unknown interface
>I was running on a split partition, Windoz and Linux. Now it is free from
of
>any hazards. But I still can't get it to see the card in anything other
than
>5.0. I also reset it so it is no longer using DHCP. Any assistance is
>greatly appreciated.
>Thanks,
>mail to : [EMAIL PROTECTED]
>Brian Riggs
>
>
>
------------------------------
Date: 05 Jun 1999 14:14:00 +0200
From: [EMAIL PROTECTED] (Detlef Bosau)
Crossposted-To: de.comm.internet.routing
Subject: Re: Linux: ICMP Redirect, IP Source Routing unterdruecken
[EMAIL PROTECTED] meinte am 04.06.99
zum Thema "Re: Linux: ICMP Redirect, IP Source Routing unterdruecken":
> In comp.os.linux.networking Detlef Bosau <[EMAIL PROTECTED]>
> > wrote: Maschinen, die nicht routen, benoetigen keinen solchen
> > Daemon.
> Stimmt, die bekommen die Informationen per ICMP redirects.
Ich schreibe jetzt nicht, was ich jetzt denke .....
Detlef
--
Detlef Bosau [EMAIL PROTECTED]
Bienroder Weg 79 Tel.: +49 531 303383
D2: +49 172 6819937
38106 Braunschweig, Germany Fax: +49 531 303364
>>>> PGP Public Key als Empfangsbestaetigung <<<<
## CrossPoint v3.1 R ##
------------------------------
Date: 05 Jun 1999 13:07:00 +0200
From: [EMAIL PROTECTED] (Detlef Bosau)
Crossposted-To: de.comm.internet.routing
Subject: Re: Linux: ICMP Redirect, IP Source Routing unterdruecken
[EMAIL PROTECTED] meinte am 04.06.99
zum Thema "Re: Linux: ICMP Redirect, IP Source Routing unterdruecken":
> In comp.os.linux.networking Detlef Bosau <[EMAIL PROTECTED]>
> > wrote: Aber Leute, die meinten, in stark frequentierten NT-Netzen
> > die goldene Regel von maximal 30 Rechnern pro IP-Segment
> > ueberschreiten zu muessen, haben meistens sehr schnell gelernt,
> > was eine Heavysidesche Sprungfunktion ist ;-)
>
> Hmm... kann ich nicht nachvollziehen. Die paar Netbios Broadcasts
> machen den Kohl nicht Fett.
>
Nun ja, das sind immer so religioese Fragen. Ich habe schon panikartige
Einsaetze erlebt, da hat ein Kollege etwas mit IPX SAP gesagt, und schon
wurden in einem Gebaeude 50 Rechner angefasst, dass die keine Druckerfrei-
gaben mehr gemacht haben. Im Notfallchaosschnellverfahren.
Natuerlich war das Quatsch.
Natuerlich wurde es trotzdem gemacht.
Natuerlich wurde da nicht nachgedacht.
Denkt jemand nach, bevor er was tut? Kaum.
Aber zum NetBEUI. Das Problem ist nicht nur die Last. Das Problem ist
einfach die Stabilitaet. Die Regeln, nach denen Masterbrowser werden,
sind halbwegs undurchsichtig. Wann diese seltsamen Masterbrowser
zur Namensaufloesung verwendet werden, wann ein WINS Server und
wann ein DNS mit Ketchup und Mayo habe ich diverse Microsofties
gefragt, die Antworten reichten von abenteuerlich bis grausig.
Aber zwei Dinge sind mir klar geworden: Erstens haben die
sich _alle_ widersprochen und zweitens weiss das selbst Microsoft
vermutlich nicht richtig.
Daraus ziehe ich eine ganz simple Lehre: Wenn sich nur 30 PC's sehen,
koennen sich auch nur 30 PC's Aerger machen. Und wenn in einem
VLAN ein NT Hubbelbubbel Server steht (wie hiess doch gleich
Obelix' Lieblingsspeise aus der Neuen Welt? Kommt ja heute abend
wieder. Ist viel wichtiger als Netzwerke) und alles durcheinander-
bringt, dann bringt der nur _die_ 30 Rechner in seinem Netz durcheinander.
Ein ehemaliger Kunde sucht nun schon seit Monaten regelmaessig alle
3 Wochen den Grund, warum sich Leute aus einem IP-Segment nicht anmelden
koennen, jedesmal ist das ein anderes, jedesmal sagen die Netzies,
es laufe alles einwandfrei, die NT-Servies sagen, die Server liefen
einwandfrei, die Pissie-Supporter sagen, die Pissies liefen alle
einwandfrei.
Na, ein alter Matheprof. von mir wuerde jetzt sagen:
Beweis, dass das alles Quatsch ist, erfolgt durch Widerspruch.
Waere das alles richtig, dann koennten sich die Kunden ja wohl anmelden.
Und das ist ja ganz offensichtlich nicht der Fall.
(Mein Matheprof. war nicht ganz so konziliant. Er sagte, das in
dem Zusammenhang, dass wir unser Fach nicht koennten, beweise man durch
Widerspruch. Wuerden wir es koennen, wuerde ja die naechste Klausur
recht gut ausfallen. Der Matheprof. hatte sehr viel Ahnung von
Mathematik...)
Ich wuerde normalerweise, wenn das vom IP Design her sinnvoll gehen
wuerde, am liebsten jeden NT-Rechner in ein isoliertes IP-Segment stellen.
Dann kann er wenigstens niemand anderem Schaden zufuegen.
Aber solange das zu teuer ist, werde ich die NT-Katastrophenareas
so klein wie moeglich halten.
Ich habe es auch hier einfach satt, durch irgendwelche schwarzen NT
Server unterm Tisch, die keiner kennt, auf einmal in halbe Gebaeude
ramponierte SAP-Listen propagiert zu bekommen, und schon kann sich
die Haelfte der Netware User nicht mehr anmelden, oder dass mir
jedesmal ein halbes Unternehmen steht, weil irgend ein xDC
mal wieder auf die NetBIOS Anmeldebroadcasts nicht hoert und in
wilder Panik hampelt dann ein Knaeuel von Menschen, Galliern,
Roemern, Netzwerkern, Pissie-Fachleuten, Servies etc. zum Kunden,
der EDV-Leiter wird wahnsinnig, alles schreit und jammert und
irgendwann koennen die Kunden wie durch Zauberhand arbeiten
und niemand weiss, wieso, und bis abens um 10 ist Krisensitzung
beim EDV-Chef.
Das habe ich alles bis zum Abwinken durch.
Also mache ich meine IP-Broadcast-Domain _klein_, und siehe da:
Es geht.
Und bei allen anderen Konstrukten habe ich teilweise im Pissie-Support
gesessen und angewiesen von ahnungsvollen und wissensschwangeren
Kollegen von Microsoft und Netzkollen habe ich mir ein halbes
Dutzend Paar Schuhsohlen und Absaetze durchgelaufen.
Wie gesagt.
Es gibt Methoden, mit denen es geht. Andere muss ich nicht mehr ausprobieren.
Detlef
--
Detlef Bosau [EMAIL PROTECTED]
Bienroder Weg 79 Tel.: +49 531 303383
D2: +49 172 6819937
38106 Braunschweig, Germany Fax: +49 531 303364
>>>> PGP Public Key als Empfangsbestaetigung <<<<
## CrossPoint v3.1 R ##
------------------------------
Date: 05 Jun 1999 13:49:00 +0200
From: [EMAIL PROTECTED] (Detlef Bosau)
Crossposted-To: de.comm.internet.routing
Subject: Re: Linux: ICMP Redirect, IP Source Routing unterdruecken
[EMAIL PROTECTED] meinte am 04.06.99
zum Thema "Re: Linux: ICMP Redirect, IP Source Routing unterdruecken":
> Das ist durchaus nicht offtopic.
>
> Aber ich habe mal eine Frage: Inwiefern unterscheidet sich der
> Aufbau eines solchen "PVC" von einem TCP/IP connect(), und muss das
> Netz _unter_ dem PVC nicht immernoch routen/switchen/wie auch
> immer?
Das ist eine sehr gute Frage.
Rein von der Theorie her, und das ist jetzt die _reine_ Theorie,
unterscheidet er sich schon rein dadurch von dem connect, dass
ich zwei Layer komplett entfallen lasse. Das heisst auch, dass
ich die Funktionen dieser beiden Layer, naemlich Pakete sortieren,
anfordern, quittieren, Wegewahl durchfuehren, umfragmentieren,
ggf. voellig umenkapsulieren und was ich jetzt alles noch
uebersehen habe, voellig entfallen lasse.
Das alles sind Aktivitaeten, die derzeit paketweise laufen.
Wenn ich einen PVC in einem switched network habe, arbeite
ich mit einem zu Beginn der Verbindung festgelegten Source Route Pfad.
Und ich arbeite auch, das ist dann eine ganz wesentliche Aenderung,
mit einer Technologie von Ende zu Ende. Die Internetworking-Technik
fehlt natuerlich. Wenn ich die mit einbauen will, muesste ich
Dinge wie MPOA machen: Ich mache den PVC bis zum naechsten Internetworking-
Uebergang. Natuerlich ist damit das Thema QoS auf der Stelle gestorben.
>
> Kann auch sein, das ich Tomaten auf den Augen habe, aber das die
> Pakete dann einfach irgendwie an die Gegenstelle beamen ohne das da
> jemand forwarded erscheint mir recht schwierig ;-)
Forwarding heisst weiterleiten. Und das heisst, ich kriege einen Brief,
schaue auf den Empfaenger und leite den weiter.
So nach dem Motto Wolodja aus Kiew schreibt an Tange Eugenie
in New York und das geht nicht auf dem offiziellen Postweg.
Na, dann geht das ganze ueber jemanden, der schon mal in Richtung
Finnland faehrt, und da ueber jemanden, der amerikanisch kann,
und von diesem Italiener, der als Korrespondent in den USA
amerikanisch gelernt hat, geht das an den Yacht-Club an der
Cote d'Azur und von dort ueber diesen und jenen schliesslich nach
New York.
So unvorstellbar das scheint, genau auf diese Art und Weise hat
mein Vater in den 70er Jahren ueber 20 Jahre nach seiner
Entlassung aus der russischen Gefangenschaft sein Wehrmachts-Soldbuch
gekriegt, was eine Frau in Estland ueber Jahrzehnte fuer ihn versteckt
gehalten hatte. Last Hop war wohl ein Journalist aus Hamburg,
der das ganze dann an uns gesandt hat. Was schon abenteuerlich
genug war, mein Vater und die estnische Frau schrieben sich
gedeckt unter abgewandeltem Namen und abgewandelter Adresse.
Dennoch ist die Post immer angekommen. In meinem Geburtsort
hat die Post das gewusst, wer gemeint war.
Zurueck zum Thema.
Im Grunde arbeitet ein PVC genau so, wie eine Leitung bei der Telekom.
Was sich da geaendert hat, ist eigentlich "nur" die Technik
des Multiplexing. Beim klassischen Lineswitching forwarded
niemand. Da werden die Endgeraete ueber Relais miteinander verbunden.
Die naechste Stufe ist, dies zu multiplexen. Das heisst, auf
Verbindungen im Zeitmultiplex n Leitungen gleichzeitig zu legen.
Das verhaelt sich dann wie n feste Leitungen und die kann ich
wieder wie feste Leitungen verbinden.
Der Schritt zum Cell Switching ist eigentlich "nur" noch der, dass
ich diese virtuellen Leitungen nicht mehr mit einer Synchronmatrix
verdrahte, sondern auf Zellen umbreche, die jeweils eine virtuelle
Leitungsnummer (Channel Identification) haben, damit ich
sie zuordnen kann.
Die Wegewahl reduziert sich dann auf ein ganz stures Table Lookup,
waehrend ich bei einem IP-Paket echt etwas tun muss. Da kommt
z.B. ein Paket an 10.10.10.5. Ich habe aber nur eine Route
zu 10.10.0.0. Das muss ich zuordnen, dass 10.10.10.5 ueberhaupt
dazugehoert. Und das kostet auch viel Zeit.
Beim Cellswitching habe ich den DLCI 10. Und da schaue ich in
die Tabelle, da habe ich die 10: neuer DLCI ist 7, Ausgangsport
ist 8.
Bei Frame Relay (das unterscheidet sich im Switching Mechanismus
selber ueberhaupt nicht, nur die Parameter sehen etwas anders aus)
habe ich, nur mal so als Orientierung, teilweise "nur" DLCIs von
0 bis 1023. Also 1024 Tabelleneintraege fuer maximal 1024 Channels.
Das reicht fuer viele Faelle absolut aus.
Hingegen hast Du bei IP Routing schon bei mittlerer Unternehmensgroesse
mehrere hundert Routing-Eintraege, und bei jedem Paket musst Du wieder
entscheiden, wo Du das Paket hinrouten willst. Und ob Du das Paket
anfassen musst, ob Du aus einem Paket mehrere machen musst oder nicht.
>
> Ich wuerde annehmen, das die heutigen Modelle darauf auch ganz
> schlecht skalieren, wenn ploetzlich nicht 10 PVCs zwischen den
> Backboneknoten, sondern einige Tausend/Millionen zwischen den
> Kommunikationspartnern aufgebaut werden. Da koennen wir dann nochmal
> bei den Telcos klauen. ;-)
Ich habe gerade gestern mit unserem Service Engineer bei unserem
Haupt-Carrier gesprochen. Der hat mich mit einigem voellig
entsetzt. Z.B. damit, dass man bei ihm zumindest _leitungsbezogen_
auf Glasfaserstrecken keine Fehlerkorrektur mache. Und die
Fehlerkorrektur bzw. -behandlung getrost dem TCP ueberlasse,
da ja keine Fehler auftreten wuerden. Nun, "keine" ist relativ.
"Keine" heisst bei der DTAG im Service Level "Fehlerrate <= 10^-9"
und das ist bei 2.4 GBit/s Backbone Leitungen schon ganz bemerkbar.
Ausserdem erklaert das manchen Fehler der letzten Wochen und Monate
und da werde ich mal die eine oder andere etwas schmerzlichere
Frage stellen.
Aber. Zum Topic. Auf Backbone-Leitungen faehrst Du heute mehrere
Tausend PVC's parallel. Das ist auch logisch. Zwischen IGX und IGX
liegen vielleicht 600 MBit/s oder auch 2.4 GBit/s. PVC's aus
dem Weitverkehrsbereich liegen typischerweise so bei 64 kBit/s.
Mal sind das deutlich mehr, aber mal auch deutlich weniger.
Faustregel pro R/3 Anwender ist 2 kBit/s pro Anwender. (Jetzt
weisst Du, wie ich Leitungen skaliere ;-)) Wiviel 64 kBit/s PVCs
nun auf 600 MBit/s passen, kannst Du Dir selber ausrechnen. Und
die Bandbreite liegt da ja nicht zum Daeumchendrehen und zum Versauern.
Noch ein Wort zu Frame Relay: Eben _weil_ die Zahls der PVCs da
sehr unterschiedlich ausfallen kann, kannst Du bei Frame Relay,
wenn ich das richtig sehe, den Bereich der DLCI auch vereinbaren
und dabei deutlich mehr DLCIs verwalten als nur 1024.
Noch ein Bogen zurueck, zu oben. Eben die Tatsache, dass man hier
"unten" keine Fehlerkorrektur macht, erzwingt hier auf dem PVC
wieder eine Fehlerkorrektur. Bei TCP ist die gegeben, aber
auch _NUR_ da. D.h. unser lieber Carrier wird sich noch ganz
gewaltig umschauen, wenn da jemand z.B. IPX macht, wo die Pruefsumme
ueblicherweise nicht gepflegt wird. Oder auch nur UDP, wo die Retransmission
nicht so penetrant laeuft wie bei TCP, sondern die Clients in der
Regel etwas verhaltener reagieren. Das verbluefft die Leute
immer wieder, wenn dann eine simple Routerkonfiguration von 2 kByte
nicht per tftp ausgeliefert werden kann.
Zum einen meine ich, dass da nach unten was gemacht werden muss.
Hier ist dann doch noch zuviel Telco drin, zuviel "Wenns knackt, dann
knackts"-Denke. Ein einzelner Drop Out im Telefon ist ein Knacks,
da sagt kein Mensch was. Bei Daten, die der Aufbewahrungspflicht
unterliegen, sieht das anders aus. Da ist mir unser Carrier,
ich sage das offen, zu laessig. Die Aussage "das macht keiner"
ist vielleicht ein Armutszeugnis, macht die Scheisse aber nicht
weniger braun. Zumal auch das Retransmission-Verhalten mancher
IP-Implementierungen (ich kann nicht sagen, ob aller, darum
sage ich mancher, weil ich mich da auf die beschraenken muss,
die ich vom Sniffer kenne) im Fehlerfall schlicht desastroes ist,
um das zurueckhaltend auszudruecken. Manche Stacks reissen da ganz
einfach den Kredit auf bis der Arzt kommt und donnern die
eh schon ueberlastete und fehlerbehaftete Leitung mit Retransmissions
dicht bis nichts mehr geht. Da faehrst Du dann mit mehrhundertprozentiger
Ueberbuchung, da ist dann nur noch die Leased-Line die Kapaztitaets-
rettung, sonst wuerde das trommeln, bis die IGX zur Heizung wird.
Ich habe erst gestern wieder so ein Ueberbuchungsprofil in der Hand
gehabt, das sah nur noch "toll" aus. Wir ueberlegen jetzt,
ob wir Traffic Shaping machen, um das ganze besser zu steuern.
Zum anderen lerne ich daraus aber auch, dass ich mich _nicht_
darauf verlassen kann, dass ein PVC mir die Daten richtig rueberschaufelt.
Offenbar ist da noch zuviel Kaffeetantendenke drin, wo
man eh nicht zuhoert, sondern spaetestens bei Dame Edna den Telefonhoerer
im Sofakissen plaziert und nur alle zwei Minuten (mit leichter Variation)
hineinruft: "Wirklich! Es ist wirklich UNERHOeRT! Nein, das kann
ich ja kaum glauben!" und ansonsten Dame Edna quasseln laesst.
Wenn ich Datenintegritaet brauche, brauche ich da in jedem Falle
noch eine Schicht, die sich genau um Datenintegritaet kuemmert.
Wie, darueber muss man nachdenken. Z.B. ob man nicht nur ein
Header-CRC Feld hat, sondern die CRC ueber die ganze Zelle zieht.
Aber auch, wie eine Retransmissionsanforderung im Drop Out Fall
aussehen kann. Und zwar dem Medium und dem Uebertragungsweg gemaess
und nicht ganz so herzschmerzmaessig, wie das bei TCP laeuft.
Soweit.
War eh schon viel zu lang ;-)
Detlef
--
Detlef Bosau [EMAIL PROTECTED]
Bienroder Weg 79 Tel.: +49 531 303383
D2: +49 172 6819937
38106 Braunschweig, Germany Fax: +49 531 303364
>>>> PGP Public Key als Empfangsbestaetigung <<<<
## CrossPoint v3.1 R ##
------------------------------
From: [EMAIL PROTECTED] (Jim Lowry)
Subject: Re: $SOCKS_N Environment
Date: Sat, 05 Jun 1999 13:48:37 GMT
That site is not accessible.
>specific name server. You might take a look at www.nec.socks.com for more
------------------------------
Date: 05 Jun 1999 14:15:00 +0200
From: [EMAIL PROTECTED] (Detlef Bosau)
Crossposted-To: de.comm.internet.routing
Subject: Re: Linux: ICMP Redirect, IP Source Routing unterdruecken
[EMAIL PROTECTED] meinte am 04.06.99
zum Thema "Re: Linux: ICMP Redirect, IP Source Routing unterdruecken":
> Bernd Eckenfels <[EMAIL PROTECTED]> writes:
>
> > SAP Router sind keine Router sondern Application Level Proxies.
>
> Ich weiss das! Auch ich kriege manchmal Dinge ausserhalb meines
> Tellerrandes mit ;-)
>
> Darum wunderte ich mich (insgeheim) ja etwas ueber Detlefs
> Ausfuehrungen zu dem Thema in Verbindung mit dyn. Routing.
Worueber genau?
Detlef
--
Detlef Bosau [EMAIL PROTECTED]
Bienroder Weg 79 Tel.: +49 531 303383
D2: +49 172 6819937
38106 Braunschweig, Germany Fax: +49 531 303364
>>>> PGP Public Key als Empfangsbestaetigung <<<<
## CrossPoint v3.1 R ##
------------------------------
Date: 05 Jun 1999 14:14:00 +0200
From: [EMAIL PROTECTED] (Detlef Bosau)
Crossposted-To: de.comm.internet.routing
Subject: Re: Linux: ICMP Redirect, IP Source Routing unterdruecken
[EMAIL PROTECTED] meinte am 03.06.99
zum Thema "Re: Linux: ICMP Redirect, IP Source Routing unterdruecken":
> [EMAIL PROTECTED] (Detlef Bosau) writes:
>
> > Ich stimme mit Dir ueberein, dass Routing ausgedient hat.
>
> Hast du eine Alternative anzubieten?
> Oder sollen wir gar den Layer 3 abschaffen? ;-)
Genau das.
Wir brauchen keine Stationszuordnung auf Layer 2 und dann auf
Layer 3 nochmal, und dann mit NBT Broadcast auf TCP (also Layer 4)
nocheinmal, und dann noch einmal mit der NIS Domaene auf Layer
irgendwas, das ist jetzt schon Hoehenangst, da bin ich nicht mehr
schwindelfrei.
Wir brauchen _eine_ Stationszuordnung, die funktioniert. Alles
andere ist meines Erachtens ueberfluessig.
Detlef
--
Detlef Bosau [EMAIL PROTECTED]
Bienroder Weg 79 Tel.: +49 531 303383
D2: +49 172 6819937
38106 Braunschweig, Germany Fax: +49 531 303364
>>>> PGP Public Key als Empfangsbestaetigung <<<<
## CrossPoint v3.1 R ##
------------------------------
** FOR YOUR REFERENCE **
The service address, to which questions about the list itself and requests
to be added to or deleted from it should be directed, is:
Internet: [EMAIL PROTECTED]
You can send mail to the entire list (and comp.os.linux.networking) via:
Internet: [EMAIL PROTECTED]
Linux may be obtained via one of these FTP sites:
ftp.funet.fi pub/Linux
tsx-11.mit.edu pub/linux
sunsite.unc.edu pub/Linux
End of Linux-Networking Digest
******************************
