vraag: routerings probleem, 2 netwerken aan elkaar koppelen.
Matthijs
Op volgende url is een schema te zien van ons netwerk
http://mth.xs4all.nl/wifi/EdwinMatthijs_files/EdwinMatthijs_frames.htm
We hebben ons netwerk aan elkaar geknoopt via een wireless bridge (2 linksys
WAP11 apparaten)
Zoals je op het plaatje kan zien hebben we beide een internetverbinding, das
allemaal prima en werkt ook. Edwin heeft de 192.168.0.x range en ik
192.168.2.x range op ons netwerk.
Ik dacht eerst dat als ik in mijn router een route toevoeg 192.168.0.0 mask
255.255.255 naar 192.168.0.1 en hij net andersom dus 192.168.2.0 mask
255.255.2550 naar 192.168.2.1 dat alles goed zou zijn, maar helaas, we
kunnen elkaar dan niet pingen.
Als ik mijn router een 2e ip adres erbij geef, zeg 192.168.0.200 dan kan ik
op edwin's netwerk alle adressen pingen, servers benaderen etc.
Als hij een ping doet naar bv 192.168.2.100 krijgt hij een response van
192.168.0.200!! (das de router aan mijn kant) dat vindt ik gek.
Iemand een idee wat hier fout aan is? Ik heb ook al geprobeerd de wireless
bridge aan mijn kant een ip adres in de 192.168.0.x range te geven, maar dan
heb ik precies hetzelfde effect.
Alvast bedankt,
Matthijs
Thijs Cobben
Matthijs wrote in message ...
>Hoi,
>Op volgende url is een schema te zien van ons netwerk
>http://mth.xs4all.nl/wifi/EdwinMatthijs_files/EdwinMatthijs_frames.htm
>
>We hebben ons netwerk aan elkaar geknoopt via een wireless bridge (2
linksys
>WAP11 apparaten)
>
>Zoals je op het plaatje kan zien hebben we beide een internetverbinding,
das
>allemaal prima en werkt ook. Edwin heeft de 192.168.0.x range en ik
>192.168.2.x range op ons netwerk.
>
Groet,
Thijs
Thijs Cobben
Thijs Cobben wrote in message ...
>>allemaal prima en werkt ook. Edwin heeft de 192.168.0.x range en ik
>>192.168.2.x range op ons netwerk.
>>
>Probeer het eens met 192.168.1.x
Danny Terweij
"Thijs Cobben" <cob...@abfab.nl> schreef in bericht
news:agc3cl$249e$1...@news.versatel.net...
Moet niks uitmaken, een router routeerd alles.
Als is de Y : 192.121.251.yyy en X: 10.23.223.xxx ...
Kwestie van goed instellen, weten wat je aan het doen bent, veel lezen,
diagnostic tools gebruiken enz..
Dan kom je er wel.
Danny.
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.373 / Virus Database: 208 - Release Date: 1-7-02
Matthijs
"Danny Terweij" <da...@poema.yi.org> wrote in message
news:PS8696...@p-s.nl...
>
> "Thijs Cobben" <cob...@abfab.nl> schreef in bericht
> news:agc3cl$249e$1...@news.versatel.net...
>
> > Thijs Cobben wrote in message ...
> > >>allemaal prima en werkt ook. Edwin heeft de 192.168.0.x range en ik
> > >>192.168.2.x range op ons netwerk.
> > >>
> > >Probeer het eens met 192.168.1.x
> > (ipv 192.168.0.x dus 1.x en 2.y)
>
> Moet niks uitmaken, een router routeerd alles.
> Als is de Y : 192.121.251.yyy en X: 10.23.223.xxx ...
>
> Kwestie van goed instellen, weten wat je aan het doen bent, veel lezen,
> diagnostic tools gebruiken enz..
> Dan kom je er wel.
>
> Danny.
>
die via routeren samen laten werken, maar het werkte niet zoals verwacht.
Vandaar mijn vraag.
Vandaag probeer ik het eens zonder de routers maar met een paar losse pc's.
bedankt
Matthijs
Thijs Cobben
Danny Terweij wrote in message ...
>Moet niks uitmaken, een router routeerd alles.
>Als is de Y : 192.121.251.yyy en X: 10.23.223.xxx ...
Hmmm... ik weet niks van 'echte' routers maar voor het unix 'route' commando
heeft een 0-octet toch echt een speciale betekenis ('default'). Volgens mij
is dat 'TCP/IP' spec (net zoals 255 'broadcast' betekent).
Dus volgens mij is 'route add 192.168.0.223 eth0' zoiets als 'routeer
verkeer naar 192.168.1.223 , 192.168.2.223 , ... , 192.168.254.223 naar
eth1'
Dacht ik. Stel anders je vraag op nl.comp.os.linux.netwerken ofzo?
Matthijs: heb je het al geprobeerd met 1.x ipv 0.x?
Groet,
--
Thijs
JP Velders
> Hmmm... ik weet niks van 'echte' routers maar voor het unix 'route' commando
> heeft een 0-octet toch echt een speciale betekenis ('default'). Volgens mij
> is dat 'TCP/IP' spec (net zoals 255 'broadcast' betekent).
> Dus volgens mij is 'route add 192.168.0.223 eth0' zoiets als 'routeer
> verkeer naar 192.168.1.223 , 192.168.2.223 , ... , 192.168.254.223 naar
> eth1'
Zeg, het is geen Windows !
Groetjes,
JP Velders
Rob Janssen
>Danny Terweij wrote in message ...
>>Moet niks uitmaken, een router routeerd alles.
>>Als is de Y : 192.121.251.yyy en X: 10.23.223.xxx ...
>Hmmm... ik weet niks van 'echte' routers maar voor het unix 'route' commando
>heeft een 0-octet toch echt een speciale betekenis ('default'). Volgens mij
>is dat 'TCP/IP' spec (net zoals 255 'broadcast' betekent).
>Dus volgens mij is 'route add 192.168.0.223 eth0' zoiets als 'routeer
>verkeer naar 192.168.1.223 , 192.168.2.223 , ... , 192.168.254.223 naar
>eth1'
>Dacht ik.
Jaja. Nou gelukkig is dat niet zo.
Net zoals je gelukkig geen mail kunt sturen aan *@*.nl
Rob
--
+--------------------------------+--------------------------------------+
| Rob Janssen pe1...@amsat.org | WWW: http://www.xs4all.nl/~pe1chl/ |
| AMPRnet: r...@pe1chl.ampr.org | AX.25 BBS: PE1CHL@PI8ZAA.#NBO.NLD.EU |
+--------------------------------+--------------------------------------+
Erwin
<snip probleem met WLAN>
Ik kan je netwerktekening niet laden omdat je webserver niet
draait/verbinding niet online is whatever.
Als het een echte bridge is dan moeten jullie ipadressen in hetzelfde subnet
zitten dus moet een van de 2 omnummeren.
Dat verklaart ook wel het feit dat wanneer je een 2e adres toevoegt wat in
dezelfde range als die van je vriendje ligt het allemaal werkt en hij ook
antwoord krijgt.
Ergo, probeer eens een van je machines om te nummeren en kijk of je dan wel
het andere netwerk kan benaderen.
Als je je pagina weer online helpt zal ik eens verder kijken mocht dit niet
werken.
Erwin
Vincent Zweije
Erwin <vol...@REMOVExs4all.nl> wrote:
|| Ik kan je netwerktekening niet laden omdat je webserver niet
|| draait/verbinding niet online is whatever.
Nee, de ongelukkige blokt met zijn firewall waarschijnlijk ICMP
waardoor TCP/ECN communicatie niet goed werkt.
ICMP blokkeren is geen goed idee.
|| Als het een echte bridge is dan moeten jullie ipadressen in hetzelfde
|| subnet zitten dus moet een van de 2 omnummeren.
|| Dat verklaart ook wel het feit dat wanneer je een 2e adres toevoegt wat in
|| dezelfde range als die van je vriendje ligt het allemaal werkt en hij ook
|| antwoord krijgt.
|| Ergo, probeer eens een van je machines om te nummeren en kijk of je dan wel
|| het andere netwerk kan benaderen.
Inderdaad, hoewel dat ook met een supernet is op te lossen
(192.168.0.0/22).
|| Als je je pagina weer online helpt zal ik eens verder kijken mocht dit niet
|| werken.
=> zodra ICMP niet meer wordt geblokt...
Ciao. Vincent.
jos...@quadpro.stupendous.org
> Hmmm... ik weet niks van 'echte' routers maar voor het unix 'route' commando
> heeft een 0-octet toch echt een speciale betekenis ('default'). Volgens mij
> is dat 'TCP/IP' spec (net zoals 255 'broadcast' betekent).
0.0.0.0 betekent zoiets als "this host, this network".
--
Jurjen Oskam
PGP Key available at http://www.stupendous.org/
Matthijs
"Vincent Zweije" <zwe...@xs4all.nl> wrote in message
news:ageg0d$si7$1...@news1.xs4all.nl...
De reden dat de pagina niet bereikbaar was, was omdat ik alle spullen los
gehaald heb en samen met de spullen van Edwin op zolder de boel aan elkaar
heb geknoopt om eens het een en ander te testen.
Het lijkt erop dat mijn router (Vigor2200) iets anders werkt dan ik dacht.
Ik had een 2e netwerk adres toegevoegd, maar blijkbaar wordt die over de WAN
poort ipv de LAN poort gerouteerd. (als ik de handleiding goed begrijp) Dus
ik ga eens testen wat er gebeurt als ik daar een kabeltje inprik naar het
andere netwerk.
Maar bedankt voor de verschillende suggesties.
Matthijs
Floor van Unen
Standaard routers routeren geen private subnetten zoals 192.168.*.*, omdat
ze nou juist private zijn. Dat is ook de reden dat iedereen zomaar die range
mag gebruiken, omdat ze elkaar nooit in de weg kunnen zitten omdat ze alleen
dan gerouteert worden als je dat in de router expliciet opgeeft.
Floor
"Matthijs" <matt...@mth.xs4all.nl> wrote in message
news:agcdla$frh$1...@news1.xs4all.nl...
comecme
> Ahum,
>
> Standaard routers routeren geen private subnetten zoals 192.168.*.*,
> omdat ze nou juist private zijn. Dat is ook de reden dat iedereen
> zomaar die range mag gebruiken, omdat ze elkaar nooit in de weg
> kunnen zitten omdat ze alleen dan gerouteert worden als je dat in de
> router expliciet opgeeft.
Oh? Wat bedoel je dan met een standaard router? XS4All gebruikt i.i.g.
routers die dat wel doen.
C:\>tracert 213.84.232.33
Tracing route to uptime.xs4all.nl [213.84.232.33]
over a maximum of 30 hops:
1 <10 ms <10 ms <10 ms vigor2200 [192.168.1.1]
2 <10 ms 31 ms 16 ms 195.190.240.165
3 16 ms 31 ms 15 ms 10.142.232.73
4 31 ms 31 ms 47 ms uptime.xs4all.nl [213.84.232.33]
Het gaat hier dan natuurlijk om de 3e hop.
Maurice Janssen
Grappig, vanaf mijn PC zit er een gat in de trace naar diezelfde bak:
Matt's traceroute [v0.44]
linux.z74.net Mon Jul 15 00:02:17 2002
Keys: D - Display mode R - Restart statistics Q - Quit
Packets Pings
Hostname %Loss Rcv Snt Last Best Avg Worst
1. router.z74.net 0% 22 22 1 1 1 1
2. gw-64-93.sms-1.ams-tel.cistron.net 0% 22 22 18 16 18 19
3. ve10.rtr-1.ams-tel.cistron.net 0% 22 22 18 16 18 20
4. ams-ix.sara.xs4all.net 0% 22 22 20 17 18 24
5. 0.ge-0-3-0.xr1.pbw.xs4all.net 0% 22 22 19 17 18 20
6. mxstream1.pbw.xs4all.net 0% 22 22 21 18 20 22
7. ???
8. uptime.xs4all.nl 0% 22 22 35 33 34 36
tracen met UDP of ICMP maakt in dit geval niet uit, voor beide geeft de
7e hop geen antwoord.
--
Maurice
Floor van Unen
het netwerk heeft. Net als je vigor 2200 (geeft ook private range IP terug;
draait dus NAT). Beiden kunnen aan de andere kant een ander ip-adres hebben.
XS4All heeft dus expliciet in haar routers regeltjes geprogrammeerd om dit
te laten werken. Zie ook http://www.traceroute.nl/whois?q=10.142.232.73 .
Floor
"comecme" <nos...@dicknagtegaal.com> wrote in message
news:agss0k$475$1...@news1.xs4all.nl...
Rob Janssen
>C:\>tracert 213.84.232.33
Een "standaard" router maakt ook helemaal geen uitzonderingen voor
die adressen, er wordt hooguit bij Internet providers een rule in geladen
om verkeer wat door de klant wordt aangeboden niet verder te routeren als
het naar zo'n adres moet.
Zou ook een mooie boel zijn, dan zou je een "standaard" router niet kunnen
gebruiken in je eigen netwerk wat met prive adressen draait!!
(op het werk hebben we verschillende subnetten binnen de 172.16-32 range
en er staan "standaard" cisco routers die dit via huurlijnen routeren
zonder speciale aanpassingen oid)
Vincent Zweije
<nos...@dicknagtegaal.com>:
|| Oh? Wat bedoel je dan met een standaard router? XS4All gebruikt i.i.g.
|| routers die dat wel doen.
||
|| C:\>tracert 213.84.232.33
||
|| Tracing route to uptime.xs4all.nl [213.84.232.33]
|| over a maximum of 30 hops:
||
|| 1 <10 ms <10 ms <10 ms vigor2200 [192.168.1.1]
|| 2 <10 ms 31 ms 16 ms 195.190.240.165
|| 3 16 ms 31 ms 15 ms 10.142.232.73
|| 4 31 ms 31 ms 47 ms uptime.xs4all.nl [213.84.232.33]
Het uitgaande derde ping pakketje had je eigen adres (zeg w.x.y.z)
als source adres en 213.84.232.33 als destination adres.
Het terugkerende derde ping pakketje had w.x.y.z als destination adres
maar 10.142.232.73 als source adres.
Geen van beide pakketjes had een 10.*.*.* adres als bestemming. 10.*.*.*
is dus niet gebruikt voor de routering.
De routers die geen private adressen routeren zijn volgens mij de
"defaultless" routers - de grote jongens die verkeer tussen ISPs
routeren en zo. Er is geen probleem om een private adres binnen een ISP
te gebruiken.
Ciao. Vincent.
--
Vincent Zweije <zwe...@xs4all.nl> | "If you're flamed in a group you
<http://www.xs4all.nl/~zweije/> | don't read, does anybody get burnt?"
[Xhost should be taken out and shot] | -- Paul Tomblin on a.s.r.
Boudewijn W. Ch. Visser
Er is een behoorlijk verschil tussen traceroute en MTR.
Traceroute stuurt een serie pakketen naar een bestemming (met jouw source-adres), met oplopende TTL.
MTR doet dat maar 1 keer, en pingt daarna elke hop afzonderlijk. (dus jouw
source, maar de destination van een hop, niet van het eindstation)
Ik denk dat na het tracen, de ping naar dat 10-adres faalt, en daarom de hop
als ??? wordt weergegeven.
Ik verwacht dat je met je 'gewone' traceroute hetzelfde als de OP zult zien.
Boudewijn
--
+--------------------------------------------------------------+
|Boudewijn Visser | E-mail:vis...@ph.tn.tudelft.nl |
| - - | http: |
+-- my own opinions etc ---------------------------------------+
Boudewijn W. Ch. Visser
>In artikel <agss0k$475$1...@news1.xs4all.nl> schrijft comecme
><nos...@dicknagtegaal.com>:
[..]
>Het terugkerende derde ping pakketje had w.x.y.z als destination adres
>maar 10.142.232.73 als source adres.
>
>Geen van beide pakketjes had een 10.*.*.* adres als bestemming. 10.*.*.*
>is dus niet gebruikt voor de routering.
>
>De routers die geen private adressen routeren zijn volgens mij de
>"defaultless" routers - de grote jongens die verkeer tussen ISPs
>routeren en zo. Er is geen probleem om een private adres binnen een ISP
>te gebruiken.
Voor ongeveer alle routers geldt, dat ze routeren als ze een entry in
hun routing table hebben. Er is helemaal *niets* bijzonders aan
rfc1918 adressen, wat dat betreft.
Als je in je netwerk rfc1918 adressen gebruikt, worden die gerouteerd.
Gewoon door die in de routing table van je routers te zetten, statisch,
of dynamisch via een routing protocol (rip, ospf,is-is,bgp etc etc ).
Of, als de router een default route heeft zal alle verkeer wat niet
ergens naar toe gaat, inclusief rfc1918, de default volgen.
Defaultless is ook niet per se een grote router. Het is perfect mogelijk
om een netwerk met kleine routers te hebben die geen default routes
hebben, in een bedrijfsnetwerk bijvoorbeeld. (alleen internet ip
connectivity gaat dan niet, met kleine routers zonder default).
Grote routers zonder default (die dan de volledige internet routing
table, zo'n 110-120K routes hebben) kunnen nog steeds prima rfc1918
routeren, als de ISP die in gebruik heeft en ze ook in de routers zet.
(maar alleen voor intern gebruik binnen die ISP, dus).
Het *enige* wat er bijzonder is aan rfc1918, is dat die reeksen adressen
bij afspraak niet uitgegeven worden aan 1 netwerk, maar voor algemeen
gebruik zijn.
En dus niet uniek in de wereld, en dus kan niet 1 netwerk die adresreeksen
naar zich toe laten routeren.
ISP's en bedrijven die die adressen gebruiken, moeten hun routers zodanig
configureren dat die adressen niet naar buiten 'lekken'.
Niet qua pakketten, maar vooral ook niet als BGP announcements.
(routing informatie die andere ISP's verteld welke addressen door of via
een ISP bereikbaar zijn ).
En omgekeerd, hun routers configureren om die addressen ook niet naar
binnen te laten lekken, als een andere provider een foutje mocht maken
en zo'n netwerk per ongeluk zou announcen.
Hoe dan ook, rfc1918 adressen zijn speciaal omdat ze in rfc1918 staan,
en ISP's hun routers configureren. Het zit niet in de hardware of software(firmware) van een router, in elk geval.
Ik zou moeten controleren of er uberhaupt wel 'speciale' IP reeksen voor
routers bestaan. Ik denk hooguit de multicast reeks [class D adres]
misschien 'ingebouwd' speciaal is, omdat die ook op layer2 bijzonder is,
maar ik zou moeten controleren of daarvoor niet eerst multicast aangezet
moet worden.
Maurice Janssen
>On 14 Jul 2002 22:05:13 GMT, Maurice Janssen <th...@is.invalid> wrote:
>>On Sun, 14 Jul 2002 23:55:31 +0200, comecme wrote:
>>> 1 <10 ms <10 ms <10 ms vigor2200 [192.168.1.1]
>>> 2 <10 ms 31 ms 16 ms 195.190.240.165
>>> 3 16 ms 31 ms 15 ms 10.142.232.73
>>> 4 31 ms 31 ms 47 ms uptime.xs4all.nl [213.84.232.33]
>>Grappig, vanaf mijn PC zit er een gat in de trace naar diezelfde bak:
[mtr trace:]
>> 1. router.z74.net 0% 22 22 1 1 1 1
>> 2. gw-64-93.sms-1.ams-tel.cistron.net 0% 22 22 18 16 18 19
>> 3. ve10.rtr-1.ams-tel.cistron.net 0% 22 22 18 16 18 20
>> 4. ams-ix.sara.xs4all.net 0% 22 22 20 17 18 24
>> 5. 0.ge-0-3-0.xr1.pbw.xs4all.net 0% 22 22 19 17 18 20
>> 6. mxstream1.pbw.xs4all.net 0% 22 22 21 18 20 22
>> 7. ???
>> 8. uptime.xs4all.nl 0% 22 22 35 33 34 36
>>
>>tracen met UDP of ICMP maakt in dit geval niet uit, voor beide geeft de
>>7e hop geen antwoord.
>
>Er is een behoorlijk verschil tussen traceroute en MTR.
>
>Traceroute stuurt een serie pakketen naar een bestemming (met jouw
>source-adres), met oplopende TTL.
>
>MTR doet dat maar 1 keer, en pingt daarna elke hop afzonderlijk. (dus jouw
>source, maar de destination van een hop, niet van het eindstation)
Nee hoor, ook mtr stuurt een ICMP echo request naar de laatste host en
ziet TTL-exceeded pakketjes terugkomen. Stukje tethereal tijdens een
mtr naar ping.xs4all.nl:
07:30:26.3036 192.168.1.2 -> 194.109.6.11 ICMP Echo (ping) request
07:30:26.3044 192.168.1.1 -> 192.168.1.2 ICMP Time-to-live exceeded
07:30:26.4737 192.168.1.2 -> 194.109.6.11 ICMP Echo (ping) request
07:30:26.4909 195.64.93.1 -> 192.168.1.2 ICMP Time-to-live exceeded
07:30:26.6436 192.168.1.2 -> 194.109.6.11 ICMP Echo (ping) request
07:30:26.6612 62.216.31.1 -> 192.168.1.2 ICMP Time-to-live exceeded
07:30:26.8136 192.168.1.2 -> 194.109.6.11 ICMP Echo (ping) request
07:30:26.8309 193.148.15.48 -> 192.168.1.2 ICMP Time-to-live exceeded
07:30:26.9836 192.168.1.2 -> 194.109.6.11 ICMP Echo (ping) request
07:30:27.0022 194.109.5.13 -> 192.168.1.2 ICMP Time-to-live exceeded
07:30:27.0037 192.168.1.2 -> 194.109.6.11 ICMP Echo (ping) request
07:30:27.0223 194.109.6.11 -> 192.168.1.2 ICMP Echo (ping) reply
(En dit was niet de eerste serie, maar nadat mtr al een paar seconden
had gedraaid.)
>Ik denk dat na het tracen, de ping naar dat 10-adres faalt, en daarom de hop
>als ??? wordt weergegeven.
>
>Ik verwacht dat je met je 'gewone' traceroute hetzelfde als de OP zult zien.
De host van hierboven is nu niet on-line, maar ik heb het even met een
willekeurige andere ADSL-klant geprobeerd en ook daar krijg ik (zowel
met UDP als met ICMP) geen antwoord van de betreffende hop:
6 mxstream1.pbw.xs4all.net (194.109.5.66) 19.392 ms 19.143 ms 18.183 ms
7 * * *
8 eljakimbmc.xs4all.nl (213.84.166.144) 31.568 ms 34.620 ms 32.997 ms
FWIW: ook vanaf xs1 krijg ik geen antwoord en zie ik geen 10.x.y.z adres
voorbijkomen.
--
Maurice
Maurice Janssen
>>On Sun, 14 Jul 2002 23:55:31 +0200, comecme wrote:
>>> 1 <10 ms <10 ms <10 ms vigor2200 [192.168.1.1]
>>> 2 <10 ms 31 ms 16 ms 195.190.240.165
>>> 3 16 ms 31 ms 15 ms 10.142.232.73
>>> 4 31 ms 31 ms 47 ms uptime.xs4all.nl [213.84.232.33]
>>Grappig, vanaf mijn PC zit er een gat in de trace naar diezelfde bak:
[mtr trace:]
>> 1. router.z74.net 0% 22 22 1 1 1 1
>> 2. gw-64-93.sms-1.ams-tel.cistron.net 0% 22 22 18 16 18 19
>> 3. ve10.rtr-1.ams-tel.cistron.net 0% 22 22 18 16 18 20
>> 4. ams-ix.sara.xs4all.net 0% 22 22 20 17 18 24
>> 5. 0.ge-0-3-0.xr1.pbw.xs4all.net 0% 22 22 19 17 18 20
>> 6. mxstream1.pbw.xs4all.net 0% 22 22 21 18 20 22
>> 7. ???
>> 8. uptime.xs4all.nl 0% 22 22 35 33 34 36
>>
>>tracen met UDP of ICMP maakt in dit geval niet uit, voor beide geeft de
>>7e hop geen antwoord.
>
>Er is een behoorlijk verschil tussen traceroute en MTR.
>
>Traceroute stuurt een serie pakketen naar een bestemming (met jouw
>source-adres), met oplopende TTL.
>
>MTR doet dat maar 1 keer, en pingt daarna elke hop afzonderlijk. (dus jouw
>source, maar de destination van een hop, niet van het eindstation)
Nee hoor, ook mtr stuurt een ICMP echo request naar de laatste host en
ziet TTL-exceeded pakketjes terugkomen. Stukje tethereal tijdens een
mtr naar ping.xs4all.nl:
07:30:26.3036 192.168.1.2 -> 194.109.6.11 ICMP Echo (ping) request
07:30:26.3044 192.168.1.1 -> 192.168.1.2 ICMP Time-to-live exceeded
07:30:26.4737 192.168.1.2 -> 194.109.6.11 ICMP Echo (ping) request
07:30:26.4909 195.64.93.1 -> 192.168.1.2 ICMP Time-to-live exceeded
07:30:26.6436 192.168.1.2 -> 194.109.6.11 ICMP Echo (ping) request
07:30:26.6612 62.216.31.1 -> 192.168.1.2 ICMP Time-to-live exceeded
07:30:26.8136 192.168.1.2 -> 194.109.6.11 ICMP Echo (ping) request
07:30:26.8309 193.148.15.48 -> 192.168.1.2 ICMP Time-to-live exceeded
07:30:26.9836 192.168.1.2 -> 194.109.6.11 ICMP Echo (ping) request
07:30:27.0022 194.109.5.13 -> 192.168.1.2 ICMP Time-to-live exceeded
07:30:27.0037 192.168.1.2 -> 194.109.6.11 ICMP Echo (ping) request
07:30:27.0223 194.109.6.11 -> 192.168.1.2 ICMP Echo (ping) reply
(En dit was niet de eerste serie, maar nadat mtr al een paar seconden
had gedraaid.)
>Ik denk dat na het tracen, de ping naar dat 10-adres faalt, en daarom de hop
>als ??? wordt weergegeven.
>
>Ik verwacht dat je met je 'gewone' traceroute hetzelfde als de OP zult zien.
De host van hierboven is nu niet on-line, maar ik heb het even met een
willekeurige andere ADSL-klant geprobeerd en ook daar krijg ik (zowel
met UDP als met ICMP) geen antwoord van de betreffende hop:
6 mxstream1.pbw.xs4all.net (194.109.5.66) 19.392 ms 19.143 ms 18.183 ms
7 * * *
8 <somehost>.xs4all.nl (213.84.166.***) 31.568 ms 34.620 ms 32.997 ms
Boudewijn W. Ch. Visser
>On 17 Jul 2002 23:31:30 GMT, Boudewijn W. Ch. Visser wrote:
[over werkwijze van mtr]
>>
>>Er is een behoorlijk verschil tussen traceroute en MTR.
>>
>>Traceroute stuurt een serie pakketen naar een bestemming (met jouw
>>source-adres), met oplopende TTL.
>>
>>MTR doet dat maar 1 keer, en pingt daarna elke hop afzonderlijk. (dus jouw
>>source, maar de destination van een hop, niet van het eindstation)
>
>Nee hoor, ook mtr stuurt een ICMP echo request naar de laatste host en
>ziet TTL-exceeded pakketjes terugkomen. Stukje tethereal tijdens een
>mtr naar ping.xs4all.nl:
>07:30:26.3036 192.168.1.2 -> 194.109.6.11 ICMP Echo (ping) request
>07:30:26.3044 192.168.1.1 -> 192.168.1.2 ICMP Time-to-live exceeded
>07:30:26.4737 192.168.1.2 -> 194.109.6.11 ICMP Echo (ping) request
>07:30:26.4909 195.64.93.1 -> 192.168.1.2 ICMP Time-to-live exceeded
>07:30:26.6436 192.168.1.2 -> 194.109.6.11 ICMP Echo (ping) request
>07:30:26.6612 62.216.31.1 -> 192.168.1.2 ICMP Time-to-live exceeded
>07:30:26.8136 192.168.1.2 -> 194.109.6.11 ICMP Echo (ping) request
>07:30:26.8309 193.148.15.48 -> 192.168.1.2 ICMP Time-to-live exceeded
>07:30:26.9836 192.168.1.2 -> 194.109.6.11 ICMP Echo (ping) request
>07:30:27.0022 194.109.5.13 -> 192.168.1.2 ICMP Time-to-live exceeded
>07:30:27.0037 192.168.1.2 -> 194.109.6.11 ICMP Echo (ping) request
>07:30:27.0223 194.109.6.11 -> 192.168.1.2 ICMP Echo (ping) reply
>(En dit was niet de eerste serie, maar nadat mtr al een paar seconden
>had gedraaid.)
Mw, ik dacht alleen de eerste. Ik had er lang geleden eens naar gekeken,
en mijn check-before-posting beperkt tot de mtr manpage :
mtr 0.51 :
As mtr starts, it investigates the network connection
between the host mtr runs on and HOSTNAME. After it
determines the address of each network hop between the
machines, it sends a sequence ICMP ECHO requests to each
one to determine the quality of the link to each machine.
As it does this, it prints running statistics about each
machine.
Hoewel ook een regelmatige tussendoor-traceroute niet uitsluit dat mtr ???
laat zien wanneer het de hop niet ook kan pingen.
>
>>Ik denk dat na het tracen, de ping naar dat 10-adres faalt, en daarom de hop
>>als ??? wordt weergegeven.
>>
>>Ik verwacht dat je met je 'gewone' traceroute hetzelfde als de OP zult zien.
>
>De host van hierboven is nu niet on-line, maar ik heb het even met een
>willekeurige andere ADSL-klant geprobeerd en ook daar krijg ik (zowel
>met UDP als met ICMP) geen antwoord van de betreffende hop:
> 6 mxstream1.pbw.xs4all.net (194.109.5.66) 19.392 ms 19.143 ms 18.183 ms
> 7 * * *
> 8 <somehost>.xs4all.nl (213.84.166.***) 31.568 ms 34.620 ms 32.997 ms
Het zou natuurlijk heel goed kunnen dat die router nu gewoon helemaal geen
ttl exceeded meer stuurt.
Wat je zou kunnen proberen (liefst van een host zo dichtbij mogelijk) is
een beetje handmatig pmtu discovery doen. Dus pingen met steeds groter wordende
pakketen, die het DF (don't fragment) bit gezet hebben.
Op moment dat de mystery hop moet fragmenteren, maar dat vanwege DF niet
mag moet die hop een icmp message sturen.
Geen grote kans dat dit lukt, alleen, want je moet tot aan de mystery hop
een grotere mtu hebben dan op een uitgaande link vanaf de mystery hop.
Als je onderweg al een kleinere of dezelfde mtu hebt gaat het niet lukken.
Maurice Janssen
>On 18 Jul 2002 06:05:11 GMT, Maurice Janssen <th...@is.invalid> wrote:
>>On 17 Jul 2002 23:31:30 GMT, Boudewijn W. Ch. Visser wrote:
>
>[over werkwijze van mtr]
>
>>>
>>>Er is een behoorlijk verschil tussen traceroute en MTR.
>>>
>>>Traceroute stuurt een serie pakketen naar een bestemming (met jouw
>>>source-adres), met oplopende TTL.
>>>
>>>MTR doet dat maar 1 keer, en pingt daarna elke hop afzonderlijk. (dus jouw
>>>source, maar de destination van een hop, niet van het eindstation)
>>
>>Nee hoor, ook mtr stuurt een ICMP echo request naar de laatste host en
>>ziet TTL-exceeded pakketjes terugkomen. Stukje tethereal tijdens een
>>mtr naar ping.xs4all.nl:
>>(En dit was niet de eerste serie, maar nadat mtr al een paar seconden
>>had gedraaid.)
>
>Mw, ik dacht alleen de eerste. Ik had er lang geleden eens naar gekeken,
>en mijn check-before-posting beperkt tot de mtr manpage :
>
>mtr 0.51 :
>
> As mtr starts, it investigates the network connection
> between the host mtr runs on and HOSTNAME. After it
> determines the address of each network hop between the
> machines, it sends a sequence ICMP ECHO requests to each
> one to determine the quality of the link to each machine.
> As it does this, it prints running statistics about each
> machine.
Had ik nog niet gelezen, maar blijkbaar klopt dat toch niet. Ik
gebruikte nog een oude versie (0.44), maar 0.51 vertoont precies
hetzelfde gedrag. Ik heb hem een tijdje laten lopen, maar ook dat haalt
niets uit, hij blijft met oplopende TTL de laatste hop pingen.
>>De host van hierboven is nu niet on-line, maar ik heb het even met een
>>willekeurige andere ADSL-klant geprobeerd en ook daar krijg ik (zowel
>>met UDP als met ICMP) geen antwoord van de betreffende hop:
>> 6 mxstream1.pbw.xs4all.net (194.109.5.66) 19.392 ms 19.143 ms 18.183 ms
>> 7 * * *
>> 8 <somehost>.xs4all.nl (213.84.166.***) 31.568 ms 34.620 ms 32.997 ms
>
>Het zou natuurlijk heel goed kunnen dat die router nu gewoon helemaal geen
>ttl exceeded meer stuurt.
Of een andere router ergens filtert pakketjes met source IP in de
10.0.0.0/8 range eruit. Ik heb immers geen xs4all-adsl verbinding, en de
OP wel IIRC. Ik kom dus een aantal routers tegen die de OP niet tegen
komt.
>Wat je zou kunnen proberen (liefst van een host zo dichtbij mogelijk) is
>een beetje handmatig pmtu discovery doen. Dus pingen met steeds groter wordende
>pakketen, die het DF (don't fragment) bit gezet hebben.
>Op moment dat de mystery hop moet fragmenteren, maar dat vanwege DF niet
>mag moet die hop een icmp message sturen.
>
>Geen grote kans dat dit lukt, alleen, want je moet tot aan de mystery hop
>een grotere mtu hebben dan op een uitgaande link vanaf de mystery hop.
>Als je onderweg al een kleinere of dezelfde mtu hebt gaat het niet lukken.
Dichterbij dan xs1 kom ik niet, en die krijgt ook geen antwoord van de
betreffende hop bij een traceroute. Ik geloog het verder wel ;-)
--
Maurice
Boudewijn W. Ch. Visser
>On 18 Jul 2002 15:11:50 GMT, Boudewijn W. Ch. Visser wrote:
>>On 18 Jul 2002 06:05:11 GMT, Maurice Janssen <th...@is.invalid> wrote:
>>>On 17 Jul 2002 23:31:30 GMT, Boudewijn W. Ch. Visser wrote:
>>
>>[over werkwijze van mtr]
[..]
>> machines, it sends a sequence ICMP ECHO requests to each
>> one to determine the quality of the link to each machine.
>> As it does this, it prints running statistics about each
>> machine.
>
>Had ik nog niet gelezen, maar blijkbaar klopt dat toch niet. Ik
>gebruikte nog een oude versie (0.44), maar 0.51 vertoont precies
>hetzelfde gedrag. Ik heb hem een tijdje laten lopen, maar ook dat haalt
>niets uit, hij blijft met oplopende TTL de laatste hop pingen.
Wel, het moet echt lang geleden zijn dat ik er naar keek.
Binary search...
mtr 0.21 heeft het gedrag wat ik (en de manpage) beschreven, mtr 0.40
doet alleen herhaaldelijk een traceroute (met icmp echo's ).
mtr 0.30 klopt ook nog met de manpage.
mtr 0.36 heeft het 'nieuwe' gedrag,alleen icmp based traceroutes.
Niks in de NEWS file wat op het verschil wijst.
Bingo.
mtr 0.33 oud , mtr 0.34 nieuw.
Bugrapport gestuurd met verzoek om manpage en readme aan te passen.
[..]
>>> 8 <somehost>.xs4all.nl (213.84.166.***) 31.568 ms 34.620 ms 32.997 ms
>>
>>Het zou natuurlijk heel goed kunnen dat die router nu gewoon helemaal geen
>>ttl exceeded meer stuurt.
>
>Of een andere router ergens filtert pakketjes met source IP in de
>10.0.0.0/8 range eruit. Ik heb immers geen xs4all-adsl verbinding, en de
>OP wel IIRC. Ik kom dus een aantal routers tegen die de OP niet tegen
>komt.
Dat is zeker ook mogelijk. Hoewel het me minder waarschijnlijk lijkt
binnen het xs4all netwerk zelf. Dat is typisch iets om alleen aan
de edge van een netwerk te doen.
(je had het toch ook van xs1 geprobeerd ? )
[..]
>Dichterbij dan xs1 kom ik niet, en die krijgt ook geen antwoord van de
>betreffende hop bij een traceroute. Ik geloog het verder wel ;-)
Ja...
Maurice Janssen
>On 18 Jul 2002 19:17:37 GMT, Maurice Janssen <th...@is.invalid> wrote:
>>On 18 Jul 2002 15:11:50 GMT, Boudewijn W. Ch. Visser wrote:
>
>Wel, het moet echt lang geleden zijn dat ik er naar keek.
>
>Binary search...
>
>mtr 0.21 heeft het gedrag wat ik (en de manpage) beschreven, mtr 0.40
>doet alleen herhaaldelijk een traceroute (met icmp echo's ).
>
>mtr 0.30 klopt ook nog met de manpage.
>
>mtr 0.36 heeft het 'nieuwe' gedrag,alleen icmp based traceroutes.
>
>Niks in de NEWS file wat op het verschil wijst.
>
>Bingo.
>
>mtr 0.33 oud , mtr 0.34 nieuw.
>
>Bugrapport gestuurd met verzoek om manpage en readme aan te passen.
Aha, bedankt voor het speurwerk.
>>>Het zou natuurlijk heel goed kunnen dat die router nu gewoon helemaal geen
>>>ttl exceeded meer stuurt.
>>
>>Of een andere router ergens filtert pakketjes met source IP in de
>>10.0.0.0/8 range eruit. Ik heb immers geen xs4all-adsl verbinding, en de
>>OP wel IIRC. Ik kom dus een aantal routers tegen die de OP niet tegen
>>komt.
>
>Dat is zeker ook mogelijk. Hoewel het me minder waarschijnlijk lijkt
>binnen het xs4all netwerk zelf. Dat is typisch iets om alleen aan
>de edge van een netwerk te doen.
>(je had het toch ook van xs1 geprobeerd ? )
Ack. Vanaf xs1 zie ik hetzelfde gedrag als van buiten xs4all.
Misschien wordt dit gefilterd op de router(s?) die het mxstream net aan
de rest van xs4all knopen, mxstream1.pbw.xs4all.net lijkt me wel een
voor de hand liggende router.
--
Maurice