HSRP vs VRRP for IPv6 on IOS-XE - rekindling an old flame
A while back I brought up a discussion about IPv6 and I mentioned having some HSRP issues. Not end of the world, just adjusting to IPv6. Several folks went offline to tell me that I should dump legacy HSRP and go to VRRP. While I never did find anyone who could explain how HSRP is a sunset feature in IOS, I did agree with a few folks to look into VRRP for IPv6. Well I'm just now getting around to it and there is literally nothing out there. I found a few older articles implying that it's not there yet and of course I found the usual docs about RAs and SLAC and whatnot. But nothing recent. So, for those who criticized me previously about using HSRP (or anyone else) instead of VRRP, do you have VRRP up and running on Cisco IOS-XE and if so how? Can anyone provide a link or a document explaining how this is accomplished? Sample configs? Usually if you can't find it on Google or CCO it's not promising. I'm also reaching out to our AS team for guidance on the subject. PS: I'm not taunting here. It's just that several folks made the effort to go offline with me and tell me how wrong I was with HSRP and that I need to progress to VRRP and I can't find a single doc on the subject now that I look. Were these folks mistaken or am I missing something? Any help would be appreciated. -- -Hammer- I was a normal American nerd -Jack Herer
Re: HSRP vs VRRP for IPv6 on IOS-XE - rekindling an old flame
And two seconds after I hit send I find an updated article http://www.cisco.com/en/US/docs/ios-xml/ios/ipapp_fhrp/configuration/xe-3s/fhp-vrrp.html facepalm If you have more information I still welcome it. I'm going to go sit in the corner now... -Hammer- I was a normal American nerd -Jack Herer On 8/20/2012 9:36 AM, -Hammer- wrote: A while back I brought up a discussion about IPv6 and I mentioned having some HSRP issues. Not end of the world, just adjusting to IPv6. Several folks went offline to tell me that I should dump legacy HSRP and go to VRRP. While I never did find anyone who could explain how HSRP is a sunset feature in IOS, I did agree with a few folks to look into VRRP for IPv6. Well I'm just now getting around to it and there is literally nothing out there. I found a few older articles implying that it's not there yet and of course I found the usual docs about RAs and SLAC and whatnot. But nothing recent. So, for those who criticized me previously about using HSRP (or anyone else) instead of VRRP, do you have VRRP up and running on Cisco IOS-XE and if so how? Can anyone provide a link or a document explaining how this is accomplished? Sample configs? Usually if you can't find it on Google or CCO it's not promising. I'm also reaching out to our AS team for guidance on the subject. PS: I'm not taunting here. It's just that several folks made the effort to go offline with me and tell me how wrong I was with HSRP and that I need to progress to VRRP and I can't find a single doc on the subject now that I look. Were these folks mistaken or am I missing something? Any help would be appreciated.
Re: HSRP vs VRRP for IPv6 on IOS-XE - rekindling an old flame
Correction. Still looking for something IPv6 specific. -Hammer- I was a normal American nerd -Jack Herer On 8/20/2012 9:39 AM, -Hammer- wrote: And two seconds after I hit send I find an updated article http://www.cisco.com/en/US/docs/ios-xml/ios/ipapp_fhrp/configuration/xe-3s/fhp-vrrp.html facepalm If you have more information I still welcome it. I'm going to go sit in the corner now... -Hammer- I was a normal American nerd -Jack Herer On 8/20/2012 9:36 AM, -Hammer- wrote: A while back I brought up a discussion about IPv6 and I mentioned having some HSRP issues. Not end of the world, just adjusting to IPv6. Several folks went offline to tell me that I should dump legacy HSRP and go to VRRP. While I never did find anyone who could explain how HSRP is a sunset feature in IOS, I did agree with a few folks to look into VRRP for IPv6. Well I'm just now getting around to it and there is literally nothing out there. I found a few older articles implying that it's not there yet and of course I found the usual docs about RAs and SLAC and whatnot. But nothing recent. So, for those who criticized me previously about using HSRP (or anyone else) instead of VRRP, do you have VRRP up and running on Cisco IOS-XE and if so how? Can anyone provide a link or a document explaining how this is accomplished? Sample configs? Usually if you can't find it on Google or CCO it's not promising. I'm also reaching out to our AS team for guidance on the subject. PS: I'm not taunting here. It's just that several folks made the effort to go offline with me and tell me how wrong I was with HSRP and that I need to progress to VRRP and I can't find a single doc on the subject now that I look. Were these folks mistaken or am I missing something? Any help would be appreciated.
Re: HSRP vs VRRP for IPv6 on IOS-XE - rekindling an old flame
Yeah I see the disconnect. I'm assuming that what I see is what I get. Which means I'm going to stick with HSRP. If our AS team gives me any good feedback that I can share I will do so. Thanks Nick. XE: v4: HSRPv1, HSRPv2, VRRPv6: HSRPv2 Reflections of a madman... Why is parity such a difficult task? -Hammer- I was a normal American nerd -Jack Herer On 8/20/2012 9:51 AM, Nick Hilliard wrote: On 20/08/2012 15:41, -Hammer- wrote: Correction. Still looking for something IPv6 specific. Last time I looked, the support looked like this: XR: v4: HSRPv1, VRRP v6: VRRP IOS: v4: HSRPv1, HSRPv2, VRRP, GLBP v6: HSRPv2, GLBP You'll notice a certain lack of joined-up thinking here. Nick
Re: HSRP vs VRRP for IPv6 on IOS-XE - rekindling an old flame
It's a good argument Owen. Unfortunately it looks like VRRP is not an available feature on the ASR for IPv6 FHRP. I'm still trying to confirm it but it is definitely not configurable in my version of code and if it's just coming out in a new release there is no way I'm jumping in with both feet. I'll have to stick with HSRP and LL addressing. If anyone knows different please let me know. Thanks PS: Yes, I still have some ISL. :( On legacy environments only though. I promise. Nothing new in years... -Hammer- I was a normal American nerd -Jack Herer On 8/20/2012 3:31 PM, Owen DeLong wrote: VRRP is to HSRP what 802.1q is to ISL... I highly recommend using VRRP instead of HSRP because: 1. It is a more robust protocol 2. It is vendor agnostic 3. Being vendor agnostic it is more likely to have a continuing future. Does anyone still use ISL? Owen On Aug 20, 2012, at 13:10 , sth...@nethelp.no wrote: Yeah I see the disconnect. I'm assuming that what I see is what I get. Which means I'm going to stick with HSRP. If our AS team gives me any good feedback that I can share I will do so. Thanks Nick. XE: v4: HSRPv1, HSRPv2, VRRPv6: HSRPv2 Not particularly relevant to the original question - however, I'd like to mention that we've been using IPv6 VRRP on our Juniper routers for well over a year. No particular problems so far. Steinar Haug, Nethelp consulting, sth...@nethelp.no
Re: HSRP vs VRRP for IPv6 on IOS-XE - rekindling an old flame
That's good to know. Seriously. I can point that out to the Cisco guys... :) -Hammer- I was a normal American nerd -Jack Herer On 8/20/2012 3:10 PM, sth...@nethelp.no wrote: Yeah I see the disconnect. I'm assuming that what I see is what I get. Which means I'm going to stick with HSRP. If our AS team gives me any good feedback that I can share I will do so. Thanks Nick. XE: v4: HSRPv1, HSRPv2, VRRPv6: HSRPv2 Not particularly relevant to the original question - however, I'd like to mention that we've been using IPv6 VRRP on our Juniper routers for well over a year. No particular problems so far. Steinar Haug, Nethelp consulting, sth...@nethelp.no
Re: NAT66 was Re: using reserved IPv6 space
I have almost one hundred FWs. Some physical. Some virtual. Various vendors. Your point is spot on. -Hammer- I was a normal American nerd -Jack Herer On 7/16/2012 8:55 PM, Lee wrote: On 7/16/12, Owen DeLong o...@delong.com wrote: Why would you want NAT66? ICK!!! One of the best benefits of IPv6 is being able to eliminate NAT. NAT was a necessary evil for IPv4 address conservation. It has no good use in IPv6. NAT is good for getting the return traffic to the right firewall. How else do you deal with multiple firewalls asymmetric routing? Yes, it's possible to get traffic back to the right place without NAT. But is it as easy as just NATing the outbound traffic at the firewall? Lee
Re: using reserved IPv6 space
-Hammer- I was a normal American nerd -Jack Herer On 7/16/2012 11:18 PM, Jimmy Hess wrote: On 7/16/12, -Hammer- bhmc...@gmail.com wrote: hurdles. Example? HSRP IPv6 global addressing on Cisco ASR platform. If HSRP is a legacy proprietary protocol; try VRRP. Stateless autoconfig and router advertisements can obviate (eliminate/reduce) the need in many cases; albeit, with a longer failure recovery duration. This isn't PAGP vs LACP again is it? Can someone show me a sunset document for HSRP from Cisco? Yes, VRRP, I use it as well. But that's not the point. The point is that it's a feature from a vendor that lacks parity across the product suites. Like most of the folks out there, I run IOS, NX-OS, IOS-XE, etc and that's just from Cisco. Feature parity is a big gripe that doesn't have an easy solution. I feel for the vendors but at the same time I'm frustrated when I read a document on a function and realize afterwards I can only deploy it on some of my up to date products. That's the point. this morning from CheckPoint for NAT66. This should have been ready for prime time years ago. I guess the vendors weren't getting the push from NAT66; you're talking about something that is not a mainline feature, an experimental proposition; RFC6296 produced in 2011. Very few IPv6 deployments should require prefix translation or any kind of NAT technology with IPv6, other than the IPv4 transition technologies. So... NO.. they should not have had this ready for prime time years ago. I disagree. I was asking security vendors what they were doing about these kinds of future needs years ago. Many years ago. They all conceded that they had had similar requests from other customers but the demand wasn't there yet. They should have had more vision on their road maps but they focused on basic functionality of the protocol and not features beyond that and now they are playing catch up. I understand, they were focused on what features were getting the attention. That's business. But everyone knew the depletion rates and everyone knew that whether the pompous USA wanted it or not IPv6 was coming in the late 2000s and early 2010s. So they should have been more diligent. You can pull up any marketing document from any vendor and they will tell you IPv6 is fully supported. But when you implement features (who the heck runs a default config these days?) you really test the functionality of the product. There are other things they should have been working on, such as getting the base IPv6 implementation correct, V6 connectivity, V6-enabled protocols, support for the newer RA/DHCPv6 options, and support for the newer more fully baked IPv4 transition specs such as 6to4, NAT-PT, and bugfixing. I'll take the stable platform, that has the standards-specified features, over one with bells and whistles, and the latest experimental draft features such as 6to6, that are not required to deploy IPv6, thanks. I agree. Stability. But a stable platform that doesn't have the features I need is not a stable platform I can invest in. Cart before horse. -- -JH
Re: using reserved IPv6 space
There's are routing and switching people and there are security people. And they look at things different. That, IMHO, is the root of the emotion on this thread. No one is actually wrong except me for stirring the pot as the OP. :) -Hammer- I was a normal American nerd -Jack Herer On 7/17/2012 7:47 AM, Saku Ytti wrote: I wonder who really believes there is no usage case for NAT66. Have these people seen non-trivial corporate networks? I'm sure many people in this list finance part of their lives with renumber projects costing MUSDs. For many companies just finding out where addresses have been punched in (your FWs, your software, partner FWs, partner software, configurations...) will take months, before even starting renumbering. If my enterprise customers don't have plan and ask my advice, I will recommend own PI, if they don't want (extra cost, extra clue needed) ULA and NAT66. If I recommend more specific from our PA, I know when they switch operators in few years time, some of them will decide renumbering is out-of-the-question[0] and will NAT my PA to new operator PA, essentially forcing me to never return any addresses to my free pool. I wonder if that is valid reason to ask more allocations? That address was once used? More specific from our PA is fine for small offices with trivial setup, residential networks and few niche shops who specifically design for renumbering (but I guess these most often already want PI+BGP) [0] I don't want NAT66 anywhere. I won't use NAT66 anywhere. But just because we have new protocol, does not mean we have new set of people, who share my ideologies and goals about network design. Only thing I can do, is protect myself from problems they would cause me.
Re: using reserved IPv6 space
There are multiple issues here. I understand most folks on these threads are beyond me but I'm pretty sure I'm not the only person in this position. 1) (This one is currently a personal issue) I am still building up a true IPv6 skillset. Yes, I understand it for the most part but now is the time to apply it. 2) All the reading you do doesn't prepare you for application and the vendors aren't necessarily helping. Feature parity across platforms and vendors beyond just interface x/x/x and ipv6 address fe80:blah:blah::babe:1 seems to seriously be lacking. When I try to take what I understand and apply it beyond the basics I often see hurdles. Example? HSRP IPv6 global addressing on Cisco ASR platform. If it's working for you hit me offline. Example2? Any vendor product beyond a router or switch. CheckPoint FW? F5 LB? Netscaler LB or AF? The WAN guys may be rolling deep in IPv6 but not everyone else. I just got an EA this morning from CheckPoint for NAT66. This should have been ready for prime time years ago. I guess the vendors weren't getting the push from the customers so there was no need to make an effort 3) When I'm not preoccupied attempting to digest the fundamentals I am well aware of the retooling of the brain that is required for this in a network design. Last year I reached out to Team Cymru and attempted to build an IPv6 router template to match their IPv4 template. It was a completely different animal. Ironically most of the STIGs and NSA reference garbage I used was ten years old but still applied. After going thru all those docs my brain hurt trying to orient my ACLs properly and go thru all the different attributes you want to block where and when. Then I spent some time trying to work our design schemas for our ARIN space with the WAN design team. What I'm trying to say is that Roberts comments are spot on. It is a very different way of thinking on a small scale and a large scale and you can't take your IPv4 logic and apply it. I've tried and it's just slowing me down. -Hammer- I was a normal American nerd -Jack Herer On 7/15/2012 10:35 PM, Lee wrote: On 7/14/12, Robert E. Seastrom r...@seastrom.com wrote: Actually, that's one of the most insightful meta-points I've seen on NANOG in a long time. There is a HUGE difference between IPv4 and IPv6 thinking. We've all been living in an austerity regime for so long that we've completely forgotten how to leave parsimony behind. Even those of us who worked at companies that were summarily handed a Class B when we mumbled something about internal subnetting have a really hard time remembering how to act when we suddenly don't have to answer for every single host address and can design a network to conserve other things (like our brain cells). Suggestions? I feel like I should be able to do something really nice with an absurdly large address space. But lack of imagination or whatever.. I haven't come up with anything that really appeals to me. Thanks, Lee -Hammer- bhmc...@gmail.com writes: bashes head against wall Thank you all. It's not the protocol that hurts. It's rethinking the culture/philosophy around it. -Hammer- On 7/14/12 3:20 PM, Owen DeLong o...@delong.com wrote: They're a bad thing in IPv6. The only place for security through obscurity IMHO is a small round container that sits next to my desk. Besides, if you don't advertise it, a GUA prefix is just as obscure as a ULA prefix and provides a larger search space in which one has to hunt for it... Think /3 instead of /8. Owen On Jul 14, 2012, at 1:14 PM, -Hammer- wrote: Guys, The whole purpose of this is that they do NOT need to be global. Security thru obscurity. It actually has a place in some worlds. Does that make sense? Or are such V4-centric approaches a bad thing in v6? On 7/13/12 8:41 PM, Brandon Ross br...@pobox.com wrote: On Fri, 13 Jul 2012, Owen DeLong wrote: On Jul 13, 2012, at 4:24 PM, Randy Bush wrote: keep life simple. use global ipv6 space. randy Though it is rare, this is one time when I absolutely agree with Randy. It's even more rare for me to agree with Randy AND Owen at the same time. -- Brandon Ross Yahoo AIM: BrandonNRoss +1-404-635-6667ICQ: 2269442 Schedule a meeting: https://tungle.me/bross Skype: brandonross
Re: using reserved IPv6 space
Inline - -Hammer- I was a normal American nerd -Jack Herer 1) (This one is currently a personal issue) I am still building up a true IPv6 skillset. Yes, I understand it for the most part but now is the time to apply it. Frankly, IMHO, the best way to build up a truly useful IPv6 skill set is to start applying what you don't know and see what happens. For the most part, you will find that it is truly 96 more bits, no magic. --- Completely agree. Been playing in GNS3 on the basics and we're starting to play in a full lab soon. 2) All the reading you do doesn't prepare you for application and the vendors aren't necessarily helping. Feature parity across platforms and vendors beyond just interface x/x/x and ipv6 address fe80:blah:blah::babe:1 seems to seriously be lacking. When I try to take what I understand and apply it beyond the basics I often see hurdles. Example? HSRP IPv6 global addressing on Cisco ASR platform. If it's working for you hit me offline. Example2? Any vendor product beyond a router or switch. CheckPoint FW? F5 LB? Netscaler LB or AF? The WAN guys may be rolling deep in IPv6 but not everyone else. I just got an EA this morning from CheckPoint for NAT66. This should have been ready for prime time years ago. I guess the vendors weren't getting the push from the customers so there was no need to make an effort You probably meant 2001:db8:b1aa:b1aa::babe:1 (blah isn't hex and fe80::/10 is link local. 2001:db8::/16 is the example prefix) --- I stand corrected. :) For the most part, HSRP really isn't even necessary or useful in IPv6 since ND should take care of what HSRP did for IPv4. --- On the WAN? Sure. On my Internet facing equipment? I disagree. RAs and ND and all that fun stuff needs to be suppressed. I believe F5 has rolled out IPv6 in a subset of their products and that you need pretty recent versions to get IPv6 functionality from them. The ARIN Wiki (http://www.getipv6.info) may be a good source of information on various vendor statuses. Contribute what you know/find out there as well, please. --- Yes they have and NetScaler is running solid as well. My issues are when you go beyond basic features of any product with IPv6 things get tricky. I need content switching with redirects and whatnot and based on the few efforts I've seen so far I'm not optimistic. Again, routers and switches seem to be further ahead than other products. They all have their limits in advanced features. Back to my ASR comment. Why would you want NAT66? ICK!!! One of the best benefits of IPv6 is being able to eliminate NAT. NAT was a necessary evil for IPv4 address conservation. It has no good use in IPv6. ---That is clearly a matter of opinion. NAT64 and NAT66 wouldn't be there if there weren't enough customers asking for it. Are all the customers naive? I doubt it. They have their reasons. I agree with your purist definition and did not say I was using it. My point is that vendors are still rolling out baseline features even today. 3) When I'm not preoccupied attempting to digest the fundamentals I am well aware of the retooling of the brain that is required for this in a network design. Last year I reached out to Team Cymru and attempted to build an IPv6 router template to match their IPv4 template. It was a completely different animal. Ironically most of the STIGs and NSA reference garbage I used was ten years old but still applied. After going thru all those docs my brain hurt trying to orient my ACLs properly and go thru all the different attributes you want to block where and when. Then I spent some time trying to work our design schemas for our ARIN space with the WAN design team. What I'm trying to say is that Roberts comments are spot on. It is a very different way of thinking on a small scale and a large scale and you can't take your IPv4 logic and apply it. I've tried and it's just slowing me down. Yes and no. If you have been doing IPv4 long enough to remember pre-NAT IPv4, then, you just need to remember some of the old ways of IPv4. If you have no recollection of IPv4 without NAT, then, you are correct, it is a huge paradigm shift to go back to the way the internet is supposed to have been before we ran out of addresses. --- This isn't specific to you Owen, but the group in general. I have been around for a while. Not as long as some others here. NAT is a feature and it does have a place. Security. I'm sorry that this frustrates people but security is a layered approach and it starts off simple. If you have a network that doesn't need exposure to the Internet or to someone else you can get fancy with anything from a FW to control source and destination or AD controls so only the accounting team can get in. Sure. They all work. You can also NAT them. Make them invisible. Or null the traffic. The more fundamental the point of defense is the easier it is to understand and sometimes
Re: using reserved IPv6 space
I agree. Most are naive. Not all. -Hammer- I was a normal American nerd -Jack Herer On 7/16/2012 11:34 AM, valdis.kletni...@vt.edu wrote: On Mon, 16 Jul 2012 11:09:28 -0500, -Hammer- said: ---That is clearly a matter of opinion. NAT64 and NAT66 wouldn't be there if there weren't enough customers asking for it. Are all the customers naive? I doubt it. They have their reasons. I agree with your purist definition and did not say I was using it. My point is that vendors are still rolling out base line features even today. Sorry to tell you this, but the customers *are* naive and asking for stupid stuff. They think they need NAT under IPv6 because they suffered with it in IPv4 due to addressing issues or a (totally percieved) security benefit (said benefit being *entirely* based on the fact that once you get NAT working, you can build a stateful firewall for essentially free). The address crunch is gone, and stateful firewalls exist, so there's no *real* reason to keep pounding your head against the wall other than we've been doing it for 15 years.
Re: using reserved IPv6 space
Guys, The whole purpose of this is that they do NOT need to be global. Security thru obscurity. It actually has a place in some worlds. Does that make sense? Or are such V4-centric approaches a bad thing in v6? On 7/13/12 8:41 PM, Brandon Ross br...@pobox.com wrote: On Fri, 13 Jul 2012, Owen DeLong wrote: On Jul 13, 2012, at 4:24 PM, Randy Bush wrote: keep life simple. use global ipv6 space. randy Though it is rare, this is one time when I absolutely agree with Randy. It's even more rare for me to agree with Randy AND Owen at the same time. -- Brandon Ross Yahoo AIM: BrandonNRoss +1-404-635-6667ICQ: 2269442 Schedule a meeting: https://tungle.me/bross Skype: brandonross
Re: using reserved IPv6 space
bashes head against wall Thank you all. It's not the protocol that hurts. It's rethinking the culture/philosophy around it. -Hammer- On 7/14/12 3:20 PM, Owen DeLong o...@delong.com wrote: They're a bad thing in IPv6. The only place for security through obscurity IMHO is a small round container that sits next to my desk. Besides, if you don't advertise it, a GUA prefix is just as obscure as a ULA prefix and provides a larger search space in which one has to hunt for it... Think /3 instead of /8. Owen On Jul 14, 2012, at 1:14 PM, -Hammer- wrote: Guys, The whole purpose of this is that they do NOT need to be global. Security thru obscurity. It actually has a place in some worlds. Does that make sense? Or are such V4-centric approaches a bad thing in v6? On 7/13/12 8:41 PM, Brandon Ross br...@pobox.com wrote: On Fri, 13 Jul 2012, Owen DeLong wrote: On Jul 13, 2012, at 4:24 PM, Randy Bush wrote: keep life simple. use global ipv6 space. randy Though it is rare, this is one time when I absolutely agree with Randy. It's even more rare for me to agree with Randy AND Owen at the same time. -- Brandon Ross Yahoo AIM: BrandonNRoss +1-404-635-6667ICQ: 2269442 Schedule a meeting: https://tungle.me/bross Skype: brandonross
using reserved IPv6 space
OK. I'm pretty sure I'm gonna get some flak for this but I'll share this question and it's background anyway. Please be gentle. In the past, with IPv4, we have used reserved or non-routable space Internally in production for segments that won't be seen anywhere else. Examples? A sync VLAN for some FWs to share state. An IBGP link between routers that will never be seen or advertised. In those cases, we have often used 192.0.2.0/24. It's reserved and never used and even if it did get used one day we aren't routing it internally. It's just on segments where we need some L3 that will never be seen. On to IPv6 I was considering taking the same approach. Maybe using 0100::/8 or 1000::/4 or A000::/3 as a space for this. Other than the usual Hey, you shouldn't do that can anyone give me some IPv6 specific reasons that I may not be forecasting that would make it worse doing this than in an IPv4 scenario. I know, not apples to apples but for this question they are close enough. Unless there is something IPv6 specific that is influencing this -- -Hammer- I was a normal American nerd -Jack Herer
Re: using reserved IPv6 space
Leo/Jeroen, Thank you both. That is the simple answer that I wasn't thinking of. I'm not as IPv6 savvy as I need to be (yet) so I haven't put all the pieces together when trying to look at the bigger picture. Thanks again. -Hammer- I was a normal American nerd -Jack Herer On 7/13/2012 9:41 AM, Jeroen Massar wrote: On 2012-07-13 16:38, -Hammer- wrote: OK. I'm pretty sure I'm gonna get some flak for this but I'll share this question and it's background anyway. Please be gentle. In the past, with IPv4, we have used reserved or non-routable space Internally in production for segments that won't be seen anywhere else. There is this very nice concept called ULA (RFC4193), use it. If you want to be more sure about uniqueness, use http://www.sixxs.net/tools/grh/ula/ or you can also just use a chunk of your 'global' prefix and don't announce a route for it and firewall it off properly. Greets, Jeroen
Re: using reserved IPv6 space
I think they would. I'm just a bit too new to this. Thanks. -Hammer- I was a normal American nerd -Jack Herer On 7/13/2012 10:05 AM, TJ wrote: On Fri, Jul 13, 2012 at 10:38 AM, -Hammer- bhmc...@gmail.com mailto:bhmc...@gmail.com wrote: OK. I'm pretty sure I'm gonna get some flak for this but I'll share this question and it's background anyway. Please be gentle. In the past, with IPv4, we have used reserved or non-routable space Internally in production for segments that won't be seen anywhere else. Examples? A sync VLAN for some FWs to share state. An IBGP link between routers that will never be seen or advertised. In those cases, we have often used 192.0.2.0/24 http://192.0.2.0/24. It's reserved and never used and even if it did get used one day we aren't routing it internally. It's just on segments where we need some L3 that will never be seen. On to IPv6 I was considering taking the same approach. Maybe using 0100::/8 or 1000::/4 or A000::/3 as a space for this. Would using just Link Locals not be sufficient? /(Failing that, as others noted, ULAs are the next right answer ... )/ / / /TJ
Re: using reserved IPv6 space
I'm having similar thoughts and we are about to implement. Fortunately we are implementing in an isolated lab first for this exact reason. For us to figure things out first before attempting them elsewhere. I like the ULA approach. I'm not sure about link local being used as strategy for Internal services. I'm finally getting to the point where I'm looking past the vastness of the numbers and just focusing on subnets and masks and subnetting and whatnot. -Hammer- I was a normal American nerd -Jack Herer On 7/13/2012 11:11 AM, Tom Cooper wrote: On Fri, Jul 13, 2012 at 11:05 AM, TJ trej...@gmail.com mailto:trej...@gmail.com wrote: On Fri, Jul 13, 2012 at 10:38 AM, -Hammer- bhmc...@gmail.com mailto:bhmc...@gmail.com wrote: OK. I'm pretty sure I'm gonna get some flak for this but I'll share this question and it's background anyway. Please be gentle. In the past, with IPv4, we have used reserved or non-routable space Internally in production for segments that won't be seen anywhere else. Examples? A sync VLAN for some FWs to share state. An IBGP link between routers that will never be seen or advertised. In those cases, we have often used 192.0.2.0/24 http://192.0.2.0/24. It's reserved and never used and even if it did get used one day we aren't routing it internally. It's just on segments where we need some L3 that will never be seen. On to IPv6 I was considering taking the same approach. Maybe using 0100::/8 or 1000::/4 or A000::/3 as a space for this. Would using just Link Locals not be sufficient? *(Failing that, as others noted, ULAs are the next right answer ... )* * * /TJ As an IPv6 newbie myself, I wonder how hosts handle link local, ULA and global addresses. For example, if you have some internal web traffic used for intranet use only, do you bind those servers to use only ULA addresses? This way your internal users with ULA addressing only have access to those servers? No need to give intranet-only servers a global address if they're not needed to be accessed globally. Is there a way for hosts to prefer or attempt to connect to a service by first trying a link-local scope, then a ULA and finally a global address if its off the AS? I really like the idea of ULA and think it makes much more sense than RFC1918 + NAT. I just don't have any deployment experience with it yet so I'm curious how the host would handle it. On the router side, I'm sure ULA and global routing just run as ships-in-the-night side-by-side anyways...right? -- Thomas Cooper
Re: LinkedIn password database compromised
I gotta agree with Aaron here. What would be my motivation to trust an open and public infrastructure? With my business or personal keys? -Hammer- I was a normal American nerd -Jack Herer On 6/7/2012 2:37 PM, Aaron C. de Bruyn wrote: On Thu, Jun 7, 2012 at 12:24 PM, Owen DeLongo...@delong.com wrote: Heck no to X.509. We'd run into the same issue we have right now--a select group of companies charging users to prove their identity. Not if enough of us get behind CACERT. Yet again, another org (free or not) that is holding my identity hostage. Would you give cacert your SSH key and use them to log in to your Linux servers? I'd bet most *nix admins would shout hell no! So why would you make them the gateway for your online identity? -A
Re: LinkedIn password database compromised
Thank you for educating without insulting. Always professional Owen. It's appreciated. -Hammer- I was a normal American nerd -Jack Herer On 6/7/2012 3:18 PM, Owen DeLong wrote: A proper CA does not have your business or personal keys, they merely sign them and attest to the fact that they actually represent you. You are free to seek and obtain such validation from any and as many parties as you see fit. At no point should any CA be given your private key data. They merely use their private key to encrypt a hash of your public key and other data to indicate that your private key is bound to your other data. You trust DMV/Passport Agency/etc. to validate your identity in the form of your government issued ID credentials, right? That doesn't give DMV/Passport Agency/etc. control over your face, but, it does allow them to indicate to others that your face is tied to your name, date of birth, etc. Owen On Jun 7, 2012, at 1:04 PM, -Hammer- wrote: I gotta agree with Aaron here. What would be my motivation to trust an open and public infrastructure? With my business or personal keys? -Hammer- I was a normal American nerd -Jack Herer On 6/7/2012 2:37 PM, Aaron C. de Bruyn wrote: On Thu, Jun 7, 2012 at 12:24 PM, Owen DeLongo...@delong.com wrote: Heck no to X.509. We'd run into the same issue we have right now--a select group of companies charging users to prove their identity. Not if enough of us get behind CACERT. Yet again, another org (free or not) that is holding my identity hostage. Would you give cacert your SSH key and use them to log in to your Linux servers? I'd bet most *nix admins would shout hell no! So why would you make them the gateway for your online identity? -A
Re: ISPs and full packet inspection
You should be discussing this with inside counsel. Not NANOG. -Hammer- I was a normal American nerd -Jack Herer On 5/24/2012 7:50 AM, not common wrote: Hello, I am looking for some guidance on full packet inspection at the ISP level. Is there any regulations that prohibit or provide guidance on this? .
Re: ISPs and full packet inspection
The problem is that it is strictly a jurisdictional question. I'm not trying to throw it back at you. But I can't advise you w/o knowing the specifics of your ISP which I don't want to know. Does that make sense? What country? State? Where's your customer base? Do you have multiple carriers? Do you service DOD? Outside of US? Do you service EU? SWIFT (Financial wires?) etc? Mainly consumer? Commercial? The list could go on. If you are being prodded by legal on this question then my advice would be to tell them that they have to provide that direction. If you are being prodded by technology my advice would be to direct them to legal. You should be picking up a pattern here -Hammer- I was a normal American nerd -Jack Herer On 5/24/2012 8:13 AM, not common wrote: Thanks guys, I am looking for stuff to bring to my legal team (which is one guy, that can't spell IP) and VPs. There has to be some thing out there or is this really a hands of topic? On Thu, May 24, 2012 at 8:58 AM, -Hammer- bhmc...@gmail.com mailto:bhmc...@gmail.com wrote: You should be discussing this with inside counsel. Not NANOG. -Hammer- I was a normal American nerd -Jack Herer On 5/24/2012 7:50 AM, not common wrote: Hello, I am looking for some guidance on full packet inspection at the ISP level. Is there any regulations that prohibit or provide guidance on this? .
Re: ISPs and full packet inspection
And if your legal can't figure it out that is exactly what outside counsel is for. -Hammer- I was a normal American nerd -Jack Herer On 5/24/2012 8:22 AM, -Hammer- wrote: The problem is that it is strictly a jurisdictional question. I'm not trying to throw it back at you. But I can't advise you w/o knowing the specifics of your ISP which I don't want to know. Does that make sense? What country? State? Where's your customer base? Do you have multiple carriers? Do you service DOD? Outside of US? Do you service EU? SWIFT (Financial wires?) etc? Mainly consumer? Commercial? The list could go on. If you are being prodded by legal on this question then my advice would be to tell them that they have to provide that direction. If you are being prodded by technology my advice would be to direct them to legal. You should be picking up a pattern here -Hammer- I was a normal American nerd -Jack Herer On 5/24/2012 8:13 AM, not common wrote: Thanks guys, I am looking for stuff to bring to my legal team (which is one guy, that can't spell IP) and VPs. There has to be some thing out there or is this really a hands of topic? On Thu, May 24, 2012 at 8:58 AM, -Hammer- bhmc...@gmail.com mailto:bhmc...@gmail.com wrote: You should be discussing this with inside counsel. Not NANOG. -Hammer- I was a normal American nerd -Jack Herer On 5/24/2012 7:50 AM, not common wrote: Hello, I am looking for some guidance on full packet inspection at the ISP level. Is there any regulations that prohibit or provide guidance on this? .
Re: ISPs and full packet inspection
Very nice Patrick -Hammer- I was a normal American nerd -Jack Herer On 5/24/2012 8:19 AM, Patrick Darden wrote: 0. General Reference http://en.wikipedia.org/wiki/Deep_packet_inspection#DPI_at_network.2FInternet_service_providers e.g. Lawful Intercept 1. network neutrality -- lots of possible laws coming up, http://en.wikipedia.org/wiki/Network_neutrality#Law_in_the_United_States http://www.sans.org/reading_room/whitepapers/policyissues/net-neutrality-rest-peace_33809 2. intellectual property -- all the sopa/pipa/etc. specifically privacy invasion http://en.wikipedia.org/wiki/Stop_Online_Piracy_Act#Deep-packet_inspection_and_privacy 3. principle of implied responsibility -- if you change a data stream, it is implied you are responsible for it (i.e. administratively, editorially, etc.) 4. Check out the CISSP legal domain. Especially resources and references for it. Someone on your team should have this certification. http://www.amazon.com/CISSP-Boxed-Set-All---One/dp/0071768459/ref=sr_1_1?ie=UTF8qid=1337865477sr=8-1 5. The EFF might be able to help you. WRT Privacy espec. 6. SANS has tons of references. www.sans.org 7. Get with a lawyer who is network-aware. Good luck with that. Maybe try to find a lawyer with a CISSP cert? --Patrick Darden On 05/24/2012 08:50 AM, not common wrote: Hello, I am looking for some guidance on full packet inspection at the ISP level. Is there any regulations that prohibit or provide guidance on this? .
Re: Squeezing IPs out of ARIN
I can say that I recently completed the purchase of a large IPv6 block. We've had several large V4 blocks for years and got them with very little effort. For this block, we had to provide a detailed list of all our physical locations as well as how the IP schema would be utilized. I also had to provide site drawings (scrubbed visios) showing my topology layout to justify my additional ASNs. It was not a harsh ordeal. ARIN was very professional about it. But it was a lot more paperwork than what I've needed in the past. None of it seemed unreasonable. We just had to work out NDAs and whatnot so I could share more detailed information with them. -Hammer- I was a normal American nerd -Jack Herer On 4/25/2012 10:34 AM, Owen DeLong wrote: There is not a new policy added on to prevent hoarding. What is required is what has been required for several years. Utilization information and proper justification. If you are seeking an ISP allocation, then, reassignment (customer) information is in fact part of that utilization information. Owen On Apr 25, 2012, at 8:22 AM, Kenneth McRae wrote: Negative.. I have never had to provide end user information. I have been required to provide utilization information. I am sure this policy is and add-on to make it more difficult to prevent hoarding.. On Tue, Apr 24, 2012 at 10:47 AM, Jonathan Lassoffj...@thejof.com wrote: On Tue, Apr 24, 2012 at 10:32 AM,ad...@thecpaneladmin.com wrote: Anyone have any tips for getting IPs from ARIN? For an end-user allocation they are requesting that we provide customer names for existing allocations, which is information that will take a while to obtain. They are insisting that this is standard process and something that everyone does when requesting IPs. Has anyone actually had to do this? Indeed. It's worked this way for a long time. When starting a new organization, there's a bit of a chicken and egg problem with IP space. If anyone could get IP space just for asking for it, it would have been consumed too quickly. So, organizations must first get some space assigned to them from an upstream provider and begin using it. At some point the current usage and growth rate of the assigned space will justify a direct allocation. Then, you can renumber into your new space and be totally independent. Cheers, jof -- Best Regards, Kenneth McRae *Sr. Network Engineer* kenneth.mc...@dreamhost.com Ph: 323-375-3814 www.dreamhost.com
Re: Squeezing IPs out of ARIN
purchase/lease/rent/titlepawn/etc. We paid for and got a block of IPs. -Hammer- I was a normal American nerd -Jack Herer On 4/25/2012 11:13 AM, valdis.kletni...@vt.edu wrote: On Wed, 25 Apr 2012 10:54:39 -0500, -Hammer- said: I can say that I recently completed the purchase of a large IPv6 block. purchase??!?
Re: Squeezing IPs out of ARIN
Sorry everyone. Bad choice of words. I simply meant they have their money and we have our allocation. Stand down. Move along. Nothing to see here. -Hammer- I was a normal American nerd -Jack Herer On 4/25/2012 11:55 AM, Owen DeLong wrote: No, you didn't. You may have completed the acquisition of a large IPv6 block, but you did not purchase it. Number resources are not property and cannot be bought and/or sold. What you pay to ARIN pays for registration services (the registration of the numbers, not the numbers themselves). While I realize that in practice this may seem like a distinction without a difference, there are major legal and practical implications to this fact that are quite important to the very underpinnings of how the internet works. Owen On Apr 25, 2012, at 8:54 AM, -Hammer- wrote: I can say that I recently completed the purchase of a large IPv6 block. We've had several large V4 blocks for years and got them with very little effort. For this block, we had to provide a detailed list of all our physical locations as well as how the IP schema would be utilized. I also had to provide site drawings (scrubbed visios) showing my topology layout to justify my additional ASNs. It was not a harsh ordeal. ARIN was very professional about it. But it was a lot more paperwork than what I've needed in the past. None of it seemed unreasonable. We just had to work out NDAs and whatnot so I could share more detailed information with them. -Hammer- I was a normal American nerd -Jack Herer On 4/25/2012 10:34 AM, Owen DeLong wrote: There is not a new policy added on to prevent hoarding. What is required is what has been required for several years. Utilization information and proper justification. If you are seeking an ISP allocation, then, reassignment (customer) information is in fact part of that utilization information. Owen On Apr 25, 2012, at 8:22 AM, Kenneth McRae wrote: Negative.. I have never had to provide end user information. I have been required to provide utilization information. I am sure this policy is and add-on to make it more difficult to prevent hoarding.. On Tue, Apr 24, 2012 at 10:47 AM, Jonathan Lassoffj...@thejof.com wrote: On Tue, Apr 24, 2012 at 10:32 AM,ad...@thecpaneladmin.com wrote: Anyone have any tips for getting IPs from ARIN? For an end-user allocation they are requesting that we provide customer names for existing allocations, which is information that will take a while to obtain. They are insisting that this is standard process and something that everyone does when requesting IPs. Has anyone actually had to do this? Indeed. It's worked this way for a long time. When starting a new organization, there's a bit of a chicken and egg problem with IP space. If anyone could get IP space just for asking for it, it would have been consumed too quickly. So, organizations must first get some space assigned to them from an upstream provider and begin using it. At some point the current usage and growth rate of the assigned space will justify a direct allocation. Then, you can renumber into your new space and be totally independent. Cheers, jof -- Best Regards, Kenneth McRae *Sr. Network Engineer* kenneth.mc...@dreamhost.com Ph: 323-375-3814 www.dreamhost.com
Re: Squeezing IPs out of ARIN
Killing me softly Owen -Hammer- I was a normal American nerd -Jack Herer On 4/25/2012 1:15 PM, Owen DeLong wrote: Nope... You paid for and received registration services for a block of IP Addresses. Anyone can use those integers for many purposes, but, only you are registered to use them as topological identifiers on the internet according to ARIN and the other RIRs. Owen On Apr 25, 2012, at 10:59 AM, -Hammer- wrote: purchase/lease/rent/titlepawn/etc. We paid for and got a block of IPs. -Hammer- I was a normal American nerd -Jack Herer On 4/25/2012 11:13 AM, valdis.kletni...@vt.edu wrote: On Wed, 25 Apr 2012 10:54:39 -0500, -Hammer- said: I can say that I recently completed the purchase of a large IPv6 block. purchase??!?
Re: Looking for some diversity in Alabama that does not involve ATT Fiber
Joe, We have a wide variety of both Internet and MPLS (WAN) circuits in Alabama from ATT and ITC/Deltacom (Now Earthlink Business). They both have a significant footprint in Alabama. Check with Earthlink Business. -Hammer- I was a normal American nerd -Jack Herer On 3/21/2012 10:44 AM, Joe Maimon wrote: Hey All, I have a site in Alabama that could really use some additional diversity, but apparently ATT fiber is the only game in town. If anybody has any options, such as fixed wireless in the 10-50mbs, please reply to me, off-list. Best, Joe .
Re: Whitelist of update servers
Can you be a little more specific? Otherwise I think your answer would be The Internet -Hammer- I was a normal American nerd -Jack Herer On 3/12/2012 3:05 PM, Maverick wrote: Is there a whitelist that applications have to talk to in order to update themselves?
Re: root zone stats
Shouldn't eh be Canada and not Western Sahara? -Hammer- I was a normal American nerd -Jack Herer On 3/12/2012 3:10 PM, Marco Davids (Prive) wrote: On Mon, 12 Mar 2012, Marco Davids (Prive) wrote: Some nice info here, too: http://bgp.he.net/report/dns .cw seems to be missing. Oops, it isn't... it's just not wehere I expected it. -- Marco
Re: Clueful road runner contact?
Wile E Coyote knows all about him. Sorry, couldn't resist. -Hammer- I was a normal American nerd -Jack Herer On 3/5/2012 3:26 PM, goe...@anime.net wrote: Anyone have a clueful road runner contact? -Dan
Re: Cisco CAT6500 IOS Simulator
I'm sure that virtualizing the sup would be possible. But having to come up with all the line cards would be a nightmare. I'd love for someone Internal to tell me I'm wrong but until we can get a 3560 or a 3750X on Dynamips I wouldn't push for a 6500 or a Nexus. -Hammer- I was a normal American nerd -Jack Herer On 2/23/2012 3:00 AM, Carlos Asensio wrote: Hi Hammer, Thanks for your answer. That was pretty much what I was thinking. Thanks to all the offers I've received off-line :). Best regards, Carlos. -Mensaje original- De: -Hammer- [mailto:bhmc...@gmail.com] Enviado el: miércoles, 22 de febrero de 2012 16:56 Para: nanog@nanog.org Asunto: Re: Cisco CAT6500 IOS Simulator NO. There is no method. Go to Ebay and buy one. Sorry. Or if you are a big enough customer you can ask Cisco to mock up your solution in one of their labs. -Hammer- I was a normal American nerd -Jack Herer On 2/22/2012 9:48 AM, Hank Nussbacher wrote: On Wed, 22 Feb 2012, Carlos Asensio wrote: Not supported: http://www.gns3.net/hardware-emulated/ -Hank Hi John, Thanks for your answer but, as far as I know, with GNS3 we can't run a CAT6500 IOS. Any alternative? Cheers, Carlos. -Mensaje original- De: John Kreno [mailto:john.kr...@gmail.com] Enviado el: miércoles, 22 de febrero de 2012 15:25 Para: Carlos Asensio Asunto: Re: Cisco CAT6500 IOS Simulator Try GNS 3 On Wed, Feb 22, 2012 at 6:53 AM, Carlos Asensiocasen...@nexica.com wrote: Hi there, Anyone know a way of simulate a Cisco CAT6500 IOS? We're trying to deploy a lab of our production environment. Thanks in advance, Carlos.
Re: Cisco CAT6500 IOS Simulator
NO. There is no method. Go to Ebay and buy one. Sorry. Or if you are a big enough customer you can ask Cisco to mock up your solution in one of their labs. -Hammer- I was a normal American nerd -Jack Herer On 2/22/2012 9:48 AM, Hank Nussbacher wrote: On Wed, 22 Feb 2012, Carlos Asensio wrote: Not supported: http://www.gns3.net/hardware-emulated/ -Hank Hi John, Thanks for your answer but, as far as I know, with GNS3 we can't run a CAT6500 IOS. Any alternative? Cheers, Carlos. -Mensaje original- De: John Kreno [mailto:john.kr...@gmail.com] Enviado el: miércoles, 22 de febrero de 2012 15:25 Para: Carlos Asensio Asunto: Re: Cisco CAT6500 IOS Simulator Try GNS 3 On Wed, Feb 22, 2012 at 6:53 AM, Carlos Asensio casen...@nexica.com wrote: Hi there, Anyone know a way of simulate a Cisco CAT6500 IOS? We're trying to deploy a lab of our production environment. Thanks in advance, Carlos.
Re: WW: Colo Vending Machine
Can someone give me a link or part number on the Raritan site? I see LCD consoles but they are the generic slide out versions. Looking for the netbook concept referenced below -Hammer- I was a normal American nerd -Jack Herer On 2/21/2012 3:51 AM, Owen DeLong wrote: +1 for Raritan... I was very happy with their KVM switches at my last job. Owen On Feb 20, 2012, at 7:40 AM, Matthew Black wrote: Take a look at Raritan. We use their product to gain remote access to system consoles. No more driving 100s of miles. Ok, it would be 200 feet for us. matthew black information technology services bh-188 california state university, long beach -Original Message- From: Jon Lewis [mailto:jle...@lewis.org] Sent: Monday, February 20, 2012 7:35 AM To: nanog@nanog.org Subject: Re: WW: Colo Vending Machine On Sat, 18 Feb 2012, John Osmon wrote: At my $JOB[-1] they laughed at me when I pulled a Wyse out of the trash bin and stuck it on a spare crash cart. Then I fixed something while they were still looking for USB-Serial, etc. Speaking of that sort of thing, I'd really LOVE if there were a device about the size of a netbook that could be hooked up to otherwise headless machines in colos that would give you keyboard, video mouse. i.e. a folding netbook shaped VGA monitor with USB keyboard and touchpad. I know there are folding rackmount versions of this (i.e. from Dell), but I want something far more portable. Twice in the past month, I'd had to drive 100+ miles to a remote colo and took a full size flat panel monitor and keyboard with me. Has anyone actually built this yet? -- Jon Lewis, MCP :) | I route Senior Network Engineer | therefore you are Atlantic Net| _ http://www.lewis.org/~jlewis/pgp for PGP public key_
Re: Common operational misconceptions
This list is awesome. Is anyone consolidating it? I'm still catching up on the thread -Hammer- I was a normal American nerd -Jack Herer On 2/17/2012 1:05 AM, Carsten Bormann wrote: On Feb 17, 2012, at 07:50, Paul Graydon wrote: what OSI means Yet another common misconception popping up: -- You can talk about the OSI model in the present tense (That said -- yes, it is still useful as a set of simple terms for certain combinations of functions. It is also still useful as a way to calibrate your gut feeling of what is going on in a network. Just never expect OSI terms to have a precise meaning in today's networks. 1978 is now a third of a century ago... If you need precision, you need to spell out what you mean in today's terms.) Grüße, Carsten
Re: Common operational misconceptions
Let me simplify that. If you are over 35 you know how to troubleshoot. Yes, I'm going to get flamed. Yes, there are exceptions in both directions. -Hammer- I was a normal American nerd -Jack Herer On 2/17/2012 8:29 AM, Leo Bicknell wrote: In a message written on Thu, Feb 16, 2012 at 08:50:11PM -1000, Paul Graydon wrote: At the same time, it's shocking how many network people I come across with no real grasp of even what OSI means by each layer, even if it's only in theory. Just having a grasp of that makes all the world of difference when it comes to troubleshooting. Start at layer 1 and work upwards (unless you're able to make appropriate intuitive leaps.) Is it physically connected? Are the link lights flashing? Can traffic route to it, etc. etc. I wouldn't call it a misconception, but I want to echo Paul's comment. I would venture over 90% of the engineers I work with have no idea how to troubleshoot properly. Thinking back to my own education, I don't recall anyone in highschool or college attempting to teach troubleshooting skills. Most classes teach you how to build things, not deal with them when they are broken. The basic skills are probably obvious to someone who might design course material if they sat down and thought about how to teach troubleshooting. However, there is one area that may not be obvious. There's also a group management problem. Many times troubleshooting is done with multiple folks on the phone (say, customer, ISP and vendor). Not only do you have to know how to troubleshoot, but how to get everyone on the same page so every possible cause isn't tested 3 times. I think all college level courses should include a break/fix exercise/module after learning how to build something, and much of that should be done in a group enviornment.
Re: Common operational misconceptions
Well said. An American tragedy. -Hammer- I was a normal American nerd -Jack Herer On 2/17/2012 9:01 AM, Brandt, Ralph wrote: Hammer, you are at least 75% right. You will get flamed and in most cases, the 35 year age is close to right. But then in Programming where I spent most of my IT time since Feb 1963, few current programmers have skills that they need to be really successful. Same thing. It is the fault of the educational system like one school district here that teaches Alice, VB and then two days of C++ to High School Kids. Heck, they will fiddle with Alice on their own. They need some exposure to one of the SQL's and how to build some tables, maybe a good script language, some command line on SQL+ and unix or PostgresSQL and linux if the school can't afford the unix licenses. The fun and games is more important than the substance and it goes into the colleges in spades. BTW, I am a school board member who votes 1:8 often on things But let me give you a perspective, one of the board members called Golf an Essential Life Skill. Maybe, but how about balancing a checkbook... Ralph Brandt Communications Engineer HP Enterprise Services Telephone +1 717.506.0802 FAX +1 717.506.4358 Email ralph.bra...@pateam.com 5095 Ritter Rd Mechanicsburg PA 17055 -Original Message- From: -Hammer- [mailto:bhmc...@gmail.com] Sent: Friday, February 17, 2012 9:52 AM To: nanog@nanog.org Subject: Re: Common operational misconceptions Let me simplify that. If you are over 35 you know how to troubleshoot. Yes, I'm going to get flamed. Yes, there are exceptions in both directions. -Hammer- I was a normal American nerd -Jack Herer On 2/17/2012 8:29 AM, Leo Bicknell wrote: In a message written on Thu, Feb 16, 2012 at 08:50:11PM -1000, Paul Graydon wrote: At the same time, it's shocking how many network people I come across with no real grasp of even what OSI means by each layer, even if it's only in theory. Just having a grasp of that makes all the world of difference when it comes to troubleshooting. Start at layer 1 and work upwards (unless you're able to make appropriate intuitive leaps.) Is it physically connected? Are the link lights flashing? Can traffic route to it, etc. etc. I wouldn't call it a misconception, but I want to echo Paul's comment. I would venture over 90% of the engineers I work with have no idea how to troubleshoot properly. Thinking back to my own education, I don't recall anyone in highschool or college attempting to teach troubleshooting skills. Most classes teach you how to build things, not deal with them when they are broken. The basic skills are probably obvious to someone who might design course material if they sat down and thought about how to teach troubleshooting. However, there is one area that may not be obvious. There's also a group management problem. Many times troubleshooting is done with multiple folks on the phone (say, customer, ISP and vendor). Not only do you have to know how to troubleshoot, but how to get everyone on the same page so every possible cause isn't tested 3 times. I think all college level courses should include a break/fix exercise/module after learning how to build something, and much of that should be done in a group enviornment.
Re: Common operational misconceptions
Mario, I was kinda having fun and kinda not. My point is that the 40-50 year olds that were doing this 30 years ago grew up understanding things in order. Bits. Bytes. KiloBits. KiloBytes. (Some folks still get those confused). Hex. etc. Move on to the OSI model and it's the same thing. Voltage. Amplitude. Binary. etc. I think that this generation that I'm referring to is a great generation because we were at the beginning of the Internet blooming. There are folks on this forum that go back further. Into DARPA. Before DARPA was just chapter 1 one every single Cisco Press book. They have a unique understanding of the layers. I had that understanding in my 20s. The technology is so complicated these days that many folks miss those fundamentals and go right into VSS on the 6500s or MPLS over Juniper. In the end, it all comes in time. -Hammer- I was a normal American nerd -Jack Herer On 2/17/2012 9:12 AM, Mario Eirea wrote: Well, I will argue this. I think the important factor in any troubleshooting is having a real understanding of how the system works. That is, how different things interact with each others to achieve a specific goal. The biggest problem I see is that many people understand understand the individual parts but when it comes to understanding the system as a whole they fall miserably short. A short example, probably not the best but the one that comes to mind right now: Someone replaces a device on the network with a new one. They give it the same IP address as the old device. They don't understand why the router cant communicate with it at first and then starts working. The people understand ARP, but cant correlate one event with another. I guess if your 35 you have seen this at least once and can fix it. But what happens if you have never seen this problem or a related one? At this point your going to have to really troubleshoot, not just go on experience. Mario Eirea From: -Hammer- [bhmc...@gmail.com] Sent: Friday, February 17, 2012 9:52 AM To: nanog@nanog.org Subject: Re: Common operational misconceptions Let me simplify that. If you are over 35 you know how to troubleshoot. Yes, I'm going to get flamed. Yes, there are exceptions in both directions. -Hammer- I was a normal American nerd -Jack Herer On 2/17/2012 8:29 AM, Leo Bicknell wrote: In a message written on Thu, Feb 16, 2012 at 08:50:11PM -1000, Paul Graydon wrote: At the same time, it's shocking how many network people I come across with no real grasp of even what OSI means by each layer, even if it's only in theory. Just having a grasp of that makes all the world of difference when it comes to troubleshooting. Start at layer 1 and work upwards (unless you're able to make appropriate intuitive leaps.) Is it physically connected? Are the link lights flashing? Can traffic route to it, etc. etc. I wouldn't call it a misconception, but I want to echo Paul's comment. I would venture over 90% of the engineers I work with have no idea how to troubleshoot properly. Thinking back to my own education, I don't recall anyone in highschool or college attempting to teach troubleshooting skills. Most classes teach you how to build things, not deal with them when they are broken. The basic skills are probably obvious to someone who might design course material if they sat down and thought about how to teach troubleshooting. However, there is one area that may not be obvious. There's also a group management problem. Many times troubleshooting is done with multiple folks on the phone (say, customer, ISP and vendor). Not only do you have to know how to troubleshoot, but how to get everyone on the same page so every possible cause isn't tested 3 times. I think all college level courses should include a break/fix exercise/module after learning how to build something, and much of that should be done in a group enviornment.
Re: Common operational misconceptions
If you do, please share it. Thank you. -Hammer- I was a normal American nerd -Jack Herer On 2/17/2012 9:36 AM, Jared Mauch wrote: On Feb 17, 2012, at 9:29 AM, -Hammer- wrote: This list is awesome. Is anyone consolidating it? I'm still catching up on the thread I was thinking of making a checklist out of it. - Jared
Re: Common operational misconceptions
I give I give. I should have. But I left a bunch of stuff out and the folks that I'm referring to know it. One of the fun things I do with network guys is ask them about canonical bit ordering across routers. Always causes the room to go quiet. Them someone of the appropriate age group will speak up after he's done laughing. The best thing I have ever figured out to tell less experienced (I didn't say younger) folks is to start at the bottom of the stack and work your way up. That's the way many of us troubleshoot. Is the cable on the floor? That's bad. If not, is the ARP entry incomplete? That's bad. If not, is the route missing? That's bad. If not, can you reach the route? Try this radical command that was invented by Steve Jobs while working on his first IPhone (They won't know who Vint Cerf or anyone else is and by using Steves name they will trust you)(I run Android): telnet 1.2.3.4 1433 What? It answered? So the SQL service is running? Then it ain't the network dude So many times people don't pick up on that. But when they do, it's like a light bulb went off and they see the world differently. Like subnetting -Hammer- I was a normal American nerd -Jack Herer On 2/17/2012 12:49 PM, Owen DeLong wrote: Now, come on... If you're in the 40-50 range, you should have put octal before hex. :p Owen (Who grew up on a PDP-11 in his high-school and still remembers 1777300 and its significance to anyone who has used a larger PDP system) On Feb 17, 2012, at 7:51 AM, -Hammer- wrote: Mario, I was kinda having fun and kinda not. My point is that the 40-50 year olds that were doing this 30 years ago grew up understanding things in order. Bits. Bytes. KiloBits. KiloBytes. (Some folks still get those confused). Hex. etc. Move on to the OSI model and it's the same thing. Voltage. Amplitude. Binary. etc. I think that this generation that I'm referring to is a great generation because we were at the beginning of the Internet blooming. There are folks on this forum that go back further. Into DARPA. Before DARPA was just chapter 1 one every single Cisco Press book. They have a unique understanding of the layers. I had that understanding in my 20s. The technology is so complicated these days that many folks miss those fundamentals and go right into VSS on the 6500s or MPLS over Juniper. In the end, it all comes in time. -Hammer- I was a normal American nerd -Jack Herer On 2/17/2012 9:12 AM, Mario Eirea wrote: Well, I will argue this. I think the important factor in any troubleshooting is having a real understanding of how the system works. That is, how different things interact with each others to achieve a specific goal. The biggest problem I see is that many people understand understand the individual parts but when it comes to understanding the system as a whole they fall miserably short. A short example, probably not the best but the one that comes to mind right now: Someone replaces a device on the network with a new one. They give it the same IP address as the old device. They don't understand why the router cant communicate with it at first and then starts working. The people understand ARP, but cant correlate one event with another. I guess if your 35 you have seen this at least once and can fix it. But what happens if you have never seen this problem or a related one? At this point your going to have to really troubleshoot, not just go on experience. Mario Eirea From: -Hammer- [bhmc...@gmail.com] Sent: Friday, February 17, 2012 9:52 AM To: nanog@nanog.org Subject: Re: Common operational misconceptions Let me simplify that. If you are over 35 you know how to troubleshoot. Yes, I'm going to get flamed. Yes, there are exceptions in both directions. -Hammer- I was a normal American nerd -Jack Herer On 2/17/2012 8:29 AM, Leo Bicknell wrote: In a message written on Thu, Feb 16, 2012 at 08:50:11PM -1000, Paul Graydon wrote: At the same time, it's shocking how many network people I come across with no real grasp of even what OSI means by each layer, even if it's only in theory. Just having a grasp of that makes all the world of difference when it comes to troubleshooting. Start at layer 1 and work upwards (unless you're able to make appropriate intuitive leaps.) Is it physically connected? Are the link lights flashing? Can traffic route to it, etc. etc. I wouldn't call it a misconception, but I want to echo Paul's comment. I would venture over 90% of the engineers I work with have no idea how to troubleshoot properly. Thinking back to my own education, I don't recall anyone in highschool or college attempting to teach troubleshooting skills. Most classes teach you how to build things, not deal with them when they are broken. The basic skills are probably obvious to someone who might design course material if they sat down and thought about how to teach troubleshooting. However, there is one area
Re: Common operational misconceptions
Well put and great example Owen. -Hammer- I was a normal American nerd -Jack Herer On 2/17/2012 12:59 PM, Owen DeLong wrote: This reminds me of what I think is the biggest root misconception of the 20th and 21st centuries: Rapid step-by-step training can replace conceptual education on the fundamentals. In other words, we have moved from the old-school of teaching people why things work and how they work to a newer school of teaching people how to complete specific tasks. This has had the following negative effects, IMHO: 1. When the only tool you have is a hammer, you try to mold every problem into a nail. 2. When you only know a procedure for doing something and don't understand the fundamentals of why X is supposed to occur at step Y, then when you get result A instead of X, your only options are to either continue to step Z and hope everything turns out OK, or, go back to an earlier step and hope everything works this time. 3. Troubleshooting skills are limited to knowing the number of the vendor's help desk. I once worked with a director of QA that epitomized this. It was a small company, so, as director, he was directly responsible for most of the tasks in the QA lab. He was meticulous in following directions which was a good thing. However, when he reached a step where he did not get the expected result, he was limited to telling the engineers that the test failed at step X and would not make any effort to identify or resolve the problem and would literally block the entire QA process waiting for engineering to resolve the issue before he would continue testing. Worse, he would not test independent pieces of the system in parallel, so, when he blocked on one system failing, he wouldn't test the others, either. Further investigation revealed that this was because he didn't actually know which systems were or were not dependent on each other. He was so completely immersed in the procedural school of thought that he was literally unwilling to accept conceptual knowledge or develop an understanding of the theory and principles of operation of any of the systems. Owen On Feb 17, 2012, at 8:13 AM, Mario Eirea wrote: I definitely understand and agree with what you saying. Actually, most my friends are over 50 years old... I do agree with you on the generational statement. My argument was that many people over 35 have no idea what they are doing, and some under 35 do know what they are doing. On thing is for sure, experience goes a long way. The importance is knowing the fundamentals and putting it all together (a skill that has been lost in recent times) I have a lot to say about the current generation of people growing up in this country, but that's a whole other thread in a whole other list. :-) Mario Eirea
Re: Common operational misconceptions
Still buzzing over that cheap auto insurance eh? :) Wait till people stop carding you. -Hammer- I was a normal American nerd -Jack Herer On 2/17/2012 1:42 PM, Ray Soucy wrote: As someone who was born in 1984 I respectfully disagree. ;-) On Fri, Feb 17, 2012 at 9:52 AM, -Hammer-bhmc...@gmail.com wrote: Let me simplify that. If you are over 35 you know how to troubleshoot. Yes, I'm going to get flamed. Yes, there are exceptions in both directions. -Hammer- I was a normal American nerd -Jack Herer On 2/17/2012 8:29 AM, Leo Bicknell wrote: In a message written on Thu, Feb 16, 2012 at 08:50:11PM -1000, Paul Graydon wrote: At the same time, it's shocking how many network people I come across with no real grasp of even what OSI means by each layer, even if it's only in theory. Just having a grasp of that makes all the world of difference when it comes to troubleshooting. Start at layer 1 and work upwards (unless you're able to make appropriate intuitive leaps.) Is it physically connected? Are the link lights flashing? Can traffic route to it, etc. etc. I wouldn't call it a misconception, but I want to echo Paul's comment. I would venture over 90% of the engineers I work with have no idea how to troubleshoot properly. Thinking back to my own education, I don't recall anyone in highschool or college attempting to teach troubleshooting skills. Most classes teach you how to build things, not deal with them when they are broken. The basic skills are probably obvious to someone who might design course material if they sat down and thought about how to teach troubleshooting. However, there is one area that may not be obvious. There's also a group management problem. Many times troubleshooting is done with multiple folks on the phone (say, customer, ISP and vendor). Not only do you have to know how to troubleshoot, but how to get everyone on the same page so every possible cause isn't tested 3 times. I think all college level courses should include a break/fix exercise/module after learning how to build something, and much of that should be done in a group enviornment.
Re: Common operational misconceptions
I couldn't argue with any of that. Again, there are exceptions on either side. -Hammer- I was a normal American nerd -Jack Herer On 2/17/2012 2:40 PM, Ray Soucy wrote: Maybe ;-) I don't think it's an age thing, though. The number of people who have a real interest in technology, and how things work under the hood hasn't changed much. I know people 10 years younger than me who can keep up with the best of us, and people 10 years older who are complete failures at technology. People like us have always been a fairly small number. What has changed, though, is that there are a lot more young people who think they have technology skills; perhaps as a side effect of growing up in a world where the Internet has always been there. Naturally, we have a lot of people filling IT spots that aren't qualified and lack the basic knowledge of how complex systems are built. To troubleshoot effectively, you need to be able to break down systems into their components and isolate the problem; and a lot of people just don't have the background to be able to do that because they never cared to do so. It's just a paycheck to them. Those of us in my age group were lucky enough to be around for the transition from dial-up BBS, to dial-up Internet, to broadband. As a networking geek I don't think I could ask for a better year to be born, really. It's always been exciting. These days I'm playing with DWDM and a state wide RE network in a state that established dark fiber as a public utility; doesn't get much better than that. I'd say the future is pretty bright. ;-) On Fri, Feb 17, 2012 at 3:26 PM, -Hammer-bhmc...@gmail.com wrote: Still buzzing over that cheap auto insurance eh? :) Wait till people stop carding you. -Hammer- I was a normal American nerd -Jack Herer On 2/17/2012 1:42 PM, Ray Soucy wrote: As someone who was born in 1984 I respectfully disagree. ;-) On Fri, Feb 17, 2012 at 9:52 AM, -Hammer-bhmc...@gmail.comwrote: Let me simplify that. If you are over 35 you know how to troubleshoot. Yes, I'm going to get flamed. Yes, there are exceptions in both directions. -Hammer- I was a normal American nerd -Jack Herer On 2/17/2012 8:29 AM, Leo Bicknell wrote: In a message written on Thu, Feb 16, 2012 at 08:50:11PM -1000, Paul Graydon wrote: At the same time, it's shocking how many network people I come across with no real grasp of even what OSI means by each layer, even if it's only in theory. Just having a grasp of that makes all the world of difference when it comes to troubleshooting. Start at layer 1 and work upwards (unless you're able to make appropriate intuitive leaps.) Is it physically connected? Are the link lights flashing? Can traffic route to it, etc. etc. I wouldn't call it a misconception, but I want to echo Paul's comment. I would venture over 90% of the engineers I work with have no idea how to troubleshoot properly. Thinking back to my own education, I don't recall anyone in highschool or college attempting to teach troubleshooting skills. Most classes teach you how to build things, not deal with them when they are broken. The basic skills are probably obvious to someone who might design course material if they sat down and thought about how to teach troubleshooting. However, there is one area that may not be obvious. There's also a group management problem. Many times troubleshooting is done with multiple folks on the phone (say, customer, ISP and vendor). Not only do you have to know how to troubleshoot, but how to get everyone on the same page so every possible cause isn't tested 3 times. I think all college level courses should include a break/fix exercise/module after learning how to build something, and much of that should be done in a group enviornment.
Re: Common operational misconceptions
Switching VS Bridging Collision Domain VS Broadcast Domain L2 in general is the layer that the new folks often misunderstand. I once had someone ask me what a hub was. That pretty much told me how old I was -Hammer- I was a normal American nerd -Jack Herer On 2/15/2012 2:47 PM, John Kristoff wrote: Hi friends, As some of you may know, I occasionally teach networking to college students and I frequently encounter misconceptions about some aspect of networking that can take a fair amount of effort to correct. For instance, a topic that has come up on this list before is how the inappropriate use of classful terminology is rampant among students, books and often other teachers. Furthermore, the terminology isn't even always used correctly in the original context of classful addressing. I have a handful of common misconceptions that I'd put on a top 10 list, but I'd like to solicit from this community what it considers to be the most annoying and common operational misconceptions future operators often come at you with. I'd prefer replies off-list and can summarize back to the list if there is interest. John
Re: Common operational misconceptions
Packet loss at hop X in traceroute/mtr does not necessarily point to a problem at hop X. Good one. Also, security as a whole seems to be confusing for folks. They've seen Firewall with Harrison Ford and therefore the FW is some secret master voodoo widget that only people from Area 51 can operate. They don't understand header manipulation vs payload. -Hammer- I was a normal American nerd -Jack Herer On 2/15/2012 3:52 PM, Dan White wrote: Packet loss at hop X in traceroute/mtr does not necessarily point to a problem at hop X.
Re: Dear RIPE: Please don't encourage phishing
Leo, This has nothing to do with the competency of the folks on the nanog list. It's a safe rule in general. Why? Because the stupid on the Internet outnumbers all of us. It's just easier to not send clickable links then it is to have the call center lit up because your users are getting hijacked. -Hammer- I was a normal American nerd -Jack Herer On 2/10/2012 11:51 AM, valdis.kletni...@vt.edu wrote: On Fri, 10 Feb 2012 09:37:01 PST, Leo Bicknell said: We know how to sign and encrypt web sites. We know how to sign and encrypt e-mail. We even know how to compare keys between the web site and e-mail via a variety of mechanisms. We know how to sign DNS. Remind me again why we live in this sad word Randy (correcly) described? Obi-Wan Kenobi: (shocked) How could this have happened?? We're supposed to be smarter than this. Anakin Skywalker: Apparently not.
IPv6 dual stacking and route tables
So, we are preparing to add IPv6 to our multi-homed (separate routers and carriers with IBGP) multi-site business. Starting off with a lab of course. Circuits and hardware are a few months away. I'm doing the initial designs and having some delivery questions with the carrier(s). One interesting question came up. There was a thread I found (and have since lost) regarding what routes to accept. Currently, in IPv4, we accept a default route only from both carriers at both sites. Works fine. Optimal? No. Significantly negative impact? No. In IPv6, I have heard some folks say that in a multi-homed environment it is better to get the full IPv6 table fed into both of your edge routers. Ok. Fine. Then, The thread I was referring to said that it is also advisable to have the entire IPv4 table fed in parallel. Ok. I understand we are talking about completely separate protocols. So it's not a layer 3 issue. The reasoning was that DNS could potentially introduce some latency. If you have a specific route to a record but a less specific route to an A record the potential is for the trip to take longer. That was the premise of the thread. I swear I googled it for 20 minutes to link before giving up. Anyway, can anyone who's been thru this provide any opinions on why or why not it is important to accept the full IPv6 table AND the full IPv4 table? I have the hardware to handle it I'm just not sure long term what the reasoning would be for or against. Again, I'm an end customer. Not a carrier. So my concern is (A) my Internet facing applications and (B) my users who eventually will surf IPv6. Any guidance would be appreciated. Thanks. -Hammer- I was a normal American nerd -Jack Herer
Re: IPv6 dual stacking and route tables
Thanks Jeroen (and Ryan/Philip/Cameron/Justin/Etc.) for all the online and offline responses. That was fast. The struggle is that I'm having trouble seeing how/why it would matter other than potential latency on the IPv4 side. IPv6 conversations usually involve taking the full table when dealing with multi-homed/multi-site setups. IPv4 I didn't really consider (taking the full table) until I mentioned this to some of my vendors technical folks and it caused a lot of reflection. Not on the L3 part. Just on the DNS part. This appears to be a tough subject area when it comes to V4/V6 deployment strategies. The bottom line is that I'll take whatever the carrier feeds in V6. Just trying to see where I would be missing out by not doing the same in V4. Again, I have the hardware to support it and I really have no reason not to do it. I just want to be able to justify to myself why I'm doing it. A lot of kinks to work out this year. -Hammer- I was a normal American nerd -Jack Herer On 2/3/2012 2:28 PM, Jeroen Massar wrote: On 2012-02-03 21:10 , -Hammer- wrote: So, we are preparing to add IPv6 to our multi-homed (separate routers and carriers with IBGP) multi-site business. Starting off with a lab of course. Dear Hammer, Welcome to the 21th century. 2012 is going to the year (they claim, again ;) of IPv6 thus it is better to start before the big launch event that is this year, (of which there was also one back in in 2004: http://www.global-ipv6.org/ for the folks who have IPv6 for some time now ;) Better late than never some would say. Circuits and hardware are a few months away. I'm doing the initial designs and having some delivery questions with the carrier(s). One interesting question came up. There was a thread I found (and have since lost) regarding what routes to accept. Currently, in IPv4, we accept a default route only from both carriers at both sites. Works fine. Optimal? No. Significantly negative impact? No. In IPv6, I have heard some folks say that in a multi-homed environment it is better to get the full IPv6 table fed into both of your edge routers. Ok. Fine. Then, The thread I was referring to said that it is also advisable to have the entire IPv4 table fed in parallel. Ok. I understand we are talking about completely separate protocols. So it's not a layer 3 issue. The only advantage of more routes, in both IPv4 and IPv6 is that the path selection can be better. An end-host does not make this decision where packets flow, thus having a full route or not should not matter much, except that the route might be more optimal. No DNS involvement here yet. The trick comes with Happy-Eyeballs alike setups (especially Mac OSX Lion and up which does not follow that spec and in which it cannot be turned off either, which is awesome when you are debugging things...) Due to HE (Happy-Eyeballs) setups, which can differ per OS and per tool. Chrome has it's own HE implementation, thus if you run Chrome on a Mac you will have sometimes one sometimes another connect depending on if you are using Safari or Chrome for instance as Safari does use the system provided things. Ping will pick another again etc. It will be quite random all the time. The fun with the Mac OS X implementation is that it keeps a local cache of per-destination latency/speed information. If you thus have two default routes, be that IPv4 or IPv6, and your routers are swapping paths between either and thus don't have a stable outgoing path those latencies will vary and thus the pretty HE algorithms will be very confused. This is likely why your source recommended to have a full path, as per sub-prefix the path will become more stable and established than if you are doing hot-potato with two defaults. Greets, Jeroen
Re: IPv6 dual stacking and route tables
OK. Looking forward to getting the lab up. Since I can handle the volume I'll take both tables. At least in the lab. Looking forward to doing some experiments with DNS just to see what all the fuss is about. Looks like I'll need to order a Mac for the lab. No harm there. :) -Hammer- I was a normal American nerd -Jack Herer On 2/3/2012 2:47 PM, Jeroen Massar wrote: On 2012-02-03 21:37 , -Hammer- wrote: Thanks Jeroen (and Ryan/Philip/Cameron/Justin/Etc.) for all the online and offline responses. That was fast. The struggle is that I'm having trouble seeing how/why it would matter other than potential latency on the IPv4 side. IPv6 conversations usually involve taking the full table when dealing with multi-homed/multi-site setups. IPv4 I didn't really consider (taking the full table) until I mentioned this to some of my vendors technical folks and it caused a lot of reflection. Not on the L3 part. Just on the DNS part. This appears to be a tough subject area when it comes to V4/V6 deployment strategies. The bottom line is that I'll take whatever the carrier feeds in V6. Just trying to see where I would be missing out by not doing the same in V4. Again, I have the hardware to support it and I really have no reason not to do it. I just want to be able to justify to myself why I'm doing it. Why you want non-defaults in both IPv4 and IPv6: - more possible paths - less chances of blackholes. And of course, those paths will be more stable and you don't get hot-potato swapping between two defaults. And that in turn allows the Happy Eyeballs mechanisms to do their jobs much better as they keep a history per host or prefix, they assume IPv6 /48's and IPv4 /24's from what I have seen, in some cases. Greets, Jeroen
Re: Console Server Recommendation
Avocent Cyclades ACS. Enterprise class. http://www.avocent.com/Products/Category/Serial_Appliances.aspx -Hammer- I was a normal American nerd -Jack Herer On 1/30/2012 10:08 AM, Ray Soucy wrote: What are people using for console servers these days? We've historically used retired routers with ASYNC ports, but it's time for an upgrade. OpenGear seems to have some nice stuff, anyone else?
Re: XBOX 720: possible digital download mass service.
Here's your baseline: Sony Vita. They already tossed the UMD out with the PSP-GO and that failed miserably. Now they are trying again to go to digital only with the Vita. It's not the scale of PS3 or XBOX360 but it may be a good way to gauge the potential success of the concept. -Hammer- I was a normal American nerd -Jack Herer On 1/27/2012 7:34 AM, Jared Mauch wrote: It's already done on a similar scale when apple releases new software for their mobile devices. Just don't do it if you are on a low cap plan (eg: mobile, satellite etc). Caps will be the new market discriminator IMHO. Jared Mauch On Jan 27, 2012, at 3:35 AM, Teioscar.vi...@gmail.com wrote: Can internet in USA support that? Call of Duty 15 releases may 2014 and 30 million gamers start downloading a 20 GB files. Would the internet collapse like a house of cards?.
Re: XBOX 720: possible digital download mass service.
Now we are venturing OT but I thought the format was proprietary but you still had to get the content on the memory via the glorious Internet? Are you saying I can go to Gamestop and buy a stick with whatever game I'm looking for? Is that the plan? -Hammer- I was a normal American nerd -Jack Herer On 1/27/2012 8:13 AM, Eric Tykwinski wrote: The PS Vita still uses a proprietary memory card format, so it's not just download only. The best example of download only would be OnLive, which basically is a game system that only delivers on demand games. IMHO, it's the market that will determine whether this is the right choice in the long run. It's a creative way to eliminate the used market and stop piracy, but if the consumers don't join up like the PSP Go, it will eventually fail. Sincerely, Eric Tykwinski TrueNet, Inc. P: 610-429-8300 F: 610-429-3222 -Original Message- From: -Hammer- [mailto:bhmc...@gmail.com] Sent: Friday, January 27, 2012 9:02 AM To: nanog@nanog.org Subject: Re: XBOX 720: possible digital download mass service. Here's your baseline: Sony Vita. They already tossed the UMD out with the PSP-GO and that failed miserably. Now they are trying again to go to digital only with the Vita. It's not the scale of PS3 or XBOX360 but it may be a good way to gauge the potential success of the concept. -Hammer- I was a normal American nerd -Jack Herer On 1/27/2012 7:34 AM, Jared Mauch wrote: It's already done on a similar scale when apple releases new software for their mobile devices. Just don't do it if you are on a low cap plan (eg: mobile, satellite etc). Caps will be the new market discriminator IMHO. Jared Mauch On Jan 27, 2012, at 3:35 AM, Teioscar.vi...@gmail.com wrote: Can internet in USA support that? Call of Duty 15 releases may 2014 and 30 million gamers start downloading a 20 GB files. Would the internet collapse like a house of cards?.
Re: US DOJ victim letter
On a less serious note, did anyone notice the numbers on the fbi.gov link? I'm pretty sure they are implying those are IP addresses. 123.456.789 and 987.654.321. Must be the same folks that do the Nexus documentation for Cisco. -Hammer- I was a normal American nerd -Jack Herer On 1/19/2012 4:36 PM, Ryan Gelobter wrote: They are related to the DNSChanger and Ghostclick malware as ML said. The e-mails to us did come from the DOJ e-mail servers and were legitimate. The phone number is legit as well. On Thu, Jan 19, 2012 at 3:37 PM, Todd Lyonstly...@ivenue.com wrote: On Thu, Jan 19, 2012 at 1:39 PM, Carlos Alcantarcar...@race.com wrote: +1 on these emails we have received 3 of them. Three here as well. -- SOPA: Any attempt to [use legal means to] reverse technological advances is doomed. --Leo Leporte
Re: VPC=S/MLT?
Found them all on the same page. Not exactly what I was looking for but it's worth sharing. http://www.cisco.com/en/US/products/ps9670/products_implementation_design_guides_list.html -Hammer- I was a normal American nerd -Jack Herer On 1/14/2012 7:10 PM, Charles Spurgeon wrote: On Fri, Jan 13, 2012 at 03:05:45PM -0600, -Hammer- wrote: The first link references chapter 3. I found chapter 5 as well but I can't find the full index. Do you have that link by any chance? I don't have a link to a full index. The links I sent are from a set of Nexus design and operation chapters I've found. Each chapter is a guide to a specific aspect of Nexus and vPC operation and DC design. The set doesn't appear to have been turned into standard Cisco docs with indexes etc. Here are the links that I've been able to find: Chapter 1: Data Center Design with Cisco Nexus Switches and Virtual PortChannel: Overview http://www.cisco.com/en/US/prod/collateral/switches/ps9441/ps9670/C07-572831-00_Dsgn_Nexus_vPC_DG.pdf Chapter 2: Cisco NX-OS Software Command-Line Interface Primer http://www.cisco.com/en/US/prod/collateral/switches/ps9441/ps9670/C07-572833-00_NX-OS_CLI.pdf Chapter 3: Cisco NX-OS Software Virtual PortChannel: Fundamental Concepts http://www.cisco.com/en/US/prod/collateral/switches/ps9441/ps9670/C07-572835-00_NX-OS_vPC_DG.pdf Chapter 4: Spanning Tree Design Guidelines for Cisco NX-OS Software and Virtual PortChannels http://www.cisco.com/en/US/prod/collateral/switches/ps9441/ps9670/C07-572834-00_STDG_NX-OS_vPC_DG.pdf Chapter 5: Data Center Aggregation Layer Design and Configuration with Cisco Nexus Switches and Virtual PortChannels http://www.cisco.com/en/US/prod/collateral/switches/ps9441/ps9670/C07-572830-00_Agg_Dsgn_Config_DG.pdf Chapter 6 Data Center Access Design with Cisco Nexus 5000 Series Switches and 2000 Series Fabric Extenders and Virtual PortChannels http://www.cisco.com/en/US/prod/collateral/switches/ps9441/ps9670/C07-572829-01_Design_N5K_N2K_vPC_DG.pdf Chapter 7 10 Gigabit Ethernet Connectivity with Microsoft Windows Servers http://www.cisco.com/en/US/prod/collateral/switches/ps9441/ps9670/C07-572828-00_10Gb_Conn_Win_DG.pdf Chapter 8 Data Center Design with VMware ESX 4.0 and Cisco Nexus 5000 and 1000V Series Switches 4.0(4)SV1(1) and 2000 Series Fabric Extenders http://www.cisco.com/en/US/prod/collateral/switches/ps9441/ps9670/C07-572832-00_VMware_ESX4_Nexus_DG.pdf -Charles Charles E. Spurgeon / UTnet UT Austin ITS / Networking c.spurg...@its.utexas.edu / 512.475.9265
Re: VPC=S/MLT?
Nice link. Thanks Joshua. -Hammer- I was a normal American nerd -Jack Herer On 1/18/2012 11:57 AM, joshua sahala wrote: vpc has a long list of unclear and/or seemingly contradictory caveats (spread across multiple cisco docs/webpages). when it doesn't work (as expected), it can be challenging to find someone with tac who can actually tell you why (or how to fix it properly). if your needs are fairly basic, are all cisco, follow their dc3.0 verbatim, and don't mind the lack of features on the nexus platform, then it isn't a bad box (if rather expensive for the lack of features...like ipv6 for is-is). also, be prepared to keep spanning-tree around and keep bugging your cisco se/am about trill support (as opposed to fabricpath...see tdp vs ldp) if you *might* want to involve the n7k in routing at all, then http://bradhedlund.com/2010/12/16/routing-over-nexus-7000-vpc-peer-link-yes-and-no/ offers a much clearer explanation than cisco.com about what works and what doesn't (and whether-or-not tac might try to help) hth /joshua
Re: VPC=S/MLT?
Thanks Charles. It's a start. -Hammer- I was a normal American nerd -Jack Herer On 1/14/2012 7:10 PM, Charles Spurgeon wrote: On Fri, Jan 13, 2012 at 03:05:45PM -0600, -Hammer- wrote: The first link references chapter 3. I found chapter 5 as well but I can't find the full index. Do you have that link by any chance? I don't have a link to a full index. The links I sent are from a set of Nexus design and operation chapters I've found. Each chapter is a guide to a specific aspect of Nexus and vPC operation and DC design. The set doesn't appear to have been turned into standard Cisco docs with indexes etc. Here are the links that I've been able to find: Chapter 1: Data Center Design with Cisco Nexus Switches and Virtual PortChannel: Overview http://www.cisco.com/en/US/prod/collateral/switches/ps9441/ps9670/C07-572831-00_Dsgn_Nexus_vPC_DG.pdf Chapter 2: Cisco NX-OS Software Command-Line Interface Primer http://www.cisco.com/en/US/prod/collateral/switches/ps9441/ps9670/C07-572833-00_NX-OS_CLI.pdf Chapter 3: Cisco NX-OS Software Virtual PortChannel: Fundamental Concepts http://www.cisco.com/en/US/prod/collateral/switches/ps9441/ps9670/C07-572835-00_NX-OS_vPC_DG.pdf Chapter 4: Spanning Tree Design Guidelines for Cisco NX-OS Software and Virtual PortChannels http://www.cisco.com/en/US/prod/collateral/switches/ps9441/ps9670/C07-572834-00_STDG_NX-OS_vPC_DG.pdf Chapter 5: Data Center Aggregation Layer Design and Configuration with Cisco Nexus Switches and Virtual PortChannels http://www.cisco.com/en/US/prod/collateral/switches/ps9441/ps9670/C07-572830-00_Agg_Dsgn_Config_DG.pdf Chapter 6 Data Center Access Design with Cisco Nexus 5000 Series Switches and 2000 Series Fabric Extenders and Virtual PortChannels http://www.cisco.com/en/US/prod/collateral/switches/ps9441/ps9670/C07-572829-01_Design_N5K_N2K_vPC_DG.pdf Chapter 7 10 Gigabit Ethernet Connectivity with Microsoft Windows Servers http://www.cisco.com/en/US/prod/collateral/switches/ps9441/ps9670/C07-572828-00_10Gb_Conn_Win_DG.pdf Chapter 8 Data Center Design with VMware ESX 4.0 and Cisco Nexus 5000 and 1000V Series Switches 4.0(4)SV1(1) and 2000 Series Fabric Extenders http://www.cisco.com/en/US/prod/collateral/switches/ps9441/ps9670/C07-572832-00_VMware_ESX4_Nexus_DG.pdf -Charles Charles E. Spurgeon / UTnet UT Austin ITS / Networking c.spurg...@its.utexas.edu / 512.475.9265
VPC=S/MLT?
OK, So I'm doing a lot of reading lately on Nexus as we are about to get into the 7k/5k game and of course a lot of the marketing revolves around VPC. Every time I see it referenced, I keep remembering a reasonably reliable Nortel implementation called Split MLT (Multi Link Trunk). Is there something fancy here that I'm missing in the docs or am I wrong in equating the two? Isn't VPC just S/MLT? It's just that Cisco has shown up 8 years late and is trying to hype it up to compensate? -- -Hammer- I was a normal American nerd -Jack Herer
Re: VPC=S/MLT?
Wow. A fellow greybeard. OK. That's what I needed to know. I'm trying to understand if VPC has any more recent enhancements that weren't around for some older multi-chassis channel methods but I don't see anything specific in the docs other than some FHRP (HSRP only it appears) and PIM tweaks. If anyone has some really deep docs on VPC I'd appreciate the links. Thanks. -Hammer- I was a normal American nerd -Jack Herer On 1/13/2012 1:31 PM, Joel jaeggli wrote: On 1/13/12 11:19 , -Hammer- wrote: OK, So I'm doing a lot of reading lately on Nexus as we are about to get into the 7k/5k game and of course a lot of the marketing revolves around VPC. Every time I see it referenced, I keep remembering a reasonably reliable Nortel implementation called Split MLT (Multi Link Trunk). Is there something fancy here that I'm missing in the docs or am I wrong in equating the two? Isn't VPC just S/MLT? It's just that Cisco has shown up 8 years late and is trying to hype it up to compensate? vpc/vlt/mlag/s/mlt
Re: VPC=S/MLT?
Thanks Charles. Good stuff. -Hammer- I was a normal American nerd -Jack Herer On 1/13/2012 2:10 PM, Charles Spurgeon wrote: On Fri, Jan 13, 2012 at 01:38:26PM -0600, -Hammer- wrote: Wow. A fellow greybeard. OK. That's what I needed to know. I'm trying to understand if VPC has any more recent enhancements that weren't around for some older multi-chassis channel methods but I don't see anything specific in the docs other than some FHRP (HSRP only it appears) and PIM tweaks. If anyone has some really deep docs on VPC I'd appreciate the links. Thanks. These two docs provide a lot of details: vPC fundamental concepts: http://www.cisco.com/en/US/prod/collateral/switches/ps9441/ps9670/C07-572835-00_NX-OS_vPC_DG.pdf Data Center Access Design with Cisco Nexus 5000 Series Switches and 2000 Series Fabric Extenders and Virtual PortChannels Updated to Cisco NX-OS Software Release 5.1(3)N1(1): http://www.cisco.com/en/US/prod/collateral/switches/ps9441/ps9670/C07-572829-01_Design_N5K_N2K_vPC_DG.pdf -Charles Charles E. Spurgeon / UTnet UT Austin ITS / Networking c.spurg...@its.utexas.edu / 512.475.9265
Re: VPC=S/MLT?
Charles, The first link references chapter 3. I found chapter 5 as well but I can't find the full index. Do you have that link by any chance? -Hammer- I was a normal American nerd -Jack Herer On 1/13/2012 2:10 PM, Charles Spurgeon wrote: On Fri, Jan 13, 2012 at 01:38:26PM -0600, -Hammer- wrote: Wow. A fellow greybeard. OK. That's what I needed to know. I'm trying to understand if VPC has any more recent enhancements that weren't around for some older multi-chassis channel methods but I don't see anything specific in the docs other than some FHRP (HSRP only it appears) and PIM tweaks. If anyone has some really deep docs on VPC I'd appreciate the links. Thanks. These two docs provide a lot of details: vPC fundamental concepts: http://www.cisco.com/en/US/prod/collateral/switches/ps9441/ps9670/C07-572835-00_NX-OS_vPC_DG.pdf Data Center Access Design with Cisco Nexus 5000 Series Switches and 2000 Series Fabric Extenders and Virtual PortChannels Updated to Cisco NX-OS Software Release 5.1(3)N1(1): http://www.cisco.com/en/US/prod/collateral/switches/ps9441/ps9670/C07-572829-01_Design_N5K_N2K_vPC_DG.pdf -Charles Charles E. Spurgeon / UTnet UT Austin ITS / Networking c.spurg...@its.utexas.edu / 512.475.9265
Re: So... my colo was just bought.
Jay, Do you know if they'll be keeping/maintaining your colo? Or is it too early for that kind of information? -Hammer- I was a normal American nerd -Jack Herer On 1/10/2012 9:58 AM, Jay Ashworth wrote: By Knology. Should I be scared? My experiences with Knology have been fairly thin, but uniformly negative, for at least the last 5 years. But I know that the plural of 'anecdote' is not 'data'. That said, I'm accepting all anecdotes. :-) Cheers, -- jra
Nexus emulation? Anyone?
I know we can't throw NX code on Dynamips but I figured I would ask the group anyway. We are starting to discuss Nexus platform options and I can only get so much from demo depot before our AM gets whiny. Is anyone currently emulating Nexus on anything that is open to the public? Not I.O.U. but Dynamips or something similar? If the software is out there I have the hardware to support it. Based on some cheap googling I'm thinking the answer will be no. Although I did find Greg Ferros public outcry for network emulators from last year -- -Hammer- I was a normal American nerd -Jack Herer
Re: software wanted
So you want a dynamic real time network discovery / topology mapping? I think Whatsup gold tried this years ago and it could even export to Visio. But not sure lately. -Hammer- I was a normal American nerd -Jack Herer On 12/20/2011 08:37 AM, Gregory Edigarov wrote: On Tue, 20 Dec 2011 16:21:50 +0200 Gregory Edigarovg...@bestnet.kharkov.ua wrote: Hi everybody, can anybody recomend a piece of software, that could graph a live network scanning it via snmp. requirements are: 1. must produce a text output suitable for postproduction. graphviz is an ideal, xml - acceptable. 2. must use no external database i.e. have text config file. clean text console, suitable to run as a cronjob. 3. must be able to work in heterogenous environment. thanks a lot in advance and, the question is about producing network schematic, not about graphs like mrtg, cacti etc, etc
Re: Nexus emulation? Anyone?
Bah. Look like I need more of an education on Nexus in general. Thanks for the easy pointer. -Hammer- I was a normal American nerd -Jack Herer On 12/20/2011 11:02 AM, Nick Hilliard wrote: On 20/12/2011 13:55, -Hammer- wrote: I know we can't throw NX code on Dynamips but I figured I would ask the group anyway. We are starting to discuss Nexus platform options and I can only get so much from demo depot before our AM gets whiny. Is anyone currently emulating Nexus on anything that is open to the public? nexus1k? Nick
Re: Nexus emulation? Anyone?
I am understanding that more as I am researching. I didn't realize there was a separation between 1000v and [5,7]K. I thought Nexus was Nexus. I should have known not to simplify it to that level. :) So I'm understanding more the differences as well as why I won't be expecting to find a good way to emulate the [5,7]K anytime soon. Thank you all for your comments. -Hammer- I was a normal American nerd -Jack Herer On 12/20/2011 12:03 PM, Tim Stevenson wrote: You couldn't use Titanium to judge/discuss the nexus family as a whole either. Aside from 1KV, all the nexus products use ASIC hardware specific to that platform/linecard and no NXOS software emulator exists that mimics those behaviors. 2 cents, Tim At 09:34 AM 12/20/2011, Luan Nguyen gushed: You can't use the software switch Nexus 1000V to judge/discuss the Nexus family products N7K, N5K...etc as a whole? Check out this discussion https://supportforums.cisco.com/thread/2054884https://supportforums.cisco.com/thread/2054884 Titanium as they call the NX-OS simulator is not available to the public though... -Luan On Tue, Dec 20, 2011 at 12:08 PM, -Hammer- bhmc...@gmail.com wrote: Bah. Look like I need more of an education on Nexus in general. Thanks for the easy pointer. -Hammer- I was a normal American nerd -Jack Herer On 12/20/2011 11:02 AM, Nick Hilliard wrote: On 20/12/2011 13:55, -Hammer- wrote: I know we can't throw NX code on Dynamips but I figured I would ask the group anyway. We are starting to discuss Nexus platform options and I can only get so much from demo depot before our AM gets whiny. Is anyone currently emulating Nexus on anything that is open to the public? nexus1k? Nick Tim Stevenson, tstev...@cisco.com Routing Switching CCIE #5561 Distinguished Technical Marketing Engineer, Cisco Nexus 7000 Cisco - http://www.cisco.com IP Phone: 408-526-6759 The contents of this message may be *Cisco Confidential* and are intended for the specified recipients only.
Re: Nexus emulation? Anyone?
Doesn't Titanium achieve this for you? I know. It's Internal. But it simulates the 7k. Or am I getting it backwards? My point is that if Cisco already simulates it Internally it's only a matter of time before someone ports something -Hammer- I was a normal American nerd -Jack Herer On 12/20/2011 12:19 PM, David Sinn wrote: I don't think anyone is asking for a full simulation of the platform in software, that is how the actual ASIC's operate. That is probably best for an entirely different conversation. But there is huge need to simulate the control-plane functionally with a basic forwarding ability (not performant, but pass packets correctly such that you can verify the topology). This is something Dyanmips does great in emulating a cluster of 7200's and allows operators to validate topologies and planned changes in mainstream IOS platforms. Having that for NX-OS would increase the adoption and confidence in the platform. VM's on multiple boxes make simulating a whole network of a given platform simple and easy. From the outside Cisco continues to miss the need for this. At least some of the other vendors are picking up how helpful this and are reacting positively to it. David I've been ranting about this to my account team and Nexus management for a while now, so sorry if this is a duplicate you've already seen. On Dec 20, 2011, at 10:03 AM, Tim Stevenson wrote: You couldn't use Titanium to judge/discuss the nexus family as a whole either. Aside from 1KV, all the nexus products use ASIC hardware specific to that platform/linecard and no NXOS software emulator exists that mimics those behaviors. 2 cents, Tim At 09:34 AM 12/20/2011, Luan Nguyen gushed: You can't use the software switch Nexus 1000V to judge/discuss the Nexus family products N7K, N5K...etc as a whole? Check out this discussion https://supportforums.cisco.com/thread/2054884https://supportforums.cisco.com/thread/2054884 Titanium as they call the NX-OS simulator is not available to the public though... -Luan On Tue, Dec 20, 2011 at 12:08 PM, -Hammer-bhmc...@gmail.com wrote: Bah. Look like I need more of an education on Nexus in general. Thanks for the easy pointer. -Hammer- I was a normal American nerd -Jack Herer On 12/20/2011 11:02 AM, Nick Hilliard wrote: On 20/12/2011 13:55, -Hammer- wrote: I know we can't throw NX code on Dynamips but I figured I would ask the group anyway. We are starting to discuss Nexus platform options and I can only get so much from demo depot before our AM gets whiny. Is anyone currently emulating Nexus on anything that is open to the public? nexus1k? Nick Tim Stevenson, tstev...@cisco.com Routing Switching CCIE #5561 Distinguished Technical Marketing Engineer, Cisco Nexus 7000 Cisco - http://www.cisco.com IP Phone: 408-526-6759 The contents of this message may be *Cisco Confidential* and are intended for the specified recipients only.
Re: Nexus emulation? Anyone?
OK. Thanks for the clarification. I understand that resources would be required to support such an effort. I was more or less implying that if it's done Internally it probably won't be long before someone comes up with a way to do it (Dynamips part deux) for the public. Not supported by Cisco. I don't see how it can hurt Cisco to have people wanting to run their stuff for learning/training/validation purposes in a virtual environment. But that is a whole different thread. -Hammer- I was a normal American nerd -Jack Herer On 12/20/2011 12:31 PM, Tim Stevenson wrote: At 10:18 AM 12/20/2011, -Hammer- gushed: Doesn't Titanium achieve this for you? I know. It's Internal. But it simulates the 7k. Or am I getting it backwards? Titanium is basically the NXOS control plane, sans data plane. It's the platform independent part of the OS. My point is that if Cisco already simulates it Internally it's only a matter of time before someone ports something Not saying whether it's right or wrong, but maintaining, releasing, supporting it would require resources, which as you can imagine get prioritized onto other things. Tim -Hammer- I was a normal American nerd -Jack Herer On 12/20/2011 12:19 PM, David Sinn wrote: I don't think anyone is asking for a full simulation of the platform in software, that is how the actual ASIC's operate. That is probably best for an entirely different conversation. But there is huge need to simulate the control-plane functionally with a basic forwarding ability (not performant, but pass packets correctly such that you can verify the topology). This is something Dyanmips does great in emulating a cluster of 7200's and allows operators to validate topologies and planned changes in mainstream IOS platforms. Having that for NX-OS would increase the adoption and confidence in the platform. VM's on multiple boxes make simulating a whole network of a given platform simple and easy. From the outside Cisco continues to miss the need for this. At least some of the other vendors are picking up how helpful this and are reacting positively to it. David I've been ranting about this to my account team and Nexus management for a while now, so sorry if this is a duplicate you've already seen. On Dec 20, 2011, at 10:03 AM, Tim Stevenson wrote: You couldn't use Titanium to judge/discuss the nexus family as a whole either. Aside from 1KV, all the nexus products use ASIC hardware specific to that platform/linecard and no NXOS software emulator exists that mimics those behaviors. 2 cents, Tim At 09:34 AM 12/20/2011, Luan Nguyen gushed: You can't use the software switch Nexus 1000V to judge/discuss the Nexus family products N7K, N5K...etc as a whole? Check out this discussion https://supportforums.cisco.com/thread/2054884https://supportforums.cisco.com/thread/2054884https://supportforums.cisco.com/thread/2054884 Titanium as they call the NX-OS simulator is not available to the public though... -Luan On Tue, Dec 20, 2011 at 12:08 PM, -Hammer-bhmc...@gmail.com wrote: Bah. Look like I need more of an education on Nexus in general. Thanks for the easy pointer. -Hammer- I was a normal American nerd -Jack Herer On 12/20/2011 11:02 AM, Nick Hilliard wrote: On 20/12/2011 13:55, -Hammer- wrote: I know we can't throw NX code on Dynamips but I figured I would ask the group anyway. We are starting to discuss Nexus platform options and I can only get so much from demo depot before our AM gets whiny. Is anyone currently emulating Nexus on anything that is open to the public? nexus1k? Nick Tim Stevenson, tstev...@cisco.com Routing Switching CCIE #5561 Distinguished Technical Marketing Engineer, Cisco Nexus 7000 Cisco - http://www.cisco.comhttp://www.cisco.com IP Phone: 408-526-6759 The contents of this message may be *Cisco Confidential* and are intended for the specified recipients only. Tim Stevenson, tstev...@cisco.com Routing Switching CCIE #5561 Distinguished Technical Marketing Engineer, Cisco Nexus 7000 Cisco - http://www.cisco.com IP Phone: 408-526-6759 The contents of this message may be *Cisco Confidential* and are intended for the specified recipients only.
Re: BGP and Firewalls...
Roland, While I understand that the definition has nothing to do with IT Security there is no question that many folks use the phrase to summarize a layered IT security model. Edge routers with ACLs to filter white noise go to edge L3/4 firewalls to filter their layer go to load balancers to terminate SSL (not really security I know) which go to L7 firewalls to inspect HTTP just to get to the web server. Then you have the whole layered DMZs for the WEBs/APPs/DBs/inside etc. We employ defense in depth and everyone is familiar with the concept even if they are using the phrase incorrectly. And our wonderful federal auditors expect it and call it the same thing. -Hammer- I was a normal American nerd -Jack Herer On 12/07/2011 09:43 PM, Dobbins, Roland wrote: On Dec 8, 2011, at 1:36 AM, Leo Bicknell wrote: I don't think you're looking at defense in depth in the right way, Actually, it sometimes seems as if nobody in the industry understands what 'defense in depth' really means, heh. 'Defense in depth' is a military term of art which equates to 'trading space for time in order to facilitate attrition of enemy forces'. It does not have any real relevance to infosec/opsec; unfortunately, its original meaning has been corrupted and so it is widely (and incorrectly) used in place of the more appropriate 'combined arms approach' or 'jointness' or 'mutual support' or 'layered defense' metaphors. Hannibal's tactics at Cannae are generally cited as the canonical (pardon the pun) example of actual military defense in depth. ; --- Roland Dobbinsrdobb...@arbor.net //http://www.arbornetworks.com The basis of optimism is sheer terror. -- Oscar Wilde
Re: Internet Edge and Defense in Depth
I personally have not seen it done in large environments. Hardware isn't there yet. I've seen it done in small business environments. Not a fan of the idea. -Hammer- I was a normal American nerd -Jack Herer On 12/06/2011 03:16 PM, Holmes,David A wrote: Some firewall vendors are proposing to collapse all Internet edge functions into a single device (border router, firewall, IPS, caching engine, proxy, etc.). A general Internet edge design principle has been the defense in depth concept. Is anyone collapsing all Internet edge functions into one device? Regards, David This communication, together with any attachments or embedded links, is for the sole use of the intended recipient(s) and may contain information that is confidential or legally protected. If you are not the intended recipient, you are hereby notified that any review, disclosure, copying, dissemination, distribution or use of this communication is strictly prohibited. If you have received this communication in error, please notify the sender immediately by return e-mail message and delete the original and all copies of the communication, along with any attachments or embedded links, from your system.
Re: Recent DNS attacks from China?
There was a new BIND vulnerability announced... http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2011-4313 -Hammer- I was a normal American nerd -Jack Herer On 11/30/2011 10:59 AM, rob.vercoute...@kpn.com wrote: Hello Leland, Yes we do see the same behavior! regards, Rob Vercouteren
Re: Recent DNS attacks from China?
Just offering it up. It's not a 0day or anything but it is recently published. I am not receiving the DoS so I haven't had a chance to observe the traffic. -Hammer- I was a normal American nerd -Jack Herer On 11/30/2011 11:40 AM, David Conrad wrote: On Nov 30, 2011, at 9:13 AM, -Hammer- wrote: There was a new BIND vulnerability announced... http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2011-4313 I strongly suspect the BIND vulnerability is unrelated. These attacks appear to be simple (if large) DDoSes. Regards, -drc
Re: First real-world SCADA attack in US
LOL. I see what you did there. -Hammer- I was a normal American nerd -Jack Herer On 11/21/2011 01:17 PM, Arturo Servin wrote: I wonder if they are using private IP addresses. -as On 21 Nov 2011, at 13:32, Jay Ashworth wrote: On an Illinois water utility: http://www.msnbc.msn.com/id/45359594/ns/technology_and_science-security Cheers, -- jra -- Jay R. Ashworth Baylink j...@baylink.com Designer The Things I Think RFC 2100 Ashworth Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274
Re: Arguing against using public IP space
NAT neither provides nor contributes to security. NAT detracts from security by destroying audit trails and interrupting/obfuscating attack source identification, forensics, etc. Respectfully, I'm really struggling with this. Sentence one is an opinion. It's all a matter of the designers viewpoint. Step 1 in most security books is to not reveal ANYTHING to ANYONE that you don't have to. Taken to the extreme, that could include your network layout and native addressing schema. Sentence two is wrong. If employing NAT breaks your audit trail or interferes with your forensics then you need to address your audit/forensics method. We have correlation engines that track the state of a conversation (defined as multiple TCP sessions in series) thru our secure architecture. We can 100% tell you the public IP of a session whether it's the destination or source and whether it's been NATted once or three or four times. We have cookies/sessionIDs/JSessionIDs/ and Xforwarders we manipulate to allow the application layer to manage the proper source of the client as well. These are proven technologies that have been around for a decade. They have stood up in court and been used against bad guys w/o question. While I agree that this is an extra layer of complexity, the focus is to make in manageable. I'm not saying you are flat out wrong Owen. I am saying that it's all a matter of your viewpoint. -Hammer- I was a normal American nerd -Jack Herer On 11/16/2011 10:44 AM, Owen DeLong wrote: NAT neither provides nor contributes to security. NAT detracts from security by destroying audit trails and interrupting/obfuscating attack source identification, forensics, etc.
Re: Arguing against using public IP space
Well argued Owen. I can see both sides. -Hammer- I was a normal American nerd -Jack Herer On 11/16/2011 02:44 PM, Owen DeLong wrote: On Nov 16, 2011, at 9:13 AM, -Hammer- wrote: NAT neither provides nor contributes to security. NAT detracts from security by destroying audit trails and interrupting/obfuscating attack source identification, forensics, etc. Respectfully, I'm really struggling with this. Sentence one is an opinion. It's all a matter of the designers viewpoint. Step 1 in most security books is to not reveal ANYTHING to ANYONE that you don't have to. Taken to the extreme, that could include your network layout and native addressing schema. Actually, the first rule of security in many texts I have read is Security through obscurity is no security.. While you don't reveal anything to anyone that you don't have to, it is arguable that you need to reveal enough for security threats (abusers, attackers, etc.) to be identified as part of being a good network citizen. As with most things, taken to extreme, you reach a point of reductio ad absurdum. Sentence two is wrong. If employing NAT breaks your audit trail or interferes with your forensics then you need to address your audit/forensics method. We have correlation engines that track the state of a conversation (defined as multiple TCP sessions in series) thru our secure architecture. We can 100% tell you the public IP of a session whether it's the destination or source and whether it's been NATted once or three or four times. We have cookies/sessionIDs/JSessionIDs/ and Xforwarders we manipulate to allow the application layer to manage the proper source of the client as well. These are proven technologies that have been around for a decade. They have stood up in court and been used against bad guys w/o question. While I agree that this is an extra layer of complexity, the focus is to make in manageable. It may not break your own, but, it certainly breaks that of your user's victims. Most people don't store port information in their webserver logs, for example. They may not have that data to come back at you to identify the internal host in question. All they have is the public IP address of your NAT box and the date/time the event occurred. Ignoring for a moment the fact that if your clocks aren't perfectly synchronized, that may not necessarily provide the needed identification, even if they do have the port number, without the source port number from your side, they don't have enough for you to find the attacker. I'm not saying you are flat out wrong Owen. I am saying that it's all a matter of your viewpoint. I think in considering this in general, all viewpoints must be considered. From the global viewpoint, overall, I think that the case is well made that the security negatives associated with NAT and the cost/impact imposed on everyone, including those outside of the NAT- using organization far outweigh the (very minuscule) possible positives that have been argued so far. This leaves one and only one key benefit to NAT, which is address sharing (conservation). Since we don't have a shortage of IPv6 addresses, bringing a technology forward into IPv6 solely for the purpose of address sharing (conservation) makes little sense. Owen
Re: Arguing against using public IP space
Guys, Everyone is complaining about whether a FW serves its purpose or not. Take a step back. Security is about layers. Router ACLs to filter whitenoise. FW ACLs to filter more. L7 (application) FWs to inspect HTTP payload. Patch management at the OS and Application layer on the server. Heuristics analyzing strategically placed SPAN feeds. The list goes on depending upon the size of your enterprise. I don't think in a large environment you can avoid complexity these days. What you have to succeed at is managing that complexity. And L3 FWs have a very important purpose. They filter garbage. You focus your IDS/IPS on what the FW is allowing. It's more than a screen door. But yes, it's LESS than a true vault door. It's all about mitigating the risk. You'll never be 100% full proof. -Hammer- I was a normal American nerd -Jack Herer On 11/15/2011 08:56 AM, William Herrin wrote: On Tue, Nov 15, 2011 at 9:17 AM,valdis.kletni...@vt.edu wrote: And this is totally overlooking the fact that the vast majority of *actual* attacks these days are web-based drive-bys and similar things that most firewalls are configured to pass through. Valdis, A firewall's job is to prevent the success of ACTIVE attack vectors against your network. If your firewall successfully restricts attackers to passive attack vectors (drive-by downloads) and social engineering vectors then it has done everything reasonably expected of it. Those other parts of the overall network security picture are dealt with elsewhere in system security apparatus. So it's no mistake than in a discussion of firewalls those two attack vectors do not feature prominently. Regards, Bill Herrin
Re: Ok; let's have the Does DNAT contribute to Security argument one more time...
There are some methods of security that NAT has a good use for. We use NAT to prevent reachibility. In other words, not only does an ACL have to allow traffic thru the FW, but a complimenting NAT rule has to allow the actual layer 3 reachibility. If not, even with the ACL, the routing path won't be available. It is a great safety check when we implement FW rules because it forces almost every manual entry to have two specific steps. In our layered environments, we also use local routing in some of our DMZs. In other words, a server on a subnet will only be aware of it's local broadcast domain. Even with a default GW, if it doesn't have a NAT in the FW, it can't route thru it. So even if a server gets compromised, the bad guy doesn't have a method to reach beyond the local DMZ without also making adjustments on the FW. I don't think this complicates our design to much and definitely keeps us in check from human errors. -Hammer- I was a normal American nerd -Jack Herer On 11/15/2011 09:00 AM, Owen DeLong wrote: On the other hand, since a firewall's job is to stop packets you don't want, if it stops doing it's just as a firewall, it's likely to keep on doing it's other job: passing packets. It certainly depends on the fundamental design of the firewall, which I can't speak to generally... but you proponents of NAT contributes no security can't, either. Perhaps this misunderstanding of the job of a firewall explains your errant conclusions about their failure modes better than anything else in the thread. I would say that your description above does not fit a stateful firewall, but, instead describes a packet-filtering router. A stateful firewall's job is to forward only those packets you have permitted. If ti stops doing it's job, it's default failure mode is to stop forwarding packets. Please explain to me how mutilating the packet header makes any difference in this. That makes sense, but I'm wondering if that should be considered correct behavior. Obviously a non-consumer grade router can have rules defining what is/isn't PATed in or out, but a Linksys/D-Link/etc should expect everything coming from the outside in to either a) match up with something in the translation table, b) be a service the router itself is hosting (http, etc), or c) be a port it explicitly forwards to the same inside host. Anything not matching one of those 3 categories you'd think could be dropped. Routing without translating ports and addresses seems like the root of the issue. It is. And IME, the people who think NAT provides no security rarely if ever seem to address that aspect of the issue. It's a lovely hypothetical description of how those devices should work. IME, and, as has been explained earlier in the thread, it is not necessarily how they ACTUALLY work. Since security depends not on the theoretical ideal of how the devices should work, but, rather on how they actually work, perhaps it is worth considering that our addressing reality instead of theory is actually a feature rather than a bug. And, for what it's worth, I'm discussing the common case: 1-to-many incoming DNAT; rerouting specific TCP or UDP ports to internal machines, possibly on other ports. I think that is what the discussion has been about all along. Owen
Re: Arguing against using public IP space
I see your side Cameron. -Hammer- I was a normal American nerd -Jack Herer On 11/15/2011 09:20 AM, Cameron Byrne wrote: On Nov 15, 2011 7:09 AM, -Hammer- bhmc...@gmail.com mailto:bhmc...@gmail.com wrote: Guys, Everyone is complaining about whether a FW serves its purpose or not. Take a step back. Security is about layers. Router ACLs to filter whitenoise. FW ACLs to filter more. L7 (application) FWs to inspect HTTP payload. Patch management at the OS and Application layer on the server. Heuristics analyzing strategically placed SPAN feeds. The list goes on depending upon the size of your enterprise. I would say security is about stopping threats , not layering in technology and tools. Granted, layer is a good idea, throwing everything including the kitchen sink at a problem will result in just a larger problem. I don't think in a large environment you can avoid complexity these days. What you have to succeed at is managing that complexity. And L3 FWs have a very important purpose. They filter garbage. You focus your IDS/IPS on what the FW is allowing. It's more than a screen door. But yes, it's LESS than a true vault door. It's all about mitigating the risk. You'll never be 100% full proof. Large environments have to force simplicity to combat the natural ebb of complexity. The largest operators live by one rule , KISS. L3 network fw are an attack vector and single point of failure. But, I think this thread is not changing anyone's mind at this point. -Hammer- I was a normal American nerd -Jack Herer On 11/15/2011 08:56 AM, William Herrin wrote: On Tue, Nov 15, 2011 at 9:17 AM,valdis.kletni...@vt.edu mailto:valdis.kletni...@vt.edu wrote: And this is totally overlooking the fact that the vast majority of *actual* attacks these days are web-based drive-bys and similar things that most firewalls are configured to pass through. Valdis, A firewall's job is to prevent the success of ACTIVE attack vectors against your network. If your firewall successfully restricts attackers to passive attack vectors (drive-by downloads) and social engineering vectors then it has done everything reasonably expected of it. Those other parts of the overall network security picture are dealt with elsewhere in system security apparatus. So it's no mistake than in a discussion of firewalls those two attack vectors do not feature prominently. Regards, Bill Herrin
Re: Ok; let's have the Does DNAT contribute to Security argument one more time...
There really is no winner or right way on this thread. In IPv4 as a security guy we have often implemented NAT as an extra layer of obfuscation. In IPv6, that option really isn't there. So it's a cultural change for me. I'm not shedding any tears. We've talked to our FW vendors about various 6to6 and 4to6/6to4 options and we may consider it but given the push in the IPv6 community for native addressing I really am hesitant to add NAT functionality given that no one really knows what the IPv6 future holds. -Hammer- I was a normal American nerd -Jack Herer On 11/14/2011 02:55 PM, Jay Ashworth wrote: Kill this subject if you're sick of it. - Original Message - From: Gabriel McCallgabriel.mcc...@thyssenkrupp.com If your firewall is working properly, then having public addresses behind it is no less secure than private. And if your firewall is not working properly, then having private addresses behind it is no more secure than public. This assertion is frequently made -- it was made a couple other times this morning -- but I continue to think that it doesn't hold much water, primarly because it doesn't take into account *the probability of various potential failure modes in a firewall*. The basic assertion made by proponents of this theory, when analyzed, amounts to the probability that a firewall between a publicly routable internal network and the internet will fail in such a fashion as to pass packets addressed to internal machines is of the same close order as the probability that a DNAT router will fail in such a fashion as to allow people outside it to address packets to *arbitrary* internal machine IP addresses (assuming they have any way to determine what those are). Hopefully, my rephrasing makes it clearer why those of us who believe that there is, in fact, *some* extra security contributed by RFC 1918 and DNAT in the over all stack tend not to buy the arguments of those who say that in fact, it contributes none: they never show their work, so we cannot evaluate their assertions. But in fact, as someone pointed out this morning in the original thread: even if you happen to *know* the internal 1918 IP of the NATted target, the default failure mode of the NAT box is stop forwarding packets into private network at all. Certainly, individual NAT boxes can have other failure modes, but each of those extra layers adds at least another 0 to the probability p-number, in my not-a-mathematician estimation. On the other hand, since a firewall's job is to stop packets you don't want, if it stops doing it's just as a firewall, it's likely to keep on doing it's other job: passing packets. It certainly depends on the fundamental design of the firewall, which I can't speak to generally... but you proponents of NAT contributes no security can't, either. That makes sense, but I'm wondering if that should be considered correct behavior. Obviously a non-consumer grade router can have rules defining what is/isn't PATed in or out, but a Linksys/D-Link/etc should expect everything coming from the outside in to either a) match up with something in the translation table, b) be a service the router itself is hosting (http, etc), or c) be a port it explicitly forwards to the same inside host. Anything not matching one of those 3 categories you'd think could be dropped. Routing without translating ports and addresses seems like the root of the issue. It is. And IME, the people who think NAT provides no security rarely if ever seem to address that aspect of the issue. And, for what it's worth, I'm discussing the common case: 1-to-many incoming DNAT; rerouting specific TCP or UDP ports to internal machines, possibly on other ports. Cheers, -- jra
Re: Firewalls - Ease of Use and Maintenance?
The other high cost of free that people sometimes overlook is liability. Many organizations want/need someone to hold the fire to in the event of an issue. I believe in open source and am an advocate of open source computing (this email is from my Debian (NOT UBUNTU) laptop and my BSD workstation is right beside it), but at an organizational level, if I had an open source FW and a vulnerability was allowed to get thru it and compromise customer or confidential data, my management would be looking to the vendor for answers. If I told them it's open source, there is no vendor it would not go over well. Why? Because the liability is now assumed by my company. So when the customer sues it's on me. Or (and we see these on a regular basis) when the patent troll contacts us about his patent that the open source product is violating and wants compensation the liability stops at my company. IF I am using a vendor supported platform, I can take that to my vendor and discuss options. Many (not all) large businesses have agreements with vendors that go well beyond NDAs. Agreements about liability. Healthcare/Financial/Defense all have these kinds of agreements. I'm not saying it's fair. It's just how the world works. For that reason there are some areas where open source is smart while there are other areas (a firewall you depend on to protect you) where open source may put you and your employer at risk. You have to consider that. Or... Some of us do. -Hammer- I was a normal American nerd -Jack Herer On 11/10/2011 07:36 AM, Jimmy Hess wrote: On Wed, Nov 9, 2011 at 2:44 PM, Nick Hilliardn...@foobar.org wrote: On 09/11/2011 19:07, C. Jon Larsen wrote: As I said, it's not a pf problem. Commercial firewalls will do all this sort of thing off the shelf. It's a pain to have to write scripts to do this manually. Ah... the high cost of 'free' products, you have to do some scripting, or pay another organization to support it / do scripting work for you. The advantage is... you _can_ do a small amount of scripting or programming to add minor additional required functionality. And a very large number commercial firewalls do not have config synchronization, except, perhaps between a failover pair, anyways. Anyways... I can see synchronizing blacklists on a firewall, or having a firewall configured to fetch certain 'drop' rules from a HTTPS URL.Otherwise: the thought of mass synchronization of lots of firewalls can be bad in that it creates a single point of system compromise; supposing the synchronization source machine were compromised, one dirty rule inserted by an intruder followed by a kick off of the sync mechanism, and then actions to break it/prevent further syncing, defeats the security of the entire deployment -- -JH
Re: Firewalls - Ease of Use and Maintenance?
OK. Right off the bat you know I can't and won't. But in some places it is common practice to make sure agreements are in place to make sure all parties are protected based on how a product is expected/designed to perform. I can't say more than that. Realize I'm speaking about things that are solely on the vendor. Not Did you configure the ACL properly? What you can Google is the names of companies who have settled out of court against various trolling lawsuits vs the names of companies that are still in litigation. There is a mix of both manufacturer/vendor and end customer. It all depends on the case. This shouldn't surprise you. If Toyota makes a defective brake and you slam into someone else, your insurance covers you. Eventually, if the issue scales out to the point that it is obvious that Toyota made a defective brake and it is not your fault, some insurance companies collectively will go to the government or directly to the manufacturer for compensation. This is no different. If you sell me a FW and it catches on fire thru no fault of my own and then the public finds out that FWs are catching on fire all over the place, it's a good bet that that FW vendor will be getting some lawsuits. If a FW vendor reports a product to work a certain way and instead thru a massive vulnerability or development oversight it does not the same applies. Software. Hardware. Physical (fire). Logical (vulnerability). I'm not saying that it happens all the time and I'm not even saying it's a general practice. What I'm saying is it happens. And depending on your business vertical it could be a very real consideration. COMPLETELY 100% MADE UP HYPOTHETICAL SCENARIO: I put a FW in. I put proper L3 ACLs in. I block 443 inbound. I didn't say I block HTTPS. I block 443. I test it by telnetting from the Internet to 1.1.1.1:443 and I am unable to connect. Looks good. A month later our CEO is surfing the Internet. Thru a development oversight in the product, when I NAT or PAT him to the Internet his source port is not pulled from the Ephemeral range but is instead sourced as port 443. He of course goes to sites riddled with Malware because that's what CEOs do. They click on links. So the Malware website initiates a new TCP session to destination port 443 with his NATted IP. The state table has an entry for that IP and 443 and even though this is a new TCP session the FW lets it thru. The malware site bad guys are able to retrieve confidential information about a merger and publish it. The other company that we were merging with sues us because the information is leaked to the public and adversely impacted their stock value. Everything in the above paragraph is able to be documented thru forensics and it is indisputable that the FW was properly configured and should have blocked it but didn't. The FW did NOT perform as advertised/designed. This is NOT the fault of me or my company. If a few thousand dollars is at stake nothing may come of this. If tens or hundreds of millions of dollars are at stake I promise you that our lawyers will be contacting the manufacturer whose product did not perform as advertised. They will compensate (in one way or another) us for our losses. It's a big ugly world full of lots of lawyers. -Hammer- I was a normal American nerd -Jack Herer On 11/10/2011 09:14 AM, Richard Kulawiec wrote: On Thu, Nov 10, 2011 at 08:52:22AM -0600, -Hammer- wrote: The other high cost of free that people sometimes overlook is liability. Please point to an instance (case citation, please) where a commercial firewall vendor has been successfully litigated against -- that is, held responsible by a court of law for a failure of their product to provide the functionality that it's claimed to provide. ---rsk
Re: Firewalls - Ease of Use and Maintenance?
Look the thread was about considerations for various firewalls. Eventually it spun off to be considerations and issues with Open Source options. I was merely pointing out a consideration that some folks have to take into account. You don't have to like it, agree with it, or even believe it. But it does happen and it is out there. I was just pointing it out. Take it for what you want but arguing it is pointless. It's out there for some of us. -Hammer- I was a normal American nerd -Jack Herer On 11/10/2011 10:04 AM, Peter Kristolaitis wrote: Your hypothetical scenario assumes you're the only organization compromised by the flaw (or one of very few), and not #3972 on the list, in which case the company could go bankrupt before a court can hear your case, and the liability protection they offered you is worth the electrons it's printed on.It's great if you're a Fortune 50 and have the legal, political and financial clout to be #1 on the lawsuit list, but nearly worthless for most organizations. - Peter On 11/10/2011 10:39 AM, -Hammer- wrote: OK. Right off the bat you know I can't and won't. But in some places it is common practice to make sure agreements are in place to make sure all parties are protected based on how a product is expected/designed to perform. I can't say more than that. Realize I'm speaking about things that are solely on the vendor. Not Did you configure the ACL properly? What you can Google is the names of companies who have settled out of court against various trolling lawsuits vs the names of companies that are still in litigation. There is a mix of both manufacturer/vendor and end customer. It all depends on the case. This shouldn't surprise you. If Toyota makes a defective brake and you slam into someone else, your insurance covers you. Eventually, if the issue scales out to the point that it is obvious that Toyota made a defective brake and it is not your fault, some insurance companies collectively will go to the government or directly to the manufacturer for compensation. This is no different. If you sell me a FW and it catches on fire thru no fault of my own and then the public finds out that FWs are catching on fire all over the place, it's a good bet that that FW vendor will be getting some lawsuits. If a FW vendor reports a product to work a certain way and instead thru a massive vulnerability or development oversight it does not the same applies. Software. Hardware. Physical (fire). Logical (vulnerability). I'm not saying that it happens all the time and I'm not even saying it's a general practice. What I'm saying is it happens. And depending on your business vertical it could be a very real consideration. COMPLETELY 100% MADE UP HYPOTHETICAL SCENARIO: I put a FW in. I put proper L3 ACLs in. I block 443 inbound. I didn't say I block HTTPS. I block 443. I test it by telnetting from the Internet to 1.1.1.1:443 and I am unable to connect. Looks good. A month later our CEO is surfing the Internet. Thru a development oversight in the product, when I NAT or PAT him to the Internet his source port is not pulled from the Ephemeral range but is instead sourced as port 443. He of course goes to sites riddled with Malware because that's what CEOs do. They click on links. So the Malware website initiates a new TCP session to destination port 443 with his NATted IP. The state table has an entry for that IP and 443 and even though this is a new TCP session the FW lets it thru. The malware site bad guys are able to retrieve confidential information about a merger and publish it. The other company that we were merging with sues us because the information is leaked to the public and adversely impacted their stock value. Everything in the above paragraph is able to be documented thru forensics and it is indisputable that the FW was properly configured and should have blocked it but didn't. The FW did NOT perform as advertised/designed. This is NOT the fault of me or my company. If a few thousand dollars is at stake nothing may come of this. If tens or hundreds of millions of dollars are at stake I promise you that our lawyers will be contacting the manufacturer whose product did not perform as advertised. They will compensate (in one way or another) us for our losses. It's a big ugly world full of lots of lawyers. -Hammer- I was a normal American nerd -Jack Herer On 11/10/2011 09:14 AM, Richard Kulawiec wrote: On Thu, Nov 10, 2011 at 08:52:22AM -0600, -Hammer- wrote: The other high cost of free that people sometimes overlook is liability. Please point to an instance (case citation, please) where a commercial firewall vendor has been successfully litigated against -- that is, held responsible by a court of law for a failure of their product to provide the functionality that it's claimed to provide. ---rsk
Re: Firewalls - Ease of Use and Maintenance?
WOW. You really are naive -Hammer- I was a normal American nerd -Jack Herer On 11/10/2011 12:12 PM, Richard Kulawiec wrote: On Thu, Nov 10, 2011 at 09:39:29AM -0600, -Hammer- wrote: OK. Right off the bat you know I can't and won't. Right. I know you can't and won't. I can't either. So we can summarily dismiss all the concerns about liability because they have no relationship to reality. You will not be suing BigFirewallCo, no matter how horribly their product fails, no matter how bad the damage is, no matter how obvious to all of us the failure is, no matter how culpable we might all agree they are, because (a) your pockets aren't as deep as BigFirewallCo's, and (b) you'd probably lose anyway (c) after 11 years and a lot of billable hours for everyone's attorneys. (s/you/I/ and everyone else, unless we happen to work for a Fortune 50 company...and probably not even then.) When it comes to security, I think it's better to rely on software engineering than litigation. ---rsk
Re: Firewalls - Ease of Litigation and Subrogation
You guys are hilarious. OK. I give up. It never happens. I'll leave this thread alone. -Hammer- I was a normal American nerd -Jack Herer On 11/10/2011 12:19 PM, Jay Ashworth wrote: - Original Message - From: Richard Kulawiecr...@gsp.org Right. I know you can't and won't. I can't either. So we can summarily dismiss all the concerns about liability because they have no relationship to reality. You will not be suing BigFirewallCo, no matter how horribly their product fails, no matter how bad the damage is, no matter how obvious to all of us the failure is, no matter how culpable we might all agree they are, because (a) your pockets aren't as deep as BigFirewallCo's, and (b) you'd probably lose anyway (c) after 11 years and a lot of billable hours for everyone's attorneys. (s/you/I/ and everyone else, unless we happen to work for a Fortune 50 company...and probably not even then.) Yeah, Rich, but come on: you and I -- and even his managers -- know that while that is true (that no one's actually going to sue anyone, and likely legally cannot anyway), that *still* won't keep Pointy Haired Bosses from making that *capability* a firm requirement. That's why their hair is pointy. Cheers, -- jra
Re: Firewalls - Ease of Use and Maintenance?
OK. Maybe I jumped to hard. But to tell me that what I'm referring to has never happened (even though I've participated) just because he hasn't heard of it is not the best way to approach an argument. When these things happen, there are agreements in place so it's not discussed. Especially when it's settled out of court. If you want some fun reading on the subject google Walker Digital or Leon Stambler. Again, I never said it happens to everyone. But it does happen and some of us have to consider it. I didn't realize it would come under such scrutiny just because it isn't widely published. Again, I'll try and leave this thread alone. -Hammer- I was a normal American nerd -Jack Herer On 11/10/2011 12:24 PM, valdis.kletni...@vt.edu wrote: On Thu, 10 Nov 2011 12:12:21 CST, -Hammer- said: WOW. You really are naive I think Rich has been around long enough that he gets called a *lot* of things (many of them non-complimentary), but this is the first time this century anybody's called him *naive*... ;)
Re: Firewalls - Ease of Use and Maintenance?
I changed my mind. I want to clear this up. Here is an example of where a patent troll skipped over the manufacturer and went straight for the end customer. There are dozens of these attacking all verticals and manufacturers alike for various reasons. http://dockets.justia.com/docket/texas/txedce/2:2008cv00471/113504/ So a customer buys a product that contains a technology. Then the customer is sued for possessing said technology. You don't think the customer (Merrill Lynch / BofA / Citigroup / etc) isn't gonna take that lawsuit and call the manufacturer up and tell them they are gonna eat it? You don't think a financial institution or a healthcare organization would attempt to recuperate the costs? You don't think that after the fact agreements are put in place so that frivolous lawsuits like this are appropriately handled between the manufacturer and the customer in the future? When millions of dollars are at stake? You don't have to like it. But you should be a little more objective. I am not speaking of specific cases I'm involved in. I just googled a few things and found some results -Hammer- I was a normal American nerd -Jack Herer On 11/10/2011 12:24 PM, valdis.kletni...@vt.edu wrote: On Thu, 10 Nov 2011 12:12:21 CST, -Hammer- said: WOW. You really are naive I think Rich has been around long enough that he gets called a *lot* of things (many of them non-complimentary), but this is the first time this century anybody's called him *naive*... ;)
Re: Firewalls - Ease of Use and Maintenance?
I think that firewall/censorship is all semantics. The real question is the scale of the environment and the culture of your shop and areas of ownership. I work in a large enterprise. Combining functions such as L3 firewalling with content filtering with url filtering with XXX can be difficult. 1. Can the platform actually handle all the traffic? 2. Does one group own ALL the separate functions? If not, RBAC becomes an important (and sometimes political) issue. 3. How easy is it to troubleshoot? Although modern hardware is quickly catching up with all the glorious software features people want these days, in our environment we found it easier and saner to separate these functions. They were owned by different groups and the number of FWs we deploy vs the number of content filters didn't add up to make sense when aggregating functions was discussed. In a smaller operation a Fortinet or other product that consolidates these efforts may make sense. In a larger operation in depends on many outside factors. I've had the (dis)pleasure of working with PIX/FWSM/ASA since Vietnam. I've worked with Netscreen/Juniper, IPTables, PFsense, CheckPoint over Nokia, CheckPoint over Winblows, CheckPoint over UTM, Fortinet, Sonicwall (say Uncle!) and others. They all have their pros and cons and in the end it is specific to your shops needs. More of a UNIX guy? BSD FWs. No we aren't going to talk about how BSD isn't UNIX. That's a different mailing list. More of a Linux guy and need to make sure you have a vendor to yell at? CheckPoint. IPSO/SPLAT/GAEA is all Linux. Not a UNIX/Linux guy and you need a more reliable vendor? And a traditionally safer bet? No one ever got fired for buying Cisco. Need to save money? Consolidate functions? Confident of the capabilities of the product? Fortinet. And the list goes on and on and on -Hammer- I was a normal American nerd -Jack Herer On 11/09/2011 08:00 AM, Joe Greco wrote: On Wed, Nov 09, 2011 at 03:32:45PM +0300, Alex Nderitu wrote: An important feature lacking for now as far as I know is content/web filtering especially for corporates wishing to block inappropriate/time wasting content like facebook. 1. That's not a firewall function. That's a censorship function. A firewall is pretty much a censorship function, you're using it to disallow certain types of traffic on your network. It's simply a matter of what layer you find most convenient to block things... a firewall is better closer to the bottom of the OSI layer model, a proxy is better closer to the top of the OSI layer model. Is it censorship not to want unwanted connection attempts to our gear, and block unsolicited TCP connections inbound? Is it censorship not to want unwanted exploit attempts to our gear, and run everything through ClamAV, and use blocklists to prevent users inadvertently pulling content from known malware sites? There's no functional differentiation between blocking content for one reason and blocking it for another. There's certainly a huge difference in the POLICY decisions that drive those blocking decisions, but the technology to do them is essentially identical. You can, after all, block facebook on your firewall at the IP level and I think we would both agree that that is censorship but also something a firewall is completely capable of. It's just neater and more practical to do at a higher level, for when facebook changes IP addresses (etc), so a higher level block is really more appropriate. 2. You can of course easily do that via a variety of means, including BOGUS'ing the domains in DNS, blocking port 80 traffic to their network allocations, running an HTTP proxy that blocks them, etc. I presume that any minimally-competent censor could easily devise a first-order solution (using the software packages supplied with OpenBSD) in an afternoon. It's a little trickier to do in practice. I kind of wish pfSense included such functionality by default, it'd be so killer. :-) Last I checked, it was possible-but-a-fair-bit-of-messing-around. Still, vote++ for pfSense. ... JG
Re: Firewalls - Ease of Use and Maintenance?
OH yeah! MANAGEMENT: If you have a few FWs and you manage them independently life is grand. But what if you have 20? 50? 100? and if 30-40 percent of the policy is the same? Cisco: NOTHING. Don't let them lie to you. CheckPoint: Provider 1 and SmartManager. Juniper: Not sure. BSD/PFSense: Nothing I know of Others: ??? Disclaimer: We are currently a CheckPoint/FWSM/PIX/ASA/Juniper shop. This is the byproduct of mergers/acquisitions/etc. We have standardized on CheckPoint and are phasing out the other vendors as they sunset. A major factor in the decision was management. In the end, if you separate the functions like we do, a FW is a FW is a FW. L3/4 isn't that complicated these days. It's L7 FWs that get the attention. So if the product is stable and has a good MTBF then it's not a huge difference to us as far as the capability of the FW to perform it's function. They all do it well. -Hammer- I was a normal American nerd -Jack Herer On 11/09/2011 08:52 AM, -Hammer- wrote: I think that firewall/censorship is all semantics. The real question is the scale of the environment and the culture of your shop and areas of ownership. I work in a large enterprise. Combining functions such as L3 firewalling with content filtering with url filtering with XXX can be difficult. 1. Can the platform actually handle all the traffic? 2. Does one group own ALL the separate functions? If not, RBAC becomes an important (and sometimes political) issue. 3. How easy is it to troubleshoot? Although modern hardware is quickly catching up with all the glorious software features people want these days, in our environment we found it easier and saner to separate these functions. They were owned by different groups and the number of FWs we deploy vs the number of content filters didn't add up to make sense when aggregating functions was discussed. In a smaller operation a Fortinet or other product that consolidates these efforts may make sense. In a larger operation in depends on many outside factors. I've had the (dis)pleasure of working with PIX/FWSM/ASA since Vietnam. I've worked with Netscreen/Juniper, IPTables, PFsense, CheckPoint over Nokia, CheckPoint over Winblows, CheckPoint over UTM, Fortinet, Sonicwall (say Uncle!) and others. They all have their pros and cons and in the end it is specific to your shops needs. More of a UNIX guy? BSD FWs. No we aren't going to talk about how BSD isn't UNIX. That's a different mailing list. More of a Linux guy and need to make sure you have a vendor to yell at? CheckPoint. IPSO/SPLAT/GAEA is all Linux. Not a UNIX/Linux guy and you need a more reliable vendor? And a traditionally safer bet? No one ever got fired for buying Cisco. Need to save money? Consolidate functions? Confident of the capabilities of the product? Fortinet. And the list goes on and on and on -Hammer- I was a normal American nerd -Jack Herer On 11/09/2011 08:00 AM, Joe Greco wrote: On Wed, Nov 09, 2011 at 03:32:45PM +0300, Alex Nderitu wrote: An important feature lacking for now as far as I know is content/web filtering especially for corporates wishing to block inappropriate/time wasting content like facebook. 1. That's not a firewall function. That's a censorship function. A firewall is pretty much a censorship function, you're using it to disallow certain types of traffic on your network. It's simply a matter of what layer you find most convenient to block things... a firewall is better closer to the bottom of the OSI layer model, a proxy is better closer to the top of the OSI layer model. Is it censorship not to want unwanted connection attempts to our gear, and block unsolicited TCP connections inbound? Is it censorship not to want unwanted exploit attempts to our gear, and run everything through ClamAV, and use blocklists to prevent users inadvertently pulling content from known malware sites? There's no functional differentiation between blocking content for one reason and blocking it for another. There's certainly a huge difference in the POLICY decisions that drive those blocking decisions, but the technology to do them is essentially identical. You can, after all, block facebook on your firewall at the IP level and I think we would both agree that that is censorship but also something a firewall is completely capable of. It's just neater and more practical to do at a higher level, for when facebook changes IP addresses (etc), so a higher level block is really more appropriate. 2. You can of course easily do that via a variety of means, including BOGUS'ing the domains in DNS, blocking port 80 traffic to their network allocations, running an HTTP proxy that blocks them, etc. I presume that any minimally-competent censor could easily devise a first-order solution (using the software packages supplied with OpenBSD) in an afternoon. It's a little trickier to do in practice. I kind of wish pfSense included
Re: Firewalls - Ease of Use and Maintenance?
You've worked with all the big dogs. What are you looking for? Alternative options? -Hammer- I was a normal American nerd -Jack Herer On 11/08/2011 05:06 PM, Jones, Barry wrote: Hello all. I am potentially looking at firewall products and wanted suggestions as to the easiest firewalls to install, configure and maintain? I have a few small networks ( 50 nodes at one site, 50 odd at another, and maybe 20 at another. I have worked with Cisco Pix, ASA, Netscreen, and Checkpoint (Nokia), and each have strong and not as strong features for ease of use. Like everyone, I'm resource challenged and need an easy solution to stand up and operate. Feel free to ping me offline - and thank you for the assistance. Barry Jones - CISSP GSNA Project Manager II Sempra Energy Utilities (760) 271-6822 P please don't print this e-mail unless you really need to.
Re: General Internet Instability
I'm struggling to do the same. All the various Internet Health sites show(ed) some upticks in negative performance but I don't have any specifics. We are a Gomez customer and Gomez is showing issues In St. Louis (SAVVIS) and Philly (L3) that specifically impacts the availability of our applications but it's not clear on the underlying reason. I'm giving cautious updates to management because even though it's obvious something is going on I don't have anything official except random email threads. Looking for more insight before misinforming management. -Hammer- I was a normal American nerd -Jack Herer On 11/07/2011 10:09 AM, Todd Snyder wrote: Can anyone point to any authoritative updates about this? On Mon, Nov 7, 2011 at 10:31 AM, Jared Mauchja...@puck.nether.net wrote: On Nov 7, 2011, at 10:08 AM, Tom Hill wrote: On Mon, 2011-11-07 at 10:00 -0500, Todd Snyder wrote: We seem to be having some problems with our tata links - first seen in EU about 45 minutes ago, now we're seeing problems in NA. I'm focused on DNS, so I'm seeing a lot of timeouts/servfails, but our networking folks are talking about links dropping. Anyone else seeing oddness on the NA Internet right now? http://downrightnow.com/ confirms - something is up. There are widespread issues across the Internet; certain versions of Juniper firmware have core dumped after seeing a particular BGP 'UPDATE' message. (That's the running theory at least). It's affected multiple service providers, globally, not just those connected to TATA. Pretty much any major BGP event will impact multiple providers. A threshold you should use to view the general instability (which I find valuable, you may as well) is route views data. If you look at the BGP UPDATES archive sizes, you can see when something happens, e.g.: http://archive.routeviews.org/bgpdata/2011.11/UPDATES/ Take a look at the size of the updates.2007.1400.bz2 file and the 1415 file. They are abnormally large compared to a normal period of time. This shows there were a lot of updates out there being processed and a reference to levels of instability. If you are not feeding route views or similar community projects, please consider doing so. It helps paint the view for those doing analysis. - Jared
Re: General Internet Instability
So the file size was 30% higher implies that the number of updates is larger and therefore there is instability? I see the logic but if you scroll thru that page (the whole month of November) there are tons of 1M files. Trying to see what is different about today -Hammer- I was a normal American nerd -Jack Herer On 11/07/2011 10:27 AM, Richard Golodner wrote: On Mon, 2011-11-07 at 11:09 -0500, Todd Snyder wrote: Can anyone point to any authoritative updates about this? I think Jared's suggestion was about as close as your going to get for right now. Look at the size of the files he mentioned as compared to the average size of the others. Hopefully someone will come forth with an authoritative answer later today. Richard Golodner
Re: General Internet Instability
Thank you. This is somewhat of a learning opportunity for me. I hit all the generic Internet health sites and I understand that there IS an issue. Now I'm getting to learn how you guys attempt to understand WHY we had an issue. But my point is the same. If this is the case than the entire month of November reflects instability where I see transitions from 600k to 1M between updates. Yet we didn't experience the same negative customer experience for those. So how do you see the difference with todays events? Digging into files now. -Hammer- I was a normal American nerd -Jack Herer On 11/07/2011 10:45 AM, Jared Mauch wrote: On Nov 7, 2011, at 11:41 AM, -Hammer- wrote: So the file size was 30% higher implies that the number of updates is larger and therefore there is instability? I see the logic but if you scroll thru that page (the whole month of November) there are tons of1M files. Trying to see what is different about today This is an easy benchmark to gauge overall stability. Large files mean something was unstable. Then you need to actually look at them to see *why*. Also since the files are compressed you lose some visibility into what is really in them. - Jared
Re: real data [Re: General Internet Instability]
Jared, This is good stuff and I'm understanding how you interpret the data. So this confirms what we are seeing. How do we take this towards a root cause? Mash it with the Juniper threads and see where it goes? -Hammer- I was a normal American nerd -Jack Herer On 11/07/2011 11:01 AM, Jared Mauch wrote: Here's some real data for those interested. It seems a quick view seems many TATA- Level3 and TATA- GBLX sets of instability. Combined with the overall update levels seen over that 30 minutes, we saw ~1.566M updates at route views. Compared with the 24h prior (2011.11.06 14:15 as reference) we see ~17-20x the updates in the same time period. Now take your control plane and make it work 17-20x as hard, and you can see why we had some even general instability. I don't have better tools for doing a more detailed analysis at this time, but this should get you started in talking to others about what happened. (There were no stand-out prefixes for this time-period, they all had about the same number of updates per prefix). #Updates|Filename +- 42041 2006.1415.out 727711 2007.1400.out 838894 2007.1415.out 2011.11.07 14:15 datafile - Most updates/as-path (complete as seen @ rviews) Count AS_PATH -+ 4563 3549 3356 3172 3549 3356 11492 2912 8492 3356 6453 4755 2729 812 6453 4755 2695 3549 6453 14080 10620 2504 3549 3356 11492 11492 11492 2421 3549 3356 7029 2362 3356 209 721 27064 2244 3356 209 20115 2130 3356 209 22561 2044 7018 6453 14080 10620 2000 3356 209 1934 3549 3356 2907 1909 3356 15412 18101 1821 3549 6453 4755 1807 3356 6453 4755 1660 8492 3356 174 1634 3549 3356 18566 1619 3549 3356 4837 17623 1617 7018 6453 4755 1581 2497 6453 7545 7545 7545 1496 8492 3356 209 721 27064 1478 2497 6453 4755 1437 8492 8928 3356 11492 11492 11492 1427 3356 3549 3216 8402 1395 3356 701 19262 1362 8492 3356 209 20115 1357 3549 7843 7843 7843 10796 1336 3549 3356 6830 6830 6830 1259 2497 3356 1238 3356 9498 1229 812 6453 14080 10620 1229 3356 6453 14080 10620 1221 3356 9121 42926 1220 3549 3356 29314 1203 3549 3356 680 680 680 680 680 1194 2497 3356 5650 7011 1165 2497 3356 9498 1151 8001 4436 7843 10796 1150 3549 3356 15412 18101 18101 18101 18101 17803 1106 8492 3356 6762 7303 1105 3549 3356 55410 45528 1098 3549 3356 15412 18101 17803 1073 3549 7843 7843 7843 1072 3549 3356 7713 17974 1069 3549 3356 15290 1041 3356 3549 1032 3549 3356 11992 1030 3356 4323 1021 3549 6453 7843 11351 1020 8492 8928 3356 7843 11351 1016 2497 3356 11492 1014 3356 2907 1011 7018 3356 2907 2011.11.07 14:00 datafile - Most updates/as-path (complete as seen @ rviews) Count AS_PATH -+ 3894 3356 6453 4755 3504 3549 3356 2930 812 6453 4755 2793 3549 6453 4755 2254 3549 3356 11492 11492 11492 2235 812 6453 14080 10620 1826 2497 6453 4755 1795 3549 3356 7029 1753 3356 3549 1689 7018 6453 14080 10620 1653 812 6453 4755 17488 1649 3549 3356 18566 1613 2497 3356 1568 3549 3356 6830 6830 6830 1496 7018 6453 4755 1419 3549 6453 14080 10620 1394 3356 701 19262 1389 3356 9121 42926 1382 3549 3356 21565 1293 3549 6453 4755 17488 1252 3549 3356 13407 1188 2497 3356 5650 7011 1156 7018 6453 4755 17488 1154 3356 6453 14080 10620 1127 3356 701 3216 8402 1106 8492 9002 3549 6762 7303 1104 3549 3356 4837 17623 1049 39756 3356 7018 1048 39756 3257 7018 1035 2497 6453 7713 17974 1008 3356 3320
Re: TATA problems?
This was posted on pastebin earlier today in case it helps. 1. View Bulletin PSN-2011-08-327 2. Title MX Series MPC crash in Ktree::createFourWayNode after BGP UPDATE 3. Products Affected This issue can affect any MX Series router with port concentrators based on the Trio chipset -- such as the MPC or embedded into the MX80 -- with active protocol-based route prefix additions/deletions occurring. 4. Platforms Affected 5. Security 6. JUNOS 11.x 7. MX-series 8. JUNOS 10.x 9. SIRT Security Advisory 10. SIRT Security Notice 11. Revision Number 1 12. Issue Date 2011-08-08 13. 14. PSN Issue : 15. MPCs (Modular Port Concentrators) installed in an MX Series router may crash upon receipt of very specific and unlikely route prefix install/delete actions, such as a BGP routing update. The set of route prefix updates is non-deterministic and exceedingly unlikely to occur. Junos versions affected include 10.0, 10.1, 10.2, 10.3, 10.4 prior to 10.4R6, and 11.1 prior to 11.1R4. The trigger for the MPC crash was determined to be a valid BGP UPDATE received from a registered network service provider, although this one UPDATE was determined to not be solely responsible for the crashes. A complex sequence of preconditions is required to trigger this crash. Both IPv4 and IPv6 routing prefix updates can trigger this MPC crash. 16. 17. There is no indication that this issue was triggered maliciously. Given the complexity of conditions required to trigger this issue, the probability of exploiting this defect is extremely low. 18. 19. The assertions (crash) all occurred in the code used to store routing information, called Ktree, on the MPC. Due to the order and mix of adds and deletes to the tree, certain combinations of address adds and deletes can corrupt the data structures within the MPC, which in turn can cause this line card crash. The MPC recovers and returns to service quickly, and without operator intervention. 20. 21. This issue only affects MX Series routers with port concentrators based on the Trio chipset, such as the MPC or embedded into the MX80. No other product or platform is vulnerable to this issue. 22. 23. Solution: 24. The Ktree code has been updated and enhanced to ensure that combinations and permutations of routing updates will not corrupt the state of the line card. Extensive testing has been performed to validate an exceedingly large combination and permutation of route prefix additions and deletions. 25. 26. All Junos OS software releases built on or after 2011-08-03 have fixed this specific issue. Releases containing the fix specifically include: 10.0S18, 10.4R6, 11.1R4, 11.2R1, and all subsequent releases (i.e. all releases built after 11.2R1). 27. 28. This issue is being tracked as PR 610864. While this PR may not be viewable by customers, it can be used as a reference when discussing the issue with JTAC. 29. 30. KB16765 - In which releases are vulnerabilities fixed? describes which release vulnerabilities are fixed as per our End of Engineering and End of Life support policies. 31. 32. Workarounds 33. No known workaround exists for this issue. -Hammer- I was a normal American nerd -Jack Herer On 11/07/2011 04:09 PM, Leigh Porter wrote: Any thoughts on just how wide read this was? Did every Juniper that receives Internet BGP updates with the affected software break? Or did it die out quite quickly?
Re: Outgoing SMTP Servers
Girls, You are all pretty. End the thread. Seriously. -Hammer- I was a normal American nerd -Jack Herer On 10/28/2011 01:59 PM, William Herrin wrote: On Fri, Oct 28, 2011 at 1:34 AM, Joel jaegglijoe...@bogus.com wrote: Email as facility is a public good whether it constitutes a commons or not... If wasn't you wouldn't bother putting up a server that would accept unsolicited incoming connections on behalf of yourself and others, doing so is generically non-rival and non-excludable although not perfectly so in either case (what public good is). Interesting. I want to abstract and restate what I think you just said and ask you to correct my understanding: Making a service accessible to the public via the Internet implicitly grants some basic permission to that public to make use of the service, permission which can not be revoked solely by saying so. If that's the case, what is the common denominator? What is the standard of permission automatically granted by placing an email server on the internet, from which a particular operator may grant more permission but may not reasonably grant less? Put another way, what's the whitelist of activities for which we generally expect our vendor to ignore complaints, what's the blacklist of activities for which a vendor who fails to adequately redress complaints is misbehaving and what's left in the gray zone where behavior might be abusive but is not automatically so? Regards, Bill Herrin
Re: [outages] News item: Blackberry services down worldwide, Egypt affected (not N.A.)
What kills me is what they have told the public. The lost a core switch. I don't know if they actually mean network switch or not but I'm pretty sure any of us that work on an enterprise environment know how to factor N+1 just for these types of days. And then the backup solution failed? I'm not buying it either. -Hammer- I was a normal American nerd -Jack Herer On 10/12/2011 09:47 AM, andrew.wallace wrote: Guys the outage has moved to U.S and Canada, I think we need to look at this perhaps being sabotage. http://news.cnet.com/8301-30686_3-20119163-266/blackberry-service-issues-spread-to-u.s-and-canada/ Andrew From: Frank Bulkfrnk...@iname.com To: outa...@outages.org Sent: Tuesday, October 11, 2011 7:32 PM Subject: Re: [outages] News item: Blackberry services down worldwide, Egypt affected (not N.A.) And continues: “RIM'S SERVICE OUTAGE CONTINUES INTO DAY 2” http://www.channelstv.com/global/news_details.php?nid=29652cat=Politics Frank From:andrew.wallace [mailto:andrew.wall...@rocketmail.com] Sent: Monday, October 10, 2011 2:52 PM To: frnk...@iname.com Cc: outa...@outages.org Subject: Re: [outages] News item: Blackberry services down worldwide, Egypt affected (not N.A.) RIM shares down as BlackBerry outage continues http://www.marketwatch.com/story/rim-shares-down-as-blackberry-outage-continues-2011-10-10 Andrew From:Frank Bulkfrnk...@iname.com To: outa...@outages.org Sent: Monday, October 10, 2011 2:47 PM Subject: [outages] News item: Blackberry services down worldwide, Egypt affected (not N.A.) http://english.ahram.org.eg/NewsContent/3/12/23792/Business/Economy/Blackber ry-services-down-worldwide,-Egypt-affected.aspx FYI ___ Outages mailing list outa...@outages.org https://puck.nether.net/mailman/listinfo/outages ___ Outages mailing list outa...@outages.org https://puck.nether.net/mailman/listinfo/outages
Re: [outages] News item: Blackberry services down worldwide, Egypt affected (not N.A.)
I have been witness to N+1 HUMAN failures but never a N+1 hardware failure or system/design failure that warranted questioning the need for N+2. Usually your N+1 failure is (as already referenced) pasting in a bad config that gets replicated or something like that. Not saying the hardware is perfect. It's just that I haven't personally seen a full blown failure like that without human help. Closest example would be an update that wasn't properly vetted in dev/test before migrating to prod. I've seen a few of those that I guess you could blame on the system. Even though the humans could have tested better -Hammer- I was a normal American nerd -Jack Herer On 10/12/2011 10:58 AM, Chris Campbell wrote: I think it raises serious questions about RIM's DR strategy if a DB corruption or switch failure or whatever can cause this much outage. 'Surely' RIM have an second site that is independent of the primary (within reason) that they could of flipped to when they realised the DB was borked. If not then any business that relies on them needs to be shouting from the rooftops to get RIM to fix it. Chris. On 12 Oct 2011, at 16:49, valdis.kletni...@vt.edu wrote: On Wed, 12 Oct 2011 09:52:02 CDT, -Hammer- said: What kills me is what they have told the public. The lost a core switch. I don't know if they actually mean network switch or not but I'm pretty sure any of us that work on an enterprise environment know how to factor N+1 just for these types of days. And then the backup solution failed? I'm not buying it either. Yeah, and that extra comma in the one config file that didn't make a difference when you tested the failover in the lab *never* makes a difference when it hits in the production network, right? Or they changed the config of the primary and it didn't get propogated just right to the backup, or they had mismatched firmware levels on blades in the blades on the primary and backup switches, so traffic that didn't tickle a bug on the primary blades caused the blade to crash on the backup, or... Anybody on this list who's been around long enough probably has enough We should have had N+2 because the N+1'th device failed too stories to drain *several* pitchers of beer at a good pub... I've even had one case where my butt got *saved* from a ohnosecond-class whoops because the N+1'th device *was* crashed (stomped a config file, it replicated, was able to salvage a copy from a device that didn't replicate because it was down at the time).
Re: [outages] News item: Blackberry services down worldwide, Egypt affected (not N.A.)
Again. I know those stories are out there. I'm blessed with a lower profile or higher karma. One of the two. digging thru cube to fine wood to knock on -Hammer- I was a normal American nerd -Jack Herer On 10/12/2011 11:53 AM, Mike Gatti wrote: I have and totally get the point ... -- Michael Gatti cell.949.735.5612 ekim.it...@gmail.com (UTC-8) On Oct 12, 2011, at 9:12 AM, Leigh Porter wrote: -Original Message- From: -Hammer- [mailto:bhmc...@gmail.com] Sent: 12 October 2011 17:10 To: nanog@nanog.org Subject: Re: [outages] News item: Blackberry services down worldwide, Egypt affected (not N.A.) I have been witness to N+1 HUMAN failures but never a N+1 hardware failure or system/design failure that warranted questioning the need for N+2. Usually your N+1 failure is (as already referenced) pasting in a bad config that gets replicated or something like that. Not saying the hardware is perfect. It's just that I haven't personally seen a full blown failure like that without human help. You have not seen VIP2-40s and CEF in action ;-) -- Leigh Porter __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __
Re: Telus mail server admin
Girls. You're both pretty. Really. Move on. -Hammer- I was a normal American nerd -Jack Herer On 10/07/2011 10:40 AM, Paul Graydon wrote: On 10/7/2011 5:30 AM, Joel jaeggli wrote: On 10/7/11 08:26 , Paul Graydon wrote: On 10/6/2011 8:02 PM, John Levine wrote: DISCLAIMER:... Wow. I was thinking about answering the question, but now I don't dare. Regards, John Levine, jo...@iecc.com, Primary Perpetrator of The Internet for Dummies, Please consider the environment before reading this e-mail. http://jl.ly PS: I spent ten years as an elected official with no disclaimer in my e-mail, and lived! That's nice for you, but some of us are stuck with a corporate policy that requires us to use such disclaimers, or face disciplinary actions. The legality and practicality might be questionable but short of quitting and finding other employment over something utterly trivial, what can you do if protests fall on deaf ears? Subscribe from your personal account. Which I do. But note the original complaint was not about using ridiculously long disclaimers on a mailing list, it was about the ridiculously long disclaimer, full stop. Paul
Re: Point to MultiPoint VPN w/qos
CheckPoint Series 80 has 10 ports. I think there is a Juniper option as well. -Hammer- I was a normal American nerd -Jack Herer On 09/06/2011 09:36 AM, Seth Mos wrote: On 6-9-2011 15:49, Positively Optimistic wrote: Greetings Does anyone have a suggestion for a single piece of hardware that would support 8 or less Ethernet interfaces and the two vpn tunnels ? Single piece of hardware, no. If 2, then yes. A PCengines Alix 2D3 with pfSense/m0n0wall and OpenVPN UDP tunnels to the datacenter combined with a Power over Ethernet switch would seem a likely combination. A HP Procurve 8 Port gigabit desktop switch with PoE comes to mind. Not too expensive, fanless, quiet, reliable does VLANS. That way you can power the router and phones from the same (smallish) UPS. Say a 700VA APC. Regards, Seth
