Search
Randomness (via klauster.com)

Entries in Cisco (6)

Tuesday
May222012

Configuring Jumbo Frames on Cisco Data Center Switches

Ethernet jumbo frames are a common requirement in data center networks, especially ones that rely on Ethernet based storage protocols such as NFS and iSCSI. Jumbo frames are not enabled on Cisco switches by default - here are the commands to configure the larger MTUs on the most common switches seen within the data center.

Nexus 5000s and 5500s

Enabling jumbo frames on the Nexus 5000/5500 platform is done via a policy-map. When applied using class-default, jumbo frames are enabled across the whole switch.

policy-map type network-qos jumbo
  class type network-qos class-default
    mtu 9216
    multicast-optimize
system qos
  service-policy type network-qos jumbo

Note: The MTU parameter in “show interface” will continute to show a value of 1500. The best way to verify that jumbo frames is enabled is to setup a ping across the switch to endpoints that are also configured with jumbo frames using a packet size of 9216 and the “do not fragment” bit set (e.g. another switch, a server, NAS controller, etc…).

ping 10.10.10.10 packet-size 9216 df-bit count 10

Nexus 7000

Jumbo frame configuration on the Nexus 7000 is much simpler. Simply set the system jumbo MTU in global config mode:

switch-n7k(config)#system jumbomtu 9216

Then specify the MTU for specific interfaces

switch-n7k(config)#interface ethernet x/x
switch-n7k(config-if)#mtu 9216

MTU settings on individual interfaces can be verified via the “show interface” command:

 switch#sh interface vlan10
 Vlan100 is up, line protocol is up
  Hardware is EtherSVI, address is  4055.3927.2cc1
  Description: Sample
  Internet Address is 10.10.10.1/24
  MTU 9216 bytes, BW 1000000 Kbit, DLY 10 usec,

Catalyst 6500 (IOS Native Mode)

Configuring jumbo frames on a 6500 also requires simply setting the MTU on the individual interfaces:

switch-6500(config)#int GigabitEthernet1/1
switch-6500(config-if)#mtu 9216

Verify using the “show interface” command.

Reference

Cisco.com Configuration of Jumbo MTU on Nexus 5000 and 7000 Series

Cisco.com Jumbo/Giant Frame Support on Catalyst Switches Configuration Example

JasonNash.com Enabling Jumbo Frames on the Cisco Nexus 1000v

Friday
May112012

Using Configuration Sync on the Nexus 5500

Cisco’s Virtual Port Channel (VPC) feature is a nice way to build multiple link redundancy between two switches without the limitations of spanning tree (notably having one link unused in “blocking” mode). VPC is an extension of traditional Ether Channel bundles, but across two separate switches, and is a feature on the Cisco Nexus 5000 and 7000 switches.

A challenge when using VPC is that it requires duplicate and identical configuration of ports on both switches that have member ports. Cisco introduced “configuration sync” in NX-OS 5.0(2)N1(1) for the Nexus 5000s to help with this issue.

Setting up Configuration Sync

The initial configuration to enable configuration sync is simple. You do have to have the mgmt0 interface configured on both Nexus switches so that they can communicate with each other over IP.

The initial configuration involves the following steps:

! Enable CFS distribution over IP
    configuration terminal
        cfs ipv4 distribute

! Configure a switch profile and the sync-peer
    config sync
        switch-profile [name]
        sync-peers destination [peer-IP-address]

The switch profile needs to be identically configured on both Nexus switches that are sync-peers. You will need to enter the switch-profile name everytime you want to add a synced configuration, so keep it short and simple - e.g. “switch-profile vpc”.

Once you have the initial configuration entered you can verify that things are working:

N5K01# sh switch-profile vpc status

switch-profile  : vpc
----------------------------------------------------------

Start-time:  67539 usecs after Wed Apr 25 10:18:18 2012
End-time: 422813 usecs after Wed Apr 25 10:18:20 2012

Profile-Revision: 18
Session-type: Commit
Session-subtype: -
Peer-triggered: No
Profile-status: Sync Success

Local information:
----------------
Status: Commit Success
Error(s):

Peer information:
----------------
IP-address: 10.10.1.4
Sync-status: In sync
Status: Commit Success
Error(s):

That’s pretty much it to get it setup.

Configuring Interfaces and Virtual PortChannels

Configuration sync is most useful when configuring Virtual PortChannels (VPC) since it requires an exact replica of the interface and port-channel configuration on two Nexus 5000 switches.

Entering configuration commands using config sync requires two additional steps beyond entering standard config mode.

  1. Enter normal configuration mode

    config t
    
  2. Enter Configuration Sync mode

    config sync
    
  3. Enter the switch profile name

    switch-profile [name]
    

Now you can enter configuration commands just as you would in normal configuration mode.

It’s About Commitment

There is one important additional difference over normal configuration - commands do not take effect, and are not synced, until you type the “commit” command. You can type any number of commands before committing them.

The “commit” process includes a mutual exclusion check (verify) step that validates that no existing commands are unintentionally overwritten. (You can also check this along the way with the “verify” command before you “commit” a large number of commands.) Commands that are entered in configuration sync mode cannot already be configured through regular command mode, and once configuration sync is used, subsequent changes to that configuration also need to be made in configuration sync mode (with the exception of some interface commands, shut/no-shuts, and system qos).

If commands in the commit buffer fail verification you can delete or edit them and then try the commit process again.

See which commands are sitting in the commit buffer:

    show switch-profile buffer

Commands can be moved in the commit buffer:

    buffer-move [current-seqID] [new-seqID]

Commands can also be deleted:

    buffer-delete [seqID]

To clear the entire commit buffer:

    buffer-delete all

Viewing Config Commands in the Switch Profile

Once a configuration is completed it can be hard to remember which interfaces and features were configured with config sync, and once you use config sync you need to modify those elements in the future with config sync.

To view the running or startup configuration commands that have been entered with config sync:

    show running-configuration switch-profile
    show startup-configuration switch-profile

Importing Existing Commands

If you already have a switch configuration that you want to migrate to a synced switch profile, there is an import process.

For details on importing and additional commands, features, and caveats check the Nexus 5000 NX-OS System Management Configuration Guide - Configuring Switch Profiles

Final Thoughts

The configuration sync is a useful option for setting up a large number of virtual port channels between two Nexus 5000 switches. It can also be used to configure physical interfaces for VPCs as long as identically numbered ports are used on both switches (which I consider a recommended practice anyway). Some may prefer to continue to copy-and-paste manually given the extra number of steps involved in the config-sync.

Update - Using CLI Alias to remember switch-profile

I find that remembering the switch-profile name is the item that trips me up the most when trying to use config sync. An easy way around this of course is to define an alias command for the switch profile:

    cli alias name swpr switch-profile PROFILE_NAME

This way, anytime I want to add config via the config sync feature I just type the following from Enable mode:

    nexus# config sync
    nexus(config-sync)# swpr
    nexus(config-sync-sp)# <enter commands>
    nexus(config-sync-sp)# commit

Done.

Wednesday
Mar212012

Cisco subnetting game

Want to practice your IP subnetting skills? Check out Cisco’s IP subnetting game.

Monday
Mar122012

Quicktip: Evaluating Cisco IOS releases for deployment

I had thoughts of someday writing up a methodology to evaluate Cisco IOS releases for deployment, but Greg Ferro has already done a nice job at Etherealmind so check it out.

Tuesday
Mar062012

New Cisco Catalyst 4500-X 10GE modular switch

Along with 40 GE and 100 GE modules, Cisco recently announced the Catalyst 4500-X 10GE aggregation switch.

Cisco Catalyst 4500-X family

10GE Density

On its face, it looks similar to the Cisco Nexus 5000 series switches, but looking at the features it is definitely more of a campus LAN switch, rather than the Nexus data center line. There are two base configurations - a 16-port and a 32-port 10GE models. Each model has an expansion slot that currently supports an 8-port 10GE uplink model (Cisco datasheets suggest that a 40GE uplink module is on the roadmap).

Similar to the Nexus 5000s, the 4500-X ports support SFP+ 10GE optics along with 1GE SFP modules.

Layer 3 Support

The 4500-X supports both IPv4 and IPv6 routing in hardware, along with support for VRF-Lite and “Easy Virtual Network” (EVN) features. (The Nexus 5000s require an additional expansion module for layer 3 support).

VSS

The most intriguing feature in the 4500-X may be built-in VSS (“Virtual Switch System”) support. Two 4500-X switches can be linked by 10GE ports and configured as a single logical switch. This simplifies configuration while providing a higher level of availability. It also allows ether-channels to be be built across two switches (for link redundancy and performance while eliminating the need to build spanning-tree triangles). The VSS feature has previously been reserved for the 6500 chassis with Supervisor 720s. The 4500-X therefore offers a much more cost effective way to provide a highly available distribution layer (or even a core for smaller environments that want a 10GE backbone).

4500x as a distribution.

Summary

The 4500-X is an intriguing new solution as an aggregation switch for campus LANs that want to bring in 10GE uplinks without the cost or complexity of a chassis based switch. VSS capabilities in particularly allow for a dual switch redundant solution that logically functions as a single switch — a solution that up until now has required a much more expensive chassis based switch.