My CCIE by Adrian Brayton

Console Into A Cisco Device Using Linux

2013-04-16T23:58:00.001-05:00

If you are using some flavor of Linux and find yourself needing to console into a Cisco device using a USB / Serial adapter, here is one way to do this.

You will need to install a program called screen if you don't already have it on your Linux box. It's easy, quick and free so lets get started.

The name of your linux box will be different of course but the command you need will be the same.

abrayton@Home-Mint ~ $ sudo apt-get install screen
[sudo] password for abrayton:

Now that has been installed, lets find your USB Console cable.

abrayton@Home-Mint ~ $ dmesg | grep tty
[ 0.000000] console [tty0] enabled
[ 0.432406] serial8250: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
[ 0.453385] 00:03: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
[ 2.397087] usb 1-1.4: >MCT U232 converter now attached to ttyUSB0

We can see it in the last line of output just above in bold lettering.

So far so good!

Disclaimer: I needed to open the TTY line as ROOT, your system might be set up a little different so you can try it without root if you would like but below is using root.

Just below is the command to use and a little explanation to go with it.

abrayton@Home-Mint ~ $ sudo screen /dev/ttyUSB0 9600
[sudo] password for abrayton:

We are calling the TTY emulator with " screen " using the /dev/ice ttyUSB0 and specifying the speed of the connection which we all know is 9600 bps.

If everything went well than you should be seeing output that you can read such as what you see below.

Press RETURN to get started.

Home_3750G>

Thats it!

Hope this helped get you moving in the right direction!

Cisco WLCM ( Wireless LAN Control Module ) 2800 / 3800

2012-08-29T22:30:00.020-05:00

This post is all about getting the Cisco WLCM initial setup completed correctly to the point where you can access the GUI and login successfully. The additional configuration needed to add AP's, apply security etc. will be contained in other posts.

Disclaimer: The interface's used will depend on what platform / slot you place the module.

On to the good stuff... I decided to add a quick summary / description of the interfaces being used below. Once you understand what the port is doing and going to do, it makes things much easier. (Note: The brief explanations do not cover everything that the interfaces will do, please see Cisco website if you want more information.)

Management Interface -

The management interface is the default interface for in-band management of the controller and connectivity to enterprise services such as AAA servers. It is also used for communications between the controller and access points. The management interface has the only consistently "pingable" in-band interface IP address on the controller. You can access the controller's GUI by entering the controller's management interface IP address in Internet Explorer's or Mozilla Firefox's address field.
For CAPWAP, the controller requires one management interface to control all inter-controller communications and one AP-manager interface to control all controller-to-access point communications, regardless of the number of ports.

AP-Manager Interface -

A controller has one or more AP-manager interfaces, which are used for all Layer 3 communications between the controller and lightweight access points after the access points have joined the controller. The AP-manager IP address is used as the tunnel source for CAPWAP packets from the controller to the access point and as the destination for CAPWAP packets from the access point to the controller. The AP-manager interface communicates through any distribution system port by listening across the Layer 3 network for access point CAPWAP or LWAPP join messages to associate and communicate with as many lightweight access points as possible.

For Cisco 4404 and WiSM Controllers, configure the AP-manager interface on all distribution system ports (1, 2, 3, and 4). For Cisco 4402 Controllers, configure the AP-manager interface on distribution system ports 1 and 2. In both cases, the static (or permanent) AP-manager interface is always assigned to distribution system port 1 and given a unique IP address. Configuring the AP-manager interface on the same VLAN or IP subnet as the management interface results in optimum access point association.

Virtual Interface -

The virtual interface is used to support mobility management, Dynamic Host Configuration Protocol (DHCP) relay, and embedded Layer 3 security such as guest web authentication and VPN termination. It also maintains the DNS gateway host name used by Layer 3 security and mobility managers to verify the source of certificates when Layer 3 web authorization is enabled.

Specifically, the virtual interface plays these two primary roles:
•Acts as the DHCP server placeholder for wireless clients that obtain their IP address from a DHCP server.
•Serves as the redirect address for the web authentication login page.

Note: All controllers within a mobility group must be configured with the same virtual interface IP address. Otherwise, inter-controller roaming may appear to work, but the handoff does not complete, and the client loses connectivity for a period of time.

The virtual interface IP address is used only in communications between the controller and wireless clients. It never appears as the source or destination address of a packet that goes out a distribution system port and onto the switched network. For the system to operate correctly, the virtual interface IP address must be set (it cannot be 0.0.0.0), and no other device on the network can have the same address as the virtual interface. Therefore, the virtual interface must be configured with an unassigned and unused gateway IP address. The virtual interface IP address is not pingable and should not exist in any routing table in your network. In addition, the virtual interface cannot be mapped to a backup port.

Service-Port Interface -

The service-port interface controls communications through and is statically mapped by the system to the service port. The service port can obtain an IP address using DHCP, or it can be assigned a static IP address, but a default gateway cannot be assigned to the service-port interface. Static routes can be defined through the controller for remote network access to the service port.

Dynamic Interface -

Dynamic interfaces, also known as VLAN interfaces, are created by users and designed to be analogous to VLANs for wireless LAN clients. A controller can support up to 512 dynamic interfaces (VLANs). Each dynamic interface is individually configured and allows separate communication streams to exist on any or all of a controller's distribution system ports. Each dynamic interface controls VLANs and other communications between controllers and all other network devices, and each acts as a DHCP relay for wireless clients associated to WLANs mapped to the interface. You can assign dynamic interfaces to distribution system ports, WLANs, the Layer 2 management interface, and the Layer 3 AP-manager interface, and you can map the dynamic interface to a backup port.

You can configure zero, one, or multiple dynamic interfaces on a distribution system port. However, all dynamic interfaces must be on a different VLAN or IP subnet from all other interfaces configured on the port. If the port is untagged, all dynamic interfaces must be on a different IP subnet from any other interface configured on the port.

Dynamic AP Management -

A dynamic interface is created as a WLAN interface by default. However, any dynamic interface can be configured as an AP-manager interface, with one AP-manager interface allowed per physical port. A dynamic interface with the Dynamic AP Management option enabled is used as the tunnel source for packets from the controller to the access point and as the destination for CAPWAP packets from the access point to the controller. The dynamic interfaces for AP management must have a unique IP address and are usually configured on the same subnet as the management interface.

You may want to verify that the router actually recognizes the module first, just in case.

Home_3825#sh inventory

NAME: "Integrated Service Engine for Modular and Integrated Services Routers on Slot 2", DESCR: "Integrated Service Engine for Modular and Integrated Services Routers"
PID: NME-AIR-WLC8-K9 , VID: V02 , SN: XXXXXXXX

Home_3825#show ip interface brief
In2/0 10.1.22.1 YES manual up up

This is what the module interface will look like (In1/0 | In2/0)

The module in the router that I am using is configured already, well as far along as this blog will take us. (Your's probably wont have an IP address and it will be shut down)

We need to log into the WLCM to start the initial configuration.

First, we need to give the module an IP address and no shut the interface before we can begin our "session" with the module. If we try and session in with the two commands just mentioned, you will get the error below.

Home_3825#service-module integrated-Service-Engine 2/0 session
IP address needs to be configured on interface Integrated-Service-Engine2/0

The IP address that you give this interface will be the default-gateway IP for the additional interfaces we will be adding later so choose wisely.

Home_3825(config)#inter integrated-Service-Engine 2/0

Home_3825(config-if)#ip add 10.1.22.1 255.255.255.0

Home_3825(config-if)#no shut

Try to think of this interface just like you would any other layer 3 interface. (e.g. GigabitEthernet0/0)

Lets open a session into the module!

Home_3825#service-module integrated-Service-Engine 2/0 session
Trying 10.1.22.1, 2130 ... Open

Username: Cisco
Password: cisco

Once you are in a session, to get back out. ( control + shift + 6 ) X) If you want to permanantely back out, once your at the router interface type: #disconnect < --- enter

We are now asked for credentials to log into the WLCM to begin working on its initial configuration. I wanted to make sure the module was reverted back to factory-default.

User:Cisco
Password:cisco

(Cisco Controller) >clear config
Are you sure you want to clear the configuration? (y/n) y

Configuration Cleared!
(Cisco Controller) >reset
(Cisco Controller) reset>system

The system has unsaved changes.
Would you like to save them now? (y/N) N

Configuration Not Saved!
Are you sure you would like to reset the system? (y/N) y

System will now restart!
------------------------------------------
Just like anything Cisco, exit out of the configuration wizard to begin. It will present you with a different "wizard", this one is the one you want plus you can't cancel out of this one.

*** autoinstall must be terminated in order to run the configuration wizard.

Would you like to terminate autoinstall? [yes]:

System Name [Cisco_cc:cb:60] (31 characters max): Your_clever_WLCM_name

Enter Administrative User Name (24 characters max): jdoe

Enter Administrative Password (24 characters max): password

Re-enter Administrative Password : password

Management Interface IP Address: 10.1.22.18

Management Interface Netmask: 255.255.255.0

Management Interface Default Router: 10.1.22.1

Management Interface VLAN Identifier (0 = untagged): 0

Management Interface Port Num [1]: 1

Management Interface DHCP Server IP Address: 10.1.22.18

AP Manager Interface IP Address: 10.1.22.19

AP-Manager is on Management subnet, using same
values AP Manager Interface DHCP Server (10.1.22.18): 10.1.22.18

Virtual Gateway IP Address: 22.22.22.22

Mobility/RF Group Name: wlan-22-mg

Network Name (SSID): wlan-22

Configure DHCP Bridging Mode [yes][NO]: n

Configure DHCP Bridging Mode [yes][NO]: NO

Allow Static IP Addresses [YES][no]: no

Configure a RADIUS Server now? [YES][no]: no

Warning! The default WLAN security policy requires a RADIUS server.
Please see documentation for more details.

Enter Country Code list (enter 'help' for a list of countries) [US]:

Enable 802.11b Network [YES][no]: yes

Enable 802.11a Network [YES][no]: yes

Enable 802.11g Network [YES][no]: yes

Enable Auto-RF [YES][no]:

Configure a NTP server now? [YES][no]: yes

Enter the NTP server's IP address: 10.1.2.1

Enter a polling interval between 3600 and 604800 secs: 604800

Configuration correct? If yes, system will save it and reset. [yes][NO]: yes

Configuration saved!
Resetting system with new configuration...

When the module come's back up after the reboot, you should see something similar to this:

(Cisco Controller) config>

And now, you should be able to type the management IP into a web browser, hit enter and see something similar to this:

More to come...

Cisco ROMMON Privilege Mode - Fixing a broken cookie.

2012-03-14T17:12:00.000-05:00

This blog will be about ROMMON Mode on a Cisco ISR and some of the issue's that I had when I started up one of my 2800's at home. It seems that the cookie was corrupt and the router would not boot because it thought I had the incorrect image on the flash which was not the case.

So after doing a lot of searching I found out that I needed to fix the cookie and enter privilege mode of ROMMON to do this. I have been working with Cisco hardware for quite sometime and had never once heard of this little known TAC feature.

Ok, now onto the good stuff.

DISCLAIMER: USE AT YOUR OWN RISK | USE AT YOUR OWN RISK | USE AT YOUR OWN RISK

Here is the error that I was getting when I was trying to boot up my router.

"Readonly ROMMON initialized
loadprog: error - Invalid image for platform"

Now to enter the privledge mode of ROMMON. You will need to find the password to get
in and to get this password, you will need to display the cookie in ROMMON and find
a site that can decipher it for you.

This is the website that I found and kudos to this person!!

http://ers.pp.ru/cgi-bin/priv.cgi

Here is a partial piece of the cookie that was on my router:

rommon 2 > cookie

cookie:
04 ff 09 86 ff ff ff ff ff ff ff ff ff ff ff ff
4f 43 31 31 31 37 33 38 46 50 40 04 0c 41 07 00
82 49 1f fe 07 42 41 30 c0 46 03 20 00 5b 8b 05
88 00 00 00 00 02 04 c6 8a 49 50 4d 37 56 30 30

Now once that you have this on your screen, go to the website mentioned above and
paste the entire first line into the box. It will be a 4 digit password that it
spits out.

Now that you have your password, type in: priv and hit enter, input your password
and the outpur will be something like this.

rommon 7 > priv
Password:
You now have access to the full set of monitor commands.
Warning: some commands will allow you to destroy your
configuration and/or system images and could render
the machine unbootable.

Now that you are here, you will need to fix your cookie and will be a topic for
another blog post but what I did was boot up another router into ROMMON and grabbed
the cookie off of that one. (Thats probably not the best idea as it seems that the
MAC address' for the interfaces are derived from this Hexa-Decimal cookie.)

rommon 8 > ?
addrloop walk 1 thru range of addresses
alias set and display aliases command
alter alter locations in memory
berrscan scan range of addresses for bus errors
boot boot up an external process
break set/show/clear the breakpoint
call call a subroutine at address with converted hex args
cat concatenate files
checksum checksum a block of memory
clrerr clear the error log
compare compare two blocks of memory
confreg configuration register utility
cont continue executing a downloaded image
context display the context of a loaded image
cookie display contents of motherboard cookie PROM in hex
cpu cpu / system information and control
cycles excercise the hardware with all possible cycles
dev list the device table
dir list files in file system
dis disassemble instruction stream
dnld serial download a program module
dram verify DRAM
dump display a block of memory
echo monitor echo command
errlog display the error log
fdump file dump utility
fill fill a block of memory
flash flash services command
frame print out a selected stack frame
giodn gio ucode download
giopref select which gio to boot next
gioshow show the gio version
gt96100 print out GT96100 registers
gt96100fe print out GT96100 FE registers
help monitor builtin command help
history monitor command history
ifill fill a block of memory w/incrementing pattern
iomemset set IO memory percent
initfs re-initialize the file system access structures
jump call a subroutine at address with argc/argv
launch launch a downloaded image
leds check out the error LED
memdebug write/read/verify scope loop
meminfo main memory information
memloop write or read scope loop
memtest simple memory test
menu main diagnostic menu
move move a block of memory
repeat repeat a monitor command
reset system reset
rommon-pref Select ROMMON
set display the monitor variables
showmon display currently selected ROM monitor
sleep millisecond sleep command
speed timed performance loop
stack produce a stack trace
sync write monitor environment to NVRAM
sysret print out info from last system return
tcal timer calibration test
tftpdnld tftp image download
tlbdump display the cpu TLB
tlbflush flush the TLB
tlbmap initialize a TLB mapping
tlbpid set/display process ID number
tlbphy search TLB for physical translation
tlbtest test the TLB
tlbscan scan for TLB exceptions
tlbvir search TLB for a virtual translation
tscope timer scope loop
unalias unset an alias
unset unset a monitor variable
watchdog test watchdog rebooting of the box
xmodem x/ymodem image download

Now we need to enter cookie mode so type: cookie

This is what you will see:

View/alter bytes of serial cookie by field --
Input hex byte(s) or: CR -> skip field; ? -> list values

Now if you have a good cookie (In Hexa-Decimal), you will need to paste each line in one at a time.

bytes 0x08-0x0F: ff ff ff ff ff ff ff ff
>
bytes 0x10-0x17: 4f 43 31 31 31 37 33 38
>
bytes 0x18-0x1F: 46 50 40 04 0c 41 07 00
>
bytes 0x20-0x27: 82 49 1f fe 07 42 41 30

<output omitted>

######################

Here are a few more show commands:

rommon 13 > menu

Main Diagnostic Menu
a: alter diag flags
b: basic utilities
c: do all diags in this menu
d: do group of diags in this menu
e: monitor image checksum test
f: internal interrupt test
g: bev state test
h: timer interrupt test
i: size main memory
j: main memory test
k: aux loopback test
l: aux port interrupt test
m: cookie test
n: primary data cache test
o: secondary data cache test
p: tlb test
q: mother board reg test
r: gt96xx dma test
x: return to previous menu
FLAGS: Continuous OFF Stop on error OFF Loop on error OFF Quiet mode OFF

enter Main Diagnostic Menu item > m

*** Warning: if power is lost or user sends break ***
the system will not recover until cookie content is restored.

main board cookie test cookie out of scope, cookie number 0.
phase 1: cookie test with 0x5a5a pattern, main board cookie test
*** TLB (Load/Fetch) Exception ***
Access address = 0x10
PC = 0xbfc1efe8, Cause = 0x8, Status Reg = 0x3041e803

enter Main Diagnostic Menu item > b

Diagnostic Utilities Menu
a: alter memory
b: compare memory block
c: display memory
d: move memory block
e: fill memory
f: memory test
g: memory read or write loop
h: memory debug loop
i: address loop
j: system reset
k: system cold
l: console break interrupt test
m: AUX port echo test
n: show mother board regs
o: poll slots
p: mother board cookie utility
q: show GT96K registers
r: show NM PCI regs
s: PCI config write
t: PCI config read
u: show CF info
x: return to previous menu

Now if you have done everything correct, type the (3) commands below and it should boot up just fine.

rommon 8 > initfs
rommon 9 > sync
rommon 10 > reset

System Bootstrap, Version 12.4(13r)T, RELEASE SOFTWARE (fc1)
Technical Support: http://www.cisco.com/techsupport
Copyright (c) 2006 by cisco Systems, Inc.
PLD version 0x10
GIO ASIC version 0x127
c2801 platform with 262144 Kbytes of main memory
Main memory is configured to 64 bit mode with parity disabled

Readonly ROMMON initialized
program load complete, entry point: 0x8000f000, size: 0xcb80
program load complete, entry point: 0x8000f000, size: 0xcb80

program load complete, entry point: 0x8000f000, size: 0x2fb6af8
Self decompressing the image :
####################################################################################
####################################################################################
####################################################################################
############# [OK]

Smart Init is enabled
smart init is sizing iomem
ID MEMORY_REQ TYPE
0X003AA110 public buffer pools
0X00211000 public particle pools
0X00020000 Crypto module pools
0X00120000 VPM buffer pools
0X0012 0X00035000 Card in slot 1
0X000021B8 Onboard USB

If any of the above Memory Requirements are
"UNKNOWN", you may be using an unsupported
configuration or there is a software problem and
system operation may be compromised.

Allocating additional 12389767 bytes to IO Memory.
PMem allocated: 245366784 bytes; IOMem allocated: 23068672 bytes

Cisco IOS Software, 2801 Software (C2801-ADVENTERPRISEK9-M), Version 12.4(22)YB6,
RELEASE SOFTWARE (fc2)
Technical Support: http://www.cisco.com/techsupport
Copyright (c) 1986-2010 by Cisco Systems, Inc.
Compiled Wed 02-Jun-10 22:33 by prod_rel_team

This product contains cryptographic features and is subject to United
States and local country laws governing import, export, transfer and
use. Delivery of Cisco cryptographic products does not imply
third-party authority to import, export, distribute or use encryption.
Importers, exporters, distributors and users are responsible for
compliance with U.S. and local country laws. By using this product you
agree to comply with applicable laws and regulations. If you are unable
to comply with U.S. and local laws, return this product immediately.

A summary of U.S. laws governing Cisco cryptographic products may be found at:
http://www.cisco.com/wwl/export/crypto/tool/stqrg.html

If you require further assistance please contact us by sending email to
export@cisco.com.

Installed image archive
Cisco 2801 (revision 6.0) with 239616K/22528K bytes of memory.
Processor board ID FTX1023Y0S3
2 FastEthernet interfaces
2 Serial(sync/async) interfaces
1 Virtual Private Network (VPN) Module
DRAM configuration is 64 bits wide with parity disabled.
191K bytes of NVRAM.
63984K bytes of USB Flash usbflash0 (Read/Write)
125440K bytes of ATA CompactFlash (Read/Write)

BGP Memory Usage on a Cisco ISR

2012-01-27T16:22:00.000-06:00

Is you ever wanted to know how much memory a BGP route uses on a Cisco ISR Router, take a look at the example below.
__________________

From Cisco:

The memory consumption by BGP routes depends on the number of attributes, such as multipath support, soft reconfiguration, the number of peers, and AS_PATH etc.

When the BGP router receives its neighbors' full BGP routing table (98,410 routes), the router consumes approximately 71 MB. With the AS_PATH filters applied to inbound updates, the size of the BGP routing table is reduced to 31,667 routes, and the memory consumption is approximately 28 MB. This decrease in memory utilization is more than 60 percent with optimal routing.

__________________

Below are (2) BGP peers with 2 static routes and no other attributes applied. You can see the first output with (1) static route and then a second static route was added.

r2#sh ip bgp summ

BGP router identifier 2.2.2.2, local AS number 2 BGP table version is 3, main routing table version 3

1 network entries using 120 bytes of memory

1 path entries using 52 bytes of memory

2/1 BGP path/bestpath attribute entries using 248 bytes of memory

1 BGP AS-PATH entries using 24 bytes of memory 0 BGP route-map cache entries using 0 bytes of memory 0 BGP filter-list cache entries using 0 bytes of memory BGP using 444 total bytes of memory BGP activity 1/0 prefixes, 1/0 paths, scan interval 60 secs

Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd

10.1.1.1 4 1 4 3 3 0 0 00:00:31 1

r2#sh ip bgp

*Mar 1 00:06:57.475: %SYS-5-CONFIG_I: Configured from console by consolep summ BGP router identifier 2.2.2.2, local AS number 2 BGP table version is 8, main routing table version 8

2 network entries using 240 bytes of memory

2 path entries using 104 bytes of memory

3/3 BGP path/bestpath attribute entries using 372 bytes of memory

1 BGP AS-PATH entries using 24 bytes of memory 0 BGP route-map cache entries using 0 bytes of memory 0 BGP filter-list cache entries using 0 bytes of memory Bitfield cache entries: current 1 (at peak 1) using 32 bytes of memory BGP using 772 total bytes of memory BGP activity 3/0 prefixes, 3/1 paths, scan interval 60 secs

Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd

10.1.1.1 4 1 9 7 6 0 0 00:03:23 1

1.0.0.0/32 is subnetted, 1 subnets

S 1.1.1.1 [1/0] via 10.1.1.1

3.0.0.0/32 is subnetted, 1 subnets

C 3.3.3.3 is directly connected, Loopback0

4.0.0.0/32 is subnetted, 1 subnets

S 4.4.4.4 [1/0] via 10.1.1.1

10.0.0.0/24 is subnetted, 1 subnets

C 10.1.1.0 is directly connected, Serial0/0

Cisco Bootstrap / ROMMON Upgrade

2011-11-30T19:11:00.000-06:00

Here we are going to upgrade the Bootstrap on a Cisco 1841 ISR but would be the same on Cisco 2800 / 3800 series.

There really isn't a lot to it but since you will probably only do it a handful of times during your career I thought it was a worthy post.

First things that you need to do is download the latest image from Cisco and will look something like this.

C1841_RM2.srec.124-13r.T5

You can check to see what revision your router is running by entering this command:

#show version

Look for this line in the output, it will vary depending on your device and image.

ROM: System Bootstrap, Version 12.3(8r)T8, RELEASE SOFTWARE (fc1)

We are going to upgrade the current image to (124-13r)

Once you have the file, you need to get it onto your routers flash card or put it on a USB drive.

All you have to do is type this command and thats it.

Router#upgrade rom-monitor file flash:C1841_RM2.srec.124-13r.T5

This command will result in a 'power-on reset' of the router!
Continue? [yes/no]: y
ROMMON image upgrade in progress.
Erasing boot flash eeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee
Programming boot flash ppppppppppp

Now Reloading
System Bootstrap, Version 12.3(8r)T8, RELEASE SOFTWARE (fc1)
Technical Support: http://www.cisco.com/techsupport
Copyright (c) 2004 by cisco Systems, Inc.

And here we are:

System Bootstrap, Version 12.4(13r)T5, RELEASE SOFTWARE (fc1)
Technical Support: http://www.cisco.com/techsupport
Copyright (c) 2007 by cisco Systems, Inc.

Thats it for today!

ASA - ASDM

2011-11-13T13:03:00.002-06:00

When you open the ASDM on your ASA and your tired of accepting the "untrusted" certificate multiple times. All you need to do is create a self-signed certificate and this will go away. I am showing (2) ways to do it, the first is through the ASDM and the second via the CLI.

NOTE: When you create the certificate, keep in mind that all you have done is create it. When you launch the ASDM again you will still need to accept the certificates but this time they will be stored on your computer and from this point on you should no longer have to.

All you need to do is navigate to Device Management => Certificate Management => Identity Certificates.
Just press "Add" and you will see something similiar to the screen shot I have attached.

The trustpoint name & Certificate Subject will self populate but it can be anything you choose and thats it.

If you are looking to accomplish the same thing with the CLI, here is the command structure. You can also go through it with ASDM and preview the commands before there sent | Tools => Preferences => Communications.

#crypto ca trustpoint ASDM_ASA_Self_Signed

#id-usage ssl-ipsec

#no fqdn

#subject-name CN=ASA1

#enrollment self

#crypto ca enroll ASDM_ASA_Self_Signed noconfirm

Cisco ASA Factory Default Configuration

2011-11-12T15:26:00.000-06:00

This post contains a few options related to a factory default configuration on a Cisco ASA 5505. The first part shows how to reset the ASA to factory default configuration from the CLI and the commands that are automatically executed once you press enter. The second part is just a clean, fresh from the factory configuration.

asa2(config)# configure factory-default

Based on the inside IP address and mask, the DHCP address
pool size is reduced to 250 from the platform limit 256

WARNING: The boot system configuration will be cleared.
The first image found in disk0:/ will be used to boot the
system on the next reload.
Verify there is a valid image on disk0:/ or the system will
not boot.

Begin to apply factory-default configuration:
Clear all configuration
Executing command: interface Ethernet 0/0
Executing command: switchport access vlan 2
Executing command: no shutdown
Executing command: exit
Executing command: interface Ethernet 0/1
Executing command: switchport access vlan 1
Executing command: no shutdown
Executing command: exit
Executing command: interface Ethernet 0/2
Executing command: switchport access vlan 1
Executing command: no shutdown
Executing command: exit
Executing command: interface Ethernet 0/3
Executing command: switchport access vlan 1
Executing command: no shutdown
Executing command: exit
Executing command: interface Ethernet 0/4
Executing command: switchport access vlan 1
Executing command: no shutdown
Executing command: exit
Executing command: interface Ethernet 0/5
Executing command: switchport access vlan 1
Executing command: no shutdown
Executing command: exit
Executing command: interface Ethernet 0/6
Executing command: switchport access vlan 1
Executing command: no shutdown
Executing command: exit
Executing command: interface Ethernet 0/7
Executing command: switchport access vlan 1
Executing command: no shutdown
Executing command: exit
Executing command: interface vlan2
Executing command: nameif outside
INFO: Security level for "outside" set to 0 by default.
Executing command: no shutdown
Executing command: ip address dhcp setroute
Executing command: exit
Executing command: interface vlan1
Executing command: nameif inside
INFO: Security level for "inside" set to 100 by default.
Executing command: ip address 192.168.1.1 255.255.255.0
Executing command: security-level 100
Executing command: allow-ssc-mgmt
ERROR: SSC card is not available
Executing command: no shutdown
Executing command: exit
Executing command: object network obj_any
Executing command: subnet 0.0.0.0 0.0.0.0
Executing command: nat (inside,outside) dynamic interface
Executing command: exit
Executing command: http server enable
Executing command: http 192.168.1.0 255.255.255.0 inside
Executing command: dhcpd address 192.168.1.5-192.168.1.254 inside
Executing command: dhcpd auto_config outside
Executing command: dhcpd enable inside
Executing command: logging asdm informational
Factory-default configuration is completed
ciscoasa(config)#

_______________________

ciscoasa# sh run
: Saved
:
ASA Version 8.4(1)
!
hostname ciscoasa
enable password mrc2YGsms0Df41/U encrypted
passwd 2KFQnbNIdI.2KYOU encrypted
names
!
interface Vlan1
nameif inside
security-level 100
ip address 192.168.1.1 255.255.255.0
!
interface Vlan2
nameif outside
security-level 0
ip address dhcp setroute
!
interface Ethernet0/0
switchport access vlan 2
!
interface Ethernet0/1
!
interface Ethernet0/2
!
interface Ethernet0/3
!
interface Ethernet0/4
!
interface Ethernet0/5
!
interface Ethernet0/6
!
interface Ethernet0/7
!
ftp mode passive
object network obj_any
subnet 0.0.0.0 0.0.0.0
pager lines 24
logging asdm informational
mtu outside 1500
mtu inside 1500
icmp unreachable rate-limit 1 burst-size 1
no asdm history enable
arp timeout 14400
!
object network obj_any
nat (inside,outside) dynamic interface
timeout xlate 3:00:00
timeout conn 1:00:00 half-closed 0:10:00 udp 0:02:00 icmp 0:00:02
timeout sunrpc 0:10:00 h323 0:05:00 h225 1:00:00 mgcp 0:05:00 mgcp-pat 0:05:00
timeout sip 0:30:00 sip_media 0:02:00 sip-invite 0:03:00 sip-disconnect 0:02:00
timeout sip-provisional-media 0:02:00 uauth 0:05:00 absolute
timeout tcp-proxy-reassembly 0:01:00
dynamic-access-policy-record DfltAccessPolicy
http server enable
http 192.168.1.0 255.255.255.0 inside
no snmp-server location
no snmp-server contact
snmp-server enable traps snmp authentication linkup linkdown coldstart warmstart
telnet timeout 5
ssh timeout 5
console timeout 0

dhcpd auto_config outside
!
dhcpd address 192.168.1.5-192.168.1.254 inside
dhcpd enable inside
!
threat-detection basic-threat
threat-detection statistics access-list
no threat-detection statistics tcp-intercept
webvpn
!
class-map inspection_default
match default-inspection-traffic
!
!
policy-map type inspect dns preset_dns_map
parameters
message-length maximum client auto
message-length maximum 512
policy-map global_policy
class inspection_default
inspect dns preset_dns_map
inspect ftp
inspect h323 h225
inspect h323 ras
inspect rsh
inspect rtsp
inspect esmtp
inspect sqlnet
inspect skinny
inspect sunrpc
inspect xdmcp
inspect sip
inspect netbios
inspect tftp
inspect ip-options
!
service-policy global_policy global
prompt hostname context
Cryptochecksum:5ee3fb383a35c98a6d5891329d759d6c
: end
ciscoasa#

TCL Notes - Part 2

2011-10-18T21:06:00.000-05:00

This is an example of a simple script as well as how to run them from either the TCL shell or global exec mode. I will have an example of how to fire off a TCL script using EEM at a later date.

Let's get started -

The command below get's passed off to IOS because the TCL interpreter doesn't understand what to do with it, thus the output looks like it was from global exec. It does populate the variable "mybuffer" with the output seen.

2811_Home(tcl)#set mybuffer [exec "show ip interface brief"]
Load for five secs: 2%/0%; one minute: 2%; five minutes: 3%
Time source is NTP, 20:10:08.650 CST Tue Oct 18 2011

Interface IP-Address OK? Method Status Protocol
FastEthernet0/0 192.168.1.1 YES NVRAM up up
FastEthernet0/1 10.1.2.1 YES NVRAM up up
FastEthernet0/1.3 10.1.3.1 YES NVRAM up up
Dot11Radio0/0/0 unassigned YES NVRAM up up
NVI0 192.168.1.1 YES unset up up

What this script is doing is looking for the first instance of "10.1.2." in the variable "mybuffer" which was populated by "show ip interface brief" command. If found, it will return the line "We found my inside subnet 10.1.2.0 / 24!" and if not it will return a (-1).

Here is the complete script, written in a simple text editor and saved as a ".tcl" file.

set mybuffer [exec "show ip interface brief"]
set foundposition [string first "10.1.2." $mybuffer]
if {$foundposition > -1} {
puts "We found my inside subnet 10.1.2.0 / 24!"
}

I copied the file to my router...

2811_Home#copy usbflash0: flash
Source filename []? my-tcl.tcl
Destination filename [my-tcl.tcl]?
Copy in progress...C
181 bytes copied in 0.416 secs (435 bytes/sec)

2811_Home#sh flash
Load for five secs: 11%/0%; one minute: 4%; five minutes: 3%
Time source is NTP, 20:19:55.263 CST Tue Oct 18 2011
-#- --length-- -----date/time------ path
1 59171892 Oct 14 2011 06:08:04 c2800nm-adventerprisek9_ivs-mz.124-22.T5.bin
33 5561 Aug 27 2011 20:10:16 2811_internet_ips-CONFIG
35 12757876 Sep 07 2011 02:55:20 IOS-S556-CLI.pkg
42 180 Oct 20 2011 01:31:54 my-tcl.tcl

Here are (2) ways in which to execute to script.

2811_Home#tclsh
2811_Home(tcl)#source flash:my-tcl.tcl
We found my inside subnet 10.1.2.0 / 24!

2811_Home#tclsh flash:my-tcl.tcl
We found my inside subnet 10.1.2.0 / 24!

Thats it for now...

TCL Notes

2011-10-16T15:13:00.001-05:00

I have been spending a little time working with TCL, a scripting language which is open source but is also available in the majority of Cisco's IOS. If you would like more information, check out Cisco Press - TCL Scripting for Cisco IOS.

TCL Scripting (Some of the Basics)

R1(tcl)#

set a "This is"

set b " a test!"

Router(tcl)#append a $b

This is a test!

______________

r1(tcl)#set x 1
1
r1(tcl)#incr x
2

r1(tcl)#set y 2
2
r1(tcl)#incr y
3
r1(tcl)#incr y 2
5
______________

r1(tcl)#set m 2
2
r1(tcl)#expr $m+2
4
r1(tcl)#puts $m
2
______________

" " Double quotes allow substitutions

{ } Braces need to be open / closed and DONT allow substitutions.

[ ] This is for command substitution and invokes the TCL interpreter to process the characters between the open and closed brackets.

This allows for an array variable
$variable

$variable (index)

r1(tcl)#set x(2) 200
200
r1(tcl)#set y(3) 300
300
r1(tcl)#puts $x(2)
200

r1(tcl)#set n(m) 1000
1000
r1(tcl)#puts $n(m)
1000

r1(tcl)#set {I am awesome!} Adrian
Adrian

r1(tcl)#set c cool
cool
r1(tcl)#set d "I am $c"
I am cool
r1(tcl)#puts {You are $c}
You are $c
______________

Append is similar to lappend but the variable's are contained in quotes.

r1(tcl)#set a "This is "
This is
r1(tcl)#set b "my script"
my script
r1(tcl)#append a $b
This is my script
r1(tcl)#puts $a
This is my script
______________

List Append (lappend) add's a variable to a string / list separated by white space.

r1(tcl)#lappend oscar This is
This is
r1(tcl)#lappend oscar my script
This is my script
r1(tcl)#puts $oscar
This is my script
______________

List Index (lindex) will extract elements from a list but will not modify the list.

As you can see we have extracted data from this list. Keep in mind that the list is read from left to right and start's at the number zero.

r1(tcl)#puts $a
This is my script

r1(tcl)#lindex $a 2
my
r1(tcl)#
r1(tcl)#lindex $a 0
This

r1(tcl)#puts $a
This is my script
______________

List Insert (linsert) will add new elements to a list.

r1(tcl)#set a [linsert $a 3 awesome ]
This is my awesome script
r1(tcl)#

r1(tcl)#puts $adrian
This is my awesome list

r1(tcl)#llength $adrian
5
______________

r1(tcl)#lsearch $adrian y
-1
r1(tcl)#lsearch $adrian my
2

r1(tcl)#lsearch -regexp $adrian y
2

r1(tcl)#lsearch -regexp $adrian i
0

r1(tcl)#lsearch -global $adrian i
bad search mode "-global": must be -exact, -glob, or -regexp
r1(tcl)#lsearch -glob $adrian i
-1

r1(tcl)#puts $adrian
This is my list

r1(tcl)#lsearch -regexp $adrian "is"
0
r1(tcl)#
______________

r1(tcl)#set a "This is my script"
This is my script
r1(tcl)#puts $a
This is my script
______________

r1(tcl)#set a [lreplace $a 3 3 really awesome script]
This is my really awesome script
r1(tcl)#puts $a
This is my really awesome script

r1(tcl)#set b "My dogs name is oscar"
My dogs name is oscar
r1(tcl)#set b [lreplace $b 0 4 I also have a dog named shelby!]
I also have a dog named shelby!
r1(tcl)#
______________

r1(tcl)#puts $c
Pulling info from a file

r1(tcl)#set d [lrange $c 2 4]
from a file
r1(tcl)#puts $d
from a file
______________

List Sort puts a string of variables in alphabetical order.

r1(tcl)#puts $d
from a file

r1(tcl)#set d [lsort $d]
a file from

r1(tcl)#lsort -ascii -decreasing $d
from file a
r1(tcl)#lsort -ascii -increasing $d
a file from
r1(tcl)#
______________

r1(tcl)#proc my_script {} {
+>(tcl)#puts "This is my script"
+>(tcl)#}

r1(tcl)#set z {}

r1(tcl)#puts $z

r1(tcl)#for {set z 0} {$z<10} {incr z} {
+>(tcl)#my_script
+>(tcl)#}
This is my script
This is my script
This is my script
This is my script
This is my script
This is my script
This is my script
This is my script
This is my script
This is my script
______________

r1(tcl)#for {set m 0} {$m<5} {incr m} {puts " $m. This is a script"}
0. This is a script
1. This is a script
2. This is a script
3. This is a script
4. This is a script

r1(tcl)#set cpuinfo {r1 50 90 r2 10 20}
r1 50 90 r2 10 20

r1(tcl)#$info { set CPUavg [expr ($CPU1+$CPU2)/2] ; puts "$router $CPUavg" }
r1 70
r2 15
______________

r1(tcl)#set y 0 ; while {$y < 5} { set T [expr ($y*2)] ; puts "$y. Twice $y is $T" ; incr y }
0. Twice 0 is 0
1. Twice 1 is 2
2. Twice 2 is 4
3. Twice 3 is 6
4. Twice 4 is 8

More to come...

Cisco ASA 8.4 IOS - Remote Access VPN

2011-07-13T18:56:00.002-05:00

Below is the minimal configuration needed to implement remote access VPN's on a Cisco ASA 5505 running 8.4. Please keep in mind that the names that I used in my configuration is of my dog but it's best practice to use a name that describes what / who its for.

Enable ISAKMP on the interface:

ASA-2(config)# crypto ikev1 enable outside

ASA-2(config)# crypto ikev1 policy 1

ASA-2(config-ikev1-policy)# encryption 3des

ASA-2(config-ikev1-policy)# authentication pre-share

ASA-2(config-ikev1-policy)# hash md5

Setup your Group Policies & Tunnel Policies

ASA-2(config)# group-policy oscar_GP internal

ASA-2(config)# group-policy oscar_GP attributes

ASA-2(config-group-policy)# vpn-tunnel-protocol ikev1

ASA-2(config-group-policy)# address-pools value oscar_pool

*******************

ASA-2(config)# tunnel-group oscar_tg type remote-access

ASA-2(config)# tunnel-group oscar_tg general-attributes

ASA-2(config-tunnel-general)# default-group-policy oscar_GP

ASA-2(config-tunnel-general)# authentication-server-group LOCAL

ASA-2(config)# tunnel-group oscar_tg ipsec-attributes

ASA-2(config-tunnel-ipsec)# ikev1 pre-shared-key C1sc0

*******************

ASA-2(config)# crypto ipsec ikev1 transform-set oscar_trans esp-3des esp-md5-hmac

ASA-2(config)# ip local pool oscar_pool 10.1.2.140-10.1.2.145 mask 255.255.255.0

ASA-2(config)# crypto dynamic-map SYSTEM_DEFAULT_CRYPTO_MAP 65535 set ikev1 transform-set oscar_trans

ASA-2(config)#username oscar password omEMDQBc9noujG1X encrypted privilege 15

ASA-2(config)# crypto map outside_map 65535 ipsec-isakmp dynamic SYSTEM_DEFAULT_CRYPTO_MAP

ASA-2(config)# crypto map outside_map interface outside

Cisco IOS IPS (Intrusion Prevention System) - 2801 ISR

2011-07-03T22:27:00.004-05:00

Below is the basic configuration needed to get the IPS feature up and running on an IOS router.

First thing that we need to do is create a directory on your flash to store all of your files, you can name it whatever you like but something to describe what's in there is usually best practice.

r1#mkdir flash:/oscar_ips
Create directory filename [oscar_ips]?
Created dir flash:/oscar_ips

We need to name the IPS:

r1(config)#ip ips name oscar

We need to tell the IPS where to store it's signature files:

r1(config)#ip ips config location flash:/oscar_ips

Lets retire all of the signatures before we decide on which ones we want to turn on and unless you have a lot of memory in your router, you won't be able to turn them all on.

r1(config-ips-category)#category ?
adware/spyware Adware/Spyware (more sub-categories)
all All Categories
attack Attack (more sub-categories)
ddos DDoS (more sub-categories)
dos DoS (more sub-categories)
email Email (more sub-categories)
instant_messaging Instant Messaging (more sub-categories)
ios_ips IOS IPS (more sub-categories)
l2/l3/l4_protocol L2/L3/L4 Protocol (more sub-categories)
network_services Network Services (more sub-categories)
os OS (more sub-categories)
other_services Other Services (more sub-categories)
p2p P2P (more sub-categories)
reconnaissance Reconnaissance (more sub-categories)
releases Releases (more sub-categories)
viruses/worms/trojans Viruses/Worms/Trojans (more sub-categories)
web_server Web Server (more sub-categories)

r1(config)#ip ips signature-category
r1(config-ips-category)#category all
r1(config-ips-category-action)#retired true
r1(config-ips-category-action)#exit

Since I am using a 2801 with 256MB of RAM, lets just turn on the basics. (Note: I have tried turning them all on and this is what happens:

--------------------------------------------------------------------
Possible software fault. Upon reccurence, please collect
crashinfo, "show tech" and contact Cisco Technical Support.
--------------------------------------------------------------------
-Traceback= 0x630B74C8 0x63624B48 0x63604504 0x6363D7B0 0x6349B5F4 0x6349BC3C 0x63496C10 0x6363B2E0 0x6363F2B8 0x616B7CD8 0x616B8420 0x616DDC88 0x630AF450 0x630AF434
$0 : 00000000, AT : 65E60000, v0 : 0D0D0D0D, v1 : 68636248
a0 : 00000000, a1 : 681CCEB4, a2 : 00000001, a3 : 00000009
t0 : 0000C100, t1 : 00000000, t2 : 00000000, t3 : FFFF00FF
t4 : 00000000, t5 : 0D0D0D0D, t6 : 00000002, t7 : 00000000
s0 : 681CCEB4, s1 : 65D5C044, s2 : 00000008, s3 : 00000000
s4 : 681CCC68, s5 : 680521C8, s6 : 669ACF04, s7 : 681CCC68
t8 : 00000000, t9 : 6541A234, k0 : 3041E801, k1 : 00100000
gp : 65E6DDB0, sp : 68051ED0, s8 : 6781AF04, ra : 630B73E8
EPC : 630B74C8, ErrorEPC : BFCC6038, SREG : 3401C103
MDLO : 0000004D, MDHI : 00002A9E, BadVaddr : 0D0D0D11
DATA_START : 0x63F08CB0
Cause 00000014 (Code 0x5): Address Error (store) exception

*Jul 3 18:31:04.635: %REGISTRY-3-STUB_CHK_OVERWRITE: Attempt made to overwrite a set stub function in . -Process= "Init", ipl= 3, pid= 3, -Traceback= 0x61667464 0x603774C4 0x630ECB68 0x6165BCE0 0x6165BFC0 0x630AF450 0x630AF434)

OK, that was fun!

r1(config-ips-category)#category ios_ips basic
r1(config-ips-category-action)#retired false
r1(config-ips-category-action)#exit
r1(config-ips-category)#exit

Do you want to accept these changes? [confirm]

We need to assign the IPS that we just enabled to an interface, I have chosen in / out on the same interface.

r1(config)#inter fa 0/1

r1(config-if)#ip ips oscar in

r1(config-if)#ip ips oscar out

Jul 3 18:55:57.107: %IPS-6-ENGINE_BUILDS_STARTED: 18:55:57 UTC Jul 3 2011
Jul 3 18:55:57.107: %IPS-6-ENGINE_BUILDING: atomic-ip - 3 signatures - 1 of 13 engines
Jul 3 18:55:57.119: %IPS-6-ENGINE_READY: atomic-ip - build time 12 ms - packets for this engine will be scanned
Jul 3 18:55:57.119: %IPS-6-ALL_ENGINE_BUILDS_COMPLETE: elapsed time 12 msut

Now we have to create "add" Cisco's public key to verify that the signature package is authentic. You can get the key located below from Cisco.com and this file "IOS-S359-CLI.pkg" which are the actual signatures.

r1(config)#crypto key pubkey-chain rsa

r1(config-pubkey-chain)#named-key realm-cisco.pub
Translating "realm-cisco.pub"

r1(config-pubkey-key)#key-string
Enter a public key as a hexidecimal number ....
30820122 300D0609 2A864886 F70D0101 01050003 82010F00 3082010A 02820101
00C19E93 A8AF124A D6CC7A24 5097A975 206BE3A2 06FBA13F 6F12CB5B 4E441F16
17E630D5 C02AC252 912BE27F 37FDD9C8 11FC7AF7 DCDD81D9 43CDABC3 6007D128
B199ABCB D34ED0F9 085FADC1 359C189E F30AF10A C0EFB624 7E0764BF 3E53053E
5B2146A9 D7A5EDE3 0298AF03 DED7A5B8 9479039D 20F30663 9AC64B93 C0112A35
FE3F0C87 89BCB7BB 994AE74C FA9E481D F65875D6 85EAF974 6D9CC8E3 F0B08B85
50437722 FFBE85B9 5E4189FF CC189CB9 69C46F9C A84DFBA5 7A0AF99E AD768C36
006CF498 079F88F8 A3B3FB1F 9FB7B3CB 5539E1D1 9693CCBB 551F78D2 892356AE
2F56D826 8918EF3C 80CA4F4D 87BFCA3B BFF668E9 689782A5 CF31CB6E B4B094D3
F3020301 0001

r1(config-pubkey)#quit

Now we have everything that we need in place, now we just need to copy the files to "idconf".

r1#copy flash:IOS-S359-CLI.pkg idconf

r1#
Jul 4 13:00:42.547: %IPS-6-ENGINE_BUILDS_STARTED: 13:00:42 UTC Jul 4 2011
Jul 4 13:00:42.547: %IPS-6-ENGINE_BUILDING: atomic-ip - 3 signatures - 1 of 13 engines
Jul 4 13:00:42.559: %IPS-6-ENGINE_READY: atomic-ip - build time 12 ms - packets for this engine will be scanned
Jul 4 13:00:42.559: %IPS-6-ALL_ENGINE_BUILDS_COMPLETE: elapsed time 12 ms
Jul 4 13:00:45.491: Applying Category configuration to signatures ...
Jul 4 13:01:25.047: %IPS-6-ENGINE_BUILDS_STARTED: 13:01:25 UTC Jul 4 2011
Jul 4 13:01:25.047: %IPS-6-ENGINE_BUILDING: multi-string - 11 signatures - 1 of 13 engines
Jul 4 13:01:25.067: %IPS-6-ENGINE_READY: multi-string - build time 20 ms - packets for this engine will be scanned
Jul 4 13:01:25.091: %IPS-6-ENGINE_BUILDING: service-http - 649 signatures - 2 of 13 engines
Jul 4 13:01:34.911: %IPS-6-ENGINE_READY: service-http - build time 9820 ms - packets for this engine will be scanned
Jul 4 13:01:34.947: %IPS-6-ENGINE_BUILDING: string-tcp - 1127 signatures - 3 of 13 engines
Jul 4 13:02:15.767: %IPS-6-ENGINE_READY: string-tcp - build time 40820 ms - packets for this engine will be scanned
Jul 4 13:02:15.771: %IPS-6-ENGINE_BUILDING: string-udp - 75 signatures - 4 of 13 engines
Jul 4 13:02:16.623: %IPS-6-ENGINE_READY: string-udp - build time 852 ms - packets for this engine will be scanned
Jul 4 13:02:16.627: %IPS-6-ENGINE_BUILDING: state - 31 signatures - 5 of 13 engines
Jul 4 13:02:16.711: %IPS-6-ENGINE_READY: state - build time 84 ms - packets for this engine will be scanned
Jul 4 13:02:16.775: %IPS-6-ENGINE_BUILDING: atomic-ip - 304 signatures - 6 of 13 engines
Jul 4 13:02:17.979: %IPS-6-ENGINE_READY: atomic-ip - build time 1204 ms - packets for this engine will be scanned
Jul 4 13:02:18.031: %IPS-6-ENGINE_BUILDING: string-icmp - 3 signatures - 7 of 13 engines
Jul 4 13:02:18.087: %IPS-6-ENGINE_READY: string-icmp - build time 56 ms - packets for this engine will be scanned
Jul 4 13:02:18.087: %IPS-6-ENGINE_BUILDING: service-ftp - 3 signatures - 8 of 13 engines
Jul 4 13:02:18.111: %IPS-6-ENGINE_READY: service-ftp - build time 24 ms - packets for this engine will be scanned
Jul 4 13:02:18.115: %IPS-6-ENGINE_BUILDING: service-rpc - 75 signatures - 9 of 13 engines
Jul 4 13:02:18.495: %IPS-6-ENGINE_READY: service-rpc - build time 376 ms - packets for this engine will be scanned
Jul 4 13:02:18.495: %IPS-6-ENGINE_BUILDING: service-dns - 38 signatures - 10 of 13 engines
Jul 4 13:02:18.563: %IPS-6-ENGINE_READY: service-dns - build time 68 ms - packets for this engine will be scanned
Jul 4 13:02:18.563: %IPS-6-ENGINE_BUILDING: normalizer - 9 signatures - 11 of 13 engines
Jul 4 13:02:56.947: %IPS-6-ENGINE_BUILDS_STARTED: 13:02:56 UTC Jul 4 2011
Jul 4 13:02:56.963: %IPS-6-ENGINE_BUILDING: multi-string - 11 signatures - 1 of 13 engines
Jul 4 13:02:56.975: %IPS-6-ENGINE_READY: multi-string - build time 12 ms - packets for this engine will be scanned
Jul 4 13:02:57.407: %IPS-6-ENGINE_BUILDING: service-http - 649 signatures - 2 of 13 engines
Jul 4 13:02:57.799: %IPS-6-ENGINE_READY: service-http - build time 392 ms - packets for this engine will be scanned
Jul 4 13:02:58.747: %IPS-6-ENGINE_BUILDING: string-tcp - 1127 signatures - 3 of 13 engines
Jul 4 13:02:59.359: %IPS-6-ENGINE_READY: string-tcp - build time 612 ms - packets for this engine will be scanned
Jul 4 13:02:59.911: %IPS-6-ENGINE_BUILDING: string-udp - 75 signatures - 4 of 13 engines
Jul 4 13:02:59.939: %IPS-6-ENGINE_READY: string-udp - build time 28 ms - packets for this engine will be scanned
Jul 4 13:02:59.991: %IPS-6-ENGINE_BUILDING: state - 31 signatures - 5 of 13 engines
Jul 4 13:03:00.003: %IPS-6-ENGINE_READY: state - build time 12 ms - packets for this engine will be scanned
Jul 4 13:03:00.367: %IPS-6-ENGINE_BUILDING: atomic-ip - 304 signatures - 6 of 13 engines
Jul 4 13:03:01.059: %IPS-6-ENGINE_READY: atomic-ip - build time 692 ms - packets for this engine will be scanned
Jul 4 13:03:01.319: %IPS-6-ENGINE_BUILDING: string-icmp - 3 signatures - 7 of 13 engines
Jul 4 13:03:01.375: %IPS-6-ENGINE_READY: string-icmp - build time 52 ms - packets for this engine will be scanned
Jul 4 13:03:01.379: %IPS-6-ENGINE_BUILDING: service-ftp - 3 signatures - 8 of 13 engines
Jul 4 13:03:01.383: %IPS-6-ENGINE_READY: service-ftp - build time 0 ms - packets for this engine will be scanned
Jul 4 13:03:01.435: %IPS-6-ENGINE_BUILDING: service-rpc - 75 signatures - 9 of 13 engines
Jul 4 13:03:01.467: %IPS-6-ENGINE_READY: service-rpc - build time 32 ms - packets for this engine will be scanned
Jul 4 13:03:01.535: %IPS-6-ENGINE_BUILDING: service-dns - 38 signatures - 10 of 13 engines
Jul 4 13:03:01.555: %IPS-6-ENGINE_READY: service-dns - build time 16 ms - packets for this engine will be scanned
Jul 4 13:03:01.583: %IPS-6-ENGINE_BUILDING: normalizer - 9 signatures - 11 of 13 engines
Jul 4 13:03:01.739: %IPS-6-ENGINE_READY: service-msrpc - build time 44 ms - packets for this engine will be scanned
Jul 4 13:03:01.755: %IPS-6-ALL_ENGINE_BUILDS_COMPLETE: elapsed time 4812 ms

Now you have an IPS running on your router!

More to come...

Cisco ASA NAT 8.4

2011-06-29T12:37:00.007-05:00

This is a very simple example of the new NAT structure beginning with IOS version 8.3 on a Cisco ASA appliance. There are more examples on the way...

I have (2) routers, R1 is on the "inside" and R2 is on the "outside".

We will be translating the subnet 1.1.1.0 / 24

This is the range "pool" of address's to use in the translation of subnet 1.1.1.0/24

object network TEST
range 10.1.1.5 10.1.1.10

object network TEST_Inside
subnet 1.1.1.0 255.255.255.0
nat (inside,outside) dynamic TEST

************
R2#debug ip icmp

*Jun 29 17:27:05.551: ICMP: echo reply sent, src 10.1.1.25, dst 10.1.1.5

************
ASA# sh nat translated interface outside

Auto NAT Policies (Section 2)

1 (inside) to (outside) source dynamic TEST_Inside TEST

translate_hits = 7, untranslate_hits = 14

ciscoasa#

************
R1#ping 10.1.1.25 source 1.1.1.1

Packet sent with a source address of 1.1.1.1

!!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/4 ms

Cisco IOS to ASA (8.4) - Basic IPSec Site-to-Site VPN

2011-06-25T12:57:00.000-05:00

R1 -

crypto isakmp policy 1

encr 3des

hash md5

authentication pre-share

group 2

crypto isakmp key ipexpert address 10.1.1.2

crypto ipsec transform-set oscar esp-3des esp-md5-hmac

crypto map shelby 1 ipsec-isakmp

set peer 10.1.1.2

set transform-set oscar

match address 100

access-list 100 permit ip host 2.2.2.2 host 1.1.1.1

interface FastEthernet0/0

ip address 10.1.1.25 255.255.255.0

duplex auto

speed auto

crypto map shelby

****************************

ASA -

crypto ipsec ikev1 transform-set oscar esp-3des esp-md5-hmac

crypto map shelby 1 match address abby

crypto map shelby 1 set peer 10.1.1.25

crypto map shelby 1 set ikev1 transform-set oscar

crypto map shelby interface outside

crypto ikev1 enable outside

crypto ikev1 policy 1

authentication pre-share

encryption 3des

hash md5

group 2

lifetime 86400

tunnel-group adrian type ipsec-l2l

tunnel-group 10.1.1.25 type ipsec-l2l

tunnel-group 10.1.1.25 ipsec-attributes

ikev1 pre-shared-key *****

access-list abby extended permit ip host 2.2.2.2 host 1.1.1.1

access-list abby extended permit ip host 1.1.1.1 host 2.2.2.2

Cisco IOS - Basic IPSec Site-to-Site VPN

2011-06-20T12:07:00.001-05:00

This is the basic configuration needed to bring up an IPSec tunnel between (2) IOS routers (This was done on a pair of 2801's)

Please keep in mind that the names used do not have to match on both side's.

R1

crypto isakmp policy 1
encr 3des
hash md5
authentication pre-share
group 2

crypto isakmp key c1sco address 10.1.12.2

crypto ipsec transform-set shelby esp-3des esp-md5-hmac

crypto map CMAP 10 ipsec-isakmp
set peer 10.1.12.2
set transform-set shelby
match address 100

interface Serial0/3/0
ip address 10.1.12.1 255.255.255.0
clock rate 64000
crypto map CMAP

interface Loopback0

ip address 1.1.1.1 255.255.255.255

ip route 2.2.2.0 255.255.255.0 10.1.12.2

access-list 100 permit ip host 1.1.1.1 host 2.2.2.2

r1#ping 2.2.2.2 source lo0

Packet sent with a source address of 1.1.1.1
!!!!!

r1#show crypto session

Crypto session current status

Interface: Serial0/3/0
Session status: UP-ACTIVE
Peer: 10.1.12.2 port 500
IKE SA: local 10.1.12.1/500 remote 10.1.12.2/500 Active
IPSEC FLOW: permit ip host 1.1.1.1 host 2.2.2.2
Active SAs: 2, origin: crypto map

*************

R2

crypto isakmp policy 1
encr 3des
hash md5
authentication pre-share
group 2

crypto isakmp key c1sco address 10.1.12.1

crypto ipsec transform-set shelby esp-3des esp-md5-hmac

crypto map CMAP 10 ipsec-isakmp
set peer 10.1.12.1
set transform-set shelby
match address 100

interface Loopback0
ip address 2.2.2.2 255.255.255.255

interface Serial0/3/0
ip address 10.1.12.2 255.255.255.0
crypto map CMAP

ip route 1.1.1.0 255.255.255.0 10.1.12.1

access-list 100 permit ip host 2.2.2.2 host 1.1.1.1

IPSEC - ISAKMP Perfect Forwarding Secrecy / Diffie-Hellman

2011-06-14T20:17:00.000-05:00

Diffie-Hellman (DH)

Diffie-Hellman (DH) is a public-key cryptography protocol that allows two devices to establish a shared secret over an unsecure communications channel (ISAKMP Phase 1 / IPSec Phase 2)

Diffie-Hellman Group 1 — 768-bit DH Group.

Diffie-Hellman Group 2 — 1024-bit DH Group.

Diffie-Hellman Group 5 — 1536-bit DH Group.

________________________

Perfect Forward Secrecy (PFS)

The PFS determines the length (complexity) of the IPSec "Session keys" (used in the encryption and decryption of data in the IPSec tunnel (IPSEC Security Association (SA) )), and is derived from the public and private keys.

PFS has four groups:

Group1: Specifies that IPSec should use the 768-bit Diffie-Hellman prime modulus group when performing the new Diffie-Hellman exchange.

Group2: Specifies that IPSec should use the 1024-bit Diffie-Hellman prime modulus group when performing the new Diffie-Hellman exchange.

Group5: Specifies that IPSec should use the 1536-bit Diffie-Hellman prime modulus group when performing the new Diffie-Hellman exchange.

Group7: Specifies that IPSec should use group7 (ECC) where the elliptical curve field size is 163-bits, for example, with the movianVPN client.

The crypto map set pfs command sets IPSec to ask for Perfect Forward Secrecy (PFS) when new security associations are requested for this crypto map entry. Alternatively, it asks that IPSec requires PFS when requests are received for new security associations.

To specify that IPSec not request PFS, issue the no crypto map set pfs command. This command is only available for ipsec-isakmp crypto map entries and dynamic crypto map entries.
Note: By default, PFS is not requested.

With PFS, every time a new security association is negotiated, a new Diffie-Hellman exchange occurs, which requires additional processing time.

PFS adds another level of security because if one key is ever cracked by an attacker, only the data sent with that key is compromised. During negotiation, the no crypto map set PFS command causes IPSec to request PFS when new security associations are requested for the crypto map entry.

The default (group1) is sent if the set pfs statement does not specify a group. If the peer initiates the negotiation and the local configuration specifies PFS, the peer must perform a PFS exchange or the negotiation fails.

If the local configuration does not specify a group, a default of group1 is assumed and an offer of either group1 or group2 is accepted. If the local configuration specifies group2, that group must be part of the peer offer or the negotiation fails.

IPSec

2011-06-11T18:38:00.000-05:00

IKE - Internet Key Exchange | Uses uses the framework provided by ISAKMP

ISAKMP - Internet Security Association Key Management Protocol

IPSec -

Phase 1 - The first phase is used to create a secure and authentic communication channel between the peers.

The are (2) mode’s to est. Phase 1 SA (Security Association):

Main mode - Typically used for Site-to-Site VPN

(6) packet / 3 round trips to est. SA

Aggressive - Typically used for Remote-Access

(3) packets total to est. SA

These are the default when pre-shared keys are being used.

ISAKMP Attributes negotiated during Phase 1:

Encryption - DES, 3DES, (AES 128, 192, 256)
Hashing - MD5 , SHA
Authentication Method - Pre-shared Keys, RSA or DSA Signature
DH (Diffie - Hellman) Group - 1, 2, 5, 7

Once the ISAKMP SA negotiation is complete, Phase 2 IPsec SA will then be negotiated over an encrypted channel.

All the payloads are encrypted in phase 2 negotiations except for the IP header.

IPSec Pass-Through / NAT-T - These are technologies used to avoid packet drop should the device be behind a PAT device.

IPSec Attributes negotiated during Phase 2:

Encryption - DES, 3DES, (AES 128, 192, 256)
Hashing - MD5 , SHA or Null
Identity Information - Network, Protocol, port number
Lifetime
Mode - Tunnel , Transport
PFS group - None, 1, 2, or 5

IPSec Protocols

AH (Authentication Header) IP Protocol 51
ESP (Encapsulation Security Payload) IP Protocol 50

These protocols as an IPSec header allowing the peer to decrypt the data.

(Cisco ASA does not support AH encapsulation)

Cisco ASA - Active / Passive

2011-04-24T07:58:00.001-05:00

If you need to set up a pair of ASA 55XX for Active / Passive, here is the base configuration needed to get this up and running. Please keep in mind that both ASA’s need to be running identical code and below is the minimal amount of configuration needed, there are many more configuration options available.

The commands below are to be entered into the Primary ASA:

#failover (This is the last command you should enter, this turns on the failover)

#failover lan unit primary

#failover lan interface failover GigabitEthernet1/1

#failover replication http (This is optional as HTTP sessions don’t get replicated to the stand-by device)

#failover mac address GigabitEthernet0/0 c471.fe43.f830 f866.f24d.0d4a (The first mac address is the primary and the second is the passive ASA)

#failover mac address GigabitEthernet0/1 c471.fe43.f831 f866.f24d.0d4b

#failover mac address GigabitEthernet0/2 c471.fe43.f832 f866.f24d.0d4c

#failover mac address GigabitEthernet0/3 c471.fe43.f833 f866.f24d.0d4d

#failover mac address GigabitEthernet1/0 c471.fe43.fd34 588d.096c.b2d0

#failover link failover GigabitEthernet1/1

#failover interface ip failover 172.16.169.1 255.255.255.252 standby 172.16.169.2

The commands below are to be entered into the Passive ASA:

#failover (This is the last command you should enter, this turns on the failover)

#failover lan unit secondary

#failover lan interface failover GigabitEthernet1/1

#failover interface ip failover 172.16.169.1 255.255.255.252 standby 172.16.169.2 (The IP are correct, they have to match what is on the Primary device)

Nexus - AAA w/ VRFs & VDCs

2011-04-19T21:28:00.003-05:00

If you are looking to configure AAA on a nexus 70XX and the subnet you are going to use to contact the ACS server is in a VRF and / or the non-default VDC (VDC 2, 3, 4) then you will have to do things a little different than you might be used to.

First, make sure that the TACACS+ feature is enabled or none of the options below will be available.

Second, all AAA commands are local to each individual VDC so you will need to do this with each one.

The configuration on the ACS server will remain the same and you are also able to test from exec mode:

#test aaa server tacacs+ 10.1.1.1 vrf VRF-NAME-HERE jdoe cisco123

Now, onto the fun stuff...

You will need to define your TACACS server / keys before preceding onto the next part:

#tacacs-server host 10.1.1.1 key 0 cisco123

#tacacs-server host 10.1.1.2 key 0 cisco123

Add this line after you create your server group:

#aaa authentication login default group Tacserver_DMZ

This is where it varies slightly from what you might be used to. You need to create a “aaa server group” in order to use a different VRF.

#aaa group server tacacs+ Tacserver_DMZ
    server 10.1.1.1
   (You dont need to add the key as they will use the ones already stated earlier.)
    server 10.1.1.2
    use-vrf DMZ_TEST
    source-interface Vlan10
    (This is the SVI that will be used to contact the ACS Server but you can also use interfaces, loopback interfaces ect.)

You might also want to add these few commands under your VRF context also:

#vrf context DMZ_TEST
ip domain-name cisco.com
ip name-server 10.1.1.100 10.1.1.200

That should get you going in the right direction!

Nexus - Removing an Allocated Ethernet Port.

2011-04-14T15:15:00.000-05:00

When it comes to allocating ports to a VDC (Virtual Device Context),there is a lot of information on the web to help you out.

Now, lets just say that you want to remove a port from a VDC.

Until you know how to do it, it is not the normal Cisco way of doing a "no" in front of the command.

Usually you will just enter the non-default VDC:

#vdc servers

Now you can allocate ports, something like this:

allocate interface Ethernet1/2,Ethernet1/4,Ethernet1/6,Ethernet1/8
allocate interface Ethernet2/2,Ethernet2/4,Ethernet2/6,Ethernet2/8

In order to get these ports back to the default VDC, it makes sense once someone explains it.

Even if you are in the default VDC, you need to enter the "default" VDC

#vdc "name of default VDC"

Now once you are there, you just do the same thing to get them back.

#allocate interface Ethernet1/2,Ethernet1/4,Ethernet1/6,Ethernet1/8

Now the ports have no configuration and are ready to be re-used.

Lab 2 Cisco 360 Notes

2011-01-01T16:28:00.000-06:00

When you enable OSPF authentication on a link and do a "show ip ospf" you get the output below but you can clearly see that authentication has been configured on the interface. If you do a "debug ip ospf packet" you will see that " aut:2 " MD5 is being used.

Note: aut:0 / No authentication | aut:1 / Clear text authentication.

R2#sh ip ospf

<output omitted>

Area has no authentication

interface FastEthernet0/0
ip address 172.16.20.2 255.255.255.128
ip ospf authentication message-digest
ip ospf message-digest-key 1 md5 c1sco
ip ospf mtu-ignore
duplex auto
speed auto
end

R2#deb ip ospf packet
OSPF packet debugging is on
R2#
*Jan 1 15:03:30.239: OSPF: rcv. v:2 t:1 l:48 rid:172.16.200.1
      aid:0.0.0.3 chk:0 aut:2 keyid:1 seq:0x2B916A81 from FastEthernet0/0

***********
ICMP Router Discovery Protocol (IRDP)

SW3 -

interface FastEthernet0/10
no switchport
ip address 172.16.30.10 255.255.255.128
ip irdp

interface FastEthernet0/0.50
encapsulation dot1Q 50
ip address 172.16.30.3 255.255.255.128
ip irdp
ip irdp multicast
ip irdp maxadvertinterval 20
ip irdp minadvertinterval 20
ip irdp holdtime 60
!

***********
IPv6 Tunneling

R1 -

interface Tunnel15 - To R5
no ip address
ipv6 address FEC0::15:1/112
ipv6 ospf 1 area 0
tunnel source BVI1
tunnel destination 172.16.10.5
tunnel mode ipv6ip (Non-Cisco Proprietary)

interface Tunnel16 - To R6
no ip address
ipv6 address FEC0::16:1/112
ipv6 ospf 1 area 56
tunnel source BVI1
tunnel destination 172.16.10.6
(GRE - Default and Cisco Proprietary)

R5 -

interface Tunnel15 - To R1
no ip address
ipv6 address FEC0::15:5/112
ipv6 ospf 1 area 0
tunnel source FastEthernet0/0.10
tunnel destination 172.16.10.1
tunnel mode ipv6ip (Non-Cisco Proprietary)

R6 -

interface Tunnel16 - To R1
no ip address
ipv6 address FEC0::16:6/112
ipv6 ospf 1 area 56
tunnel source FastEthernet0/0
tunnel destination 172.16.10.1
(GRE - Default and Cisco Proprietary)

***********

SW3#show spanning-tree mst configuration
Name      []
Revision 0     Instances configured 3

Instance Vlans mapped
-------- ---------------------------------------------------------------------
0         1-109,131-139,161-4094
1         110-130
2         140-160
-------------------------------------------------------------------------------

SW3(config)#spanning-tree mst 1 priority 24576

SW3#sh spanning-tree mst 1

##### MST1    vlans mapped:   110-130
Bridge        address 0013.1a06.6580 priority      24577 (24576 sysid 1)
Root          this switch for MST1

Interface        Role Sts Cost      Prio.Nbr Type
---------------- ---- --- --------- -------- --------------------------------
Fa0/13           Desg FWD 200000    128.13   P2p
Fa0/14           Desg FWD 200000    128.14   P2p

***********
RSPAN -

The link that we are monitoring is a trunk and has numerous VLANs traversing the link. Below you will see we are only interested in the traffic from v120 and v130.

monitor session 1 source interface Fa0/16
monitor session 1 filter vlan 120 , 130
monitor session 1 destination remote vlan 999

sw1#sh monitor session 1
Session 1
---------
Type                   : Remote Source Session
Source Ports           :
    Both               : Fa0/16
Filter VLANs           : 120,130
Dest RSPAN VLAN        : 999

What you see configured here in that we are taking the interesting traffic from the trunk and adding all of it to v120 as the sniffer is attached to an access port belonging to v120.

monitor session 1 destination interface Fa0/16 ingress untagged vlan 120
monitor session 1 source remote vlan 999

sw2#sh monitor session 1
Session 1
---------
Type                   : Remote Destination Session
Source RSPAN VLAN      : 999
Destination Ports      : Fa0/16
    Encapsulation      : Native
          Ingress : Enabled, default VLAN = 120
    Ingress encap : Untagged

IP SLA

2010-12-30T18:24:00.001-06:00

Cisco IOS IP SLAs can send SNMP traps that are triggered by events such as the following:

• Connection loss
• Timeout
• Round-trip time threshold
• Average jitter threshold
• One-way packet loss
• One-way jitter
• One-way mean opinion score (MOS)
• One-way latency

Alternately, an Cisco IOS IP SLAs threshold violation can trigger another Cisco IOS IP SLAs operation for further analysis.

The Cisco IOS IP SLAs MPLS VPN Awareness feature provides the capability to monitor IP service levels within Multiprotocol Label Switching (MPLS) Virtual Private Networks (VPNs). IP SLAs operations can be configured for a specific VPN by specifying a VPN routing and forwarding (VRF) name.

*************

The IP SLAs UDP jitter operation was primarily designed to diagnose network suitability for real-time traffic applications such as voice over IP (VoIP), video over IP, or real-time conferencing.

UDP jitter operations are capable of measuring the following:

Per-direction jitter (source to destination and destination to source)
Per-direction packet-loss
Per-direction delay (one-way delay)
Round-trip delay (average round-trip time)

Before configuring a UDP jitter operation on the source device, the IP SLAs Responder MUST be enabled on the target device (the operational target). The IP SLAs Responder is available only on Cisco IOS software-based devices.

When compared to the IP SLAs User Datagram Protocol (UDP) jitter operation, the IP SLAs ICMP jitter operation may provide less accurate measurements because the accuracy of the measurements provided by a non-Cisco destination device cannot be determined.

Since ICMP packets do not support voice technology, the IP SLAs ICMP jitter operation does not support Mean Opinion Score (MOS), Calculated Planning Impairment Factor (ICPIF), or estimated transmission rating factor (R) reaction configuration capabilities.

*************

The IP SLAs ICMP Jitter Operation feature provides the following key benefits:

End-to-end performance measurements between a Cisco device (source) and any other IP device (destination) using ICMP.

Proactive threshold violation monitoring through Simple Network Management Protocol (SNMP) trap notifications and syslog messages.

The IP SLAs ICMP jitter operation supports the following statistical measurements:

Jitter (source-to-destination and destination-to-source)
Latency (source-to-destination and destination-to-source)
Round-trip time latency
Packet loss
Successive packet loss
Out-of-sequence packets (source-to-destination, destination-to-source, and round-trip)
Late packets

*************

The IP SLAs UDP echo operation measures end-to-end response time between a Cisco router and devices using IP. UDP is a network layer (Layer 3) Internet protocol that is used for many IP services. UDP echo is used to measure response times and test end-to-end connectivity.

UDP echo accuracy is enhanced by using the IP SLAs Responder at Router A, the
destination Cisco router. If the destination router is a Cisco router, then IP SLAs sends a UDP datagram to any port number that you specified. Using the IP SLAs Responder is OPTIONAL for a UDP echo operation when using Cisco devices.

A UDP echo operation measures round-trip delay times and tests connectivity to Cisco and
non-Cisco devices.

*************

The IP SLAs HTTP operation measures the round-trip time (RTT) between a Cisco device and an HTTP server to retrieve a web page. The HTTP server response time measurements consist of three types:

DNS lookup—RTT taken to perform domain name lookup.
TCP Connect—RTT taken to perform a TCP connection to the HTTP server.
HTTP transaction time—RTT taken to send a request and get a response from the HTTP server. The operation retrieves only the home HTML page.

The DNS operation is performed first and the DNS RTT is measured. Once the domain name is found, a TCP Connect operation to the appropriate HTTP server is performed and the RTT for this operation is measured. The final operation is an HTTP request and the RTT to retrieve the home HTML page from the HTTP server is measured. One other measurement is made and called the time to first byte which measures the time from the start of the TCP Connect operation to the first HTML byte retrieved by the HTTP operation. The total HTTP RTT is a sum of the DNS RTT, the TCP Connect RTT, and the HTTP
RTT.

*************

The IP SLAs TCP Connect operation measures the response time taken to perform a TCP Connect operation between a Cisco router and devices using IP. TCP is a transport layer (Layer 4) Internet protocol that provides reliable full-duplex data transmission. The destination device can be any device using IP or an IP SLAs Responder.

*************

The IP SLAs ICMP Echo operation measures end-to-end response time between a Cisco router and any devices using IP. Response time is computed by measuring the time taken between sending an ICMP Echo request message to the destination and receiving an ICMP Echo reply. This operation does not require the IP SLAs Responder to be enabled.

*************

The IP SLAs ICMP Path Echo operation records statistics for each hop along the path that the IP SLAs operation takes to reach its destination. The ICMP Path Echo operation determines this hop-by-hop response time between a Cisco router and any IP device on the network by discovering the path using the traceroute facility.

The source IP SLAs device uses traceroute to discover the path to the destination IP device.

A ping is then used to measure the response time between the source IP SLAs device and each subsequent hop in the path to the destination IP device. This operation does NOT require the IP SLAs Responder to be enabled.

*************

The IP SLAs ICMP Path Jitter operation provides hop-by-hop jitter, packet loss, and delay measurement statistics in an IP network. The Path Jitter operation functions differently than the standard UDP Jitter operation, which provides total one-way data and total round-trip data.

The ICMP Path Jitter operation can be used a supplement to the standard UDP Jitter operation. For example, results from the UDP Jitter operation may indicate unexpected delays or high jitter values; the ICMP Path Jitter operation could then be used to troubleshoot the network path and determine if traffic is bottlenecking in a particular segment along the transmission path.

The operation first discovers the hop-by-hop IP route from the source to the destination using a traceroute utility, and then uses ICMP echoes to determine the response times, packet loss and approximate jitter values for each hop along the path. The jitter values obtained using the ICMP Path Jitter operation are approximates because ICMP only provides round trip times.

The ICMP Path Jitter operation is NOT supported in the RTTMON MIB; configuration and performance data can only be obtained using the CLI.

The ICMP Path Jitter operation functions by tracing the IP path from a source device to a specified destination device, then sending N number of Echo probes to each hop along the traced path, with a time interval of T milliseconds between each Echo probe. The operation as a whole is repeated at a frequency of once every F seconds. The attributes are user-configurable.

The IP SLAs ICMP Path Jitter operation is ICMP-based. ICMP-based operations can compensate for source processing delay but cannot compensate for target processing delay. For more robust monitoring and verifying, use of the IP SLAs UDP Jitter operation is recommended.

The jitter values obtained using the ICMP Path Jitter operation are approximates because ICMP does not provide the capability to embed processing times on routers in the packet. If the target router does not place ICMP packets as the highest priority, then the router will not respond properly. ICMP performance also can be affected by the configuration of priority queueing on the router and by ping response.

Unlike other IP SLAs operations, the ICMP Path Jitter operation is not supported in the RTTMON MIB. Path Jitter operations can only be configured using the CLI, and statistics can only be returned using CLI show ip sla commands.

In contrast with other IP SLAs operations, the IP SLAs Responder does NOT have to be enabled on either the target device or intermediate devices for Path Jitter operations. However, the operational efficiency may improve if you enable the IP SLAs Responder;

*************

The FTP operation measures the round-trip time (RTT) between a Cisco device and an FTP server to retrieve a file. FTP is an application protocol, part of the Transmission Control Protocol (TCP)/IP protocol stack, used for transferring files between network nodes.

Both active and passive FTP transfer modes are supported. The passive mode is enabled by default. Only the FTP GET (download) operation type is supported. The URL specified for the FTP GET operation must be in one of the following formats:

ftp://username:password@host/filename
ftp://host/filename

If the username and password are not specified, the defaults are anonymous and test, respectively. FTP carries a significant amount of data traffic and can affect the performance of your network. The results of an IP SLAs FTP operation to retrieve a large file can be used to determine the capacity of the network but retrieve large files with caution because the FTP operation will consume more bandwidth. The FTP operation also measures your FTP server performance levels by determining the RTT taken to retrieve a file.

*************

The DNS operation measures the difference between the time taken to send a DNS request and receive a reply. DNS is used in the Internet for translating names of network nodes into addresses. The IP SLAs DNS operation queries for an IP address if you specify a host name, or queries for a host name if you specify an IP address.

*************

The Dynamic Host Configuration Protocol (DHCP) operation measures the round-trip time (RTT) taken to discover a DHCP server and obtain a leased IP address from it. DHCP provides a mechanism for allocating IP addresses dynamically so that addresses can be reused when hosts no longer need them. IP SLAs releases the leased IP address after the operation.

There are two modes for the DHCP operation. By default, the DHCP operation sends discovery packets on every available IP interface on the router. If a specific server is configured on the router, using the ip dhcp-server command, discovery packets are sent only to that DHCP server.

The DHCP operation also measures your DHCP server performance levels by determining the RTT taken to obtain a leased IP address.

A DHCP relay agent is any host that forwards DHCP packets between clients and servers. Relay agents are used to forward requests and replies between clients and servers when they are not on the same physical subnet. Relay agent forwarding is distinct from the normal forwarding of an IP router, where IP packets are switched between networks somewhat transparently. Relay agents receive DHCP messages and then generate a new DHCP message to send out on another interface.

The IP SLAs DHCP operation contains a relay agent information option—Option 82—which is inserted by the DHCP relay agent when forwarding client-originated DHCP packets to a DHCP server. Servers recognizing the relay agent information option may use the information to implement IP address or other parameter assignment policies. The DHCP server echoes the option back verbatim to the relay agent in server-to-client replies, and the relay agent strips the option before forwarding the reply to the client. Option 82 includes three suboptions that convey information known by the relay agent:

circuit-id—identifies the incoming circuit.
remote-id—provides a trusted identifier for a remote high-speed modem.
subnet-mask—identifies the mask of the logical IP subnet from which the relay agent received the client DHCP packet.

This operation does NOT require the IP SLAs responder to be enabled so there
are no tasks to be performed on the destination device.

Prerequisites for Multioperation Scheduling of IP SLAs Operations

Configure the IP SLAs operations before group scheduling those operations.

Determine the IP SLAs operations you want to schedule as a single group.

Identify the network traffic type and the location of your network management station.

Identify the topology and the types of devices in your network.

Decide on the frequency of testing for each operation. Normal scheduling of IP SLAs operations allows you to schedule one operation at a time. If you have large networks with thousands of IP SLAs operations to monitor network performance, normal scheduling (scheduling each operation individually) will be inefficient and time-consuming.

The IP SLAs multiple operations scheduling functionality allows you to schedule multiple IP SLAs operations as a group using the ip sla group schedule command. The following parameters can be configured with this command:

Group operation number—Group configuration or group schedule number of the IP SLAs operation to be scheduled.

Operation ID numbers—A list of IP SLAs operation ID numbers in the scheduled operation group.

Schedule period—Amount of time for which the IP SLAs operation group is scheduled.

Ageout—Amount of time to keep the operation in memory when it is not actively collecting
information. By default, the operation remains in memory indefinitely.

Frequency—Amount of time after which each IP SLAs operation is restarted. When the frequency option is specified, it overwrites the operation frequency of all operations belonging to the group. Note that when the frequency option is not specified, the frequency for each operation is set to the value of the schedule period.

Life—Amount of time the operation actively collects information. The operation can be configured to run indefinitely. By default, the lifetime of an operation is one hour.

Start time—Time when the operation starts collecting information. You can specify an operation to start immediately or at an absolute start time using hours, minutes, seconds, day, and month. The IP SLAs multiple operations scheduling functionality schedules the maximum number of operations possible without aborting. However, this functionality skips those IP SLAs operations that are already running or those that are not configured and hence do not exist. The total number of operations will be calculated based on the number of operations specified in the command, irrespective of the number of operations that are missing or already running. The IP SLAs multiple operations scheduling functionality displays a message showing the number of active and missing operations. However, these messages are displayed only if you schedule operations that are not configured or are already running.

A main benefit for scheduling multiple IP SLAs operations is that the load on the network is reduced by distributing the operations equally over a scheduled period. This distribution helps you to achieve more consistent monitoring coverage. To illustrate this scenario, consider configuring 60 operations to start during the same 1-second interval over a 60-second schedule period.

If a network failure occurs 30 seconds after all 60 operations have started and the network is restored before the operations are due to start again (in another 30 seconds), then this failure would never be detected by any of the 60 operations. However, if the 60 operations are distributed equally at 1-second intervals over a 60-second schedule period, then some of the operations would detect the network failure. Conversely, if a network failure occurs when all 60 operations are active, then all 60 operations would fail, indicating that the failure is possibly more severe than it really is.

Operations of the same type and same frequency should be used for IP SLAs multiple operations scheduling. If you do not specify a frequency, the default frequency will be the same as that of the schedule period. The schedule period is the period of time in which all the specified operations should run.

The following sections explain the IP SLAs multiple operations scheduling process:

Multiple operations scheduling allows you to schedule multiple IP SLAs operations using a single command through the command line interface (CLI) or the CISCO-RTTMON-MIB.

This feature allows you to control the amount of IP SLAs monitoring traffic by scheduling the operations to run at evenly distributed times. You must specify the operation ID numbers to be scheduled and the time range over which all the IP SLAs operations should start. This feature automatically distributes the IP SLAs operations at equal intervals over a specified time frame. The spacing between the operations (start interval) is calculated and the operations are started. This distribution of IP SLAs operations helps minimize the CPU utilization and thereby enhances the scalability of the network.

The IP SLAs Multiple Operations Scheduling feature allows you to schedule multiple IP SLAs
operations as a group using the ip sla group schedule command.

The ip sla group schedule 1 1-10 schedule-period 20 [frequency 20] command is configured. This example schedules operation 1 to operation 10 within operation group 1. Operation group 1 has a schedule period of 20 seconds, which means that all operations in the group will be started at equal intervals within a 20-second period. By default, the frequency is set to the same value as the configured schedule period.

IP SLAs entry configuration commands:

dhcp           DHCP Operation
dns             DNS Query Operation
ethernet      Ethernet Operations
exit             Exit Operation Configuration
frame-relay Frame-relay Operation
ftp              FTP Operation
http             HTTP Operation
icmp-echo    ICMP Echo Operation
icmp-jitter    ICMP Jitter Operation
mpls           MPLS Operation
path-echo   Path Discovered ICMP Echo Operation
path-jitter    Path Discovered ICMP Jitter Operation
tcp-connect TCP Connect Operation
udp-echo     UDP Echo Operation
udp-jitter     UDP Jitter Operation
voip         Voice Over IP Operation

#ip sla reaction-configuration 1 react ?

jitterAvg           Jitter Average in both the directions
jitterDSAvg        Jitter Average in the direction from Destination to Source
jitterSDAvg        Jitter Average in the direction from Source to Destination

*************

#ip sla reaction-configuration 1 react jitterAvg threshold-type ?

average       Average over N attempts
consecutive Consecutive occurrences
immediate   React immediately
never          Never react
xOfy           X out of Y occurrences

*************

#ip sla reaction-configuration 1 react jitterAvg action-type ?
none                No action
trapAndTrigger Trap and Trigger action
trapOnly           Trap Only action
triggerOnly       Trigger Only action

*************

packetLateArrival          Packets arriving Late
packetLoss                   Packet Loss in both direction
packetLossDS               Packet Loss in the direction from Destination to Source
packetLossSD               Packet Loss in the direction from Source to Destination
packetMIA                   Missing In Action
packetOutOfSequence   Packets arriving out of sequence

IP SLAs Reaction Configuration -

IP SLAs can be configured to react to certain measured network conditions. For example, if IP SLAs measures too much jitter on a connection, IP SLAs can generate a notification to a network management application, or trigger another IP SLAs operation to gather more data.

IP SLAs reaction configuration is performed using the ip sla reaction-configuration command. You can configure the ip sla reaction-configuration command multiple times so as to allow reactions for multiple monitored elements (for example, configuring thresholds for operation 1 for destination-to-source packet loss, and also configuring MOS thresholds for same operation). However, issuing the no ip sla reaction-configuration operation-number will clear all reactions for the specified operation. In other words, disabling of granular reaction elements (no ip sla reaction-configuration operation-number react monitored-element) is not currently supported, so as to provide backwards compatibility with the earlier version of this command.

You can check the configuration of the IP SLAs reaction configuration using the <show ip sla
reaction-configuration> command.

IP SLAs includes the capability for triggering SNMP notifications based on defined thresholds. This allows for proactive monitoring in an environment where IT departments can be alerted to potential network problems, rather than having to manually examine data.

IP SLAs supports threshold monitoring for performance parameters such as average jitter, unidirectional latency and bidirectional round trip time and connectivity. This proactive monitoring capability provides options for configuring reaction thresholds for important VoIP related parameters including unidirectional jitter, unidirectional packet loss, and unidirectional VoIP voice quality scoring (MOS scores).

IP SLAs can generate system logging (syslog) messages when a reaction condition occurs. These system logging messages can then be sent as SNMP notifications (traps) using the CISCO-RTTMON-MIB. For packet loss and jitter, notifications can be generated for violations in either direction (source to destination and destination to source) or for round trip values. Packet loss, jitter and MOS statistics are specific to IP SLAs Jitter operations. Notifications can also be triggered for other events, such as round-trip-time violations, for most IP SLAs monitoring operations.

SNMP notifications (traps) for IP SLAs can be configured as a triggered action, to be sent when monitored values exceed an upper threshold or fall below a lower threshold, or when a set of defined conditions are met. For example, an SNMP trap can be triggered by 5 consecutive timeouts during an IP SLAs operation.

The sending of SNMP traps is one of the options for triggered actions that can be configured for IP SLAs violations. The monitored values (also called monitored elements), the threshold type, and the triggered action are configured using the ip sla reaction-configuration global configuration mode command.

SNMP traps for IP SLAs are supported by the CISCO-RTTMON-MIB and CISCO-SYSLOG-MIB. Use the ip sla logging traps command to enable the generation of SNMP system logging messages specific to IP SLAs trap notifications. Use the snmp-server enable traps rtr command to enable the sending of IP SLAs SNMP trap notifications.

IP SLAs reactions are configured to be triggered when a monitored value exceeds or falls below a specified level, or when a monitored event (such as a timeout or connection loss) occurs. These monitored values and events are called monitored elements.

Round-trip-time (rtt) is one of the monitored values of all IP SLAs operations. Events (such as traps) can be triggered when the rtt value rises above a specified threshold, or when it falls below a specified threshold. To configure rtt as the monitored element, use the following version of the ip sla reaction-configuration command:

Jitter (interpacket delay variance) is one of the monitored values of IP SLAs UDP Jitter operations.

Jitter values are computed as source-to-destination, destination-to-source, and combined round-trip values. Events (such as traps) can be triggered when the average jitter value in either direction, or in both directions, rises above a specified threshold, or when it falls below a specified threshold.

Pactket loss is one of the monitored values of IP SLAs UDP Jitter operations. Jitter values are computed as source-to-destination and destination-to-source values. Events (such as traps) can be triggered when the jitter value in either direction rises above a specified threshold, or when it falls below a specified threshold.

To configure source-to-destination packet loss as the monitored element, use the react PacketLossSD syntax in the ip sla reaction-configuration command.

To configure destination-to-source jitter as the monitored element , use the react PacketLossDS syntax in the ip sla reaction-configuration command.

Mean opinion score (MOS) is one of the monitored values of IP SLAs Jitter VoIP operations. MOS values are computed as numbers to two decimal places, from a value of 1.00 (worst quality) to 5.00 (best quality). Events (such as traps) can be triggered when the MOS value in either direction rises above a specified threshold, or when it falls below a specified threshold.

To configure destination-to-source jitter as the monitored element , use the react mos syntax in the ip sla reaction-configuration command.

The threhold-type syntax of the ip sla reaction-configuration command defines the type of threshold violation (or combination of threshold violations) that will trigger an event. Threshold violation types are as follows:

immediate - Triggers an event immediately when the value for a reaction type (such as response time) exceeds the upper threshold value or falls below the lower threshold value, or when a timeout, connectionLoss, or verifyError event occurs.

consecutive - Triggers an event only after a violation occurs a specified number of times
consecutively. For example, the consecutive violation type could be used to configure an action to occur after a timeout occurs 5 times in a row, or when the round-trip-time exceeds the upper threshold value 5 times in a row

x of y - Triggers an event after some number (x) of violations within some other number (y) of probe operations (x of y)

averaged - Triggers an event when the averaged totals of a value for x number of probe operations exceeds the specied upper-threshold value, or falls below the lower-threshold value. Configuring these threshold violation types is described in the following sections.

Generating Events for Each Violation -

To generate a trap (or trigger another operation) each time a specified condition is met, use the immediate threshold-type keyword:

ip sla reaction-configuration operation-number react data-type threshold-type immediate
threshold-value raising-value falling-value action-type action-value

Generating Events for Consecutive Violations -

To generate a trap (or trigger another operation) after a certain number (x) of consecutive violations, use the consecutive keyword with the optional number-of-occurrences argument:
ip sla reaction-configuration operation-number react reaction-condition threshold-type consecutive [number-of-occurances] threshold-value raising-value falling-value action-type action-value. The default value for number-of-occurances is 5.

Generating Events for x of y Violations -

To generate a trap (or trigger another operation) after some number (x) of violations within some other number (y) of probe operations (x of y), use the xofy [x-value y-value] syntax:
ip sla reaction-configuration operation-number react reaction-condition threshold-type xofy x-value y-value threshold-value raising-value falling-value action-type action-value
The default x-value and y-value is 5 (xofy 5 5).

Generating Events for Averaged Violations -

To generate a trap (or trigger another operation) when the averaged totals of x number of probe operations violate a falling-threshold or rising-threshold, use the average [attempts] syntax:

ip sla reaction-configuration operation-number react reaction-condition threshold-type average [attempts] threshold-value raising-value falling-value action-type action-value
The default value for attempts is 5.

Specifying Reaction Events -

Action type options for the ip sla reaction-configuration command are as follows:

none—No action is taken.

trapOnly - Send an SNMP logging trap when the specified violation type occurs for the monitored element. IP SLAs logging traps are enabled using the ip sla logging traps command. For SNMP logging traps to be sent, SNMP logging must be enabled using the appropriate SNMP commands, including the snmp-server enable traps syslog command.

triggerOnly - Have one or more target operation's operational state make the transition from "pending" to "active" when the violation conditions are met. The target operations to be triggered are specified using the ip sla reaction-trigger command. A target operation will continue until its life expires, as specified by the target operation's configured lifetime value). A triggered target operation must finish its life before it can be triggered again.

trapAndTrigger - Trigger both an SNMP trap and start another IP SLAs operation when the violation conditions are met, as defined in the trapOnly and triggerOnly options above.

In the following example, IP SLAs operation 10 (a UDP Jitter operation) is configured to send an SNM logging trap when the MOS value exceeds 4.9 (best quality) of falls below 2.5 (poor quality)

# ip sla reaction-configuration 10 react mos threshold-type immediate threshold-value 490 250 action-type trapOnly

The 3560 Ingress Queue

2010-12-25T18:22:00.001-06:00

3560 Ingress Queue (2 Input) -

Inside a DOT1q tag you have COS or Priority Bits - 802.1p ( Layer 2 )

The DSCP value is located in the IP header. ( Layer 3 )

Ingress QoS features such as classification, marking and policing can be configured on a per port basis.

Input map tables and ingress queueing can be configured globally and can not be configured on a per port basis.

You can Classify / Mark the frames based on the incoming CoS / DSCP values or an ACL in one of three ways and only one method per port.

Port based configuration using the mls qos interface based commands.

intf# mls qos cos <#> - This will NOT change the CoS values of a frame that is already tagged, this will only add the CoS value you specify to packets that do not already have a tag.

intf# mls qos cos <#> override - This WILL change the CoS values of ALL frames that are tagged or untagged to the value that you designate.

intf#mls qos extend cos <#> - Will allow you to keep the EF frames from the phone and designate the marking you would like to see attached to the packets received from the PC / Server Ect.

MQC based configuration using class−map and policy−map

NOTE: PHB (Per Hop Behavior)

The configuration under each class of policy−map are called PHB actions. Marking, queuing,
policing, shaping and congestion avoidance are the supported PHB actions in Cisco routers.

Marking and Policing are the ONLY supported PHB actions in the Cisco Catalyst 3560 Switch.

The set and trust commands are Marking PHB actions.

The police command is the Policing PHB action.

Policing can only be configured on the ingress port. Policing can only be configured through MQC and this means there is no interface specific command to police the traffic.

Marking Example:

policy−map Shelby
class Class−A
trust cos
class Class−B
set dscp af21

The Cisco Catalyst 3560 Switch supports only single rate, single bucket policing. This means the switch meters at only one rate and it can profile the traffic in two colors conform and exceed action.

Policing Example:

Policy−map Oscar
class Class−A
   police 10000000 8000 exceed−action drop

Policed−dscp map:
        0   1   2   3 4   5   6   7 8 9
−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−
0 : 00 01 02 03 04 05 06 07 08 09
1 : 10 11 12 13 14 15 16 17 18 19
2 : 20 21 22 23 24 25 26 27 28 29
3 : 30 31 32 33 34 35 36 37 38 39
4 : 40 41 42 43 44 45 26 47 48 49
5 : 50 51 52 53 54 55 56 57 58 59
6 : 60 61 62 63

mls qos map policed−dscp 46 to 26

Policy−map Abby
class Class−A
   trust dscp
   police 256000 8000 exceed−action policed−dscp−transmit

SRR for ingress queue can be configured globally.

3 Steps -
i.    Queuing
ii.    Dropping
iii.    Scheduling

Ingress queues use SRR (Shared Round Robin) and is the only mode supported.

The queues share the bandwidth according to configured weights and are guaranteed this amount but not limited to it.

sw1(config)#mls qos srr-queue input ?
bandwidth       Configure SRR bandwidth
buffers            Configure buffer allocation
cos-map          Configure cos-map for a queue id
dscp-map        Configure dscp-map for a queue id
priority-queue Configure priority scheduling
threshold         Configure queue tail-drop thresholds

Queueing:

buffers          Configure buffer allocation
cos-map         Configure cos-map for a queue id
dscp-map        Configure dscp-map for a queue id

Scheduling:

bandwidth       Configure SRR bandwidth
priority-queue    Configure priority scheduling

Dropping:

threshold        Configure queue tail-drop thresholds

Each queue can support (3) threshold levels, the 3rd is 100% and cant be changed.

On the ingress queue, queue 2 is the priority-queue unlike the output queue where queue 1 is the priority-queue.

   Dscp-inputq-threshold map:
     d1 :d2    0     1     2     3     4     5     6     7     8     9
     ------------------------------------------------------------
      0 :    01-01 01-01 01-01 01-01 01-01 01-01 01-01 01-01 01-01 01-01
      1 :    01-01 01-01 01-01 01-01 01-01 01-01 01-01 01-01 01-01 01-01
      2 :    01-01 01-01 01-01 01-01 01-01 01-01 01-01 01-01 01-01 01-01
      3 :    01-01 01-01 01-01 01-01 01-01 01-01 01-01 01-01 01-01 01-01
      4 :    02-01 02-01 02-01 02-01 02-01 02-01 02-01 02-01 01-01 01-01
      5 :    01-01 01-01 01-01 01-01 01-01 01-01 01-01 01-01 01-01 01-01
      6 :    01-01 01-01 01-01 01-01

By default as you can see, the DSCP values of 40-46 are place in queue 2.

Queue 2 is the priority queue and is serviced for its configured weight (Default 10%) and the shares the remaining bandwidth 90% between queue 1 AND 2 so 45% each.

There are (3) steps to configure queuing and scheduling.

1. Queue Map configuration -
    Maps the packets to 1 of 2 queues based on CoS or DSCP

2. Queue configuration -
    Defines the ratio with which to divide the ingress buffers between the (2) queues.

3. Scheduler configuration -
    Defines the ratio of the weights that controls the frequency of dequeuing packets from the queues to the stack ring.

This will be a work in progress so hang tight...

Nexus Notes ~ Continued

2010-12-11T18:34:00.000-06:00

DCNM - Data Center Network management

Configuration Rollback-

This feature enables you to take a snapshot or checkpoint of the current
running configuration and re-apply it at any point without the need to
reload.

3 Types of Configuration rollback

Atomic - Implement only if there are no errors

Best-Effort - Implement a roll back and skip any errors

Stop-at-first-failure - Implement a roll back and stop at the first error.

Limitations-

10 snapshots per VDC

You can not use one snapshot made in one VDC and apply it to the
configuration of another VDC

You can not apply a snapshot in a non-default VDC if there is a change to
the global configuration

Filename 75 characters or less

You can not start the file name with AUTO or SUMMARY

A write erase and reload destroys the snapshot

To change which VDC you are in

#switchto vdc

To create a snapshot

#checkpoint <snapshot-filename>

To rollback to a checkpoint

#rollback running-config checkpoint <snapshot-filename>

If you do not have dual supervisors in the N7k, you cant use the ISSU

VDCs cant be shut down and restarted.

Steps needed to create a VDC and assign resources to it:

Note: VDC(s) are always created from the default admin VDC context (VDC 1)

#vdc <name of VDC>

Allocate interfaces to a VDC

#vdc <name>

#allocate interface ethernet1/17

#show vdc membership

Connectivity Management Processor-

Supports remote management and troubleshooting of the complete system.
This provides complete out-of-band management that is completely
independent independent from the primary OS. It has its own processor,
memory and bootflash and even a separate ethernet management port.

#attach cmp

FCoE (Fiber-Channel over Ethernet)

2010-12-10T13:45:00.002-06:00

Fiber-Channel Layers

5 Layers / 0 - 4 (FC0 - FC4)

Layer 0 - Physical Interface

Layer 1 - FC1 Encoding

Layer 2 - FC2 Framing & Flow Control

Layer 3 - FC3 Common Services

Layer 4 - FC4 Protocol Mapping Layer

FCoE (Fiber-Channel over Ethernet)

System MTU 2240 (Default)

Frame size (2112 Bytes) Baby Jumbo

FCoE ether type value 16 bits (0x8906)

____________________

Data Center Enhanced Ethernet

i) Priority Flow Control

Nexus Notes

2010-12-10T13:01:00.003-06:00

The Nexus 7000 switch supports 4096 VLANs per Virtual Device Context (VDC) for a system total of ~16k VLANs. Some of these VLANs are used by system-level functions and are not user-configurable.

Bridge Assurance is a new feature that can eliminate issues caused by a malfunctioning bridge. With Bridge Assurance, all ports send and receive BPDUs on all VLANs regardless of their state.

This creates a bidirectional keepalive using BPDUs, and if a bridge stops receiving BPDUs, these ports are placed into an inconsistent state. This functionality can prevent loops that can be introduced as a result of a malfunctioning bridge. Bridge Assurance is enabled by default on any port that is configured with a spanningtree port type network but can be disabled globally with the following command:

(config)# no spanning-tree bridge assurance

To enable Bridge Assurance by setting the spanning-tree port type, enter the following commands:

(config)# int port-channel 1

(config-if)# spanning-tree port type network

An interesting side effect of Bridge Assurance is an automatic pruning function.

In the topology, if a VLAN is defined on but not on , Bridge Assurance puts that VLAN into a blocking state because it is not receiving BPDUs for that VLAN.

(config)# port-profile COMMUNITY1

(config-ppm)# switchport

(config-ppm)# switchport mode access

(config-ppm)# switchport private-vlan host-association 100 102

(config-ppm)# spanning-tree port type edge

(config-ppm)# spanning-tree bpdufilter enable

(config-ppm)# spanning-tree bpduguard enable

(config-ppm)# no shutdown

(config-ppm)# state enabled

(config)# interface ethernet 2/28

(config-if)# inherit port-profile COMMUNITY1

The vPC peer-keepalive link can be either 1 Gbps or 10 Gbps.

vPC peer link:Used to exchange state information between the vPC peers and also provides additional mechanisms that can detect and prevent split-brain scenarios.

Note:The mgmt0 interface can be used as the vPC peer-keepalive link but should be avoided if at all possible.

On the Nexus 7000, the mgmt0 is actually a logical interface representing the physical management port of the active supervisor.

During processes such as supervisor switchover during hardware failure or In-Service Software Upgrades (ISSU), the physical link

supporting the mgmt0 interface might change, causing a disruption of the keepalive messages. By using normal switch interfaces, additionallevels of redundnancy in the port-channels can be used.

If the mgmt0 interface is used as the peer-keepalive link, it is critical to ensure thatall physical management ports are connected to an external device, such as a management switch.

Create VRF for the VPC keepalive link:

(config-if)# vrf context vpc-keepalive

(config)# vrf context vpc-keepalive

(config)# int ethernet 2/47

(config-if)# vrf member vpc-keepalive

(config-if)# ip address 1.1.1.1 255.255.255.252

(config)# interface ethernet 2/48

(config-if)# no switchport

(config-if)# vrf member vpc-keepalive

(config-if)# ip address 1.1.1.2 255.255.255.252

(config-if)# vrf context vpc-keepalive

(config)# vrf context vpc-keepalive

(config)# vpc domain 1

(config-vpc-domain)# peer-keepalive destination 1.1.1.2 source 1.1.1.1 vrf vpckeepalive

(config)# vpc domain 1

(config-vpc-domain)# peer-keepalive destination 1.1.1.1 source 1.1.1.2 vrf vpc-keepalive

(config)# interface port-channel 100

(config-if)# vpc peer-link

Please note that spanning tree port type is changed to “network” port type on vPC peerlink. This will enable spanning tree Bridge Assurance on vPC peer-link provided the STP Bridge Assurance (which is enabled by default) is not disabled.

(config-if)# switchport mode trunk

(config)# interface port-channel 100

(config-if)# vpc peer-link

(config)# interface ethernet 2/1

(config-if)# channel-group 1 mode active

(config)# interface port-channel 1

(config-if)# switchport

(config-if)# switchport mode trunk

(config-if)# vpc 1

VPC Peer-Gateway

This feature is designed to enable certain storage, application servers or load balancers to implement fast-path functionality.

This causes nodes to send return traffic to a specific MAC address of the sender rather than HSRP address.

By default, this traffic might be dropped as VPC loop avoidance does not allow traffic received on a VPC peer-link to be forwarded out a VPC interface (loop avoidance).

A VPC Peer-Gateway enables the VPC peer device to forward packets destined for its peer router MAC locally. To enable the peer-gateway, enter the following command:

(config-vpc-domain)# peer-gateway

(config)# power redundancy-mode ?

combined Configure power supply redundancy mode as combined

insrc-redundant Configure power supply redundancy mode as grid/AC input source redundant

vPC Concepts

The following list defines critical vPC concepts:

vPC: vPC refers to the combined PortChannel between the vPC peer devices and the downstream device.

vPC peer switch: The vPC peer switch is one of a pair of switches that are connected to the special PortChannel known as the vPC peer link. One device will be selected as the primary device, and the other will be the secondary device.

vPC peer link: The vPC peer link is the link used to synchronize states between the vPC peer devices. The vPC peer link carries control traffic between two vPC switches and also multicast, broadcast data traffic. In some link failure scenarios, it also carries unicast traffic. You should have at least two 10 Gigabit Ethernet interfaces for peer links.

vPC domain: This domain includes both vPC peer devices, the vPC peer keepalive link, and all the PortChannels in the vPC connected to the downstream devices. It is also associated with the configuration mode that you must use to assign vPC global parameters.

vPC peer keepalive link: The peer keepalive link monitors the vitality of a vPC peer switch. The peer keepalive link sends periodic keepalive messages between vPC peer devices. The vPC peer keepalive link can be a management interface or switched virtual interface (SVI). No data or synchronization traffic moves over the vPC peer keepalive link; the only traffic on this link is a message that indicates that the originating switch is operating and running vPC.

vPC member port: vPC member ports are interfaces that belong to the vPCs.