Re: That MIT paper

2004-08-11 Thread Siegbert Marschall

Hi,

 But, to my understanding a too short TTL will do harm to cache server
 performance
 esp. the amount of RR cached is so large that BIND have to wait for
 swapping I/O
 and re-fetching those timeout RR again.
I think you missed the main point of the report, it does not say that
low TTLs are a good idea in general.

What it does say is that the stability and performance of the DNS is
mainyl based on a rather high TTL for NS records, which distrubutes
the query load among a larger number of servers and avoid therefore
SPFs and Bootlenecks.

Compared to that the overall performance and load impact of lowering
the TTL for A records down to a few 100 seconds is not an issue, mostly
because the large number of queries for A records vom clients happen
in very short intervals of time, just look at what your webbrowser is
doing when you are surfing and therefore will be cached after the first
query by the local nameserver anyway. The important thing here is that
this nameserver does not have to go throught the same chain od DNS servers
again to find the one who gives him the right answer a few hours or days
later, but instead can just ask this server directly from his cached NS
record.

Parts of this I can also verify from my own experience. Although a nicely
tuned cascade of nameservers might add some measurable performance to DNS
resolution on client side, when surfing, the most noticeable performance
improvement is having a decent DNS server in your local lan which you can
reach within a few µS.

So in short:
LOW TTL A Records, will not affect stability and perfomance of DNS much.
LOW TTL NS Records, bad bad Idea.

Bye, Siggi.


Testing procedures for new network implementation?

2004-08-11 Thread Wayne Chow




Hi 
All

We are in the 
process of planning for the upgrade of a 3Com network.

The new 
infrastructure will be comprised of 3Com 4950s with XRN and a dozen stacks of 
4400s.

What are the 
best practices of testing the new implementation? Any advices or suggestions would be 
greatly appreciated.

The only 
software that we have is the 3Com Network Director.


Thank you in 
advance.



Wayne 
Chow
Network Administrator
Faculty of Dentistry, 
University of Toronto



Legal intercept - 3550

2004-08-11 Thread Stefan Baltus

Hi,

We have a situation where we need to intercept certain IP traffic
that is somewhere within a link of 300Mbit/s of traffic (GigabitEthernet).
The setup that we built is as follows:

router 
  ^
  | GE
  | 
fiber tap --- cisco catalyst 3550
  |
  | GE
  v
switch


The catalyst 3350 is receiving the traffic from router to switch
and vice versa. Now, we'd like to filter all but certain IP's on the
3350 and switch this traffic to a FE port on that same 3550. Currently
we've put the FE interface in SPAN mode, but that fills up the
FE port completely (obviously). Is there any way to accomplish this?

Regards,

Stefan 

-- 
Stefan Baltus [EMAIL PROTECTED]XB Networks B.V. 
Manager Engineering Televisieweg 2
telefoon: +31 36 54624001322 AC  Almere
fax: +31 36 5462424 The Netherlands


Re: Testing procedures for new network implementation?

2004-08-11 Thread Ricardo \Rick\ Gonzalez

Wayne,

My organization has recently switched from a similar infrastructure to
the following:

Core: http://www.svec.com/PRODUCTS/fd800ds/FD800DS2.htm
Distribution layer: http://www.svec.com/Products/FD521EDS.HTM
Wire closet: http://www.svec.com/Products/fd510eds.htm

We have seen a noticeable increase in performance, ROI, and
manageability following the migration away from the prior 3Com
solution.  If you have any implementation-specific questions, please
mail me off list and I'll do my best to answer them.

With regards,
---Rico


- Original Message -
From: Wayne Chow [EMAIL PROTECTED]
Date: Wed, 11 Aug 2004 10:20:44 -0400
Subject: Testing procedures for new network implementation?
To: [EMAIL PROTECTED]

 
 

Hi All 

  

We are in the process of planning for the upgrade of a 3Com network. 

  

The new infrastructure will be comprised of 3Com 4950s with XRN and a
dozen stacks of 4400s.

  

What are the best practices of testing the new implementation?  Any
advices or suggestions would be greatly appreciated.

  

The only software that we have is the 3Com Network Director. 

  

  

Thank you in advance. 

  
  
 

Wayne Chow 

Network Administrator 

Faculty of Dentistry, University of Toronto


Re: Legal intercept - 3550

2004-08-11 Thread Ricardo \Rick\ Gonzalez

Stefan,

I think you're confusing your OSI layers here, routers route and
switches switch.

If you're spanning 300 megabits per second, what you'll need is a
gigabit card for the span port on the 3550 (or directly connected to
the passive tap you've installed).

---Rico

On Wed, 11 Aug 2004 16:37:24 +0200, Stefan Baltus [EMAIL PROTECTED] wrote:
 
 Hi,
 
 We have a situation where we need to intercept certain IP traffic
 that is somewhere within a link of 300Mbit/s of traffic (GigabitEthernet).
 The setup that we built is as follows:
 
 router
   ^
   | GE
   |
 fiber tap --- cisco catalyst 3550
   |
   | GE
   v
 switch
 
 The catalyst 3350 is receiving the traffic from router to switch
 and vice versa. Now, we'd like to filter all but certain IP's on the
 3350 and switch this traffic to a FE port on that same 3550. Currently
 we've put the FE interface in SPAN mode, but that fills up the
 FE port completely (obviously). Is there any way to accomplish this?
 
 Regards,
 
 Stefan
 
 --
 Stefan Baltus [EMAIL PROTECTED]XB Networks B.V.
 Manager Engineering Televisieweg 2
 telefoon: +31 36 54624001322 AC  Almere
 fax: +31 36 5462424 The Netherlands



Re: Testing procedures for new network implementation?

2004-08-11 Thread Rafi Sadowsky


Hi Rick 

 You seem slightly confused:

All the URLs you sent are for 10/100 ethernet switches/hubs
(I inserted the relevant title below each url )

-- 
Rafi

## On 2004-08-11 10:39 -0400 Ricardo Rick Gonzalez typed:

RG 
RG Wayne,
RG 
RG My organization has recently switched from a similar infrastructure to
RG the following:
RG 
RG Core: http://www.svec.com/PRODUCTS/fd800ds/FD800DS2.htm
FD800DS 8-port Dual Speed Hub 

RG Distribution layer: http://www.svec.com/Products/FD521EDS.HTM
FD521 5-port Fast Ethernet Switch

RG Wire closet: http://www.svec.com/Products/fd510eds.htm
FD510 5-Port Fast Ethernet Hub 

RG 
RG We have seen a noticeable increase in performance, ROI, and
RG manageability following the migration away from the prior 3Com
RG solution.  If you have any implementation-specific questions, please
RG mail me off list and I'll do my best to answer them.
RG 
RG With regards,
RG ---Rico
RG 



Re: Testing procedures for new network implementation?

2004-08-11 Thread Ricardo \Rick\ Gonzalez

No Rafi, I'm not confused, I replied recounting what my organization
deployed as a replacement for the hardware which Wayne is currently
working on.  Please refrain from further ad-hominem personal attacks
in violation of this forum's charter.

Just because different list participants have different approaches for
solving a particular problem doesn't mean one is necessarily wrong,
and needs to be lambasted.  This is what makes NANOG so diverse and
great, like this country of ours.

---Rico, who is putting NA back in NANOG

On Wed, 11 Aug 2004 18:13:37 +0300 (IDT), Rafi Sadowsky
[EMAIL PROTECTED] wrote:
 
 Hi Rick
 
  You seem slightly confused:
 
 All the URLs you sent are for 10/100 ethernet switches/hubs
 (I inserted the relevant title below each url )
 
 --
 Rafi
 
 ## On 2004-08-11 10:39 -0400 Ricardo Rick Gonzalez typed:
 
 RG
 RG Wayne,
 RG
 RG My organization has recently switched from a similar infrastructure to
 RG the following:
 RG
 RG Core: http://www.svec.com/PRODUCTS/fd800ds/FD800DS2.htm
 FD800DS 8-port Dual Speed Hub
 
 RG Distribution layer: http://www.svec.com/Products/FD521EDS.HTM
 FD521 5-port Fast Ethernet Switch
 
 RG Wire closet: http://www.svec.com/Products/fd510eds.htm
 FD510 5-Port Fast Ethernet Hub
 
 RG
 RG We have seen a noticeable increase in performance, ROI, and
 RG manageability following the migration away from the prior 3Com
 RG solution.  If you have any implementation-specific questions, please
 RG mail me off list and I'll do my best to answer them.
 RG
 RG With regards,
 RG ---Rico
 RG
 



Floorspace / Power Possibilities - location independant

2004-08-11 Thread Micah McNelly
Guys/Gals,
I'm currently digging for cheap floorspace / power / network with no 
specific geographical region in mind.  If you know of any well managed 
facilities with very low per square foot cost and cheap power (no 
hamsters please) please respond to me offlist.  Should be carrier 
neutral but have bandwidth available. 

Thanks,
/m


Re: That MIT paper

2004-08-11 Thread Paul Vixie

what i meant by act globally, think locally in connection with That
MIT Paper is that the caching effects seen at mit are at best
representative of that part of mit's campus for that week, and that
even a variance of 1% in caching effectiveness at MIT that's due to
generally high or low TTL's (on A, or MX, or any other kind of data)
becomes a huge factor in f-root's load, since MIT's load is only one
drop in a larger ocean.  see duane's paper, which is more of a think
globally, act locally kind of thing.  how much of the measured traffic
was due to bad logic in caching/forwarding servers, or in clients?  how
will high and low ttl's affect bad logic that's known to be in wide
deployment?  what if 20,000 enterprise networks the size of MIT all
saw a 1% decrease in caching effectiveness due to generally low TTL's?
(what if a general decline in TTL's resulted from publication of That
MIT Paper?)

here's a snapshot of f-root's life.  That MIT Paper not only fails to
address it, and fails to take it into account, it fails to identify
the global characteristic of the variables under study.  caching
performance is not simply a local issue.  everyone connected to the
internet acts globally.  it is wildly foolish to think locally.

16:44:35.118922 208.139.64.98.12978  192.5.5.241.53:  16218 ? H.ROOT-SERVERS.NET. 
(36)
16:44:35.121171 208.139.64.98.12978  192.5.5.241.53:  10080 A6? H.ROOT-SERVERS.NET. 
(36)
16:44:35.124668 208.139.64.98.12978  192.5.5.241.53:  1902 ? C.ROOT-SERVERS.NET. 
(36)
16:44:35.127544 208.139.64.98.12978  192.5.5.241.53:  10098 ? G.ROOT-SERVERS.NET. 
(36)
16:44:35.130185 208.139.64.98.12978  192.5.5.241.53:  6010 A6? C.ROOT-SERVERS.NET. 
(36)
16:44:35.133828 208.139.64.98.12978  192.5.5.241.53:  1920 A6? G.ROOT-SERVERS.NET. 
(36)
16:44:35.136286 208.139.64.98.12978  192.5.5.241.53:  12169 ? F.ROOT-SERVERS.NET. 
(36)
16:44:35.139433 208.139.64.98.12978  192.5.5.241.53:  3988 A6? F.ROOT-SERVERS.NET. 
(36)
16:44:35.142324 208.139.64.98.12978  192.5.5.241.53:  10140 A6? B.ROOT-SERVERS.NET. 
(36)
16:44:35.145453 208.139.64.98.12978  192.5.5.241.53:  14244 ? B.ROOT-SERVERS.NET. 
(36)
16:44:35.149344 208.139.64.98.12978  192.5.5.241.53:  16297 A6? J.ROOT-SERVERS.NET. 
(36)
16:44:35.151674 208.139.64.98.12978  192.5.5.241.53:  1968 ? J.ROOT-SERVERS.NET. 
(36)


Re: Legal intercept - 3550

2004-08-11 Thread Owen DeLong
You might be able to do what yo want by hard-coding the CAM entries in the
catalyst so that it forwards the MAC addresses you're concerned about to
the port in question, but, that may or may not achieve what you want, 
depending
on the makeup of the MAC addresses in the 300mbps traffic and whether there
is a limited number of MAC addresses that apply only to the traffic that
interests you (destination field only).

Otherwise, you really need to feed this off to anothger GE interface and
use libpcap (snoop, tcpdump, ethereal) to filter stuff into a file.
Owen


pgpkJj4xGWvPd.pgp
Description: PGP signature


Re: Legal intercept - 3550

2004-08-11 Thread Scott Stursa

On Wed, 11 Aug 2004, Stefan Baltus wrote:

 The catalyst 3350 is receiving the traffic from router to switch
 and vice versa.

Can we assume the 3550 port attached to the tap is GE?

 Now, we'd like to filter all but certain IP's on the
 3350 and switch this traffic to a FE port on that same 3550. Currently
 we've put the FE interface in SPAN mode, but that fills up the
 FE port completely (obviously). Is there any way to accomplish this?


It might be possible to assign a VLAN to the 3550 port and set up a VACL
(VLAN ACL) to filter, capture, and direct the data to another 3550 port. I
did this two years ago while evaluating an IDS blade in a 6500 chassis,
and wanted to reduce the number of false positives. In that case the
output was directed to the IDS module, but it may be possible to direct it
to a physical port.

I haven't messed with VACLs since then, and thus cannot provide specific
syntax for doing this, so I'd suggest you go to www.cisco.com and search
on: vacl ids

Good luck,

- SLS

-
Scott L. Stursa  850/645-2397
Network Security Assessment [EMAIL PROTECTED]
User Services/Office of Technology Integration   Florida State University

 The Internet? Yeah, I remember that. Well, all I can say is
 that it seemed like a good idea at the time...

   - Any Number of People, circa 2020


Re: Legal intercept - 3550

2004-08-11 Thread Joe Abley

On 11 Aug 2004, at 10:48, Ricardo Rick Gonzalez wrote:
I think you're confusing your OSI layers here, routers route and
switches switch.
Oh, those were the days.


Are AOL's MXs mass rejecting anyone else's emails?

2004-08-11 Thread Andrew Paprocki

We're currently getting this from AOL MX servers:



64.12.138.57 failed after I sent the message.

Remote host said: 554-: (RLY:FA) http://postmaster.info.aol.com/errors/554r
lyfa.html

554 TRANSACTION FAILED



Yet, after viewing their alleged reason for rejecting the mail, we can find
 nothing wrong with our mail headers. Wondering if this is a bug on AOL's s
ide or if anyone else has encountered/fixed this issue to stop the bouncing
 mail?



-Andrew


Verizon Data (T1) Rep?

2004-08-11 Thread Jonathan M. Slivko

Hello,

Can a Verizon Data (T1) Rep. please call/contact me off list ASAP? Thanks!
-- Jonathan

--
Jonathan M. Slivko
Invisible Hand Networks, Inc.
670 Broadway, Suite 302
New York, NY 10012
Phone: (212) 226-1422 x601
Fax:   (212) 202-7640

[EMAIL PROTECTED]




Re: Are AOL's MXs mass rejecting anyone else's emails?

2004-08-11 Thread rwcrowe

Just a suggestion, but make sure that your mail servers have the correct reverse DNS. AOL has been rejecting mail for any mail servers that have incorrect or no reverse DNS entries.
--Rob Crowe [EMAIL PROTECTED]
-- Original message --   We're currently getting this from AOL MX servers: 64.12.138.57 failed after I sent the message.   Remote host said: 554-: (RLY:FA) http://postmaster.info.aol.com/errors/554r  lyfa.html   554 TRANSACTION FAILED Yet, after viewing their alleged reason for rejecting the mail, we can find  nothing wrong with our mail headers. Wondering if this is a bug on AOL's s  ide or if anyone else has encountered/fixed this issue to stop the bouncing  mail? -Andrew 


Re: Legal intercept - 3550

2004-08-11 Thread Stefan Baltus

Thanks for all the replies. The best solution was by Boyan Krosnov who
suggested the following:

Configure the GE port where the traffic comes in from the fiber tap in a
separate new vlan A, access mode.
Configure fastethernet X to be in access mode for vlan A.
Configure a static mac entry for vlan A pointing the destination mac
address of the router where the traffic heads to to fastethernet X. 
Connect your sniffer on Fastethernet X. 
-- at this stage all traffic going to that router will be dumped to the
sniffer. Not precisely what you want. 
-- now comes the trick 
Configure a VLAN access-map
http://www.cisco.com/en/US/products/hw/switches/ps646/products_command_r
eference_chapter09186a008021145c.html
  ip access-list ext acl1
permit ip host x.x.x.x any
permit ip any host x.x.x.x
  vlan access-map alabala
   match ip address acl1 
   action forward
  vlan filter alabala vlan-list A

This works for my case. Boyan: thanks a lot.

Stefan

On Wed, Aug 11, 2004 at 04:37:24PM +0200, Stefan Baltus wrote:
 
 Hi,
 
 We have a situation where we need to intercept certain IP traffic
 that is somewhere within a link of 300Mbit/s of traffic (GigabitEthernet).
 The setup that we built is as follows:
 
 router 
   ^
   | GE
   | 
 fiber tap --- cisco catalyst 3550
   |
   | GE
   v
 switch
 
 
 The catalyst 3350 is receiving the traffic from router to switch
 and vice versa. Now, we'd like to filter all but certain IP's on the
 3350 and switch this traffic to a FE port on that same 3550. Currently
 we've put the FE interface in SPAN mode, but that fills up the
 FE port completely (obviously). Is there any way to accomplish this?
 
 Regards,
 
 Stefan 
 
 -- 
 Stefan Baltus [EMAIL PROTECTED]XB Networks B.V. 
 Manager Engineering Televisieweg 2
 telefoon: +31 36 54624001322 AC  Almere
 fax: +31 36 5462424 The Netherlands

-- 
Stefan Baltus [EMAIL PROTECTED]XB Networks B.V. 
Manager Engineering Televisieweg 2
telefoon: +31 36 54624001322 AC  Almere
fax: +31 36 5462424 The Netherlands


Re: Testing procedures for new network implementation?

2004-08-11 Thread Will Hargrave

On Wed, Aug 11, 2004 at 10:20:44AM -0400, Wayne Chow wrote:
 We are in the process of planning for the upgrade of a 3Com network.
 The new infrastructure will be comprised of 3Com 4950s with XRN and a dozen
 stacks of 4400s.
 What are the best practices of testing the new implementation?  Any advices
 or suggestions would be greatly appreciated.
 The only software that we have is the 3Com Network Director.

Ignoring the lame trolling which has already beset this thread, the 4400 is a 
solid, reasonably priced and fast edge switch [1]. 3Com could do some things 
better but then so can lots of manufacturers. They're certainly a world apart
from the old Superstack II stuff. Unfortunately they do little to market
some of the little know features of the platform. 

You want at least v3 firmware although v4 is out now and we've pretty much
deployed it with no problems.

There's not really a great deal to testing a L2 infrastructure. Analyse
the failure modes fully - power down devices to see what breaks, unplug optics 
and replug to check links come back up cleanly. Test and tune your spanning 
tree if you use it. Test multicast if you're using it. Create some loops
and see if storm control works. 

Usual site-specific stuff you'd probably have done during procurement -
test with your common desktop hardware, test with other devices, etc. 

We don't really use 3NS - it doesn't scale at all to our network - but we
do give it to some of the remote site 2nd-line people where they have a few
handfuls of switches in nonstandard topologies to look after.

Will.


[1] with ~400 24 and 48-port devices deployed on our network I feel I
can speak with a degree of authority. For our edge, Vendor 3 won a 
competitive OJEC tender vs others including Vendor C.


verizon postmaster contact?

2004-08-11 Thread Brian Russo

Can someone with verizon mail/postmaster group get in touch with me.

thanks,
 - bri


-- 
Recursivity. Call back if it happens again.



Datacenter

2004-08-11 Thread Daniel Corbe
Hello,
My company is looking to build a new Datacenter in the Ft. Lauderdale 
area of florida.  This is my first such experience building one from 
scratch.  Does anyone have or know of an available design guide?

What kind of options are available for backup power?  (IE low or 
midrange Diesel generators, Backup Battery Arrays, etc)  Can someone 
recommend a good electrician that has experience with Datacenters?

What about enviornmental controls?  (IE A/C Systems, Fire Supression 
systems designed for datacenters, Humidity control, access control (key 
card/pad systems), etc)

Anyone out there do raised flooring cheaply? :)


RE: Legal intercept - 3550

2004-08-11 Thread Burton, Chris

You could setup a Linux/Solaris (or other) device (It would need
to be GigE capable) and span all of the data to that port and then use
either iptables/ipchains to log the data and drop what don't need or use
ethereal/tcpdump to capture the data using filters to weed out the
information you do not need.  Also as mentioned in a previous reply you
could use the VLAN ACL features depending on your IOS version.  There
are several ways to achieve what you are looking to do; it just depends
on your level of comfort with configuring the methods mentioned and of
course cost.

Chris Burton
Network Engineer
Walt Disney Internet Group: Network Services

The information contained in this e-mail message is confidential,
intended only for the use of the individual or entity named above. If
the reader of this e-mail is not the intended recipient, or the employee
or agent responsible to deliver it to the intended recipient, you are
hereby notified that any review, dissemination, distribution or copying
of this communication is strictly prohibited. If you have received this
e-mail in error, please contact Walt Disney Internet Group at
206-664-4000.





-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of
Stefan Baltus
Sent: Wednesday, August 11, 2004 12:05 PM
To: [EMAIL PROTECTED]
Subject: Re: Legal intercept - 3550



Thanks for all the replies. The best solution was by Boyan Krosnov who
suggested the following:

Configure the GE port where the traffic comes in from the fiber tap in a
separate new vlan A, access mode. Configure fastethernet X to be in
access mode for vlan A. Configure a static mac entry for vlan A pointing
the destination mac address of the router where the traffic heads to to
fastethernet X. 
Connect your sniffer on Fastethernet X. 
-- at this stage all traffic going to that router will be dumped to the
sniffer. Not precisely what you want. 
-- now comes the trick 
Configure a VLAN access-map
http://www.cisco.com/en/US/products/hw/switches/ps646/products_command_r
eference_chapter09186a008021145c.html
  ip access-list ext acl1
permit ip host x.x.x.x any
permit ip any host x.x.x.x
  vlan access-map alabala
   match ip address acl1 
   action forward
  vlan filter alabala vlan-list A

This works for my case. Boyan: thanks a lot.

Stefan

On Wed, Aug 11, 2004 at 04:37:24PM +0200, Stefan Baltus wrote:
 
 Hi,
 
 We have a situation where we need to intercept certain IP traffic that

 is somewhere within a link of 300Mbit/s of traffic (GigabitEthernet). 
 The setup that we built is as follows:
 
 router 
   ^
   | GE
   |
 fiber tap --- cisco catalyst 3550
   |
   | GE
   v
 switch
 
 
 The catalyst 3350 is receiving the traffic from router to switch and 
 vice versa. Now, we'd like to filter all but certain IP's on the 3350 
 and switch this traffic to a FE port on that same 3550. Currently 
 we've put the FE interface in SPAN mode, but that fills up the FE port

 completely (obviously). Is there any way to accomplish this?
 
 Regards,
 
 Stefan
 
 -- 
 Stefan Baltus [EMAIL PROTECTED]XB Networks B.V. 
 Manager Engineering Televisieweg 2
 telefoon: +31 36 54624001322 AC  Almere
 fax: +31 36 5462424 The Netherlands

-- 
Stefan Baltus [EMAIL PROTECTED]XB Networks B.V. 
Manager Engineering Televisieweg 2
telefoon: +31 36 54624001322 AC  Almere
fax: +31 36 5462424 The Netherlands


Re: That MIT paper

2004-08-11 Thread David G. Andersen

On Wed, Aug 11, 2004 at 04:49:18PM +, Paul Vixie scribed:
 what i meant by act globally, think locally in connection with That
 MIT Paper is that the caching effects seen at mit are at best
 representative of that part of mit's campus for that week, and that

  Totally agreed.  The paper was based upon two traces, one from
MIT LCS, and one from KAIST in Korea.  I think that the authors
understood that they were only looking at two sites, but their
numbers have a very interesting story to tell -- and I think that
they're actually fairly generalizable.  For instance, the rather
poorly-behaving example from your f-root snapshot is rather consistent
with one of the findings in the paper:

  [Regarding root and gTLD server lookups] ...It is likely that
many of these are automatically generated by incorrectly implemented
or configured resolvers;  for example, the most common error 'loopback'
is unlikely to be entered by a user

 even a variance of 1% in caching effectiveness at MIT that's due to
 generally high or low TTL's (on A, or MX, or any other kind of data)
 becomes a huge factor in f-root's load, since MIT's load is only one

  But remember - the only TTLs that the paper was suggesting could be
reduced were non-nameserver A records.  You could drop those all to zero
and not affect f-root's load one bit.  In fairness, I think this is
jumbled together with NS record caching in the paper, since most
responses from the root/gTLD servers include both NS records and
A records in an additional section.

Global impact is greatest when the resulting load changes are
concentrated in one place.  The most clear example of that is changes
that impact the root servers.  When a 1% increase in total traffic
is instead spread among hundreds of thousands of different, relatively
unloaded DNS servers, the impact on any one DNS server is minimal.
And since we're talking about a protocol that variously occupies less than
3% of all Internet traffic, the packet count / byte count impact is
negligible (unless it's concentrated, as happens at root and
gtld servers).

The other questions you raise, such as:

 how much of the measured traffic was due to bad logic in 
 caching/forwarding servers, or in clients?  how
 will high and low ttl's affect bad logic that's known to be in wide
 deployment? 

are equally important questions to ask, but .. there are only so many
questions that a single paper can answer.  This one provides valuable
insight into client behavior and when and why DNS caching is effective.
There have been other papers in the past (for instance, Danzig's 1992
study) that examined questions closer to those you pose.  The results from
those papers were useful in an entirely different way (namely, that almost
all root server traffic was totally bogus because of client errors).

It's clear that from the perspective of a root name server operator,
the latter questions are probably more important.  But from the
perspective of, say, an Akamai or a Yahoo (or joe-random dot com),
the former insights are equally valuable.

  -Dave

-- 
work: [EMAIL PROTECTED]  me:  [EMAIL PROTECTED]
  MIT Laboratory for Computer Science   http://www.angio.net/


Re: That MIT paper

2004-08-11 Thread Randy Bush

there are many sites and isps like mit and kaist.  there are few
root servers.  while i care about the root servers, i presume that
they are run by competent folk and certainly they are measured to
death (which is rather boring from the pov of most of us).  i care
about isp and user site measurements.  i think the study by the mit
crew, which i have read a number of times, was a real service to
the community.

randy



Re: That MIT paper

2004-08-11 Thread William Allen Simpson

Paul Vixie wrote:
 
 (what if a general decline in TTL's resulted from publication of That
 MIT Paper?)
 
It's an academic paper.  The best antedote would be to publish a nicely 
researched reply paper.

Meanwhile, I'm probably one of those guilty of too large a reduction of 
TTLs.  I remember when the example file had a TTL of 99 for NS.  

What's the best practice? 

Currently, we're using (dig result, criticism appreciated):

watervalley.net.1d12h IN SOAns2.watervalley.net. hshere.watervalley.net. (
2004081002  ; serial
4h33m20s; refresh
10M ; retry
1d12h   ; expiry
1H ); minimum

watervalley.net.1H IN MX10 mail.watervalley.net.
watervalley.net.1H IN A 12.168.164.26
watervalley.net.1H IN NSns3.watervalley.net.
watervalley.net.1H IN NSns1.ispc.org.
watervalley.net.1H IN NSns2.ispc.org.
watervalley.net.1H IN NSns2.watervalley.net.
watervalley.net.1H IN NSns3.ispc.org.

;; ADDITIONAL SECTION:
mail.watervalley.net.   1H IN A 12.168.164.3
ns1.ispc.org.   15h29m10s IN A  66.254.94.14
ns2.ispc.org.   15h29m10s IN A  199.125.85.129
ns2.watervalley.net.1D IN A 12.168.164.2
ns3.ispc.org.   15h29m10s IN A  12.168.164.102
ns3.watervalley.net.1H IN A 64.49.16.2

-- 
William Allen Simpson
Key fingerprint =  17 40 5E 67 15 6F 31 26  DD 0D B9 9B 6A 15 2C 32


Fwd: Re: Are AOL's MXs mass rejecting anyone else's emails?

2004-08-11 Thread Andrew Paprocki

This message was sent to me offline after my post to the list. This apparen
tly solved our problems. Just sending back to the list so anyone else searc
hing for this issue can find an answer. Thanks NANOG!



-Andrew



 - Begin Forwarded Message -



 To: [EMAIL PROTECTED]

 From: [EMAIL PROTECTED]

 Subject: Re: Are AOL's MXs mass rejecting anyone else's emails?

 Date: Wed, 11 Aug 2004 11:41:24 -0700



 Andrew,

 

 I lurk on the NANOG list for interesting topics (can't currently post thr
u). I

 started having this exact same problem in June with AOL. Spent an hour on
 the

 phone with Michael W ([EMAIL PROTECTED]) and another couple hours doin
g

 debuging via telnet to their servers before figuring it out.

 

 The problem in my case is that they seem to have put in place an email he
ader

 order filter (which gives back the 554 RLY:FA error if failed). Of course
, the

 web/mail masters didn;t seem to have any idea the mail admins did this.

 

 In my case, the problem is caused by the position of the From:, Mime:
, and

 Content: headers. The From: header MUST come before the other 2 in th
e

 message flow, otherwise it is rejected. I don't know of any RFC which dic
tates

 email header order... but apparently AOL is filtering on it... I forwarde
d this

 info to them long ago and Michael said he would add it to their notes.

 

 Below is the message I sent them with the details:

 ---

 Date: Thu, 10 Jun 2004 12:22:35 -0700

 From: [EMAIL PROTECTED]

 Subject: Bouncing email - believe to have found the problem

 To: [EMAIL PROTECTED]

 

  I think I have found the problem with the 554 RLY:FA error message.

  According

  to

  my logs, I have been able to successfully send you a few messages.

  

  The problem appears to lie in the processing of mail header order withi
n the

  email message itself, not the SMTP MAIL FROM or RCPT TO commands.

  Previously when I sent out email, the headers of the email would look

  something

  like:

  

Received from: blah blah blah

To: [EMAIL PROTECTED]

Subject: subject

MIME-Version: 1.0

Content-type: text/html; charset=iso-8859-1

From: [EMAIL PROTECTED]

Message-Id: [EMAIL PROTECTED]

Date: date string

  

Message...

  

  This was done through a PHP script using the mail() function,  based 
on

  the

  example 4 in the PHP manual (http://www.php.net/manual/en/function.mail
.php)

  (NOTE: in the example they have To/From/CC: and Bcc: headers following

  MIME/Content headers). This method still works fine through several oth
er

  mail 

  servers (cox.net, arizona.edu, af.mil) and had worked fine for the past
 year

  with aol.com. As of approximately Jun 9th, 4pm MST (or earlier, was wor
king

  at

  10am according to my logs), this no longer works with AOL servers.

  

  After some manipulation I have found that for the AOL servers, the From
:

  header

  (regardless of the SMTP MAIL FROM command) MUST come before the MIME

  and/or

  Content headers within the email message. It appears that reordering th
e

  To/From/CC: headers does not affect the outcome, so long as the From: h
eader

  precedes the MIME: and Content: headers of the message.

  

  Therefore, for a message to get through to an AOL user, the message mus
t be

  formatted in the manner of:

  

Received from: blah blah blah

To: [EMAIL PROTECTED]

Subject: subject

From: [EMAIL PROTECTED]

MIME-Version: 1.0

Content-type: text/html; charset=iso-8859-1

Message-Id: [EMAIL PROTECTED]

Date: date string

  

Message...

  

 

  

 Adrian Jensen

 [EMAIL PROTECTED]

 Systems Administrator

 National Traffic Safety Institute

 Tucson, Az

 

 

 This mail was sent through webmail services for the 

 National Traffic Safety Institute and may contain

 privileged and confidential information. Use or 

 interception by any intermediate agency or 

 individual is prohibited.

 

 



 - End Forwarded Message -