The Times, They Are a'Changin'

To all good things, and end must come.  I recently ended my tenure with Marco and accepted a position with a state university.  I'm now leading the Systems Team, which is a formidable challenge, one of which I am excited to get underway.

I'm incredibly grateful for my time and friends at Marco.  I've been given many opportunities to grow and have made some of the strongest friendships I have ever had.

After a couple weeks in my new position, I'm excited to get moving.  Certainly there are new challenges on the horizon.  Higher education faces a unique set of issues that are new to me coming out of a rapidly growing private business.  But from a technology perspective, we're dealing with many of the same issues, such as leveraging cloud resources in ways that make sense technically and fiscally, and keeping infrastructure updated with limited budgets.

I'm excited to continue, and excited to add to my ramblings here as I dive into new and uncharted territory.  Thanks to all my friends at Marco, and my new friends at the university.  I'm looking forward to this bright future!

CCNA DC - more quick hit notes to self

A few more notes to jog my memory:

Ethernet is 802.3 and includes wiring of some sort.  Wireless LAN is 802.11 and is not Ethernet.

The Frame Check Sequence (FCS) is 4 bytes and is in the Ethernet trailer.  It is used for error detection by computing a value and verifying it is the same when the frame is sent.

Ethernet standards:
802.3 = 10Base-T
802.3u = 100Base-T
802.3z = 1000Base-LX (max distance is 5000m)
802.3ab = 1000Base-T
802.3an = 10GBase-T

GBIC - Gigabit Interface Connector
SFP - Small Form-factor Pluggable module

Crossover cable connects pin 1 to pin 3 and pin 2 to pin 6.
Gb Crossover cable crosses pairs of wires, 1-2 go to 3-6, 4-5 go to 7-8

A data link header:
| Preamble | SFD | Src MAC | Dst MAC | Type | ---Data+padding--- | FCS     |
|   7B     |  1B |   6B    |    6B   |  2B  |        1500B       |  4B     |
| -----------------Header-------------------|  --- Payload ------| Trailer |

SFD - Start Frame Delimiter, signifies that the next sequence is the source MAC address.

A hub is a L1 device, repeats on all ports except the originating.

CCNA Data Center - opening remarks

I am about to complete my CCNA Data Center certification.  I have a CCNA Route & Switch due to expire in August, and with the change in my career focus to data center technologies, I felt it was more appropriate to continue this certification path in the data center instead of route/switch.

I'm beginning with the DCICN 640-911, "Introducing Cisco Data Center Networking" exam.  it covers many of the same topics as the CCNA R/S so I'm figuring I'll have a leg up.

So I purchased the Cisco certification guide and will begin there.

The Cisco guide begins with Networking fundamentals, including the OSI model, ethernet LANs, WAN and IPv4 addressing and routing.  It also goes into the fundamentals of TCP/IP transport and applications.

While I have to admit I don't use it every day, I do recall that the OSI model consists of:

1. Physical Layer - the actual wiring and connectors
2. Data Link Layer - physical addressing, error detection (CRC), Protocols include PPP, Frame Relay, HDLC
3. Network Layer - logical addressing network devices, IP addresses, protocols include IP, IPX, RIP
4. Transport Layer - end-to end communication and defines buffering, window size and flow control, error correction.  Protocols include UDP, TCP, SPX
5. Session Layer - Establish, maintain and tear down sessions. Protocols include SQL, RPC, NFS
6. Presentation Layer - Compression, encryption and decryption happen at L6.  Here protocols include ASCII, JPEG, GIF
7. Application Layer - makes data available to software, protocols include FTP, telnet, HTTP(S), SMTP

Where TCP/IP combines some of these into:

1. Link - OSI L1-L2
2. Internet - OSI L3
3. Transport - OSI L4
4. Application - OSI L5-L7

As data moves from one layer to the next, it encapsulates the data it receives from the previous layer, adds some info to the header and passes it to the next layer.  The terminology for the encapsulated data at each layer is:

1. L1 - bits
2. L2 - frame
3. L3 - packet
4. L4 - segment
5. L5-L7 data

Instead of bits-frames-packets-segments-data, the OSI model uses "Protocol Data Units" such as L7PDU, L6PDU, which consist of the data encapsulated in that particular layer's header and trailer.  Someone should have thought of that before everyone started with the commonly used terminology above...while it's more clear, let's face it...nobody uses that.

And a few other reminders for myself from chapter 1:

Adjacent-layer communication happens within the same computer between different layers, while same-layer communication occurs between different computers.  Adjacent-layer communication is when one layer requests or provides services to the layer above or below it.

The TCP/IP model in recent years shows the Link Layer at level 1 split into 2 layers, the Data Link and Physical layers.

Sending an F11 to ESXi from a Macbook Pro when using RDP to a Windows system for installation

Many more irritating moments spent wishing I had written this down somewhere.

I work remotely much of the time.  I'm currently reinstalling ESXi on a number of hosts and using a workstation located on the LAN of my office to hold the install ISO.  I'm accessing it via RDP from a Mac connected by VPN.  I have configured my Mac to use F-keys in a more traditional manner like I recorded in this post, but for some reason the F11 would show the desktop instead of actually instructing the ESXi installation to continue.

The secret key sequence is:

Command+F11

I don't know what it is about the Mac that makes it behave like this, but I'm tired of wasting time searching for this answer.  I hope I remember it now...

Avamar Commands

Avamar MCCLI commands I use regularly:

View all clients (pipe to grep for selective search):
admin@AVAMAR001:~/>: mccli client show --recursive=true

Retire a client:
admin@AVAMAR001:~/>: mccli client retire --name=</path/to/client>

Naviseccli commands

A handy reference of naviseccli commands I use:

Get stats on a particular LUN:
C:\>naviseccli -h <SP> lun -list -l 56 -perfData
C:\>naviseccli -h 1.1.1.1 lun -list -l 56 -perfData

Get stats on all LUNs
C:\>naviseccli -h <SP> lun -list -perfData

Proactive disk copy to hotspare:
C:\>naviseccli -h <SP> copytohotspare <disk-to-replace> -initiate

Check status of disk with percentage rebuilt:
C:\naviseccli -h <SP> getDisk <disk-being-replaced> -stat -rb

A List for 2016

I have a few objectives this year and I've decided that I'll leverage the accountability of the Internet to keep me honest and on track.  I tend to be more purposeful when I write them out, and this helps me stay reminded of the long-term goals for the year in the midst of the daily fires and tasks.

So, without further ado, here is my list of career objectives for 2016:

1. Build an effective monitoring process for our storage and virtualization platforms.  Over the past few years the company I have worked for has grown substantially, both organically and through acquisition.  This makes for a very dynamic storage infrastructure, requiring me to be able to report quickly and efficiently on where we're at today, where we've been based on landmark events, and what is a reasonable projection.  
2. Expand knowledge and understanding of public cloud services and how they may integrate to serve our company's infrastructure.  While I haven't fully bought into migrating our data center into "the cloud," I'm afraid the writing is on the wall as far as the use of public/private cloud infrastructure goes.    There are several players involved, and my company is partnered with several.  To ignore this technology would be to ignore the future, and I've got a lot of "future" left in my career.  It will be better to know and understand well enough to make informed decisions where this technology is a good fit and if not, be able to answer with authority to state as such.
3. Expand my understanding of OpenStack, SDN and related projects for data center orchestration.  Determine if there is a good fit in the mid-size enterprise for this technology.
4. Expand my knowledge and use of Python as a means of automating processes in the data center.  This dove-tails into the above objective, as well.
5. Renew my CCNA Route/Switch via CCNA Data Center.  My life seems to be going down the path of Data Center Engineering more than routing and switching.  I'll go this direction and use the CCNA/DC to renew my CCNA/RS.

I have several other objectives, but these are the over-arching goals.  I've decided not to include project-based goals I've already defined, such as upgrade our EMC VNX storage or add compute.  These are much more tactical objectives and I view them as daily work, not so much as objectives to increase my knowledge and expand my understanding.

I'll be posting my study notes again as I start down the CCNA Data Center learning track, and am also planning a trip to EMC World 2016 this year.  It's going to be fun and exciting...