Re: [Nanog-futures] ADMIN: Reminder on off-topic threads
Moderation has never worked well. Personal choice, killfiles, are optimal IMHO. I agree. is there another ops group, ripe, sanog, apops, afnog, ... which seems to need/want moderation? i am not aware of any other list i read that is moderated. if not, does that seem a bit strange to anyone (else)? and the moderation has not, imiho, improved the content of the mailing list. the bean counters, albeit well meaning, only know how to cut expenses. you don't make a successful company by throttling expense. it's the income that makes a company. randy ___ Nanog-futures mailing list Nanog-futures@nanog.org http://mailman.nanog.org/mailman/listinfo/nanog-futures
Re: [Nanog-futures] Fwd: ADMIN: Reminder on off-topic threads
Let's try and take a step back, and see how low-key moderation works again? No, let's not. To steal a line from rbush, we tried that three years ago and it didn't work then. actually it did The current MLC's approach is working Just Fine; in your opinion mine differs ___ Nanog-futures mailing list Nanog-futures@nanog.org http://mailman.nanog.org/mailman/listinfo/nanog-futures
Re: Important New Requirement for IPv4 Requests
On Apr 21, 2009, at 5:23 PM, Matthew Palmer wrote: Oh, you lucky, lucky person. We've got a couple of customers at the day job that constantly come back to us for more IP addresses for bandwidth accounting purposes for their colo machine(s). Attempts at education are like talking to a particularly stupid brick wall. And not very effective either, because anything they do to solve the problem another way will likely create the valid need for an external IP. These days, virtual hosting is all virtual machines, so the IP justification is just there anyway. -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness
Re: IXP
On 24.04.2009 03:48 Paul Vixie wrote Bill Woodcock wo...@pch.net writes: ... Nobody's arguing against VLANs. Paul's argument was that VLANs rendered shared subnets obsolete, and everybody else has been rebutting that. Not saying that VLANs shouldn't be used. i think i saw several folks, not just stephen, say virtual wire was how they'd do an IXP today if they had to start from scratch. i know that for many here, starting from scratch isn't a reachable worldview, and so i've tagged most of the defenses of shared subnets with that caveat. the question i was answering was from someone starting from scratch, and when starting an IXP from scratch, a shared subnet would be just crazy talk. I like to disagree here, Paul. Best regards, Arnold -- Arnold Nipper / nIPper consulting, Sandhausen, Germany email: arn...@nipper.de phone: +49 6224 9259 299 mobile: +49 172 2650958 fax: +49 6224 9259 333 signature.asc Description: OpenPGP digital signature
Re: Important New Requirement for IPv4 Requests
On Apr 21, 2009, at 5:20 PM, Matthew Palmer wrote: Then they come back with a request for IPs for SSL certificates, which is a valid technical justification. BTDT. People will find a way to do the stupid thing they want to do. Most of the stupid people don't, actually. That's the funny thing that surprises me -- just how obviously lame the justifications are, and how they are unable even with direct statements about how to justify the IP space to do so. My god, it's really not hard to build a valid justification for more space than you need -- seriously. But these people just can't pull it off. Likewise, every company with whom I've had to debate the topic has failed within 18 months, so the problem pervades the organization ;-) -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness
Re: Important New Requirement for IPv4 Requests
On Apr 21, 2009, at 6:50 PM, bmann...@vacation.karoshi.com wrote: FTP? Who uses FTP these days? Certainly not consumers. Even Cisco well, pretty much anyone who has large datasets to move around. that default 64k buffer in the openssl libs pretty much sucks rocks for large data flows. Large data sets? So you are saying that 512-byte packets with no windowing work better? Bill, have you measured this? Time to download a 100mb file over HTTP and a 100mb interface: 20 seconds. Time to download a 100mb file over FTP and a 100mb interface: ~7 minutes. And yes, that was FreeBSD with the old version openssl library that shipped with 6.3. -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness
Re: IXP
Leo Bicknell wrote: In a message written on Fri, Apr 24, 2009 at 01:48:28AM +, Paul Vixie wrote: i think i saw several folks, not just stephen, say virtual wire was how they'd do an IXP today if they had to start from scratch. i know that for many here, starting from scratch isn't a reachable worldview, and so i've tagged most of the defenses of shared subnets with that caveat. the question i was answering was from someone starting from scratch, and when starting an IXP from scratch, a shared subnet would be just crazy talk. I disagree. Having no shared subnet renders an exchange switching platform useless to me. If I have to go to all the work of configuring both ends in a exchange point operator provisioning system (and undoubtly being billed for it), assigning a /30, and configuring an interface on my router then I will follow that procedure and order a hunk of fiber. Less points of failure, don't have to deal with how the exchange operator runs their switch, and I get the bonus of no shared port issues. The value of an exchange switch is the shared vlan. I could see an argument that switching is no longer necessary; but I can see no rational argument to both go through all the hassles of per-peer setup and get all the drawbacks of a shared switch. Even exchanges that took the small step of IPv4 and IPv6 on separate VLAN's have diminished value to me, it makes no sense. It's the technological equvilient of bringing everyone into a conference room and then having them use their cell phones to call each other and talk across the table. Why are you all in the same room if you don't want a shared medium? I second that. We got to go through all the badness that was the ATM NAPs (AADS, PacBell NAP, MAE-WEST ATM). I think exactly for the reason Leo mentions they failed. That is, it didn't even require people to figure out all the technical reasons they were bad (many), they were fundamentally doomed due to increasing the difficulty of peering which translated to an economic scaling problem. i.e. if you make it hard for people to peer then you end up with less peers and shared vlan exchanges based on things like ethernet outcompete you. Been there done that. We've already experienced the result of secure ID cards and the PeerMaker tool. It was like pulling teeth to get sessions setup, and most peers plus the exchange operator didn't believe in oversubscription (can you say CBR? I knew you could), so you end up with 2 year old bandwidth allocations cast in stone because it was such a pain to get the peer to set it up in the first place, and to increase bandwidth to you means your peer has to reduce the bandwidth they allocated to somebody else. Mike. -- + H U R R I C A N E - E L E C T R I C + | Mike LeberWholesale IPv4 and IPv6 Transit 510 580 4100 | | Hurricane Electric AS6939 | | mle...@he.net Internet Backbone Colocation http://he.net | +-+
Re: Important New Requirement for IPv4 Requests
Large data sets? So you are saying that 512-byte packets with no windowing work better? Bill, have you measured this? Time to download a 100mb file over HTTP and a 100mb interface: 20 seconds. Time to download a 100mb file over FTP and a 100mb interface: ~7 minutes. And yes, that was FreeBSD with the old version openssl library that shipped with 6.3. As someone who copies large network trace files around a bit, 100MB at 100mb, over what I presume is a local (low latency) link is barely a fair test. Many popular web servers choke on serving files 2GB or 4GB in size (Sigh). I'm in New Zealand. It's usually at least 150ms to anywhere, often 300ms, so I feel the pain of small window sizes in popular encryption programs very strongly. Transferring data over high speed research networks means receive windows of at least 2MB, usually more. When popular programs provide their own window of 64kB, things get very slow.
Re: IXP
It's the technological equvilient of bringing everyone into a conference room and then having them use their cell phones to call each other and talk across the table. Why are you all in the same room if you don't want a shared medium? Probably the wrong people to ask (cf. IRC @ NANOG meetings...) brandon
Config Backup / Inventory
Hi, I am looking for a bit of advice around configuration backup / inventory. We currently have a large multi-vendor network which is currently managed through two separate tools (rancid - http://www.shrubbery.net/rancid and ns4 - http://www.noodles.org.uk/ns4.html). Both tools do the job very well, but management have asked that we look for commercial alternatives that have a proper support organisation looking after them. IP Service Activator has been mentioned as something which can fit this role, but I haven't had any experience and I haven't heard a lot of good things about it. We are looking for a tool which is flexible that allows configuration backup to textual form for easy restoration as well as the ability to deploy scripted changes to the network quickly. Do people generally use free tools for network management or are there viable commercial alternatives? Thanks, Josh
Re: IXP
But routers dont have bo.:) --- original message --- From: Brandon Butterworth bran...@rd.bbc.co.uk Subject: Re: IXP Date: 24th April 2009 Time: 8:16:00 am It's the technological equvilient of bringing everyone into a conference room and then having them use their cell phones to call each other and talk across the table. Why are you all in the same room if you don't want a shared medium? Probably the wrong people to ask (cf. IRC @ NANOG meetings...) brandon
Re: Important New Requirement for IPv4 Requests
On Wed, Apr 22, 2009 at 10:57:31AM +1000, Matthew Palmer wrote: On Tue, Apr 21, 2009 at 08:24:38PM -0400, Ricky Beam wrote: On Tue, 21 Apr 2009 18:40:30 -0400, Chris Adams cmad...@hiwaay.net wrote: SSL and FTP are techincal justifications for an IP per site. No they aren't. SSL will work just fine as a name-based virtual host with any modern webserver / browser. (Server Name Indication (SNI) [RFC3546, sec 3.1]) I encourage my competitors to do this. You only have to get one noisy curmudgeon who can't get to your customer's SSL website because IE 5.0 has worked fine for them for years to make it a completely losing strategy to try deploying this everywhere. Since you can't predict in advance which sites are going to be accessed by said noisy curmudgeon, you don't bother deploying it anywhere, to be on the safe side. The switch to HTTP requests include a hostname had the same problem, but still did occur; it may take a few years, but doable. Probably too late to save IPv4 addresses; though. By then (I really, really, hope) IPv6 will be mainstream. -- Lionel
Re: Config Backup / Inventory
On Apr 24, 2009, at 4:25 AM, Joshua Eyres wrote: Hi, I am looking for a bit of advice around configuration backup / inventory. We currently have a large multi-vendor network which is currently managed through two separate tools (rancid - http://www.shrubbery.net/rancid and ns4 - http://www.noodles.org.uk/ns4.html). Both tools do the job very well, but management have asked that we look for commercial alternatives that have a proper support organisation looking after them. Yay for management... IP Service Activator has been mentioned as something which can fit this role, but I haven't had any experience and I haven't heard a lot of good things about it. We are looking for a tool which is flexible that allows configuration backup to textual form for easy restoration as well as the ability to deploy scripted changes to the network quickly. Do people generally use free tools for network management or are there viable commercial alternatives? A large large number of people use things like RANCID and / or some homegrown things... The people who are using commercial products (for the above role) are usually doing so because they were saddled with these requirements by management and / or are a windows shop.. As you say, RANCID is working well, maybe if you explain the costs involved in installing / migrating to and supporting a commercial product your management will see things saner? W Thanks, Josh smime.p7s Description: S/MIME cryptographic signature
BGP Update Report
BGP Update Report Interval: 23-Mar-09 -to- 23-Apr-09 (32 days) Observation Point: BGP Peering with AS131072 TOP 20 Unstable Origin AS Rank ASNUpds % Upds/PfxAS-Name 1 - AS6389 347165 4.2% 79.4 -- BELLSOUTH-NET-BLK - BellSouth.net Inc. 2 - AS238697456 1.2% 75.6 -- INS-AS - ATT Data Communications Services 3 - AS845288023 1.1% 61.4 -- TEDATA TEDATA 4 - AS647874893 0.9% 54.0 -- ATT-INTERNET3 - ATT WorldNet Services 5 - AS29049 72202 0.9% 222.8 -- DELTA-TELECOM-AS Delta Telecom LTD. 6 - AS17488 71849 0.9% 46.1 -- HATHWAY-NET-AP Hathway IP Over Cable Internet 7 - AS11492 60689 0.7% 49.4 -- CABLEONE - CABLE ONE, INC. 8 - AS701853533 0.7% 35.3 -- ATT-INTERNET4 - ATT WorldNet Services 9 - AS12978 53255 0.7% 294.2 -- DOGAN-ONLINE Dogan Iletisim Elektronik Servis Hizmetleri AS 10 - AS19262 51431 0.6% 52.2 -- VZGNI-TRANSIT - Verizon Internet Services Inc. 11 - AS313051157 0.6% 198.3 -- RGNET-3130 RGnet/PSGnet 12 - AS432351029 0.6% 11.8 -- TWTC - tw telecom holdings, inc. 13 - AS10796 48612 0.6% 83.7 -- SCRR-10796 - Road Runner HoldCo LLC 14 - AS982946946 0.6% 71.2 -- BSNL-NIB National Internet Backbone 15 - AS35805 46767 0.6% 144.8 -- UTG-AS United Telecom AS 16 - AS475546138 0.6% 37.0 -- TATACOMM-AS TATA Communications formerly VSNL is Leading ISP 17 - AS20115 42268 0.5% 25.3 -- CHARTER-NET-HKY-NC - Charter Communications 18 - AS815141307 0.5% 27.6 -- Uninet S.A. de C.V. 19 - AS949841056 0.5% 55.1 -- BBIL-AP BHARTI Airtel Ltd. 20 - AS764334446 0.4% 31.2 -- VNN-AS-AP Vietnam Posts and Telecommunications (VNPT) TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASNUpds % Upds/PfxAS-Name 1 - AS7717 7985 0.1%7985.0 -- OPENIXP-AS-ID-AP OpenIXP ASN 2 - AS46653 17208 0.2%5736.0 -- FREDRIKSON---BYRON - Fredrikson Byron, P.A. 3 - AS15045 11268 0.1%3756.0 -- KITTELSON - KITTELSON AND ASSOCIATES, INC. 4 - AS142236661 0.1%3330.5 -- NYSDOH - New York State Department of Health 5 - AS32398 18185 0.2%3030.8 -- REALNET-ASN-1 6 - AS304234072 0.1%2036.0 -- AMEDI-3-ASN1 - Amedisys, Inc. 7 - AS46328 16488 0.2%1832.0 -- PTCNEBRASKA - PIERCE TELEPHONE COMPANY, INCORPORATED 8 - AS505024819 0.3%1772.8 -- PSC-EXT - Pittsburgh Supercomputing Center 9 - AS476405116 0.1%1705.3 -- TRICOMPAS Tricomp Sp. z. o. o. 10 - AS409671521 0.0%1521.0 -- CSF-AS CSF Computersoftware fuer Fachanwendungen GmbH 11 - AS9796 3838 0.1%1279.3 -- WIPRO Internet Service Providers 12 - AS282561275 0.0%1275.0 -- 13 - AS343212295 0.0%1147.5 -- LDK-AS Institute of strategic marks, Kiev, Ukraine 14 - AS21491 32496 0.4%1048.3 -- UTL-ON-LINE UTL On-line is RF broadband ISP in Uganda - Africa 15 - AS190171016 0.0%1016.0 -- QUALCOMM-QWBS-LV - Qualcomm, Inc. 16 - AS193981941 0.0% 970.5 -- INDENET - Indenet.net 17 - AS40344 946 0.0% 946.0 -- PROSK-1 - Pro Sky Wireless 18 - AS34996 874 0.0% 874.0 -- ANADOLUSIGORTA-AS Anadolu Sigorta AS 19 - AS17975 10440 0.1% 870.0 -- APT-AP AS# for peering purpose with IX and ISP. 20 - AS569110633 0.1% 817.9 -- MITRE-AS-5 - The MITRE Corporation TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 72.23.246.0/2424718 0.3% AS5050 -- PSC-EXT - Pittsburgh Supercomputing Center 2 - 41.204.2.0/24 17903 0.2% AS32398 -- REALNET-ASN-1 3 - 199.45.13.0/2417186 0.2% AS46653 -- FREDRIKSON---BYRON - Fredrikson Byron, P.A. 4 - 192.35.129.0/24 10828 0.1% AS6629 -- NOAA-AS - NOAA 5 - 222.255.51.64/26 10760 0.1% AS7643 -- VNN-AS-AP Vietnam Posts and Telecommunications (VNPT) 6 - 198.77.177.0/24 10723 0.1% AS6629 -- NOAA-AS - NOAA 7 - 192.102.88.0/24 10685 0.1% AS6629 -- NOAA-AS - NOAA 8 - 192.12.120.0/24 10508 0.1% AS5691 -- MITRE-AS-5 - The MITRE Corporation 9 - 121.101.184.0/24 8030 0.1% AS38785 -- BAGUSNET-AS-ID PT. BORNEO BROADBAND TECHNOLOGY AS7717 -- OPENIXP-AS-ID-AP OpenIXP ASN 10 - 192.135.176.0/24 6651 0.1% AS14223 -- NYSDOH - New York State Department of Health 11 - 202.92.235.0/246465 0.1% AS9498 -- BBIL-AP BHARTI Airtel Ltd. 12 - 195.96.69.0/24 6005 0.1% AS8225 -- ASTELIT-MSK-AS Astelit Autonomous System 13 - 193.201.184.0/21 5640 0.1% AS25546 -- BROOKLANDCOMP-AS Brookland Computer Services 14 - 94.124.16.0/21 5033
The Cidr Report
This report has been generated at Fri Apr 24 21:13:59 2009 AEST.
The report analyses the BGP Routing Table of AS2.0 router
and generates a report on aggregation potential within the table.
Check http://www.cidr-report.org for a current version of this report.
Recent Table History
Date PrefixesCIDR Agg
17-04-09292288 183122
18-04-09292580 182677
19-04-09292736 182860
20-04-09292576 183243
21-04-09292958 182956
22-04-09292769 182911
23-04-09292923 183618
24-04-09293508 183392
AS Summary
31191 Number of ASes in routing system
13247 Number of ASes announcing only one prefix
4313 Largest number of prefixes announced by an AS
AS6389 : BELLSOUTH-NET-BLK - BellSouth.net Inc.
89678848 Largest address span announced by an AS (/32s)
AS27064: DDN-ASNBLK1 - DoD Network Information Center
Aggregation Summary
The algorithm used in this report proposes aggregation only
when there is a precise match using the AS path, so as
to preserve traffic transit policies. Aggregation is also
proposed across non-advertised address space ('holes').
--- 24Apr09 ---
ASnumNetsNow NetsAggr NetGain % Gain Description
Table 293332 183149 11018337.6% All ASes
AS6389 4313 361 395291.6% BELLSOUTH-NET-BLK -
BellSouth.net Inc.
AS4323 4272 1717 255559.8% TWTC - tw telecom holdings,
inc.
AS209 2649 1161 148856.2% ASN-QWEST - Qwest
Communications Corporation
AS4766 1802 520 128271.1% KIXS-AS-KR Korea Telecom
AS17488 1553 301 125280.6% HATHWAY-NET-AP Hathway IP Over
Cable Internet
AS22773 1049 66 98393.7% ASN-CXA-ALL-CCI-22773-RDC -
Cox Communications Inc.
AS4755 1229 274 95577.7% TATACOMM-AS TATA
Communications formerly VSNL
is Leading ISP
AS8452 1248 326 92273.9% TEDATA TEDATA
AS8151 1450 580 87060.0% Uninet S.A. de C.V.
AS1785 1753 911 84248.0% AS-PAETEC-NET - PaeTec
Communications, Inc.
AS19262 982 238 74475.8% VZGNI-TRANSIT - Verizon
Internet Services Inc.
AS18566 1059 419 64060.4% COVAD - Covad Communications
Co.
AS18101 756 150 60680.2% RIL-IDC Reliance Infocom Ltd
Internet Data Centre,
AS6478 1368 785 58342.6% ATT-INTERNET3 - ATT WorldNet
Services
AS11492 1163 607 55647.8% CABLEONE - CABLE ONE, INC.
AS855627 97 53084.5% CANET-ASN-4 - Bell Aliant
Regional Communications, Inc.
AS22047 615 111 50482.0% VTR BANDA ANCHA S.A.
AS2706 543 41 50292.4% HKSUPER-HK-AP Pacific Internet
(Hong Kong) Limited
AS17908 611 115 49681.2% TCISL Tata Communications
AS7545 808 321 48760.3% TPG-INTERNET-AP TPG Internet
Pty Ltd
AS4134 896 413 48353.9% CHINANET-BACKBONE
No.31,Jin-rong Street
AS7018 1479 1016 46331.3% ATT-INTERNET4 - ATT WorldNet
Services
AS4808 615 164 45173.3% CHINA169-BJ CNCGROUP IP
network China169 Beijing
Province Network
AS4804 497 64 43387.1% MPX-AS Microplex PTY LTD
AS24560 682 251 43163.2% AIRTELBROADBAND-AS-AP Bharti
Airtel Ltd., Telemedia
Services
AS17676 562 138 42475.4% GIGAINFRA BB TECHNOLOGY Corp.
AS6517 678 267 41160.6% RELIANCEGLOBALCOM - Reliance
Globalcom Services, Inc
AS7011 958 551 40742.5% FRONTIER-AND-CITIZENS -
Frontier Communications of
America, Inc.
AS4668 688 282 406
Problems reaching tools.ietf.org?
Anyone seeing issues with reachability for tools.ietf.org in IPv6? v4 works fine for me, but oh, the timeouts. :( Tracing the route to tools.ietf.org (2001:1890:1112:1:214:22FF:FE1F:1E54) 1 bnet6-2.tunnel.tserv2.fmt.ipv6.he.net (2001:470:1F03:1031::1) 64 msec 64 msec 64 msec 2 1g-3-9.core1.fmt1.ipv6.he.net (2001:470:0:44::3) 76 msec 72 msec 76 msec 3 10gigabitethernet1-1.core1.pao1.he.net (2001:470:0:2E::2) 64 msec 64 msec 64 msec 4 10gigabitethernet2-4.core1.ash1.he.net (2001:470:0:35::2) 144 msec 140 msec 140 msec 5 ibr01-ve96.asbn01.occaid.net (2001:504:0:2:0:3:71:1) 140 msec 140 msec 140 msec 6 r1.flpnj.ipv6.att.net (2001:4830:E2:2B::2) 148 msec 148 msec 148 msec 7 2001:1890:61:9117::2 224 msec 228 msec 224 msec 8 2001:1890:61:9117::2 !H * *
Re: NAT64/NAT-PT update in IETF, was: Re: Important New Requirement for IPv4 Requests [reimpacting revenue]
On Apr 23, 2009, at 11:31 AM, Manish Karir wrote: Would there be interest in trying to organize a day long mini-nanog with the ietf in March 2010? The regular nanog mtg is scheduled for Feb 22 2010 so this would have to be an extra meeting. and would require all sorts of help and interest from the ietf to put together. Perhaps the NANOG SC can try to figure out if there is sufficient interest in this and what this should consist of? People probably know this, but just in case... If there is interest in organizing a joint meeting during an IETF, the person to contact with logistical concerns (getting a room or rooms, etc.) would be the IAD, Ray Pelletier, i...@ietf.org; I would also cc the IAOC, i...@ietf.org . To coordinate technical concerns, I would start with either the IETF Chair, Russ Housley, ch...@ietf.org, or the OPS area ADs, Dan Romascanu and Ron Bonica (see http://www.ietf.org/IESGmems.html ). Regards Marshall -manish --- * From: Iljitsch van Beijnum * Date: Thu Apr 23 10:37:12 2009 * List-archive: http://mailman.nanog.org/mailman/nanog * List-help: mailto:nanog-requ...@nanog.org?subject=help * List-id: North American Network Operators Group nanog.nanog.org * List-post: mailto:nanog@nanog.org * List-subscribe: http://mailman.nanog.org/mailman/listinfo/ nanog,mailto:nanog-requ...@nanog.org?subject=subscribe * List-unsubscribe: http://mailman.nanog.org/mailman/listinfo/nanog ,mailto:nanog-requ...@nanog.org?subject=unsubscribe On 23 apr 2009, at 14:17, Adrian Chadd wrote: Methinks its time a large cabal of network operators should represent at IETF and make their opinions heard as a collective group. That would be how change is brought about in a participative organisation, no? :) Why don't you start by simpling stating what you want to have happen? So far I've seen a number of messages complaining about the IETF (btw, if you like complaining about the IETF, go to the meetings, there is significant time set aside for that there) but not a single technical request, remark or observation. The IETF works by rough consensus. That means if people disagree, nothing much happens. That is annoying. But a lot of good work gets done when people agree, and a lot of the time good technical arguments help. Like I said, the IETF really wants input from operators. Why not start by giving some? Regards Marshall Eubanks CEO / AmericaFree.TV
Re: Problems reaching tools.ietf.org?
On 25/04/2009, at 12:45 AM, Jack Bates wrote: Anyone seeing issues with reachability for tools.ietf.org in IPv6? v4 works fine for me, but oh, the timeouts. :( Tracing the route to tools.ietf.org (2001:1890:1112:1:214:22FF:FE1F: 1E54) 1 bnet6-2.tunnel.tserv2.fmt.ipv6.he.net (2001:470:1F03:1031::1) 64 msec 64 msec 64 msec 2 1g-3-9.core1.fmt1.ipv6.he.net (2001:470:0:44::3) 76 msec 72 msec 76 msec 3 10gigabitethernet1-1.core1.pao1.he.net (2001:470:0:2E::2) 64 msec 64 msec 64 msec 4 10gigabitethernet2-4.core1.ash1.he.net (2001:470:0:35::2) 144 msec 140 msec 140 msec 5 ibr01-ve96.asbn01.occaid.net (2001:504:0:2:0:3:71:1) 140 msec 140 msec 140 msec 6 r1.flpnj.ipv6.att.net (2001:4830:E2:2B::2) 148 msec 148 msec 148 msec 7 2001:1890:61:9117::2 224 msec 228 msec 224 msec 8 2001:1890:61:9117::2 !H * * I'm betting you are on 6to4. 6to4 has never worked for me, reaching tools.ietf.org. -- Nathan Ward
Re: Problems reaching tools.ietf.org?
Finally hit the office and called someone at random. They are looking into it. I can reach www.ietf.org just fine which is in the same network, so this appears to be host specific. Be funny if the MAC address changed and SLAAC mismatched the host from the ; an annoying problem seen occasionally. Jack Jack Bates wrote: Anyone seeing issues with reachability for tools.ietf.org in IPv6? v4 works fine for me, but oh, the timeouts. :( Tracing the route to tools.ietf.org (2001:1890:1112:1:214:22FF:FE1F:1E54) 1 bnet6-2.tunnel.tserv2.fmt.ipv6.he.net (2001:470:1F03:1031::1) 64 msec 64 msec 64 msec 2 1g-3-9.core1.fmt1.ipv6.he.net (2001:470:0:44::3) 76 msec 72 msec 76 msec 3 10gigabitethernet1-1.core1.pao1.he.net (2001:470:0:2E::2) 64 msec 64 msec 64 msec 4 10gigabitethernet2-4.core1.ash1.he.net (2001:470:0:35::2) 144 msec 140 msec 140 msec 5 ibr01-ve96.asbn01.occaid.net (2001:504:0:2:0:3:71:1) 140 msec 140 msec 140 msec 6 r1.flpnj.ipv6.att.net (2001:4830:E2:2B::2) 148 msec 148 msec 148 msec 7 2001:1890:61:9117::2 224 msec 228 msec 224 msec 8 2001:1890:61:9117::2 !H * *
Re: Problems reaching tools.ietf.org?
On Apr 24, 2009, at 9:14 AM, Jack Bates wrote: Finally hit the office and called someone at random. They are looking into it. I can reach www.ietf.org just fine which is in the same network, so this appears to be host specific. Be funny if the MAC address changed and SLAAC mismatched the host from the ; an annoying problem seen occasionally. from http://www.ietf.org/secretariat.html : To report technical problems (e.g., problems related to servers, mailing lists, archives, web tools, etc.) or to offer suggestions: ietf-act...@ietf.org Regards Marshall Jack Jack Bates wrote: Anyone seeing issues with reachability for tools.ietf.org in IPv6? v4 works fine for me, but oh, the timeouts. :( Tracing the route to tools.ietf.org (2001:1890:1112:1:214:22FF:FE1F: 1E54) 1 bnet6-2.tunnel.tserv2.fmt.ipv6.he.net (2001:470:1F03:1031::1) 64 msec 64 msec 64 msec 2 1g-3-9.core1.fmt1.ipv6.he.net (2001:470:0:44::3) 76 msec 72 msec 76 msec 3 10gigabitethernet1-1.core1.pao1.he.net (2001:470:0:2E::2) 64 msec 64 msec 64 msec 4 10gigabitethernet2-4.core1.ash1.he.net (2001:470:0:35::2) 144 msec 140 msec 140 msec 5 ibr01-ve96.asbn01.occaid.net (2001:504:0:2:0:3:71:1) 140 msec 140 msec 140 msec 6 r1.flpnj.ipv6.att.net (2001:4830:E2:2B::2) 148 msec 148 msec 148 msec 7 2001:1890:61:9117::2 224 msec 228 msec 224 msec 8 2001:1890:61:9117::2 !H * * Regards Marshall Eubanks CEO / AmericaFree.TV
Re: Config Backup / Inventory
Check out HyperConf http://www.winagents.com/en/products/hyperconf/ It does multi-vendor device backups as well as a scripting function to blow out mass changes to devices. They are also pretty easy to work with to enable new devices if you want them. The licensing is somewhat reasonable. Jon Wolberg Operations Manager PowerVPS / Defender Hosting Defender Technologies Group, LLC. - Original Message - From: Joshua Eyres joshua.ey...@gmail.com To: nanog@nanog.org Sent: Friday, April 24, 2009 4:25:05 AM GMT -05:00 US/Canada Eastern Subject: Config Backup / Inventory Hi, I am looking for a bit of advice around configuration backup / inventory. We currently have a large multi-vendor network which is currently managed through two separate tools (rancid - http://www.shrubbery.net/rancid and ns4 - http://www.noodles.org.uk/ns4.html). Both tools do the job very well, but management have asked that we look for commercial alternatives that have a proper support organisation looking after them. IP Service Activator has been mentioned as something which can fit this role, but I haven't had any experience and I haven't heard a lot of good things about it. We are looking for a tool which is flexible that allows configuration backup to textual form for easy restoration as well as the ability to deploy scripted changes to the network quickly. Do people generally use free tools for network management or are there viable commercial alternatives? Thanks, Josh
RE: Broadband Subscriber Management
So what were you doing than, RFC 1483? Frank -Original Message- From: Curtis Maurand [mailto:cmaur...@xyonet.com] Sent: Friday, April 24, 2009 7:16 AM To: Frank Bulk Cc: 'William McCall'; nanog@nanog.org Subject: Re: Broadband Subscriber Management Way back when Verizon first started rolling out DSL, we at a small ISP looked to wholesale ports from them via a deal they were offering. The were simply delivering PVC's to us via ATM on a DS3. 1 for each customer. They were doing the rate limiting based on what we ordered. I was able to use a lucent DSL aggregator for the handoff to our network. PPPoE wasn't necessary. --Curtis Frank Bulk wrote: I wasn't aware that LECs have the money to provide a DSLAM port per pair. =) PPPoA/E wasn't invented to prevent DSL sharing (not possible), but was the result of extending the dial-up approach of PPP with usernames and passwords to provide end-users IP connectivity. As Arie mentions in his posting, the separation of physical link termination and session termination, done in the dial-up world at the time, lent to setting up DSL in the same manner. You don't have to read too many commentaries on IRB RFC 1483 to recognize that that approach is all that great, either. Frank -Original Message- From: William McCall [mailto:william.mcc...@gmail.com] Sent: Thursday, April 23, 2009 7:24 AM To: nanog@nanog.org Subject: Re: Broadband Subscriber Management My understanding of the PPPoA/E deal is that SPs (originally) wanted to prevent some yahoo with a DSL modem from just being able to hook in to someone's existing DSL connection and using it, so they decided to implemement PPPoA and require some sort of authentication to prevent this scenario. snip
Re: Important New Requirement for IPv4 Requests
Date: Fri, 24 Apr 2009 19:05:26 +1200 From: Perry Lorier pe...@coders.net Large data sets? So you are saying that 512-byte packets with no windowing work better? Bill, have you measured this? Time to download a 100mb file over HTTP and a 100mb interface: 20 seconds. Time to download a 100mb file over FTP and a 100mb interface: ~7 minutes. And yes, that was FreeBSD with the old version openssl library that shipped with 6.3. As someone who copies large network trace files around a bit, 100MB at 100mb, over what I presume is a local (low latency) link is barely a fair test. Many popular web servers choke on serving files 2GB or 4GB in size (Sigh). I'm in New Zealand. It's usually at least 150ms to anywhere, often 300ms, so I feel the pain of small window sizes in popular encryption programs very strongly. Transferring data over high speed research networks means receive windows of at least 2MB, usually more. When popular programs provide their own window of 64kB, things get very slow. Very few people (including some on this list) have much idea of the difficulty in moving large volumes of data between continents, especially between the Pacific (China, NZ, Australia, Japan, ...) and either Europe or North America. Getting TCP bandwidth over about 1Gbps is very difficult. Getting over 5G is nearly impossible. I can get 5Gbps pretty reliably with tuned end systems over a 100 ms. RTT, but that drops to about 2G at 200 ms. A good web site to read a bout getting fast bulk data transfers is: http://fasterdata.es.net It is aimed at DOE and DOE related researchers, but the information is valid for anyone needing to move data on a Terabyte or greater scale over long distances. We move a LOT of data between our facilities at FermiLab in Chicago and Brookhaven in New York and CERN in Europe. A Terabyte is just the opener for that data. Also, if you see anything that needs improvement or correction, please let me know. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: ober...@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751
Re: Config Backup / Inventory
Sounds like rancid par to me. :-) Par?
Re: integrated KVMoIP and serial console terminal server
I haven't really found a combo unit I like as yet. For KVM, I like the Raritan products. For Serial, I prefer the Avocent line. Owen On Apr 23, 2009, at 3:17 PM, Joe Abley wrote: Hi all, What is everybody's favourite combination rack-mount VGA/USB KVM- over-IP and serial console concentrator in 2009? I'm looking for something that will accommodate 8 or so 9600bps serial devices and about 12 VGA/USB devices, all reachable over IP via sane means (ssh, https, etc). Being able to trunk everything through cat5E/RJ45 plant is not necessary; in this application everything is in the same cabinet. Avocent seem to make a likely-looking box, but (a) it's a bit insanely expensive, and (b) the adapters that you connect using RJ45 to the avocent and via RS232 to the serial devices *each seem to require a power supply* which frankly makes me recoil in horror. Perhaps I mis-read the glossy web page. Advice would be appreciated; direct mail is fine; I can summarise back to the list if there is interest in me doing so. Joe smime.p7s Description: S/MIME cryptographic signature
Re: IXP
We got to go through all the badness that was the ATM NAPs (AADS, PacBell NAP, MAE-WEST ATM). I think exactly for the reason Leo mentions they failed. That is, it didn't even require people to figure out all the technical reasons they were bad (many), they were fundamentally doomed due to increasing the difficulty of peering which translated to an economic scaling problem. i.e. if you make it hard for people to peer then you end up with less peers and shared vlan exchanges based on things like ethernet outcompete you. Been there done that. We've already experienced the result of secure ID cards and the PeerMaker tool. It was like pulling teeth to get sessions setup, and most peers plus the exchange operator didn't believe in oversubscription (can you say CBR? I knew you could), so you end up with 2 year old bandwidth allocations cast in stone because it was such a pain to get the peer to set it up in the first place, and to increase bandwidth to you means your peer has to reduce the bandwidth they allocated to somebody else. I, too, had a SecureID card, whose PIN I promptly forgot. I actually feel sorry for the poor software developers of that system; who knows what requirements were imposed on them by management fiat versus researched from the customer (and potential customer) base? Ethernet != shared VLAN, as I'm sure you know, so equating the two is non-sequitur. Ethernet has grown enough features that it can be used effectively in a variety of ways - and knowing which features to avoid is just as important as knowing which features to expose. Not every knob that can be turned, should be turned. The challenge to a developer of the software infrastructure of a modern IXP is to take what we learned about the ease of use of shared VLAN peering and translate it into the world of pseudo-wire interconnect. Does it have to be as hard as PeerMaker? Clearly not. If someone is going to jump into that space, though, there's a lot of homework to do to research what a provisioning system would need to do to present as little a barrier to peering as possible. Your argument, and Leo's, is fundamentally the complacency argument that I pointed out earlier. You're content with how things are, despite the failure modes, and despite inefficiencies that the IXP operator is forced to have in *their* business model because of your complacency.
Re: integrated KVMoIP and serial console terminal server
I have had good luck with Digi console managers for serial... I think they have some KVM functionality, but I don't know how well that works as I have only used the serial management. http://www.digi.com/products/consoleservers/ Regards, James Pleger e: jple...@gmail.com g: http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0x9D7141C9 On Apr 24, 2009, at 9:52 AM, Owen DeLong wrote: I haven't really found a combo unit I like as yet. For KVM, I like the Raritan products. For Serial, I prefer the Avocent line. Owen On Apr 23, 2009, at 3:17 PM, Joe Abley wrote: Hi all, What is everybody's favourite combination rack-mount VGA/USB KVM- over-IP and serial console concentrator in 2009? I'm looking for something that will accommodate 8 or so 9600bps serial devices and about 12 VGA/USB devices, all reachable over IP via sane means (ssh, https, etc). Being able to trunk everything through cat5E/RJ45 plant is not necessary; in this application everything is in the same cabinet. Avocent seem to make a likely-looking box, but (a) it's a bit insanely expensive, and (b) the adapters that you connect using RJ45 to the avocent and via RS232 to the serial devices *each seem to require a power supply* which frankly makes me recoil in horror. Perhaps I mis-read the glossy web page. Advice would be appreciated; direct mail is fine; I can summarise back to the list if there is interest in me doing so. Joe PGP.sig Description: This is a digitally signed message part
RE: integrated KVMoIP and serial console terminal server
We have just implemented Avocent console and power concentrators. Console servers are reachable via a highly customizable web interface. The Avocent software can also be virtualized on VMWare. Console connectivity can be provisioned to first try SSH via the IP network, and automatically failover to a dial-up modem connection if the network is down. For power both AC and DC power supplies are supported. With DC the battery plant main fuse panel connects to the device that is used to power cycle the electronic equipment using low amperage grasshopper fuses for each device. I believe that Avocent is the only vendor with DC power-cycle support. The serial cables for the device consoles do not require power supplies as indicated below. -Original Message- From: Owen DeLong [mailto:o...@delong.com] Sent: Friday, April 24, 2009 9:52 AM To: Joe Abley Cc: NANOG list Subject: Re: integrated KVMoIP and serial console terminal server I haven't really found a combo unit I like as yet. For KVM, I like the Raritan products. For Serial, I prefer the Avocent line. Owen On Apr 23, 2009, at 3:17 PM, Joe Abley wrote: Hi all, What is everybody's favourite combination rack-mount VGA/USB KVM- over-IP and serial console concentrator in 2009? I'm looking for something that will accommodate 8 or so 9600bps serial devices and about 12 VGA/USB devices, all reachable over IP via sane means (ssh, https, etc). Being able to trunk everything through cat5E/RJ45 plant is not necessary; in this application everything is in the same cabinet. Avocent seem to make a likely-looking box, but (a) it's a bit insanely expensive, and (b) the adapters that you connect using RJ45 to the avocent and via RS232 to the serial devices *each seem to require a power supply* which frankly makes me recoil in horror. Perhaps I mis-read the glossy web page. Advice would be appreciated; direct mail is fine; I can summarise back to the list if there is interest in me doing so. Joe
Re: integrated KVMoIP and serial console terminal server
Have you considered VM's for remote OS access to win devices and eliminating vga/kb requirements? If you are looking for console uptime and ease of use, avoid anything with moving parts (disk) and go with cisco. Consider the secondary market for the concentrator and cards to keep costs very low. Alternatively, I like MRV. Console will work fine over cat5, but if your cabinet is going to be 'busy' you should consider going shielded. Cisco asynch octo cables are shielded iirc, but I prefer in cabinet xcon for ease of use so if that's your technique too shield the xcon. You won't regret it. Best, Martin On 4/23/09, Joe Abley jab...@hopcount.ca wrote: Hi all, What is everybody's favourite combination rack-mount VGA/USB KVM-over- IP and serial console concentrator in 2009? I'm looking for something that will accommodate 8 or so 9600bps serial devices and about 12 VGA/USB devices, all reachable over IP via sane means (ssh, https, etc). Being able to trunk everything through cat5E/ RJ45 plant is not necessary; in this application everything is in the same cabinet. Avocent seem to make a likely-looking box, but (a) it's a bit insanely expensive, and (b) the adapters that you connect using RJ45 to the avocent and via RS232 to the serial devices *each seem to require a power supply* which frankly makes me recoil in horror. Perhaps I mis- read the glossy web page. Advice would be appreciated; direct mail is fine; I can summarise back to the list if there is interest in me doing so. Joe -- Martin Hannigan mar...@theicelandguy.com p: +16178216079 Power, Network, and Costs Consulting for Iceland Datacenters and Occupants
Weekly Routing Table Report
This is an automated weekly mailing describing the state of the Internet Routing Table as seen from APNIC's router in Japan. Daily listings are sent to bgp-st...@lists.apnic.net For historical data, please see http://thyme.apnic.net. If you have any comments please contact Philip Smith p...@cisco.com. Routing Table Report 04:00 +10GMT Sat 25 Apr, 2009 Report Website: http://thyme.apnic.net Detailed Analysis: http://thyme.apnic.net/current/ Analysis Summary BGP routing table entries examined: 286265 Prefixes after maximum aggregation: 135384 Deaggregation factor: 2.11 Unique aggregates announced to Internet: 141034 Total ASes present in the Internet Routing Table: 31102 Prefixes per ASN: 9.20 Origin-only ASes present in the Internet Routing Table: 27064 Origin ASes announcing only one prefix: 13174 Transit ASes present in the Internet Routing Table:4038 Transit-only ASes present in the Internet Routing Table: 94 Average AS path length visible in the Internet Routing Table: 3.6 Max AS path length visible: 33 Max AS path prepend of ASN (43683) 31 Prefixes from unregistered ASNs in the Routing Table: 456 Unregistered ASNs in the Routing Table: 152 Number of 32-bit ASNs allocated by the RIRs:141 Prefixes from 32-bit ASNs in the Routing Table: 25 Special use prefixes present in the Routing Table:0 Prefixes being announced from unallocated address space:208 Number of addresses announced to Internet: 2035527744 Equivalent to 121 /8s, 83 /16s and 176 /24s Percentage of available address space announced: 54.9 Percentage of allocated address space announced: 64.2 Percentage of available address space allocated: 85.5 Percentage of address space in use by end-sites: 76.5 Total number of prefixes smaller than registry allocations: 141104 APNIC Region Analysis Summary - Prefixes being announced by APNIC Region ASes:66477 Total APNIC prefixes after maximum aggregation: 23664 APNIC Deaggregation factor:2.81 Prefixes being announced from the APNIC address blocks: 63236 Unique aggregates announced from the APNIC address blocks:28895 APNIC Region origin ASes present in the Internet Routing Table:3607 APNIC Prefixes per ASN: 17.53 APNIC Region origin ASes announcing only one prefix:974 APNIC Region transit ASes present in the Internet Routing Table:548 Average APNIC Region AS path length visible:3.5 Max APNIC Region AS path length visible: 18 Number of APNIC addresses announced to Internet: 411598112 Equivalent to 24 /8s, 136 /16s and 125 /24s Percentage of available APNIC address space announced: 81.8 APNIC AS Blocks4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079 APNIC Address Blocks58/8, 59/8, 60/8, 61/8, 110/8, 111/8, 112/8, 113/8, 114/8, 115/8, 116/8, 117/8, 118/8, 119/8, 120/8, 121/8, 122/8, 123/8, 124/8, 125/8, 126/8, 202/8, 203/8, 210/8, 211/8, 218/8, 219/8, 220/8, 221/8, 222/8, ARIN Region Analysis Summary Prefixes being announced by ARIN Region ASes:124769 Total ARIN prefixes after maximum aggregation:65935 ARIN Deaggregation factor: 1.89 Prefixes being announced from the ARIN address blocks:93936 Unique aggregates announced from the ARIN address blocks: 36650 ARIN Region origin ASes present in the Internet Routing Table:12944 ARIN Prefixes per ASN: 7.26 ARIN Region origin ASes announcing only one prefix:4998 ARIN Region transit ASes present in the Internet Routing Table:1253 Average ARIN Region AS path length visible: 3.3 Max ARIN Region AS path length visible: 24 Number of ARIN addresses announced to Internet: 42736 Equivalent to 25 /8s, 120 /16s and 255 /24s Percentage of available ARIN address space announced: 82.2 ARIN AS Blocks 1-1876, 1902-2042, 2044-2046, 2048-2106 (pre-ERX allocations) 2138-2584, 2615-2772,
Re: integrated KVMoIP and serial console terminal server
Joe Abley jab...@hopcount.ca writes: What is everybody's favourite combination rack-mount VGA/USB KVM-over- IP and serial console concentrator in 2009? I'm looking for something that will accommodate 8 or so 9600bps serial devices and about 12 VGA/USB devices, all reachable over IP via sane means (ssh, https, etc). Being able to trunk everything through cat5E/ RJ45 plant is not necessary; in this application everything is in the same cabinet. I can't speak to the KVM over IP (for *NIX, they are obviously inferior to serial) but I do have some suggestions for the serial end. Personally, I use an opengear cm4148; it seems to work fairly well. If I only needed 8 ports, I'd still be using my solution from 2005, which was an 8 port rocketport serial card in a FreeBSD box. I only moved to the opengear because I need many more ports I like both the opengear and the freebsd box because I can use ssh auth, I can log, and I can lock down each user so that a given private key can only view a certain port.
Re: IXP
In a message written on Fri, Apr 24, 2009 at 05:06:15PM +, Stephen Stuart wrote: Your argument, and Leo's, is fundamentally the complacency argument that I pointed out earlier. You're content with how things are, despite the failure modes, and despite inefficiencies that the IXP operator is forced to have in *their* business model because of your complacency. I do not think that is my argument. I have looked at the failure modes and the cost of fixing them and decided that it is cheaper and easier to deal with the failure modes than it is to deal with the fix. Quite frankly, I think the failure modes have been grossly overblown. The number of incidents of shared network badness that have caused problems are actually few and far between. I can't attribute any down-time to shared-network badness at exchanges (note, colos are a different story) in a good 5-7 years. On the contrary, I can attribute downtime already to paranoia about it. When I had an ethernet interface fail at a colo provider to remain nameless I was forced to call the noc, have them put the port in a quarantine vlan, watch it with tcpdump for a hour, and then return it to service. Total additional downtime after the bad interface was replaced, 2 hours. I have no idea how watching an interface in a vlan with tcpdump supposedly protects a shared network. Remember the 7513's, where adding or removing a dot1q subinterface might bounce the entire trunk? I know of several providers to this day that won't add/remove subinterfaces during the day, but turning up BGP sessions on shared lans can be done all day long. The scheme proposed with private vlan's to every provider adds a significant amount of engineering time, documentation, and general effort to public peering. Public peering barely makes economic sense when its cost is as close to free as we can get it, virtually any increase makes it useless. We've already seen many major networks drop public peering all together because the internal time and effort to deal with small peers is not worth the benefit. Important volumes of traffic will be carried outside of a shared switch. The colo provider cannot provision a switching platform at a cost effective rate to handle all cross connects. So in the world of PNI's, the public switch, and shared segment already select for small players. You may want to peer with them because you think it's fair and good, you may do it to qualify up and comers for PNI's, but you're not /public peering/ for profit in 99% of the cases. All this is not to say private VLAN's aren't a service that could be offered. There may be a niche for particular size networks with particular sized flows to use them for good purposes. Colo providers should look at providing the service. A replacement for a shared, multi-access peering LAN? No. No. No. -- Leo Bicknell - bickn...@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ pgpS8b9Xu2m7v.pgp Description: PGP signature
RE: Config Backup / Inventory
Joe, If you're looking for a commercial solution, you might try out our Orion NCM product. http://www.solarwinds.com/products/orion/configuration_manager/ Ping me if you want any additional info. Josh -Original Message- From: Joe Provo [mailto:nanog-p...@rsuc.gweep.net] Sent: Friday, April 24, 2009 8:11 AM To: nanog@nanog.org Subject: Re: Config Backup / Inventory On Fri, Apr 24, 2009 at 09:25:05AM +0100, Joshua Eyres wrote: [snip] I am looking for a bit of advice around configuration backup / inventory. We currently have a large multi-vendor network which is currently managed through two separate tools (rancid - http://www.shrubbery.net/rancid and ns4 - http://www.noodles.org.uk/ns4.html). Both tools do the job very well, but management have asked that we look for commercial alternatives that have a proper support organisation looking after them. Since rtrmon waned and rancid waxed (97ish?), I've been a proponent and seen no support issues. Lots of commercial offerings (mostly vendor- specific) have changed or were from companies which folded between then and now. A non-trivial track record speaks volumes. [snip] things about it. We are looking for a tool which is flexible that allows configuration backup to textual form for easy restoration as well as the ability to deploy scripted changes to the network quickly. Sounds like rancid par to me. :-) Cheers, Joe -- RSUC / GweepNet / Spunk / FnB / Usenix / SAGE
Re: IXP
On 24/04/2009 18:46, Leo Bicknell wrote: I have looked at the failure modes and the cost of fixing them and decided that it is cheaper and easier to deal with the failure modes than it is to deal with the fix. Leo, your position is: worse is better. I happen to agree with this sentiment for a variety of reasons. Stephen Stuart disagrees - for a number of other carefully considered and well-thought-out reasons. Richard Gabriel's essay on worse is better as it applied to Lisp is worth reading in this context. The ideas he presents are relevant well beyond the article's intended scope and are applicable to the shared l2 domain vs PI interconnection argument (within reasonable bounds). Nick
RE: Config Backup / Inventory
CheckoutAlterpoint Network Authority Inventory. The Inventory tool is free asn was developed as the Ziptie opensource project. Inventory is the basis for how Alterpoint does the paid offerings for configurtion audit and compliance and the higher level analytics based on the configuration and inventory repository that NA Inventory provides. The Inventory component is free but be prepared for sticker shock for the whole Alterpoint suite of tools. There is also ManageEngine DeviceExpert (not free, but inexpensive) and Solarwinds Orion NCM (fromerly Cirrus configuration management, also inexpensive) Sam Crooks GTS Network Architecture 701 Experian Pkwy B5302 Allen, TX 75013 972-390-3186 sam.cro...@experian.com -Original Message- From: Joe Provo [mailto:nanog-p...@rsuc.gweep.net] Sent: Friday, April 24, 2009 8:11 AM To: nanog@nanog.org Subject: Re: Config Backup / Inventory On Fri, Apr 24, 2009 at 09:25:05AM +0100, Joshua Eyres wrote: [snip] I am looking for a bit of advice around configuration backup / inventory. We currently have a large multi-vendor network which is currently managed through two separate tools (rancid - http://www.shrubbery.net/rancid and ns4 - http://www.noodles.org.uk/ns4.html). Both tools do the job very well, but management have asked that we look for commercial alternatives that have a proper support organisation looking after them. Since rtrmon waned and rancid waxed (97ish?), I've been a proponent and seen no support issues. Lots of commercial offerings (mostly vendor- specific) have changed or were from companies which folded between then and now. A non-trivial track record speaks volumes. [snip] things about it. We are looking for a tool which is flexible that allows configuration backup to textual form for easy restoration as well as the ability to deploy scripted changes to the network quickly. Sounds like rancid par to me. :-) Cheers, Joe -- RSUC / GweepNet / Spunk / FnB / Usenix / SAGE
RE: Important New Requirement for IPv4 Requests
Of course, sftp and other ssh-based protocols are *still* hamstrung to a maximum of 32k data outstanding due to hardcoded SSH channel window sizes by default for most people, unless you're patching up both your clients and servers. Sadly, this blows ssh out of the water for anything with even modest high-bitrate requirements over moderate-BDP links. - S -Original Message- From: Jo Rhett jrh...@netconsonance.com Sent: Thursday, April 23, 2009 23:27 To: Joe Greco jgr...@ns.sol.net Cc: bmann...@vacation.karoshi.com bmann...@vacation.karoshi.com; nanog@nanog.org nanog@nanog.org Subject: Re: Important New Requirement for IPv4 Requests On Apr 22, 2009, at 7:42 AM, Joe Greco wrote: While HTTP remains popular as a way to interact with humans, especially if you want to try to do redirects, acknowledge license agreements, etc., FTP is the file transfer protocol of choice for basic file transfer Speak for yourself. I haven't used FTP to transfer files in 10 years now. About 7 years ago I turned off FTP support for all of our webhosting clients, and forced them to use SFTP. 3 left, for a net loss of $45/month. And we stopped having to deal with the massive undertaking that supporting FTP properly chrooted and capable of dealing with all parts of the multi-mount web platform required. We've never looked back. Ever once in a while I find someone who's offering a file I want only via FTP, and I chide them and they fix it ;-) -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness
Re: Important New Requirement for IPv4 Requests
From: Skywing skyw...@valhallalegends.com Date: Fri, 24 Apr 2009 10:55:07 -0500 Of course, sftp and other ssh-based protocols are *still* hamstrung to a maximum of 32k data outstanding due to hardcoded SSH channel window sizes by default for most people, unless you're patching up both your clients and servers. Sadly, this blows ssh out of the water for anything with even modest high-bitrate requirements over moderate-BDP links. The HPN patches for OpenSSH are readily available and, at least on FreeBSD, including them is just a single checkbox when you install. That said, I have been told that there is a corner case where a transfer using the HPN patches will lock up. I have never seen it, but that is purported to be the reason that OpenBSD has not accepted the patches for the base OpenSSH software. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: ober...@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751
Re: IXP
On Fri, Apr 24, 2009 at 12:46 PM, Leo Bicknell bickn...@ufp.org wrote: Quite frankly, I think the failure modes have been grossly overblown. The number of incidents of shared network badness that have caused problems are actually few and far between. I can't attribute any down-time to shared-network badness at exchanges (note, colos are a different story) in a good 5-7 years. Wait aren't you on NYIIX and Any2? Those two alone are good for 5-7 times a year like clockwork. Please allow me to send you a complementary copy of The Twelve Days of NYIIX for your caroling collection this December: On the first day of Christmas, NYIIX gave to me, A BPDU from someone's spanning tree. On the second day of Christmas, NYIIX gave to me, Two forwarding loops, And a BPDU from someone's spanning tree. On the third day of Christmas, NYIIX gave to me, Three routing leaks, Two forwarding loops, And a BPDU from someone's spanning tree. On the fourth day of Christmas, NYIIX gave to me, Four Foundry crashes, Three routing leaks, Two forwarding loops, And a BPDU from someone's spanning tree. On the fifth day of Christmas, NYIIX gave to me, Five flapping sessions, Four Foundry crashes, Three routing leaks, Two forwarding loops, And a BPDU from someone's spanning tree. On the sixth day of Christmas, NYIIX gave to me, Six maintenances notices, Five flapping sessions, Four Foundry crashes, Three routing leaks, Two forwarding loops, And a BPDU from someone's spanning tree. On the seventh day of Christmas, NYIIX gave to me, Seven broadcast floods, Six maintenances notices, Five flapping sessions, Four Foundry crashes, Three routing leaks, Two forwarding loops, And a BPDU from someone's spanning tree. On the eighth day of Christmas, NYIIX gave to me, Eight defaulting peers, Seven broadcast floods, Six maintenances notices, Five flapping sessions, Four Foundry crashes, Three routing leaks, Two forwarding loops, And a BPDU from someone's spanning tree. On the ninth day of Christmas, NYIIX gave to me, Nine CDP neighbors, Eight defaulting peers, Seven broadcast floods, Six maintenances notices, Five flapping sessions, Four Foundry crashes, Three routing leaks, Two forwarding loops, And a BPDU from someone's spanning tree. On the tenth day of Christmas, NYIIX gave to me, Ten proxy ARPs, Nine CDP neighbors, Eight defaulting peers, Seven broadcast floods, Six maintenances notices, Five flapping sessions, Four Foundry crashes, Three routing leaks, Two forwarding loops, And a BPDU from someone's spanning tree. On the eleventh day of Christmas, NYIIX gave to me, Eleven OSPF hellos, Ten proxy ARPs, Nine CDP neighbors, Eight defaulting peers, Seven broadcast floods, Six maintenances notices, Five flapping sessions, Four Foundry crashes, Three routing leaks, Two forwarding loops, And a BPDU from someone's spanning tree. On the twelfth day of Christmas, NYIIX gave to me, Twelve peers in half-duplex, Eleven OSPF hellos, Ten proxy ARPs, Nine CDP neighbors, Eight defaulting peers, Seven broadcast floods, Six maintenances notices, Five flapping sessions, Four Foundry crashes, Three routing leaks, Two forwarding loops, And a BPDU from someone's spanning tree.
RE: integrated KVMoIP and serial console terminal server
The OpenGear (based on their online demo) has much better configuration GUI than the WTI, hands down. Every time I make a change on the WTI, it has to reboot itself. =( Frank -Original Message- From: Luke S Crawford [mailto:l...@prgmr.com] Sent: Friday, April 24, 2009 1:33 PM To: Joe Abley Cc: NANOG list Subject: Re: integrated KVMoIP and serial console terminal server Joe Abley jab...@hopcount.ca writes: What is everybody's favourite combination rack-mount VGA/USB KVM-over- IP and serial console concentrator in 2009? I'm looking for something that will accommodate 8 or so 9600bps serial devices and about 12 VGA/USB devices, all reachable over IP via sane means (ssh, https, etc). Being able to trunk everything through cat5E/ RJ45 plant is not necessary; in this application everything is in the same cabinet. I can't speak to the KVM over IP (for *NIX, they are obviously inferior to serial) but I do have some suggestions for the serial end. Personally, I use an opengear cm4148; it seems to work fairly well. If I only needed 8 ports, I'd still be using my solution from 2005, which was an 8 port rocketport serial card in a FreeBSD box. I only moved to the opengear because I need many more ports I like both the opengear and the freebsd box because I can use ssh auth, I can log, and I can lock down each user so that a given private key can only view a certain port.
Re: integrated KVMoIP and serial console terminal server
We just switched from using Avocent/Cyclades to using Raritan for our terminal servers, and I am happier with the Raritan. I have used Raritan IP KVM's in the past and been happy, and the IT folks seem to like their new one. I found the Raritan terminal server docs much more complete, it's support for direct access to serial ports via ssh much more complete, its support for remote authentication (TACACS+) better, it's console sharing features better, etc. etc. I was surprised how much better we liked it than the other products we've used. --D On Fri, Apr 24, 2009 at 11:33 AM, Luke S Crawford l...@prgmr.com wrote: Joe Abley jab...@hopcount.ca writes: What is everybody's favourite combination rack-mount VGA/USB KVM-over- IP and serial console concentrator in 2009? I'm looking for something that will accommodate 8 or so 9600bps serial devices and about 12 VGA/USB devices, all reachable over IP via sane means (ssh, https, etc). Being able to trunk everything through cat5E/ RJ45 plant is not necessary; in this application everything is in the same cabinet. I can't speak to the KVM over IP (for *NIX, they are obviously inferior to serial) but I do have some suggestions for the serial end. Personally, I use an opengear cm4148; it seems to work fairly well. If I only needed 8 ports, I'd still be using my solution from 2005, which was an 8 port rocketport serial card in a FreeBSD box. I only moved to the opengear because I need many more ports I like both the opengear and the freebsd box because I can use ssh auth, I can log, and I can lock down each user so that a given private key can only view a certain port. -- -- Darren Bolding -- -- dar...@bolding.org --
Re: IXP
In a message written on Fri, Apr 24, 2009 at 04:22:49PM -0500, Paul Wall wrote: On the twelfth day of Christmas, NYIIX gave to me, Twelve peers in half-duplex, Eleven OSPF hellos, Ten proxy ARPs, Nine CDP neighbors, Eight defaulting peers, Seven broadcast floods, Six maintenances notices, Five flapping sessions, Four Foundry crashes, Three routing leaks, Two forwarding loops, And a BPDU from someone's spanning tree. Let's group: Problems that can/will occur with per-vlan peering: Twelve peers in half-duplex, Six maintenances notices, Five flapping sessions, Four Foundry crashes, Three routing leaks, Two forwarding loops, Problems that if they affect your equipment, you're configuring it wrong, and can/will occur with per-vlan peering: Eleven OSPF hellos, Nine CDP neighbors, Problems that if they affect the exchange, the exchange is configuring their equipment wrong, and can/will ocurr with per-vlan peering: Two forwarding loops, And a BPDU from someone's spanning tree. Problems unique to a shared layer 2 network: Eight defaulting peers, Seven broadcast floods, Leaving aside the particular exchanges, I'm going to guess you are not impressed by the technical tallent operating the exchange switches from the tone of your message. Do you believe making the configuration for the exchange operation 100 times more complex will: A) Lead to more mistakes and down time. B) Lead to less mistakes and down time. C) Have no effect? I'm going with A. I also think the downtime from A, will be an order of magnitude more down time than the result of defaulting peers (which, generally results in no down time, just theft of service), or broadcast floods. -- Leo Bicknell - bickn...@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ pgpVGi4gGru4u.pgp Description: PGP signature
RE: Important New Requirement for IPv4 Requests
Keep in mind that you also need to patch your clients for perf improvements bidirectionally. As well as patching locally means you must assume responsibility for custom builds for security fixes on all of your clients and servers. - S -Original Message- From: Kevin Oberman ober...@es.net Sent: Friday, April 24, 2009 13:39 To: Skywing skyw...@valhallalegends.com Cc: Jo Rhett jrh...@netconsonance.com; Joe Greco jgr...@ns.sol.net; bmann...@vacation.karoshi.com bmann...@vacation.karoshi.com; nanog@nanog.org nanog@nanog.org Subject: Re: Important New Requirement for IPv4 Requests From: Skywing skyw...@valhallalegends.com Date: Fri, 24 Apr 2009 10:55:07 -0500 Of course, sftp and other ssh-based protocols are *still* hamstrung to a maximum of 32k data outstanding due to hardcoded SSH channel window sizes by default for most people, unless you're patching up both your clients and servers. Sadly, this blows ssh out of the water for anything with even modest high-bitrate requirements over moderate-BDP links. The HPN patches for OpenSSH are readily available and, at least on FreeBSD, including them is just a single checkbox when you install. That said, I have been told that there is a corner case where a transfer using the HPN patches will lock up. I have never seen it, but that is purported to be the reason that OpenBSD has not accepted the patches for the base OpenSSH software. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: ober...@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751
Re: Important New Requirement for IPv4 Requests
A good web site to read a bout getting fast bulk data transfers is: http://fasterdata.es.net indeed mtu clue is also useful. here on tokyo b-flets, and i would guess in many other ppoe environments, you need to tune or lose big-time. randy
RE: Config Backup / Inventory
Kiwi CatTools works well for us-and it's inexpensive. I've been very happy with it. -- Tim -Original Message- From: Joshua Eyres [mailto:joshua.ey...@gmail.com] Sent: Friday, April 24, 2009 4:25 AM To: nanog@nanog.org Subject: Config Backup / Inventory Hi, I am looking for a bit of advice around configuration backup / inventory. We currently have a large multi-vendor network which is currently managed through two separate tools (rancid - http://www.shrubbery.net/rancid and ns4 - http://www.noodles.org.uk/ns4.html). Both tools do the job very well, but management have asked that we look for commercial alternatives that have a proper support organisation looking after them. IP Service Activator has been mentioned as something which can fit this role, but I haven't had any experience and I haven't heard a lot of good things about it. We are looking for a tool which is flexible that allows configuration backup to textual form for easy restoration as well as the ability to deploy scripted changes to the network quickly. Do people generally use free tools for network management or are there viable commercial alternatives? Thanks, Josh THIS MESSAGE IS INTENDED ONLY FOR PERSONAL AND CONFIDENTIAL USE OF THE INDIVIDUAL OR ENTITY TO WHOM IT IS ADDRESSED AND MAY CONTAIN INFORMATION THAT IS PRIVILEGED, CONFIDENTIAL, AND EXEMPT FROM DISCLOSURE UNDER APPLICABLE LAW. If the reader of this message is not the intended recipient, or the employee or agent responsible for delivering the message to the intended recipient, you are hereby notified that you have received this message in error and that any review, dissemination, distribution, or copying of this message is strictly prohibited. If you have received this message in error, please notify the sender immediately by e-mail or telephone, and delete the original message immediately. Thank you.
