Looking for power metering equipment...
Preamble: We run a colocation center. We sell power to customers. Question: We are looking for something that sits in the PDUs or branch circuit-breaker distribution load centers, that, on a branch-circuit by branch-circuit basis, can monitor amperage, and be queried by SNMP. Considering there are several hundreds of circuits to be monitored, cheap and featureless (all we need is amperage via SNMP) is fine. Looked at things like Square-D PowerLogin stuff, but thats very pricey, and does about 30x what we need. Pointers? URLs? Experiences? Thanks.
Re: /24s run amuck
Hi Sean, long time no spar. :) Going to Miami? I'll buy you a drink. -- TTFN, patrick On Jan 14, 2004, at 7:14 AM, Sean M.Doran wrote: Unfortunately there has been a macroeconomic cost to the growth of background noise in the Internet -- and the noise is still there -- which has made the Internet as a whole more expensive and less widely available than it ought to be. However, there are much larger contributions of such waste outside the public Internet's routing system that dwarf the cost of the unnecessary demands on router power resulting from poor aggregation, poor hygiene, and poor stabilization practices. Interestingly, the main reason I wanted to stop filtering on /18|/19|/20 filtering is precisely the thing you say is hurt by lack of filtering - availability. A small ISP who wants two upstreams but did not have the customers to support a /19 back in the day was forced to deal with partial connectivity from one of their upstreams. Today anyone can have robust connectivity, no matter how small their network, even if they are not an ISP. I believe this has helped the Internet, not hurt it. If everyone but major backbones were forced to be single homed, I doubt the 'Net would be where it is today. [Guess I should start reading my multi6 folder if I don't wanna go through this again in a few years, huh? :-] Almost everyone filters on /24s - they do not want to see /32s in the global table. Why not? I'm curious about why /24s are OK but /32s are not. Because that is where the Internet decided the break point should be - small enough to not upset people handing them out, but large enough to not have too many in the global table. If ISPs were handing out /26s to people who wanted to multi-home, that is where the break point would be. To be honest, I suspect it had more to do with inertia than a well-thought-out-plan. Lots of people had "Class Cs", so it just stuck. But the fact remains that anyone who wants to multi-home can get a /24, so the table only has to support /24s. I suggest that if there is no reason other than a watered down version of the voodoo mentality you've accused me personally of having with respect to long prefixes -- i.e., if you think I'm right about the problem but too aggressive about the limit -- that there is a business opportunity still waiting to be exploited by someone enterprising. Interesting way of putting it. Yes, I think some level of filtering needs to be done, and yes I think you were too aggressive. Neither of these are secrets to anyone who's been on the 'Net for a few years. But how we came to our decisions are very different. Is there a business opportunity? Maybe. Personally I think the time has past. The Internet is a commodity, trying to put on unneeded expenses or restricting access only loses you customers and therefore money. But I could be wrong, try setting up your idea and prove me wrong by getting rich off it. With respect to that, for my part I wish I could go back in time and complete the next phase of the filtering, viz. a web page which would accept a credit card number from anyone who wanted to have a particular prefix allowed through the access-list, for a small recurring fee. The problem with your idea is it requires collusion. The only way to get it to work is to guarantee that everyone does it, no one breaks ranks. Otherwise when you set up your web page, everyone else says "we'll do it for free", and then you're out of biz. :) -- TTFN, patrick
Re: IP Subnet Management?
On Wed, Jan 14, 2004 at 06:09:09PM -0800, bill is rumored to have said: > > on ftp.isi.edu/pub/bill/tree-2.1.5.tar.gz > is a nifty tool. for the record, it's tree-2.1.5.tar.Z handy - thanks for the link. > > --bill Steve -- "In any contest between power and patience, bet on patience." - W.B. Prescott
Re: PC Routers (was Re: /24s run amuck)
> I didn't say that I did it, but having a server with a backup OS image > in case your flash-drive fails isn't the worst thing in the world. > Especially for a remotely-adminstered POP. Possibly I misunderstood your words: There's no problem having backup image from network, but there's a problem doing network load as a rule (as you seemed to suggest for version control purposes). > > How many flash drives will fail due to overwrite in a year? 1 per 1000? > if even? Its an absurd solution for an even less likely problem. > > [EMAIL PROTECTED] wrote: > >>One problem is that with Cisco, unless you are buying the largest > >>platforms available, each Cisco series uses different underlying > >>hardware with different performance characteristics and images. You need > >>to keep track of lots of separate images and versions when doing > >>upgrades. With a network boot OS for each POP, you can do version > >>control much much more easily. > > > > In words of Randy, "I encourage all my competitors to network boot their > > routers". > > > > Seriously - that's insane, multiple single points of failure. > > > > -alex > > > > > > >
Re: PC Routers (was Re: /24s run amuck)
I didn't say that I did it, but having a server with a backup OS image in case your flash-drive fails isn't the worst thing in the world. Especially for a remotely-adminstered POP. How many flash drives will fail due to overwrite in a year? 1 per 1000? if even? Its an absurd solution for an even less likely problem. [EMAIL PROTECTED] wrote: One problem is that with Cisco, unless you are buying the largest platforms available, each Cisco series uses different underlying hardware with different performance characteristics and images. You need to keep track of lots of separate images and versions when doing upgrades. With a network boot OS for each POP, you can do version control much much more easily. In words of Randy, "I encourage all my competitors to network boot their routers". Seriously - that's insane, multiple single points of failure. -alex
Re: /24s run amuck
--On Wednesday, January 14, 2004 3:36 PM -0500 Daniel Golding <[EMAIL PROTECTED]> wrote: There is one mechanism for helping to solve this. Is there an RFC, informational or otherwise that clearly specifies that BGP announcements to peers and transit providers must be aggregated to the greatest extent possible? Just want to clarify that BGP announcements to peers should by default be aggregated as far as possible, but can be completely deaggregated if both parties agree. For example, if you have a BGP session with my employer and we haven't mentioned it recently, we would *love* deaggregation. Send us /32s, MEDs, communities and we'll chew it up and ask for more. But we're special - we don't have a network and we don't sell transit.
Re: PC Routers (was Re: /24s run amuck)
> I also think that it is extremely important to seperate "what you can do > with a redhat cd and a dream" from "what someone can do with PC hardware". Absolutely correct ;) > The bottom line is: You are only going to get so much performance when > you forward packets through a box which is processing an interrupt per > packet, doing a patricia tree lookup per packet, copying the packet in > memory a couple times, and doing some sequential comparisons through a > firewall ruleset on every packet. None of the above has anything to do > with PC hardware, but rather the poor software that people currently > making "PC routers" choose to run. > > If someone were to take *half* the software innovations which have been > made over the past 15 years (a decent fib, interrupt coalescing, > compiled packet matching rulesets, etc) and applied them as if they knew > something about networking and coding, they could very easily produce a > box using off the shelf PC hardware which woops up on a 7206vxr for > somewhere less than $2000. If there is one thing PC hardware is good at, > it is getting faster fast enough to keep up with the amount of bad code > people keep churning out. :) Of course, then they would probably need to > know a little bit more about routing protocols than just "how to compile > zebra", but assuming they did that too... They would be bought by Cisco. > :) You may find it interesting that both Linux and FreeBSD now have interrupt coalescing, and www.hipac.org is building a compiled ruleset. As far as broken-ness of linux rib/route lookup code: Yes, it is so very 1985, but there may be changes coming soon [Pilosoft may be sponsoring a rewrite]. > Anything else is either a cute playtoy for your house, or an endless > source of laughter for the people who know better as they watch you work > away at it. The vast majority of this discussion falls into the latter > category, but after a while even this gem of a subject turns from funny > to just plain sad. :) ...Until they get bought by Cisco? ;)
Re: PC Routers (was Re: /24s run amuck)
On Thu, Jan 15, 2004 at 04:34:00AM +0100, Mikael Abrahamsson wrote: > > On Wed, 14 Jan 2004, Stephen J. Wilcox wrote: > > > o) On a standard PCI but your limit is about 350Mb, you can increase that to a > > couple of Gb using 64-bit fancy thingies > > The limit is not megabit/s, it's packet per second (or rather, interrupts > per second). I-mix the average might be 350 megabit/s on a fairly good PC, > but going PCI-X wont help you much there. I also think that it is extremely important to seperate "what you can do with a redhat cd and a dream" from "what someone can do with PC hardware". The bottom line is: You are only going to get so much performance when you forward packets through a box which is processing an interrupt per packet, doing a patricia tree lookup per packet, copying the packet in memory a couple times, and doing some sequential comparisons through a firewall ruleset on every packet. None of the above has anything to do with PC hardware, but rather the poor software that people currently making "PC routers" choose to run. If someone were to take *half* the software innovations which have been made over the past 15 years (a decent fib, interrupt coalescing, compiled packet matching rulesets, etc) and applied them as if they knew something about networking and coding, they could very easily produce a box using off the shelf PC hardware which woops up on a 7206vxr for somewhere less than $2000. If there is one thing PC hardware is good at, it is getting faster fast enough to keep up with the amount of bad code people keep churning out. :) Of course, then they would probably need to know a little bit more about routing protocols than just "how to compile zebra", but assuming they did that too... They would be bought by Cisco. :) Anything else is either a cute playtoy for your house, or an endless source of laughter for the people who know better as they watch you work away at it. The vast majority of this discussion falls into the latter category, but after a while even this gem of a subject turns from funny to just plain sad. :) -- Richard A Steenbergen <[EMAIL PROTECTED]> http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)
Re: PC Routers (was Re: /24s run amuck)
On Wed, 14 Jan 2004, Stephen J. Wilcox wrote: > o) On a standard PCI but your limit is about 350Mb, you can increase that to a > couple of Gb using 64-bit fancy thingies The limit is not megabit/s, it's packet per second (or rather, interrupts per second). I-mix the average might be 350 megabit/s on a fairly good PC, but going PCI-X wont help you much there. -- Mikael Abrahamssonemail: [EMAIL PROTECTED]
Re: PC Routers (was Re: /24s run amuck)
He also said that Internet is growing by 1000% a year. In fact I think that it is an extremely bad idea to use clusters of enterprise boxes to build a global network. --vadim On Wed, 14 Jan 2004, Randy Bush wrote: > > > On the topic of PC routers, I've fully given in to the zen > > of Randy Bush. I FULLY encourage my competitor to use > > them. :) > > actually, i stole it from mike o'dell. > > he also said something on the order of "let's not bother to > discuss using home appliances to build a global network." > > randy
Re: PC Routers (was Re: /24s run amuck)
> On the topic of PC routers, I've fully given in to the zen > of Randy Bush. I FULLY encourage my competitor to use > them. :) actually, i stole it from mike o'dell. he also said something on the order of "let's not bother to discuss using home appliances to build a global network." randy
Re: PC Routers (was Re: /24s run amuck)
> One problem is that with Cisco, unless you are buying the largest > platforms available, each Cisco series uses different underlying > hardware with different performance characteristics and images. You need > to keep track of lots of separate images and versions when doing > upgrades. With a network boot OS for each POP, you can do version > control much much more easily. In words of Randy, "I encourage all my competitors to network boot their routers". Seriously - that's insane, multiple single points of failure. -alex
Re: PC Routers (was Re: /24s run amuck)
> > OSPF and ISIS, etc redistribution is a Zebra/etc function and I am told > it is pretty good at these functions. > > >multilink PPP? With spanning tree on multiple VLANs? With peer groups? > > Most of these are OS functions, but I believe they support peer groups > in the later editions of the software. We extensively and heavily utilize peer-groups all over at the edge of our IPv6 testbed network, which is mainly powered by Quagga (Some zebra), and a couple C's and J's. We absolutely had no problem running peer-groups with Quagga in both v6 and v4 as of date. Remember that Zebra/Quagga is not a _solution_. It is a userland component you build into an OS or a platform, to BUILD a solution. > > >With SNMP? > > OS function. Works. > > > > >How does the host deal with 802.1q trunks? With Channel interfaces? With > >hot-swapping a line card? With TCP MD5? > > Hotswapping is a chassis function. The rest are OS functions. > > > > >These are the questions I ask myself when I pick a routing platform. > >Cheap is of no use to me if it does not do what I need. > > Of course, but you may not need all of these functions on your > low-medium end, or you'll want to pick your alternate platform as > thoughtfully as you'd pick a large-capital item. > > Deepak Jain > AiNET -- James Jun (formerly Haesu) TowardEX Technologies, Inc. 1740 Massachusetts Ave. Boxborough, MA 01719 Consulting, IPv4 & IPv6 colocation, web hosting, network design & implementation http://www.towardex.com | [EMAIL PROTECTED] Cell: (978)394-2867 | Office: (978)263-3399 Ext. 170 Fax: (978)263-0033 | AIM: GigabitEthernet0 NOC: http://www.twdx.net | POC: HAESU-ARIN, HDJ1-6BONE
Re: PC Routers (was Re: /24s run amuck)
On Wed, Jan 14, 2004 at 08:06:50PM -0500, [EMAIL PROTECTED] wrote: > > > ... and we care because? the router is a black box. if the output is not > > what is expected, it matters not why. though understandable, it is still not > > acceptable. > > and you blame zebra ? There are so many many many legitimate things to blame Zebra for, and so many more legitimate things to blame Linux for, that when you put the two of them together there is no need to make up problems that aren't their fault. The reasons that PC routers bite have nothing to do with the fact that they use PC hardware, the limitations of the PCI bus, or any other nonsense like that. PC routers bite because of the software, pure and simple. Raw forwarding performance is only a small component of a quality router, the rest is SOFTWARE, SOFTWARE, and MORE SOFTWARE. Unfortunately, software quality isn't easy to measure in numbers other than units sold. On the topic of PC routers, I've fully given in to the zen of Randy Bush. I FULLY encourage my competitor to use them. :) -- Richard A Steenbergen <[EMAIL PROTECTED]> http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)
Re: PC Routers (was Re: /24s run amuck)
Not that I am pitching Zebra/Quagga/Gated/a brand of chewing gum/... The main issues I have with zebra are: 1. The need to install an OS on the host. 2. The need to harden it. These are also part of having access to more features. If you can use them. 3. The possible hard disk failure (having *nix on ATA flash is no better given the actual limits in the number of times one can write to flash). True, but you can also boot these (OS-wise) from the network (not just the config file), so you upgrade an entire network automagically -- or you can set them to boot from the network if the HD fails. There are things that I don't like with Cisco, but one thing I do like is that it boots from flash and it takes no time to install an image, remove the pcmcia card from the router, and boot different images from the flash with the flip of a config command. One problem is that with Cisco, unless you are buying the largest platforms available, each Cisco series uses different underlying hardware with different performance characteristics and images. You need to keep track of lots of separate images and versions when doing upgrades. With a network boot OS for each POP, you can do version control much much more easily. The concept of appliance (vs. computer) comes to mind. Yes, plenty of boxes can be made this way. I will let someone who knows more about this talk about it. That being said, How does zebra deal with QOS/priority/custom/queuing/LLQ? With CAR? With QOS, priority/custom queueing are all KERNEL/underlying OS functions. If you are using Linux you have an absurd number of options here. Likewise with CAR. You have many more options (depending on your knowledge of these underlying OSes) than you do with dedicated routing hardware. IDS? With route redistribution to/from OSPF or ISIS? With multichassis Likewise, while you can get limited IDS functions on some dedicated HW, you can do much more advanced IDS, etc on a Unix based platform. You can do it all on one box instead of needing multiple ones to get the best-of-breed set of features. OSPF and ISIS, etc redistribution is a Zebra/etc function and I am told it is pretty good at these functions. multilink PPP? With spanning tree on multiple VLANs? With peer groups? Most of these are OS functions, but I believe they support peer groups in the later editions of the software. With SNMP? OS function. Works. How does the host deal with 802.1q trunks? With Channel interfaces? With hot-swapping a line card? With TCP MD5? Hotswapping is a chassis function. The rest are OS functions. These are the questions I ask myself when I pick a routing platform. Cheap is of no use to me if it does not do what I need. Of course, but you may not need all of these functions on your low-medium end, or you'll want to pick your alternate platform as thoughtfully as you'd pick a large-capital item. Deepak Jain AiNET
RE: PC Routers (was Re: /24s run amuck)
> [EMAIL PROTECTED] wrote: > o) lack of unified tools to configure and manage: > Each of those tools has varied degrees of documentation, > different configuration interface, vastly different > 'status' interface, different support mailing lists, etc. > It is much easier for a given organization to find a > cisco/juniper/etc expert than to find someone who's > experienced with Linux/FreeBSD network toolchain, and I > don't foresee that changing anytime soon. You summarized it very well. > There are linux and freebsd distributions that aim to > minimize the "OS" layer to suit router better. Linux > also has a filesystem that spreads writes across the > flash area, so you are not likely to write single block > 10 times in your life. This is exactly where Cisco got their act together: they understand that what's above is exactly the kind of thing that many people are willing to pay more for in trade for not having to research the issue. In the end, time is money: each organization has a finite number of good techs; sometimes there is value in paying more for gear and have your senior techs available to deal with issues that are directly related to the business, instead of optimizing the OS filesystem so it does not wear out the flash. Michel.
Re: PC Routers (was Re: /24s run amuck)
On Wed, 14 Jan 2004 [EMAIL PROTECTED] wrote: > Getting to 1mpps on a single router today will probably be hard. However, > I've been considering implementing a "clustered router" architecture, > should scale pps more or less linearly based on number of "PCs" or > "routing nodes" involved. I'm not sure if discussion of that is on-topic > here, so maybe better to take it offline. This is exactly what Pluris PC-based proof-of-concept prototype did in 97. PCs were single-board 133MHz P-IIs, running custom forwarding code on bare metal, yielding about 120kpps per board, or 1.9Mpps per cage. In the production box CPU-based forwarding was replaced with ASICs, 1Gbps hybrid optical/electrical butterfly/hypercube interconnect was replaced with 12Gbps optical hypercube interconnect, otherwise architecture was unchanged. That was a total overkill which was one of the reasons the company went down. --vadim
RE: PC Routers (was Re: /24s run amuck)
> The main issues I have with zebra are: > 1. The need to install an OS on the host. > 2. The need to harden it. > 3. The possible hard disk failure (having *nix on ATA flash is no better > given the actual limits in the number of times one can write to flash). There are linux and freebsd distributions that aim to minimize the "OS" layer to suit router better. Linux also has a filesystem that spreads writes across the flash area, so you are not likely to write single block 10 times in your life. > > How does zebra deal with QOS/priority/custom/queuing/LLQ? With CAR? With > IDS? With route redistribution to/from OSPF or ISIS? With multichassis > multilink PPP? With spanning tree on multiple VLANs? With peer groups? > With SNMP? > > How does the host deal with 802.1q trunks? With Channel interfaces? With > hot-swapping a line card? With TCP MD5? > > These are the questions I ask myself when I pick a routing platform. > Cheap is of no use to me if it does not do what I need. The above are not Zebra issues: It is the host platform. For qos/priority/custom queueing/CAR, Linux has tc, and FreeBSD has ALTQ, which in my opinion, are at least as good as vendor C and vendor J equivalents. For everything else, I'll answer for Linux host platform, as that's what I'm most familiar with: IDS = snort, again, competive to proprietary solutions ISIS = beta status on quagga, not recommended. Route redistribution = yes multichassis ppp = no spanning tree = yes per-vlan-spanning-tree = yes dot1q = yes hotswap = *should* work, with PCI hot-plug, but you may have to make certain configuration changes manually post-swap TCP MD5 = yes in 2.6
Re: IP Subnet Management?
> > > Hey everyone, I've been trying to come up with an > algorithm to describe the assignment of IP subnets. > I have something in a proof of concept form that > will break a block of addresses into subnets at > a user's request. The thing is that the assignments > it makes are provably optimal. Within the limits > you may place on an assignment, there will never > be more than one empty subnet of any particular size. > I am curious as to what other things I should try > and put into this. Right now, if you request a /16 from > a /8, the /16 is considered assigned and further > changes within it are not possible. Would 'children' > so to speak be useful for you? What would your ideas > be? How have you tackled this problem? > Feel free to respond off list if you'd like :-) > > Appreciate your time! > > Mike (sick of spreadsheets) Wiacek > have you looked at/seen RFC 1878? on ftp.isi.edu/pub/bill/tree-2.1.5.tar.gz is a nifty tool. --bill
Re: PC Routers (was Re: /24s run amuck)
> Have been discussing PCs for a bit but as yet not deployed one, as I > understand it a *nix based PC running Zebra will work pretty fine but > has the constraints that: > > o) It has no features - not a problem for a lot of purposes > > This isnt necessarily a problem for what I have in mind It depends. Zebra/Quagga has lots of features, it just may be that these aren't the features you want. At many cases, you can get a developer to implement the features you need for half the cost of a proprietary router. I would add, more importantly for nanog audience: o) lack of unified tools to configure and manage: Your average PC router is configured at least by: * your distribution-based startup scripts * your routing protocol daemon (gated/zebra/etc) * linecard-specific tools (ethtool for linux) * protocol-specific tools (br2684 for rfc1483 encaps, for example) * eb/iptables to configure ACLs (or ipfw/ipf/pf) * tc to configure QoS (or ALTQ) Each of those tools has varied degrees of documentation, different configuration interface, vastly different 'status' interface, different support mailing lists, etc. It is much easier for a given organization to find a cisco/juniper/etc expert than to find someone who's experienced with Linux/FreeBSD network toolchain, and I don't foresee that changing anytime soon. > o) On a standard PCI but your limit is about 350Mb, you can increase > that to a couple of Gb using 64-bit fancy thingies > > For connecting to small IXPs, connecting customers, I dont need large > amounts of throughput. 64/66 PCI hasn't been fancy for last 3 years. On a single-processor P4/3ghz, I already can (and do:) route 400mbps of DoS-like traffic (one packet per flow, small packets, 400kpps). Of course, this is ridiculously low compared to current generation of high-end routers, however, it has its niche (and see below for possible scaling). > o) This may be fixed but I found it slow to update the kernel routing table > which isnt designed to take 12 routes being added at once > > Icky, could perhaps cause issues if theres a major reconvergence due to an > adjacent backbone router failing etc, might be okay tho Actually, considering the CPU on common desktop and CPU on a RE on common router (aka "you are reading this email on a machine with faster CPU than fastest RE in your network"), PCs can do BGP much faster than "hardware-based" routers (aka "forwarding ASICs don't run BGP"). As result, BGP Zebra/Linux can take 100k routes in <10 seconds (haven't measured exactly). > o) As its entirely process based it will hurt badly in a DoS attack > > This is a show stopper. I need the box to stay up in an attack and be > responsive to me whilst I attempt to find the source. Well, its not "process based", but it *is* "flow based". Yes, performance suffers as packets/flow rate decreases, however, it doesn't suffer as bad as other flow-based devices. > I'm not an expert in PC hardware, so I do struggle to work out the > architecture that I need and I'm sure its possible to build boxes that > are optimised for this purpose however I'm still not convinced that the > box can keep up with the demands of day to day packet switching - I'd > like to hear otherwise tho.. has anyone deployed a PC with Zebra that > could switch a few Gbs, didnt suffer from latency or jitter or fail > under a DoS? It is not gbps that kill you, it is the pps (and/or new-flows-per-second). Getting to 1mpps on a single router today will probably be hard. However, I've been considering implementing a "clustered router" architecture, should scale pps more or less linearly based on number of "PCs" or "routing nodes" involved. I'm not sure if discussion of that is on-topic here, so maybe better to take it offline.
RE: PC Routers (was Re: /24s run amuck)
>> almost all times I hear people saying there is problem >> with Zebra or Quagga, more than half of all times it >> is problem with their OS, not the daemon. > and we care because? the router is a black box. if the > output is not what is expected, it matters not why. > though understandable, it is still not acceptable. The main issues I have with zebra are: 1. The need to install an OS on the host. 2. The need to harden it. 3. The possible hard disk failure (having *nix on ATA flash is no better given the actual limits in the number of times one can write to flash). There are things that I don't like with Cisco, but one thing I do like is that it boots from flash and it takes no time to install an image, remove the pcmcia card from the router, and boot different images from the flash with the flip of a config command. The concept of appliance (vs. computer) comes to mind. That being said, How does zebra deal with QOS/priority/custom/queuing/LLQ? With CAR? With IDS? With route redistribution to/from OSPF or ISIS? With multichassis multilink PPP? With spanning tree on multiple VLANs? With peer groups? With SNMP? How does the host deal with 802.1q trunks? With Channel interfaces? With hot-swapping a line card? With TCP MD5? These are the questions I ask myself when I pick a routing platform. Cheap is of no use to me if it does not do what I need. Michel.
Re: PC Routers (was Re: /24s run amuck)
- Original Message - From: <[EMAIL PROTECTED]> To: "Paul" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]>; "james" <[EMAIL PROTECTED]>; "Danny Burns" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Wednesday, January 14, 2004 8:18 PM Subject: Re: PC Routers (was Re: /24s run amuck) > > > > no, i blame the solution. if fans in my switch keep dying, i blame the > > manufacturer of the switch for picking an unreliable fan manufactuer, not > > the manufacturer of the fan alone. > > wrong. more than half of all problems i hear, the _fan_ is the OS or the > implementation by user, not zebra/quagga. that is exactly the way i meant it. paul
Re: PC Routers (was Re: /24s run amuck)
> > no, i blame the solution. if fans in my switch keep dying, i blame the > manufacturer of the switch for picking an unreliable fan manufactuer, not > the manufacturer of the fan alone. wrong. more than half of all problems i hear, the _fan_ is the OS or the implementation by user, not zebra/quagga. > > > if an equipment / vendor you have on your network is not acceptable, do > what is > > acceptable such as (get another vendor|debug the problem|call the support) > etc > > yes. i handle this by not using zebra/(.*)OS boxes for tasks that are better > handled by something else. > > paul > -- James Jun (formerly Haesu) TowardEX Technologies, Inc. 1740 Massachusetts Ave. Boxborough, MA 01719 Consulting, IPv4 & IPv6 colocation, web hosting, network design & implementation http://www.towardex.com | [EMAIL PROTECTED] Cell: (978)394-2867 | Office: (978)263-3399 Ext. 170 Fax: (978)263-0033 | AIM: GigabitEthernet0 NOC: http://www.twdx.net | POC: HAESU-ARIN, HDJ1-6BONE
Re: PC Routers (was Re: /24s run amuck)
- Original Message - From: <[EMAIL PROTECTED]> To: "Paul" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]>; "james" <[EMAIL PROTECTED]>; "Danny Burns" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Wednesday, January 14, 2004 8:06 PM Subject: Re: PC Routers (was Re: /24s run amuck) > > ... and we care because? the router is a black box. if the output is not > > what is expected, it matters not why. though understandable, it is still not > > acceptable. > > and you blame zebra ? no, i blame the solution. if fans in my switch keep dying, i blame the manufacturer of the switch for picking an unreliable fan manufactuer, not the manufacturer of the fan alone. > if an equipment / vendor you have on your network is not acceptable, do what is > acceptable such as (get another vendor|debug the problem|call the support) etc yes. i handle this by not using zebra/(.*)OS boxes for tasks that are better handled by something else. paul
Re: PC Routers (was Re: /24s run amuck)
> ... and we care because? the router is a black box. if the output is not > what is expected, it matters not why. though understandable, it is still not > acceptable. and you blame zebra ? if an equipment / vendor you have on your network is not acceptable, do what is acceptable such as (get another vendor|debug the problem|call the support) etc > > paul > -- James Jun (formerly Haesu) TowardEX Technologies, Inc. 1740 Massachusetts Ave. Boxborough, MA 01719 Consulting, IPv4 & IPv6 colocation, web hosting, network design & implementation http://www.towardex.com | [EMAIL PROTECTED] Cell: (978)394-2867 | Office: (978)263-3399 Ext. 170 Fax: (978)263-0033 | AIM: GigabitEthernet0 NOC: http://www.twdx.net | POC: HAESU-ARIN, HDJ1-6BONE
Re: PC Routers (was Re: /24s run amuck)
- Original Message - From: <[EMAIL PROTECTED]> To: "james" <[EMAIL PROTECTED]> Cc: "Danny Burns" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Wednesday, January 14, 2004 7:36 PM Subject: Re: PC Routers (was Re: /24s run amuck) > > almost all times I hear people saying there is problem with Zebra or Quagga, > more than half of all times it is problem with their OS, not the daemon. ... and we care because? the router is a black box. if the output is not what is expected, it matters not why. though understandable, it is still not acceptable. paul
IP Subnet Management?
Hey everyone, I've been trying to come up with an algorithm to describe the assignment of IP subnets. I have something in a proof of concept form that will break a block of addresses into subnets at a user's request. The thing is that the assignments it makes are provably optimal. Within the limits you may place on an assignment, there will never be more than one empty subnet of any particular size. I am curious as to what other things I should try and put into this. Right now, if you request a /16 from a /8, the /16 is considered assigned and further changes within it are not possible. Would 'children' so to speak be useful for you? What would your ideas be? How have you tackled this problem? Feel free to respond off list if you'd like :-) Appreciate your time! Mike (sick of spreadsheets) Wiacek
Re: PC Routers (was Re: /24s run amuck)
almost all times I hear people saying there is problem with Zebra or Quagga, more than half of all times it is problem with their OS, not the daemon. On Wed, Jan 14, 2004 at 05:00:06PM -0700, james wrote: > > > : Be real carfull with Zebra, I got stung big time !!! > > What I run is actually Quagga, despite saying Zebra. > Would you share your experiences ? > > James Edwards > Routing and Security > [EMAIL PROTECTED] > At the Santa Fe Office: Internet at Cyber Mesa > Store hours: 9-6 Monday through Friday > 505-988-9200 SIP:1(747)669-1965 -- James Jun (formerly Haesu) TowardEX Technologies, Inc. 1740 Massachusetts Ave. Boxborough, MA 01719 Consulting, IPv4 & IPv6 colocation, web hosting, network design & implementation http://www.towardex.com | [EMAIL PROTECTED] Cell: (978)394-2867 | Office: (978)263-3399 Ext. 170 Fax: (978)263-0033 | AIM: GigabitEthernet0 NOC: http://www.twdx.net | POC: HAESU-ARIN, HDJ1-6BONE
Re: PC Routers (was Re: /24s run amuck)
: Be real carfull with Zebra, I got stung big time !!! What I run is actually Quagga, despite saying Zebra. Would you share your experiences ? James Edwards Routing and Security [EMAIL PROTECTED] At the Santa Fe Office: Internet at Cyber Mesa Store hours: 9-6 Monday through Friday 505-988-9200 SIP:1(747)669-1965
Re: PC Routers (was Re: /24s run amuck)
: Which "no features"? I haven't played with zebra yet, but my : understanding is that it supports a large subset of the IOS BGP config : language including application of route-maps to incoming/outgoing routes, : and therefore things like prepending, setting metrics or preference, etc. : Am I mistaken? Yes, all of that is supported & more: zebra(config-router)# neighbor 1.1.1.1 advertisement-interval Minimum interval between sending BGP routing updates interface Interface peer-group Member of the peer-group port Neighbor's BGP port strict-capability-matchStrict capability negotiation match timers BGP per neighbor timers transparent-as Do not append my AS number even peer is EBGP peer transparent-nexthopDo not change nexthop even peer is EBGP peer versionNeighbor's BGP version activate Enable the Address Family for this Neighbor allowas-in Accept as-path with my AS present in it attribute-unchangedBGP attribute is propagated unchanged to this neighbor capability Advertise capability to the peer default-originate Originate default route to this neighbor descriptionNeighbor specific description distribute-listFilter updates to/from this neighbor dont-capability-negotiate Do not perform capability negotiation ebgp-multihop Allow EBGP neighbors not on directly connected networks enforce-multihop Enforce EBGP neighbors perform multihop filter-listEstablish BGP filters local-as Specify a local-as number maximum-prefix Maximum number of prefix accept from this peer next-hop-self Disable the next hop calculation for this neighbor override-capabilityOverride capability negotiation result passiveDon't send open messages to this neighbor prefix-listFilter updates to/from this neighbor remote-as Specify a BGP neighbor remove-private-AS Remove private AS number from outbound updates route-map Apply route map to neighbor route-reflector-client Configure a neighbor as Route Reflector client route-server-clientConfigure a neighbor as Route Server client send-community Send Community attribute to this neighbor shutdown Administratively shut down this neighbor soft-reconfiguration Per neighbor soft reconfiguration unsuppress-map Route-map to selectively unsuppress suppressed routes update-source Source of routing updates weight Set default weight for routes from this neighbor James Edwards Routing and Security [EMAIL PROTECTED] At the Santa Fe Office: Internet at Cyber Mesa Store hours: 9-6 Monday through Friday 505-988-9200 SIP:1(747)669-1965
Re: PC Routers (was Re: /24s run amuck)
On 14 Jan 2004, at 17:49, [EMAIL PROTECTED] wrote: On Wed, 14 Jan 2004, Stephen J. Wilcox wrote: Have been discussing PCs for a bit but as yet not deployed one, as I understand it a *nix based PC running Zebra will work pretty fine but has the constraints that: o) It has no features - not a problem for a lot of purposes Which "no features"? I haven't played with zebra yet, but my understanding is that it supports a large subset of the IOS BGP config language including application of route-maps to incoming/outgoing routes, and therefore things like prepending, setting metrics or preference, etc. Am I mistaken? It is my impression that Zebra is pretty feature-rich. There are some things that are difficult for Zebra to do since they relate to (absent) capabilities in the host kernel, though; RFC 2385 requires the host to support the TCP MD5 Signature option, for example, and most do not. Joe
Re: PC Routers (was Re: /24s run amuck)
On Wed, 14 Jan 2004, Stephen J. Wilcox wrote: > Have been discussing PCs for a bit but as yet not deployed one, as I > understand it a *nix based PC running Zebra will work pretty fine but > has the constraints that: > > o) It has no features - not a problem for a lot of purposes Which "no features"? I haven't played with zebra yet, but my understanding is that it supports a large subset of the IOS BGP config language including application of route-maps to incoming/outgoing routes, and therefore things like prepending, setting metrics or preference, etc. Am I mistaken? > o) On a standard PCI but your limit is about 350Mb, you can increase that to a > couple of Gb using 64-bit fancy thingies The application where I'm caring for one of these is around a dozen T1's to several different transit providers on a Gateway router. According to Imagestream, this router can handle up to 1 OC3 at "wire speed". We're obviously not pushing anywhere near that through it. The same customer has a handful of Rebel routers used for T1s/ethernets within their network. > o) This may be fixed but I found it slow to update the kernel routing table > which isnt designed to take 12 routes being added at once > > Icky, could perhaps cause issues if theres a major reconvergence due to an > adjacent backbone router failing etc, might be okay tho I've never timed it, but I haven't noticed it taking routes any slower than the ciscos I'm used to. > o) As its entirely process based it will hurt badly in a DoS attack > > This is a show stopper. I need the box to stay up in an attack and be responsive > to me whilst I attempt to find the source. But it's got so much more CPU power than comparably priced ciscos...and most of the cisco gear I've worked on doesn't to terribly well under DoS...so I don't see a distinction here. Either way, getting DoS'd sucks, but I've never seen a DoS hit any of the Imagestreams, so I don't know how it copes. > I'm not an expert in PC hardware, so I do struggle to work out the > architecture that I need and I'm sure its possible to build boxes that > are optimised for this purpose however I'm still not convinced that the > box can keep up with the demands of day to day packet switching - I'd Their bigger routers, I'm pretty sure, have multiple PCI buses, so if you wanted to push lots of traffic, careful planning of which bus you put each card in may make a difference. Their tech support is pretty responsive, so they'd be the place to go with technical/architectural questions. Another nice feature is with iptables, they can now do stateful firewalling / connection tracking. -- Jon Lewis [EMAIL PROTECTED]| I route Senior Network Engineer | therefore you are Atlantic Net| _ http://www.lewis.org/~jlewis/pgp for PGP public key_
Re: PC Routers (was Re: /24s run amuck)
: o) This may be fixed but I found it slow to update the kernel routing table : which isnt designed to take 12 routes being added at once : : Icky, could perhaps cause issues if theres a major reconvergence due to an : adjacent backbone router failing etc, might be okay tho This is the general feeling on the Quagga list; that many limitations are not the routing daemon(s) themselves but the underlying OS and kernel. james
RE: /24s run amuck
If you have had any experiences, good or bad, with Imagestream, please contact me off-list (or here). I would appreciate any or all of your collective input. Thank you, Shawn -- Shawn Solomon Senior Network Engineer / Systems Design IHETS / ITN 317.263.8875 [EMAIL PROTECTED] fx317.263.8831 -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Wednesday, January 14, 2004 4:20 PM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: /24s run amuck On Wed, 14 Jan 2004 [EMAIL PROTECTED] wrote: > I stand corrected. The following page comparing Cisco and Imagestream > is quite interesting. > > http://www.imagestream.com/Cisco_Comparison.html > > How many of you would buy an Imagestream box to evaluate for > your next network buildout? I've been managing a couple of these for a customer for a couple of years. They work. The main problem I'd have with trying to use them on our network is a lack of certain features I'm either used to or totally dependent on in our ciscos. i.e. MPLSVPN (lack of it) would be a show stopper for us. The gated-public they come with lacks features...AFAIK there is no support for communities, prepending, etc. Their current software image does include zebra now, but last I looked it was not officially supported. For a relatively simple end-user BGP customer, it works fine. And the nice thing is it's PC-type hardware so if you need more RAM, just throw in another dimm. No worries about the global routing table growing and having to buy a bigger router because your year or two old one no longer supports enough memory to hold full routes. I suspect the CPUs are upgradable as well...but I've never actually touched the hardware...I've always worked on it remotely. OS-wise, it's a minimal Linux distribution with a menu interface (or you can drop to a shell) and there is a little space on the flash to add additional software if there something you want that they don't supply. -- Jon Lewis [EMAIL PROTECTED]| I route Senior Network Engineer | therefore you are Atlantic Net| _ http://www.lewis.org/~jlewis/pgp for PGP public key_
PC Routers (was Re: /24s run amuck)
On Wed, 14 Jan 2004, [EMAIL PROTECTED] wrote: > > http://www.imagestream.com/Cisco_Comparison.html > > > > How many of you would buy an Imagestream box to evaluate for > > your next network buildout? > > For a relatively simple end-user BGP customer, it works fine. And the > nice thing is it's PC-type hardware so if you need more RAM, just throw in > another dimm. No worries about the global routing table growing and > having to buy a bigger router because your year or two old one no longer > supports enough memory to hold full routes. I suspect the CPUs are > upgradable as well...but I've never actually touched the hardware...I've > always worked on it remotely. Have been discussing PCs for a bit but as yet not deployed one, as I understand it a *nix based PC running Zebra will work pretty fine but has the constraints that: o) It has no features - not a problem for a lot of purposes This isnt necessarily a problem for what I have in mind o) On a standard PCI but your limit is about 350Mb, you can increase that to a couple of Gb using 64-bit fancy thingies For connecting to small IXPs, connecting customers, I dont need large amounts of throughput. o) This may be fixed but I found it slow to update the kernel routing table which isnt designed to take 12 routes being added at once Icky, could perhaps cause issues if theres a major reconvergence due to an adjacent backbone router failing etc, might be okay tho o) As its entirely process based it will hurt badly in a DoS attack This is a show stopper. I need the box to stay up in an attack and be responsive to me whilst I attempt to find the source. I'm not an expert in PC hardware, so I do struggle to work out the architecture that I need and I'm sure its possible to build boxes that are optimised for this purpose however I'm still not convinced that the box can keep up with the demands of day to day packet switching - I'd like to hear otherwise tho.. has anyone deployed a PC with Zebra that could switch a few Gbs, didnt suffer from latency or jitter or fail under a DoS? Steve
Re: /24s run amuck
At 03:36 PM 1/14/2004, Daniel Golding wrote: Sadly, the type of person that public shame would work on, is the type of person that is already taking care of the problem, or will be soon. There is one mechanism for helping to solve this. Is there an RFC, informational or otherwise that clearly specifies that BGP announcements to peers and transit providers must be aggregated to the greatest extent possible? If not, someone should write one. If yes, they lets publicize it. This is a wonderful tool for network engineers to take to their managers, so they can say "look, we have to do this, the RFC says so, and we MUST be RFC complaint or #insert-horrible-thing will happen to us". We live in a world of PHBs (Point Haired Bosses - see dilbert) When those engineers succeed with their bosses in keeping RFC 1918 addresses off the backbone (read it, 1918 is a BCP, and says that), or when those engineers manage to implement RFC 2827 -- ingress filtering (also BCP) then maybe you'll have some ammunition that having a BCP about prefix filtering will be respected. RFCs make suggestions. BCPs make stronger suggestions than some other RFCs, but clearly much of the community doesn't care, and ignores them just the same.
Peering BOF: Announcing The Great Debate
Hi all - Restrictive Peering Policies: The Great Debate --- Monday Evening at the upcoming Peering BOF at NANOG 30 in Miami we are trying something new: at the beginning of the Peering BOF there will be "A Great Debate" on the topic of Restrictive Peering Policies. Taking the Pro: side is Vijay Gill who will argue "A Restrictive Peering Policy makes business sense." Taking the Con: side is Avi Freedman who will argue "Restrictive Peering Policies are counter productive." Note: The views presented do not necessarily represent the views of the individuals or their employers; the debaters have been coached to present the most compelling case possible given the following rough peering policy classifications and definitions: Open means that the entity will generally agree to peer with anyone in any single location with no prerequisites. Selective means that the entity will generally peer but there are some prerequisites (such as meeting in multiple Interconnect Regions, with a minimum traffic volume, not to exceed a certain In/Out traffic ratio, etc). The Peering Policy documents these prerequisites, which, once met, generally lead to peering. Restrictive means that the entity is generally not open to new peering. The Peering Policy documents extremely difficult to meet peering prerequisites, with the unstated purpose of denying peering. Peering is defined as a business relationship whereby two entities reciprocally and freely exchange access to each others customers. Transit is defined as a business relationship whereby one entity sells access to the *entire* Internet to another. There are of course variations of the above including Paid Peering (exchange of access to each others customers with some form of settlement) and Partial Transit (one entity sells access to part of the Internet, typically broader than just their customers). The format of the Debate: Coin Flip to decide who goes first Side A presents their position (3.5 minutes) Side B presents their position (3.5 minutes) Side A counters and/or reinforces their own position (3.5 minutes) Side B counters and/or reinforces their own position (3.5 minutes) Side A Summation (3.5 minutes) Side B Summation (3.5 minutes) The audience will vote "Who makes the more compelling case" to determine the winner of the debate. My hope is that this will focus the light on an issue that seems to have always caused a great deal more heat than light in the Peering Coordinator Community. Perhaps we will see that there are indeed reasonable and rational arguments on both sides of this debate. Following the debate will be Peering Personals, giving Peering Coordinators a chance to talk about their network, what they look for in a peer, why others should want to peer with them, etc. as per http://www.nanog.org/mtg-0402/norton.html This has proven to be an effective way of pulling together the community of Peering Coordinators, hopefully resulting in more peering sessions. I think you will find this debate and the Peering BOF highly entertaining and maybe even educational ;-) Cheers - Bill PS - If you are a Peering Coordinator and would like to take part in the Peering Personals, I have a handful of slots left. Please fill out the form at the URL above and send it to [EMAIL PROTECTED] Thanks!
Re: /24s run amuck
On Wed, 14 Jan 2004 [EMAIL PROTECTED] wrote: > I stand corrected. The following page comparing Cisco and Imagestream > is quite interesting. > > http://www.imagestream.com/Cisco_Comparison.html > > How many of you would buy an Imagestream box to evaluate for > your next network buildout? I've been managing a couple of these for a customer for a couple of years. They work. The main problem I'd have with trying to use them on our network is a lack of certain features I'm either used to or totally dependent on in our ciscos. i.e. MPLSVPN (lack of it) would be a show stopper for us. The gated-public they come with lacks features...AFAIK there is no support for communities, prepending, etc. Their current software image does include zebra now, but last I looked it was not officially supported. For a relatively simple end-user BGP customer, it works fine. And the nice thing is it's PC-type hardware so if you need more RAM, just throw in another dimm. No worries about the global routing table growing and having to buy a bigger router because your year or two old one no longer supports enough memory to hold full routes. I suspect the CPUs are upgradable as well...but I've never actually touched the hardware...I've always worked on it remotely. OS-wise, it's a minimal Linux distribution with a menu interface (or you can drop to a shell) and there is a little space on the flash to add additional software if there something you want that they don't supply. -- Jon Lewis [EMAIL PROTECTED]| I route Senior Network Engineer | therefore you are Atlantic Net| _ http://www.lewis.org/~jlewis/pgp for PGP public key_
Re: /24s run amuck
> >I stand corrected. The following page comparing Cisco and Imagestream > >is quite interesting. > > > >http://www.imagestream.com/Cisco_Comparison.html > > > > Hmm -- does anyone here have one? How good a job did they do locking > down Linux? I have one. Two, actually. They have user-friendlied it up - you log in and you get a not-that-fancy menu interface. The router is based on gated, not zebra/quagga. It works alright, but there are a number of gaping inconsistencies with it. It's not necessarily that I have a problem with PC routers, it's that their implementation leaves some to be desired. For further information, inquiries to me off-list. Tim
Re: /24s run amuck
Sadly, the type of person that public shame would work on, is the type of person that is already taking care of the problem, or will be soon. There is one mechanism for helping to solve this. Is there an RFC, informational or otherwise that clearly specifies that BGP announcements to peers and transit providers must be aggregated to the greatest extent possible? If not, someone should write one. If yes, they lets publicize it. This is a wonderful tool for network engineers to take to their managers, so they can say "look, we have to do this, the RFC says so, and we MUST be RFC complaint or #insert-horrible-thing will happen to us". We live in a world of PHBs (Point Haired Bosses - see dilbert) - Dan On 1/13/04 12:26 PM, "Patrick W.Gilmore" <[EMAIL PROTECTED]> wrote: > > On Jan 13, 2004, at 9:58 AM, Randy Bush wrote: >> >>> Deaggregation is at an all time high, I have raised this publically in >>> some forums and IXP ops lists. Response is poor, action is >>> non-existent. >>> >>> The only way I can see to do anything about this is for upstreams to >>> educate their customers and others to pressure their peers. >> >> or just filter > > Unfortunately, most customers expect connecting to the entire Internet, > not just the parts that are smart and courteous enough to aggregate. > Since most networks are in business to make money, they do what their > customers want. Unless all networks filter alike, customers will > migrate to the ones with the "best" connectivity. Given that some > networks cannot even aggregate properly, I submit it is impossible to > get all networks to filter alike. > > Deaggregation is annoying, rude, and silly, but it does not actually > stop me my data getting from point A to point B. Disconnectivity > between me and someone else on the Internet, whether they are > aggregating properly or not, is not why I pay my transit provider. If > I can't get there, you don't get paid. > > This is a serious issue, since "Tier 1" networks have been huge > deaggregation culprits in the past. I think China Telecom topped the > latest CIDR report, and lots of people want to talk to the billion-plus > end users over there. > > So perhaps we should find a better way to encourage aggregation than > hurting our business and customers? Anyone have a suggestion? Maybe > public humiliation at NANOG? :)
Re: /24s run amuck
This was always a bad practice. One of the major networks to do this is Gone. Another had rewritten their policy to say something along the lines of "should advertise X amount of address space in aggregate or the equivalent". I don't think anyone still measures by prefixes alone. It was always the sign of cluelessness amongst those setting peering requirements. - Daniel Golding On 1/13/04 6:52 AM, "Patrick W.Gilmore" <[EMAIL PROTECTED]> wrote: > > On Jan 13, 2004, at 6:33 AM, Michael Hallgren wrote: > >>> and that a large driver is to >>> make your network look larger than it is... >>> >> >> What audience?? > > Unfortunately, I've seen Peering Policies which require things like > "Must announce a minimum of 5,000 prefixes". :(
Re: Contact from Google urgently needed
On Wed, Jan 14, 2004 at 03:04:02PM -0500, Eric L. Howard wrote: > At a certain time, now past [Jan.14.2004-01:36:08PM -0500], [EMAIL PROTECTED] spake > thusly: > > If anyone on the list is employed by Google please contact me ASAP. > > I've sent emails to [EMAIL PROTECTED] and haven't gotten a response. > > There's nothing on the NOC list for Google. > Don't know if you've got this issue resolved yet...but you might try any/one > of these: [ ARIN, domain whois and RADB contacts snipped... and in general, it's probably impolite to post unmunged email addresses here, since I'm sure Google probably gets enough spam to their various role accounts ] I'll just say that on the few occasions I've had to contact Google about one thing or another (generally via the contacts listed in the ARIN whois), they've been helpful and responsive. -- "Since when is skepticism un-American? Dissent's not treason but they talk like it's the same..." (Sleater-Kinney - "Combat Rock")
Re: Contact from Google urgently needed
At a certain time, now past [Jan.14.2004-01:36:08PM -0500], [EMAIL PROTECTED] spake thusly: > > If anyone on the list is employed by Google please contact me ASAP. I've > sent emails to [EMAIL PROTECTED] and haven't gotten a response. There's > nothing on the NOC list for Google. Don't know if you've got this issue resolved yet...but you might try any/one of these: [EMAIL PROTECTED] elh $ whois google.com | grep google.com Domain Name: google.com [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] elh $ dnsip www.google.com 216.239.39.99 [EMAIL PROTECTED] elh $ awhois 216.239.39.99 | grep google.com TechEmail: [EMAIL PROTECTED] OrgTechEmail: [EMAIL PROTECTED] [EMAIL PROTECTED] elh $ radbwhois 216.239.39.99 | grep google.com notify:[EMAIL PROTECTED] changed: [EMAIL PROTECTED] 20030903 [EMAIL PROTECTED] elh $ radbwhois AS15169 | grep google.com descr: Google Inc (search engine www.google.com) notify:[EMAIL PROTECTED] changed: [EMAIL PROTECTED] 2418 ~elh -- Eric L. Howard e l h @ o u t r e a c h n e t w o r k s . c o m www.OutreachNetworks.com313.297.9900 JabberID: [EMAIL PROTECTED] Advocate of the Theocratic Rule
Contact from Google urgently needed
If anyone on the list is employed by Google please contact me ASAP. I've sent emails to [EMAIL PROTECTED] and haven't gotten a response. There's nothing on the NOC list for Google. Thanks, -Dave
Re: imagestream vs. Cisco
On Wed, Jan 14, 2004 at 09:23:35AM -0500, Alex Yuriev wrote: > > Imagestream uses Cisco list prices to sell their wares. No sane person that > buys from Cisco pays list price. > > If one wants to complete with Cisco in a router business, they cannot claim > that it costs $3411 to get 2x T1 router by Cisco or that 7507 chassis is > $21,700. That might be true, but have a look at the following article: they outperform a 26xx. (Ok, I admit, a 26xx is not a power-monster, but it's in the same price range as the small rebels)... http://www.nwfusion.com/reviews/2003/0714rev.html Kind Regards, Frank Louwers -- Openminds bvbawww.openminds.be Tweebruggenstraat 16 - 9000 Gent - Belgium
imagestream vs. Cisco
> >imagestream does this, afaik. not too familiar with their offerings > though. > > I stand corrected. The following page comparing Cisco and Imagestream > is quite interesting. > > http://www.imagestream.com/Cisco_Comparison.html > > How many of you would buy an Imagestream box to evaluate for > your next network buildout? Imagestream uses Cisco list prices to sell their wares. No sane person that buys from Cisco pays list price. If one wants to complete with Cisco in a router business, they cannot claim that it costs $3411 to get 2x T1 router by Cisco or that 7507 chassis is $21,700. Alex
Re: /24s run amuck
In message <[EMAIL PROTECTED] om>, [EMAIL PROTECTED] writes: > >>> The thing that surprises me is that there aren't any small >>> vendors offering fairly generic routing boxes, i.e. Intel-based > >>imagestream does this, afaik. not too familiar with their offerings >though. > >I stand corrected. The following page comparing Cisco and Imagestream >is quite interesting. > >http://www.imagestream.com/Cisco_Comparison.html > Hmm -- does anyone here have one? How good a job did they do locking down Linux? --Steve Bellovin, http://www.research.att.com/~smb
Re: c1700 router
> Does anyone have data on the capacity of a c1700 using a T1 csu/dsu. The most I've run through one is four T1s and one FastE. No problem to pass 50K pps. > I have a customer who backhauls several sites into a c1700. I > suspect that it is or will soon reach capacity and should be > upgraded. It will run out of slots before it runs out of CPU. -Bill
c1700 router
Does anyone have data on the capacity of a c1700 using a T1 csu/dsu. I have a customer who backhauls several sites into a c1700. I suspect that it is or will soon reach capacity and should be upgraded. I need hard proof to that point. Tracey Webb Network Operations Cameron Communications, LLC 337-775-3097 Office 337-583-2097 [EMAIL PROTECTED] GO LSU!!! GO DUKE !!!
Re: /24s run amuck
I intend to give them a serious look: they sound like they could make good CPE for about 75% of my customers... (and of course, ssh v2 is a big plus :) -David Barak -Fully RFC 1925 Compliant- --- [EMAIL PROTECTED] wrote: > http://www.imagestream.com/Cisco_Comparison.html > > How many of you would buy an Imagestream box to > evaluate for > your next network buildout? > > --Michael Dillon > > = David Barak -fully RFC 1925 compliant- __ Do you Yahoo!? Yahoo! Hotjobs: Enter the "Signing Bonus" Sweepstakes http://hotjobs.sweepstakes.yahoo.com/signingbonus
Re: /24s run amuck
Sprint and a few others used to filter on /19s, 'cause that's what ARIN & others handed out. They changed that to /20s when the rules changed. Sprint gave that up. The filtering was done on the /18 because that was what I expected we could easily afford to support in terms of memory and computation, in terms of maximum number of prefixes. The move to /19s was driven by two arguments: firstly, the regional internet registries explained how they would not allocate out half the available /19s within a generation of routing equipment, and secondly, it squelched many of the usual sources of complaint. The deployment of progressive flap-damping further relieved the need to filter on short prefixes, and the subsequent complementary deployment of progressive maximum prefix count limits have essentially eliminated the need to do prefix-length filtering at all. Long prefixes now are simply less reliable than the covering shorter prefixes allocated by the RIRs. Just how unreliable a given prefix is would be difficult to predict, which is a misfeature, but the routing system as a whole is much more robust than it was a decade ago. Unfortunately there has been a macroeconomic cost to the growth of background noise in the Internet -- and the noise is still there -- which has made the Internet as a whole more expensive and less widely available than it ought to be. However, there are much larger contributions of such waste outside the public Internet's routing system that dwarf the cost of the unnecessary demands on router power resulting from poor aggregation, poor hygiene, and poor stabilization practices. Almost everyone filters on /24s - they do not want to see /32s in the global table. Why not? I'm curious about why /24s are OK but /32s are not. I suggest that if there is no reason other than a watered down version of the voodoo mentality you've accused me personally of having with respect to long prefixes -- i.e., if you think I'm right about the problem but too aggressive about the limit -- that there is a business opportunity still waiting to be exploited by someone enterprising. With respect to that, for my part I wish I could go back in time and complete the next phase of the filtering, viz. a web page which would accept a credit card number from anyone who wanted to have a particular prefix allowed through the access-list, for a small recurring fee. Live and learn... Sean.
Re: /24s run amuck
>> The thing that surprises me is that there aren't any small >> vendors offering fairly generic routing boxes, i.e. Intel-based >imagestream does this, afaik. not too familiar with their offerings though. I stand corrected. The following page comparing Cisco and Imagestream is quite interesting. http://www.imagestream.com/Cisco_Comparison.html How many of you would buy an Imagestream box to evaluate for your next network buildout? --Michael Dillon
Re: /24s run amuck
michael, imagestream does this, afaik. not too familiar with their offerings though. paul - Original Message - From: <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Wednesday, January 14, 2004 5:02 AM Subject: Re: /24s run amuck > > >Why vendors feel the need to design route > >processors which are barely upgradable in RAM, not upgradable in > >processing power, and at best 24-36 months behind the times of the > >technology the Dell Interns are pushing for $499, is beyond me. > > It's called profit margins. > > The thing that surprises me is that there aren't any small > vendors offering fairly generic routing boxes, i.e. Intel-based > motherboard, lots of RAM, BSD/Linux base OS with Zebra for > routing and some of the many PCI cards supporting T1 and > DS3 circuits (not to forget GigE...). In most other industries > that are dominated by a few large brand-name high-margin > suppliers there are also several low-margin suppliers offering > generic products with minimal handholding. Why don't we > see this in the router business? > > --Michael Dillon > >
Re: /24s run amuck
[EMAIL PROTECTED] wrote: The thing that surprises me is that there aren't any small vendors offering fairly generic routing boxes, i.e. Intel-based motherboard, lots of RAM, BSD/Linux base OS with Zebra for routing and some of the many PCI cards supporting T1 and DS3 circuits (not to forget GigE...). In most other industries that are dominated by a few large brand-name high-margin suppliers there are also several low-margin suppliers offering generic products with minimal handholding. Why don't we see this in the router business? A lot of the "broadband routers" / wireless access points you see in the market are built kind of like this.
Re: /24s run amuck
>Why vendors feel the need to design route >processors which are barely upgradable in RAM, not upgradable in >processing power, and at best 24-36 months behind the times of the >technology the Dell Interns are pushing for $499, is beyond me. It's called profit margins. The thing that surprises me is that there aren't any small vendors offering fairly generic routing boxes, i.e. Intel-based motherboard, lots of RAM, BSD/Linux base OS with Zebra for routing and some of the many PCI cards supporting T1 and DS3 circuits (not to forget GigE...). In most other industries that are dominated by a few large brand-name high-margin suppliers there are also several low-margin suppliers offering generic products with minimal handholding. Why don't we see this in the router business? --Michael Dillon
