Sunday, December 23, 2012

CUCM 9.1 gives us a little christmas present

Native paging is now included in CUCM 9.1 using informacast (which is a good product I have used it myself :)



Paging

Now included with Unified Communications Manager is the Singlewire InformaCast product that provides paging capabilities for users to make point-to-point, or group pages, to and from Cisco IP Phones. The software and documentation for the InformaCast product is on a separate DVD included with the purchase of Unified Communications Manager. It is also available online as a software download on cisco.com.
The InformaCast product is divided into two categories, basic and advanced functionality. The basic paging features allow paging between Cisco IP Phones to groups and zones that the administrator configures. An unlimited number of groups is possible but with a maximum of 50 users total in each group in basic paging. Basic paging is provided as a new Unified Communications Manager feature at no cost. If there is a requirement for more than 50 users in a single group or for higher level capabilities, the advanced features of InformaCast are required and are highly recommended.
The advanced features of InformaCast include:
  • Paging and Emergency Notification to All Users
  • Paging to Overhead Analog and IP Speakers
  • Bell Scheduling
  • Prioritizing Emergency Notifications with Call Barge Option
  • Pre-Recorded and Text only pages
  • Integration with Social Media Sites for Notification
  • Email and SMS Mass Notification
  • Call Number Monitoring - 911 Alerting
  • Integration with Jabber clients
There are numerous additional features of Advanced Paging. To determine if Advanced Paging/Notification is appropriate for the end user's Unified Communications Manager deployment, there is a 60 day trial of the advanced functionality to evaluate the higher level features. After installation of the software, there is an option to begin the demonstration period for full access to all capabilities. To retain Advanced Functionality after trial or if this functionality is required at the time of the Unified Communications Manager purchase, the Advanced Paging/Notification functionality can be purchased as a perpetual license from SolutionsPlus or as a subscription directly from Singlewire. For more information on the product's capabilities or for sales questions, contact Singlewire or refer to the documentation and support information included with the product.
 
 
 

Saturday, November 24, 2012

Sorry about that guys, problems with one of my scripts

You may have seen something like the following email from my blog:

"

Sophos Email Appliance (an automated content monitoring gateway) has not delivered the following message:

   Message: 50B0B25A_24955_11277_1
   To:      peter_revill@data3.com.au
   Subject: [Peter's CCIE Musings and Rants (now in colour!)] Google doesn't seem  to like my analytics

This is due to automatic rules that have determined that the message contains at least one potentially dangerous attachment.

If you were not expecting this message, please contact 3V7KwUAgLDAoxy-1ozv8lvyqqo1.mywzo3o1_1o5svvnk3kD.myw.k4@blogger.bounces.google.com
to confirm the message was legitimate.

If you believe the message was business related please reply to this email (including this original body section) and request that the message be released.
If no contact is made within 5 days the message will automatically be deleted."


Sorry about that i had some java script in my templates that blogger.com didn't like for some reason (even though it was just google analytics code)
 

Google doesn't seem to like my analytics

Test I think blogger.com has an outage..

Sunday, November 18, 2012

Help recover a stranded LWAPP or CAPWAP AP

We have all been there.. You've just performed an upgrade on a remote access point (AP) from autonomous to CAPWAP/LWAPP in the middle of nowhere. You have your DHCP Server setup with option 43 (or, alternatively, you have your DNS entry setup correctly.)

You patiently wait for your AP to reboot... Great you can see it via CDP it's running the new image... Phew mission accomplished!

Login to my controller... That's odd... I can't see the access point...

Your heart starts beating as you perform show cdp neighbor and notice the address appears to be static, your sweating increases as you notice the domain-name configured on the access point is all wrong! AP44442.cisco.com? What the heck!

The phone starts ringing! It's the remote users at the middle-of-nowhere camp, the wireless has gone down they say, the social internet is now down and the campers are very unhappy!!!

You cross your fingers and hope you can find someone with a console cable... No! No one down there has a console cable!

Fear not! you are NOT stuck, there is a way to recover from this situation!

As you probably know the process an access point takes to select a controller is:

  • Local Broadcast
  • Option 43
  • DNS
  • Previously known
  • Over the air
  • Statically configured

In our example we can't use option 43 because it's not DHCP, the domain-name is wrong so DNS won't work, there are no previously known WLC's since this is a new AP and we can't do over the air as this is the only AP available!

 The secret is the use of Local Broadcast!

All you need to do is go to the layer 3 interface that the AP is sitting on, and configure the following:

conf t

(config)# ip forward-protocol udp 5246

(config)# ip forward-protocol udp 12223
(config)#int #IntForLocalAPSubnet
(config-int)#ip helper-address #WirelessLanControllerIPAddress#


What the config above does is forward any UDP traffic destined to port 5246 (CAPWAP) or 12223 (LWAPP) on the broadcast address (255.255.255.255) to your WLC! Your tricking the access point into thinking the WLC is local, after which it will join and all will be right with the world!

Quickly you add this option to your Layer 3 interface.. you return to the wlc.... YES! the access point is in the downloading run state downloading the latest image from the WLC. Your heart rate returns to it's healthy, caffeine addicted levels.

I hope you guys found this helpful, I could have used it last week! I actually ran into this information completely by accident when reading a CCIE Wireless book, the book has lots of great hints and tips, please take a look and if you like it and enjoyed this blog please purchase the book through this link Thanks so much :)

Kindle Version:
Physical Version:

Saturday, November 17, 2012

Cisco WAAS with SSL Acceleration and RDP

Hi Guys!

Another blog post on my favorite Cisco Product, Cisco WAAS.  We are going to go through how to accelerate SSL and RDP Traffic with the full levels of optimization (TFO, LZ and DRE)

By default, SSL and RDP are only TCP Flow Optimized, this is because SSL is obviously encrypted, so compression and DRE is not going to work on encrypted traffic flow, and RDP is also encrypted and compressed by Microsoft.

Both SSL and RDP have many things to gain by being accelerated by Cisco WAAS: SSL is just HTTP traffic that is encrypted, and HTTP Traffic is accelerated extremely well. Therefore it makes total sense to take advantage of this. Microsoft RDP is a bit more complicated as it already has some compression being done by Microsoft, but the Cisco Compression algorithims are superior so you are better off using it.

First let's discuss SSL acceleration

The way the WAAS works with SSL is rather than presenting it's own certificate to your end user applications when they visit https webpages etc, it requires the private key from the conversation so that it can intercept the traffic and perform acceleration in this way. This means that you need to tell WAAS what TCP Conversations are using SSL encryption.

RDP requires you to configure some settings on the Microsoft server to disable certain encryption and to disable compression on the client side.


Let's get to it!

SSL Acceleration
Important Note: When using SSL Acceleration, Disk-Based encryption for your WAAS is highly recommended but not mandatory.  It is highly recommended due to the fact that you may potentially be storing secure information on the unencrypted DRE cache, so if your a security-sensitive organization you should keep this in mind. Disk Based Encryption will be covered in another blog post.


First Step: find a service running https, in my example I am going to use my vCENTER server which runs on port 443.

Second Step: you need to export the private and public certificate from the server, in my case for VMWARE it was very easy, I simply navigated to the following directory:

"C:\Users\All Users\VMware\VMware VirtualCenter\SSL"

In this directory i found the .crt file and also the .key file that made up my certificate.


-----BEGIN CERTIFICATE-----
MIIDqTCCApGgAwIBAgIEIE5yBDANBgkqhkiG9w0BAQUFADBrMRUwEwYDVQQKEwxW
 <--- -="-" ommited="ommited" output="output">
CBFADwAvKWhk5FUXxRzlvstq4gldvHZJcXiBLOI=
-----END CERTIFICATE-----




Certificates come in a variety of formats, and so too do the private keys, I found that as long as my private key began with:

----- BEGIN RSA PRIVATE KEY ----

That this certificate worked for me, so let's go ahead and import the certificates


Third Step:
Login to WAAS. then go to Device Groups, I like to configure everything from device groups ALLWAASGROUP because it configures all devices at the same time (Depending on your group membership configuration)


Click on configure - SSL Accelerated Services, then click create:

Go ahead and give the service a name, Click the In service button and most importantly, enter in a list of servers and Ports (either as IP Addresses or hostnames) that use the certificate your about to import, if you have multiple servers using the same certificate (such as a web server farm) then you can enter in multiple addresses here to save time on your configuration.

So you basically need 1 SSL Service for every seperate certificate you might have.





Here is an example of multiple servers entered in:






You can also see that the port numbers are entered, so be sure to include any ports your server might use.


Next, you import the certificates, I find it easiest to simply open the certificates in notepad and copy/paste the contents of the private key and the certificate, as per the example below:

Click on "import existing certificate and optionally private key"  then select "Paste certificate and key in PEM-format"

From here you can copy-paste in your certificates:






 Remember that you want the key to begin with:

--- BEGIN RSA PRIVATE KEY ----



Otherwise you may receive this error message:







When you try and import the key.

Click import to import the certificate, if you have a valid cert you will see its detailed reflected as per the example below:



Now click Submit in the right hand corner to save your settings.

Only one more easy step to go!


Under ALLWAASGROUP (where you are at the moment), go to configure - Peering Service



Ensure that "Enable Certificate Verification" is UNCHECKED, and SSL Version is set to ALL (just incase your certificates use a particular type of SSL).

The enable certificate verification is used when two WAAS peers attempt to talk to each other via SSL. Unchecking this box ensures that the self-signed certs that each of the WAAS peers has by default is accepted as valid. If you wanted to you could configure a proper SSL trust relationship between the actual WAAS peers but this is beyond the scope of this article. Thus for now to get SSL Acceleration working great we simply un-check this option.

Now if you browse to your SSL Webpage we added as an SSL accelerated service in our WAAS, and go to a WAAS and view the "connection statistics" you should notice the traffic is accelerated:





Success! We can see that SSL Traffic is accelerated! Hooray!

 The next step is now RDP traffic.



RDP Traffic


For RDP Traffic, the first thing we need to do is disable encryption of everything but the login traffic on the RDP Server, to do this, you can edit the registery setting manually or you can copy-paste the below into a .reg file and run it on your Windows Terminal Server


Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp]
"SecurityLayer"=dword:00000000


Once this is done, you will need to restart the terminal server.

Next, go to your RDP Client and enter in the details but DON'T connect just yet.

Expand the options section and click "save" to save the connection as an RDP File.




Open the file in notepad and change the line:
compression:i:1

to

compression:i:0

This will disable the inbuilt compression on RDP.

Next, we need to go back to WAAS to enable the Remote Desktop Service to have full optimization.

Login to Cisco WAAS and go to ALLWAASGROUP again under "Device groups"

Click on Configure - Optimization Policies

This will present a heck of a lot of options, so use the quick filter button on the right to narrow down the policies

Enter in the port 3389 and you will see the policies narrowed down






click the checkbox next to the policy and click edit.

Change the action to full optimization (TFO with DRE Bidirectional and LZ)




Click OK


Go to your connection statistics page under monitor for one of your WAAS Devices and you will notice that the acceleration has now taken affect!








That is all there is to it!

I hope you found this useful guys, Cisco WAAS is my favorite Cisco product along with Cisco UCS and I can't recommend it enough.

For a great book on Cisco WAAS, check out:


Please use this link to purchase the book if you enjoyed my tutorial :).


Just one more thing guys, this is really more for me but you might find it useful, if for some reason you accidently connect to a server without turning compression off, or you don't turn the encryption off, the WAN accelerator still tries to accelerate but it is not effective because the traffic is encrypted/compressed. But you won't have any adverse effects.