Re: major packet loss at hot server
It seems like a lame excuse. tcptraceroute is to bypass firewall. Normally you would run traceroute. Which suggest they might block a larger range of ports. Nmap would show all the ranges are blocked. BTW, tell them to use ZombieZapper against DDOS. http://www.suggestafix.com/index.php?showtopic=1895 Here are the results I ran on netvision.net.il tcptraceroute netvision.net.il Selected device eth2, address 10.0.0.5, port 34527 for outgoing packets Tracing the path to netvision.net.il (62.0.18.221) on TCP port 80 (http), 30 hops max 1 10.0.0.1 1.136 ms 1.022 ms 1.022 ms 2 10.163.160.1 11.996 ms 9.137 ms 9.063 ms 3 172.18.2.14 9.291 ms 10.326 ms 11.478 ms 4 172.17.0.169 11.413 ms 14.965 ms 10.424 ms 5 CORE-1.PT-SUSITA-gig4-12.012.net.il (212.199.18.133) 200.404 ms CORE-1.PT-SUSITA-gig4-2.012.net.il (212.199.170.18) 167.329 ms 106.137 ms 6 CORE-1.MRK-tengig7-3.012.net.il (212.199.6.82) 10.169 ms 13.232 ms 11.085 ms 7 * BB.MR-01-gig3-8.012.net.il (212.199.19.217) 12.954 ms 10.638 ms 8 gi0-1.peersw01.ptk.nv.net.il (212.143.12.50) 9.514 ms 11.738 ms 10.703 ms 9 * vl101.coresw1.ptk.nv.net.il (212.143.10.1) 11.112 ms 10.815 ms 10 * ge1-5.coresw1.hfa.nv.net.il (212.143.12.93) 12.784 ms 14.589 ms 11 po41.srvc4.hfa.nv.net.il (212.143.8.50) 14.701 ms 13.859 ms 13.076 ms 12 * * * 13 nvb.netvision.net.il (62.0.18.221) [open] 14.049 ms 28.000 ms 58.943 ms -- traceroute netvision.net.il traceroute to netvision.net.il (62.0.18.221), 30 hops max, 40 byte packets 1 10.0.0.1 (10.0.0.1) 1.963 ms 3.321 ms 4.583 ms 2 10.163.160.1 (10.163.160.1) 14.831 ms 18.463 ms 22.821 ms 3 172.18.2.14 (172.18.2.14) 29.602 ms 33.470 ms 38.706 ms 4 172.17.0.169 (172.17.0.169) 41.919 ms 45.026 ms 50.168 ms 5 CORE-1.PT-SUSITA-gig4-12.012.net.il (212.199.18.133) 53.678 ms * * 6 CORE-1.MRK-tengig7-3.012.net.il (212.199.6.82) 65.499 ms 9.560 ms 12.288 ms 7 BB.MR-01-gig3-8.012.net.il (212.199.19.217) 16.122 ms 20.342 ms * 8 gi0-1.peersw01.ptk.nv.net.il (212.143.12.50) 28.201 ms 32.621 ms 36.436 ms 9 * vl101.coresw1.ptk.nv.net.il (212.143.10.1) 45.054 ms 49.730 ms 10 ge1-5.coresw1.hfa.nv.net.il (212.143.12.93) 54.835 ms 59.280 ms 63.632 ms 11 po41.srvc4.hfa.nv.net.il (212.143.8.50) 65.898 ms 57.562 ms 57.864 ms 12 * * * 13 * * * 14 * * * 15 * * * 16 * * * 17 * * * 18 * * * 19 * * * 20 * * * 21 * * * 22 * * * 23 * * * 24 * * * 25 * * * 26 * * * 27 * * * 28 * * * 29 * * * 30 * * * - mtr -r -c 10 www.netvision.net.il HOST: carin Loss% Snt Last Avg Best Wrst StDev 1. 10.0.0.1 0.0%101.1 1.1 1.1 1.7 0.2 2. 10.163.160.1 0.0%107.4 8.6 6.9 17.6 3.2 3. 172.18.2.14 0.0%10 11.3 10.5 9.8 11.3 0.5 4. 172.17.0.169 0.0%10 26.8 13.9 9.6 26.8 5.3 5. CORE-1.PT-SUSITA-gig4-1.012. 10.0%10 150.8 43.6 10.6 150.8 54.5 6. CORE-1.MRK-tengig7-3.012.net 0.0%10 11.8 19.4 10.1 81.0 21.8 7. BB.MR-01-gig3-8.012.net.il 30.0%10 10.9 13.4 10.9 21.0 3.5 8. gi0-1.peersw01.ptk.nv.net.il 0.0%10 20.1 14.5 10.6 23.4 5.3 9. vl101.coresw1.ptk.nv.net.il 20.0%10 11.3 13.2 10.3 21.6 3.9 10. ge1-5.coresw1.hfa.nv.net.il 20.0%10 14.3 16.1 12.9 21.6 2.8 11. po41.srvc4.hfa.nv.net.il 0.0%10 11.8 13.8 11.8 24.3 3.8 12. ??? 100.0100.0 0.0 0.0 0.0 0.0 On Fri, Apr 25, 2008 at 1:46 AM, Michael Tewner <[EMAIL PROTECTED]> wrote: > BTW, > > Top Netvision support people have claimed that it's an anti-DDOS > mechanism > > But that seems strange - I mean, filtering legitimate TCP web requests > (tcptracroute) - 20% of the packets over just a few requests? > > Can anyone on Netvision try a simple web request with a sniffer and > see if there are any packet re-requests? (I would, but I'm our of > town) > > > > > On Sat, Apr 5, 2008 at 8:51 PM, Michael Tewner <[EMAIL PROTECTED]> wrote: > > Yeah - I seem to be getting 20-30% loss on TCP packets to www.cnn.com > > on the same router that was dropping the ICMP packets. (#4 below) > > > > Selected device eth0, address 10.1.1.193, port 38669 for outgoing packets > > Tracing the path to www.cnn.com (64.236.29.120) on TCP port 80 (www), > > 30 hops max > > 1 10.1.1.254 0.514 ms 0.974 ms 0.985 ms > > 2 X 0.986 ms 0.988 ms 0.983 ms > > 3 xxx.ser.netvision.net.il () 9.403 ms 11.062 ms 12.373 ms > > 4 vl100.coresw2.hfa.nv.net.il (212.143.8.69) 13.803 ms * 10.785 ms > > 5 ge0-1.gw2.hfa.nv.net.il (212.143.8.212) 9.913 ms 9.894 ms 26.442 ms > > 6 pos1-0.brdr1.nyc.nv.net.il (212.143.12.13) 255.455 ms 247.516 ms > > > > > > On Fri, Apr 4, 2008 at 11:30 PM, Amos Shapira <[EMAIL PR
Re: major packet loss at hot server
BTW, Top Netvision support people have claimed that it's an anti-DDOS mechanism But that seems strange - I mean, filtering legitimate TCP web requests (tcptracroute) - 20% of the packets over just a few requests? Can anyone on Netvision try a simple web request with a sniffer and see if there are any packet re-requests? (I would, but I'm our of town) On Sat, Apr 5, 2008 at 8:51 PM, Michael Tewner <[EMAIL PROTECTED]> wrote: > Yeah - I seem to be getting 20-30% loss on TCP packets to www.cnn.com > on the same router that was dropping the ICMP packets. (#4 below) > > Selected device eth0, address 10.1.1.193, port 38669 for outgoing packets > Tracing the path to www.cnn.com (64.236.29.120) on TCP port 80 (www), > 30 hops max > 1 10.1.1.254 0.514 ms 0.974 ms 0.985 ms > 2 X 0.986 ms 0.988 ms 0.983 ms > 3 xxx.ser.netvision.net.il () 9.403 ms 11.062 ms 12.373 ms > 4 vl100.coresw2.hfa.nv.net.il (212.143.8.69) 13.803 ms * 10.785 ms > 5 ge0-1.gw2.hfa.nv.net.il (212.143.8.212) 9.913 ms 9.894 ms 26.442 ms > 6 pos1-0.brdr1.nyc.nv.net.il (212.143.12.13) 255.455 ms 247.516 ms > > > On Fri, Apr 4, 2008 at 11:30 PM, Amos Shapira <[EMAIL PROTECTED]> wrote: > > On Fri, Apr 4, 2008 at 10:35 PM, Michael Tewner <[EMAIL PROTECTED]> wrote: > > > > > Just talked to Netvision Asakim support - > > > He was knowlegable - ran `mtr` on his workstation and saw the packet > > loss. > > > > > > He explained that "there is no problem" and that the core routers are > > > dropping the ping packets based on the amount of load on the router. > > > He explained that the router should only be dropping ICMP packets. > > > > I didn't read all the messages on this thread but maybe if you could run the > > same tests with tcptraceroute you could see weather the packet drop happens > > to TCP packets or not? > > > > --Amos > > > > > = To unsubscribe, send mail to [EMAIL PROTECTED] with the word "unsubscribe" in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
Re: major packet loss at hot server
I will eventually. But right now I have contract up to end of september. On Fri, Apr 4, 2008 at 11:03 AM, Jonathan Ben Avraham <[EMAIL PROTECTED]> wrote: > Hi Sara, > I wonder if you aren't better off just getting an ADSL line and switching > service providers. > > - yba > > > On Thu, 3 Apr 2008, sara fink wrote: > > > > Date: Thu, 3 Apr 2008 16:14:51 +0300 > > > > From: sara fink <[EMAIL PROTECTED]> > > To: Jonathan Ben Avraham <[EMAIL PROTECTED]> > > Cc: ILUG > > > > > > > > Subject: Re: major packet loss at hot server > > > > I don't have a machine that runs tcpdump. Plus it needs root access. > > I wonder if I create one of these free shells that are out there, will > > it help? tcpdump will work without root as well? > > > > Last time I talked with 012 and hot, hot managed to dissconnect me > > completely. The support from hot was nice, but told me to unplug the > > cable and replug again. And from then I don't have internet at all. > > The /etc/resolv.conf is correct. I waited for hot to call me back, > > but it didn't happen. Since now I am not at home, I can't check > > anything. When I will return back will have to shout at them to > > connect me to internet. > > > > All the time when I ran mtr google.com (outside) there was the packet > > loss. The loss is in the 2nd and 3rd hop. first is the router of hot ( > > I have another router at home but last time I didn't use it for the > > purpose of checking and proving hot it's not my router fault), then > > the switch with 80% packet loss and 3rd another switch/router of hot > > with 20% packet loss. 2nd hop is bgp. port 179 open. 3rd switch/router > > has port 49 open (tacacs). AND from my scannings, I pass only through > > 1 switch which has bgp open. > > > > I have access to a machine, but not as root. I can run there > > traceroute. And will definitely run from there mtr to machine A and > > traceroute from there to my machine. Are there any others programs > > that I can run as simple user? > > > > I can't understand them, if I pass through such a switch, where they > > close all the ports and allow only 179, 646, and all udp ports are > > closed what kind of internet is that. It castrates all the concept of > > internet. > > > > > > BTW, I want to ask a legal question. I will finally submit a complaint > > through tluna.co.il, but I don't know if it's legal to submit the ip > > numbers. A lot of people are using these switches, and people don't > > know about this problem. > > > > Thanks in advance for all the help. > > > > > > > > > > Hi Sara, > > > If you have access to a machine somewhere that runs tcpdump, then use > hping > > > commands from your MPLS to that machine in order to see if the packet > loss > > > is occuring on the outgoing or on the return trip. That is, hping out 50 > > > packets. Check to see how many of those get to the target and then check > to > > > see how many of those that got to the target got back to you. If there > is a > > > more packet loss on the return leg than on the outgoing leg I would > suspect > > > a routing problem. If there is more loss on the early hops of the > outgoing > > > leg then I suspect either congestion or physical transmission problems > with > > > the final repeater or router. > > > > > > > > > > > > > > > > > How do I use different routing? Any idea of which ips should I put? > > > > > > > > > > > > > > You can't if you dont have a static IP. Well, I guess that you could > check > > > the routing to your first hop out that has a routed IP address by using > > > various foreign traceroute web pages. If the routing problem is low > enough > > > and there is only one BGP router through which your packets can pass, > then > > > you might not be able to see the routing problem. I was able to see the > > > routing problem that I had at Netvision last week because I was able to > > > access my line from different Netvision border routers because Netvision > is > > > pretty big. It was really clear that one particular border router was > > > getting bad information from an internal router. > > > > > > > > > > > > > I know someone who is very nice at 012. She belongs to service dep, > > > > and she promissed to send someone who knows well
Re: major packet loss at hot server
I'm in conversation with Netvision about this issue - sending diagnostic information. On Sat, Apr 5, 2008 at 2:14 PM, Michael Tewner <[EMAIL PROTECTED]> wrote: > Wow - > A post from December 2006 in a gaming forum shows major packet loss > from the same router: > http://forums.guru3d.com/showthread.php?t=208330 > > C:\Documents and Settings\Administrator>tracert ablpls-01-02.planetside.com > > Tracing route to ablpls-01-02.planetside.com [199.108.204.34] > over a maximum of 30 hops: > > 1 18 ms 19 ms 19 ms lo0.lns13.hfa.nv.net.il [212.143.205.170] > 2 19 ms 19 ms 19 ms vl102.agr01.hfa.netvision.net.il [212.143.210.25 > 3] > 3 * * 19 ms vl100.coresw2.hfa.nv.net.il [212.143.8.69] > 4 28 ms 19 ms 19 ms ge5-0.core2.hfa.nv.net.il [212.143.8.210] > 5 99 ms 99 ms 99 ms pos2-3.brdr1.lnd.nv.net.il [212.143.12.57] > 6 108 ms 99 ms 99 ms ge9-1.br02.ldn01.pccwbtn.net [63.218.52.13] > 7 * * * Request timed out. > 8 179 ms 179 ms 179 ms vl46.ashaens-1.sonyonline.net [64.37.144.177] > 9 189 ms 179 ms 169 ms ablpls-01-02.planetside.com [199.108.204.34] > > > > > On Sat, Apr 5, 2008 at 9:18 PM, Jonathan Ben Avraham <[EMAIL PROTECTED]> > wrote: > > Hi Michael et al, > > I have been watching vl100.coresw2.hfa.nv.net.il for the past month for a > > customer of mine and have seem roughly the same TCP packet loss going into > > it on port 80. (It turned out that the customer's problem was not that but > a > > configuration error on a different, internal Netvision router. FYI, > > > > - yba > > > > > > On Sat, 5 Apr 2008, Michael Tewner wrote: > > > > > > > Date: Sat, 5 Apr 2008 20:51:06 +0300 > > > From: Michael Tewner <[EMAIL PROTECTED]> > > > To: Amos Shapira <[EMAIL PROTECTED]> > > > Cc: IGLU Mailing list > > > > > > Subject: Re: major packet loss at hot server > > > > > > > > > > > > > > > Yeah - I seem to be getting 20-30% loss on TCP packets to www.cnn.com > > > on the same router that was dropping the ICMP packets. (#4 below) > > > > > > Selected device eth0, address 10.1.1.193, port 38669 for outgoing packets > > > Tracing the path to www.cnn.com (64.236.29.120) on TCP port 80 (www), > > > 30 hops max > > > 1 10.1.1.254 0.514 ms 0.974 ms 0.985 ms > > > 2 X 0.986 ms 0.988 ms 0.983 ms > > > 3 xxx.ser.netvision.net.il () 9.403 ms 11.062 ms 12.373 > ms > > > 4 vl100.coresw2.hfa.nv.net.il (212.143.8.69) 13.803 ms * 10.785 ms > > > 5 ge0-1.gw2.hfa.nv.net.il (212.143.8.212) 9.913 ms 9.894 ms 26.442 ms > > > 6 pos1-0.brdr1.nyc.nv.net.il (212.143.12.13) 255.455 ms 247.516 ms > > > > > > On Fri, Apr 4, 2008 at 11:30 PM, Amos Shapira <[EMAIL PROTECTED]> > > wrote: > > > > > > > On Fri, Apr 4, 2008 at 10:35 PM, Michael Tewner <[EMAIL PROTECTED]> > > wrote: > > > > > > > > > > > > > Just talked to Netvision Asakim support - > > > > > He was knowlegable - ran `mtr` on his workstation and saw the packet > > > > > > > > > loss. > > > > > > > > > > > > > > He explained that "there is no problem" and that the core routers are > > > > > dropping the ping packets based on the amount of load on the router. > > > > > He explained that the router should only be dropping ICMP packets. > > > > > > > > > > > > > I didn't read all the messages on this thread but maybe if you could > run > > the > > > > same tests with tcptraceroute you could see weather the packet drop > > happens > > > > to TCP packets or not? > > > > > > > > --Amos > > > > > > > > > > > > > > > > > > > > > = > > > To unsubscribe, send mail to [EMAIL PROTECTED] with > > > the word "unsubscribe" in the message body, e.g., run the command > > > echo unsubscribe | mail [EMAIL PROTECTED] > > > > > > > > > > > > > -- > > > > EE 77 7F 30 4A 64 2E C5 83 5F E7 49 A6 82 29 BA~. .~ Tk Open > > Systems > > > =}ooO--U--Ooo{= > > - [EMAIL PROTECTED] - tel: +972.2.679.5364, http://www.tkos.co.il - > > > = To unsubscribe, send mail to [EMAIL PROTECTED] with the word "unsubscribe" in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
Re: major packet loss at hot server
Wow - A post from December 2006 in a gaming forum shows major packet loss from the same router: http://forums.guru3d.com/showthread.php?t=208330 C:\Documents and Settings\Administrator>tracert ablpls-01-02.planetside.com Tracing route to ablpls-01-02.planetside.com [199.108.204.34] over a maximum of 30 hops: 1 18 ms 19 ms 19 ms lo0.lns13.hfa.nv.net.il [212.143.205.170] 2 19 ms 19 ms 19 ms vl102.agr01.hfa.netvision.net.il [212.143.210.25 3] 3 * * 19 ms vl100.coresw2.hfa.nv.net.il [212.143.8.69] 4 28 ms 19 ms 19 ms ge5-0.core2.hfa.nv.net.il [212.143.8.210] 5 99 ms 99 ms 99 ms pos2-3.brdr1.lnd.nv.net.il [212.143.12.57] 6 108 ms 99 ms 99 ms ge9-1.br02.ldn01.pccwbtn.net [63.218.52.13] 7 * * * Request timed out. 8 179 ms 179 ms 179 ms vl46.ashaens-1.sonyonline.net [64.37.144.177] 9 189 ms 179 ms 169 ms ablpls-01-02.planetside.com [199.108.204.34] On Sat, Apr 5, 2008 at 9:18 PM, Jonathan Ben Avraham <[EMAIL PROTECTED]> wrote: > Hi Michael et al, > I have been watching vl100.coresw2.hfa.nv.net.il for the past month for a > customer of mine and have seem roughly the same TCP packet loss going into > it on port 80. (It turned out that the customer's problem was not that but a > configuration error on a different, internal Netvision router. FYI, > > - yba > > > On Sat, 5 Apr 2008, Michael Tewner wrote: > > > > Date: Sat, 5 Apr 2008 20:51:06 +0300 > > From: Michael Tewner <[EMAIL PROTECTED]> > > To: Amos Shapira <[EMAIL PROTECTED]> > > Cc: IGLU Mailing list > > > > Subject: Re: major packet loss at hot server > > > > > > > > > > Yeah - I seem to be getting 20-30% loss on TCP packets to www.cnn.com > > on the same router that was dropping the ICMP packets. (#4 below) > > > > Selected device eth0, address 10.1.1.193, port 38669 for outgoing packets > > Tracing the path to www.cnn.com (64.236.29.120) on TCP port 80 (www), > > 30 hops max > > 1 10.1.1.254 0.514 ms 0.974 ms 0.985 ms > > 2 X 0.986 ms 0.988 ms 0.983 ms > > 3 xxx.ser.netvision.net.il () 9.403 ms 11.062 ms 12.373 ms > > 4 vl100.coresw2.hfa.nv.net.il (212.143.8.69) 13.803 ms * 10.785 ms > > 5 ge0-1.gw2.hfa.nv.net.il (212.143.8.212) 9.913 ms 9.894 ms 26.442 ms > > 6 pos1-0.brdr1.nyc.nv.net.il (212.143.12.13) 255.455 ms 247.516 ms > > > > On Fri, Apr 4, 2008 at 11:30 PM, Amos Shapira <[EMAIL PROTECTED]> > wrote: > > > > > On Fri, Apr 4, 2008 at 10:35 PM, Michael Tewner <[EMAIL PROTECTED]> > wrote: > > > > > > > > > > Just talked to Netvision Asakim support - > > > > He was knowlegable - ran `mtr` on his workstation and saw the packet > > > > > > > loss. > > > > > > > > > > > He explained that "there is no problem" and that the core routers are > > > > dropping the ping packets based on the amount of load on the router. > > > > He explained that the router should only be dropping ICMP packets. > > > > > > > > > > I didn't read all the messages on this thread but maybe if you could run > the > > > same tests with tcptraceroute you could see weather the packet drop > happens > > > to TCP packets or not? > > > > > > --Amos > > > > > > > > > > > > > > > = > > To unsubscribe, send mail to [EMAIL PROTECTED] with > > the word "unsubscribe" in the message body, e.g., run the command > > echo unsubscribe | mail [EMAIL PROTECTED] > > > > > > > > -- > > EE 77 7F 30 4A 64 2E C5 83 5F E7 49 A6 82 29 BA~. .~ Tk Open > Systems > =}ooO--U--Ooo{= > - [EMAIL PROTECTED] - tel: +972.2.679.5364, http://www.tkos.co.il - > = To unsubscribe, send mail to [EMAIL PROTECTED] with the word "unsubscribe" in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
Re: major packet loss at hot server
Hi Michael et al, I have been watching vl100.coresw2.hfa.nv.net.il for the past month for a customer of mine and have seem roughly the same TCP packet loss going into it on port 80. (It turned out that the customer's problem was not that but a configuration error on a different, internal Netvision router. FYI, - yba On Sat, 5 Apr 2008, Michael Tewner wrote: Date: Sat, 5 Apr 2008 20:51:06 +0300 From: Michael Tewner <[EMAIL PROTECTED]> To: Amos Shapira <[EMAIL PROTECTED]> Cc: IGLU Mailing list Subject: Re: major packet loss at hot server Yeah - I seem to be getting 20-30% loss on TCP packets to www.cnn.com on the same router that was dropping the ICMP packets. (#4 below) Selected device eth0, address 10.1.1.193, port 38669 for outgoing packets Tracing the path to www.cnn.com (64.236.29.120) on TCP port 80 (www), 30 hops max 1 10.1.1.254 0.514 ms 0.974 ms 0.985 ms 2 X 0.986 ms 0.988 ms 0.983 ms 3 xxx.ser.netvision.net.il () 9.403 ms 11.062 ms 12.373 ms 4 vl100.coresw2.hfa.nv.net.il (212.143.8.69) 13.803 ms * 10.785 ms 5 ge0-1.gw2.hfa.nv.net.il (212.143.8.212) 9.913 ms 9.894 ms 26.442 ms 6 pos1-0.brdr1.nyc.nv.net.il (212.143.12.13) 255.455 ms 247.516 ms On Fri, Apr 4, 2008 at 11:30 PM, Amos Shapira <[EMAIL PROTECTED]> wrote: On Fri, Apr 4, 2008 at 10:35 PM, Michael Tewner <[EMAIL PROTECTED]> wrote: Just talked to Netvision Asakim support - He was knowlegable - ran `mtr` on his workstation and saw the packet loss. He explained that "there is no problem" and that the core routers are dropping the ping packets based on the amount of load on the router. He explained that the router should only be dropping ICMP packets. I didn't read all the messages on this thread but maybe if you could run the same tests with tcptraceroute you could see weather the packet drop happens to TCP packets or not? --Amos = To unsubscribe, send mail to [EMAIL PROTECTED] with the word "unsubscribe" in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED] -- EE 77 7F 30 4A 64 2E C5 83 5F E7 49 A6 82 29 BA~. .~ Tk Open Systems =}ooO--U--Ooo{= - [EMAIL PROTECTED] - tel: +972.2.679.5364, http://www.tkos.co.il - = To unsubscribe, send mail to [EMAIL PROTECTED] with the word "unsubscribe" in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
Re: major packet loss at hot server
Yeah - I seem to be getting 20-30% loss on TCP packets to www.cnn.com on the same router that was dropping the ICMP packets. (#4 below) Selected device eth0, address 10.1.1.193, port 38669 for outgoing packets Tracing the path to www.cnn.com (64.236.29.120) on TCP port 80 (www), 30 hops max 1 10.1.1.254 0.514 ms 0.974 ms 0.985 ms 2 X 0.986 ms 0.988 ms 0.983 ms 3 xxx.ser.netvision.net.il () 9.403 ms 11.062 ms 12.373 ms 4 vl100.coresw2.hfa.nv.net.il (212.143.8.69) 13.803 ms * 10.785 ms 5 ge0-1.gw2.hfa.nv.net.il (212.143.8.212) 9.913 ms 9.894 ms 26.442 ms 6 pos1-0.brdr1.nyc.nv.net.il (212.143.12.13) 255.455 ms 247.516 ms On Fri, Apr 4, 2008 at 11:30 PM, Amos Shapira <[EMAIL PROTECTED]> wrote: > On Fri, Apr 4, 2008 at 10:35 PM, Michael Tewner <[EMAIL PROTECTED]> wrote: > > > Just talked to Netvision Asakim support - > > He was knowlegable - ran `mtr` on his workstation and saw the packet > loss. > > > > He explained that "there is no problem" and that the core routers are > > dropping the ping packets based on the amount of load on the router. > > He explained that the router should only be dropping ICMP packets. > > I didn't read all the messages on this thread but maybe if you could run the > same tests with tcptraceroute you could see weather the packet drop happens > to TCP packets or not? > > --Amos > > = To unsubscribe, send mail to [EMAIL PROTECTED] with the word "unsubscribe" in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
Re: major packet loss at hot server
On Fri, Apr 4, 2008 at 10:35 PM, Michael Tewner <[EMAIL PROTECTED]> wrote: > Just talked to Netvision Asakim support - > He was knowlegable - ran `mtr` on his workstation and saw the packet > loss. > > He explained that "there is no problem" and that the core routers are > dropping the ping packets based on the amount of load on the router. > He explained that the router should only be dropping ICMP packets. I didn't read all the messages on this thread but maybe if you could run the same tests with tcptraceroute you could see weather the packet drop happens to TCP packets or not? --Amos
Re: major packet loss at hot server
Just talked to Netvision Asakim support - He was knowlegable - ran `mtr` on his workstation and saw the packet loss. He explained that "there is no problem" and that the core routers are dropping the ping packets based on the amount of load on the router. He explained that the router should only be dropping ICMP packets. I got to them by calling support ( 04-856-0550 ?) and telling them that there is a problem with their core network. On Fri, Apr 4, 2008 at 2:12 PM, Michael Tewner <[EMAIL PROTECTED]> wrote: > OK - I decided to give this a look, because I'm not happy with my > transfer speeds - > > I ran mtr from work (Netvision 5Mbit(?) ) to my home IP (Hot+Netvision): > 4. vl100.coresw1.hfa.nv.net.il > 23.0% 279 10.7 15.2 8.2 172.4 15.2 > 5. ge1-7.coresw1.ptk.nv.net.il > 17.2% 279 10.8 16.1 10.6 98.1 12.1 > 6. clr1.cab01.ptk.nv.net.il >0.0% 279 12.8 18.9 10.5 109.8 16.4 > 7. ??? > > > That vl100.coresw1.hfa.nv.net.il router is causing loss for every > host I've tried. www.cnn.com (~15%). > > www.yahoo.com it's giving ~20% loss, and pos2-13.brdr1.lnd.nv.net.il > is giving another 10%. > www.google.com - vl100 is giving 16%, pos2-9.brdr1.lnd.nv.net.il is > giving 26% loss. > > Is this on purpose, or is this some type of shaping/QOS? > > -mike > > On Sat, Mar 22, 2008 at 2:02 AM, Hetz Ben Hamo <[EMAIL PROTECTED]> wrote: > > > > I use ADSL (5Mbit). My ISP: Netvision. > > > > It seems that they also have some serious packet drops even from my > > machine to Netvision! check this out: (problems are marked with > > arrows) > > > > /mtr -c 10 -r netvision.net.il > > HOST: witch.dyndns.orgLoss% Snt Last Avg Best Wrst > StDev > > 1. 192.168.1.1 0.0%101.3 0.9 0.7 1.4 > 0.3 > > 2. lo0.lns05.hfa.nv.net.il 0.0%10 11.4 26.6 11.4 147.4 > 42.5 > > -->> 3. vl201.coresw1.hfa.nv.net.il 30.0%10 30.6 16.3 12.0 > > 30.6 6.4 <<--- > > 4. po41.srvc4.hfa.nv.net.il 0.0%10 30.5 16.6 11.7 30.5 > 7.4 > > 5. ??? 100.0100.0 0.0 0.0 0.0 > 0.0 > > > > /mtr -c 10 -r www.ynet.co.il > > HOST: witch.dyndns.orgLoss% Snt Last Avg Best Wrst > StDev > > 1. 192.168.1.1 0.0%100.8 0.9 0.7 1.4 > 0.2 > > 2. lo0.lns05.hfa.nv.net.il 0.0%10 11.5 11.6 11.3 12.1 > 0.2 > > -->> 3. vl201.coresw1.hfa.nv.net.il 40.0%10 12.1 14.6 11.8 > > 27.1 6.1 <<-- > > 4. po41.srvc4.hfa.nv.net.il 0.0%10 11.6 12.9 11.6 17.9 > 2.1 > > 5. 212.143.162.136 0.0%10 14.2 13.2 11.4 16.3 > 1.6 > > > > Hmm, I wonder if Netvision knows about this.. > > > > Hetz > > > > > > > > On Fri, Mar 21, 2008 at 10:10 PM, sara fink <[EMAIL PROTECTED]> wrote: > > > Hello Everyone > > > > > > I am having major problem with packet loss at some hot server that > > > sits in tel aviv. www.dnsstuff.com revealed this info. > > > > > > I would like to know how many people suffer from this problem. > > > > > > For this task mtr program is needed. The program can be downloaded at > > > http://www.bitwizard.nl/mtr/ . > > > > > > The description of the program is mtr combines the functionality > > > of the traceroute and ping programs in a single network diagnostic > > > tool. > > > > > >As mtr starts, it investigates the network connection between the > > > host mtr runs on and HOSTNAME. by sending packets with purposly > > > low TTLs. It continues to send packets with low TTL, noting the > > > response time of the intervening routers. This allows mtr to print > > > the response percentage and response times of the internet route > > > to HOSTNAME. A sudden increase in packetloss or response time > > > is often an indication of a bad (or simply overloaded) link. > > > > > > After installing this program please run the command mtr google.com or > > > even mtr walla.co.il mtr ynet.co.il > > > > > > I got in all 3 urls ~75% packet loss at ip 213.57.43.199 and at > > > 213.57.43.22 (or 14) another ~20% packet loss. > > > > > > Please inform me how many people suffer from this problem and who is > > > their isp. Mine is 012. but the ips mentioned belong to hot. > > > > > > I already talked with a nice technician at hot and he promissed to > > > give me an answer. Meanwhile at 012 tried to help me and in the end he > > > told me it's a operating sytem problem. I just hate to hear such > > > stupid excuses. I tried bot with and without iptables and it's the > > > same. Instead of solving the problem they blame the OS. And all this > > > happens with router or without. > > > > > > Besides that, the first IP is actually border gateway. > > > > > > Thanks for your
Re: major packet loss at hot server
OK - I decided to give this a look, because I'm not happy with my transfer speeds - I ran mtr from work (Netvision 5Mbit(?) ) to my home IP (Hot+Netvision): 4. vl100.coresw1.hfa.nv.net.il 23.0% 279 10.7 15.2 8.2 172.4 15.2 5. ge1-7.coresw1.ptk.nv.net.il 17.2% 279 10.8 16.1 10.6 98.1 12.1 6. clr1.cab01.ptk.nv.net.il 0.0% 279 12.8 18.9 10.5 109.8 16.4 7. ??? That vl100.coresw1.hfa.nv.net.il router is causing loss for every host I've tried. www.cnn.com (~15%). www.yahoo.com it's giving ~20% loss, and pos2-13.brdr1.lnd.nv.net.il is giving another 10%. www.google.com - vl100 is giving 16%, pos2-9.brdr1.lnd.nv.net.il is giving 26% loss. Is this on purpose, or is this some type of shaping/QOS? -mike On Sat, Mar 22, 2008 at 2:02 AM, Hetz Ben Hamo <[EMAIL PROTECTED]> wrote: > I use ADSL (5Mbit). My ISP: Netvision. > > It seems that they also have some serious packet drops even from my > machine to Netvision! check this out: (problems are marked with > arrows) > > /mtr -c 10 -r netvision.net.il > HOST: witch.dyndns.orgLoss% Snt Last Avg Best Wrst StDev > 1. 192.168.1.1 0.0%101.3 0.9 0.7 1.4 0.3 > 2. lo0.lns05.hfa.nv.net.il 0.0%10 11.4 26.6 11.4 147.4 42.5 > -->> 3. vl201.coresw1.hfa.nv.net.il 30.0%10 30.6 16.3 12.0 > 30.6 6.4 <<--- > 4. po41.srvc4.hfa.nv.net.il 0.0%10 30.5 16.6 11.7 30.5 7.4 > 5. ??? 100.0100.0 0.0 0.0 0.0 0.0 > > /mtr -c 10 -r www.ynet.co.il > HOST: witch.dyndns.orgLoss% Snt Last Avg Best Wrst StDev > 1. 192.168.1.1 0.0%100.8 0.9 0.7 1.4 0.2 > 2. lo0.lns05.hfa.nv.net.il 0.0%10 11.5 11.6 11.3 12.1 0.2 > -->> 3. vl201.coresw1.hfa.nv.net.il 40.0%10 12.1 14.6 11.8 > 27.1 6.1 <<-- > 4. po41.srvc4.hfa.nv.net.il 0.0%10 11.6 12.9 11.6 17.9 2.1 > 5. 212.143.162.136 0.0%10 14.2 13.2 11.4 16.3 1.6 > > Hmm, I wonder if Netvision knows about this.. > > Hetz > > > > On Fri, Mar 21, 2008 at 10:10 PM, sara fink <[EMAIL PROTECTED]> wrote: > > Hello Everyone > > > > I am having major problem with packet loss at some hot server that > > sits in tel aviv. www.dnsstuff.com revealed this info. > > > > I would like to know how many people suffer from this problem. > > > > For this task mtr program is needed. The program can be downloaded at > > http://www.bitwizard.nl/mtr/ . > > > > The description of the program is mtr combines the functionality > > of the traceroute and ping programs in a single network diagnostic > > tool. > > > >As mtr starts, it investigates the network connection between the > > host mtr runs on and HOSTNAME. by sending packets with purposly > > low TTLs. It continues to send packets with low TTL, noting the > > response time of the intervening routers. This allows mtr to print > > the response percentage and response times of the internet route > > to HOSTNAME. A sudden increase in packetloss or response time > > is often an indication of a bad (or simply overloaded) link. > > > > After installing this program please run the command mtr google.com or > > even mtr walla.co.il mtr ynet.co.il > > > > I got in all 3 urls ~75% packet loss at ip 213.57.43.199 and at > > 213.57.43.22 (or 14) another ~20% packet loss. > > > > Please inform me how many people suffer from this problem and who is > > their isp. Mine is 012. but the ips mentioned belong to hot. > > > > I already talked with a nice technician at hot and he promissed to > > give me an answer. Meanwhile at 012 tried to help me and in the end he > > told me it's a operating sytem problem. I just hate to hear such > > stupid excuses. I tried bot with and without iptables and it's the > > same. Instead of solving the problem they blame the OS. And all this > > happens with router or without. > > > > Besides that, the first IP is actually border gateway. > > > > Thanks for your help > > > > = > > To unsubscribe, send mail to [EMAIL PROTECTED] with > > the word "unsubscribe" in the message body, e.g., run the command > > echo unsubscribe | mail [EMAIL PROTECTED] > > > > > > > > -- > Skepticism is the lazy person's default position. > my blog (hebrew): http://benhamo.org > > > > = > To unsubscribe, send mail to [EMAIL PROTECTED] with > the word "unsubscribe" in the message body, e.g., run the command > echo unsubscribe | mail [EMAIL PROTECTED] > > = To unsubscribe, send mail to [EMAIL PROTECTED] with the word "unsubscribe" in the message body, e.g., run the command echo unsubscribe |
Re: major packet loss at hot server
Hi Sara, I wonder if you aren't better off just getting an ADSL line and switching service providers. - yba On Thu, 3 Apr 2008, sara fink wrote: Date: Thu, 3 Apr 2008 16:14:51 +0300 From: sara fink <[EMAIL PROTECTED]> To: Jonathan Ben Avraham <[EMAIL PROTECTED]> Cc: ILUG Subject: Re: major packet loss at hot server I don't have a machine that runs tcpdump. Plus it needs root access. I wonder if I create one of these free shells that are out there, will it help? tcpdump will work without root as well? Last time I talked with 012 and hot, hot managed to dissconnect me completely. The support from hot was nice, but told me to unplug the cable and replug again. And from then I don't have internet at all. The /etc/resolv.conf is correct. I waited for hot to call me back, but it didn't happen. Since now I am not at home, I can't check anything. When I will return back will have to shout at them to connect me to internet. All the time when I ran mtr google.com (outside) there was the packet loss. The loss is in the 2nd and 3rd hop. first is the router of hot ( I have another router at home but last time I didn't use it for the purpose of checking and proving hot it's not my router fault), then the switch with 80% packet loss and 3rd another switch/router of hot with 20% packet loss. 2nd hop is bgp. port 179 open. 3rd switch/router has port 49 open (tacacs). AND from my scannings, I pass only through 1 switch which has bgp open. I have access to a machine, but not as root. I can run there traceroute. And will definitely run from there mtr to machine A and traceroute from there to my machine. Are there any others programs that I can run as simple user? I can't understand them, if I pass through such a switch, where they close all the ports and allow only 179, 646, and all udp ports are closed what kind of internet is that. It castrates all the concept of internet. BTW, I want to ask a legal question. I will finally submit a complaint through tluna.co.il, but I don't know if it's legal to submit the ip numbers. A lot of people are using these switches, and people don't know about this problem. Thanks in advance for all the help. Hi Sara, If you have access to a machine somewhere that runs tcpdump, then use hping commands from your MPLS to that machine in order to see if the packet loss is occuring on the outgoing or on the return trip. That is, hping out 50 packets. Check to see how many of those get to the target and then check to see how many of those that got to the target got back to you. If there is a more packet loss on the return leg than on the outgoing leg I would suspect a routing problem. If there is more loss on the early hops of the outgoing leg then I suspect either congestion or physical transmission problems with the final repeater or router. How do I use different routing? Any idea of which ips should I put? You can't if you dont have a static IP. Well, I guess that you could check the routing to your first hop out that has a routed IP address by using various foreign traceroute web pages. If the routing problem is low enough and there is only one BGP router through which your packets can pass, then you might not be able to see the routing problem. I was able to see the routing problem that I had at Netvision last week because I was able to access my line from different Netvision border routers because Netvision is pretty big. It was really clear that one particular border router was getting bad information from an internal router. I know someone who is very nice at 012. She belongs to service dep, and she promissed to send someone who knows well unix/linux. I will see what I can do today. Otherwise, www.tluna.co.il is the answer. I put last year a complaint there and they started to call me (not vice versa). The problem was solved. There is another weird thing which I don't understand: the ip 213.57.43.199 shows IP address: 213.57.43.199 Reverse DNS:[Timeout] Reverse DNS authenticity: [Unknown] ASN:8584 ASN Name: UNSPECIFIED (Barak AS) I don't belong to barak. Someone at 012 told me they have agreements and they use each router on the way. Most suppliers have agreements for routing between them instead or or as well as routing through the IIX. In addition many suppliers purchase overseas bandwidth from BBL or Barak/Netvision. You can probably ask Hot if they use Barak/Netvision. - yba http://www.dnsstuff.com/tools/ipall.ch?domain=213.57.43.199 If someone can explain this, I will be glad. On 3/29/08, Jonathan Ben Avraham <[EMAIL PROTECTED]> wrote: Hi Sara, Sounds like you should consider switching suppliers. Regarding my problem with Netvision reported last week, I was able to show Netvision the difference in results (5% loss vs 70% loss) when using dif
Re: major packet loss at hot server
Oh, I forgot, I have static ip. On 4/1/08, Jonathan Ben Avraham <[EMAIL PROTECTED]> wrote: > On Sun, 30 Mar 2008, sara fink wrote: > > > > Date: Sun, 30 Mar 2008 09:48:41 +0300 > > From: sara fink <[EMAIL PROTECTED]> > > To: Jonathan Ben Avraham <[EMAIL PROTECTED]> > > Cc: linux-il@cs.huji.ac.il > > Subject: Re: major packet loss at hot server > > > > I can't check symmetry. I don't have adsl. In my case the problem > > starts at hot. the first 2 hops belong to hot and the 3rd hop is 012. > > The 80% packet lost is in the first hop. The 2nd hop another 20%. I > > have MPLS without dialer. > > > > Hi Sara, > If you have access to a machine somewhere that runs tcpdump, then use hping > commands from your MPLS to that machine in order to see if the packet loss > is occuring on the outgoing or on the return trip. That is, hping out 50 > packets. Check to see how many of those get to the target and then check to > see how many of those that got to the target got back to you. If there is a > more packet loss on the return leg than on the outgoing leg I would suspect > a routing problem. If there is more loss on the early hops of the outgoing > leg then I suspect either congestion or physical transmission problems with > the final repeater or router. > > > > > > How do I use different routing? Any idea of which ips should I put? > > > > You can't if you dont have a static IP. Well, I guess that you could check > the routing to your first hop out that has a routed IP address by using > various foreign traceroute web pages. If the routing problem is low enough > and there is only one BGP router through which your packets can pass, then > you might not be able to see the routing problem. I was able to see the > routing problem that I had at Netvision last week because I was able to > access my line from different Netvision border routers because Netvision is > pretty big. It was really clear that one particular border router was > getting bad information from an internal router. > > > > I know someone who is very nice at 012. She belongs to service dep, > > and she promissed to send someone who knows well unix/linux. I will > > see what I can do today. Otherwise, www.tluna.co.il is the answer. I > > put last year a complaint there and they started to call me (not vice > > versa). The problem was solved. > > > > There is another weird thing which I don't understand: the ip > > 213.57.43.199 shows > > IP address: 213.57.43.199 > > Reverse DNS:[Timeout] > > Reverse DNS authenticity: [Unknown] > > ASN:8584 > > ASN Name: UNSPECIFIED (Barak AS) > > > > I don't belong to barak. Someone at 012 told me they have agreements > > and they use each router on the way. > > > > Most suppliers have agreements for routing between them instead or or as > well as routing through the IIX. In addition many suppliers purchase > overseas bandwidth from BBL or Barak/Netvision. You can probably ask Hot if > they use Barak/Netvision. > > - yba > > > > > > http://www.dnsstuff.com/tools/ipall.ch?domain=213.57.43.199 > > > > If someone can explain this, I will be glad. > > > > > > On 3/29/08, Jonathan Ben Avraham <[EMAIL PROTECTED]> wrote: > > > > > Hi Sara, > > > Sounds like you should consider switching suppliers. > > > > > > Regarding my problem with Netvision reported last week, I was able to > show > > > Netvision the difference in results (5% loss vs 70% loss) when using > > > different routes through Netvisions AS, mainly depending on where the > > > connection originated but this did not actually prove that there was a > > > routing error AFAIK. For some reason I didn't think to test if the > packet > > > loss was symmetric (outgoing as well as incomming). That would > > > probably have been as close as you could get to a proof of routing > error. > > > > > > Does your packet loss depend on where you enter 012 from (i.e. from > Med1, > > > from the IIX, from 012 ADSL)? Is the packet loss symmetric? That is do > you > > > lose the same percent of packets on packet going out as comming in? > > > > > > From my experience with Netvision, the level of service that you get at > > > the ISP depends on who knows you, or who knows someone who knows you. > > > Shavua Tov, > > > > > > - yba > > > > > > > > > On Fri, 28 Mar 2008, sa
Re: major packet loss at hot server
my problem with Netvision reported last week, I was able to > show > > > Netvision the difference in results (5% loss vs 70% loss) when using > > > different routes through Netvisions AS, mainly depending on where the > > > connection originated but this did not actually prove that there was a > > > routing error AFAIK. For some reason I didn't think to test if the > packet > > > loss was symmetric (outgoing as well as incomming). That would > > > probably have been as close as you could get to a proof of routing > error. > > > > > > Does your packet loss depend on where you enter 012 from (i.e. from > Med1, > > > from the IIX, from 012 ADSL)? Is the packet loss symmetric? That is do > you > > > lose the same percent of packets on packet going out as comming in? > > > > > > From my experience with Netvision, the level of service that you get at > > > the ISP depends on who knows you, or who knows someone who knows you. > > > Shavua Tov, > > > > > > - yba > > > > > > > > > On Fri, 28 Mar 2008, sara fink wrote: > > > > > > > > > > Date: Fri, 28 Mar 2008 16:43:37 +0300 > > > > From: sara fink <[EMAIL PROTECTED]> > > > > To: Jonathan Ben Avraham <[EMAIL PROTECTED]> > > > > Cc: linux-il@cs.huji.ac.il > > > > Subject: Re: major packet loss at hot server > > > > > > > > I haven't solved the problem yet. From 012 someone "superior" (network > > > > dep) are supposed to call me and they will put hot on conference and > > > > this time I intend to request the net admin/integrator to take care of > > > > that AND ask them to go directly to the switch and disable the > > > > firewall.The ip from where there is 75-80% packet lost is a principal > > > > switchand another 1 or 2 ips where I get additional ~15-20% packet > > > > lost. They have a harsh firewall on the main switch. ALL UDP ports > > > > are blocked. TCP also a lot of ports closed. > > > > > > > > tcptraceroute (as opposed to traceroute manages to bypass firewall) > > > > reveals that there is a firewall, although inside hot (between > > > > switches) the ports are open (firewalk). As for the problem you had > > > > last week, I am not sure, because I have static IP without dialer > > > > (MPLS) and the first 2 hops belong to hot (where the packet loss > > > > occurs) and the 3rd hop is 012. One of support guys said that is 012 > > > > blame because they are only infrastructure. 012 says it's hot ip and > > > > they are right. And I am the ball which is ping-ponged. ;-( > > > > > > > > AND ttl to my default gateway is 255. ttl for google.com is 225. > > > > > > > > But, I will try wireshark as well to check syn, syn-ack. I don't use 3 > > > > way handshake. Otherwise I will be detected. I use nmap -sS. I > > > > understand that you used -sT flag. Correct? > > > > > > > > They make troubles if you scan their net? -sT for instance? > > > > > > > > If you can tell me what exactly you ran, I will be glad. > > > > > > > > On 3/28/08, Jonathan Ben Avraham <[EMAIL PROTECTED]> wrote: > > > > > > > > > Hi Sara, > > > > > Did you solve this problem? > > > > > Are you sure that it isn't a routing problem at 012 similar to what > I had > > > > > last week with Netvision? > > > > > > > > > > - yba > > > > > > > > > > > > > > > On Fri, 21 Mar 2008, sara fink wrote: > > > > > > > > > > > > > > > > Date: Fri, 21 Mar 2008 22:10:56 +0200 > > > > > > From: sara fink <[EMAIL PROTECTED]> > > > > > > To: Israeli Linux mailing list > > > > > > Subject: major packet loss at hot server > > > > > > > > > > > > Hello Everyone > > > > > > > > > > > > I am having major problem with packet loss at some hot server that > > > > > > sits in tel aviv. www.dnsstuff.com revealed this info. > > > > > > > > > > > > I would like to know how many people suffer from this problem. > > > > > > > > > > > > For this task mtr program is needed. The program can be downloaded > at > > > > > > http://www.bitwizar
Re: major packet loss at hot server
On Sun, 30 Mar 2008, sara fink wrote: Date: Sun, 30 Mar 2008 09:48:41 +0300 From: sara fink <[EMAIL PROTECTED]> To: Jonathan Ben Avraham <[EMAIL PROTECTED]> Cc: linux-il@cs.huji.ac.il Subject: Re: major packet loss at hot server I can't check symmetry. I don't have adsl. In my case the problem starts at hot. the first 2 hops belong to hot and the 3rd hop is 012. The 80% packet lost is in the first hop. The 2nd hop another 20%. I have MPLS without dialer. Hi Sara, If you have access to a machine somewhere that runs tcpdump, then use hping commands from your MPLS to that machine in order to see if the packet loss is occuring on the outgoing or on the return trip. That is, hping out 50 packets. Check to see how many of those get to the target and then check to see how many of those that got to the target got back to you. If there is a more packet loss on the return leg than on the outgoing leg I would suspect a routing problem. If there is more loss on the early hops of the outgoing leg then I suspect either congestion or physical transmission problems with the final repeater or router. How do I use different routing? Any idea of which ips should I put? You can't if you dont have a static IP. Well, I guess that you could check the routing to your first hop out that has a routed IP address by using various foreign traceroute web pages. If the routing problem is low enough and there is only one BGP router through which your packets can pass, then you might not be able to see the routing problem. I was able to see the routing problem that I had at Netvision last week because I was able to access my line from different Netvision border routers because Netvision is pretty big. It was really clear that one particular border router was getting bad information from an internal router. I know someone who is very nice at 012. She belongs to service dep, and she promissed to send someone who knows well unix/linux. I will see what I can do today. Otherwise, www.tluna.co.il is the answer. I put last year a complaint there and they started to call me (not vice versa). The problem was solved. There is another weird thing which I don't understand: the ip 213.57.43.199 shows IP address: 213.57.43.199 Reverse DNS:[Timeout] Reverse DNS authenticity: [Unknown] ASN:8584 ASN Name: UNSPECIFIED (Barak AS) I don't belong to barak. Someone at 012 told me they have agreements and they use each router on the way. Most suppliers have agreements for routing between them instead or or as well as routing through the IIX. In addition many suppliers purchase overseas bandwidth from BBL or Barak/Netvision. You can probably ask Hot if they use Barak/Netvision. - yba http://www.dnsstuff.com/tools/ipall.ch?domain=213.57.43.199 If someone can explain this, I will be glad. On 3/29/08, Jonathan Ben Avraham <[EMAIL PROTECTED]> wrote: Hi Sara, Sounds like you should consider switching suppliers. Regarding my problem with Netvision reported last week, I was able to show Netvision the difference in results (5% loss vs 70% loss) when using different routes through Netvisions AS, mainly depending on where the connection originated but this did not actually prove that there was a routing error AFAIK. For some reason I didn't think to test if the packet loss was symmetric (outgoing as well as incomming). That would probably have been as close as you could get to a proof of routing error. Does your packet loss depend on where you enter 012 from (i.e. from Med1, from the IIX, from 012 ADSL)? Is the packet loss symmetric? That is do you lose the same percent of packets on packet going out as comming in? From my experience with Netvision, the level of service that you get at the ISP depends on who knows you, or who knows someone who knows you. Shavua Tov, - yba On Fri, 28 Mar 2008, sara fink wrote: Date: Fri, 28 Mar 2008 16:43:37 +0300 From: sara fink <[EMAIL PROTECTED]> To: Jonathan Ben Avraham <[EMAIL PROTECTED]> Cc: linux-il@cs.huji.ac.il Subject: Re: major packet loss at hot server I haven't solved the problem yet. From 012 someone "superior" (network dep) are supposed to call me and they will put hot on conference and this time I intend to request the net admin/integrator to take care of that AND ask them to go directly to the switch and disable the firewall.The ip from where there is 75-80% packet lost is a principal switchand another 1 or 2 ips where I get additional ~15-20% packet lost. They have a harsh firewall on the main switch. ALL UDP ports are blocked. TCP also a lot of ports closed. tcptraceroute (as opposed to traceroute manages to bypass firewall) reveals that there is a firewall, although inside hot (between switches) the ports are open (firewalk). As for the problem you had last week, I am not sure, because I hav
Re: major packet loss at hot server
I can't check symmetry. I don't have adsl. In my case the problem starts at hot. the first 2 hops belong to hot and the 3rd hop is 012. The 80% packet lost is in the first hop. The 2nd hop another 20%. I have MPLS without dialer. How do I use different routing? Any idea of which ips should I put? I know someone who is very nice at 012. She belongs to service dep, and she promissed to send someone who knows well unix/linux. I will see what I can do today. Otherwise, www.tluna.co.il is the answer. I put last year a complaint there and they started to call me (not vice versa). The problem was solved. There is another weird thing which I don't understand: the ip 213.57.43.199 shows IP address: 213.57.43.199 Reverse DNS:[Timeout] Reverse DNS authenticity: [Unknown] ASN:8584 ASN Name: UNSPECIFIED (Barak AS) I don't belong to barak. Someone at 012 told me they have agreements and they use each router on the way. http://www.dnsstuff.com/tools/ipall.ch?domain=213.57.43.199 If someone can explain this, I will be glad. On 3/29/08, Jonathan Ben Avraham <[EMAIL PROTECTED]> wrote: > Hi Sara, > Sounds like you should consider switching suppliers. > > Regarding my problem with Netvision reported last week, I was able to show > Netvision the difference in results (5% loss vs 70% loss) when using > different routes through Netvisions AS, mainly depending on where the > connection originated but this did not actually prove that there was a > routing error AFAIK. For some reason I didn't think to test if the packet > loss was symmetric (outgoing as well as incomming). That would > probably have been as close as you could get to a proof of routing error. > > Does your packet loss depend on where you enter 012 from (i.e. from Med1, > from the IIX, from 012 ADSL)? Is the packet loss symmetric? That is do you > lose the same percent of packets on packet going out as comming in? > > From my experience with Netvision, the level of service that you get at > the ISP depends on who knows you, or who knows someone who knows you. > Shavua Tov, > > - yba > > > On Fri, 28 Mar 2008, sara fink wrote: > > > Date: Fri, 28 Mar 2008 16:43:37 +0300 > > From: sara fink <[EMAIL PROTECTED]> > > To: Jonathan Ben Avraham <[EMAIL PROTECTED]> > > Cc: linux-il@cs.huji.ac.il > > Subject: Re: major packet loss at hot server > > > > I haven't solved the problem yet. From 012 someone "superior" (network > > dep) are supposed to call me and they will put hot on conference and > > this time I intend to request the net admin/integrator to take care of > > that AND ask them to go directly to the switch and disable the > > firewall.The ip from where there is 75-80% packet lost is a principal > > switchand another 1 or 2 ips where I get additional ~15-20% packet > > lost. They have a harsh firewall on the main switch. ALL UDP ports > > are blocked. TCP also a lot of ports closed. > > > > tcptraceroute (as opposed to traceroute manages to bypass firewall) > > reveals that there is a firewall, although inside hot (between > > switches) the ports are open (firewalk). As for the problem you had > > last week, I am not sure, because I have static IP without dialer > > (MPLS) and the first 2 hops belong to hot (where the packet loss > > occurs) and the 3rd hop is 012. One of support guys said that is 012 > > blame because they are only infrastructure. 012 says it's hot ip and > > they are right. And I am the ball which is ping-ponged. ;-( > > > > AND ttl to my default gateway is 255. ttl for google.com is 225. > > > > But, I will try wireshark as well to check syn, syn-ack. I don't use 3 > > way handshake. Otherwise I will be detected. I use nmap -sS. I > > understand that you used -sT flag. Correct? > > > > They make troubles if you scan their net? -sT for instance? > > > > If you can tell me what exactly you ran, I will be glad. > > > > On 3/28/08, Jonathan Ben Avraham <[EMAIL PROTECTED]> wrote: > >> Hi Sara, > >> Did you solve this problem? > >> Are you sure that it isn't a routing problem at 012 similar to what I had > >> last week with Netvision? > >> > >> - yba > >> > >> > >> On Fri, 21 Mar 2008, sara fink wrote: > >> > >>> Date: Fri, 21 Mar 2008 22:10:56 +0200 > >>> From: sara fink <[EMAIL PROTECTED]> > >>> To: Israeli Linux mailing list > >>> Subject: major packet loss at hot server > >>> > >>> Hello Everyone > >>> >
Re: major packet loss at hot server
Hi Sara, Sounds like you should consider switching suppliers. Regarding my problem with Netvision reported last week, I was able to show Netvision the difference in results (5% loss vs 70% loss) when using different routes through Netvisions AS, mainly depending on where the connection originated but this did not actually prove that there was a routing error AFAIK. For some reason I didn't think to test if the packet loss was symmetric (outgoing as well as incomming). That would probably have been as close as you could get to a proof of routing error. Does your packet loss depend on where you enter 012 from (i.e. from Med1, from the IIX, from 012 ADSL)? Is the packet loss symmetric? That is do you lose the same percent of packets on packet going out as comming in? From my experience with Netvision, the level of service that you get at the ISP depends on who knows you, or who knows someone who knows you. Shavua Tov, - yba On Fri, 28 Mar 2008, sara fink wrote: Date: Fri, 28 Mar 2008 16:43:37 +0300 From: sara fink <[EMAIL PROTECTED]> To: Jonathan Ben Avraham <[EMAIL PROTECTED]> Cc: linux-il@cs.huji.ac.il Subject: Re: major packet loss at hot server I haven't solved the problem yet. From 012 someone "superior" (network dep) are supposed to call me and they will put hot on conference and this time I intend to request the net admin/integrator to take care of that AND ask them to go directly to the switch and disable the firewall.The ip from where there is 75-80% packet lost is a principal switchand another 1 or 2 ips where I get additional ~15-20% packet lost. They have a harsh firewall on the main switch. ALL UDP ports are blocked. TCP also a lot of ports closed. tcptraceroute (as opposed to traceroute manages to bypass firewall) reveals that there is a firewall, although inside hot (between switches) the ports are open (firewalk). As for the problem you had last week, I am not sure, because I have static IP without dialer (MPLS) and the first 2 hops belong to hot (where the packet loss occurs) and the 3rd hop is 012. One of support guys said that is 012 blame because they are only infrastructure. 012 says it's hot ip and they are right. And I am the ball which is ping-ponged. ;-( AND ttl to my default gateway is 255. ttl for google.com is 225. But, I will try wireshark as well to check syn, syn-ack. I don't use 3 way handshake. Otherwise I will be detected. I use nmap -sS. I understand that you used -sT flag. Correct? They make troubles if you scan their net? -sT for instance? If you can tell me what exactly you ran, I will be glad. On 3/28/08, Jonathan Ben Avraham <[EMAIL PROTECTED]> wrote: Hi Sara, Did you solve this problem? Are you sure that it isn't a routing problem at 012 similar to what I had last week with Netvision? - yba On Fri, 21 Mar 2008, sara fink wrote: Date: Fri, 21 Mar 2008 22:10:56 +0200 From: sara fink <[EMAIL PROTECTED]> To: Israeli Linux mailing list Subject: major packet loss at hot server Hello Everyone I am having major problem with packet loss at some hot server that sits in tel aviv. www.dnsstuff.com revealed this info. I would like to know how many people suffer from this problem. For this task mtr program is needed. The program can be downloaded at http://www.bitwizard.nl/mtr/ . The description of the program is mtr combines the functionality of the traceroute and ping programs in a single network diagnostic tool. As mtr starts, it investigates the network connection between the host mtr runs on and HOSTNAME. by sending packets with purposly low TTLs. It continues to send packets with low TTL, noting the response time of the intervening routers. This allows mtr to print the response percentage and response times of the internet route to HOSTNAME. A sudden increase in packetloss or response time is often an indication of a bad (or simply overloaded) link. After installing this program please run the command mtr google.com or even mtr walla.co.il mtr ynet.co.il I got in all 3 urls ~75% packet loss at ip 213.57.43.199 and at 213.57.43.22 (or 14) another ~20% packet loss. Please inform me how many people suffer from this problem and who is their isp. Mine is 012. but the ips mentioned belong to hot. I already talked with a nice technician at hot and he promissed to give me an answer. Meanwhile at 012 tried to help me and in the end he told me it's a operating sytem problem. I just hate to hear such stupid excuses. I tried bot with and without iptables and it's the same. Instead of solving the problem they blame the OS. And all this happens with router or without. Besides that, the first IP is actually border gateway. Thanks for your help = To unsubscribe, send mail to [EMAIL PROTECTED] with the word "unsubscribe" in the message body, e.g., run the command echo unsubscribe | mail [EMAIL
Re: major packet loss at hot server
I haven't solved the problem yet. From 012 someone "superior" (network dep) are supposed to call me and they will put hot on conference and this time I intend to request the net admin/integrator to take care of that AND ask them to go directly to the switch and disable the firewall.The ip from where there is 75-80% packet lost is a principal switchand another 1 or 2 ips where I get additional ~15-20% packet lost. They have a harsh firewall on the main switch. ALL UDP ports are blocked. TCP also a lot of ports closed. tcptraceroute (as opposed to traceroute manages to bypass firewall) reveals that there is a firewall, although inside hot (between switches) the ports are open (firewalk). As for the problem you had last week, I am not sure, because I have static IP without dialer (MPLS) and the first 2 hops belong to hot (where the packet loss occurs) and the 3rd hop is 012. One of support guys said that is 012 blame because they are only infrastructure. 012 says it's hot ip and they are right. And I am the ball which is ping-ponged. ;-( AND ttl to my default gateway is 255. ttl for google.com is 225. But, I will try wireshark as well to check syn, syn-ack. I don't use 3 way handshake. Otherwise I will be detected. I use nmap -sS. I understand that you used -sT flag. Correct? They make troubles if you scan their net? -sT for instance? If you can tell me what exactly you ran, I will be glad. On 3/28/08, Jonathan Ben Avraham <[EMAIL PROTECTED]> wrote: > Hi Sara, > Did you solve this problem? > Are you sure that it isn't a routing problem at 012 similar to what I had > last week with Netvision? > > - yba > > > On Fri, 21 Mar 2008, sara fink wrote: > > > Date: Fri, 21 Mar 2008 22:10:56 +0200 > > From: sara fink <[EMAIL PROTECTED]> > > To: Israeli Linux mailing list > > Subject: major packet loss at hot server > > > > Hello Everyone > > > > I am having major problem with packet loss at some hot server that > > sits in tel aviv. www.dnsstuff.com revealed this info. > > > > I would like to know how many people suffer from this problem. > > > > For this task mtr program is needed. The program can be downloaded at > > http://www.bitwizard.nl/mtr/ . > > > > The description of the program is mtr combines the functionality > > of the traceroute and ping programs in a single network diagnostic > > tool. > > > > As mtr starts, it investigates the network connection between the > > host mtr runs on and HOSTNAME. by sending packets with purposly > > low TTLs. It continues to send packets with low TTL, noting the > > response time of the intervening routers. This allows mtr to print > > the response percentage and response times of the internet route > > to HOSTNAME. A sudden increase in packetloss or response time > > is often an indication of a bad (or simply overloaded) link. > > > > After installing this program please run the command mtr google.com or > > even mtr walla.co.il mtr ynet.co.il > > > > I got in all 3 urls ~75% packet loss at ip 213.57.43.199 and at > > 213.57.43.22 (or 14) another ~20% packet loss. > > > > Please inform me how many people suffer from this problem and who is > > their isp. Mine is 012. but the ips mentioned belong to hot. > > > > I already talked with a nice technician at hot and he promissed to > > give me an answer. Meanwhile at 012 tried to help me and in the end he > > told me it's a operating sytem problem. I just hate to hear such > > stupid excuses. I tried bot with and without iptables and it's the > > same. Instead of solving the problem they blame the OS. And all this > > happens with router or without. > > > > Besides that, the first IP is actually border gateway. > > > > Thanks for your help > > > > = > > To unsubscribe, send mail to [EMAIL PROTECTED] with > > the word "unsubscribe" in the message body, e.g., run the command > > echo unsubscribe | mail [EMAIL PROTECTED] > > > > > > -- > EE 77 7F 30 4A 64 2E C5 83 5F E7 49 A6 82 29 BA ~. .~ Tk Open > Systems > =}ooO--U--Ooo{= > - [EMAIL PROTECTED] - tel: +972.2.679.5364, http://www.tkos.co.il - > = To unsubscribe, send mail to [EMAIL PROTECTED] with the word "unsubscribe" in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
Re: major packet loss at hot server
On Mon, Mar 24, 2008 at 04:22:52PM +0200, Doron Shikmoni wrote: > This introduced high latency on that particular link; traceroute done > to debug that would have always shown the IIX on one end of the problem, > and hence, fingers were pointed at IIX as being the culprit. It wasn't. Thanks, it's always good to get the right answers. :-) Geoff. -- Geoffrey S. Mendelson, Jerusalem, Israel [EMAIL PROTECTED] N3OWJ/4X1GM = To unsubscribe, send mail to [EMAIL PROTECTED] with the word "unsubscribe" in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
Re: major packet loss at hot server
From a recent posting: >> At one time all packets between ISPs went via the IIX, which tends to >> become overloaded in the afternoon. Not exactly. Let's call this Misconception #1. >> I don't know if that has changed, >> and if it has for all packets, or just ones that the ISPs want to have >> high priority. > > Now that they are connected between themselves, I don't think IIX is > alive any more. Misconception #2. > anyone knows whats the status of IIX these days? Doron? Starting with #2. IIX is alive and kicking. All the ISPs interconnect via IIX. Currently (as opposed to, say, 5 years ago), IIX is but one of a few ways ISPs in Israel peer with each other. They also do direct, private peering. Back to #1 above. During its entire history (as of 1996 - Bar Mitzva next year!), IIX was never overloaded. It was always under capacity, with routine upgrades that preserved this status. The "overloading" sense that some people experienced in some periods in history were a result of some ISP's (to remain unnamed) conscious policy, to keep their link to the IIX narrow and fully saturated, so as to manipulate end-users Internet access experience. This way their own access customers would experience better service (because a large part of Israeli content was hosted at that ISP as well). This introduced high latency on that particular link; traceroute done to debug that would have always shown the IIX on one end of the problem, and hence, fingers were pointed at IIX as being the culprit. It wasn't. Doron = To unsubscribe, send mail to [EMAIL PROTECTED] with the word "unsubscribe" in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
Re: major packet loss at hot server
I found out that in my case they blocked all ports except 8010. So there is no need for QOS. But I am going to tell them. As for hot, they use some cisco routers and some jerky routers/switches like Juniper Networks M10 or M320 router or similar versions of juniper. In my case there is major packet loss either if I ping google or web sites in Israel. On Sun, Mar 23, 2008 at 12:12 PM, Geoffrey S. Mendelson <[EMAIL PROTECTED]> wrote: > On Sun, Mar 23, 2008 at 11:59:12AM +0200, Hetz Ben Hamo wrote: > > So I wonder, are those ISP's using Cisco's 1XXX/2XXX routers which > > makes those packet loss? > > An ISP should have a very fast equipment which shouldn't loose packet > > like nuts. Thats unacceptable these days, specially when it comes to > > any serious video streaming, for example. Few days ago I did a small > > test from a hosted server in one of the big ISP's here and tried to do > > some HD streaming for a test I'm performing. I have 5MBit ADSL, so I > > thought that it should be sufficient.. > > It was - but due to the packet loss, the stream becomes jerky playback > > (not because of my machines here at home). > > I have 5M cable, and it varries from host to host, day to day, time > to time. > > For example, I have no noticeable packet loss using VoIP (SIP) to > my provider, but had too much to make it useable to Vonage. Skype > reports 5% packet loss often, and in the evening 15%-20%. Enough > that I never use it unless I have to. > > Echolink is even worse (if you know what that is, if not suffice > it to say it's a propritary VoIP package). > > > > As much as I know (and it least according to my tests which I did 2 > > minutes ago with traceroute), all of the ISP's are connected between > > themselves with fiber optics directly. > > All? There are many ISP's in Israel besides the "big three". They probably > are connected, but what about the small ones? Or Bynet? > > > > Now that they are connected between themselves, I don't think IIX is > > alive any more. anyone knows whats the status of IIX these days? > > Doron? > > I'd like to find that out too. Please respond to the list. > > > Yeah, which makes any hosting video streaming outside Israel a joke, > > unless you have lots of money either for a slice of optic from Med1 or > > using anything like Akamai's services. > > That's life in the Internet. :-) > > > > QOS for traceroute? never heard of this thing before... > > Sure, they would very likely traffic shape ping and traceroute to > be really good, to make customers think it's not their ISP's > problem. > > > > I don't want to be sued, but my hunch tells me that all of the ISP's > > are doing QOS for stuff like Bittorrent, emule/edonkey etc. but not > > blocking those ports (which would be a joke when it comes to > > bittorrent.. It doesn't care if you block 6881-6888 TCP as long as you > > open something else). > > I know that Netvision does not block SIP nor, bit torrent but according > to several users on other lists, 012 blocks (or did block) STEAM (a gaming > site) and really slows down FTP. > > > Geoff. > > -- > Geoffrey S. Mendelson, Jerusalem, Israel [EMAIL PROTECTED] N3OWJ/4X1GM > > = > > > To unsubscribe, send mail to [EMAIL PROTECTED] with > the word "unsubscribe" in the message body, e.g., run the command > echo unsubscribe | mail [EMAIL PROTECTED] > > = To unsubscribe, send mail to [EMAIL PROTECTED] with the word "unsubscribe" in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
Re: major packet loss at hot server
On Sun, Mar 23, 2008 at 11:59:12AM +0200, Hetz Ben Hamo wrote: > So I wonder, are those ISP's using Cisco's 1XXX/2XXX routers which > makes those packet loss? > An ISP should have a very fast equipment which shouldn't loose packet > like nuts. Thats unacceptable these days, specially when it comes to > any serious video streaming, for example. Few days ago I did a small > test from a hosted server in one of the big ISP's here and tried to do > some HD streaming for a test I'm performing. I have 5MBit ADSL, so I > thought that it should be sufficient.. > It was - but due to the packet loss, the stream becomes jerky playback > (not because of my machines here at home). I have 5M cable, and it varries from host to host, day to day, time to time. For example, I have no noticeable packet loss using VoIP (SIP) to my provider, but had too much to make it useable to Vonage. Skype reports 5% packet loss often, and in the evening 15%-20%. Enough that I never use it unless I have to. Echolink is even worse (if you know what that is, if not suffice it to say it's a propritary VoIP package). > As much as I know (and it least according to my tests which I did 2 > minutes ago with traceroute), all of the ISP's are connected between > themselves with fiber optics directly. All? There are many ISP's in Israel besides the "big three". They probably are connected, but what about the small ones? Or Bynet? > Now that they are connected between themselves, I don't think IIX is > alive any more. anyone knows whats the status of IIX these days? > Doron? I'd like to find that out too. Please respond to the list. > Yeah, which makes any hosting video streaming outside Israel a joke, > unless you have lots of money either for a slice of optic from Med1 or > using anything like Akamai's services. That's life in the Internet. :-) > QOS for traceroute? never heard of this thing before... Sure, they would very likely traffic shape ping and traceroute to be really good, to make customers think it's not their ISP's problem. > I don't want to be sued, but my hunch tells me that all of the ISP's > are doing QOS for stuff like Bittorrent, emule/edonkey etc. but not > blocking those ports (which would be a joke when it comes to > bittorrent.. It doesn't care if you block 6881-6888 TCP as long as you > open something else). I know that Netvision does not block SIP nor, bit torrent but according to several users on other lists, 012 blocks (or did block) STEAM (a gaming site) and really slows down FTP. Geoff. -- Geoffrey S. Mendelson, Jerusalem, Israel [EMAIL PROTECTED] N3OWJ/4X1GM = To unsubscribe, send mail to [EMAIL PROTECTED] with the word "unsubscribe" in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
Re: major packet loss at hot server
Hi, > Not at all. Remember that the packets have to go through gateways. So I wonder, are those ISP's using Cisco's 1XXX/2XXX routers which makes those packet loss? An ISP should have a very fast equipment which shouldn't loose packet like nuts. Thats unacceptable these days, specially when it comes to any serious video streaming, for example. Few days ago I did a small test from a hosted server in one of the big ISP's here and tried to do some HD streaming for a test I'm performing. I have 5MBit ADSL, so I thought that it should be sufficient.. It was - but due to the packet loss, the stream becomes jerky playback (not because of my machines here at home). > If your ISP has a direct connection to another ISP, or is part of > the same network, for example ActCom and BBL, or 013 and Netvision, > then things will go very smoothly. If they are not, you are dependent > upon their interconnection. As much as I know (and it least according to my tests which I did 2 minutes ago with traceroute), all of the ISP's are connected between themselves with fiber optics directly. > At one time all packets between ISPs went via the IIX, which tends to > become overloaded in the afternoon. I don't know if that has changed, > and if it has for all packets, or just ones that the ISPs want to have > high priority. Now that they are connected between themselves, I don't think IIX is alive any more. anyone knows whats the status of IIX these days? Doron? > International sites are different. Your ISP connects to another ISP, > which connects to another ISP and so on. For example, I can get > ping times of less than 200ms to some sites in the U.S. and > over a second to others. Yeah, which makes any hosting video streaming outside Israel a joke, unless you have lots of money either for a slice of optic from Med1 or using anything like Akamai's services. > Hopefully BEZEQ passes all tunneled data equally, it's up to your ISP > to forward the data as it sees fit. Israel has no regulations about > port and protocol blocking or traffic shaping (QOS routing). QOS for traceroute? never heard of this thing before... > All ISPs do traffic shaping and 012 is notorious for it. I don't want to be sued, but my hunch tells me that all of the ISP's are doing QOS for stuff like Bittorrent, emule/edonkey etc. but not blocking those ports (which would be a joke when it comes to bittorrent.. It doesn't care if you block 6881-6888 TCP as long as you open something else). Thanks, Hetz = To unsubscribe, send mail to [EMAIL PROTECTED] with the word "unsubscribe" in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
Re: major packet loss at hot server
On Sun, Mar 23, 2008 at 10:32:28AM +0200, Omer Zak wrote: > > I found that when mtr'ing Israeli hosts, I get packet loss. When > mtr'ing international hosts (www.yahoo.com, www.google.com, zak.co.il > [hosted outside of Israel], I get less packet loss than when mtr'ing > Israeli hosts. Weird! Not at all. Remember that the packets have to go through gateways. If your ISP has a direct connection to another ISP, or is part of the same network, for example ActCom and BBL, or 013 and Netvision, then things will go very smoothly. If they are not, you are dependent upon their interconnection. At one time all packets between ISPs went via the IIX, which tends to become overloaded in the afternoon. I don't know if that has changed, and if it has for all packets, or just ones that the ISPs want to have high priority. International sites are different. Your ISP connects to another ISP, which connects to another ISP and so on. For example, I can get ping times of less than 200ms to some sites in the U.S. and over a second to others. > I am connected via ADSL and 012.net.il. Hopefully BEZEQ passes all tunneled data equally, it's up to your ISP to forward the data as it sees fit. Israel has no regulations about port and protocol blocking or traffic shaping (QOS routing). All ISPs do traffic shaping and 012 is notorious for it. Geoff. -- Geoffrey S. Mendelson, Jerusalem, Israel [EMAIL PROTECTED] N3OWJ/4X1GM = To unsubscribe, send mail to [EMAIL PROTECTED] with the word "unsubscribe" in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
Re: major packet loss at hot server
After having seen some E-mail messages about this subject, I decided to run my own tests. I found that when mtr'ing Israeli hosts, I get packet loss. When mtr'ing international hosts (www.yahoo.com, www.google.com, zak.co.il [hosted outside of Israel], I get less packet loss than when mtr'ing Israeli hosts. Weird! I am connected via ADSL and 012.net.il. --- Omer On Sun, 2008-03-23 at 09:19 +0200, Noam Meltzer wrote: > Hi, > > I live in Givatayim, and connected to the internet through HOT & > Bezeqint. > Also, the connection to Bezeqint is without VPN (aka. חייגן) > > Apparently, I have some packet loss too. It appears like the packet > loss are occurring exactly in the connection between HOT and Bezeqint. > > The following is the output of mtr to walla.co.il. -- MS-Windows is the Pal-Kal of the PC world. My own blog is at http://www.zak.co.il/tddpirate/ My opinions, as expressed in this E-mail message, are mine alone. They do not represent the official policy of any organization with which I may be affiliated in any way. WARNING TO SPAMMERS: at http://www.zak.co.il/spamwarning.html To unsubscribe, send mail to [EMAIL PROTECTED] with the word "unsubscribe" in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
Re: major packet loss at hot server
Hi, I live in Givatayim, and connected to the internet through HOT & Bezeqint. Also, the connection to Bezeqint is without VPN (aka. חייגן) Apparently, I have some packet loss too. It appears like the packet loss are occurring exactly in the connection between HOT and Bezeqint. The following is the output of mtr to walla.co.il. My traceroute [v0.72] meydele (0.0.0.0) Sun Mar 23 09:14:34 2008 Keys: Help Display mode Restart statistics Order of fields quit Packets Pings Host Loss% Snt Last Avg Best Wrst StDev 1. tsnoam-router.tokhes 0.0%192.0 3.1 1.0 8.6 2.4 2. 10.175.128.1 0.0%19 10.0 12.2 7.7 26.3 5.4 3. 172.18.8.42 0.0%19 17.3 16.0 8.2 45.6 9.2 4. 172.17.0.66 0.0%19 10.8 15.7 8.2 32.1 6.3 5. bzq-219-189-5.cablep.bezeqint.net 52.9%18 12.6 26.7 10.6 58.8 17.9 bzq-179-124-5.static.bezeqint.net 6. bzq-219-189-2.cablep.bezeqint.net0.0%18 15.4 19.2 8.5 95.7 19.8 bzq-179-124-2.static.bezeqint.net 7. bzq-179-59-1.static.bezeqint.net 0.0%18 12.7 16.2 8.2 41.5 8.0 bzq-115-188-1.static.bezeqint.net 8. bzq-25-88-170.static.bezeqint.net0.0%18 12.2 15.7 10.9 37.0 6.2 9. 192.118.68.130.0%18 20.6 17.4 9.3 29.6 6.0 10. 192.118.82.140 0.0%18 26.0 17.1 9.9 26.1 4.8
Re: major packet loss at hot server
nteresting indeed. I will check these machines. BTW, someone suggested to run mtr with a higher mtu. I tried with this command: mtr --psize 1500 google.com . With this size I get an empty screen. Also tried with psize 800 and I also get empty screen. With psize 500 I get the path to google but then I get around 55-60% packet loss. If I ping ping -s 1500 google.com PING google.com (64.233.167.99) 1500(1528) bytes of data. --- google.com ping statistics --- 15 packets transmitted, 0 received, 100% packet loss, time 14001ms ping -s 800 google.com PING google.com (64.233.167.99) 800(828) bytes of data. --- google.com ping statistics --- 12 packets transmitted, 0 received, 100% packet loss, time 11022ms ping -s 500 google.com PING google.com (64.233.167.99) 500(528) bytes of data. 64 bytes from py-in-f99.google.com (64.233.167.99): icmp_seq=1 ttl=236 (truncated) 64 bytes from py-in-f99.google.com (64.233.167.99): icmp_seq=2 ttl=236 (truncated) 64 bytes from py-in-f99.google.com (64.233.167.99): icmp_seq=3 ttl=236 (truncated) 64 bytes from py-in-f99.google.com (64.233.167.99): icmp_seq=4 ttl=236 (truncated) 64 bytes from py-in-f99.google.com (64.233.167.99): icmp_seq=5 ttl=236 (truncated) 64 bytes from py-in-f99.google.com (64.233.167.99): icmp_seq=6 ttl=236 (truncated) 64 bytes from py-in-f99.google.com (64.233.167.99): icmp_seq=7 ttl=236 (truncated) 64 bytes from py-in-f99.google.com (64.233.167.99): icmp_seq=8 ttl=236 (truncated) 64 bytes from py-in-f99.google.com (64.233.167.99): icmp_seq=9 ttl=236 (truncated) 64 bytes from py-in-f99.google.com (64.233.167.99): icmp_seq=10 ttl=236 (truncated) 64 bytes from py-in-f99.google.com (64.233.167.99): icmp_seq=11 ttl=236 (truncated) 64 bytes from py-in-f99.google.com (64.233.167.99): icmp_seq=12 ttl=236 (truncated) 64 bytes from py-in-f99.google.com (64.233.167.99): icmp_seq=13 ttl=236 (truncated) 64 bytes from py-in-f99.google.com (64.233.167.99): icmp_seq=14 ttl=236 (truncated) 64 bytes from py-in-f99.google.com (64.233.167.99): icmp_seq=15 ttl=236 (truncated) 64 bytes from py-in-f99.google.com (64.233.167.99): icmp_seq=16 ttl=236 (truncated) 64 bytes from py-in-f99.google.com (64.233.167.99): icmp_seq=17 ttl=236 (truncated) --- google.com ping statistics --- 17 packets transmitted, 17 received, 0% packet loss, time 16012ms rtt min/avg/max/mdev = 178.251/184.751/193.826/4.534 ms Now I know from someone who checks security at various places that those who are using adsl, he saw something called quality of service. When people complain, they start to put more centrals because they are afraid to lose customers and put more centrals. The fact that you have 5MBit/s doesn't mean you get this speed if you are far away from the nearest central. Anyone else suffers from packet loss? On Sat, Mar 22, 2008 at 1:02 AM, Hetz Ben Hamo <[EMAIL PROTECTED]> wrote: > I use ADSL (5Mbit). My ISP: Netvision. > > It seems that they also have some serious packet drops even from my > machine to Netvision! check this out: (problems are marked with > arrows) > > ./mtr -c 10 -r netvision.net.il > HOST: witch.dyndns.orgLoss% Snt Last Avg Best Wrst StDev > 1. 192.168.1.1 0.0%101.3 0.9 0.7 1.4 0.3 > 2. lo0.lns05.hfa.nv.net.il 0.0%10 11.4 26.6 11.4 147.4 42.5 > -->> 3. vl201.coresw1.hfa.nv.net.il 30.0%10 30.6 16.3 12.0 > 30.6 6.4 <<--- > 4. po41.srvc4.hfa.nv.net.il 0.0%10 30.5 16.6 11.7 30.5 7.4 > 5. ??? 100.0100.0 0.0 0.0 0.0 0.0 > > ./mtr -c 10 -r www.ynet.co.il > HOST: witch.dyndns.orgLoss% Snt Last Avg Best Wrst StDev > 1. 192.168.1.1 0.0%100.8 0.9 0.7 1.4 0.2 > 2. lo0.lns05.hfa.nv.net.il 0.0%10 11.5 11.6 11.3 12.1 0.2 > -->> 3. vl201.coresw1.hfa.nv.net.il 40.0%10 12.1 14.6 11.8 > 27.1 6.1 <<-- > 4. po41.srvc4.hfa.nv.net.il 0.0%10 11.6 12.9 11.6 17.9 2.1 > 5. 212.143.162.136 0.0%10 14.2 13.2 11.4 16.3 1.6 > > Hmm, I wonder if Netvision knows about this.. > > Hetz > > > > On Fri, Mar 21, 2008 at 10:10 PM, sara fink <[EMAIL PROTECTED]> wrote: > > Hello Everyone > > > > I am having major problem with packet loss at some hot server that > > sits in tel aviv. www.dnsstuff.com revealed this info. > > > > I would like to know how many people suffer from this problem. > > > > For this task mtr program is needed. The program can be downloaded at > > http://www.bitwizard.nl/mtr/ . > > > > The description of the program is mtr combines the functionality > > of the traceroute and ping programs in a single network diagnostic > > tool. > > > >As mtr starts, it investigates the network connection between the > > host mtr runs on and HOSTNAME. by sending packets with purposly > > low TTLs. It continues to send packets with low TTL, noting the > > response time of
Re: major packet loss at hot server
I use ADSL (5Mbit). My ISP: Netvision. It seems that they also have some serious packet drops even from my machine to Netvision! check this out: (problems are marked with arrows) /mtr -c 10 -r netvision.net.il HOST: witch.dyndns.orgLoss% Snt Last Avg Best Wrst StDev 1. 192.168.1.1 0.0%101.3 0.9 0.7 1.4 0.3 2. lo0.lns05.hfa.nv.net.il 0.0%10 11.4 26.6 11.4 147.4 42.5 -->> 3. vl201.coresw1.hfa.nv.net.il 30.0%10 30.6 16.3 12.0 30.6 6.4 <<--- 4. po41.srvc4.hfa.nv.net.il 0.0%10 30.5 16.6 11.7 30.5 7.4 5. ??? 100.0100.0 0.0 0.0 0.0 0.0 /mtr -c 10 -r www.ynet.co.il HOST: witch.dyndns.orgLoss% Snt Last Avg Best Wrst StDev 1. 192.168.1.1 0.0%100.8 0.9 0.7 1.4 0.2 2. lo0.lns05.hfa.nv.net.il 0.0%10 11.5 11.6 11.3 12.1 0.2 -->> 3. vl201.coresw1.hfa.nv.net.il 40.0%10 12.1 14.6 11.8 27.1 6.1 <<-- 4. po41.srvc4.hfa.nv.net.il 0.0%10 11.6 12.9 11.6 17.9 2.1 5. 212.143.162.136 0.0%10 14.2 13.2 11.4 16.3 1.6 Hmm, I wonder if Netvision knows about this.. Hetz On Fri, Mar 21, 2008 at 10:10 PM, sara fink <[EMAIL PROTECTED]> wrote: > Hello Everyone > > I am having major problem with packet loss at some hot server that > sits in tel aviv. www.dnsstuff.com revealed this info. > > I would like to know how many people suffer from this problem. > > For this task mtr program is needed. The program can be downloaded at > http://www.bitwizard.nl/mtr/ . > > The description of the program is mtr combines the functionality > of the traceroute and ping programs in a single network diagnostic > tool. > >As mtr starts, it investigates the network connection between the > host mtr runs on and HOSTNAME. by sending packets with purposly > low TTLs. It continues to send packets with low TTL, noting the > response time of the intervening routers. This allows mtr to print > the response percentage and response times of the internet route > to HOSTNAME. A sudden increase in packetloss or response time > is often an indication of a bad (or simply overloaded) link. > > After installing this program please run the command mtr google.com or > even mtr walla.co.il mtr ynet.co.il > > I got in all 3 urls ~75% packet loss at ip 213.57.43.199 and at > 213.57.43.22 (or 14) another ~20% packet loss. > > Please inform me how many people suffer from this problem and who is > their isp. Mine is 012. but the ips mentioned belong to hot. > > I already talked with a nice technician at hot and he promissed to > give me an answer. Meanwhile at 012 tried to help me and in the end he > told me it's a operating sytem problem. I just hate to hear such > stupid excuses. I tried bot with and without iptables and it's the > same. Instead of solving the problem they blame the OS. And all this > happens with router or without. > > Besides that, the first IP is actually border gateway. > > Thanks for your help > > = > To unsubscribe, send mail to [EMAIL PROTECTED] with > the word "unsubscribe" in the message body, e.g., run the command > echo unsubscribe | mail [EMAIL PROTECTED] > > -- Skepticism is the lazy person's default position. my blog (hebrew): http://benhamo.org = To unsubscribe, send mail to [EMAIL PROTECTED] with the word "unsubscribe" in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
Re: major packet loss at hot server
I was having the same problem with HOT in Lehavim. I came near 30% packet loss. Both a linux laptop and WinXP desktop had the same results. Still the bezeqin tech support guy insisted that the problem was with the OS and I had to format and re-install windows. After 30 minutes on line with him I started getting angry and he gave the call to a more capable TC guy, he managed to realize the problem was with the link and forwarded the problem to HOT who claimed everything was normal. I guess that he managed to convince them that it isn't so because after a few hours things came back to normal. sara fink wrote: Hello Everyone I am having major problem with packet loss at some hot server that sits in tel aviv. www.dnsstuff.com revealed this info. I would like to know how many people suffer from this problem. For this task mtr program is needed. The program can be downloaded at http://www.bitwizard.nl/mtr/ . The description of the program is mtr combines the functionality of the traceroute and ping programs in a single network diagnostic tool. As mtr starts, it investigates the network connection between the host mtr runs on and HOSTNAME. by sending packets with purposly low TTLs. It continues to send packets with low TTL, noting the response time of the intervening routers. This allows mtr to print the response percentage and response times of the internet route to HOSTNAME. A sudden increase in packetloss or response time is often an indication of a bad (or simply overloaded) link. After installing this program please run the command mtr google.com or even mtr walla.co.il mtr ynet.co.il I got in all 3 urls ~75% packet loss at ip 213.57.43.199 and at 213.57.43.22 (or 14) another ~20% packet loss. Please inform me how many people suffer from this problem and who is their isp. Mine is 012. but the ips mentioned belong to hot. I already talked with a nice technician at hot and he promissed to give me an answer. Meanwhile at 012 tried to help me and in the end he told me it's a operating sytem problem. I just hate to hear such stupid excuses. I tried bot with and without iptables and it's the same. Instead of solving the problem they blame the OS. And all this happens with router or without. Besides that, the first IP is actually border gateway. Thanks for your help = To unsubscribe, send mail to [EMAIL PROTECTED] with the word "unsubscribe" in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED] = To unsubscribe, send mail to [EMAIL PROTECTED] with the word "unsubscribe" in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
Re: major packet loss at hot server
Their magic say "os problem" OR "something in the OS blocks it". There was a more educated tech at my place and he saw. He had windows on his laptop. The ip is definitely at hot. When you had the problem? I see it immediately in dc++. It doesn't connect to hubs. I live in Haifa. But the technician said to me that they have servers in Tel Aviv and Netanya. On Fri, Mar 21, 2008 at 10:55 PM, Peleg Wasserman <[EMAIL PROTECTED]> wrote: > I was having the same problem with HOT in Lehavim. > I came near 30% packet loss. Both a linux laptop and WinXP desktop had > the same results. > Still the bezeqin tech support guy insisted that the problem was with > the OS and I had to format and re-install windows. After 30 minutes on > line with him I started getting angry and he gave the call to a more > capable TC guy, he managed to realize the problem was with the link and > forwarded the problem to HOT who claimed everything was normal. I guess > that he managed to convince them that it isn't so because after a few > hours things came back to normal. > > > > > sara fink wrote: > > Hello Everyone > > > > I am having major problem with packet loss at some hot server that > > sits in tel aviv. www.dnsstuff.com revealed this info. > > > > I would like to know how many people suffer from this problem. > > > > For this task mtr program is needed. The program can be downloaded at > > http://www.bitwizard.nl/mtr/ . > > > > The description of the program is mtr combines the functionality > > of the traceroute and ping programs in a single network diagnostic > > tool. > > > >As mtr starts, it investigates the network connection between the > > host mtr runs on and HOSTNAME. by sending packets with purposly > > low TTLs. It continues to send packets with low TTL, noting the > > response time of the intervening routers. This allows mtr to print > > the response percentage and response times of the internet route > > to HOSTNAME. A sudden increase in packetloss or response time > > is often an indication of a bad (or simply overloaded) link. > > > > After installing this program please run the command mtr google.com or > > even mtr walla.co.il mtr ynet.co.il > > > > I got in all 3 urls ~75% packet loss at ip 213.57.43.199 and at > > 213.57.43.22 (or 14) another ~20% packet loss. > > > > Please inform me how many people suffer from this problem and who is > > their isp. Mine is 012. but the ips mentioned belong to hot. > > > > I already talked with a nice technician at hot and he promissed to > > give me an answer. Meanwhile at 012 tried to help me and in the end he > > told me it's a operating sytem problem. I just hate to hear such > > stupid excuses. I tried bot with and without iptables and it's the > > same. Instead of solving the problem they blame the OS. And all this > > happens with router or without. > > > > Besides that, the first IP is actually border gateway. > > > > Thanks for your help > > > > = > > To unsubscribe, send mail to [EMAIL PROTECTED] with > > the word "unsubscribe" in the message body, e.g., run the command > > echo unsubscribe | mail [EMAIL PROTECTED] > > > > > > = To unsubscribe, send mail to [EMAIL PROTECTED] with the word "unsubscribe" in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
major packet loss at hot server
Hello Everyone I am having major problem with packet loss at some hot server that sits in tel aviv. www.dnsstuff.com revealed this info. I would like to know how many people suffer from this problem. For this task mtr program is needed. The program can be downloaded at http://www.bitwizard.nl/mtr/ . The description of the program is mtr combines the functionality of the traceroute and ping programs in a single network diagnostic tool. As mtr starts, it investigates the network connection between the host mtr runs on and HOSTNAME. by sending packets with purposly low TTLs. It continues to send packets with low TTL, noting the response time of the intervening routers. This allows mtr to print the response percentage and response times of the internet route to HOSTNAME. A sudden increase in packetloss or response time is often an indication of a bad (or simply overloaded) link. After installing this program please run the command mtr google.com or even mtr walla.co.il mtr ynet.co.il I got in all 3 urls ~75% packet loss at ip 213.57.43.199 and at 213.57.43.22 (or 14) another ~20% packet loss. Please inform me how many people suffer from this problem and who is their isp. Mine is 012. but the ips mentioned belong to hot. I already talked with a nice technician at hot and he promissed to give me an answer. Meanwhile at 012 tried to help me and in the end he told me it's a operating sytem problem. I just hate to hear such stupid excuses. I tried bot with and without iptables and it's the same. Instead of solving the problem they blame the OS. And all this happens with router or without. Besides that, the first IP is actually border gateway. Thanks for your help = To unsubscribe, send mail to [EMAIL PROTECTED] with the word "unsubscribe" in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]