NeTribe

Cisco ASA QoS For VoIP

2013-03-12T18:09:00.001-07:00

So the goal is simple, right? You have a hosted VoIP solution and you want to ensure that your data traffic does not delay the VoIP traffic or worst still, you don't want the edge firewall dropping any VoIP packets because of high data usage.

I have a few customers that have deployed hosted VoIP solutions from WaveStreet and 8x8 - the usual complaint from time to time is that "the voice quality is bad" or "I could not hear the other party". Now most of these folks have simple networks like the one depicted below and I have managed to eliminate their VoIP issues with QoS configurations on the ASA.

In this particular example, we have a Cisco ASA 5505, a layer 3 switch with two VLANs, one for data and one for voice. Not included in this blog are the configs for the switches. It is advised that you turn on QoS on the switches if they supported it.

Prioritizing VoIP traffic using a Cisco ASA is well documented but the problem is Cisco's documents tend to omit a few important facts. Their example always use just the outside interface (ISP facing). Now, because QoS only acts on the egress traffic when applied to an interface, this does nothing for the inbound traffic from the ISP - the more important direction!

The second critical detail omitted is that even after you have applied the QoS to the correct interfaces, it does not help when a really long download is saturating the ISP link. Those VoIP packets don't have a chance getting down in time from the Internet to your network over that saturated pipe!

So how do we correct these. I used a nested policy on both the outside and inside interfaces of the firewall. The policy on the inside acts on the egress interface and therefore will impact the inbound traffic from the Internet whereas the outside one impacts the outbound traffic toward the Internet. Unfortunately, you've got to sacrifice the data bandwidth for this solution to work but there is no way around it. In my opinion it's a small price to pay.

Each call takes up about 80Kbps in our example and we have had about 10 simultaneous calls in the past so I reserved 1Mbps of our 3Mbps Internet pipe for voice traffic. This implies that the data traffic (or all but voip traffic) can share 2Mbps. To do this, you shape the default class to 2Mbps and nest the voice policy so that the voip traffic is omitted from shaping (or drops) which will give it the remaining 1Mbps. Since I had a symmetrical 3Mbps Internet connection, I applied 2Mbps of traffic shaping to both interfaces. Change the shape rate accordingly if you have asymmetrical speeds.

Here's the relevant ASA 5505 configs with some explanations.

interface Vlan1
 nameif inside
 security-level 100
 ip address 10.0.0.1 255.255.255.0
!
interface Vlan2
 nameif outside
 security-level 0
 ip address i.i.i.i 255.255.255.248
!
interface Ethernet0/0
 switchport access vlan 2
!
interface Ethernet0/1
!

!I expect you to limit the udp ports to just what your provider has recommended. !I opened up all udp just to keep things simple

access-list outside_access_in extended permit udp any any

!Although I used the entire subnet to classify the voip packets, please

!feel free to use dscp, precedence or ports instead

!Inbound voip traffic classification
access-list voip_inside extended permit ip any 10.16.1.0 255.255.255.0

!outbound (toward Internet) voip traffic classification

access-list voip_outside extended permit ip 10.16.1.0 255.255.255.0 any
!
global (outside) 1 70.35.47.195 netmask 255.255.255.255
nat (inside) 1 10.0.0.0 255.0.0.0
!
access-group outside_access_in in interface outside
route outside 0.0.0.0 0.0.0.0 i.i.i.a 1
!

!Enable the piority queues on both interfaces
priority-queue inside
priority-queue outside
!

!Define the class maps for both inbound and outbound voice traffic and prioritize

!the voice traffic

!
class-map voice-inside-class
 match access-list voip_inside
class-map voip-outside-class
 match access-list voip_outside
!

policy-map global_policy
 class inspection_default
  inspect dns migrated_dns_map_1
  inspect ftp
  inspect h323 h225
  inspect h323 ras
  inspect rsh
  inspect rtsp
  inspect sqlnet
  inspect skinny
  inspect sunrpc
  inspect xdmcp
  inspect netbios
  inspect tftp

policy-map outside-policy
 class voip-outside-class
  priority
policy-map inside-policy
 class voice-inside-class
  priority
!

!Nested policy. Shapes all but VoIP traffic inbound from ISP at 2Mbps.
policy-map ins-policy
 class class-default
  shape average 2000000 8192
  service-policy inside-policy

!Nested policy. Shapes all but VoIP traffic outbound to ISP at 2Mbps.

policy-map out-policy
 class class-default
  shape average 2000000 8192
  service-policy outside-policy
!
service-policy global_policy global
service-policy ins-policy interface inside
service-policy out-policy interface outside

This will protect those sensitive real time packets in both directions but remember the bandwidth sacrifice!

Cisco SG300 or SF300 Procedure to Change from Layer2 to Layer3

2012-09-28T12:31:00.001-07:00

This process will default any configurations you already have on the switch so you want to take a copy of the config first.

Connect with the serial cable to the Console port.

Set your serial port speed to 115200

Login:

username=cisco
password=cisco

The above are default values.

Run the following command at the prompt:

#menu

This will bring up the Switch Main Menu

Select -> System Mode -> Edit ->Hit Spacebar to toggle mode from Layer 2 to Layer 3 -> Save

*sometimes, depending on your terminal emulation, you may not be able to get to the 'Save' option. Hit Esc, when you are at the top most parameter.

Your switch will reboot after another prompt to which you answer yes.

There will be no IP address when the switch boots up.

Configure an IP address on the default VLAN 1 so you can http to the switch as follows:

Same process as above to bring up the menu, then

System Configuration Menu -> Ip Configuration -> IPv4 Address Configuration ->IPv4 Address Settings -> Edit ->

Enter the IP address for the switch

Eg.

IPv4 Address: 10.16.1.1
Subnet Mask: 255.255.255.0

Save

Now you can connect to any of the ethernet ports and then http://10.16.1.1

Cisco CME with ATA186 using FAX Pass Through mode

2012-08-24T14:27:00.002-07:00

This finally worked after getting a bad ATA the first time round that would not respond to https. The first thing you want to do is point your browser to the ATAs IP address (https://IPAddr/dev) and make the following changes:

I configured ATA with static IP address and disabled TFTP.

Network Parameters
UseTFTP=0
DHCP=0
StaticIP=172.17.100.9
StaticRoute=172.17.100.1
StaticNetMask=255.255.255.0

Audio Parameters
LBRCodec=3
AudioMode=0x00150015
ConnectMode=0x90000404

On the CME I had the fax DID number 5552496501 first get translated to extension 101 using a profile. With the usual suspects of dial-peers and ephones referencing 101, the Fax call is placed to port 1 (determined by the MAC address) of the ATA.

CME Configs
voice service voip
modem passthrough nse codec g711ulaw

voice translation-rule 9
rule 1 /^55522672$..$$/ /1\1/
rule 3 /^5552496501/ /101/ <---Fax number. Translates to 101

voice translation-profile SIP_IN
translate calling 3
translate called 9 <--Incoming SIP calls

tftp-server flash:ATA030203SCCP051201A.zup

dial-peer voice 101 voip
destination-pattern 101
modem passthrough nse codec g711ulaw
session target ipv4:172.17.100.9
codec g711ulaw
fax rate disable
no vad

telephony-service
load ata ATA030203SCCP051201A.zup

ephone-dn 101
number 101

ephone 28
device-security-mode none
mac-address 001D.4595.6401 <--MAC Address of Port 1 on ATA
max-calls-per-button 2
type ata
button 1:101

Cisco 3560X License Update

2012-08-11T10:20:00.001-07:00

We initially received wrong licenses from Cisco to upgrade the feature on our 3560X switches from ipbase to ipservices - we only realize this when we installed the .lic file. This is what we got:

Switch#sh license udi
Device# PID SN UDI
-----------------------------------------------------------------------------
*0 WS-C3560X-48T-S FDO1520P0KG WS-C3560X-48T-S:FDO1520P0KG

A wrongly generated .lic file from Cisco:

Switch#license install flash:FDO1520P0KG_20110622144858347.lic
Installing licenses from "flash:FDO1520P0KG_20110622144858347.lic"
% Error: Install failed. UDI L-C3560X-LIC=:FDO1520P0KG on license does not match any device
0/1 licenses were successfully installed
0/1 licenses were existing licenses
1/1 licenses were failed to install

In order to correct this just send an email to licensing@cisco.com with the PID and UDI to have them correct this. Then install as follows:

Copy the license to the flash and run the license install command.

Switch#copy tftp flash:
Address or name of remote host [10.10.1.200]?
Source filename [FDO1520P0KG_20110622144858347.lic]? FDO1520P0KG_20110622174501853.lic
Destination filename [FDO1520P0KG_20110622174501853.lic]?
Accessing tftp://10.10.1.200/FDO1520P0KG_20110622174501853.lic...
Loading FDO1520P0KG_20110622174501853.lic from 10.10.1.200 (via Vlan1): !
[OK - 1160 bytes]

1160 bytes copied in 8.204 secs (141 bytes/sec)

Switch#license install flash:FDO1520P0KG_20110622174501853.lic
Installing licenses from "flash:FDO1520P0KG_20110622174501853.lic"
Installing...Feature:ipservices...Successful:Supported
1/1 licenses were successfully installed
0/1 licenses were existing licenses
0/1 licenses were failed to install

Switch#
*Mar 1 00:10:29.657: %IOS_LICENSE_IMAGE_APPLICATION-6-LICENSE_LEVEL: Module name = c3560x Next reboot level = ipservices and License = ipservices
*Mar 1 00:10:30.118: %LICENSE-6-INSTALL: Feature ipservices 1.0 was installed in this device. UDI=WS-C3560X-48T-S:FDO1520P0KG; StoreIndex=1:Primary License Storage
Switch#

Switch#sh license feature
Feature name Enforcement Evaluation Clear Allowed Enabled
ipservices yes yes yes yes
ipbase yes no yes no
lanbase no no yes no

Switch#sh license all
License Store: Primary License Storage
StoreIndex: 0 Feature: ipbase Version: 1.0
License Type: Permanent
License State: Active, Not in Use
License Priority: Medium
License Count: Non-Counted

StoreIndex: 1 Feature: ipservices Version: 1.0
License Type: Permanent
License State: Active, In Use
License Priority: Medium
License Count: Non-Counted

License Store: Evaluation License Storage
StoreIndex: 0 Feature: ipservices Version: 1.0
License Type: Evaluation
License State: Inactive
Evaluation total period: 8 weeks 4 days
Evaluation period left: 8 weeks 4 days
License Priority: None
License Count: Non-Counted

Cisco ASA Management over VPN Client

2012-08-11T09:54:00.001-07:00

Here is an example of a working configuration on version 8.4 to manage (via ssh and http or ASDM) a Cisco ASA over a VPN client.

interface GigabitEthernet0/0
nameif untrust
security-level 0
ip address 1.1.5.7 255.255.255.0
!
interface GigabitEthernet0/1
nameif trust
security-level 100
ip address 10.99.18.240 255.255.255.224

ip local pool vpnpool 10.99.81.1-10.99.81.254 mask 255.255.255.0

management-access trust

nat (trust,untrust) source static 10.99.0.0 10.99.0.0 destination static 10.99.81.0 10.99.81.0 route-lookup

ssh 10.99.81.0 255.255.255.0 trust
http 10.99.81.0 255.255.255.0 trust

This allows you to hit the trust interface with ASDM or ssh after you VPN into the Cisco ASA. Note that the 'route-lookup' switch under the nat (exempt) rule is often overlooked!

_k

Multi-Homed ISP using BGP - One Primary, the Other Backup

2012-03-19T16:07:00.001-07:00

If you are using two different ISPs and want to make one the primary (all traffic goes here for inbound and outbound) and the other a backup, the simplest way to achieve this is to use the 'advertise-map' feature in BGP. Remember that you cannot control which ISP the inbound traffic will pick when destined for your IP block when you have 2 ISPs. You will need to prevent the advertisement of your block to the backup ISP until the primary one goes down.

This is what we recently did to get this going at a client. We got tripped up initially with the route and I explain that below.

Our topology is simple. Routers WR1 (primary) and WR2 (backup) each are connected to ISP1 (primary) and ISP2 (backup) respectively with BGP enabled. They are cross connected to each other for the iBGP session on the 172.16.25.0/24 network. Our goal is to have WR2 advertise our IP block n.x.47.0/24 into ISP2 whenever ISP1 fails.

Steps

1. On WR1, advertise a route learned from ISP1 to WR2 (prefix list ROUTES-TO-WR2). Pick the route from the routing table. We were receiving partial routes from ISP1 so this was easy. You could also use the default route in this method even if both ISPs advertise the default route. We picked 99.0.0.0/12.

router bgp

neighbor 172.16.25.2 prefix-list ROUTES-TO-WR2 out

ip prefix-list ROUTES-TO-WR2 seq 10 permit 99.0.0.0/12

2. On WR2, use the advertise-map and non-exist-map to look for this route in the route table. Turns out it also looks in the BGP Table too! Our router map 'NON-EXIST' looks for two conditions - the route 99.0.0.0/12 AND that it was advertised from AT&T (AS=7018). Note that you must look for 7018 as the first AS number in the AS path which has an expression ^7018_

router bgp
neighbor y.z.32.133 advertise-map ADVERTISE non-exist-map NON-EXIST

access-list 47 permit n.x.47.0 0.0.0.255
ip as-path access-list 3 permit ^7018_

route-map NON-EXIST permit 10
match ip address prefix-list ATT-Route
match as-path 3

route-map ADVERTISE permit 10
match ip address 47

3. Here is the condition when ISP1 is working normally

WR1#sh ip bgp nei
BGP neighbor is y.z.32.133, remote AS 14265, external link
Description: TelePacific

Route map for outgoing advertisements is outgoing
Condition-map NON-EXIST, Advertise-map ADVERTISE, status: Withdraw

4. ISP1 goes down, so we lose the route 99.0.0.0/12 (as well as all other routes being advertised by ISP1)

WR1#sh ip bgp nei
BGP neighbor is y.z.32.133, remote AS 14265, external link
Description: TelePacific

Route map for outgoing advertisements is outgoing
Condition-map NON-EXIST, Advertise-map ADVERTISE, status: Advertise

5. Prior to us adding the 'match as-path 3' in the route map NON EXIST, the status would not change to Advertise. We found that WR2 had the route 99.0.0.0/12 in its BGP table even though it got removed from the routing table after ISP1 went down!

WR2#sh ip bgp 99.0.0.0/12
BGP routing table entry for 99.0.0.0/12, version 20658895
Paths: (1 available, best #1, table Default-IP-Routing-Table)
Not advertised to any peer
14265 3549 7018, (received-only)
y.z.32.133 from y.z.32.133 (y.z.224.176)
Origin IGP, localpref 100, valid, external
Community: 934871440

After adding 'match as-path 3' it worked! As you can tell from below that it receives the route with the first (and only) AS # as 7018 from it's iBGP neighbor 172.16.25.1 whereas from y.z.32.133 it has a string of AS#s 14265 3549 7018.

WR2#sh ip bgp 99.0.0.0/12
BGP routing table entry for 99.0.0.0/12, version 20658895
Paths: (2 available, best #1, table Default-IP-Routing-Table)
Not advertised to any peer

7018, (received & used)
172.16.25.1 from 172.16.25.1 (172.16.25.1)
Origin IGP, metric 0, localpref 150, valid, internal, best

14265 3549 7018, (received-only)
y.z.32.133 from y.z.32.133 (y.z.224.176)
Origin IGP, localpref 100, valid, external
Community: 934871440

Configs

WR1

router bgp
no synchronization
no bgp fast-external-fallover
bgp log-neighbor-changes
bgp bestpath as-path ignore
network n.x.47.0 mask 255.255.255.0
neighbor n.m.117.249 remote-as 7018
neighbor n.m.117.249 description AT&T Ethernet Peer
neighbor n.m.117.249 version 4
neighbor n.m.117.249 soft-reconfiguration inbound
neighbor n.m.117.249 route-map incoming in
neighbor n.m.117.249 route-map outgoing out
neighbor 172.16.25.2 remote-as
neighbor 172.16.25.2 description iBGP peer connection to WR2
neighbor 172.16.25.2 update-source Loopback0
neighbor 172.16.25.2 version 4
neighbor 172.16.25.2 next-hop-self
neighbor 172.16.25.2 soft-reconfiguration inbound
neighbor 172.16.25.2 prefix-list ROUTES-TO-WR2 out
no auto-summary
!

ip prefix-list ROUTES-TO-WR2 seq 10 permit 99.0.0.0/12

WR2

router bgp
no synchronization
no bgp fast-external-fallover
bgp log-neighbor-changes
bgp bestpath as-path ignore
network n.x.47.0 mask 255.255.255.0
neighbor y.z.32.133 remote-as 14265
neighbor y.z.32.133 description TelePacific
neighbor y.z.32.133 version 4
neighbor y.z.32.133 soft-reconfiguration inbound
neighbor y.z.32.133 route-map incoming in
neighbor y.z.32.133 route-map outgoing out
neighbor y.z.32.133 advertise-map ADVERTISE non-exist-map NON-EXIST
neighbor 172.16.25.1 remote-as
neighbor 172.16.25.1 description iBGP peer connection to WR1
neighbor 172.16.25.1 update-source Loopback0
neighbor 172.16.25.1 version 4
neighbor 172.16.25.1 next-hop-self
neighbor 172.16.25.1 soft-reconfiguration inbound
neighbor 172.16.25.1 prefix-list DEF-ROUTE out
no auto-summary

access-list 47 permit n.x.47.0 0.0.0.255
ip as-path access-list 3 permit ^7018_

route-map NON-EXIST permit 10
match ip address prefix-list ATT-Route
match as-path 3

route-map ADVERTISE permit 10
match ip address 47

SSL Wildcard Certificate Installation on Cisco ASA 8.x

2012-01-18T17:27:00.000-08:00

After searching high and low for instructions, I finally found this link that was most useful:

http://serverfault.com/questions/32443/any-problems-usinga-godaddy-ssl-certificate-on-a-cisco-asa-firewall

Here is the solution taken from the link above:

I have a GoDaddy (standard, not deluxe) wildcard certificate that I use on my ASA 5510 for ASDM access. ASDM says that "SSL parameters affect both ASDM and SSL VPN access," so if it works for me, it should for you and SSL VPNs.

I did have problems importing a .pem version of my certificate chain. Using a *.pfx (like IIS uses) worked fine.

I grabbed gd_intermediate.crt from https://certs.godaddy.com/Repository.go

In ASDM, Configuration, Device Management, Certificate Management, CA Certificates; click Add, don't change any defaults, install from file, locate the gd_intermediate.crt file.

I also tried loading gd_bundle.crt which some of our certs use and that failed, but since gd_intermediate.crt worked and that's what my wildcard uses, I didn't test any more.

Once the intermediate cert is loaded, go to Identity Certificates (right above CA Certificates) and do something similar (Add, import from file, chose the .pfx file, and enter the password for the .pfx.

Now that the cert is successfully installed, set which interfaces it will be used on. That's under Device Management, Advanced, SSL Settings. Click the interface (probably outside), click Edit, and choose the Trustpoint name of the certificate you added in the last step. Click OK, Apply, and try going to your https://vpn.url and see if it loads the right cert.

Thanks to serverfault.com.

Upgrade Procedure - Cisco Nexus 5000 Switch

2012-01-13T12:14:00.000-08:00

I did this on a Nexus 5548. The process was simple - no quirky issues. Our upgrade went from 9.5.0.3 to 9.5.1.3. I had alread established IP connectivity through the management port.

Remember that the management interface is belongs to the vrf context called "management", by default.

vrf context management
ip route 0.0.0.0/0 10.0.3.251
interface mgmt0
ip address 10.0.1.225/22

Download the relevant files. I downloaded these two:

n5000-uk9-kickstart.5.1.3.N1.1.bin
n5000-uk9.5.1.3.N1.1.bin

Fire up your tftp server. Verify that you have enough space on your bootflash: to hold the new files:

login: admin
Password:
Cisco Nexus Operating System (NX-OS) Software
TAC support: http://www.cisco.com/tac
Copyright (c) 2002-2011, Cisco Systems, Inc. All rights reserved.
The copyrights to certain works contained in this software are
owned by other third parties and used and distributed under
license. Certain components of this software are licensed under
the GNU General Public License (GPL) version 2.0 or the GNU
Lesser General Public License (LGPL) Version 2.1. A copy of each
such license is available at
http://www.opensource.org/licenses/gpl-2.0.php and
http://www.opensource.org/licenses/lgpl-2.1.php

Nexus5548-2# dir
744 Apr 20 02:08:48 2011 license_SSI15100AW7_10.lic
49152 Apr 20 02:11:45 2011 lost+found/
1586 Nov 10 11:47:20 2011 mts.log
25136128 Apr 20 02:01:51 2011 n5000-uk9-kickstart.5.0.3.N1.1b.bin
188700150 Apr 20 02:02:52 2011 n5000-uk9.5.0.3.N1.1b.bin
4096 Jan 01 02:05:55 2009 vdc_2/
4096 Jan 01 02:05:55 2009 vdc_3/
4096 Jan 01 02:05:55 2009 vdc_4/

Usage for bootflash://
331591680 bytes used
1319313408 bytes free
1650905088 bytes total

I had plenty of space. Now tftp the kickstart and image files into the bootflash. Use management as the vrf context!

Nexus5548-2# copy tftp://10.0.1.227/n5000-uk9-kickstart.5.1.3.N1.1.bin bootflash:n5000-uk9-kickstart.5.1.3.N1.1.bin

Enter vrf (If no input, current vrf 'default' is considered): management
Trying to connect to tftp server......
Connection to Server Established.
TFTP get operation was successful

Nexus5548-2# copy tftp://10.0.1.227/n5000-uk9.5.1.3.N1.1.bin bootflash:n5000-uk9.5.1.3.N1.1.bin

Enter vrf (If no input, current vrf 'default' is considered): management
Trying to connect to tftp server......
Connection to Server Established.
TFTP get operation was successful

Run the install command on the kickstart file.

Nexus5548-2# install all kickstart bootflash:n5000-uk9-kickstart.5.1.3.N1.1.bin system bootflash:n5000-uk9.5.1.3.N1.1.bin

Verifying image bootflash:/n5000-uk9-kickstart.5.1.3.N1.1.bin for boot variable "kickstart".
[####################] 100% -- SUCCESS
Verifying image bootflash:/n5000-uk9.5.1.3.N1.1.bin for boot variable "system".
[####################] 100% -- SUCCESS
Verifying image type.
[####################] 100% -- SUCCESS
Extracting "system" version from image bootflash:/n5000-uk9.5.1.3.N1.1.bin.
[####################] 100% -- SUCCESS
Extracting "kickstart" version from image bootflash:/n5000-uk9-kickstart.5.1.3.N1.1.bin.
[####################] 100% -- SUCCESS
Extracting "bios" version from image bootflash:/n5000-uk9.5.1.3.N1.1.bin.
[####################] 100% -- SUCCESS
Performing module support checks.
[####################] 100% -- SUCCESS
Notifying services about system upgrade.
[####################] 100% -- SUCCESS

Compatibility check is done:
Module bootable Impact Install-type Reason
------ -------- -------------- ------------ ------
1 yes disruptive reset Non-disruptive install not supported if L3 was enabled

Images will be upgraded according to following table:
Module Image Running-Version New-Version Upg-Required
------ ---------- ---------------------- ---------------------- ------------
1 system 5.0(3)N1(1b) 5.1(3)N1(1) yes
1 kickstart 5.0(3)N1(1b) 5.1(3)N1(1) yes
1 bios v3.5.0(02/03/2011) v3.5.0(02/03/2011) no
1 SFP-uC v1.0.0.0 v1.0.0.0 no
1 power-seq v1.0 v1.0 no
3 power-seq v5.0 v5.0 no
1 uC v1.2.0.1 v1.2.0.1 no

Switch will be reloaded for disruptive upgrade.

Do you want to continue with the installation (y/n)? [n] y

Install is in progress, please wait.

Performing runtime checks.
[####################] 100% -- SUCCESS
Setting boot variables.
[####################] 100% -- SUCCESS
Performing configuration copy.
[####################] 100%

The switch will reboot. Login again to verify that the you are on the new version.

Nexus 5000 Switch
login: admin
Password:

Cisco Nexus Operating System (NX-OS) Software
TAC support: http://www.cisco.com/tac
Copyright (c) 2002-2011, Cisco Systems, Inc. All rights reserved.
The copyrights to certain works contained in this software are
owned by other third parties and used and distributed under
license. Certain components of this software are licensed under
the GNU General Public License (GPL) version 2.0 or the GNU
Lesser General Public License (LGPL) Version 2.1. A copy of each
such license is available at
http://www.opensource.org/licenses/gpl-2.0.php and
http://www.opensource.org/licenses/lgpl-2.1.php
Nexus5548-2# sh ver
Cisco Nexus Operating System (NX-OS) Software
TAC support: http://www.cisco.com/tac
Documents: http://www.cisco.com/en/US/products/ps9372/tsd_products_support_serie
s_home.html
Copyright (c) 2002-2011, Cisco Systems, Inc. All rights reserved.
The copyrights to certain works contained herein are owned by
other third parties and are used and distributed under license.
Some parts of this software are covered under the GNU Public
License. A copy of the license is available at
http://www.gnu.org/licenses/gpl.html.

Software
BIOS: version 3.5.0
loader: version N/A
kickstart: version 5.1(3)N1(1)
system: version 5.1(3)N1(1)
power-seq: Module 1: version v1.0
uC: version v1.2.0.1
SFP uC: Module 1: v1.0.0.0
BIOS compile time: 02/03/2011
kickstart image file is: bootflash:///n5000-uk9-kickstart.5.1.3.N1.1.bin
kickstart compile time: 12/6/2011 22:00:00 [12/07/2011 06:30:01]
system image file is: bootflash:///n5000-uk9.5.1.3.N1.1.bin
system compile time: 12/6/2011 22:00:00 [12/07/2011 08:09:44]

Hardware
cisco Nexus5548 Chassis ("O2 32X10GE/Modular Universal Platform Supervisor")
Intel(R) Xeon(R) CPU with 8263872 kB of memory.
Processor Board ID JAF1515BBRA

Device name: Nexus5548-2
bootflash: 2007040 kB

Kernel uptime is 0 day(s), 0 hour(s), 3 minute(s), 13 second(s)

Last reset at 720106 usecs after Thu Dec 15 20:15:10 2011

Reason: Disruptive upgrade
System version: 5.0(3)N1(1b)
Service:

plugin
Core Plugin, Ethernet Plugin

Nexus5548-2#

That's it!

WOL Directed Broadcast Configuration on Cisco Layer 3 Switches

2011-04-15T13:22:00.000-07:00

Use directed broadcast to configure the Wake On LAN (WOL) application on Cisco L3 switches. In our case we had the WOL servers connected to VLAN 1 (10.1.20.64 and .65). They are used to wake client computers on all other private VLANs. Here's the working example for our test case with clients on VLAN2:

access-list 180 permit udp host 10.1.20.64 any

access-list 180 permit udp host 10.1.20.65 any

interface Vlan1

ip address 10.1.0.10 255.255.0.0

ip helper-address 10.2.255.255

interface Vlan2

ip address 10.2.0.10 255.255.0.0

ip directed-broadcast 180

Note that the helper address sends the WOL broadcast to all destination subnets that are specified there (in our case to the 10.2.0.0/16 subnet) but you control what lands up on the destination VLAN with the directed broadcast command and an acl. It works if you use a supernet in the helper address command to cover all your destination networks.

Cisco ASA 5500 7.2x to 8.4x upgrade

2011-04-13T11:49:00.000-07:00

I just completed this upgrade on two firewalls and want to share some issues I encountered. Our firewalls were using the following basic features:

IPSEC VPN client
Site to Site IPSEC VPN tunnel
PAT
Static NATs
NAT exempt

Firstly the image boots up and the new asdm works. You should have no concern about the ASA not booting up. In fact I had to do one that was located in a Data Center in Chicago and we were in California!

The known documented issue with the nat exempt command must be taken care of. The keyword unidirectional is added to the nat exempt (nat 0) rule which must be changed to bidirectional for each nat exempt command you have.
Since the new access rules now references the real IPs of translated addresses I found that none of these got changed on my outside access list! I had to change each ACL entry manually from the public address to its private IP address.
There is a site to site IPSEC VPN tunnel built that references a translated IP of a local host in the encryption domain. The conversion process added a nat exempt rule for the encryption domain! This, of course, prevented the local host from being translated when it was trying to connect to the remote host across the tunnel. No match was found and so the tunnel never gets established! I removed that nat exempt rule to fix.

That's it! All the best in your upgrades.

Here is the Cisco reference to the 8.4x release notes.

IOS NAT and VPN

2011-04-04T14:44:00.001-07:00

Building NAT (PAT or Static) on a Cisco router is fairly well documented and works well. However, I got tripped up again with an implementation today where the PAT would work but then the VPN tunnel would go down!

Case Study

My client has a site to site VPN tunnel to Cust2 with 6 remote networks. All local networks (192.168.0.0/21) communicate to the remote nets with their private IPs. In addition, the local networks get PAT'd to 39.100.3.68 when routed over to the Internet. There is one static NAT that only gets translated to 39.100.3.67 when communicating with 206.96.88.115 out on the Internet. In all other cases it will remain as it's real IP of 192.168.0.76.

Here is the configuration that I built. The VPN tunnel and static NAT rule using a route map to achieve our goal worked. However, as soon as I applied the PAT pool and overload translation, the tunnel went down.

crypto isakmp policy 10

encr 3des

authentication pre-share

group 2

crypto isakmp policy 20

encr aes

authentication pre-share

group 2

crypto isakmp key *** address 209.100.166.20

crypto ipsec transform-set 3DES-SHA esp-3des esp-sha-hmac

crypto map vpnmap 10 ipsec-isakmp

set peer 209.100.166.20

set transform-set 3DES-SHA

match address cust2-vpn

interface GigabitEthernet0/0

description to Inside

ip address 192.168.0.8 255.255.255.0

ip nat inside

interface GigabitEthernet0/1

description Internet

ip address 39.105.128.242 255.255.255.252

ip nat outside

crypto map vpnmap

ip nat pool natpool 39.100.3.68 39.100.3.68 netmask 255.255.255.0

ip nat inside source list ins_nat_source pool natpool overload

ip nat inside source static 192.168.0.76 39.100.3.67 route-map nat-exempt extendable

ip access-list extended cust2-vpn

permit ip 192.168.0.0 0.0.7.255 192.168.16.0 0.0.0.255

permit ip 192.168.0.0 0.0.7.255 70.185.0.0 0.0.255.255

permit ip 192.168.0.0 0.0.7.255 200.106.176.0 0.0.7.255

permit ip 192.168.0.0 0.0.7.255 200.106.184.0 0.0.1.255

permit ip 192.168.0.0 0.0.7.255 206.184.246.0 0.0.0.255

permit ip 192.168.0.0 0.0.7.255 208.134.161.0 0.0.0.255

ip access-list extended ins_nat_source

deny ip any 192.168.16.0 0.0.0.255

deny ip any 70.185.0.0 0.0.255.255

deny ip any 200.106.176.0 0.0.7.255

deny ip any 200.106.184.0 0.0.1.255

deny ip any 206.184.246.0 0.0.0.255

deny ip any 208.134.161.0 0.0.0.255

permit ip any any

access-list 110 permit ip host 192.168.0.76 host 206.96.88.115

access-list 110 deny ip host 192.168.0.76 any

route-map nat-exempt permit 1

match ip address 110

The fix is to also include the Internet facing interface into the NAT exempt access rules (ins_nat_source). Even though that interface is on the 'outside', it will get subjected to translation because of the 'permit any any' rule. Here's the fixed access rule:

ip access-list extended ins_nat_source

deny ip any 192.168.16.0 0.0.0.255

deny ip any 70.185.0.0 0.0.255.255

deny ip any 200.106.176.0 0.0.7.255

deny ip any 200.106.184.0 0.0.1.255

deny ip any 206.184.246.0 0.0.0.255

deny ip any 208.134.161.0 0.0.0.255

deny ip host 39.105.128.242 any

permit ip any any

FiOS Cisco PIX ARP Problem Fixed!

2010-08-27T17:56:00.000-07:00

The Problem

When you define a static NAT on the pix you cannot get to route beyond the pix. It appears that some FIOS ONTs send arp requests with a source IP of 0.0.0.0 and the PIX will not send a proxy arp reply for the static entry but will respond itself only (me). I'm using 6.2.2 on the PIX.

In this example my PIX has an outside interface configured with 71.x.x.210. The debug shows that it responds fine.

"debug arp" on the pix shows
arp-in: rqst for me from 0.0.0.0 for 71.x.x.210, on outside
arp-in: generating reply from 71.x.x.210 0013.60ac.bf97 to 0.0.0.0 000e.861c.d518

I have the following static entry configured.

static (inside,outside) 71.x.x.216 192.n.n.1 netmask 255.255.255.255

"debug arp" on the pix shows
arp-in: request at outside from 0.0.0.0 000e.861c.d518 for 71.246.225.216 0013.60ac.bf97

So the PIX knows about the mac address of .216 but it just won't not respond!

Solution or Work around

Upgrade to 8.0.4-32. On the PIX software download page select PIX Interim Releases at the top part of the page...

The PIX now replies to the arp request and everything now works like it should have in the first place!

Upgrading Cisco CUE from 3.1.1 to 7.0.5

2010-08-27T10:05:00.000-07:00

Our current version was at 3.1.1 and we needed to fix the IMAP issue with Entourage by upgrading to 3.2.x but realized I could go all the way to 7.0.x! First login to the CUE and type show software version to check current version and check that your CME version supports by consulting the compatibility matrix. My CME was at 4.1(0) - I was good to go.

Download cue-vm-k9.nm.7.0.5.zip image form here (CCO login required). Ensure you pick the one that is appropriate for your hardware. I had an NM-CUE. Extract all files into a folder onto your FTP server. I also downloaded the language pack for the US separately and place this onto the FTP server too. At some point during the installation you will be asked to select the language and for some reason the install fails when it does not see that language file on your server.

You will need an FTP server to upgrade the CUE - I did a clean install. Once sessioned into the CUE you can follow these detailed steps but here is a quick summary.

Backup all your files on the CUE (this is really important for a clean install). See below for instructions.
Verify connectivity to your FTP server.
Execute command on CUE: software download clean url ftp://192.168.1.1/cue-vm-k9.nm.3.2.4.pkg username xxx password yyy
Check status: software download status
Now install the software just downloaded: software install clean cue-vm-k9.nm.7.0.5.pkg
The system will reload after the upgrade completes.
Check new version: show software version
Restore the files from your backup server. I have the detailed steps listed below.

If you picked the wrong version of the software you will get this error message below. I downloaded the nme version during my first attempt!

WARNING:: This command will download the necessary software to
WARNING:: complete an upgrade. It is recommended that a backup be done
WARNING:: before installing software.

WARNING:: The system will briefly be brought to an offline state
WARNING:: This will terminate any active call and prevent new calls
WARNING:: from being processed.

Would you like to continue? [n] y

Downloading ftp cue-vm-k9.nme.7.0.5.pkg
Bytes downloaded : 179928

Validating package signature ... done

Downloading ftp cue-vm-installer-k9.nme.7.0.5.prt1
Bytes downloaded : 127198

Installer does not recognize package file format.
Attempting to upgrade installer...
starting_phase:
install-files.sh /dwnld/pkgdata/.installer_wo
add_file /dwnld/pkgdata/cue-vm-installer-k9.nme.7.0.5.prt1 1 / tgz
Installer upgrade successful
Restarting install process...
Validating package signature ... done
Validating installed manifests .............complete.
- Parsing package manifest files... complete.
- Checking Package dependencies... Service Engine Bootloader can not be installed on this platform/chassis combination.

CUE Backup Procedure

Config t on the CUE
Configure the backup server with backup server url ftp://192.168.1.1/temp/ username xxx password yyy
Verify with show backup server
Go into offline mode - offline
Do the back up. I normally get all the files - backup category all
Exit offline mode - continue

CUE Restore Procedure

show backup server will identify the backup ID number. Take note of this.

Go into offline mode - offline

Restore the files (my id number was 1) - restore id 1 category all

reload

Low Latency Queueing QoS on an MPLS Router with a Rate Limited Circuit

2009-04-07T17:41:00.001-07:00

In a WAN architecture where routers have MPLS circuits with full bandwidth available, deploying LLQ on the WAN interface is simple as given in the example below. Here we classify the voice traffic with the ACL 140 and mark its precedence to 5 before leaving the serial interface. In addition, during times of congestion on Serial1/0, up to 1Mbps will be reserved for the voice traffic. The priority keyword ensures that this bandwidth is reserved and also ensures that the voice queue is processed before any other queue (up to 1Mbps). All other traffic will fall in a default class which follows the WFQ mechanism for QoS on the interface.

class-map match-all voice
  match access-group 110
policy-map privport-policy
  class voice
  set ip precedence 5
  priority 1000

interface Serial1/0
  ip address 10.22.13.1 255.255.255.252
  service-policy output privport-policy

access-list 110 remark Voice
access-list 110 permit ip host 10.10.1.15 host 10.20.1.15

This example is fairly straight forward and takes care of very simple applications that require voice and data transported over private WANs - whether these are private leased lines or MPLS circuits. Unfortunately, this method cannot be used when the circuit is rate limited. For example you have purchased a DS3 circuit (45Mbps) but are contracted to use just 6Mbps of that circuit. Common networking practice recommends policing the egress traffic at 6Mbps using CAR (Committed Access Rate), which rate limits the traffic to 6Mbps. Fair enough. The next logical step is to then apply LLQ policy (as depicted above) to the interface. Wrong! Recall that the rate limiting mechanism, although has some controls, is impartial as to what traffic it drops whenever the traffic exceeds the configured rate. This is a problem for any real time traffic, whether voice or video and the consequence is fairly obvious.

So how do we overcome this dilemma? The solution - use the Child Service Policy.

In our example we have a full DS3 that must be limited to 6Mbps. This implies that the total outbound traffic cannot exceed 6Mbps. In addition, prioritize voice for 1Mbps and in the absence of voice, data should be able to use available bandwidth up to 6mbps. The configuration below solves this problem.

class-map match-all voicesignal
  match access-group 120
class-map match-all voice
  match ip rtp 16384 16383

policy-map child-policy
  class voice
  priority 1000
  set precedence 5
class voicesignal
  bandwidth 100

policy-map parent-policy
class class-default
shape average 6000000
service-policy child-policy

interface Serial1/0
  ip address 10.71.28.138 255.255.255.252
  dsu bandwidth 44210
  service-policy output parent-policy

access-list 120 permit tcp any any eq 2000
access-list 120 permit tcp any eq 2000 any
access-list 120 permit udp any any eq 2000
access-list 120 permit udp any eq 2000 any

we first classified the voice packets into two parts - voice packets (uses rtp protocol) and the voice signaling packets (SCCP - Skinny Call Control Protocol). Yeah, you guessed it, we are using Cisco Call Manager! These packets are then mapped into a policy called 'child-policy' which gives priority to voice and reserves up to 1Mbps for it during times of congistion. At the same time, 100Kbps of bandwidth is reserved for the signaling packets so that other traffic cannot 'bump' these packets when congestion occurs.

The 'parent-policy' is shaped at 6Mbps and calls on the child-policy in a nested fashion. Think of the parent-policy as an interface running at 6Mbps and you are applying an LLQ policy to it just like in our first example above. The voice and data (default class) gets nicely queued up based on the policy before it hits the actual interface where the 'parent-policy' is applied.

VLAN Filters Not Working On Cisco Catalyst 6000 with MSFC

2009-04-02T13:17:00.000-07:00

What I thought was going to be a simple 5 minute procedure ended up taking 3 hours! My goal was very simple - add some security amongst a set of VLANs on a Cisco 6000 (CatOS 7-6-17) switch based on the following requirements:

-VLAN 30 cannot initiate connections to VLAN 50 and VLAN 60 but must get to the Internet
-VLAN 50, is the Admin VLAN and can get to everything
-VLAN 60 cannot initiate connections to VLAN 50 and VLAN 30 but must get to the Internet

Piece of cake, right? I quickly define the filters on the MSFC, deciding, as it should be to place the filters closest to the initiating traffic on VLANs 30 and 60 and have no filters on VLAN 50. The configuration turned out to be like this:

interface Vlan30
description Corp VLAN
ip address 10.30.0.2 255.255.0.0
ip access-group 130 in
!
interface Vlan500
description Admin VLAN
ip address 10.50.0.2 255.255.0.0

!
interface Vlan600
description Test VLAN
ip address 10.60.0.2 255.255.0.0
ip access-group 160 in

ip route 0.0.0.0 0.0.0.0 10.30.0.11

access-list 130 permit tcp any any established
access-list 130 deny ip 10.30.0.0 0.0.255.255 10.50.0.0 0.0.255.255
access-list 130 deny ip 10.30.0.0 0.0.255.255 10.60.0.0 0.0.255.255
access-list 130 permit ip any any

access-list 160 permit tcp any any established
access-list 160 deny ip any 10.50.0.0 0.0.255.255
access-list 160 deny ip any 10.30.0.0 0.0.255.255
access-list 160 permit ip any any

We begin testing this and yay, the traffic from VLAN 30 to 50 is blocked and....then... wait a minute now it's not blocked. I check the hit counter on ACL 130 and there were a couple denies from 10.30.0.0/16 to 10.60.0.0/16 but nothing more. What's going on here? We test from VLAN 30 to VLAN 50 and then from VLAN 60 to both VLAN 30 and VLAN 50 - the same result. The first packet observe the filter rules but thereafter access to each VLAN from any other VLAN is wide open. Grrrr!

At this point I know that my filters are good - there's no rocket science to setting these so I figured that it must be beyond just the filter that was causing this. The clue that led me to the solution was the result of a trace route from a source device (10.30.0.20) to 10.60.0.20. The icmp packet got there in just one hop! Now I expected the VLAN interface hop first before getting to the destination. This wreaked of a cached entry somewhere. But, how did it bypass the Layer 3 routing functionality or...did it? And then it hit me! My theories of Multilayer Switching (MLS) came flooding back and I remembered how the switch consults the router for the initial routing of the packet (Router on a Stick) and then caches the Layer 3 entry in the switch itself for subsequent routing of the paket (Layer3 switching). Of course!

Remember, I had not worked on a Cisco 6000 switch for years so I had to do some digging and found that MLS is enabled by default on this switch (with an MSFC of course). To disable it, merely add the 'no ip mls' command to each VLAN interface. So for VLAN30 it looked like this:

interface Vlan30
description Corp VLAN
ip address 10.30.0.2 255.255.0.0
ip access-group 130 in
no ip mls

I did this on all three layer 3 interfaces and the filters are now doing the work it was supposed to. You can clear the MLS cache by issuing clear mls on the switch itself.

Switch Details

WS-C6009 Software, Version NmpSW: 7.6(17)
System Bootstrap Version: 5.3(1)
System Boot Image File is 'bootflash:cat6000-supk8.7-6-17.bin'

Modules:

WS-X6K-SUP1A-2GE
WS-F6K-PFC
WS-F6K-MSFC2

MSFC:

ROM: System Bootstrap, Version 12.1(3r)E2, RELEASE SOFTWARE (fc1)
BOOTLDR: MSFC2 Software (C6MSFC2-BOOT-M), Version 12.1(8b)E9, EARLY DEPLOYMENT RELEASE SOFTWARE (fc3)

cisco Cat6k-MSFC2 (R7000) processor with 458752K/65536K bytes of memory.
Processor board ID SAD04450FV5

These Cisco ASA VPN Filters Could Trip You Up!

2009-03-26T16:57:00.000-07:00

This filter put a little twist into my powers of reasoning but I finally figured it out.

In our example, a Cisco ASA 5510 is serving as a VPN concentrator to which we have built a LAN to LAN IPSEC Tunnel from a customer peer (192.168.103.41). Basically, a host on the customer end (192.168.48.130) transfers files over the NDM protocol (tcp/1364) to our server (10.122.52.12) and sometimes our server (10.122.52.12) has to do the same to their server.

Summary of traffic over the tunnel:

192.168.48.130 --> 10.122.52.12 (tcp/1364)
10.122.52.12 --> 192.168.48.130(tcp/1364)

Our aim is to build the VPN tunnel when traffic between the two servers is present but limit the traffic to just the NDM protocol.

Configuration Steps

1. First you want the VPN traffic to bypass the filter you have on the interface that the tunnel terminates because we don't want another filter for this traffic. In our case this is the 'untrust' interface. Use this command:

sysopt connection permit-vpn

2. Now define the encryption domain for the tunnel and the Phase 1 (ISAKMP) and Phase 2 (IPSEC) parameters. Whenever, the ASA 'sees' this traffic, it will start the process of bringing up the VPN tunnel.

access-list kis1-vpn-traffic line 1 extended permit ip host 10.122.52.12 host 192.168.48.130

crypto ipsec transform-set ESP-3DES-SHA esp-3des esp-sha-hmac

crypto map untrust_map 10 match address kis1-vpn-traffic
crypto map untrust_map 10 set peer 192.168.103.41
crypto map untrust_map 10 set transform-set ESP-3DES-SHA
crypto map untrust_map 10 set security-association lifetime seconds 28800
crypto map untrust_map 10 set security-association lifetime kilobytes 4608000
crypto map untrust_map interface untrust

crypto isakmp identity address
crypto isakmp enable untrust
crypto isakmp policy 10
authentication pre-share
encryption 3des
hash sha
group 2
lifetime 86400
3. With code 7.x on, you need to define tunnel group parameters first before the IPSEC tunnel will establish. This is where you define the pre-shared key and the filter that acts on the traffic within this tunnel

access-list kis1-vpn-filter line 1 extended permit tcp host 192.168.48.130 eq 1364 host 10.122.52.12
access-list kis1-vpn-filter line 2 extended permit tcp host 192.168.48.130 host 10.122.52.12 eq 1364

group-policy kis1-group-policy internal
group-policy kis1-group-policy attributes
vpn-filter value kis1-vpn-filter

tunnel-group 192.168.103.41 type ipsec-l2l
tunnel-group 192.168.103.41 general-attributes
default-group-policy kis1-group-policy

tunnel-group 192.168.103.41 ipsec-attributes
pre-shared-key *
4. Now let's take a closer look at the filter 'kis1-vpn-filter'. It has the familiar format where in this case, the source address is the far end address (customer host), while the destination address is the local host (10.122.52.12). Line 2 is very logical - it is allowing their host (192.168.48.130) to send traffic to our host (10.122.52.12) on tcp/1364. Nothing wrong here.

The confusion arrives in Line 1. This line permits the local host to send traffic to their host on tcp/1364! So it appears that the filter does not act on the traffic leaving the local host to the remote host, but acts on the return traffic only. Without this you will not make a connection from your local host to the remote host. Seems easy now... :o)

How to Configure RSPAN on Catalyst 6500 IOS Switches

2009-03-26T16:04:00.000-07:00

In our example we have two Cat switches (SWa and SWb). We have a packet sniffer connected to SWa interface F5/15 and want to monitor all the traffic going in and out of interface F3/1 of SWb.

Steps

1. Both switches must be trunked together.

2. Create an RSPAN VLAN. Preferably on the switch with VTP in server mode. Pick a VLAN ID that it is not being used currently. eg 999. If you do not have VTP, just create the VLAN on both switches.

Router(config)# vlan 999
Router(config-vlan)#remote-span

3. Create an RSPAN source session on SWb. This is the traffic you want to capture. The session number can be any integer that's not being used for other sessions. All traffic (tx and rx by default) from F3/1 now gets copied onto VLAN 999

Router(config)# monitor session 2 source interface f3/1
Router(config)# monitor session 2 destination remote vlan 999

4. Create the RSPAN destination session on SWa.This session need not have the same session ID as the one on SWb.

Router(config)#monitor session 8 source remote vlan 999
Router(config)#monitor session 8 destination interface f5/15

5. And that's it! You can obviously expand to monitor source VLANs, multiple interfaces etc. The source session describe in step 3 works even if it is configured on the same switch as the destination session - but then it's technically not RSPAN!

6. Here's a network management tip. Have your packet sniffer connected permanently to an interface on the switch and set up that interface as the destination session. So whenever the need arises to monitor packets on any interface, vlan etc., all you've got to do is configure the source session. This way you will save loads of unnecessary time trying to figure out which interface your sniffer was plugged into! And, always remember to label the interfaces with the description command.