for the columns
you are actually interested in, it may not even be too inefficient.
--
Simon Leinen [EMAIL PROTECTED]
SWITCH http://www.switch.ch/misc/leinen/
Computers hate being anthropomorphized.
On Mon, 8 Jul 2002 19:47:52 -0400, "Phil Rosenthal" <[EMAIL PROTECTED]> said:
> As far as I can tell, neither Foundry Bigiron, nor Cisco 65xx
> support IPV6 (I could be wrong).
It is rumored that Cisco has software for the 6500 that does IPv6,
albeit "in software" on the MSFC. And I'm sure they
Christopher L Morrow writes:
> On Sat, 16 Jul 2005, Iljitsch van Beijnum wrote:
>> And I'm sure Sprint and Verio (MCI/Worldcom/UUNET too? I have a
> I know verio does, Sprint I believe also does, and UUNET
> does... everyone has restrictions on the service though (native or
> tunnel'd type restri
[CC'ing Stanislav Shalunov, who does the Internet2 weekly reports.]
Marshall Eubanks writes, in response to Jordi's "8% IPv6" anecdote:
> These estimates seem way high and need support. Here is a counter-example.
While I'm also skeptical about the representativeness of Jordi's
estimates, this is
Kevin Loch writes:
> Does anyone have reachability data for c-root during this episode?
The RIPE NCC "DNSMON" service has some:
http://dnsmon.ripe.net/dns-servmon/server/plot?server=c.root-servers.net&type=drops&tstart=1128246543&tstop=1128972253
According to BGPlay for that particular prefix f
Daniel Roesen writes:
> On Fri, Oct 14, 2005 at 10:45:33PM -0400, Todd Vierling wrote:
>> Maybe to start -- but again, what kind of 6to4 traffic level are we
>> expecting yet?
> Peak or average? Think twice before answering. :-)
> I'm told there are 6to4 relays seeing in excess of 100mbps. Not
>
ing more evil
(such as fine-grained traffic engineering).
AS4151, could you please stop this?
Thanks & regards,
--
Simon Leinen.
SWITCH
Jay,
> Is anyone else experiencing DNS timeout errors. I've tried using
> multiple name resolvers, and tested multiple domain names using
> different name servers, and I keep getting "name not found" errors.
> Trying the same domain name a second time, and it resolves ok. This
> all started a f
Arife Vural writes:
[in response to Florian Frotzler <[EMAIL PROTECTED]>:]
>> To my knowledge, the myas-tool/-service from RIPE NCC is kind of
>> doing what you like to achive.
> MyASN is working on user-based. To get the alarm for unexpected
> routing patterns, you should set it up an account be
Drew Weaver writes:
> Also the other question I had was are there any very good either
> open source or fairly affordable netflow analyzer software packages
> out there right now?
Making a recommendation is difficult, because there is such a wide
variety of requirements, depending on context (bac
On Wed, 4 Sep 2002 05:30:46 -0400 (EDT), "jeffrey.arnold" <[EMAIL PROTECTED]> said:
> Foundry makes a very good, very stable bgp speaker. I've had them in
> my network alongside cisco's and juniper's for a couple of years
> now, and i've never run into any bgp implementation problems that i
> wou
Mikael Abrahamsson writes:
> Tier 1 operators do not do "best effort" really, at least not in
> their cores (and they have the SLAs to back it up). They buy hugely
> expensive top notch gear (Cisco 12000 (and now CRS:s) and Junipers)
> to get the big packet buffers, the fast reroutes and the full
Peter Lothberg writes:
[...]
> Optics type: VSR2000-3R2 (2km)
> Clock source: line (actual) line (configured)
> Optical Power Monitoring (accuracy: +/- 1dB)
> Rx power = 1562.3280 mW, 31.9 dBm
Ouch!
Some amplifiers you have there...
> Tx power = 15.4640 mW, 11
Michael Dillon writes:
> In the paper
> http://klamath.stanford.edu/~keslassy/download/tr04_hpng_060800_sizing.pdf
That's also in the (shorter) SIGCOMM'04 version of the paper.
> they state as follows:
> -
> While we have evidence that buffers
> can be made smaller, we haven't
Mikael Abrahamsson writes:
> On Mon, 6 Sep 2004, Simon Leinen wrote:
>> Rather than over-dimensioning the backbone for two or three users
>> (the "Petabyte crowd"), I'd prefer making them happy with a special
>> TCP.
> Tune your max window size so it won&
Daniel Roesen writes:
> On Thu, Nov 11, 2004 at 08:44:57AM -0800, Kevin Oberman wrote:
>> We have renumbered IPv6 space a couple of times when we were
>> developing our addressing plan. (We have a /32.) Renumbering was
>> pretty trivial for most systems, but servers requiring a fixed
>> address we
Robert Mathews writes:
> On Thu, 11 Nov 2004, Alexei Roudnev wrote:
>> Hmm - just introduce some jitter into your network, and add random
>> delay to the short packets - and no VoIP in your company -:).
> Alexei:
> How exactly then would anyone implement this, without screwing-up the
> overall p
Daniel Roesen writes:
> On Fri, Nov 12, 2004 at 05:19:36PM +0100, Simon Leinen wrote:
>> On Solaris, you would use the "token" option (see the extract from
>> "man ifconfig" output below). You can simply put "token ::1234:5678"
>> into /etc/
Daniel Roesen writes:
> Well, it boils down that if you have enough customers, you seem to
> get away with about any antisocial behaviour on the net.
You don't need to have many customers, it's just more fun if you have
a larger space that you can deaggregate. Since everybody stopped
filtering y
For the sake of completeness, Sun just announced a new Crypto
accelerator board with GigE interfaces that does SSL and IPSec VPNs,
and claims 800 Mb/s "bulk 3DES encryption":
http://www.sun.com/products/networking/sslaccel/suncryptoaccel4000/index.html
--
Simon.
Deepak Jain writes:
[a response with excellent pieces of advice on CWDM vs. DWDM.]
> If you are planning more than just 1 DF run, you could buy the less
> expensive solution and just swap it out when you need something more and use
> the CWDM solution somewhere else.
Yes. What we often do
Frank Louwers writes:
> On Tue, Jan 13, 2004 at 04:12:13PM -0500, Patrick W. Gilmore wrote:
> Filtering on a /20 or whatever (up to /24) is a bad thing because
> RIPE (and maybe APNIC) actually gives out /24 PI space, that comes
> out of RIPE's /8's, not your upstream's /20 or /16 or /whatever...
if anyone else has similar concerns,
> or an opinion on whether these IP addresses should actually be
> blocked.
I'd recommend against it, due to collateral damage and more general
end-to-end arguments.
--
Simon Leinen [EMAIL PROTECTED]
SWIT
We use OSPFv3 on our backbone (OSPFv2 for IPv4, separate routing
processes but largely identical metric/timeout configuration) using
mostly 12.2(17d)SXB on Catalyst 6500/7600 OSRs and various 12.3T
(pre-)releases on 7200/7500. Works fine.
--
Simon.
Priscilla,
> Questions arose while trying to explain proposed TCP fixes to my
> students. Can y'all help me with these?
> We were going over the "Transmission Control Protocol security
> considerations draft-ietf-tcpm-tcpsecure-00.txt" document here when
> the questions arose:
> http://www.ietf
Robert E Seastrom writes:
> Yes and no. CEF is {src, dst} hash IIRC, and "per-flow" usually
> means {src, srcport, dst, dstport, [proto, tos]} hash in my
> experience.
Correct.
The Catalyst 6500/7600 OSR with Sup2/Sup32/Sup720 can be configured to
hash based on L4 ports in addition to the IP ad
Gunther Stammwitz writes:
> ==> Which tools (under linux) are you using in order to measure your
> own network ore on of your upstreams in terms of "gameability" or
> voip-usage?
My favorite tool for assessing delay distribution and loss over time
is Tobi Oetiker's (of MRTG fame) SmokePing (http:
Jeroen Massar writes:
> The answer to your question: RFC4255
> "Using DNS to Securely Publish Secure Shell (SSH) Key Fingerprints"
> http://www.ietf.org/rfc/rfc4255.txt
Yes, that's cool if your SSH client supports it (recent OpenSSH's do).
> You will only need to stuff the FP's into SSHFP DNS RR
Miguel,
> We have had some problems of being beaten back. Our space, being
> annocunced by AS 16592, is 190.5.128.0/19
I only see 190.5.128.0/21, and because it is our policy to ignore
more-specifics from "PA" space (including anything more specific than
/21 from 190.0.0.0/8 and the other LACNIC
Frank Bulk writes:
> Except if the cable companies want to get rid of the 5% of heavy
> users, they can't raise the prices for that 5% and recover their
> costs. The MSOs want it win-win: they'll bring prices for metered
> access slightly lower than "unlimited" access, making it attractive
> for
Stupid typo in my last message, sorry.
> While I think this is basically a sound approach, I'm skeptical that
> *slightly* lowering prices will be sufficient to convert 80% of the
> user base from flat to unmetered pricing. [...]
"METERED pricing", of course.
--
Simon.
Iljitsch van Beijnum writes:
> Well, if they had problems like this in the past, then I wouldn't
> trust them to get it right. Which means that it's probably a good
> idea if EVERYONE starts filtering what they allow in their tables
> from PCCW. Obviously that makes it very hard for PCCW to start
Martin A Brown writes:
> Late last night, after poring through our data, I posted a detailed
> chronology of the hijack as seen from our many peering sessions. I
> would add to this that the speed of YouTube's response to this
> subprefix hijack impressed me.
For a Sunday afternoon, yes, not bad
Rick Astley writes:
> Anything more specific than a /24 would get blocked by many filters,
> so some of the "high target" sites may want to announce their
> mission critical IP space as /24 and avoid using prepends.
Good idea. But only the "high target" sites, please. If you're an
unimportant s
Marshall Eubanks writes:
> In a typical flight Europe / China I believe that there would be
> order 10-15 satellite transponder / ground station changes. The
> satellite footprints count for more that the geography.
What I remember from the Connexion presentations is that they used
only four grou
Vince Fuller writes:
> On Mon, Sep 11, 2006 at 12:32:57PM +0200, Oliver Bartels wrote:
>> Ceterum censeo: Nevertheless this moving-clients application shows
>> some demand for a true-location-independend IP-addresses
>> announcement feature (provider independend "roaming") in IPv6, as
>> in v4 (ev
cidr-report writes:
> Recent Table History
> Date PrefixesCIDR Agg
> 03-11-06199409 129843
[...]
> 10-11-06 134555024 129854
Growth of the "global routing table" really picked up pace this week!
(But maybe I'm just hallucinating for having heard th
Lionel Elie Mamane writes:
> On Mon, Dec 25, 2006 at 12:44:37AM +, Jeroen Massar wrote:
>> That said ISP's should simply have a package saying "50GiB/month
>> costs XX euros, 100GiB/month costs double" etc. As that covers what
>> their transits are charging them, nothing more, nothing less.
>
Alexander Harrowell writes:
> For example: France Telecom's consumer ISP in France (Wanadoo) is
> pushing out lots and lots of WLAN boxes to its subs, which it brands
> Liveboxes. As well as the router, they also carry their carrier-VoIP
> and IPTV STB functions. [...]
Right, and the French ADSL
Andre Oppermann gave the best advice so far IMHO.
I'll add a few points.
> To quickly sum up the facts and to dispell some misinformation:
> - TCP is limited the delay bandwidth product and the socket buffer
>sizes.
Hm... what about: The TCP socket buffer size limits the achievable
through
Ah, large MTUs. Like many other "academic" backbones, we implemented
large (9192 bytes) MTUs on our backbone and 9000 bytes on some hosts.
See [1] for an illustration. Here are *my* current thoughts on
increasing the Internet MTU beyond its current value, 1500. (On the
topic, see also [2] - a w
Steven M Bellovin writes:
> Jim Shankland <[EMAIL PROTECTED]> wrote:
>> (2) Getting this kind of throughput seems to depend on a fast
>> physical layer, plus some link-layer help (jumbo packets), plus
>> careful TCP tuning to deal with the large bandwidth-delay product.
>> The IP layer sits betwe
Tony Li writes:
> On Apr 25, 2007, at 2:55 PM, Simon Leinen wrote:
>> Routing table lookups(*) are what's most relevant here, [...]
> Actually, what's most relevant here is the ability to get end-hosts
> to run at rate. Packet forwarding at line rate has been
> demon
Jason Frisvold writes:
> I'm working on a system to alert when a bandwidth augmentation is
> needed. I've looked at using both true averages and 95th percentile
> calculations. I'm wondering what everyone else uses for this
> purpose?
We use a "secret formula", aka rules of thumb, based on perc
Leo Bicknell writes:
> However, if you put 15G down your "20G" path, you have no
> redundancy. In a cut, dropping 5G on the floor, causing 33% packet
> loss is not "up", it might as well be down.
Sorry, it doesn't work like that either. 33% packet loss is an upper
limit, but not what you'd see
45 matches
Mail list logo
