RE: CIsco 7206VXR w/NPE-G1 Question
It's not the Cisco bashing I was referring to, but the all singing all dancing Juniper performance claim. That would not have anything to do with Juniper sucking the least? Alex
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: Request for submissions: messy cabling and other broken things
http://new.onecall.net/timages/dsxcabling.jpg http://new.onecall.net/timages/cat5patch.jpg Isn't it amazing how clean cabling in nearly empty collos and mmrs looks? Alex
Re: good cabling in real environments [Re: Request for submissions: messy cabling and other broken things]
How do you do good cabling in dynamic, real environments? :-) It is not that difficult *if* the money is spent in a short term to make sure that no ugly and silly stuff is crated in a longer(long) term. Strategically pre-running certain parts of the facility with cat5/fiber to minimize the dynamic portion of interconnect is a really good way to reduce the mess. Alex
Anyone from Cogent that can look at show log and not get confused?
Hello, If there is possibly maybe a person from Cogent that does not get severely confused and say Oh, it is just the way the routers work or Oh it just takes a long time for routes to be sent to you after being shown synch errors, garbage in AS_PATH that cogent is sending, I would greatly appreciate hearing from you since your lead tech thinks that it is normal for a GSR to take 30 minutes to receive entire 576 routes. Thanks, Alex
Re: Santa Fe city government computers knocked out by worm
No explaination why Sante Fe officials had not patched the city's computers in the three months since Microsoft announced the vulnerability and released the software updates. Nor why Sante Fe didn't have up to date anti-virus programs running on its computers. Nor why they were using such rubbish software for a mission- critical system. Because for people outside our little industry the software is a tool to get a JOB done, not the job itself. Alex
Re: Santa Fe city government computers knocked out by worm
On Mon, 17 Nov 2003 06:26:50 EST, Alex Yuriev said: Because for people outside our little industry the software is a tool to get a JOB done, not the job itself. It doesn't take long for the average mechanic to learn that buying cheap wrenches is a bad idea. Do you take your car to McLaren service center? Why not? They definitely have better tools. Alex
Re: Santa Fe city government computers knocked out by worm
Valdis Kletnieks responded: It doesn't take long for the average mechanic to learn that buying cheap wrenches is a bad idea. to which Alex replied: Do you take your car to McLaren service center? Why not? They definitely have better tools. To which I say: No, but if the mechanic I did go to had a habit of using tools that regularly caused my car to halt and catch fire with me in it, I think I'd switch mechanics until I found somebody that used more reliable tools. Again, for the end customer, the level of damage that they are experiencing is too little to bother. Alex
law enforcement contacts
Hi, Anyone has any good law enforcement contacts that have enough clue ( or could be educated in process ) to work on catching and nailing DOS originators? Please drop me email off the list. Alex
Re: DDoS detection and mitigation systems
Do you use/develop in-house tools to analyze Netflow on your peering routers and have that interface in near-realtime with the said routers to null route (BGP and RPF) the offending sources? Source or destination? Null routing source of DOS is not going to do you any good. Null routing destination, especially automatically null routing destination, creates a large possibility of shooting yourself in a foot. Alex
Re: Sabotage investigation of fiber cuts in Northwest
You'd think after three previous disruptions, that Qwest would have enabled some form of redundancy. Redundancy hell. How about a *PADLOCK*? You mean that these places aren't even locked? Who has (had) the key? That'd be the first place I looked. The most amazing things can be found on certain northern cross-country fiber routes in areas where cellphones don't work - they thought about everything putting hundred thousand dollar doors and locks to prevent those who are not supposed to get into the huts from getting there... Excellence to the nines. Of course, since no one wants to carry keys to those super secure entrances, the same time of cobination keyholders that SD and some others use to attach cabinet keys to the back of the cabinets themselves had been placed right by those super secure doors. Needless to say, it did not take long for every combination locked to be popped, keys taken out and super-secure doors opened. Alex
Re: [arin-announce] IPv4 Address Space (fwd)
Are you actually saying that providers in the middle should build their networks to accommodate any amount of DDOS traffic their ingress can support instead of filtering it at their edge? How do you expect them to pay for that? Do you really want $10,000/megabit transit costs? I remember GM saying something like that about this car that put Nader on political arena. Are we that dumb that we need to be taught the same lessons? Fix the networks. Force the customers to play by the rules. Alex
RE: more on filtering
Do you actually believe that it was a BAD idea for Cisco to build a router that is more efficient (to the point of being able to handle high-rate interfaces at all) when presented with traffic flows that look like real sessions? Why buy something that works well only sometimes (we are very efficient when it looks like 'real' traffic from Cisco) when you can buy (no one told us that we should have issues with some specific packets) Juniper? Alex
RE: [arin-announce] IPv4 Address Space (fwd)
I remember GM saying something like that about this car that put Nader on political arena. Are we that dumb that we need to be taught the same lessons? GM seems to still be building cars and trucks, and Nader lost a presidential election. GM seems to also have cut a very big check to pay the judgements. Alex
Re: Yankee Group declares core routing obsolete (was Re: Anybody using GBICs?)
Maybe the Yankee Group is a subsidiary of Ncatal Ventures. That was my thought. Its Dood, Where's my Core? all over again! It got lost in san franCisco. Alex
traffic engineering (or lack of thereof)
And how many people here operate non-oversubscribed networks? The right question here should be How many people here operate non-super oversubscribed networks? Oversubscribed by a a few percents is one thing, oversubscribed the way certain cable company in NEPA does it is another.[1] So having 3 Gb of DoS traffic coming across a half dozen peering OC48s isn't that bad; but having it try to fit onto a pair of OC48s into the backbone that are already running at 40% capacity means you're SOL unless you filter some of that traffic out. Why does your backbone have only two OC48s that are 40% utilized if you have half a dozen peering OC48s that can easily take those 3Gb/sec? And I've been in that situation more times than I'd like to remember, because you can't justify increasing capacity internally from a remote peering point into the backbone simply to be able to handle a possible DoS attack. This means that the PNIs of such network are full already. So we are back to the super-oversubscribed issue. Even if you _do_ upgrade capacity there, and you carry the extra 3Gb of traffic from your peering links through your core backbone, and off to your access device, you suddenly realize that the gig port on your access device is now hosed. You can then filter the attack traffic out on the device just upstream of the access box, but then you're carrying it through your core only to throw it away after using up backbone capacity; why not discard it sooner rather than later, if you're going to have to discard it anyhow? Because you do not know what is the evil traffic and what is the good traffic. And under those circumstances, there is a strong preference to discard bad traffic rather than good traffic if at all possible. One technique we currently use for making those decisions is looking at the type of packets; are they 92 byte ICMP packets, are they TCP packets destined for port 1434, etc. And this technique presumes that the backbone routers know what are the packets that their customers are want to go through and which ones they do not. Again, this is not a job of backbone routers. It is a kluge that should be accepted as a kludge. I'd be curious to see what networks you know of where the IS component does *no* statistical aggregation of traffic whatsoever. :) The example that you are using is not based on statistical traffic aggregation. Rather it is based on an arbitrary decision of what is good and what is bad traffic (just like certain operators that claimed that DHS ordered them to block certain ports). Matt Alex [1] Bring three T1s of IP. Sell service to serveral hundred cable customers.
Re: [arin-announce] IPv4 Address Space (fwd)
Leave content filtering to the ES, and *force* ES to filter the content. Its not content filtering, I'm not filtering only certain html traffic (like access to porn sites), I'm filtering traffic that is causing harm to my network and if I know what traffic is causing problems for me, I'll filter it first chance I get. It is content filtering. You are filtering packets that you think are causing problems to the ES that you may not control. Alex
Re: [arin-announce] IPv4 Address Space (fwd)
Alex, please re-read the first paragraph. He said I'm filtering traffic that is causing harm to *my* network... (emphasis mine). He's not filtering out packets he thinks are causing problems to the ES, he's filtering out packets that are causing him problems directly, as the IS. And since the IS is not the ES, it SHOULD NOT be filtering based on content since it is NOT IS's content. Again, *force* ES to filter and hold it responsible for not doing it. Alex
Re: [arin-announce] IPv4 Address Space (fwd)
to the ES, he's filtering out packets that are causing him problems directly, as the IS. And since the IS is not the ES, it SHOULD NOT be filtering based on content since it is NOT IS's content. Again, *force* ES to filter and hold it responsible for not doing it. Do you have a generator in your colo/server space? Why? To follow your logic out, should you not simply be *forcing* the Electric Company to provide power and hold it responsible for not doing so? ( Hmm, no that is slightly different as you are direct customer ). I am so glad that you used that example. The way currently people propose everyone operates is equivalent to a company that transmits AC to customer deciding that some part of the AC waveform is harmful to its equipment, and therefore should be filtered out. Of course, no one bothers to tell the customer that the filter exists, or what is being filtered, or when, or how. Better example if you are UPS and a package being shipped is emitting RF that is interferring with your plane avionics, should you not remove that package from the shipment ( filter it out, as it were )? Another excellent example - UPS will not remove that. The shipper will. It is sound business logic that if something is impacting your ability to provide service *and* you are provided with the means to address the problem, that you should utilize those means ( w/ in the extent allowed by the law and your legal agreements ). The first part of any legal agreement establishes the parties subject to it. That is exactly what you are missing while being an IS. Alex
Re: [arin-announce] IPv4 Address Space (fwd)
I think the other point that may be escaping some people, is that as more and more connections take on this VPN-like quality, as network operators we lose any visibility into the validity of the traffic itself. As the network operators, we move bits and that is what we should stick to moving. We do not look into packets and see oh look, this to me looks like an evil application traffic, and we should not do that. It should not be the goal of IS to enforce the policy for the traffic that passes through it. That type of enforcement should be left to ES. Imagine how much more painful SQL Slammer would have been, if all the traffic was encapsulated in port 80 between sites, and only hit port 1434 locally? How do you know which traffic is good and which traffic is evil? At least today, we can decide that 92 byte ICMP echo-request packets are invalid, and drop them; or that for the most part, packets destined to port 1434 should be discarded as quickly as possible. How does you IS know that a _particular_ ES uses port 1434 for? Alex
Re: [arin-announce] IPv4 Address Space (fwd)
On Wed, 29 Oct 2003, Alex Yuriev wrote: As the network operators, we move bits and that is what we should stick to moving. We do not look into packets and see oh look, this to me looks like an evil application traffic, and we should not do that. It should not be the goal of IS to enforce the policy for the traffic that passes through it. That type of enforcement should be left to ES. Well, that is nice thery, but I'd like to see how you react to 2Gb DoS attack and if you really intend to put filters at the edge or would not prefer to do it at the entrance to your network. Slammer virus is just like DoS, that is why many are filtering it at the highiest possible level as well as at all points where traffic comes in from the customers. Actually, no, it is not theory. When you are slammed with N gigabits/sec of traffic hitting your network, if you do not have enough capacity to deal with the attack, no amount of filtering will help you, since by the time you apply a filter it is already too late - the incoming lines have no place for non-evil packets. Leave content filtering to the ES, and *force* ES to filter the content. Let IS be busy moving bits. Alex
Verio outage
There is a aparently a major outage in Verio-land between Boston and Baltiore, touch as far away as Pitts. Alex
Re: Block all servers?
Also what about folks who need to VPN in to their office (either via PPTP or IPSEC)? How would you take care of that situation? IPSEC works over NATs just fine. Alex
Re: large-scale IPSEC tunnel deployment
Orchestream has some of this functionality for setting the tunnels up, you can then use the corba interface to setup management with tools like SMARTS. The other problem is managing the keys, if you don't have a CA it will be painful if you need to change the keys. We have had some success with RSA's CA platform and IOS on this. Since you are saying some success would you mind elaborating on what did not work well with IOS? Thanks, Alex
large-scale IPSEC tunnel deployment
Hello, Does anyone have any experience with large scale production IPSEC tunnel deployment, where large scale is defined as over 100 net-to-net tunnels to different destination networks active at any time? If so, would such person(s) mind sharing any quirks/platforms/implementations for more or less automated topology testing/verification? Thanks, Alex
