Re: Email over v6
On 8 Jul 2010, at 03:00, Antonio Querubin wrote: On Wed, 7 Jul 2010, Zaid Ali wrote: Are there any folks here who would be inclined to do SMTP over IPv6? I have a test v6 network with is ready to do email but getting some real world data to verify headers would be more helpful. Please send me an email offlist if you are interested. The NANOG list mail server is IPv6-enabled. Your above message came into our mail server over IPv6. So by just using this list you'll be testing your mailserver over IPv6. So for example here's Antonio's reply header going to the list over v6 transport then out to our site also by v6: Received: from s0.nanog.org (s0.nanog.org [2001:48a8:6880:95::20]) by crow.ecs.soton.ac.uk (crow.ecs.soton.ac.uk [2001:630:d0:f110::25b]) envelope-from nanog-bounces+tjc=ecs.soton.ac...@nanog.org with ESMTP id m673381995435214jA ret-id none; Thu, 08 Jul 2010 03:03:19 +0100 Received: from localhost ([::1] helo=s0.nanog.org) by s0.nanog.org with esmtp (Exim 4.68 (FreeBSD)) (envelope-from nanog-boun...@nanog.org) id 1OWgRQ-000HxK-8m; Thu, 08 Jul 2010 02:02:20 + Received: from outgoing03.lava.net ([2001:1888:0:1:202:b3ff:fe1d:6b98]) by s0.nanog.org with esmtp (Exim 4.68 (FreeBSD)) (envelope-from t...@lava.net) id 1OWgPi-000G1S-Si for nanog@nanog.org; Thu, 08 Jul 2010 02:00:35 +
Re: Email over v6
On Thu, 8 Jul 2010, Tim Chown wrote: Received: from s0.nanog.org (s0.nanog.org = [2001:48a8:6880:95::20]) by crow.ecs.soton.ac.uk (crow.ecs.soton.ac.uk = [2001:630:d0:f110::25b]) envelope-from = nanog-bounces+tjc=3decs.soton.ac...@nanog.org with ESMTP id = m673381995435214jA ret-id none; Thu, 08 Jul 2010 03:03:19 +0100 Received: from localhost ([::1] helo=3Ds0.nanog.org) by = s0.nanog.org with esmtp (Exim 4.68 (FreeBSD)) (envelope-from = nanog-boun...@nanog.org) id 1OWgRQ-000HxK-8m; Thu, 08 Jul 2010 = 02:02:20 + Received: from outgoing03.lava.net = ([2001:1888:0:1:202:b3ff:fe1d:6b98]) by s0.nanog.org with esmtp (Exim = 4.68 (FreeBSD)) (envelope-from t...@lava.net) id 1OWgPi-000G1S-Si for = nanog@nanog.org; Thu, 08 Jul 2010 02:00:35 + One other thing I also notice is that there is a high correlation between use of TLS and IPv6, I guess a lot of people with IPv6 clue also enable TLS: Received: from s0.nanog.org (s0.nanog.org [IPv6:2001:48a8:6880:95::20]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by uplift.swm.pp.se (Postfix) with ESMTPS id F1B959F for swm...@swm.pp.se; Thu, 8 Jul 2010 09:10:41 +0200 (CEST) -- Mikael Abrahamssonemail: swm...@swm.pp.se
Re: U.S. Plans Cyber Shield for Utilities, Companies
On Thu, Jul 8, 2010 at 1:16 AM, Michael Painter tvhaw...@shaka.com wrote: Have we all gone mad? I find it hard to understand that a nuclear power plant, air-traffic control network, or electrical grid would be 'linked' to the Internet in the interest of 'efficiency'. Air gap them all and let them apply for Inefficiency Relief from the $100 million relief fund. Efficiency in this context refers to the nuke plant operator checking his email and playing games online. It is not efficient to have him use one computer for the power plant and one for his personal use. /sarcasm
Re: U.S. Plans Cyber Shield for Utilities, Companies
On Wed, 7 Jul 2010, Michael Painter wrote: Have we all gone mad? I find it hard to understand that a nuclear power plant, air-traffic control network, or electrical grid would be 'linked' to the Internet in the interest of 'efficiency'. Air gap them all and let them apply for Inefficiency Relief from the $100 million relief fund. Absolutely! For example, those thousands of flight plans filed every day by airlines across the globe, not to mention private flights, should be done manually the old fashioned way, with a paper form and stopping by your local FAA office where a human keys them into the ATC computer. Oh wait, we closed all of those offices when we moved all of those functions to the Internet. I guess we'll just have to re-open them. And flight tracking data that airlines and freight companies use to track their aircraft, yea, let's cut those off too. If they want to know where their plane is, just have them call the FAA. Surely the government can staff some huge call centers to handle the load of each airline calling about each flight every few minutes. Heck, removing all of these functions from the Internet will create jobs, too, right? And no one would mind paying for all of this out of their airline tickets, it should only increase fares by a third or so. -- Brandon Ross AIM: BrandonNRoss ICQ: 2269442 Skype: brandonross Yahoo: BrandonNRoss
Re: U.S. Plans Cyber Shield for Utilities, Companies
On Wed, 7 Jul 2010, Michael Painter wrote: Have we all gone mad? I find it hard to understand that a nuclear power plant, air-traffic control network, or electrical grid would be 'linked' to the Internet in the interest of 'efficiency'. Air gap them all and let them apply for Inefficiency Relief from the $100 million relief fund. Absolutely! For example, those thousands of flight plans filed every day by airlines across the globe, not to mention private flights, should be done manually the old fashioned way, with a paper form and stopping by your local FAA office where a human keys them into the ATC computer. Oh wait, we closed all of those offices when we moved all of those functions to the Internet. I guess we'll just have to re-open them. And flight tracking data that airlines and freight companies use to track their aircraft, yea, let's cut those off too. If they want to know where their plane is, just have them call the FAA. Surely the government can staff some huge call centers to handle the load of each airline calling about each flight every few minutes. Heck, removing all of these functions from the Internet will create jobs, too, right? And no one would mind paying for all of this out of their airline tickets, it should only increase fares by a third or so. There's a happy medium in there somewhere; it's not clear that having (to use the examples given) air traffic control computers directly on the Internet has sufficient value to outweigh the risks. However, it seems that being able to securely gateway appropriate information between the two networks should be manageable, certainly a lot more manageable than the NxM complexity involved if you try to do it by securing each and every Internet-connected ATC PC individually. It sucks in some ways, but providing a limited number of pathways in that are under tight, secure control is a desirable goal. If you give the PC that allows control of the power grid access to the Internet so that the operator can efficiently update his Facebook while he's simultaneously controlling the power grid, that's hazardous, and no amount of snide remarks about job creation will change that reality. These networks ought to be air gapped to the maximum reasonable extent possible; all pathways in ought to be defended as though they were the gateway to the kingdom. ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again. - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples.
Re: U.S. Plans Cyber Shield for Utilities, Companies
On Wed, 07 Jul 2010 19:16:27 -1000, Michael Painter said: I find it hard to understand that a nuclear power plant, air-traffic control network, or electrical grid would be 'linked' to the Internet in the interest of 'efficiency'. Air gap them all and let them apply for Inefficiency Relief from the $100 million relief fund. OK, so you airgap the whole thing, and apply for Inefficiency Relief to help pay for those 2,397 separate dark fiber dedicated links you need to contact your 2,397 remote sensing stations and control points. And of course, since you end up burning a *lot* of dark fiber pairs when every utility starts doing that, the provider gets to go back and put a whole lot more 96-pair or whatever alongside the previous bundle, driving prices back up after our long-term fiber glut. And then you discover that your actual network reliability goes *down*, because getting your provider to troubleshoot your measly 64K channel is a pain and takes a long time to get results - whereas if you went commodity Internet your packets are now mixed in with everybody else's on a important 10GE link. Sure, that 10GE link may be just 2 fibers over in the same bundle - but guess which one will probably be spliced first after the backhoe hits? (Plus of course, if 37 of those 2,397 links were in the bundle, it's going to take 37 splices to get you 100% back up, instead of just one splice) What's the going rate these days that you have to pay to make sure your fiber gets spliced first rather than that other customer's 10GE? And what's it cost to do it for all 2,397 links? And if your electrical-grid fiber is in the same cable as the other customer's ATC cable, who gets spliced first? If you have a single point of failure in your design, you really want to make sure that the point is heavily fate-shared with enough other customers that the provider will feel *really* motivated to fix your problem. ;) pgpuxYyEof2K0.pgp Description: PGP signature
Re: U.S. Plans Cyber Shield for Utilities, Companies
On Jul 8, 2010, at 10:12 AM, valdis.kletni...@vt.edu wrote: What's the going rate these days that you have to pay to make sure your fiber gets spliced first rather than that other customer's 10GE? And what's it cost to do it for all 2,397 links? And if your electrical-grid fiber is in the same cable as the other customer's ATC cable, who gets spliced first? http://tsp.ncs.gov/
Re: U.S. Plans Cyber Shield for Utilities, Companies
On Jul 8, 2010, at 10:12 AM, valdis.kletni...@vt.edu wrote: On Wed, 07 Jul 2010 19:16:27 -1000, Michael Painter said: I find it hard to understand that a nuclear power plant, air- traffic control network, or electrical grid would be 'linked' to the Internet in the interest of 'efficiency'. Air gap them all and let them apply for Inefficiency Relief from the $100 million relief fund. OK, so you airgap the whole thing, and apply for Inefficiency Relief to help pay for those 2,397 separate dark fiber dedicated links you need to contact your 2,397 remote sensing stations and control points. And of course, since you end up burning a *lot* of dark fiber pairs when every utility starts doing that, the provider gets to go back and put a whole lot more 96-pair or whatever alongside the previous bundle, driving prices back up after our long- term fiber glut. I think that there needs to be a balance. There is no Internet access to certain military systems, for example, but that doesn't mean that the base housing them has no Internet access. I would expect the same to be true for, e.g., nuclear power systems. If this has never been thought through by someone, it would not be a bad idea to start now. On the other hand, my friends in military networking tend to be cynical about these kinds of exercises. They may or may not actually increase security, in fact they sometimes degrade it, but they tend to be very good at sending money to politically well connected contractors. Regards Marshall And then you discover that your actual network reliability goes *down*, because getting your provider to troubleshoot your measly 64K channel is a pain and takes a long time to get results - whereas if you went commodity Internet your packets are now mixed in with everybody else's on a important 10GE link. Sure, that 10GE link may be just 2 fibers over in the same bundle - but guess which one will probably be spliced first after the backhoe hits? (Plus of course, if 37 of those 2,397 links were in the bundle, it's going to take 37 splices to get you 100% back up, instead of just one splice) What's the going rate these days that you have to pay to make sure your fiber gets spliced first rather than that other customer's 10GE? And what's it cost to do it for all 2,397 links? And if your electrical-grid fiber is in the same cable as the other customer's ATC cable, who gets spliced first? If you have a single point of failure in your design, you really want to make sure that the point is heavily fate-shared with enough other customers that the provider will feel *really* motivated to fix your problem. ;)
Re: U.S. Plans Cyber Shield for Utilities, Companies
valdis.kletni...@vt.edu wrote: What's the going rate these days that you have to pay to make sure your fiber gets spliced first rather than that other customer's 10GE? I'm not familiar with cable break splicing procedures, but is it even possible to pay extra to have your splice done first? I would think that the logistics of splicing are such that the guy down in the hole doesn't know whose traffic is on each strand in the bundle, and his job is just to splice them as he matches them (using color codes or similar on the sheaths of the individual strands) as fast as he can. Trying to identify a specific strand and then splicing it first would greatly slow down the task of splicing them all. If you have more than 1 strand that needs to get spliced first it would likely take longer to identify these special customers and get them done first than to just splice with no priority and get the whole bundle done. jc
Re: U.S. Plans Cyber Shield for Utilities, Companies
I find it hard to understand that a nuclear power plant, air-traffic control network, or electrical grid would be 'linked' to the Internet in the interest of 'efficiency'. The Davis-Besse nuclear generating station computers were hit by the SQL Slammer / Saphire worm back in 2003. http://www.theregister.co.uk/2003/08/20/slammer_worm_crashed_ohio_nuke/ The utility claims that there was never a risk, but take that with a grain of salt since this is the same utility that conveniently managed to overlook a hole the size of a book in the reactor head for several years. Cheers, Michael Holstein Cleveland State University
Re: U.S. Plans Cyber Shield for Utilities, Companies
On Thu, 08 Jul 2010 08:12:29 PDT, JC Dill said: valdis.kletni...@vt.edu wrote: What's the going rate these days that you have to pay to make sure your fiber gets spliced first rather than that other customer's 10GE? I'm not familiar with cable break splicing procedures, but is it even possible to pay extra to have your splice done first? I would think that the logistics of splicing are such that the guy down in the hole doesn't know whose traffic is on each strand in the bundle Exactly - which is a case for just having everybody's traffic mingled on a very busy 12-pair rather than several 96-pair with lots of dedicated links, *everybody* ends up back in service a lot faster... And remember - this industry has more trouble with backhoes and would-be copper thieves than terrorists. Anybody who is defending against terrorists by increasing their vulnerability to backhoes is, well... pgpM7bM7jKrVD.pgp Description: PGP signature
Re: U.S. Plans Cyber Shield for Utilities, Companies
In a message written on Thu, Jul 08, 2010 at 08:12:29AM -0700, JC Dill wrote: I'm not familiar with cable break splicing procedures, but is it even possible to pay extra to have your splice done first? I would think that the logistics of splicing are such that the guy down in the hole doesn't know whose traffic is on each strand in the bundle, and his job is just to splice them as he matches them (using color codes or similar on the sheaths of the individual strands) as fast as he can. Trying to identify a specific strand and then splicing it first would greatly slow down the task of splicing them all. If you have more than 1 strand that needs to get spliced first it would likely take longer to identify these special customers and get them done first than to just splice with no priority and get the whole bundle done. In the simple case of a fiber cut and repair (the proverbial errant backhoe) you're pretty much correct. The tech splices the cable in the obvious to fix order (typically by color code). I suspect you could try and be lower in the color code, but in practical terms once they get going there is not much time difference first to last. There are more complicated cases though; consider the Baltimore tunnel fire years ago. Restoration required running several km of new fiber on a temporary route, and most importantly troubleshooting if that did anything bad to anyone (e.g. put them over their distance budget). It is entirely possible to be moved to the front of the I need help queue in those situations. In most cases, if you care about paying lots of money to be first you have enough money to buy an actually physically diverse route, and it's a non-issue though -- Leo Bicknell - bickn...@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ pgp0glpQpyImg.pgp Description: PGP signature
Re: U.S. Plans Cyber Shield for Utilities, Companies
Michael Painter wrote: Have we all gone mad? I find it hard to understand that a nuclear power plant, air-traffic control network, or electrical grid would be 'linked' to the Internet in the interest of 'efficiency'. Air gap them all and let them apply for Inefficiency Relief from the $100 million relief fund. What's hard to understand about mobility. Sure the HMI, RTU's etc are NOT connected to the public Internet however, they ARE networked. All a company needs is one client side attack to give an outsider the same level of access as an insider and it's checkmate. @Jared's TSP link... Wonder how this will affect VoIP ITSP's etal, e.g., how many local NS/EP's have swapped over to VoIP. Logically, anyone with a network running a managed VoIP service, trunk, etc., could qualify. @Fiber splicing ... Let the NSA handles this (http://www.zdnet.com/news/spy-agency-taps-into-undersea-cable/115877) -- =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ J. Oquendo SGFA, SGFE, C|EH, CNDA, CHFI, OSCP, CPT It takes 20 years to build a reputation and five minutes to ruin it. If you think about that, you'll do things differently. - Warren Buffett 227C 5D35 7DCB 0893 95AA 4771 1DCE 1FD1 5CCD 6B5E http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0x5CCD6B5E
Re: Email over v6
On 7/8/10 1:20 AM, Mikael Abrahamsson wrote: On Thu, 8 Jul 2010, Tim Chown wrote: One other thing I also notice is that there is a high correlation between use of TLS and IPv6, I guess a lot of people with IPv6 clue also enable TLS: By default, at least on Debian, TLS and IPv6 (if available, even if only using link local addresses) are on by default, so there's not too much that needs to be done to use TLS on the SMTP side. -- Brielle Bruns The Summit Open Source Development Group http://www.sosdg.org/ http://www.ahbl.org
Re: U.S. Plans Cyber Shield for Utilities, Companies
On Thu, 8 Jul 2010, Joe Greco wrote: There's a happy medium in there somewhere; it's not clear that having (to use the examples given) air traffic control computers directly on the Internet has sufficient value to outweigh the risks. However, it seems that being able to securely gateway appropriate information between the two networks should be manageable, certainly a lot more manageable than the NxM complexity involved if you try to do it by securing each and every Internet-connected ATC PC individually. What makes you think that isn't exactly what this Cyber Shield project is supposed to do? Heck, what makes you think that's not the way most of these systems already work today? Do people really think the guy in the airport control tower is really surfing Facebook while he's controlling aircraft on the same computer, or that capability is even what is under consideration? -- Brandon Ross AIM: BrandonNRoss ICQ: 2269442 Skype: brandonross Yahoo: BrandonNRoss
Re: U.S. Plans Cyber Shield for Utilities, Companies
On Thu, Jul 08, 2010 at 09:51:52AM -0400, Brandon Ross wrote: On Wed, 7 Jul 2010, Michael Painter wrote: Have we all gone mad? Absolutely! For example, those thousands of flight plans filed every day by airlines across the globe, not to mention private flights, should be done manually the old fashioned way, with a paper form and stopping by your local FAA office where a human keys them into the ATC computer. Oh wait, we closed all of those offices when we moved all of those functions to the Internet. I guess we'll just have to re-open them. yeah! jobs for americans! actually, the interesting questions raised are along the lines of what is your contingency plan? ... the big EMP is coming. Heck, removing all of these functions from the Internet will create jobs, too, right? And no one would mind paying for all of this out of their airline tickets, it should only increase fares by a third or so. -- Brandon Ross AIM: BrandonNRoss ICQ: 2269442 Skype: brandonross Yahoo: BrandonNRoss
Re: U.S. Plans Cyber Shield for Utilities, Companies
Brandon Ross wrote: Do people really think the guy in the airport control tower is really surfing Facebook while he's controlling aircraft on the same computer, or that capability is even what is under consideration? Air traffic controller suspended for allowing son to radio instructions to pilots at New York's Kennedy Airport http://www.dallasnews.com/sharedcontent/dws/dn/latestnews/stories/030410dnnatairtraffic.170a785b7.html Air traffic controller suspended, was chatting on phone with girlfriend during Hudson River crash http://www.nydailynews.com/ny_local/2009/08/13/2009-08-13_air_traffic_controller__on_phone_with_girlfriend__an_supervisor_suspended_over_h.html Huh? ... Scary isn't it: Pilots were working on laptops when plane overflew Minneapolis destination http://www.japantoday.com/category/world/view/wayward-pilots-were-working-on-their-laptops-when-plane-overflew-minneapolis-destination There is that capability however, you may be looking at it from a different perspective. It's easy enough to plop open an iPhone for Internet usage. I'm almost positive there are no smart phone policies in an Air Traffic Control tower. -- =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ J. Oquendo SGFA, SGFE, C|EH, CNDA, CHFI, OSCP, CPT It takes 20 years to build a reputation and five minutes to ruin it. If you think about that, you'll do things differently. - Warren Buffett 227C 5D35 7DCB 0893 95AA 4771 1DCE 1FD1 5CCD 6B5E http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0x5CCD6B5E
Re: U.S. Plans Cyber Shield for Utilities, Companies
On Thu, 8 Jul 2010, J. Oquendo wrote: Brandon Ross wrote: Do people really think the guy in the airport control tower is really surfing Facebook while he's controlling aircraft on the same computer, or that capability is even what is under consideration? Air traffic controller suspended for allowing son to radio instructions to pilots at New York's Kennedy Airport http://www.dallasnews.com/sharedcontent/dws/dn/latestnews/stories/030410dnnatairtraffic.170a785b7.html Please read critically before replying. My exact quote included the words on the same computer. The article that started this thread is about protecting critical systems, not preventing people from making stupid mistakes. If you want to talk about ATC procedures or the misbehavior of controllers using unapproved devices, there's a whole separate mailing list for that. -- Brandon Ross AIM: BrandonNRoss ICQ: 2269442 Skype: brandonross Yahoo: BrandonNRoss
Re: Email over v6
On Thu, 8 Jul 2010, Brielle Bruns wrote: By default, at least on Debian, TLS and IPv6 (if available, even if only using link local addresses) are on by default, so there's not too much that needs to be done to use TLS on the SMTP side. TLS wasn't enabled on my Debian using Postfix, so I guess it depends on more factors than just running Debian. IPv6 seems to be on by default, yes. -- Mikael Abrahamssonemail: swm...@swm.pp.se
Re: U.S. Plans Cyber Shield for Utilities, Companies
andrew.wallace wrote: Article: http://online.wsj.com/article/SB10001424052748704545004575352983850463108.html My opinion: http://online.wsj.com/article/SB10001424052748704545004575352983850463108.html#articleTabs%3Dcomments%26commentId%3D1330685 Politifact has an interesting article on the cyber police topic: http://www.politifact.com/truth-o-meter/statements/2010/jul/06/andrew-napolitano/glenn-beck-host-says-obama-may-soon-be-able-shut-d/ Politifact says that it is technologically possible for Internet Service Providers (ISPs) to significantly limit the flow of Internet traffic because the network operator community is fairly tight-knit, so it is conceivable that (network operators) could coordinate a response to a major event and terminate basic connectivity within a matter of minutes. Network operators who maintain the Internet backbone share cell phone information, have regular meetings, and often work together through established channels in emergencies. (The have regular meetings text is a link to nanog.org) jc **
RE: U.S. Plans Cyber Shield for Utilities, Companies
-Original Message- From: Brandon Ross Sent: Thursday, July 08, 2010 6:52 AM To: Michael Painter Cc: nanog@nanog.org Subject: Re: U.S. Plans Cyber Shield for Utilities, Companies On Wed, 7 Jul 2010, Michael Painter wrote: Have we all gone mad? I find it hard to understand that a nuclear power plant, air-traffic control network, or electrical grid would be 'linked' to the Internet in the interest of 'efficiency'. Air gap them all and let them apply for Inefficiency Relief from the $100 million relief fund. Absolutely! For example, those thousands of flight plans filed every day by airlines across the globe, not to mention private flights, should be done manually the old fashioned way, with a paper form and stopping by your local FAA office where a human keys them into the ATC computer. Oh wait, we closed all of those offices when we moved all of those functions to the Internet. I guess we'll just have to re-open them. I believe the point was in response to: control systems that were often designed without Internet connectivity or security in mind. Many of those systems-which run everything from subway systems to air-traffic control networks-have since been linked to the Internet If something was designed without network security in mind and then connected to the internet as-is, then yeah, that pretty much is not only madness but is just asking for trouble. So I am torn between this being another exercise in treating the symptoms while ignoring the underlying cause and at least having SOMEONE watching the front door if the owners aren't paying any attention themselves. But I would think the cost of the program could be scaled back somewhat if certain basic security practices were mandated prior to the system being installed.
Re: U.S. Plans Cyber Shield for Utilities, Companies
On Jul 8, 2010, at 9:00 AM, Brandon Ross wrote: On Thu, 8 Jul 2010, Joe Greco wrote: There's a happy medium in there somewhere; it's not clear that having (to use the examples given) air traffic control computers directly on the Internet has sufficient value to outweigh the risks. However, it seems that being able to securely gateway appropriate information between the two networks should be manageable, certainly a lot more manageable than the NxM complexity involved if you try to do it by securing each and every Internet-connected ATC PC individually. What makes you think that isn't exactly what this Cyber Shield project is supposed to do? Heck, what makes you think that's not the way most of these systems already work today? Do people really think the guy in the airport control tower is really surfing Facebook while he's controlling aircraft on the same computer, or that capability is even what is under consideration? In fact, I know he isn't. For one thing, the guys in the towers generally do not use computers at all. Yes, some towers have RADAR displays that are actually generated by computer, but, they are essentially read-only and they are not general purpose computers with web browsers, internet connectivity, or even a keyboard for that matter. However, the guys in the tower primarily use binoculars, mark 1 eyeballs, flight progress strips, and a lot of ingenuity to control aircraft within the class D/C/B airspace immediately surrounding their airport (the local controller) and the aircraft on the ground (the ground controller). In some cases, clearance delivery is using a computer, but, technically, he's not controlling aircraft, just in the tower for communication convenience. Now, if you wanted to talk about a TRACON or ARTCC, we might (MIGHT) get into a different realm. In the TRACON, mostly not. Those controllers are generally also working specialized scopes to control aircraft within the airspace around some of the busier airports below about 12,000 feet. In the ARTCC (commonly referred to as Center) case, mostly they are using similar equipment to the TRACON, but, have wider areas of coverage with lower traffic densities and coverage up to 60,000 feet (Flight level 600). The exception would be the guys working some of the oceanic sectors who depend on email (yes, email) to receive position reports and other data from pilots via ARINC, and, to send instructions to AIRINC to relay to pilots. However, to the best of my knowledge, even that email based system is not connected to the internet and the controllers that are doing that are not doing anything else while they are doing that. I know this from being a pilot, and, also from having toured the following ATC facilities: Towers: CCR PAO SFO TRACONs: SOCAL Bay -- Now defunct, rolled into NORCAL NORCAL Monterey -- Now defunct, rolled into NORCAL Stockton -- Now defunct, rolled into NORCAL ARTCCs: ZOA (Oakland Center) Owen
Re: U.S. Plans Cyber Shield for Utilities, Companies
On 7/8/2010 9:51 AM, Brandon Ross wrote: On Wed, 7 Jul 2010, Michael Painter wrote: Have we all gone mad? I find it hard to understand that a nuclear power plant, air-traffic control network, or electrical grid would be 'linked' to the Internet in the interest of 'efficiency'. Air gap them all and let them apply for Inefficiency Relief from the $100 million relief fund. Heck, removing all of these functions from the Internet will create jobs, too, right? And no one would mind paying for all of this out of their airline tickets, it should only increase fares by a third or so. You know it is possible, mind you, possible to have control systems for things like the power grid and nuclear power plants to live on a physically separate network within a building from a terminal that has the internet connected to it. --C
Re: U.S. Plans Cyber Shield for Utilities, Companies
On Jul 8, 2010, at 10:13 AM, George Bonser wrote: -Original Message- From: Brandon Ross Sent: Thursday, July 08, 2010 6:52 AM To: Michael Painter Cc: nanog@nanog.org Subject: Re: U.S. Plans Cyber Shield for Utilities, Companies On Wed, 7 Jul 2010, Michael Painter wrote: Have we all gone mad? I find it hard to understand that a nuclear power plant, air-traffic control network, or electrical grid would be 'linked' to the Internet in the interest of 'efficiency'. Air gap them all and let them apply for Inefficiency Relief from the $100 million relief fund. Absolutely! For example, those thousands of flight plans filed every day by airlines across the globe, not to mention private flights, should be done manually the old fashioned way, with a paper form and stopping by your local FAA office where a human keys them into the ATC computer. Oh wait, we closed all of those offices when we moved all of those functions to the Internet. I guess we'll just have to re-open them. I believe the point was in response to: control systems that were often designed without Internet connectivity or security in mind. Many of those systems-which run everything from subway systems to air-traffic control networks-have since been linked to the Internet If something was designed without network security in mind and then connected to the internet as-is, then yeah, that pretty much is not only madness but is just asking for trouble. So I am torn between this being another exercise in treating the symptoms while ignoring the underlying cause and at least having SOMEONE watching the front door if the owners aren't paying any attention themselves. But I would think the cost of the program could be scaled back somewhat if certain basic security practices were mandated prior to the system being installed. I think part of the problem comes from interrelationships between the transitive property of trust (if A trusts B and B trusts C, then A trusts C whether A knows it or not) and the perceived vs. actual nature of linkage. For example, it would seem madness to put an HTTP server directly on the primary Air Traffic Scheduling System at FAA Central and have it collect flight plans directly from the internet. However, what happens is that FAA contracts Lockheed out to run several Automated Flight Service Stations and also contracts two other companies (GTE and CONTEL last I looked at who had the contracts) to run a service known as Direct User Access Terminals or DUATS. Lockheed runs their own systems and interacts with pilots by telephone and radio. Flight Plans and Pilot Reports collected by Lockheed are put into Lockheed systems which are then linked into the FAA systems. I do not know if any of those links involve internet connectivity or not. LIkely some do. The DUATS systems also link into the FAA computers for uploading flight plans and pilot reports and for getting weather and NOTAM information from the FAA. As such, at least on some level, the FAA systems are linked to systems that are linked to the internet and there definitely isn't an air-gap. I suspect it is a full enough form of proxy that only data can traverse from one to the other. I think the design of the systems is probably relatively sane on that level. However, I doubt anyone on this list really knows for sure how the systems were designed or the exact nature of their linkages and I suspect there are many many other examples of such indirect linkages that have grown organically over time as the internet has moved from scientific novelty to a place to distribute web access and now starts to become the fundamental basis for communication among humans, machines, and others throughout the world. There used to be a clear line between telecom and datacom. It used to be that the internet was clearly datacom. Today, it's almost as if telecom as a separate discipline is going away and instead voice is becoming an application on the datacom network. It used to be that datacom was many disparate specialized networks each serving a particular datacom purpose. Today, the internet has become the generic low-level building block upon which virtually every datacom application, including the new telecom (voice as an application on a data network) is being built. With these changes and their relationships to legacy systems come new security concerns. Some known, many likely not even noticed as things move forward. Owen
Re: U.S. Plans Cyber Shield for Utilities, Companies
Owen DeLong wrote: [snip] I know this from being a pilot, and, also from having toured the following ATC facilities: Towers: TRACONs: ARTCCs: Ditto to absolutely EVERYTHING that Owen said, and I can guarantee this further, having had experience with various east coast and southeastern Towers, TRACONs, and ARTCCs (and having fond memories of it all). Personally, I'm more concerned about Cisco Security Advisory: Hard-Coded SNMP Community Names in Cisco Industrial Ethernet 3000 Series Switches Vulnerability than worrying about whatever the latest scary headline from n3td3v (aka andrew wallace) is. -- All men whilst they are awake are in one common world: but each of them, when he is asleep, is in a world of his own. Plutarch
Re: Email over v6
On 7/8/10 11:04 AM, Mikael Abrahamsson wrote: On Thu, 8 Jul 2010, Brielle Bruns wrote: By default, at least on Debian, TLS and IPv6 (if available, even if only using link local addresses) are on by default, so there's not too much that needs to be done to use TLS on the SMTP side. TLS wasn't enabled on my Debian using Postfix, so I guess it depends on more factors than just running Debian. IPv6 seems to be on by default, yes. Exim tends to be the default installed MTA from everything i've seen, and its TLS configuration is done as part of the split config method they use - check /etc/exim4/conf.d/main/03_exim4-config_tlsoptions I can't speak for anything other then what I see on default installs - given I only use exim myself, no real experience with postfix beyond my ISPConfig3 server. -- Brielle Bruns The Summit Open Source Development Group http://www.sosdg.org/ http://www.ahbl.org
Re: U.S. Plans Cyber Shield for Utilities, Companies
On Jul 8, 2010, at 11:56 AM, J. Oquendo wrote: @Jared's TSP link... Wonder how this will affect VoIP ITSP's etal, e.g., how many local NS/EP's have swapped over to VoIP. Logically, anyone with a network running a managed VoIP service, trunk, etc., could qualify. This certainly is a frequent discussion point in some circles. A lot of carriers take your POTS/PRI and turn them into VoIP internally so they get the advantages of multiplexing the data on IP. This isn't universal, but a good question to ask your carrier. If you care about your call going through, you may actually want to pay a bit more and be on that more expensive TDM gear. Of course, whomever you call may also need to be on that same carrier. Take some time and research and test things out so you don't end up having trouble when you need your communications the most. You may also want to find your local HAM operator and buddy up with them, or get your no-code license today :) - Jared
Re: Email over v6
On 08/07/10 19:04 +0200, Mikael Abrahamsson wrote: On Thu, 8 Jul 2010, Brielle Bruns wrote: By default, at least on Debian, TLS and IPv6 (if available, even if only using link local addresses) are on by default, so there's not too much that needs to be done to use TLS on the SMTP side. TLS wasn't enabled on my Debian using Postfix, so I guess it depends on more factors than just running Debian. IPv6 seems to be on by default, yes. I can confirm that STARTTLS was enabled out of the box on my Debian unstable system... using the snakeoil cert of course. IPv6 (port 25 incoming) was not enabled out of the box. I needed to add inet_protocols = ipv4, ipv6 to enable it. -- Dan White
Re: U.S. Plans Cyber Shield for Utilities, Companies
On Thu, 8 Jul 2010, Joe Greco wrote: There's a happy medium in there somewhere; it's not clear that having (to use the examples given) air traffic control computers directly on the Internet has sufficient value to outweigh the risks. However, it seems that being able to securely gateway appropriate information between the two networks should be manageable, certainly a lot more manageable than the NxM complexity involved if you try to do it by securing each and every Internet-connected ATC PC individually. What makes you think that isn't exactly what this Cyber Shield project is supposed to do? Because I'm cynical and I know how the real world works, and even if it's supposed to do that, by the time all is said and done, it probably won't. Heck, what makes you think that's not the way most of these systems already work today? Because we've all been told by those in the know that there are real vulnerabilities in these systems. Do people really think the guy in the airport control tower is really surfing Facebook while he's controlling aircraft on the same computer, or that capability is even what is under consideration? The reality of what's actually going on can be debated pointlessly until we're blue in the face; none of us are in a position to know, I suspect. On the other hand, it takes a few milliseconds to recall an air traffic controller letting his kid land planes. http://tinyurl.com/2dzvooc So let's not be too naive here. Anything you expect can't happen - can and probably will at some point. The point is that we want to forcibly separate networks and technology so that an air traffic controller CANNOT possibly be surfing Facebook on a computer that's being used for critical work. ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again. - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples.
Re: U.S. Plans Cyber Shield for Utilities, Companies
On 7/8/2010 09:59, Marshall Eubanks wrote: I think that there needs to be a balance. I think it needs to be the purview of the custodian of the facility. Not some political wonk. -- Somebody should have said: A democracy is two wolves and a lamb voting on what to have for dinner. Freedom under a constitutional republic is a well armed lamb contesting the vote. Requiescas in pace o email Ex turpi causa non oritur actio Eppure si rinfresca ICBM Targeting Information: http://tinyurl.com/4sqczs http://tinyurl.com/7tp8ml
Re: Email over v6
On Jul 8, 2010, at 2:21 PM, Dan White wrote: On 08/07/10 19:04 +0200, Mikael Abrahamsson wrote: On Thu, 8 Jul 2010, Brielle Bruns wrote: By default, at least on Debian, TLS and IPv6 (if available, even if only using link local addresses) are on by default, so there's not too much that needs to be done to use TLS on the SMTP side. TLS wasn't enabled on my Debian using Postfix, so I guess it depends on more factors than just running Debian. IPv6 seems to be on by default, yes. I can confirm that STARTTLS was enabled out of the box on my Debian unstable system... using the snakeoil cert of course. IPv6 (port 25 incoming) was not enabled out of the box. I needed to add inet_protocols = ipv4, ipv6 to enable it. I figured I would share actual data for everyone here, roughly 1:4.22 messages that are handled by my system go over some sort of IPv6 transport. (excluding connections from itself-to-itself.. i should make these be IPv6) puck:~ grep sm-mta /var/log/maillog | grep IPv4 | grep -v 204.42.254.5 | wc -l 22696 puck:~ grep sm-mta /var/log/maillog | grep IPv6 | wc -l 5371 The technical community lists are good fodder for this data. (eg: nanog, *-nsp) I do wonder if gmail.com gives out addresses for their MX, and the same for other mail solutions. This seems like something that is a no-brainer for me, as latency on email isn't a big deal where for HTTP transactions it can be. - Jared
Re: U.S. Plans Cyber Shield for Utilities, Companies
On Jul 8, 2010, at 9:26 AM, valdis.kletni...@vt.edu wrote: I'm not familiar with cable break splicing procedures, but is it even possible to pay extra to have your splice done first? I would think that the logistics of splicing are such that the guy down in the hole doesn't know whose traffic is on each strand in the bundle Exactly - which is a case for just having everybody's traffic mingled on a very busy 12-pair rather than several 96-pair with lots of dedicated links, *everybody* ends up back in service a lot faster... And remember - this industry has more trouble with backhoes and would-be copper thieves than terrorists. Anybody who is defending against terrorists by increasing their vulnerability to backhoes is, well... Having done a good bit of manual copper and [old school fusion] fiber splicing for a few years as an outside plant monkey in the Army Signal Corp and a short stint thereafter as a contractor, I assure you that prioritization can make a significant different with large cable damage, in particular when single wire/pair splicing is done. Copper multi-pair splicing still allows specific bundles to be prioritized as well, sorta the same as fiber. Given that cuts and other damage usually requires splicing on two ends, some bit of coordination is required but mostly trivial, in particular with large copper cable (e.g., 2400 pair). Of course, in fairness to Valdis's comment, setup time on both ends is often the dominating factor, although bundle 1 to bundle 96 is an 2400 pair copper cable could be several hours or more. Of course, physical plant prioritization is only the dominating factor when last mile damage occurs. It's more useful and commonly employed when intermediate facility failures happen - prioritized regrooming of critical services is sometimes even automated, and often results in, err.. less critical services being booted until full restoration has occurred. -danny
Re: Email over v6
A few people have sent private replies commenting on the email/IPv6 deployment stats I posted. I thought I would also share some nameserver statistics to give an idea of what I see (at least at puck.nether.net) for IPv6 vs IPv4 queries. I won't break down the numbers for everyone, just posting the raw values from a bind stats dump. The stats are from ~June 21st to now. [View: _bind] ++ Name Server Statistics ++ 359127071 IPv4 requests received 6024171 IPv6 requests received ++ Resolver Statistics ++ [Common] 12966 mismatch responses received [View: default] 9028037 IPv4 queries sent 733851 IPv6 queries sent 8431489 IPv4 responses received 705457 IPv6 responses received ... 800617 IPv4 NS address fetches 807581 IPv6 NS address fetches 16773 IPv4 NS address fetch failed 759240 IPv6 NS address fetch failed [View: _bind (Cache: _bind)] ++ Socket I/O Statistics ++ 9047706 UDP/IPv4 sockets opened 741832 UDP/IPv6 sockets opened 73995 TCP/IPv4 sockets opened 1362 TCP/IPv6 sockets opened 9047703 UDP/IPv4 sockets closed 741831 UDP/IPv6 sockets closed 91701 TCP/IPv4 sockets closed 1569 TCP/IPv6 sockets closed 1421 UDP/IPv4 socket bind failures 10 UDP/IPv6 socket bind failures 10718 TCP/IPv4 socket connect failures 632 TCP/IPv6 socket connect failures 9025101 UDP/IPv4 connections established 733586 UDP/IPv6 connections established 63200 TCP/IPv4 connections established 729 TCP/IPv6 connections established 17709 TCP/IPv4 connections accepted 208 TCP/IPv6 connections accepted 29998 UDP/IPv4 recv errors 6842 UDP/IPv6 recv errors 1055 TCP/IPv4 recv errors
Rate Limiting on Cisco Router
Thanks again for all the responses to my previous post. We have a Cisco 7206VXR router with IOS of 12.4(12) and a PA-POS-1OC3 card ofr our OC3. The problem we have now is that we are only paying for 80 MB/s of the OC-3, and the ISP is leaving the capping of it up to us. I have googled and the only things I can find is that you can not do a real cap on this type of interface. We have tried the rate-limit command with various parameters and we are unable to keep it at 80. I have read that this is not the correct way to do it, but I'm not sure what is. Any advice? Pointers appreciated. -- Alan Bryant | Systems Administrator Gtek Computers Wireless, LLC. a...@gtekcommunications.com | www.gtek.biz O 361-777-1400 | F 361-777-1405
Re: Rate Limiting on Cisco Router
On Thu, 8 Jul 2010, Alan Bryant wrote: We have tried the rate-limit command with various parameters and we are unable to keep it at 80. I have read that this is not the correct way to do it, but I'm not sure what is. What burst parameters are you using? Try something along the lines of: rate-limit input 8000 1500 1500 conform-action transmit exceed-action drop rate-limit output 8000 1500 1500 conform-action transmit exceed-action drop on your OC3 interface. Antonio Querubin 808-545-5282 x3003 e-mail/xmpp: t...@lava.net
Re: Rate Limiting on Cisco Router
On Thu, 8 Jul 2010, Alan Bryant wrote: The problem we have now is that we are only paying for 80 MB/s of the OC-3, and the ISP is leaving the capping of it up to us. I have BTW, rate-limiting of traffic that the ISP router sends to your router is best done at the ISP router. Antonio Querubin 808-545-5282 x3003 e-mail/xmpp: t...@lava.net
re: Rate Limiting on Cisco Router
That's strange, Are you paying for a CIR of 80Mb/s? Normally they only leave the limiting up to you if its more of a burstable connection, Like you pay for 80Mb/s but its a full line rate interface and its billed per Mb/s over 80 on a 95th percentile scheme. If that is the case you can safely go over 80Mb/s for a certian amount of time per month, Assuming its billed monthly. Nick Olsen Network Operations (321) 205-1100 x106 From: Alan Bryant a...@gtekcommunications.com Sent: Thursday, July 08, 2010 6:07 PM To: nanog@nanog.org Subject: Rate Limiting on Cisco Router Thanks again for all the responses to my previous post. We have a Cisco 7206VXR router with IOS of 12.4(12) and a PA-POS-1OC3 card ofr our OC3. The problem we have now is that we are only paying for 80 MB/s of the OC-3, and the ISP is leaving the capping of it up to us. I have googled and the only things I can find is that you can not do a real cap on this type of interface. We have tried the rate-limit command with various parameters and we are unable to keep it at 80. I have read that this is not the correct way to do it, but I'm not sure what is. Any advice? Pointers appreciated. -- Alan Bryant | Systems Administrator Gtek Computers Wireless, LLC. a...@gtekcommunications.com | www.gtek.biz O 361-777-1400 | F 361-777-1405
RE: Rate Limiting on Cisco Router
traffic-shape rate 7500 9000 9000 1000 for example. Your rate limit will police your traffic and drop it all. Traffic shaping produces a queue, and does not completely junk a packet. It becomes q'd, and produces a smoother output. ~Jay Murphy IP Network Specialist NM State Government IT Services Division PSB – IP Network Management Center Santa Fé, New México 87505 We move the information that moves your world. “Good engineering demands that we understand what we’re doing and why, keep an open mind, and learn from experience.” “Engineering is about finding the sweet spot between what's solvable and what isn't. Radia Perlman Please consider the environment before printing e-mail -Original Message- From: Antonio Querubin [mailto:t...@lava.net] Sent: Thursday, July 08, 2010 4:26 PM To: Alan Bryant Cc: nanog@nanog.org Subject: Re: Rate Limiting on Cisco Router On Thu, 8 Jul 2010, Alan Bryant wrote: The problem we have now is that we are only paying for 80 MB/s of the OC-3, and the ISP is leaving the capping of it up to us. I have BTW, rate-limiting of traffic that the ISP router sends to your router is best done at the ISP router. Antonio Querubin 808-545-5282 x3003 e-mail/xmpp: t...@lava.net Confidentiality Notice: This e-mail, including all attachments is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited unless specifically provided under the New Mexico Inspection of Public Records Act. If you are not the intended recipient, please contact the sender and destroy all copies of this message. -- This email has been scanned by the Sybari - Antigen Email System.
Re: Rate Limiting on Cisco Router
I think if you try to traffic-shape 80Mbps on that platform you'll have problems. We have a 7200 with NPE-G1 (rate limited at 80Mbps) and it killed the CPU when the threshold was hit. I imagine that traffic-shaping would do the same to CPU and memory. I'd lab it first. Kenny On Thu, Jul 8, 2010 at 3:43 PM, Murphy, Jay, DOH jay.mur...@state.nm.uswrote: traffic-shape rate 7500 9000 9000 1000 for example. Your rate limit will police your traffic and drop it all. Traffic shaping produces a queue, and does not completely junk a packet. It becomes q'd, and produces a smoother output. ~Jay Murphy IP Network Specialist NM State Government IT Services Division PSB – IP Network Management Center Santa Fé, New México 87505 We move the information that moves your world. “Good engineering demands that we understand what we’re doing and why, keep an open mind, and learn from experience.” “Engineering is about finding the sweet spot between what's solvable and what isn't. Radia Perlman Please consider the environment before printing e-mail -Original Message- From: Antonio Querubin [mailto:t...@lava.net] Sent: Thursday, July 08, 2010 4:26 PM To: Alan Bryant Cc: nanog@nanog.org Subject: Re: Rate Limiting on Cisco Router On Thu, 8 Jul 2010, Alan Bryant wrote: The problem we have now is that we are only paying for 80 MB/s of the OC-3, and the ISP is leaving the capping of it up to us. I have BTW, rate-limiting of traffic that the ISP router sends to your router is best done at the ISP router. Antonio Querubin 808-545-5282 x3003 e-mail/xmpp: t...@lava.net Confidentiality Notice: This e-mail, including all attachments is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited unless specifically provided under the New Mexico Inspection of Public Records Act. If you are not the intended recipient, please contact the sender and destroy all copies of this message. -- This email has been scanned by the Sybari - Antigen Email System.
Re: Rate Limiting on Cisco Router
Agree...when you rate limit verse shaping you can actually cause more traffic because the packets need to be retransmitted to deal with those that got dropped. On 07/08/2010 06:43 PM, Murphy, Jay, DOH wrote: traffic-shape rate 7500 9000 9000 1000 for example. Your rate limit will police your traffic and drop it all. Traffic shaping produces a queue, and does not completely junk a packet. It becomes q'd, and produces a smoother output. ~Jay Murphy IP Network Specialist NM State Government
RE: Rate Limiting on Cisco Router
On Thu, 8 Jul 2010, Murphy, Jay, DOH wrote: Traffic shaping produces a queue, and does not completely junk a packet. It becomes q'd, and produces a smoother output. Traffic-shaping 80Mb/s of traffic is probably not a good idea for your router cpu :) Antonio Querubin 808-545-5282 x3003 e-mail/xmpp: t...@lava.net
Re: Rate Limiting on Cisco Router
Antonio Querubin wrote: Traffic-shaping 80Mb/s of traffic is probably not a good idea for your router cpu :) Honestly, cpu overhead shouldn't be an issue with a traffic shape queue. If it is, probably a seriously underpowered router or poor code. Now if you applied extensive rules for various traffic at different rates and queue priorities, I could see lots of extra ticks. Don't get me wrong. I have 400mbps+ traffic shapes on my junipers and probably glad for the extensive hardware support (like I have a choice, no hardware support, the router won't do it) Jack
RE: Rate Limiting on Cisco Router
What about purchasing a low-end packetshaper to be used in between? I know this doesn't answer the question but could it be an option? Date: Thu, 8 Jul 2010 13:43:17 -1000 From: t...@lava.net To: jay.mur...@state.nm.us Subject: RE: Rate Limiting on Cisco Router CC: nanog@nanog.org On Thu, 8 Jul 2010, Murphy, Jay, DOH wrote: Traffic shaping produces a queue, and does not completely junk a packet. It becomes q'd, and produces a smoother output. Traffic-shaping 80Mb/s of traffic is probably not a good idea for your router cpu :) Antonio Querubin 808-545-5282 x3003 e-mail/xmpp: t...@lava.net
Re: Rate Limiting on Cisco Router
On Thu, 2010-07-08 at 16:35 -0700, Kenny Sallee wrote: I think if you try to traffic-shape 80Mbps on that platform you'll have problems. We have a 7200 with NPE-G1 (rate limited at 80Mbps) and it killed the CPU when the threshold was hit. I imagine that traffic-shaping would do the same to CPU and memory. I'd lab it first. I've seen that model preceded by a BSD machine with 2 physical ethernet NICs. When I asked - limiting for the 7206's outgoing, so I'm assuming that was a CPU thing. In that case the 7206 was just an edge box for the fibre, so doing nothing complex. Capped at 48Mbps (IIRC) in that case - YMMV. Also bear in mind that this is borderline black art - it needs a bit of testing to be sure it's working as you expect :) My usual technique is to replay some flows then set several iperf streams going simultaneously to see how it reacts. Sometimes limiting just seems to temporarily break down under stress in bizarre ways. Whether it fails open, restricted or closed seems to be very unpredictable and not very reproducible on some kit- keep your eye on it at first, or use BSD to do it if you're more familiar with that. Gord -- Awake! for morning in the bowl of light has flung the stone that puts the stars to flight
Re: Rate Limiting on Cisco Router
On Thu, 2010-07-08 at 18:54 -0500, Jack Bates wrote: underpowered router or poor code Agreed. So which is it? :) To be fair, some IOS versions were better than others at it in my limited experience of that chassis. Gord -- I hold you XAP
Re: Rate Limiting on Cisco Router
So you guys would not recommend the traffic shaping route on a 7206 with a NPE-G1? Is it the processor or memory that would not be able to handle it? I don't necessarily plan on doing anything other than limiting it at 80Mbps or whatever it is that we are capping ourselves at at the time. On Thu, Jul 8, 2010 at 7:13 PM, gordon b slater gordsla...@ieee.org wrote: On Thu, 2010-07-08 at 18:54 -0500, Jack Bates wrote: underpowered router or poor code Agreed. So which is it? :) To be fair, some IOS versions were better than others at it in my limited experience of that chassis. Gord -- I hold you XAP -- Alan Bryant | Systems Administrator Gtek Computers Wireless, LLC. a...@gtekcommunications.com | www.gtek.biz O 361-777-1400 | F 361-777-1405
Re: Rate Limiting on Cisco Router
Also, are there any upgrades that can be done to this router to increase it's processing power? Is there something better for the 7206VXR than the NPE-G1? I see the NPE-G2, but even on ebay it is very costly. On Thu, Jul 8, 2010 at 8:32 PM, Alan Bryant a...@gtekcommunications.com wrote: So you guys would not recommend the traffic shaping route on a 7206 with a NPE-G1? Is it the processor or memory that would not be able to handle it? I don't necessarily plan on doing anything other than limiting it at 80Mbps or whatever it is that we are capping ourselves at at the time. On Thu, Jul 8, 2010 at 7:13 PM, gordon b slater gordsla...@ieee.org wrote: On Thu, 2010-07-08 at 18:54 -0500, Jack Bates wrote: underpowered router or poor code Agreed. So which is it? :) To be fair, some IOS versions were better than others at it in my limited experience of that chassis. Gord -- I hold you XAP -- Alan Bryant | Systems Administrator Gtek Computers Wireless, LLC. a...@gtekcommunications.com | www.gtek.biz O 361-777-1400 | F 361-777-1405 -- Alan Bryant | Systems Administrator Gtek Computers Wireless, LLC. a...@gtekcommunications.com | www.gtek.biz O 361-777-1400 | F 361-777-1405
Re: Rate Limiting on Cisco Router
On 7/8/2010 18:40, Alan Bryant wrote: Also, are there any upgrades that can be done to this router to increase it's processing power? Is there something better for the 7206VXR than the NPE-G1? I see the NPE-G2, but even on ebay it is very costly. The NPE-G2 is the next step after the NPE-G1. ~Seth
Re: Rate Limiting on Cisco Router
On Thu, Jul 08, 2010 at 01:43:17PM -1000, Antonio Querubin wrote: Traffic-shaping 80Mb/s of traffic is probably not a good idea for your router cpu :) I concur, we shape a 100Mb/s ethernet down to 50Mb/s on a 3845, so that QoS is doable. The router gets brought to its knees around 40Mb/s. Turn off shaping and the router is usable all the way up to the 50Mb/s and then some. Is there a more reasonable way to do this on Cisco? max-reserved-bandwidth? -cjp
Re: Rate Limiting on Cisco Router
On Jul 8, 2010, at 4:05 PM, Alan Bryant wrote: Thanks again for all the responses to my previous post. We have a Cisco 7206VXR router with IOS of 12.4(12) and a PA-POS-1OC3 card ofr our OC3. The problem we have now is that we are only paying for 80 MB/s of the OC-3, and the ISP is leaving the capping of it up to us. I have googled and the only things I can find is that you can not do a real cap on this type of interface. We have tried the rate-limit command with various parameters and we are unable to keep it at 80. I have read that this is not the correct way to do it, but I'm not sure what is. Any advice? If your issue is cost for rates larger than 80 Mbps then you probably want to find out what applications are using the bulk of the bandwidth and either adjust your budget, or their performance expectations and allocate network resources expressly. Flow data (even local cache analysis v. exporting) would help you glean some of this, but external longer term analysis would surely be more useful - and there are lots of way you can do that - and use the data to either justify more budget or cull offending applications. As others have noted, rate *limiting* is usually indiscriminate and often results in non-determinism and far less 'goodput' than rate-shaping. If hardware constraints with those WAN-side PHY devices are gating, you could always do it on the LAN side, and perhaps much more selectively based on which application and associated network transaction traffic is the most valuable to your business and in your operating environment. Given, you didn't talk about asymmetries and egress traffic policy tweaking at the CPE to induce desired ingress levels is usually a science in and of it's self - but alas, if one must turn the steam valves ;-) I can't see application of any rate-limiting policies indiscriminately be desirable in any business environment, and suggest that if budget constrained worst case you align network resource allocation with critical business applications first via LAN-side rate-shaping functions - or AUPs, or -danny
Re: Rate Limiting on Cisco Router
On Thu, 8 Jul 2010, Alan Bryant wrote: So you guys would not recommend the traffic shaping route on a 7206 with a NPE-G1? Is it the processor or memory that would not be able to handle it? With a G1 you'll be able to shape just fine, even do fancy stuff like fair-queue within those 80 megs. I've done this on a NPE-300, but only egress, and as long as packet sizes were fairly large (normal TCP sessions with mostly 1500 byte packets + ACKs) it coped with 90 megs of traffic. So with the added power of G1 you should definitely try before ruling it out. Shaping is so much better than the packet dropping that a rate limiter does. -- Mikael Abrahamssonemail: swm...@swm.pp.se
RE: Rate Limiting on Cisco Router
On Thu, 2010-07-08 at 20:01 -0400, Brandon Kim wrote: What about purchasing a low-end packetshaper to be used in between? If - 1/ budget is a problem and 2/ you have no BSD knowledge inhouse and 3/ the LAN side is all ethernet you could have a stab at using a PFsense box with two (and strictly ONLY two, for this use) physical NICs. It has a GUI to set up traffic shaping (see the sticky on the pfsense forums) PFsense 1.2.3 is current, don't go for the experimental 2.0 for production. There's a book and commercial support if you need it, free support via forums if you can't. Only two physical NICs is necessary due to shaper problems with more than two, whereas in a firewalling role the slots are the only limit (but VLANS are the norm for bucketloads of ports on a firewall PFsense box) An ITX (Littlefalls etc) mobo with 512MB RAM with an extra PCI Intel NIC added will do you fine . PFsense has nice traffic graphs, which helps you with shaping speeds in a big way. It also has a TFTP server available for it so it's handy for unmanned sites with only a few blue boxes ;) PS - a crazy afterthough - surely just about anything with a 10/100 ethernet link running at 100 and placed inline, cannot exceed 100Mbps - and probably less if it's plastic-cased? Try a few 8-port junkers and see what happens if you fancy a walk on the dangerous side. Watch out for errors and smoke :) Gord -- The drinker you are the smoker you get
Re: Rate Limiting on Cisco Router
Mikael Abrahamsson wrote: With a G1 you'll be able to shape just fine, even do fancy stuff like fair-queue within those 80 megs. I've done this on a NPE-300, but only egress, and as long as packet sizes were fairly large (normal TCP sessions with mostly 1500 byte packets + ACKs) it coped with 90 megs of traffic. So with the added power of G1 you should definitely try before ruling it out. Definitely worth the try. Your biggest enemy may be 12.4 IOS. It's bloated and buggy in my experience, but that has mostly been edge services. If 12.4 pegs your processor, you may want to check the software/hardware matrix and see if one of the older 12.0/2 service provider trains that they continued to add support for (probably some large customer's special requests). I don't know if it will support the G1, but if so, you might have better performance out of it. Shaping is so much better than the packet dropping that a rate limiter does. Definitely. My favorite off the wall use of shaping was to smooth traffic flow on a Gig-e to reduce microbursts from overrunning the hardware rx on a 7513. :) Jack
