Posts Tagged ‘Cisco’

We know that for switches to cooperate inside each region the following must be configured the same:

  • Name – Case Sensitive
  • Revision – Any number, but should be the same
  • Instance mappings and their respective VLANs

Now, what about the VLANs themselves? What about switches and security? I looked all over for this answer and it was vague at best and each vendors documentation said something a little different from each others. However, this is just my preliminary testing, I added multiple instances to my spanning-tree setup on my Cisco Catalyst 3750. My scenario was as follows along with the outputs:

  1. Two instances
  2. Instance 1 had all the real VLANs that were actual VLANs on the switch
  3. Instance 2 had 2 VLANs mapped
    • The first test of MIST2 was with both VLANs not being defined on the switch
    • The second test of MIST2 was with one VLAN defined and the other not
    • The third test of MIST2 was with both the VLANs defined

Because MST instances themselves do not communicate the actual VLANs or VLAN mappings, and IST/CIST does not actually communicate the actual VLAN-to-Instance mapping either. Instead, we rely on IST0 to transmit the BPDUs that contain our information like: name, revision, checksum/Config digest/hash and the actual configuration digest/checkum/hash is the value to which each switch will calculate to determine if they’re operating in the exact same region or in different regions. The digest/hash/checksum is calculated based on parameters present in the MST configuration table. Want to know more about the hashing? Here is a link: 802.1s explained.

The information is long and boring, but do a search for “digest” and you’ll find yourself deep into figuring out how this all works. The test results are soon to come, I am working on both Catalyst and Nexus outputs to benefit not just enterprise and branch, but for those in the data center who’re having to work in vPC hybrid environments with STP attached devices. More to come…


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


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 »


All Cisco switches by default have PVST+ as their spanning-tree protocol (mode). PVST+ is Cisco proprietary and, in my humble opinion, should never be used in a production environment. The alternatives are: RPVST and MST. In a basic 1-3 VLAN network with little to no knowledge of spanning-tree you should run RPVST (802.1w) and be done with it. However, if you have a lot of VLANs and/or you need to ensure you’re not over utilizing the CPU resources, you should use MST (802.1s).

MST (802.1s) is called Multiple instances of Spanning-Tree Protocol and actually relies on RPVST to run inside each instance. MST runs in instances (think of them as groups) and in those instances you can map as many VLANs as you want; thus, you reduce the number of RPVST processes running. For example, in RPVST if you have 10 VLANs, you will have 10 instances of RPVST running, one per VLAN. However, in MST, if you have 10 VLANs grouped into only one instance, there is only one instance running, not 10.

MST is powerful because it reduces the CPU cycles used for spanning-tree operations but can also be used to create multiple paths for groups of VLANs. Configuring MST is simple and requires only a few things to be configured, which I will show here


spanning-tree mode mst

spanning-tree mst configuration
name SOMENAMEGOESHERE
revision 1
instance 1 vlan 1-4094

spanning-tree mst 0-1 priority 4096

For the breakdown:

  • spanning-tree mode mst – Turns on MST as the spanning-tree mode
  • spanning-tree mst configuration – Places you into MST subconfiguration menu
  • name – The name is case sensitive and must match on ALL switches
  • revision 1 – This sets the revision number, which must match across ALL switches, any number will do
  • instance 1 vlan 1-4094 – This maps all the VLANs to instance (group) #1, taking them out of the default IST instance 0
  • spanning-tree mst 0-1 priority 4096 – This sets the priority of both the IST (0) and instance 1 to 4096 to ensure it is always the root bridge

By default there are two instances started by default: IST (Internal Spanning-tree) and CST (Common instance Spanning-tree); however, these are commonly viewed as just one instance CIST. Basically, CIST interacts with other “modes” of spanning tree and is ALWAYS active on access and trunk ports. You can review the details here .

This brief introduction will end with the output of the command: show spanning-tree mst

Core-Switch-01#sh spanning-tree mst

##### MST0 vlans mapped: none
Bridge address 1833.9da2.5700 priority 4096 (4096 sysid 0)
Root this switch for the CIST
Operational hello time 2 , forward delay 4 , max age 6 , txholdcount 6
Configured hello time 2 , forward delay 4 , max age 6 , max hops 20

Interface Role Sts Cost Prio.Nbr Type
---------------- ---- --- --------- -------- --------------------------------
Fa1/0/1 Desg FWD 200000 128.3 P2p
Fa1/0/2 Desg FWD 200000 128.4 P2p
Fa1/0/3 Desg FWD 200000 128.5 P2p
Fa1/0/4 Desg FWD 200000 128.6 P2p
Fa1/0/5 Desg FWD 200000 128.7 P2p
Fa1/0/6 Desg FWD 200000 128.8 P2p
Fa1/0/9 Desg FWD 200000 128.11 P2p
Fa1/0/12 Desg FWD 200000 128.14 P2p
Fa1/0/22 Desg FWD 200000 128.24 P2p
Fa1/0/23 Desg FWD 200000 128.25 P2p
Fa1/0/24 Desg FWD 200000 128.26 P2p

##### MST1 vlans mapped: 1-4094
Bridge address 1833.9da2.5700 priority 4097 (4096 sysid 1)
Root this switch for MST1

Interface Role Sts Cost Prio.Nbr Type
---------------- ---- --- --------- -------- --------------------------------
Fa1/0/1 Desg FWD 200000 128.3 P2p
Fa1/0/2 Desg FWD 200000 128.4 P2p
Fa1/0/3 Desg FWD 200000 128.5 P2p
Fa1/0/4 Desg FWD 200000 128.6 P2p
Fa1/0/5 Desg FWD 200000 128.7 P2p
Fa1/0/6 Desg FWD 200000 128.8 P2p
Fa1/0/9 Desg FWD 200000 128.11 P2p
Fa1/0/12 Desg FWD 200000 128.14 P2p
Fa1/0/22 Desg FWD 200000 128.24 P2p
Fa1/0/23 Desg FWD 200000 128.25 P2p
Fa1/0/24 Desg FWD 200000 128.26 P2p

Notice that MST0 has no VLANs mapped but is still active on all the same ports listed in MST1. Also notice it says: Root this switch for CIST


Yup, they have something similar now, here is the skinny:


archive
path flash1:
maximum 14

Now, before you make a change, issue this command:


configure terminal revert timer <1-120> <--- in minutes

Go ahead and make your changes, if you get disconnected, it will rollback the configuration in the amount of time you selected.

If the configuration works and you want to commit the changes:


configure confirm

That's all folks, a "commit confirmed" for Cisco IOS.


From: 9 Immutable Laws of Network Design – Let’s be simple, this is opinion, not law. Network design is network design and each person will have their own unique view on how to build networks. However, to say immutable laws is arrogant and only tells people you’re stuck in your ways; thus, if you stand still you’re falling behind. Read the rest of this entry »