Recently, my wife, who is also my business partner, came to the realization we were having one common problem at our office, our administrator. Nicole is an excellent clinician and is dedicated to her field like none other; however, this makes her a terrible business person because she is far too focused on helping someone. What this meant was keeping someone who clearly wasn’t fit for the job they took on and had gone far too long in that position; thus costing the company thousands in unprocessed and ill reported claims along with paying her a salary to which I have absolutely no idea what she did to earn it. Now, what makes this decision tough? Her child was a former patient and Nicole had grown close to the family. That isn’t all of it either, this woman had serious medical issues she needed to go into surgery for and would be out of commission for weeks on end and couldn’t be at the office to perform the duties of her job.

So, the prime time to have let her go had been passed because Nicole only saw that our office administrator was taking a “load” off her, that being answering phones and scheduling, which can be time consuming but shouldn’t take all of her 4 hours to perform each day. So, with the best time to have let her go already long gone I was faced with having to advise her that she wouldn’t have to work from home while recovering, because her value add to the business was absolutely zero and I would have paid her money to do absolutely nothing. So, she was told to focus on her recovery and to visit the office when she was fit enough to do so; however, it was advised she would likely just be paid her last paycheck but we were unsure if we would be in need of her services after that.

Here is something we all should learn from this scenario, learn to let people go, it could be the best thing for everyone involved. I watched this office administrator sink into a hole she could no longer crawl out of; however, someone else couldn’t see who was holding the shovel and had assumed this person was of some value, only until Nicole saw how far behind we actually were, which was costing us thousands of dollars per month. If you own a business or sit on a board where you have the responsibility of hiring and terminating people, never be afraid to cut someone loose if they’re failing at their job, it serves no good if the person isn’t able to come up to speed in a reasonable time to help support the business, you’ll only hurt yourself and those who also believe in your small business. Learn to let people go before they end up a bigger disappointment, one you’ll regret. Instead, learn from the mistake so it becomes a lesson you can use later on when deciding who to hire and when to terminate someone. Once again, terminating someone is stressful for both parties involved, but sometimes you have to learn to let that person go so they can realign themselves with a different organization, perhaps in a different role, to achieve success because they’re obviously never going to achieve it here.


It is a common mistake to assume X number of ports in an etherchannel equates to the common port speed * X; however, this is grossly incorrect and I’ll attempt to explain this behavior to you in layman terms

First, you should ALWAYS combine etherchannel bonds in even numbers (2, 4, 6, or 8). Why? It is the hashing algorithm used to determine how to load balance across the Etherchannel, more to come on how that works.

Second, you need to examine the traffic patterns on your network. If you have a model where your servers live in the “core” of your office and you have access switches connecting back to the core through etherchannel, you’re likely to have a lot of different source addresses (IP and MAC address) going to a common destination address (IP and MAC address). This is especially true of a backup server solution pulling backups for all your computers in the network or for users sending their default gateway traffic to a router which has a L3 port-channel configured from the core switch, which is a common network pattern you’ll find today. Finally, you can have server-to-server traffic patterns, where the source and destination IP addresses remain constant; however, the servers are probably utilizing numerous source and destination TCP/UDP ports; thus, the Etherchannel carrying this traffic needs to be adjusted. What about if the both models are going across the same Etherchannel (clients to the server and server-to-server) and you can’t build a separate etherchannel? The only recommendation here is to examine your traffic carefully, figure out what is more effective for your organization, we won’t get into that here.

Third, you need to understand what load balancing algorithms are available to you. However, take notice, this largely depends on the equipment you’re using. If your organization, like one I have worked inside, has decided that using 3650/3750 devices as a “core” to their network, you’re limited to the basic; however, if your organization uses true core switches (4500, 6500, 6800) you have all the options available to you. I will list the options available in ALL models below

  • src-ip – Source IP address only
  • dst-ip – Destination IP address only
  • src-dst-ip – Source and destination IP address only (XOR)
  • src-mac – Source mac address only
  • dst-mac – Destination mac address only
  • src-dst-mac – Source and Destination mac address only (XOR)

Now, here is what you’ll find available on true core switch models, in addition to the above:

  • src-port – Source port only
  • dst-port – Destination port only
  • src-dst-port – Source and Destination port only (XOR)
  • src-dst-mixed-ip-port – Source and destination IP along with the Source and Destination ports
  • src-mixed-ip-port – Source IP address and port
  • dst-mixed-ip-port – Destination IP address and port

The above commands all depend on what you’re running in your infrastructure, hardware and code level. It pays to put in the appropriate devices according to their duties. If you’re using devices like a 3560/3750 as your “core” you could be out of luck considering the few options available to you with one exception, you can look at installed a 10GB module in your switch and running Etherchannel 10GbE. This WILL NOT fix the load balancing issue but it will provide you the increased bandwidth to get you through until you’re capable of installing the appropriate hardware to support your needs This is given you’re using fiber for Inter-switch links and it supports 10GbE across the distances you’re looking to span.

Understanding your traffic patterns will be a process; however, one I think a lot of you forget is about the L3 Etherchannel you could be using between your core switch and your router. Think about this, the switch resolves the next-hop default gatway and this NEVER changes; thus, destination traffic address is always the same; thus, if you want to see if you’re able to utilize that Etherchannel more appropriately, set your etherchannel to hash based on source mac address towards the router.

I won’t let this get too long, I’ll follow up with some nice diagrams later.


Much like on firewalls you can create object groups in Nexus, which you can utilize when you’re implementing ACLs


object-group ip address {OBJECTNAME}
{subnet/mask}
{subnet/mask}
{subnet/mask}...
exit

ip access-list {ACL_NAME} permit ip addrgroup {OBJECTNAME} [destination]

Makes like simple, huh? What about showing the access-list that has been configured with an object group? Well, under the show access-lists summary you won’t see this, you’ll need to “expand”

show access-lists {ACL_NAME} expanded


In Cisco IOS, this is a monumental pain in the ass if you have a lot of interfaces, typically you’re searching the running config by eye or, if you know how to script, you can send the output to text and filter it the information to get what you need. However, all that sucks because in NX-OS you can just do this

show access-lists summary

The output will give you not only what access-lists is tied to what interface, but also the direction the ACL is applied to. You’ll see the configured section and the active session. Just remember, you can configure the ACL on the interface, but if the interface is not IP enabled, or just plain down, it will not be listed in the active section.


Why do VTP in the data center? I have absolutely no explanation for this, it is generally just a bad idea to use VTP to begin with. Perhaps “easy” is one argument, but look at the problems you face with it:

  • Rogue switch with higher revision can screw the network
  • ON some IOS versions, if not all, the VLAN configuration doesn’t reside in the startup-config
  • Rogue switch can be used to gather VLAN information on the network, helping form an inside attack

In a data center you expect a highly available, reliable, and secure computing environment, this is something VTP simply doesn’t offer for a network in the data center. Look at the Nexus lineup, VTP is a feature which is disabled by default! What a great concept, finally! I’ll go ahead and just say it, if you’re using VTP in the data center, you’re just being lazy.


Want to know what subnets are being discovered/learned off a specific interface? The the show ip cef [interface]

wan-gw1#show ip cef ser2/0
0.0.0.0/0
nexthop 10.129.23.65 Serial2/0
10.16.0.0/12
nexthop 10.129.23.65 Serial2/0
10.32.0.0/16
nexthop 10.129.23.65 Serial2/0
.....Lines omitted for brevity

Just that simple, just remember the purpose of CEF, if you forgot, read: Cisco IP CEF Overview


Let’s just get down to business, we all use it but few of us understand what any of it means. The documentation is a little, well, complicated for some people so I aim to give you a better understanding of the Cisco configuration register, also known as the config register or config-reg. Read the rest of this entry »


No doubt every engineer has their own twist on coding something to better automate configurations and deployment on networks; however, with the every increasing pace of release changes to current software sets installed on some vendors hardware, the workload to keep your scripts updated can become your full time job. There will always be two schools of engineer: the home brew and the purchased software schools, each one with their own compelling reason to use the other and why the other is wrong. I, personally, prefer the purchased software route with a small dash of home brew scripts to accomplish my job, very small. I’ll outline some experiences I’ve had in the past where both moving towards the use of purchased software solved the many problems the home brew scripts were giving us and how a small, but powerful, set of home brew scripts gave us complete control over the network from building, deploying, operating, and debugging. Read the rest of this entry »


I recently was watching a CBTNuggets video when I heard mention that you could use a careful wildcard mask to select odd or even numbered subnets for route advertisement; however, I noticed there was something off about the comment and investigated a little deeper.

We’re continuously taught early in our networking careers about having wildcard masks which end at byte boundaries or needing to be consecutive 1’s and 0’s; however, this is merely a teaching tool and not so much the case in real life. You see, a wildcard mask in an ACL is used to select routes based on the selected wildcard masks and what positions the 1’s line up to ensure matching, just remember that where you have a 0 you must match and where you have a 1 you don’t need to match exactly, the “I don’t care bit”.

Now, let’s get down to an example you’ve probably seen: You need to only redistribute odd number routes from one protocol to another using a distribute-list that references an ACL.

Let’s say we have: 10.0.[0-20].0/24 and these networks are the ones in question. You only want to select the odd number ranges to be redistributed. Let’s look at this from a binary perspective to see what all the odd numbers have in common in the third octet:

10.0.1.0/24 = 00000001
10.0.3.0/24 = 00000011
10.0.5.0/24 = 00000101
10.0.17.0/24= 00010001
10.0.19.0/24= 00010011

Notice in the odd numbers the only bit remaining the same is the last bit, all the others are changing. Now, here is an interesting concept which may blow your mind, but we’ll move back to the old way from when you were probably learning subnetting:

128|64|32|16|8|4|2|1

Now, you can add up all those numbers except the last bit (1) and you’ll always have an even number; however, utilize the last bit and you have an odd number, always. So, what is the wildcard mask you ask? Not 0000001 like some people will tell you, no, in fact that is quite the opposite because you’re saying you don’t care about the last bit, it can be whatever, even or odd in the third octet. Instead, your wildcard mask looks like this:

00000000.00000000.11111110.00000000 = 0.0.254.0 – The last bit in the third octet must always be the same from the start.

How does that work you ask? Quite simple, when you setup your ACL the key point isn’t so much the wildcard mask, it is the starting subnet you reference in the ACL:

10.0.1.0 0.0.254.0 = Will match all odd number subnets
10.0.0.0 0.0.254.0 = Will match all even number subnets

Why? Take a peek at the binary in the third octet:

10.0.1.0 = 00000001
0.0.254.0= 11111110

You see the last bit is one and must remain the same. What about even?

10.0.0.0 = 00000000
0.0.254.0= 11111110

Now, the last bit is zero, meaning any combination of bits used before it will always equal even numbers. How is this still all possible you ask? Well, we’re using standard ACLs, so we’re only referencing the host/source as a “starting point”. Think not of ACLs as “networks” but a tool which takes the portion you set in the “network” portion as a starting point to begin processing against the wildcard mask.


Just a quick tip for those looking. If you’re using 6.X code you can use the F2E for an internal OTV interface. You can actually get control plane traffic between two devices using an F2E, you’ll see the mac addresses in the: show otv route command; however, no encapsulation will occur. You will need to get an M-series card to perform OTV in a Nexus chassis.