This is not at all a bookmark for myself so that I stop googling this.

• Console into the ASA and reset/reboot the device
• Hit escape when the prompt “use BREAK or ESC to interrupt boot.” appears.
• Now that you’re in ROMMON mode, you’ll need to tell it to ignore the startup config during the next reload.

  rommon #0>confreg

• The following will show in the terminal window:
• Write down or remember the register value now (yours may be different)
• Type “Y” to continue.
• Hit enter for the next prompts to accept the default value of “no” UNTIL you see: “disable system configuration”. You’ll need to type “y” for that one. Hit enter for the rest of the prompts until the ASA adjusts the config register.
• Now you’ll need to reboot.

  rommon #1>boot

• The ASA will reboot and skip loading the startup configuration and place you into a default config.
• You’ll notice below that the ASA was instructed by a 0x040 configuration register that the device has skipped loading the startup config.
• The enable password is blank by default so go ahead type in “en” and hit enter.
• Copy the old startup config to NVRAM so you can change the passwords:

  copy start run
  
  Destination filename [running-config]? Y

• You’ll notice that you are now running your old running config and can change the passwords as follows:

  config t
  
  password password
  
  enable password password
  
  username username password password priv 15

• Lastly, you’ll need to reset your configuration register back to what you wrote down from earlier, save the config, and reboot the ASA:

• Once the ASA reboots, you’ll hopefully remember the new passwords.

So recently I was involved in a project to swap out a Nexus core that consisted of Nexus 7K Chassis with Nexus 5k distribution switches in favor of new Nexus 9396 models. This was my first opportunity to work with the Nexus line of switches whether in production or a lab and thought I’d post a couple of the differences between IOS and NX-OS.

HSRP (Hot Standby Routing Protocol)

First off, HSRP is Cisco’s proprietary redundancy protocol that allows a standby router to take over active control of the packet forwarding process in the event of a failure.
In IOS, the HSRP process is running all the time without user intervention. With NX-OS, you must enable this feature (and others) using the “feature hsrp” command.
Once HSRP is configured, if you remove the “feature hsrp” command, all the HSRP configuration will be deleted.

• HSRPv1 is enabled by default which is not compatible with HSRPv2 BUT can coexist in an HSRPv2 environment (both versions can run on the same device).
• HSRPv1 supports 256 group numbers (0-255) while HSRPv2 supports 4096 (0-4095).
• HSRPv2 is enabled on a per-interface basis.
• NX-OS uses the “hsrp #” command versus the IOS “standby ip” command

In a L3 switch environment this is normally set up in the VLAN SVI’s configuration or turning a switchport into a L3 port using the “no switchport” command and assigning that port an IP address.

HSRP on IOS

SWITCH 1

interface vlan 50
ip address 10.50.50.2 255.255.255.0 
standby 50 ip 10.50.50.1
standby 50 preempt
standby 50 priority 110

SWITCH 2

interface vlan 50
ip address 10.50.50.3 255.255.255.0 
standby 50 ip 10.50.50.1

HSRP on NX-OS

SWITCH 1

interface vlan 50
ip address 10.50.50.2/24
hsrp 0
     ip 10.50.50.1
     preempt
     priority 110

SWITCH 2

interface vlan 50
ip address 10.50.50.3/24
hsrp 0
     ip 10.50.50.1

That’s the basic difference in the configuration between NX-OS and IOS. Nothing special but the NX-OS does simplify things a little and improves readability.

vPC (Virtual Port-Channel) on NX-OS

Above is the vPC connections between the core and a set of distribution switches. Due to other configuration limitations, all routing and HSRP is configured on the core. The 3560X switches are L2 switches to provide out-of-band management for all switches in the racks using VLAN 99. We thought the mgmt ports would be better served as OOB interfaces rather than using them for keep-alive links. Also by moving the keep-alive links to normal interfaces, we were able to provide redundancy with two links vs one.

The Configuration

VPC Peer-Link on the core

*On all the switches with NX-OS, the following needs to be configured*

feature vpc
feature hsrp
feature lacp

VPC Domain and Switch Configuration

SW-CORE-A

vpc domain 10
peer-switch
role priority 120
system-priority 1024
peer-keepalive destination 10.199.199.2 source 10.199.199.1 vrf vpc-keepalive
delay restore 10
peer-gateway
auto-recovery reload-delay 300
ip arp synchronize

SW-CORE-B

vpc domain 10
peer-switch
role priority 150     *lower priority wins*
system-priority 1024
peer-keepalive destination 10.199.199.1 source 10.199.199.2 vrf vpc-keepalive
delay restore 10
peer-gateway
auto-recovery reload-delay 300
ip arp synchronize

SW-CORE-A

interface port-channel99
description VPC Peer Link - SW-CORE-B
switchport mode trunk
switchport trunk allowed vlan 1-499,501-4094
spanning-tree port type network
vpc peer-link

SW-CORE-B

interface port-channel99
description VPC Peer Link-SW-CORE-A
switchport mode trunk
switchport trunk allowed vlan 1-499,501-4094
spanning-tree port type network
vpc peer-link

Port-Channel Members (Same on both switches)

99    Po99(SU)    Eth      LACP      Eth1/47(P)   Eth1/48(P)

VPC Peer Link on the Distribution Layer

SW-DIST-A

interface port-channel1
description VPC Peer Link - SW-DIST-B
switchport mode trunk
spanning-tree port type network
vpc peer-link

SW-DIST-B

interface port-channel1
description VPC Peer Link - SW-DIST-A
switchport mode trunk
spanning-tree port type network
vpc peer-link

Port-Channel Members (Same on both switches)

1     Po1(SU)     Eth       LACP      Eth1/29(P)   Eth1/30(P)   

VPC Peer-Keepalive Links on the Core
These links need to be in their own VRF table and the interfaces need to be Layer3. Also it’s really a pleasure to be able to use CIDR notation rather than type out the subnet mask in NX-OS commands.

SW-CORE-A

interface port-channel910
no switchport
speed 1000
vrf member vpc-keepalive
ip address 10.199.199.1/30

SW-CORE-B

interface port-channel910
no switchport
speed 1000
vrf member vpc-keepalive
ip address 10.199.199.2/30

Port-Channel Members for Keepalive

910   Po910(RU)   Eth      NONE      Eth1/39(P)   Eth1/40(P) 

Member Interface Configuration

interface Ethernet#/#
description keep-alive: SW-CORE-# <> SW-CORE-#
no switchport
vrf member vpc-keepalive
channel-group 910         *lacp*
no shutdown

Peer Keepalives for Distribution

SW-DIST-A

interface port-channel920
description keep-alive: SW-DIST-A <> SW-DIST-B
no switchport
vrf member vpc-keepalive
ip address 10.199.199.13/30

SW-DIST-B

interface port-channel920
description keep-alive: SW-DIST-B <> SW-DIST-A
no switchport
vrf member vpc-keepalive
ip address 10.199.199.12/30

Port-Channel Members for Keepalive

920   Po920(RU)   Eth      NONE      Eth1/2(P)    Eth1/4(P) 

Member Interface (Same for all)

interface Ethernet#/#
no switchport
vrf member vpc-keepalive
channel-group 920        *lacp*
no shutdown

That sums up a basic installation of a VPC domain with four Nexus switches running NX-OS.

I’d like to tell you about having to troubleshoot a network that someone else put in while laughing in the face of best-practices.

Coming soon…..

NBASE-T

In 2014 Cisco and a few other companies formed the NBASE-T alliance to provide faster data rates using existing Cat5e cabling. With newer wireless technologies coming out (802.11ac Wave 2), the bottleneck has become the wired connection. As Cat5e has been out for at least 20 years, has become ubiquitous in its deployment, and the costs associated with upgrading to Cat6 or Cat6A can be steep, something needed to be done to move everyone to next-gen wireless without having to replace their infrastructure.

With NBASE-T there are 2 additional interim speeds available. Gone is the old 10base-t and I doubt anyone will miss it. NBASE-T ports have available speeds of 100/1000/2500/5000 over existing Cat5e with some limitations at 5Gbps:

• 100Mbps and 1Gbps will still work as always at distances of 100m
• 2.5Gbps will operate over Cat5e up to 100m
• 5Gbps will operate over Cat5e/Cat6 up to 100m (the Cat5e seems to be a gray area in regards to guaranteed distances)

NBASE-T or Cisco MultiGig operates on the same technology as 10Gb with some minor modifications to achieve the 2.5/5Gb data rates. 10Gb uses a 400MHz bandwidth with a 6.25 bitrate (6.25 per hertz per channel). For 2.5/5Gb the bandwidth was reduced by 1/4 and 1/2 respectively while keeping the same 6.25 bitrate.

• (6.25 * 400MHz) * 4 = 10,000Mbps
• (6.25 * 200MHz) * 4 = 5,000Mbps
• (6.25 * 100MHz) * 4 = 2,500Mbps

For reference, 1Gbps operates at a bitrate of 4 over 62.5MHz using 4 channels.

• (4 * 62.5) * 4 = 1,000Mbps

Continue reading →

Coming in a couple days.

Here’s something I’ve come across lately. I’ve been configuring stacks of Cisco 2960s using a remote console switch. Like always I set up the RSA key for SSH access and all that and everything is fine. Then the switch is installed onsite and when I attempt to remote into it, I get the following error:
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that the RSA host key has just been changed.
The fingerprint for the RSA key sent by the remote host is
random RSA key fingerprint xx:xx:xx:xx
Please contact your system administrator.
Add correct host key in /home/user/.ssh/known_hosts to get rid of this message.
Offending key in /home/user/.ssh/known_hosts
RSA host key for switch.domain.com has changed and you have requested strict checking.
Host key verification failed.

Someone COULD be eavesdropping on you but more than likely it’s a rebuilt switch with a new RSA key. In my case I don’t know what the issue is since the RSA key has not been changed. The switch was configured, unplugged, installed, powered on, and I get the error.
Obviously you don’t want to disable strict key checking so here are the steps to edit the known_hosts file.
1. Open a terminal window.
2. At the $prompt type “open /users/username/.ssh/known_hosts
3. TextEdit will open the file up automatically.
4. Command + F to find the IP address you’re having the issue with
5. Delete ALL the text associated with that IP address.
6. Close the TextEdit window and try the SSH connection again.

Once you connect to the device you’ll get the prompt to accept the RSA fingerprint.

Here’s the deal: I had to replicate the issue to get that awesome screenshot above and noticed something. If you change just a small part of the RSA fingerprint in the known_hosts file, the switch prompts you to accept the RSA key from the switch. You have to completely replace the RSA key with another key to get the error message. So it looks like the key check feature looks for a key that conforms to the RSA standard. Furthermore, if you just rebuild the RSA key on the switch (crypto key generate rsa modulus 2048), the error doesn’t show up.