On Tue, 3 May 2005 [EMAIL PROTECTED] wrote:
>
> > 7200 most certainly does not have interface processors. 7500 does have
> > processors on the VIPs that do forwarding lookups in a distributed
> > fashion, but the same procedure for software forwarding apply, there
> just
> > happen to be a f
> 7200 most certainly does not have interface processors. 7500 does have
> processors on the VIPs that do forwarding lookups in a distributed
> fashion, but the same procedure for software forwarding apply, there
just
> happen to be a few more CPUs floating around.
Also, it may not be clear f
Dean Anderson wrote:
relays. They don't advertise this fact, due to, well, abusers like Matthew
Sullivan. *You* need to put down the crackpipe.
I thought personal attacks were against the list rules...?
Moderators...?
Regards,
Mat
On Sun, 01 May 2005 23:29:54 EDT, Dean Anderson said:
> On Sun, 1 May 2005, Joe Maimon wrote:
> > How much credibility are you trying to lose?
> I have 9 years of operational experience running open relays.
OK.. I stand corrected. Unlike seat belts and phone service, if you've lost 99%
of your cr
On May 1, 2005, at 11:29 PM, Dean Anderson wrote:
On Sun, 1 May 2005, Joe Maimon wrote:
Dean Anderson wrote:
And if they aren't found by open-relay
blacklists, they aren't abused and there are no problems whatsoever.
How much credibility are you trying to lose?
I have 9 years of operational exper
On Sun, 1 May 2005, Joe Maimon wrote:
>
>
> Dean Anderson wrote:
> > And if they aren't found by open-relay
> > blacklists, they aren't abused and there are no problems whatsoever.
>
> How much credibility are you trying to lose?
I have 9 years of operational experience running open relays
Dean Anderson wrote:
And if they aren't found by open-relay
blacklists, they aren't abused and there are no problems whatsoever.
How much credibility are you trying to lose?
DA> Date: Sun, 1 May 2005 21:09:50 -0400 (EDT)
DA> From: Dean Anderson
DA> > http://www.merit.edu/mail/archives/nanog/199-11/msg00263.html
DA> > http://www.merit.edu/mail/archives/nanog/199-11/msg00289.html
DA>
DA> Neither of these links actually work. But it is "Draft Standard". That is
s,199,
On Sun, 01 May 2005 21:09:50 EDT, Dean Anderson said:
> criticisms (made presumably in 1999), were correct. In 2005, SMTP AUTH is
> basically dead. There hasn't been a new mail client supporting SMTP AUTH
> in many years. What would be the point?
There's almost no new car companies supporting se
On Sun, 1 May 2005, Steven J. Sobol wrote:
>
> On Sun, 1 May 2005, Dean Anderson wrote:
>
> > On Sun, 1 May 2005, Edward B. Dreger wrote:
> >
> > > e.g., I specifically cited laws and cases that appear to apply to
> > > blacklists... now you claim I stated DNSBLs are exempt? Someone needs
> >
On Sun, 1 May 2005, Edward B. Dreger wrote:
> You object to SMTP+AUTH because it isn't standard:
>
> http://www.merit.edu/mail/archives/nanog/199-11/msg00263.html
> http://www.merit.edu/mail/archives/nanog/199-11/msg00289.html
Neither of these links actually work. But it is "Draft Standard". T
On Sun, 1 May 2005, Dean Anderson wrote:
> On Sun, 1 May 2005, Edward B. Dreger wrote:
>
> > e.g., I specifically cited laws and cases that appear to apply to
> > blacklists... now you claim I stated DNSBLs are exempt? Someone needs
> > to put down the crackpipe.
>
> You agreed with me on some
On Sun, 1 May 2005, Edward B. Dreger wrote:
> e.g., I specifically cited laws and cases that appear to apply to
> blacklists... now you claim I stated DNSBLs are exempt? Someone needs
> to put down the crackpipe.
You agreed with me on something? I must have missed that at the time. I'm
*sure*
DA> Date: Sat, 30 Apr 2005 00:57:46 -0400 (EDT)
DA> From: Dean Anderson
DA> But for the record, you misrepresent my SMTP AUTH claims:
Someone needs to put down the crackpipe. At least do a Google search or
three to find out what I really say before putting words in my mouth.
e.g., I specificall
> > > Err. No, that would be worse. "Per prefix" load balancing is an
> > > artifact of the Cisco route cache. The route engine (ie the route
> > > table) isn't queried for every packet. Instead the route
> in the route cache is used.
> > > One doesn't configure "per prefix" load balancing. One
On Sun, May 01, 2005 at 12:44:09AM -0400, Dean Anderson wrote:
>
> > Modern Cisco routers do not use a "route cache",
>
> You'll need to define what you mean by "modern" with respect to cisco.
> This statement seems to be incorrect.
For someone with so little clue, you sure do manage to talk
On Sat, 30 Apr 2005, James wrote:
>
> On Fri, Apr 29, 2005 at 11:56:01PM -0400, Dean Anderson wrote:
>
> [ snip ]
>
> > Err. No, that would be worse. "Per prefix" load balancing is an artifact
> > of the Cisco route cache. The route engine (ie the route table) isn't
> > queried for every packe
The questions of what various routers do now or did in the past is
irrelevant. So, to wrap it up:
RFC 1546 give this rule about internetwork architecture on page 5:
An internetwork has no obligation to deliver two successive packets
sent to the same anycast address to the same host.
Whet
On Sat, 30 Apr 2005 [EMAIL PROTECTED] wrote:
> > > First of all, let's ditch the term "PPLB." The usual alternative to per
> > > packet load balancing (what's been being talked about here) is per prefix
> > > load balancing, which would also be "PPLB." The abbreviation is
> > > therefore
>
On Fri, Apr 29, 2005 at 11:56:01PM -0400, Dean Anderson wrote:
[ snip ]
> Err. No, that would be worse. "Per prefix" load balancing is an artifact
> of the Cisco route cache. The route engine (ie the route table) isn't
> queried for every packet.
> Instead the route in the route cache is used.
> > First of all, let's ditch the term "PPLB." The usual alternative to per
> > packet load balancing (what's been being talked about here) is per prefix
> > load balancing, which would also be "PPLB." The abbreviation is therefore
> > more confusing than anything else.
>
> Err. No, that wou
On Tue, 26 Apr 2005, Edward B. Dreger wrote:
> DA> Date: Sat, 23 Apr 2005 16:13:22 -0400 (EDT)
> DA> From: Dean Anderson
>
> DA> And it violates RFC 1546, as previously explained.
>
> Who cares? You've railed against SMTP+AUTH because it's not a
> "standard". Why do you give a rat's rump abou
On Sat, 30 Apr 2005, Dean Anderson wrote:
>
> On Mon, 25 Apr 2005, Stephen J. Wilcox wrote:
>
> > So agreeing for a second with Dean that indeed this behaviour would appear
> > to be
> > prohibited or at least inconsistent with the RFCs, the fact is anycast is
> > widely
> > deployed and is pro
On Mon, 25 Apr 2005, Stephen J. Wilcox wrote:
> So agreeing for a second with Dean that indeed this behaviour would appear to
> be
> prohibited or at least inconsistent with the RFCs, the fact is anycast is
> widely
> deployed and is proven to be stable.
"vixie-cast" is deployed on around 60
On Sun, 24 Apr 2005, Steve Gibbard wrote:
>
> On Sun, 24 Apr 2005, Robert M. Enger wrote:
>
> > Steinar:
> >
> > There is a large body of work from competent and well known researchers
> > that assert the claim. I certainly lack standing to question their
> > results.
> >
> > Empirically, do
> Date: Sun, 24 Apr 2005 02:00:48 -0400
> From: [EMAIL PROTECTED]
> What you seem to be missing is that the *really* smart people will be prepared
> for it when it actually gets here - and will take advantage of it's lack of
> arrival in the meantime.
Na the code in my lab and the work-i
DA> Date: Sat, 23 Apr 2005 16:13:22 -0400 (EDT)
DA> From: Dean Anderson
DA> And it violates RFC 1546, as previously explained.
Who cares? You've railed against SMTP+AUTH because it's not a
"standard". Why do you give a rat's rump about 1546?
DA> Well, PPLB isn't the end of the world. But PPL
On Sun, Apr 24, 2005 at 04:40:50PM -0400, Robert M. Enger wrote:
> More to the point however, I note that Jay is the author of RFC2100.
> I think he's just having a little bit of fun. My apologies for
> belaboring the performance issue.
I'm pleased that you noticed... but possibly less so if it m
On Sun, 24 Apr 2005, Steve Gibbard wrote:
>
> On Sun, 24 Apr 2005, Robert M. Enger wrote:
>
> > Steinar:
> >
> > There is a large body of work from competent and well known researchers
> > that assert the claim. I certainly lack standing to question their
> > results.
> >
> > Empirically, do
On Sun, 24 Apr 2005, Robert M. Enger wrote:
Steinar:
There is a large body of work from competent and well known researchers
that assert the claim. I certainly lack standing to question their
results.
Empirically, download speeds to home are nearly cut in half (18Mbps)
from sources that are su
On Sun, Apr 24, 2005 at 04:00:40PM -0400, Robert M. Enger wrote:
> In your note below you speak of 'moving on to something else' when
> PPLB comes.
No, I actually don't.
> PPLB destabilizes TCP. It elicits erroneous retransmissions, squanders
> capacity and lowers performance.
>
> You are sugges
Steinar:
There is a large body of work from competent and well known
researchers that assert the claim. I certainly lack standing to question their
results.
Empirically, download speeds to home are nearly cut in half (18Mbps) from
sources
that are subjected to packet reordering along the pat
> In your note below you speak of 'moving on to something else' when
> PPLB comes.
>
> PPLB destabilizes TCP. It elicits erroneous retransmissions,
> squanders capacity and lowers performance.
I would actually dispute this. I agree that PPLB will *occasionally*
lead to out-of-order packets, whic
Jay:
In your note below you speak of 'moving on to something else' when PPLB comes.
PPLB destabilizes TCP. It elicits erroneous retransmissions, squanders
capacity and lowers performance.
You are suggesting that we replace TCP in all the computers in the world?
Bob
At 01:43 PM 4/24/2005,
On Sun, Apr 24, 2005 at 02:00:48AM -0400, [EMAIL PROTECTED] wrote:
> > Well, PPLB isn't the end of the world. But PPLB is coming, and the smart
> > people will be prepared for it. They dumb people, well, they're dumb.
> > What can be expected from dumb people?
>
> What you seem to be missing i
> > Well, PPLB isn't the end of the world. But PPLB is coming, and the smart
> > people will be prepared for it. They dumb people, well, they're dumb.
> > What can be expected from dumb people?
>
> What you seem to be missing is that the *really* smart people will be
> prepared for it when it
On Sun, 24 Apr 2005 01:35:11 PDT, Bill Stewart said:
> There are a variety of things that don't like PPLB, notably IPSEC.
The fact that a variety of things (like PMTU Discovery) don't like it when
people block all ICMP doesn't stop it from happening. Similarly for a number
of other less-than-perf
> > Well, PPLB isn't the end of the world. But PPLB is coming, and the smart
> > people will be prepared for it. They dumb people, well, they're dumb.
> > What can be expected from dumb people?
There are a variety of things that don't like PPLB, notably IPSEC.
One problem is that if packet lengt
On Sat, 23 Apr 2005 16:13:22 EDT, Dean Anderson said:
> I'm reminded of the arguments in the late 80's about threading: People
> (like you) said there are no multithreading operating systems, and
> multiprocessor systems existed only in labs. So designing threadsafe
> libraries or writing multit
* [EMAIL PROTECTED] (James) [Sat 23 Apr 2005, 23:10 CEST]:
> With proliferation of high speed circuits and continuing trend of lower
> cost of bandwidth, PPLB is becoming more obsolete for many people that
> implemented it in the past. What is becoming more common is non-PPLB
> based setup, such
> Been happening for many years. How do you think the original
> Boardwatch / Keynote speed tests were gamed? If you have any real
> experience on the Internet, you are well acquainted with anycast web
> servers.
Let me, let me, let me! It involved an err... locating linux boxes with the
On Sat, Apr 23, 2005 at 04:13:22PM -0400, Dean Anderson wrote:
[ snip ]
>
> Well, PPLB isn't the end of the world. But PPLB is coming, and the smart
> people will be prepared for it. They dumb people, well, they're dumb.
> What can be expected from dumb people?
With proliferation of high sp
On Sat, 23 Apr 2005, Patrick W. Gilmore wrote:
> Been happening for many years. How do you think the original
> Boardwatch / Keynote speed tests were gamed? If you have any real
> experience on the Internet, you are well acquainted with anycast web
> servers.
Gaming speed tests sounds pr
Per Packet Load Balancing is not TCP friendly. (this discussion is orthogonal
to DNS)
PPLB leads to packet reordering.
Quite a few empirical and theoretical papers have been published (in peer
reviewed fora and elsewhere)
that discuss the negative consequences of packet reordering. A Google
On Fri, 22 Apr 2005, Dean Anderson wrote:
> On Thu, 21 Apr 2005, Stephen J. Wilcox wrote:
>
> > On Wed, 20 Apr 2005, Dean Anderson wrote:
> >
> > > On Wed, 20 Apr 2005 [EMAIL PROTECTED] wrote:
> > >
> > > > > I'd rather expect this sort of behavior with anycasted servers...
> > > >
> > > > W
On Sat, 23 Apr 2005, Christopher L. Morrow wrote:
oh well, I tried to stay quiet :) Probably the PPLB problem isn't quite as
simple as: "you have pplb you can't do anycast". I'd imagine that you have
to have some substantial difference in the paths that the PPLB follows,
yes? like links to differin
On Fri, Apr 22, 2005 at 11:55:23PM -0400, Dean Anderson wrote:
>
> On Wed, 20 Apr 2005, Patrick W. Gilmore wrote:
>
> >
> > On Apr 20, 2005, at 3:29 PM, Dean Anderson wrote:
> >
> > >> Or don't. No one here cares if you do. Reality trumps lab tests.
> > >
> > > "Reality" for the last ten yea
On Apr 22, 2005, at 11:55 PM, Dean Anderson wrote:
I don't know of any HTTP servers that do anycast. But their
failure to
take account of PPLB doesn't change anything. IF they are
anycasting under
false assumptions, they'll have problems, too.
Been happening for many years. How do you think t
On Apr 22, 2005, at 11:20 PM, Dean Anderson wrote:
People have been using TCP applications on anycast for at least a
decade, as I mentioned before. Since DNS responses tend to be very
short lived TCP session, it seems to me that if it works for other
applications (e.g. HTTP), it should work for DN
On Wed, 20 Apr 2005, Patrick W. Gilmore wrote:
>
> On Apr 20, 2005, at 3:29 PM, Dean Anderson wrote:
>
> >> Or don't. No one here cares if you do. Reality trumps lab tests.
> >
> > "Reality" for the last ten years has been that no one did either PPLB
> > or TCP DNS. That reality is changing.
On Fri, 22 Apr 2005, Dean Anderson wrote:
> On Wed, 20 Apr 2005, Patrick W. Gilmore wrote:
>
> >
> > On Apr 20, 2005, at 3:29 PM, Dean Anderson wrote:
> >
> > >> Or don't. No one here cares if you do. Reality trumps lab tests.
> > >
> > > "Reality" for the last ten years has been that no one di
On Thu, 21 Apr 2005, Stephen J. Wilcox wrote:
> On Wed, 20 Apr 2005, Dean Anderson wrote:
>
> > On Wed, 20 Apr 2005 [EMAIL PROTECTED] wrote:
> >
> > > > I'd rather expect this sort of behavior with anycasted servers...
> > >
> > > Where do you see any connection between anycast and ignoring D
On Wed, 20 Apr 2005 [EMAIL PROTECTED] wrote:
> On Wed, 20 Apr 2005 14:00:00 EDT, Dean Anderson said:
> > On Wed, 20 Apr 2005 [EMAIL PROTECTED] wrote:
> > > Where do you see any connection between anycast and ignoring DNS TTL?
> > The data he showed isn't necessarilly "ignoring ttl". If there are
On Wed, 20 Apr 2005, Patrick W. Gilmore wrote:
>
> On Apr 20, 2005, at 3:29 PM, Dean Anderson wrote:
>
> >> Or don't. No one here cares if you do. Reality trumps lab tests.
> >
> > "Reality" for the last ten years has been that no one did either
> > PPLB or
> > TCP DNS. That reality is chan
On Wed, 20 Apr 2005, Dean Anderson wrote:
> On Wed, 20 Apr 2005 [EMAIL PROTECTED] wrote:
>
> > > I'd rather expect this sort of behavior with anycasted servers...
> >
> > Where do you see any connection between anycast and ignoring DNS TTL? Or is
> > this just part of your usual rant against a
take the hit of very rare TCP DNS resets if it means I avoid outages of
the DNS service during DDoS attacks.
- Original Message -
From: "Dean Anderson" <[EMAIL PROTECTED]>
To: "Crist Clark" <[EMAIL PROTECTED]>
Cc:
Sent: Wednesday, April 20, 2005 2:41 PM
Su
> While that setup may have worked well, it's not an anycast implementation
> I would suggest that others follow. Having the same set of servers
> announcing multiple IP addresses (assuming those addresses are both in the
> same set of addresses given out to those doing dns lookups) leaves you
On Apr 20, 2005, at 3:29 PM, Dean Anderson wrote:
Or don't. No one here cares if you do. Reality trumps lab tests.
"Reality" for the last ten years has been that no one did either
PPLB or
TCP DNS. That reality is changing. It'll probably start to change
faster,
sooner. Then, users will start
On Wed, 20 Apr 2005 14:00:00 EDT, Dean Anderson said:
> On Wed, 20 Apr 2005 [EMAIL PROTECTED] wrote:
> > Where do you see any connection between anycast and ignoring DNS TTL?
> The data he showed isn't necessarilly "ignoring ttl". If there are
> multiple anycasted caching servers behind a specific
On Wed, 20 Apr 2005, Patrick W. Gilmore wrote:
> And I can show that if you give a pig wings
I suppose IF a pig had wings, indeed, it *would* fly. But pigs aren't
growing winglets.
However, there are two relevant facts here:
1) People are starting to deploy PPLB.
2) People
On Wed, 20 Apr 2005 [EMAIL PROTECTED] wrote:
Our recursive name service, using anycast servers, is setup with 3
name servers at 3 different physical locations, with each server
connected to a router at the same physical location. Each server
handles two different anycast addresses. There is no per-
> > But caching servers are usually setup to load balance. Usually, the
> > servers with the same IP address share an ethernet along with multiple
> > routers. So the packets are switched on essentially a per-packet
> > basis.
> > Or possibly a per-arp basis that alters the MAC-based-forwarding
400 (EDT)
From: Dean Anderson <[EMAIL PROTECTED]>
To: Crist Clark <[EMAIL PROTECTED]>
Cc: nanog@merit.edu
Subject: Re: Slashdot: Providers Ignoring DNS TTL?
On Wed, 20 Apr 2005, Crist Clark wrote:
> Dean Anderson wrote:
> > I'd rather expect this sort of behavior with anyc
Once upon a time, Dean Anderson <[EMAIL PROTECTED]> said:
> If there are
> multiple anycasted caching servers behind a specific IP address, then
> those several cache's will each have a different state. Since, [as I
> explained, and was supposed by the poster], there is "some kind of load
> balan
On Apr 20, 2005, at 2:13 PM, Dean Anderson wrote:
No, you are thinking of the (wrong) claims originally made by ISC
about
how anycast would affect TCP to an anycast authoritative server. ISC
wrongly asserted that since BGP routes don't churn very fast
compared with
DNS TCP connection lifetimes
On Wed, 20 Apr 2005, Crist Clark wrote:
> Dean Anderson wrote:
> > I'd rather expect this sort of behavior with anycasted servers...
>
> I would not expect this kind of behavior from an anycasted address.
> You'd need a LOT of routing churn to see different caches every few
> seconds. It's much
On Wed, 20 Apr 2005 [EMAIL PROTECTED] wrote:
>
> > I'd rather expect this sort of behavior with anycasted servers...
>
> Where do you see any connection between anycast and ignoring DNS TTL?
> Or is this just part of your usual rant against anycast DNS service?
The data he showed isn't necess
Dean Anderson wrote:
I'd rather expect this sort of behavior with anycasted servers...
I would not expect this kind of behavior from an anycasted address.
You'd need a LOT of routing churn to see different caches every few
seconds. It's much more likely some kind of load balancer in front
of a DNS
> I'd rather expect this sort of behavior with anycasted servers...
Where do you see any connection between anycast and ignoring DNS TTL?
Or is this just part of your usual rant against anycast DNS service?
We use anycast for our caching (recursive) DNS servers. It works well
for us, and we cer
I'd rather expect this sort of behavior with anycasted servers...
With a cache, the behavior is confusing, but also harms DNS TCP support,
just like that described for authoritative servers.
Further there isn't a good reason to have anycasted caches. Indeed, with
DHCP-learned nameservers, ther
Fergie (Paul Ferguson) wrote:
Interesting thread on /. --
http://ask.slashdot.org/article.pl?sid=05/04/18/198259&tid=95&tid=128&tid=4
FWIW, I did some 'dig'ing on my Comcast home service. The DHCP is handing
out 204.127.198.4 and 63.240.76.4 for DNS at the moment.
I ran a query for a name in a zone
On Tue, 2005-04-19 at 15:47 +, Fergie (Paul Ferguson) wrote:
>
> Interesting thread on /. --
>
> http://ask.slashdot.org/article.pl?sid=05/04/18/198259&tid=95&tid=128&tid=4
The original poster doesn't identify what his starting TTL was before he
made his change. I didn't read all the respon
Interesting thread on /. --
http://ask.slashdot.org/article.pl?sid=05/04/18/198259&tid=95&tid=128&tid=4
- ferg
--
"Fergie", a.k.a. Paul Ferguson
Engineering Architecture for the Internet
[EMAIL PROTECTED] or [EMAIL PROTECTED]
ferg's tech blog: http://fergdawg.blogspot.com/
73 matches
Mail list logo
