On 5 May 2008, at 21:49, Nathan Ward wrote:
> On 6/05/2008, at 1:21 PM, Joe Abley wrote:
>
>> On 5 May 2008, at 20:50, Nathan Ward wrote:
>>
>>> Perhaps what would make more sense here is Foundry (F5, etc.)
>>> building
>>> an anycast feature - anycast prefixes are withdrawn when a cluster
>>> re
On Tue, May 06, 2008, Nathan Ward wrote:
> Maybe you just start calling "10Mbps" "10Mbps, assuming a 500b average
> packet size."
>
> Anyway, nice idea in theory - putting more real world limitations in
> to sold product limitations - but I don't see it working out with
> marketing people,
On 6/05/2008, at 1:21 PM, Joe Abley wrote:
> On 5 May 2008, at 20:50, Nathan Ward wrote:
>
>> Perhaps what would make more sense here is Foundry (F5, etc.)
>> building
>> an anycast feature - anycast prefixes are withdrawn when a cluster
>> relying on that anycast prefix goes below a threshold.
On Tue, 6 May 2008 13:24:35 +1200
Nathan Ward <[EMAIL PROTECTED]> wrote:
> On 6/05/2008, at 1:19 PM, Steven M. Bellovin wrote:
>
> > "Steve"? I assume you meant "Paul"
>
> No, Steve Gibbard referred to not having control of routers, Paul
> referred to customers.
>
Ah. As has often been
On 6/05/2008, at 1:19 PM, Steven M. Bellovin wrote:
> "Steve"? I assume you meant "Paul"
No, Steve Gibbard referred to not having control of routers, Paul
referred to customers.
--
Nathan Ward
___
NANOG mailing list
NANOG@nanog.org
http://mail
On 5 May 2008, at 20:50, Nathan Ward wrote:
> Perhaps what would make more sense here is Foundry (F5, etc.) building
> an anycast feature - anycast prefixes are withdrawn when a cluster
> relying on that anycast prefix goes below a threshold.
I'm not sure exactly what feature is required, here.
On May 6, 2008, at 2:52 AM, Paul Vixie wrote:
> delay, because nanog meetings only happen N times per year, so
> an idea may have to wait months before it's widely circulated.
> congestion,
> because nanog meetings are of fixed duration and there is, and has
> to be,
> competition for the sl
On 6/05/2008, at 4:07 AM, Paul Vixie wrote:
> i dearly do
> wish that something like a "service advertisement protocol" existed,
> that
> did what OSPF ECMP did, without a router operator effectively giving
> every
> customer the ability to inject other customer routes, or default
> routes.
On 6/05/2008, at 8:02 AM, Iljitsch van Beijnum wrote:
> Of course not. Like I said, as an average end-user with 10 Mbps you
> get to send a maximum of 2500 packets per second. That's plenty to do
> VoIP, set up TCP sessions or do IM. You just don't get to send the
> full 10 Mbps at this size.
Hmm
* [EMAIL PROTECTED] (Iljitsch van Beijnum) [Mon 05 May 2008, 10:09 CEST]:
> PS. Am I the only one who is annoyed by the reduction in usable
> subject space by the superfluous [NANOG]?
No, and I'm just as annoyed by the (non-McQ) footer with superfluous
information attached to each mail.
On 5 m
> Did your inbound path change as a result?
Yes, I was trying to re-balance our inbound traffic a bit better. The
route-map change resulted in about 30% of our traffic coming in via
our other provider. The change was made around 16:00 (CDT) last
Friday, about 72 hours before this problem was broug
On 5 mei 2008, at 21:56, Mike Fedyk wrote:
>> So if you have a 10 Mbps connection you don't get to
>> send 14000 64-byte packets per second, but a maximum of 2500
>> packets per
>> second. So with 64-byte packets you only get to use 1.25 Mbps.
> You have just cut out the VoIP industry, TCP setu
> -Original Message-
> From: Iljitsch van Beijnum [mailto:[EMAIL PROTECTED]
> think of is DoS attacks. But that can be solved by only allowing end-
> users to send an average packet size of 500 (or 250, or whatever)
> bytes. So if you have a 10 Mbps connection you don't get to
> send 1
[EMAIL PROTECTED] ("Steven M. Bellovin") writes:
> > > If not, what should the criteria be for an "official" note of the paper?
> >
> > Perhaps it's an oversimplification, but can't those who wish to publish
> > such information simply deliver their papers at a NANOG meeting (after
> > acceptance
> ...
> A web site like arxiv is good for some stuff. But -- should there be a
> link from nanog.org to operational content? Should nanog.org have
> its own archive? Should there be a peer review process? If not, what
> should the criteria be for an "official" note of the paper?
>
>
Did your inbound path change as a result? Sounds like a path asymmetry
issue might be involved.
Douglas K. Rand wrote:
> In the popular tradition of replying to my own post ...
>
> It seems that this problem started right around the time I changed our
> BGP configuration. I did:
>
> config ter
In the popular tradition of replying to my own post ...
It seems that this problem started right around the time I changed our
BGP configuration. I did:
config term
route-map att_out permit
set as-path prepend 19317 19317
exit
clear ip bgp 12.87.125.249 out
This change was to increase our p
On Tue, 6 May 2008 01:19:36 +0700
Roland Dobbins <[EMAIL PROTECTED]> wrote:
>
> On May 6, 2008, at 12:59 AM, Steven M. Bellovin wrote:
>
> > If not, what should the criteria be for an "official" note of the
> > paper?
>
>
> Perhaps it's an oversimplification, but can't those who wish to
>
On May 6, 2008, at 12:59 AM, Steven M. Bellovin wrote:
> If not, what should the criteria be for an "official" note of the
> paper?
Perhaps it's an oversimplification, but can't those who wish to
publish such information simply deliver their papers at a NANOG
meeting (after acceptance by
On 2008-05-05, Paul Vixie <[EMAIL PROTECTED]> wrote:
> also, in OSPF, ECMP is not optional, even though most BSD-based software
> routers don't implement it yet (since multipath routing is very new.)
Some readers might be interested to know the exception to "most" here;
the OpenBSD kernel has supp
We had a very strange problem today. Two of our hosts could not reach
a server, but only those two hosts. All of our other hosts could reach
those servers fine. (OK, I didn't try ALL of our IPs, but the half
dozen I did try worked fine.)
I checked all of our firewalls and routers, and everywhere
On 05 May 2008 16:07:03 +
Paul Vixie <[EMAIL PROTECTED]> wrote:
>
> > But yes, Joe's ISC TechNote is an excellent document, and was a big
> > help in figuring out how to set this up a few years ago.
>
> and now for something completely different -- where in the interpipes
> could a document
On May 5, 2008, at 1:16 PM, David Andersen wrote:
> On May 5, 2008, at 12:07 PM, Paul Vixie wrote:
>>
>>> But yes, Joe's ISC TechNote is an excellent document, and was a big
>>> help
>>> in figuring out how to set this up a few years ago.
>>
>> and now for something completely different -- where
After a request, I can confirm that Burma / Myanmar dropped off the
BGP tables here over the weekend :
bgp.sum.May_2_00:07:00_EDT_2008: AS 9988 MPT-
AP | 3 hops | as path 174 2914 9988
bgp.sum.May_2_00:07:00_EDT_2008: AS 18399 BAGAN-TRANSIT-
AS
On Mon, May 5, 2008 at 10:07 AM, Paul Vixie <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] (Steve Gibbard) writes:
>
> > > ... if each anycast cluster is really several servers, each using OSPF
> > > ECMP, then you can lose a server and still have that cluster advertising
> > > the route upstrea
On May 5, 2008, at 12:07 PM, Paul Vixie wrote:
>
>> But yes, Joe's ISC TechNote is an excellent document, and was a big
>> help
>> in figuring out how to set this up a few years ago.
>
> and now for something completely different -- where in the
> interpipes could
> a document like that have be
Hello All ,
On Mon, 5 May 2008, Paul Vixie wrote:
> [EMAIL PROTECTED] (Steve Gibbard) writes:
...snip...
>> But yes, Joe's ISC TechNote is an excellent document, and was a big help
>> in figuring out how to set this up a few years ago.
>
> and now for something completely different -- wher
On 5 mei 2008, at 17:14, [EMAIL PROTECTED] wrote:
>> Obviously there is a lot to be gained at that end, but that doesn't
>> mean we should ignore power use in the network. One thing that could
>> help here is to increase the average packet size. Whenever I've
>> looked, this has always hovered aro
[EMAIL PROTECTED] (Steve Gibbard) writes:
> > ... if each anycast cluster is really several servers, each using OSPF
> > ECMP, then you can lose a server and still have that cluster advertising
> > the route upstream, and only when you lose all servers in a cluster will
> > that route be withdrawn
On Sun, 4 May 2008, Paul Vixie wrote:
> [EMAIL PROTECTED] (Steve Gibbard) writes:
>> The right solution is to design the anycast servers to be as sure as
>> possible that the route will go away when you want it gone, but to have
>> multiple non-interdependent anycast clouds in the NS records for e
On 2 mei 2008, at 20:51, Mike Leber wrote:
> Since nobody mentioned it yet, there are now less than 1000 days
> projected
> until IPv4 exhaustion:
> http://www.potaroo.net/tools/ipv4/
Unfortunately that won't load for me over IPv6, path MTU black hole...
> ps. 1000 days assumes no rush, specu
On 5 mei 2008, at 0:57, Adrian Chadd wrote:
> I'd seriously be looking at making current -software- run more
> efficiently
> before counting ipv6-related power savings.
Good luck with that.
Obviously there is a lot to be gained at that end, but that doesn't
mean we should ignore power use in
32 matches
Mail list logo
