Re: ip options
:-) - Original Message From: joel jaeggli To: Ron Bonica Cc: nanog Sent: Wed, November 4, 2009 3:41:26 AM Subject: Re: ip options How about unused and/or private/local diffserve code points? Ron Bonica wrote: > Folks, > > I would love to see the IETF OPSEC WG publish a document on the pros and > cons of filtering optioned packets. > > Would anybody on this list be willing to author an Internet Draft? > > Ron > (co-director IETF O&M Area) > > Luca Tosolini wrote: >> Experts, >> out of the well-known values for ip options: >> >> x...@r4# set ip-options ? >> Possible completions: >> Range of values >> [ Open a set of values >> any Any IP option >> loose-source-route Loose source route >> route-record Route record >> router-alert Router alert >> security Security >> stream-id Stream ID >> strict-source-route Strict source route >> timestamp Timestamp >> >> I can only think of: >> - RSVP using router-alert >> - ICMP using route-record, timestamp >> >> But I can not think of any other use of any other IP option. >> Considering the security hazard that they imply, I am therefore thinking >> to drop them. >> >> Is any other ip options used by: ospf, isis, bgp, ldp, igmp, pim, bfd? >> Thanks, >> Luca. >> >> >> > __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: HE.net, Fremont-2 outage?
Has anyone managed to get a root cause from HE yet regarding what happened? I'm still waiting for them to get back to me over 24 hours later... Scott On Tue, Nov 3, 2009 at 10:50 AM, Tico wrote: > I can't get through to Hurricane Electric, and they seem to be having an > outage at their Fremont-2 facility again (as of 17:30 UTC or thereabouts) -- > ticket system is unanswered, phones go to voicemail, all equipment is > unreachable. > > Does anyone here have a presence at 48233 Warm Springs Blvd, that can > provide any information about this? I got hit by the ATS failure last month, > so I guess it's possible that that equipment may have flaked again. > > -t > >
Re: Anyone having complaints about connectivity from people in asia?
On Wed, Nov 4, 2009 at 10:01 AM, Drew Weaver wrote: > Packet loss, latency, etc? > > We have 6 connections and there doesn't seem to be any real theme between > source/dest IPs except everyone complaining appears to be in Asia (pakistan, > etc). > > -Drew There's always someone somewhere complaining about packet loss and latency; this *is* the Internet we're talking about, after all. it's usually not the source/dest IPs that matter, as much as the ones in the middle. do traceroutes, and look for points of commonality; observe which ASNs show up in common along the different paths, see if there's locations in common across the different traceroutes (do they all go through a common city that might have a localized issue like an earthquake, tsunami, flood, etc.). Matt
Re: HE.net, Fremont-2 outage?
Scott Howard wrote: > Has anyone managed to get a root cause from HE yet regarding what happened? > > I'm still waiting for them to get back to me over 24 hours later... Good luck. I'm still waiting for them to get back to me about the outage six weeks ago. I called and emailed all sorts of folks there, got the run around for a week at least. Eventually got promises of "so and so should let you know shortly" but that never occurred. Cheers, Stef
Re: Speed Testing and Throughput testing
We had a problem where our (mostly research network connected, international) users were getting generally low HTTP transfer speeds, even though the path was often gigabit. The classic high bandwidth/high latency problem. Initially I tried using iperf/ndt and friends but found that iperf required too much user knowledge and interaction, and NDT was sometimes inaccurate at diagnosing problems -- it seemed to be overly fond of saying there was a duplex mismatch or congestion. Iperf in TCP mode either requires manually seeking the number of streams to try and find optimum throughput, or doing window size tweaks. I also found that packet captures were useful for discovering problems in the path; you can load it up in wireshark or tcptrace and get a sequence no. vs time graph, look for packetloss, or other good things like that. Anyways I didn't find much out there in terms of automating this type of thing (simple throughput tests with packet capture) so I just ended up making my own. It does a dump of 10 sec. of test traffic, uses a somewhat dumb algorithm to seek up the number of TCP streams, and gets an AS path from a BGP route server and displays it to the user. The caveat is that it only tests your download speed, not upload, since that was primarily what I was interested in. You can give it a try at: http://caranthir.dao.nrc.ca/netperf-www/ (login nanog/nanog). User guide here: http://www.cadc-ccda.hia-iha.nrc-cnrc.gc.ca/netperf/testdetail.shtml I might end up packaging and releasing the code if there is interest. On Mon, 2 Nov 2009 15:56:56 -0600 Mark Urbach wrote: > Anyone have a good solution to get "accurate" speed results when testing at > 10/100/1000 Ethernet speeds? > > Do you have a server/software that customer can test too? > > > > Thanks, > Mark Urbach > PinPoint Communications, Inc. > 100 N. 12th St Suite 500 > Lincoln, NE 68508 > 402-438-6211 ext 1923 Office > 402-660-7982 Cell > mark.urb...@pnpt.com > [cid:image003.jpg@01CA5BD5.1A5CEE20] > >