Salt la conținut

SUBIECTE NOI
« 1 / 5 »
RSS
samsung Xcover 5 Nu mai vrea

Recomandare serviciu / firma recu...

La mulți ani @Piniuli!

Pret inghetata corso kaufland?
 La multi ani @Constantin si Elena...

La mulți ani @Ion_Bumbu!

Obiecte vechi și inutile car...

Mentenanta Acoperis
 Cheder deteriorat , zgariat, cum ...

Laptop HP 15-AF001NQ, AMD E1-6015...

Blat de bucatarie lungime 4,60 m

Termostat incalzire si racire
 Configurare retea cu modem Vodafo...

Curtea Penala Internationala soli...

Sunt obligate bancile sa opteze p...

Pensie anticipata partiala cu cer...
 

Problema traceroute/mtr

- - - - -
Ultima postare: nov 18 2018 14:34, Inițiat de Xpicolo , nov 14 2018 16:34  
  ·  
  • Vă rugăm să vă autentificați pentru a răspunde
32 răspunsuri în acest subiect

#19
Xpicolo
Publicat: 15 noiembrie 2018 - 14:07

Xpicolo

    Junior Member

  • Grup: Junior Members
  • Mesaje: 25
  • Înscris: 14.11.2018

View PostMembruAnonim, on 15 noiembrie 2018 - 13:57, said:

Un router RDS. Primul de altfel din reteaua lor plecand de la tine.

Ok. Dar de ce se comporta diferit accest router cand trasez din exterior ip-ul xx.xx.xx.100 fata de ip-ul meu xx.xx.xx.101?
Ruta e aceeasi.
De aceea intrebam de hops 5 (???) din a doua trasare.

LE. Am inteles ce vrei sa spui, Posibil ca acel router sa nu fie folosit cand pack merge catre xx.100

Totusi problema ramane.

Editat de Xpicolo, 15 noiembrie 2018 - 14:11.

#20
MembruAnonim
Publicat: 15 noiembrie 2018 - 15:29

MembruAnonim

    MembruAnonim

  • Grup: Banned
  • Mesaje: 399.554
  • Înscris: 08.10.2015

View PostXpicolo, on 15 noiembrie 2018 - 14:07, said:

LE. Am inteles ce vrei sa spui, Posibil ca acel router sa nu fie folosit cand pack merge catre xx.100
E folosit. Doar anunta niste agegate nu anunta /32-uri. O sa fac niste teste cand ajung acasa unde am conexiune de la RDS.

#21
MembruAnonim
Publicat: 15 noiembrie 2018 - 20:51

MembruAnonim

    MembruAnonim

  • Grup: Banned
  • Mesaje: 399.554
  • Înscris: 08.10.2015
Am testat si la mine nu se manifesta situatia de mai sus:
HOST: Timberwolf				  Loss%   Snt   Last   AVG  Best  Wrst StDev
  1.|-- 192.168.100.1			 40.0%	10	0.4   0.4   0.3   0.5   0.0
  2.|-- 10.0.0.1				  40.0%	10	1.1   1.1   0.9   1.7   0.3
  3.|-- 172.19.209.1			   0.0%	10	1.2   1.2   1.0   1.7   0.2
  4.|-- 10.220.132.8			   0.0%	10   16.4  16.8  16.4  17.2   0.2
  5.|-- 213.154.130.234			0.0%	10   36.1  45.7  36.1  57.0   7.1
  6.|-- 74.125.242.225			 0.0%	10   15.4  15.2  14.8  15.5   0.2
  7.|-- 72.14.239.195			  0.0%	10   16.5  16.7  16.3  17.2   0.3
  8.|-- 172.217.16.110			 0.0%	10   17.1  17.9  17.1  19.0   0.5
Eu tot am vaga impresie ca e de la MPLS ce se petrece acolo dar nu am cum sa confirm acest lucru.

#22
Xpicolo
Publicat: 16 noiembrie 2018 - 08:31

Xpicolo

    Junior Member

  • Grup: Junior Members
  • Mesaje: 25
  • Înscris: 14.11.2018

View Postogo, on 15 noiembrie 2018 - 09:29, said:

Toate echipamentele intermediare nu fac decrement la TTL. Si nu le vezi. Dar e foarte anormala chestia asta.

Am mai studiat putin.
Si cred ca asta se intampla:
Primul router din reteua rds modifica TTL la o valoare mare,
astfel incat celelalte rutere nu au cum sa raspunda cu ICMP TTL expires.

Ati mai intalnit asa ceva?

LE. Cam ciudat ca cineva sa fie interesat sa nu vezi prin ce echipamente treci. Nu?
Cred ca este echipamentul din hop-ul 5 cand dau trace din exterior. (din postul #17)

Editat de Xpicolo, 16 noiembrie 2018 - 08:42.

#23
MembruAnonim
Publicat: 16 noiembrie 2018 - 09:12

MembruAnonim

    MembruAnonim

  • Grup: Banned
  • Mesaje: 399.554
  • Înscris: 08.10.2015
Nop. RDS nu fac astfel de operatiuni.

#24
Danut Ianc
Publicat: 17 noiembrie 2018 - 09:25

Danut Ianc

    Member

  • Grup: Members
  • Mesaje: 537
  • Înscris: 03.11.2003
şi eu sunt tot pe fo de la rds... drept este ca este un ip static. dar traceroute arata normal:

traceroute to google.ro (216.58.209.163), 30 hops max, 60 byte packets
1  gateway (192.168.23.1)  1.159 ms  1.169 ms  1.227 ms
2  10.0.0.1 (10.0.0.1)  2.665 ms  2.786 ms  2.673 ms
3  * 10.30.4.129 (10.30.4.129)  4.557 ms  4.150 ms
4  static-10-220-134-188.rdsnet.ro (10.220.134.188)  9.261 ms static-10-220-128-70.rdsnet.ro (10.220.128.70)  9.218 ms static-10-220-128-64.rdsnet.ro (10.220.128.64)  8.888 ms
5  213-154-130-234.rdsnet.ro (213.154.130.234)  10.199 ms  9.049 ms  10.531 ms
6  74.125.242.241 (74.125.242.241)  9.737 ms  8.089 ms  7.837 ms
7  66.249.94.123 (66.249.94.123)  9.197 ms  9.551 ms  7.969 ms
8  bud02s21-in-f163.1e100.net (216.58.209.163)  10.216 ms  10.450 ms  10.126 ms

#25
Xpicolo
Publicat: 17 noiembrie 2018 - 11:03

Xpicolo

    Junior Member

  • Grup: Junior Members
  • Mesaje: 25
  • Înscris: 14.11.2018
Am pus tcpdump -vvv intr-o alta fereastra. Asa arata un mtr -r -c 1 google.com in tcpdump.

10:53:52.132746 IP ttl 1   proto ICMP 192.168.0.233 > prg02s12-in-f14.1e100.net: ICMP echo request
10:53:52.133451 IP ttl 128 proto ICMP 192.168.0.1 > 192.168.0.233: ICMP time exceeded

10:53:52.232847 IP ttl 2   proto ICMP 192.168.0.233 > prg02s12-in-f14.1e100.net: ICMP echo request
10:53:52.249739 IP ttl 128 proto ICMP prg02s12-in-f14.1e100.net > 192.168.0.233: ICMP echo reply

10:53:52.332950 IP ttl 3   proto ICMP 192.168.0.233 > prg02s12-in-f14.1e100.net: ICMP echo request
10:53:52.351632 IP ttl 128 proto ICMP prg02s12-in-f14.1e100.net > 192.168.0.233: ICMP echo reply

Eu sunt 192.168.0.233 iar 192.168.0.1 este routerul Netis WF2419 din locatie.
Interesant, nu?

#26
MembruAnonim
Publicat: 17 noiembrie 2018 - 11:41

MembruAnonim

    MembruAnonim

  • Grup: Banned
  • Mesaje: 399.554
  • Înscris: 08.10.2015
Dupa cum am spus e ceva MPLS implicat acolo dar nu stiu de ce nu apar routerele de border ale celor de operatori, RDS si Google in trace.

LE: Pe IPv6 se comporta la fel?

PS: In ce zona a tarii esti? Ca  in Bucuresti nu se manifesta acest comportament cel putin pe zona in care ma aflu eu.

#27
Xpicolo
Publicat: 17 noiembrie 2018 - 11:59

Xpicolo

    Junior Member

  • Grup: Junior Members
  • Mesaje: 25
  • Înscris: 14.11.2018
In Pitesti este IP-ul.
Nu am cum sa testez V6.
Uite ce test am mai facut:

In alta locatie (IP2) din tara am dat tcpdump pentru pack care vin de la IP1 (cu problema).

Din locatia cu IP1 am dat tcptraceroute  IP2. (tcp pentru ca nu pot sa trec cu ICMP prin routerul din locatia IP2).
Packetele ajung cu TTL=125.

apoi am dat tot din IP1 tcptraceroute -f 30 IP2 ( ttl initial 30)
Packetele ajung tot cu TTL=125.

Nu cred ca este MPLS implicat.
Eu zic ca sigur este modificare de TTL la primul router provider: orice TTL initial pun, la destinatie am TTL= 125. (banuiesc ca 128 pune routerul pricinos, si se scad inca 3 hopuri pina la IP2).
(125 in cazul in care am facut tcpdump in IP2 , cand am ales alta destinatie si am pus dump acolo am de exemplu mereu TTL=122)

Editat de Xpicolo, 17 noiembrie 2018 - 12:22.

#28
KyKyKyKy
Publicat: 17 noiembrie 2018 - 12:02

KyKyKyKy

    Guru Member

  • Grup: Senior Members
  • Mesaje: 23.199
  • Înscris: 18.04.2008

View PostMembruAnonim, on 17 noiembrie 2018 - 11:41, said:

Dupa cum am spus e ceva MPLS implicat acolo dar nu stiu de ce nu apar routerele de border ale celor de operatori, RDS si Google in trace.

LE: Pe IPv6 se comporta la fel?

PS: In ce zona a tarii esti? Ca  in Bucuresti nu se manifesta acest comportament cel putin pe zona in care ma aflu eu.

Și la mine pierde pachete ICMP imediat după ce iese din Kaon. Am și schimbat cablurile degeaba.

#29
Xpicolo
Publicat: 17 noiembrie 2018 - 12:08

Xpicolo

    Junior Member

  • Grup: Junior Members
  • Mesaje: 25
  • Înscris: 14.11.2018

View PostKyKyKyKy, on 17 noiembrie 2018 - 12:02, said:

Și la mine pierde pachete ICMP imediat după ce iese din Kaon. Am și schimbat cablurile degeaba.
Nu cred are legatura cu problema expusa.
Am explicat mai sus. La mine nu apar stelute * * * la hops intermediare sau packete pierdute.

Editat de Xpicolo, 17 noiembrie 2018 - 12:20.

#30
MembruAnonim
Publicat: 17 noiembrie 2018 - 12:47

MembruAnonim

    MembruAnonim

  • Grup: Banned
  • Mesaje: 399.554
  • Înscris: 08.10.2015
@Xpicolo: Da-mi pe PM IP-ul tau sa vad daca pot face niste verificari. Sigur nu e de la RDS, nu au de ce sa modifice TTL la pachetele clientilor.  Doar daca e ceva wrong pe un router.

#31
Danut Ianc
Publicat: 18 noiembrie 2018 - 10:20

Danut Ianc

    Member

  • Grup: Members
  • Mesaje: 537
  • Înscris: 03.11.2003
Şi eu zic că undeva este o prb. cu un router.
Investigaţia este una academică doar atâta vreme cât nu afectează cu nimic viteza conexiunii...

#32
Xpicolo
Publicat: 18 noiembrie 2018 - 10:50

Xpicolo

    Junior Member

  • Grup: Junior Members
  • Mesaje: 25
  • Înscris: 14.11.2018
Nu pare sa afecteaze functionarea internetului.
Poate doar daca incerc sa dau de un IP inexistent (rutat gresit de fapt) iar pe traseu abia dupa 128 de hops, un router va face drop la packet si va trimite ICMP time exceeded ....

La mine s-a cam terminat stiinta.

#33
MembruAnonim
Publicat: 18 noiembrie 2018 - 14:34

MembruAnonim

    MembruAnonim

  • Grup: Banned
  • Mesaje: 399.554
  • Înscris: 08.10.2015
Me bad. Dap pare ca e vorba de un echipament care modifica TTL-ul la ceva != de ce e setat de catre aplicatie / host. Posibil sa fie ceva eronat pe ONT daca e folosit ca si CPE sau pe GW-ul din LAN:
Traceroute in dns google:
┌(ghost)─(Timberwolf)─(4.19.2-arch1-1-ARCH)
└─(~)─(3 files, 160KB)─ $ traceroute 8.8.8.8
traceroute to 8.8.8.8 (8.8.8.8), 30 hops max, 60 byte packets
1  google-public-dns-a.google.com (8.8.8.8)  14.082 ms  14.746 ms  15.193 ms
Regula iptables care modifica TTL la 128 daca destinatia este dns google:
Chain POSTROUTING (policy ACCEPT 67 packets, 7578 bytes)
pkts bytes target	 prot opt in	 out	 source			   destination		
   20  1296 TTL		all  --  *	  *	   0.0.0.0/0			8.8.8.8			  TTL set to 128
tcpdump laptop, test facut cu modificarea TTL-ului pe router si destinatie 8.8.4.4:
2018-11-18 14:23:44.928289 IP (tos 0x0, ttl 6, id 7388, offset 0, flags [none], proto UDP (17), length 60)
	192.168.100.3.53117 > 8.8.4.4.33449: [udp sum ok] UDP, length 32
2018-11-18 14:23:44.939914 IP (tos 0x4, ttl 121, id 52813, offset 0, flags [none], proto ICMP (1), length 88)
	8.8.4.4 > 192.168.100.3: ICMP 8.8.4.4 udp port 33436 unreachable, length 68
		IP (tos 0x80, ttl 248, id 7375, offset 0, flags [none], proto UDP (17), length 60)
	192.168.100.3.39810 > 8.8.4.4.33436: [udp sum ok] UDP, length 32
Scuze, aveam impresia ca e de la MPLS desi nu intelegeam de ce se comporta cum se comporta. Insa da e de la TTL. Ceva modifica TTL-ul, intrebarea este cum e topologia in locatie? ONT RDS - router local - PC / laptop / server? sau ONT RDS CPE - PC / laptop / server?

Daca e un router in locatie in afara de ONT-ul RDS atunci acel router modifica TTL-ul la pachete.
Trace in 8.8.8.8
┌(ghost)─(Timberwolf)─(4.19.2-arch1-1-ARCH)
└─(~)─(3 files, 160KB)─ $ traceroute 8.8.8.8
traceroute to 8.8.8.8 (8.8.8.8), 30 hops max, 60 byte packets
1  _gateway (192.168.100.1)  1.092 ms  0.974 ms  0.919 ms
2  google-public-dns-a.google.com (8.8.8.8)  15.739 ms  14.661 ms  15.053 ms
Firewall pe laptop:
┌(ghost)─(Timberwolf)─(4.19.2-arch1-1-ARCH)
└─(~)─(3 files, 160KB)─ $ sudo iptables -t mangle -vnL
Chain PREROUTING (policy ACCEPT 79 packets, 7741 bytes)
pkts bytes target	 prot opt in	 out	 source			   destination		
	0	 0 DROP	   all  --  *	  *	   0.0.0.0/0			0.0.0.0/0			ctstate INVALID
	0	 0 DROP	   tcp  --  *	  *	   0.0.0.0/0			0.0.0.0/0			tcp flags:!0x17/0x02 ctstate NEW
	0	 0 DROP	   tcp  --  *	  *	   0.0.0.0/0			0.0.0.0/0			ctstate NEW tcpmss match !536:65535
	0	 0 DROP	   tcp  --  *	  *	   0.0.0.0/0			0.0.0.0/0			tcp flags:0x3F/0x00
	0	 0 DROP	   tcp  --  *	  *	   0.0.0.0/0			0.0.0.0/0			tcp flags:0x03/0x03
	0	 0 DROP	   tcp  --  *	  *	   0.0.0.0/0			0.0.0.0/0			tcp flags:0x06/0x06
	0	 0 DROP	   tcp  --  *	  *	   0.0.0.0/0			0.0.0.0/0			tcp flags:0x03/0x03
	0	 0 DROP	   tcp  --  *	  *	   0.0.0.0/0			0.0.0.0/0			tcp flags:0x05/0x05
	0	 0 DROP	   tcp  --  *	  *	   0.0.0.0/0			0.0.0.0/0			tcp flags:0x11/0x01
	0	 0 DROP	   tcp  --  *	  *	   0.0.0.0/0			0.0.0.0/0			tcp flags:0x30/0x20
	0	 0 DROP	   tcp  --  *	  *	   0.0.0.0/0			0.0.0.0/0			tcp flags:0x11/0x01
	0	 0 DROP	   tcp  --  *	  *	   0.0.0.0/0			0.0.0.0/0			tcp flags:0x18/0x08
	0	 0 DROP	   tcp  --  *	  *	   0.0.0.0/0			0.0.0.0/0			tcp flags:0x3F/0x3F
	0	 0 DROP	   tcp  --  *	  *	   0.0.0.0/0			0.0.0.0/0			tcp flags:0x3F/0x00
	0	 0 DROP	   tcp  --  *	  *	   0.0.0.0/0			0.0.0.0/0			tcp flags:0x3F/0x29
	0	 0 DROP	   tcp  --  *	  *	   0.0.0.0/0			0.0.0.0/0			tcp flags:0x3F/0x2B
	0	 0 DROP	   tcp  --  *	  *	   0.0.0.0/0			0.0.0.0/0			tcp flags:0x3F/0x37
	0	 0 DROP	   all  -f  *	  *	   0.0.0.0/0			0.0.0.0/0		  
Chain INPUT (policy ACCEPT 79 packets, 7741 bytes)
pkts bytes target	 prot opt in	 out	 source			   destination		
Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target	 prot opt in	 out	 source			   destination		
Chain OUTPUT (policy ACCEPT 99 packets, 14223 bytes)
pkts bytes target	 prot opt in	 out	 source			   destination		
Chain POSTROUTING (policy ACCEPT 99 packets, 14223 bytes)
pkts bytes target	 prot opt in	 out	 source			   destination
Firewall pe router:
root@Takeyuuki:~# iptables -vnL -t mangle
Chain PREROUTING (policy ACCEPT 199 packets, 23087 bytes)
pkts bytes target	 prot opt in	 out	 source			   destination		
Chain INPUT (policy ACCEPT 40 packets, 2864 bytes)
pkts bytes target	 prot opt in	 out	 source			   destination		
Chain FORWARD (policy ACCEPT 150 packets, 19683 bytes)
pkts bytes target	 prot opt in	 out	 source			   destination		
	0	 0 TCPMSS	 tcp  --  *	  eth1.2  0.0.0.0/0			0.0.0.0/0			tcp flags:0x06/0x02 /* !fw3: Zone wan MTU fixing */ TCPMSS clamp to PMTU
   62  3720 TCPMSS	 tcp  --  *	  pppoe-wan  0.0.0.0/0			0.0.0.0/0			tcp flags:0x06/0x02 /* !fw3: Zone wan MTU fixing */ TCPMSS clamp to PMTU
Chain OUTPUT (policy ACCEPT 38 packets, 5095 bytes)
pkts bytes target	 prot opt in	 out	 source			   destination		
Chain POSTROUTING (policy ACCEPT 188 packets, 24778 bytes)
pkts bytes target	 prot opt in	 out	 source			   destination		
   95 14085 TTL		all  --  *	  pppoe-wan  0.0.0.0/0			0.0.0.0/0			TTL set to 255
Se vede ultima linie care modifica TTL-ul la pachetele ce ies pe interfata pppoe-wan la 255. De asemenea mai sus trace-ul este identic ca al tau, adica vad doar router-ul meu si ultimul hop.

Anunturi

Chirurgia cranio-cerebrală minim invazivă Chirurgia cranio-cerebrală minim invazivă

Tehnicile minim invazive impun utilizarea unei tehnologii ultramoderne.

Endoscoapele operatorii de diverse tipuri, microscopul operator dedicat, neuronavigația, neuroelectrofiziologia, tehnicile avansate de anestezie, chirurgia cu pacientul treaz reprezintă armamentarium fără de care neurochirurgia prin "gaura cheii" nu ar fi posibilă. Folosind tehnicile de mai sus, tratăm un spectru larg de patologii cranio-cerebrale.

www.neurohope.ro
Înapoi la Networking

▶ Utilizatori activi: 1

0 membri, 1 vizitatori, 0 utilizatori anonimi

  1. Forumul Softpedia
  2. → Professional Zone
  3. → Networking
Forumul Softpedia foloseste "cookies" pentru a imbunatati experienta utilizatorilor Accept
Pentru detalii si optiuni legate de cookies si datele personale, consultati Politica de utilizare cookies si Politica de confidentialitate