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
Cogent's claim of MFN fiber issues between PHL and DCA
Hello, Can anyone confirm claims from Cogent that there is an MFN fiber issue between PHL and DCA that creates 10-15% packet loss? Simple test are pointing at the Cogtent not having enough capacity between PHL and DCA. According to Cogent that issue had been happening for several days now. 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
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
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
> 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
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
> >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
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: 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 S&D 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: 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: [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: 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)
> 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: [arin-announce] IPv4 Address Space (fwd)
> > It is content filtering. You are filtering packets that you think are > > causing problems to the ES that you may not control. > > No, he said quite clearly he's filtering packets (such as Nachi ICMP) that are > causing harm to *his* network. He gets to make a choice - filter the known > problem packets so the rest of the traffic can get through, or watch the > network melt down and nobody gets anything. He needs to fix his network so those 92 byte ICMP packets wont break it. Alex
more on filtering
> >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. > > So, electric grids do not have any mechanisms to disconnect from other > grids ( ie, stop "transiting" their electricity ) if one is doing something > that causes problems on the local grid? As a customer I would very > much like my provider to filter out waveforms that would prevent their > ability to provide me with my service. They disconnect the SOURCE of the problem forcing the SOURCE to behave. That is equivalent of forcing the ES to behave. > If the issue is how to communicate what is being filtered to the customer, > then simply need to find a way to do that. The solution to "it is hard to > communicate what is being filtered to the end-users" is not "oh well, > we won't filter anything". At least not as I see it. Traffic to port X cannot be specified as valid or invalid for any IS, because the IS does not know why such traffic exists. Traffic ES<->ES on port X can be valid or invalid because ES knows if it is valid traffic. If you want to filter that traffic, filter it for a specific ES (the one that does not want it) and force whoever is sending you that traffic to play nicely. It is DIFFERENT from saying "We drop all packets that match port X" > Supposing a network *did* provide a way to inform customers what was > being filtered. Would you still object to the filtering? If I request that traffic, of course I would object! > >Another excellent example - UPS will not remove that. The shipper will. > > How? I'm the shipper. I put the RF generating device into package and > give it to UPS. They will do nothing to remove it or not ship it? > It is only up to me to not do it? Al Qaeda would love that to be > true I'm sure. :) After that package is removed, you, the shipper, are going to have your hands slapped very hard, which will force you in future to behave. By doing this, we successfully enforced ES filtering. > >The first part of any legal agreement establishes the parties subject to it. > >That is exactly what you are missing while being an IS. > > There is a chain of agreements connecting you to the source/dest of > any traffic on your network. Even if it is a customer of a customer > of a customer, you have a chain of agreements that establishes you > as a party. > > In what scenario would there not be a chain of agreements to connect > you as a party? Even if I have agreement with you that you sell me a GSR for $5.00, which you have agreement with RS to get from him, I do not have agreement with RS that lets me get the GSR from him for $5. 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)
> 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)
> > 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
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: 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
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
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
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
Verizon DSL issues on east coast today?
I am seeing rather strange behaviour on VZ DSL starting from about midnight today, corresponding with 20% or so traffic drop in a few webfarms. The troubles start around lo0-0.CORE-RTR2.SYR.verizon-gni.net (130.81.4.10), and manifest themselves with large sections of the internet (including places such as usatoday) non-resolving, while other location's generate very funny traceroutes that indicate packets are being filtered, while the ssh sessions happily stay up. Alex
