Learned about a new feature today, thanks to a co-worker, that I never knew about…..IOS quiet-mode.  The command reference explains it fairly well starting with the “login block-for” command here.  Basically what this allows you to do, is define a maximum login attempts made on the VTY.  When these attempts are exceeded, IOS will enter quiet mode.  IOS will put an auto-generated access-class in called sl_def_acl that will prevent telnet, ssh and www access.  You can also define your own ACL to go into effect when IOS enters quiet mode.  Consider the following:

ip access-list extended sshAccess
 permit tcp 10.0.0.0 0.255.255.255 eq 22 log
 permit tcp 172.16.0.0 0.0.31.255 eq 22 log
 permit tcp 192.168.0.0 0.0.255.255 eq 22 log
 deny ip any any log

ip access-list extended quiet-sshAccess
 permit tcp 10.1.1.1 0.0.0.0 eq 22 log
 deny ip any any log

login block-for 360 attempts 6 within 100
login quiet-mode access-class quiet-sshAccess

The login block-for command has to be entered before you enter the login quiet-mode command.  In this example, you would apply the ACL sshAccess to your VTY as normal using an access-class command.  Then, you enter the above login commands and quiet-sshAccess ACL, and after 6 attempts within 100 seconds are made, IOS will enter quiet mode for 360 seconds. During the quiet-mode the quiet-sshAccess ACL is in place, so only host 10.1.1.1 can ssh to the device.  It’s very simple.  With today’s brute force hacking botnets, something like this is very useful.  Another good command to combine with it is the login delay command which you can read about here.  This allows you to put a delay between login attempts to further hamper brute force login attempts.

When EMC re-did their group/role mappings for Celerra Administrative Roles, back in 2008 or so (When DART 5.6 was released), they had a chance to create a new set of group/roles that totally make sense.  And for the most part they do, but does anyone else see something wrong with this picture?

So with the security in Celerra, Roles and Groups have a One to One relationship.  You can see that the fullnas group is mapped to the Nasadmin role.  The nasadmin group is mapped to the Operator role.  ?!?!?!??!  To me, it would have made a lot more sense to create an operator group and map the Operator role to that.  Maybe I am just being a bit OCD about this, but it just bothers me that the entire scheme looks relatively clean, and they had an opportunity to make it just so perfect, but left in this confusing point.

Now, why are some of the Role Names capitalized and others not?  I have no idea.  But I must say this.  EMC Education does a hell of a job cranking out a great amount of material.  So sometimes typo’s exist and things are actually correct(ed) in the OS, and other times they are just the messenger and have nothing to do with the design of the system (actually, that’s probably most cases).

I have been impressed in watching the advancements of the Celerra from a few years ago until now morphing into the VNX.  Things have always improved greatly.  I am not a heavy user of RBAC, simply because I look at it more like there are two options:  Those that should have access and those who should not .  Obviously we design things for customers based on their requirements but I like to have an educated group who have access, and then not have to worry about those that don’t.  When I say educated, I don’t mean they are the Grand Master at all things, Celerra in this case, but that they understand enough to know there are things they should touch and things they should not.

If you don’t know much about Celerra, you shouldn’t be doing something like following commands that start off with you doing “export NAS_DB_DEBUG=1″.

NetApp DS14mk2

One of the questions I am asked many times is about what type of disk storage (JBOD) can be used for CCIE Storage studies.  There are many that can be used.  I prefer to use something that is public loop and has SFP interfaces.  I also prefer to use something that supports multiple loops and allows the partitioning of those loops so you can effectively have one box do the job of two.

I have written about how I like the Xyratex RS-1600-FC2 boxes.  These are in fact what NetApp OEM’ed for the DS14mk2 shelves and you can find them on ebay, craigslist, and other places.  Now I must caveat that I have not used one of these in this capacity myself, however, it’s in fact a JBOD so there is no reason it should not work.

One of the things that the NetApp Filers do however is they do write some custom information to the first sector of the disks.  You will want to zap that information.  Easiest way is to just attach the shelf to a linux fibre card or you could do this with Windows if that is what your comfortable with.  Using Linux, follow the guide here:

http://cuddletech.com/articles/netapp/netapp-evms.html

Which explains nicely how to setup a basic Linux FC card, zap the first part of the disk using dd, and also has some great information on  using the Linux LVM.

I am a huge fan of Linux, and I definitely like it more than Windows.  However, I must say that during my lab studies all my initiators were Windows.  This just makes sense to me, as the windows has easy to download iSCSI initiators, FC stacks/drivers, tools, RADIUS and TACACS tools, etc.  Sure, you can track all this down on Linux but likely the books your studying with are going to assume you are using Windows.  Now, that aside, I do prefer to do low level maintenance tasks using linux, such as zapping the drives as described by cuddletech.com.

I do not know if the LRC’s in the NetApp shelves are as feature rich as you would find on the RS-1600-FC2.  On the DS14mk2 you may find them with ESH modules or the newer ESH2 modules.  The ESH2 modules support auto-terminating FCAL.  Other than that I am not sure if there are any important differences for someone trying to use it as a JBOD, but personally I would look for a DS14mk2 with ESH2.

What about the DS14 (non-mk2)?  Well, these should work just fine as well.  These have copper interfaces, and so you would need to use a MIA, but I don’t see why in the end you would not be able to get it to work just fine, and you can likely find it cheap.

I do not know much about whether any of the DS14 (mk1 or mk2) have the DIP switches that allow you to break into multiple loops and set various tasks.  My thought is no they don’t.  Just looking at the ESH’s they look to be single loop devices (1 in, 1 out), but if you find out otherwise, please post here.  Good Luck!

This may be helpful for those of you who want to test application scripts on a CME environment, this may be confusing so follow along.

Say you have a voice application, and you need to test it on an inbound voip call leg.  CME gives you no easy way to do this.  With full CUCM your calls from the voice server come in on an inbound voip leg, which you can easily control.  With CME, calls actually do come in on a VoIP call leg, but its a hidden peer which you do not have the ability to modify.  So what you must do is call yourself.

In this example you want to run a voice application, and voice applications run on a voip dial peer.  And you want the call to go out an FXS port.  But since your a phone registered to the CME how can you make your call go through a voip dial peer?  You call yourself.  So say the endusers are to dial 1001.  What you need to do is setup like so:
!
voice translation-rule 2
 rule 1 /1001/ /1002/
!
!
voice translation-profile 2
 translate called 2
!
!
application
 service myapplication flash://myapplication.tcl
!
dial-peer voice 200 pots
 destination-pattern 1002
 port 2/0
!
dial-peer voice 300 voip
 translation-profile outgoing 2
 destination-pattern 1001
 session target ipv4:172.16.2.2 <————- This is the CME’s IP address
 dtmf-relay h245-alphanumeric
 codec g711ulaw
 no vad
!
dial-peer voice 301 voip
 service myapplication
 incoming called-number 1002
 dtmf-relay h245-alphanumeric
 codec g711ulaw
 no vad

So you call 1001, it matches an outgoing voip dial peer, which then translates the called number so now you go inbound on another voip dial peer, which then goes outbound to your pots dial peer.  This is pretty crazy, but if you think about how dial-peers work in CME it seems to be the only way.

We use incoming called-number to make sure our re-routed call comes in on this peer.

Why would you need to do this?  Well for one, to test TCL applications.  Maybe you have a CME available to you, but you don’t have a CUCM environment……although these days, with virtualization most people do have a test CUCM at their disposal.  The other reason, would be you actually want to run the TCL application on CME.  For example say you have a TCL application that supervises the FXS line and hangs it up after a set timeout.  This is useful if your using like a page port tied to an FXS, and you don’t want it to get “stuck”.  Some page units don’t properly supervise the line, and can get confused…….this is just an example.  You can use this re-routing of traffic in any voip application scenario.

I am humbled that EMC chose me this month for their Proven Professional Spotlight piece. I have the fortunate job of working with many who know more than I do and am elevated by our collective success. EMC is a great partner of ours (Presidio) and I am grateful for our excellent relationship.  All told I now have 7 EMC certifications and I am currently working on my VNX Implementation Engineer (VILT is on the way!).  I don’t get to use the equipment that much but it’s important to me to understand how it works and it’s capabilities as I enjoy being a part of solutions discussions.

Main community page:  https://community.emc.com/community/connect/emcpp

Direct to spotlight:  https://community.emc.com/message/578882