Tuesday, March 12, 2013

Cisco ASA QoS For VoIP

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!

Friday, September 28, 2012

Cisco SG300 or SF300 Procedure to Change from Layer2 to Layer3


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



Friday, August 24, 2012

Cisco CME with ATA186 using FAX Pass Through mode


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

Saturday, August 11, 2012

Cisco 3560X License Update

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

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

Monday, March 19, 2012

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

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

Wednesday, January 18, 2012

SSL Wildcard Certificate Installation on Cisco ASA 8.x

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.