Re: major packet loss at hot server

2008-04-04 Thread Jonathan Ben Avraham

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 linux-il@cs.huji.ac.il
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
different routes through Netvisions AS, mainly depending on where the

Re: major packet loss at hot server

2008-04-04 Thread Michael Tewner
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 | mail [EMAIL PROTECTED]



Re: major packet loss at hot server

2008-04-04 Thread Michael Tewner
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 help

  =
  To unsubscribe, send mail to [EMAIL PROTECTED] with
  the word unsubscribe in the message body, e.g., run the command
  echo unsubscribe | 

[HAIFUX Lecture] IPv6 in the Linux Kernel (Advanced Linux Kernel Networking) by Rami Rosen

2008-04-04 Thread Orr Dunkelman
Next Monday, 7th of April, at 18:30 the Haifa Linux Club, will gather
to enjoy Rami Ronen's presenation about

IPv6 in the Linux Kernel (Advanced Linux Kernel Networking)

Abstract

This lecture is a sequel to the Linux Kernel Networking lecture and
Advanced Linux Kernel Networking - Neighboring Subsystem; IPSec.

This lecture will mostly deal with IPV6 implementation in the linux
kernel. We will also discuss some IPV6 user space tools, and also draw
a comparison between IPV6 and IPV4.

Among the topics we will deal with are:

* IPV6
* General background and history
* ICMPV6
* Router Advertisements and Router Solicitations
  o Radvd daemon
* Autoconfiguration
  o DHCPV6
  o MLDv1 and MLDv2
  o IPV6 header
  o SOKCET API

Note: If time permits, we will also talk shortly about Network
Namespaces and Bridging Subsystem.


==

We meet in Taub building, room 6. For instructions see:
http://www.haifux.org/where.html

Attendance is free, and you are all invited!

==

Future Lectures:

None. You see, our queue is empty. Now I don't want to sound like the
Polish mother who can sit in the dark while you go outside in a cold
night without sweater and not calling her once you arrive (Sheko'o
Ye'hie li Tov), so I won't say a word. I will just sit here quite,
and look at the mailbox, hoping that someone, maybe YOU, will send an
email to [EMAIL PROTECTED] proposing an interesting presentation. I
mean, I already have my diploma, and the bell is for me and for you.
And of course, Don't drink marijuana there, you hear me?!?.

We are always interested in hearing your talks and ideas. If you wish
to give a talk, hold a discussion, or just plan some event haifux
might be interested in, please contact us at [EMAIL PROTECTED]

-- 
Orr Dunkelman,
[EMAIL PROTECTED]

Any human thing supposed to be complete, must for that reason infallibly
be faulty -- Herman Melville, Moby Dick.

GPG fingerprint: C2D5 C6D6 9A24 9A95 C5B3 2023 6CAB 4A7C B73F D0AA
(This key will never sign Emails, only other PGP keys. The key
corresponds to [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

2008-04-04 Thread Amos Shapira
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