Which IOS do *you* use?

Sorry folks,

I'm up too late. I replied to the wrong list! Have a good
night everyone.

-Robert


Tellurian Networks - The Ultimate Internet Connection
http://www.tellurian.com
| 888-TELLURIAN | 973-300-9211
"Well done is better than well said." - Benjamin
Franklin

On Friday 01 June 2007, Vince Fuller wrote:
> If you think about it, the NAT approach actually offers
the possibility of
> improved routing scalability: site multihomed with NATs
connected to each
> of its providers could use topologically-significant
(read "PA") global
> addresses on the NATs while using the same private
address space on their
> network. 

Cisco has a whitepaper entitled "Enabling Enterprise
Multihoming with Cisco 
IOS NAT" that addresses this.  See 
http://www.cisco.com/e
n/US/tech/tk648/tk361/technologies_white_paper09186a0080091c
8a.shtml
as well as RFC2260.

There are indeed a few thorny issues with this approach; the
largest issue is 
that all connectivity becomes DNS-dependent and raw IP
addresses (from both 
the inside and outside) become virtually useless.  Running
servers behind 
this scheme, while doable, is difficult.
-- 
Lamar Owen
Chief Information Officer
Pisgah Astronomical Research Institute
1 PARI Drive
Rosman, NC  28772
(828)862-5554
www.pari.edu

On Monday 04 June 2007, Valdis.Kletnieksvt.edu
wrote:
> Nope. Zip. Zero. Ziltch.  Nothing over and above what a
good properly
> configured stateful *non*-NAT firewall should be doing
for you already.

Since when are CPE devices 'properly' configured?
-- 
Lamar Owen
Chief Information Officer
Pisgah Astronomical Research Institute
1 PARI Drive
Rosman, NC  28772
(828)862-5554
www.pari.edu

On Monday 03 September 2007, Steven M. Bellovin wrote:
> More seriously -- the question is whether new services
will cause
> operator congestion problems that today's mechanisms
don't handle.
> It's also possible, per the note that some solutions
will have operator
> implications, such as new tuning knobs for routers
and/or new funky new
> DNS records to make it clear which hosts support TCP++.
 Beyond that,
> there are likely implications for things like
firewalls, ACLs, and
> service measurements.

Is this not partially where SCTP fits in?  Reading a few of
the SCTP RFC's 
certainly indicates that SCTP has some interesting
possibilities as far as 
congestion control is concerned.
-- 
Lamar Owen
Chief Information Officer
Pisgah Astronomical Research Institute
1 PARI Drive
Rosman, NC  28772
(828)862-5554
www.pari.edu

On Sunday 23 March 2008, Justin Shore wrote:
> There are a few things to remember.  Code only permits
you to load a
> circuit to 80% of its maximum-rated capacity.  The
remaining 20% is the
> safety margin required by the NEC.  Knowing this that
means that the
> 12Kw specified above require 7x 20a 120v circuits or 5x
30a 120v circuits.

Cord connected loads can be 50A easily enough; something
like a NEMA L21-60P 
can give you 18KW in one plug (after 80% derating); if you
could use 277V the 
L22-60P is available to get you almost 40KW on one plug
(again, after the 80% 
is factored in; it's almost 50KW at 100% rating).  Hubbell
makes 60 and 100A 
plugs and receptacles if 40KW isn't enough.  PDU's for these
are more scarce, 
but I'm sure Marway would build to suit.

We have a few of the older Hubbell 50A twistloks here that
were used for some 
sort of signal processing equipment back in the day.

> Also remember that many of the larger servers (such as
the Dell 6850s or
> 6950s) are 240v and will require a pair of dedicated
circuits (20a or 30a).

The 6950 can run on 120VAC.  That is one of the primary
reasons we bought 
6950's with Opterons instead of 6850's with Xeons; I only
had 120VAC capable 
UPS's at the time.

With router densities going way up, and heating going along
with them, this 
facilities issue can even impact the network operator.

> I would also recommend that you look into in-row power
distribution
> cabinets like the Liebert FDC. 

We have Liebert PPA's here.  Two 125's and a 50.

> Grounding is a topic that is worthy of its own book. 
Consult an
> electrician used to working with data centers.  Don't
overlook this
> critical thing.  

Ground reference grid.  See Cisco's 'Building the Best Data
Center for your 
Business' book and/or Sun's Blueprint series datacenter book
for more good 
information.  Also be thoroughly familiar with NEC Article
645.

While this discussion might seem out of the ordinary for a
network operator's 
group, it is a very good discussion.

Another good resource for datacenter/commcenter information
is 
www.datacenterknowledge.com; at least I've found it to be.
-- 
Lamar Owen
Chief Information Officer
Pisgah Astronomical Research Institute
1 PARI Drive
Rosman, NC  28772
(828)862-5554
www.pari.edu

On Monday 24 March 2008, Robert E. Seastrom wrote:
> Lamar Owen <lowenpari.edu> writes:
> > While this discussion might seem out of the
ordinary for a network
> > operator's group, it is a very good discussion.
>
> The sad part is the extraordinariness of discussions
that are so
> solidly on-topic as this one.  Thanks for your
contribution; I (at
> least) really appreciate it.

You're quite welcome.

There is a whole 'nother side to this, too, especially for
those who run DC 
power.  The ampacity of conductors is quite a bit higher for
DC; I have a 
copy of the best book on that subject, written by a telco
engineer.  Let's 
see:

"DC Power System Design for Telecommunications" by
Whitham D. Reeve, Wiley is 
the publisher.  

This is an expensive book; about $100 from Wiley; low price
on Amazon right 
now is $75.75.  This one goes over EVERYTHING when it comes
to DC power 
distribution design and implementation.  It was worth the
price I paid, 
that's for sure.

We have two 200A Lorains here, with A battery being 450Ah of
C&D flooded 
cells, and B battery being a bank of 4 135Ah 12V sealed AGM
batteries.  Our 
core switches and all but one of our core routers have DC
power supplies.

Incidentally, all of this is fresh to me primarily because
I'm in the process 
of building a new datacenter and moving our existing
equipment into it, 
primarily for RFI mitigation reasons.
-- 
Lamar Owen
Chief Information Officer
Pisgah Astronomical Research Institute
1 PARI Drive
Rosman, NC  28772
(828)862-5554
www.pari.edu

On Monday 24 March 2008, Deepak Jain wrote:
> While I enjoy hand waving as much as the next guy...
reading over this
> thread, there are several definitions of sq ft (ft^2)
here and folks are
> interchanging their uses whether aware of it or not.
[snip]
> A 30KW cabinet while one sounds lovely, a huge amount
of space is going
> to turned over to most or all of a dedicated PCU and
1/15th of the
> infrastructure of 500KVA UPS (0.9PF) including batteries,
transformers,
> etc.
[snip]
> Even ignoring heat rejection, the battery + UPS gear
for 500KVA (even
> with minimal battery times) is approximately the same
size (physically)
> as the 12 cabinets or so it takes to reach that
capacity.  [same applies
> for flywheel/kinetic systems]

This is certainly a fascinating thread.

One thing I haven't seen discussed, though, is the other big
issue with 
high-density equipment, and that is weight.

Those raised floors have a weight limit.  In our case, our
floors, built out 
in the early 90's, have a 1500 lb per square inch point load
rating, and 
7,000 pound per pedestal max weight.  The static load rating
of 300 pounds 
per square foot on top of the point load rating doesn't
sound too great, but 
it's ok; we just have to be careful.  Our floors are
concrete-in-steel, on 24 
inch pedestals, with stringers.

In contrast, a 42U rack loaded with 75 pound 1U servers is
going to weigh 
upwards of  3,150 pounds (if you figure 300 pounds for the
rack and the PDU's 
in the rack, make that 3,450 pounds).  When we get to
heavier than 75 pound 
1U servers things are going to get dicey.  Also in contrast,
a fully loaded 
EMC CX700 is about 2,000 pounds.

It sounds more and more like simply charging for
rack-occupied square footage 
is an unsustainable business model.  The four actual
billables are power, 
cooling (could be considered power), bandwidth, and weight. 
When we see 
systems as dense as a Cray 2, but with modern IC's, we'll be
treated to 
flourinert waterfalls again. 
-- 
Lamar Owen
Chief Information Officer
Pisgah Astronomical Research Institute
1 PARI Drive
Rosman, NC  28772
(828)862-5554
www.pari.edu

On Tuesday 25 March 2008, Aaron Glenn wrote:
> On Tue, Mar 25, 2008 at 6:15 PM, Patrick Clochesy
<patrickchegg.com> wrote:
> > Very interesting study I had not seen, and a
bummer. That really puts a
> > cramp in my advocation of our CARP+pf load
balancers/firewalls/gateways.
> > Than again, what's a PIX box capable of?

> I'd rather tweak a whitebox than pay through the nose
for a PIX.

But aren't PIXen whiteboxes internally?  I know the PIX-like
LocalDirector 
that was donated to us makes a very nice nBox deployment for
us.

Lots of these sorts of boxes are internally whiteboxes (I'm
using that term 
loosely to mean an Intel-based box that could potentially
run something like 
a Linux or *BSD).  The second-hand Content Engine 565 I got
on eBay that had 
a fried power supply was just a Cisco-labeled IBM eServer
xSeries 305, and 
was loaded with WindowsXP when I got it.  It's running
CentOS 5 now, with a 
new IBM power supply in the box.  The two earlier Content
Engines and two 
even earlier Cache Engines I got second-hand are likewise
custom Intel 
hardware; PIII 800's, to be precise.  Now, they DO use ECC
RAM, which most 
whiteboxes won't have.  But otherwise they are customized
whiteboxes, and 
you're paying for the software and support.

But cisco is not alone in this.  Nomadix gateways, to use
one example, are 
built on custom embedded x86 systems.

What I'm waiting on is someone to take a system like a
Xilinx ML410 dev board 
and use the FPGA to do hardware-accelerated
forwarding/filtering.  See 
http://www.lynuxworks.com/board-support/xilinx/ml410.php
 for info on the 
board.

As to PIXen performance, see the charts in 
http://en.wiki
pedia.org/wiki/Cisco_PIX
-- 
Lamar Owen
Chief Information Officer
Pisgah Astronomical Research Institute
1 PARI Drive
Rosman, NC  28772
(828)862-5554
www.pari.edu