Re: an over-the-top data center
Just me, or is showing the floorplan not the typical behavior of a super-secure anything? --Original Message-- From: Måns Nilsson To: Steven M. Bellovin To: NANOG Sent: Nov 28, 2008 6:52 AM Subject: Re: an over-the-top data center --On fredag, fredag 28 nov 2008 08.34.33 -0500 "Steven M. Bellovin" <[EMAIL PROTECTED]> wrote: > http://royal.pingdom.com/2008/11/14/the-worlds-most-super-designed-data-c > enter-fit-for-a-james-bond-villain/ (No, I don't know if it's real or > not.) It is. The server space is outside the blastproof area. Go figure. -- Måns NilssonM A C H I N A I'm into SOFTWARE!
Re: Recommendation of Tools
Hi... > According to the 0.75 sorcecode ICMP is still the default prot used, > and the definition of MTR from bitwizards homepage disagress with you: > > "mtr combines the functionality of the 'traceroute' and 'ping' > programs in a single network diagnostic tool. > As mtr starts, it investigates the network connection between the > host mtr runs on and a user-specified destination host. After it > determines the address of each network hop between the machines, it > sends a sequence ICMP ECHO requests to each one to determine the > quality of the link to each machine. As it does this, it prints > running statistics about each machine. For a preview take a look at > the screenshots." > > Even if you use UDP/TCP or whatever, the return packet will be ICMP > and that will be ratelimited by any carrier worth there salt... ...recent attempts to get mtr working through a cisco fwsm got me sniffing, and yes indeed, icmp is the protocol in play with mtr (both outbound and inbound). Rgs, craig
Re: Comcast DNS
Hi... > I find your report too specific. Can you make it a bit more generic, > perhaps by not including the name of the company that provides a myriad > of web-based services? Isn't 'specific' good for operations related stuff? I mean if you are just complaining about something for the sake of complaining or are giving examples I can see where names wouldn't be necessary. Rgs, Craig
Re: Comcast DNS
*blush* at missing the original sarcasm. --Original Message-- From: Craig Holland To: NANOG Sent: Dec 8, 2008 5:42 PM Subject: Re: Comcast DNS Hi... > I find your report too specific. Can you make it a bit more generic, > perhaps by not including the name of the company that provides a myriad > of web-based services? Isn't 'specific' good for operations related stuff? I mean if you are just complaining about something for the sake of complaining or are giving examples I can see where names wouldn't be necessary. Rgs, Craig
Re: Network diagram software
Mathias Wolkert wrote: >>> OmniGraffle is the better Visio. ...except I've not found any good networking/systems stencils for omnigraffle (even on graffletopia). I tried to import the visio ones in 5.0 but that didn't work too well. Someone out there have something for omnigraffle that rivals the visio network stencils? Thanks, craig
Fiber cut in SF area
Just dropping a note that there is a fiber cut in the SF area (I have a metro line down). AboveNet is reporting issues and I've heard unconfirmed reports that ATT and VZW are affected as well. Rgs, craig
Savvis route loop
Hi, Could someone from Savvis contact me off-list please. We have been stuck behind a route-loop since last night's maintenance: traceroute 208.91.191.1 traceroute to 208.91.191.1 (208.91.191.1), 64 hops max, 40 byte packets 1 FE0-0-12.nav1.nyc.access.net (166.84.1.28) 0.443 ms 0.568 ms 0.456 ms 2 port-channel1-128.l3core.nyc.access.net (166.84.66.1) 1.359 ms 1.000 ms 0.977 ms 3 gi0-7.na21.b001105-3.jfk02.atlas.cogentco.com (38.102.195.129) 1.499 ms 1.788 ms 1.312 ms 4 vl3608.mpd01.jfk02.atlas.cogentco.com (38.20.32.61) 1.861 ms 1.695 ms 3.223 ms 5 vl3493.mpd03.jfk02.atlas.cogentco.com (154.54.5.226) 2.714 ms te2-3.mpd03.jfk02.atlas.cogentco.com (154.54.3.1) 2.482 ms vl3493.mpd03.jfk02.atlas.cogentco.com (154.54.5.226) 2.634 ms 6 te8-3.mpd01.dca01.atlas.cogentco.com (154.54.5.98) 12.221 ms 8.209 ms 9.022 ms 7 vl3498.mpd01.dca02.atlas.cogentco.com (154.54.7.6) 10.168 ms vl3492.mpd01.dca02.atlas.cogentco.com (66.28.4.86) 8.746 ms 11.408 ms 8 vl3496.mpd01.iad01.atlas.cogentco.com (154.54.5.46) 17.866 ms vl3494.mpd01.iad01.atlas.cogentco.com (154.54.5.42) 11.052 ms vl3497.mpd01.iad01.atlas.cogentco.com (154.54.5.66) 8.642 ms 9 ber1-ge-7-43.virginiaequinix.savvis.net (208.173.10.181) 8.604 ms 8.954 ms ber1-ge-7-39.virginiaequinix.savvis.net (208.173.52.105) 8.373 ms 10 * cr1-tengig0-7-2-0.washington.savvis.net (204.70.197.242) 9.919 ms 10.052 ms 11 cr2-pos-0-0-5-0.sanfrancisco.savvis.net (204.70.200.194) 83.281 ms 82.172 ms 82.575 ms 12 pr1-so-0-0-0.PaloAltoPaix.savvis.net (204.70.200.193) 80.832 ms 82.515 ms 81.396 ms 13 pr3-so-0-0-0.PaloAltoPaix.savvis.net (204.70.199.106) 80.805 ms 81.499 ms 80.664 ms 14 206.24.241.202 (206.24.241.202) 94.556 ms 89.078 ms 90.265 ms 15 pr3-ge-3-0-0.PaloAltoPaix.savvis.net (206.24.241.201) 82.002 ms 81.618 ms 81.731 ms 16 206.24.241.202 (206.24.241.202) 82.548 ms 85.024 ms 90.215 ms 17 pr3-ge-3-0-0.PaloAltoPaix.savvis.net (206.24.241.201) 83.186 ms 84.437 ms 83.145 ms 18 206.24.241.202 (206.24.241.202) 94.735 ms 89.556 ms 89.939 ms 19 pr3-ge-3-0-0.PaloAltoPaix.savvis.net (206.24.241.201) 83.556 ms 84.091 ms 85.894 ms 20 206.24.241.202 (206.24.241.202) 88.289 ms 90.290 ms 89.362 ms Thanks, Craig Craig Holland Rhythm NewMedia Sr. Director Operations & Integration YIM: cholland
Sprint/Cogent Peering Issue?
Hi, We are seeing traffic getting dropped between our Cogent and Sprint connect DC's. One of them is getting shutdown, so we just have a Cogent link there :| Anyone seeing anything similar? From: 91.102.40.18 traceroute to ops1.scc.rnmd.net (208.91.188.136), 30 hops max, 38 byte packets 1 v1-core-sw1 (91.102.40.5) 0.471 ms 0.422 ms 0.431 ms 2 ge-0-1-0-pat2 (91.102.40.146) 0.376 ms 0.354 ms 0.335 ms 3 fe-1-3-1-501-pat1 (91.102.40.208) 0.376 ms 0.344 ms 0.407 ms 4 vl324.mpd01.lon01.atlas.cogentco.com (149.6.147.217) 0.745 ms 0.744 ms 0.740 ms 5 te3-1.mpd02.lon01.atlas.cogentco.com (130.117.2.26) 0.717 ms 39.037 ms te1-8.ccr01.lon01.atlas.cogentco.com (130.117.3.226) 0.565 ms 6 gi6-0-0.core01.lon01.atlas.cogentco.com (130.117.1.73) 0.592 ms 0.450 ms 0.483 ms 7 213.206.131.29 (213.206.131.29) 0.581 ms 0.503 ms 0.483 ms 8 sl-bb21-lon-3-0.sprintlink.net (213.206.129.152) 1.078 ms 0.905 ms 0.934 ms 9 * >From 208.91.188.138 traceroute to ops2.lnc.rnmd.net (91.102.40.18), 30 hops max, 38 byte packets 1 v1-core-sw1 (208.91.188.130) 0.600 ms 0.456 ms 2.105 ms 2 f0-0-4-0-pat2 (207.0.21.114) 0.416 ms 0.466 ms 0.486 ms 3 sl-st1-sc-2-6.sprintlink.net (144.228.111.25) 0.455 ms 0.224 ms 0.236 ms 4 sl-crs2-sj-0-1-0-3.sprintlink.net (144.232.20.196) 1.482 ms 1.477 ms 1.232 ms 5 sl-st20-sj-12-0-0.sprintlink.net (144.232.20.63) 2.482 ms 2.472 ms 2.485 ms 6 po5-3.core01.sjc03.atlas.cogentco.com (154.54.13.49) 2.732 ms 2.472 ms 2.485 ms 7 te3-1.mpd01.sjc03.atlas.cogentco.com (154.54.6.85) 2.705 ms 2.723 ms 2.735 ms 8 vl3493.ccr02.sjc01.atlas.cogentco.com (154.54.6.109) 3.231 ms vl3492.mpd01.sjc01.atlas.cogentco.com (154.54.6.105) 3.227 ms vl3491.ccr02.sjc01.atlas.cogentco.com (154.54.6.101) 2.726 ms 9 te9-3.mpd01.sfo01.atlas.cogentco.com (154.54.2.53) 3.968 ms 3.722 ms te8-3.ccr02.sfo01.atlas.cogentco.com (154.54.2.137) 3.988 ms 10 te9-2.ccr02.mci01.atlas.cogentco.com (154.54.24.118) 50.943 ms te7-4.mpd01.mci01.atlas.cogentco.com (154.54.24.106) 50.944 ms 50.720 ms 11 te9-3.ccr02.ord01.atlas.cogentco.com (154.54.25.78) 50.669 ms 63.423 ms te9-3.mpd01.ord01.atlas.cogentco.com (154.54.25.82) 51.206 ms 12 te2-1.ccr02.bos01.atlas.cogentco.com (154.54.7.170) 78.172 ms te3-3.mpd01.bos01.atlas.cogentco.com (154.54.7.82) 100.666 ms te2-1.ccr02.bos01.atlas.cogentco.com (154.54.7.170) 78.176 ms 13 * * * Thanks, craig ____ Craig Holland Rhythm NewMedia Sr. Director Operations & Integration YIM: cholland
ARIN Routing Registry vs RADB vs X
Hi, I recently ran across a situation where a large ISP only accepts IRR entries generated by RADB to build their path filters. I use the ARIN Routing Registry. Is this a common practice? Should I convert over to RADB? Thanks, Craig
RE: ARIN Routing Registry vs RADB vs X
Hi... > Are you saying the ISP only accepts entries they can pull from the RADB? > Or > only entries that originate with the RADB? ...ones that only originate from RADB. This is the part that I found strange considering the ARIN records are in (show up in) RADB and they are what most would consider a trusted source. CH > If the former, you're fine. > Your > ARIN records are in the RADB. > > DS > > >
RE: ARIN Routing Registry vs RADB vs X
They gave no particular reason. I figured I'd ask ya'all before I started to push back and use phrases like 'silly', 'ridiculous', and 'pointless' in my argument to them. Thanks, Craig > -Original Message- > From: Christian Koch [mailto:[EMAIL PROTECTED] > Sent: Thursday, September 25, 2008 3:53 PM > To: Craig Holland > Cc: [EMAIL PROTECTED] > Subject: Re: ARIN Routing Registry vs RADB vs X > > Sounds ridiculous...radb mirrors arins db, I don't see why they are > trying to force you to use radb. > > You can query whois.radb.net and you will be able to see your arin > objects... > > Did they give you a reason on WHY you should have to use RADB? > > > Christian > > > > On Thu, Sep 25, 2008 at 6:38 PM, Craig Holland <[EMAIL PROTECTED]> wrote: > > Hi, > > > > I recently ran across a situation where a large ISP only accepts IRR > > entries generated by RADB to build their path filters. I use the ARIN > > Routing Registry. Is this a common practice? Should I convert over to > > RADB? > > > > Thanks, > > Craig > > > > > >
