Tomasz Wendlandt

UCCX 8 Licensing

juggler — Mon, 10 Jan 2011 12:49:38 +0000

W UCCX 8 Cisco zmieni�o model licencjonowania. W nowej wersji licencja jest przypisana do node’a i generowana na podstawie kilku konfigurowalnych (sic!) parametr�w – Time zone, NTP Server, Hostname itp. A wszystko po to by doda� wsparcie dla VMware. Szczeg�y poni�ej:

One of the big changes in the 8.x version is the licensing model, as it changed from a non node locked license to a node locked license schema. In the old versions of UCCX the license was not dependant on the hardware of software configuration, so basically you were able to use any license on any server without any issue. But in this new version the license gets associated to something we call now ‘License MAC’, which is a 12 digit HEX value created by hashing a great deal of parameters that you configure on the server, including: Time zone, NTP Server 1 (or ‘none’), NIC speed (or ‘auto’), Hostname, IP Address, IP Mask, Gateway Address, Primary DNS, SMTP Server (or ‘none’), Certificate Information (Organization, Unit, Location, State, Country), etc. If there’s a change on any of these parameters, the License MAC also changes and you will need to request a re-host license to the Cisco licensing team in no more than 30 days.

�r�d�o

Cisco Unified Communications Manager Software Compatibility Matrix

juggler — Mon, 10 Jan 2011 11:56:52 +0000

Cisco Unified Communications Manager Software Compatibility Matrix

Cisco Unified SRST 8.0 Supported Firmware, Platforms, Memory, and Voice Products

Cisco Unified Communications System Release Summary Matrix for IP Telephony

Transparent spreading of incoming network traffic load across CPUs

juggler — Sun, 10 Oct 2010 17:03:02 +0000

Ciekawy ficzer w kernelu 2.6.35.

Network cards have improved the bandwidth to the point where it’s hard for a single modern CPU to keep up. Two new features contributed by Google aim to spread the load of network handling across the CPUs available in the system: Receive Packet Steering (RPS) and Receive Flow Steering (RFS).

RPS distributes the load of received packet processing across multiple CPUs. This solution allows protocol processing (e.g. IP and TCP) to be performed on packets in parallel (contrary to the previous code). For each device (or each receive queue in a multi-queue device) a hashing of the packet header is used to index into a mask of CPUs (which can be configured manually in /sys/class/net//queues/rx-/rps_cpus) and decide which CPU will be used to process a packet. But there’re also some heuristics provided by the RFS side of this feature. Instead of randomly choosing the CPU from a hash, RFS tries to use the CPU where the application running the recvmsg() syscall is running or has run in the past, to improve cache utilization. Hardware hashing is used if available. This feature effectively emulates what a multi-queue NIC can provide, but instead it is implement in software and for all kind of network hardware, including single queue cards and not excluding multiqueue cards.

Benchmarks of 500 instances of netperf TCP_RR test with 1 byte request and response show the potential benefit of this feature, a e1000e network card on 8 core Intel server goes from 104K tps at 30% CPU usage, to 303K tps at 61% CPU usage when using RPS+RFS. A RPC test which is similar in structure to the netperf RR test with 100 threads on each host, but doing more work in userspace that netperf, goes from 103K tps at 48% of CPU utilization to 223K at 73% CPU utilization and much lower latency.

Wi�cej o RPS i RFS:
http://lwn.net/Articles/362339/
http://lwn.net/Articles/362339/
http://www.kernel.org/pub/linux/kernel/v2.6/ChangeLog-2.6.35

�r�d�o

Unicast mac flooding on Catalyst 6500

juggler — Fri, 08 Oct 2010 21:42:28 +0000

W architekturze 6500 przy zastosowaniu DFC nast�puje rozproszone przetwarzanie ramek (distributed switching). W takiej kofiguracji ka�da karta liniowa ma w�asn� tablice CAM. Co w praktyce oznacza, �e ka�da karta z DFC uczy si� MAC�w niezale�nie i przechowuje je w tablicy przez okre�lony czas (aging time). Naturalne jest w�wczas, �e Supervisor nie widzi ruchu dla danego MAC adresu, poniewa� ruch ten zostanie wys�any z pomini�ciem Supervisora (bezpo�rednio przez kart� liniow�), a poniewa� przez d�u�szy czas Supervisor nie b�dzie widzia� ruchu do danego MACa, zostanie on usuni�ty z jego tablicy CAM.

Co si� dzieje dalej? Ponownie przychodzi ruch dla danego MACa, ale poniewa� inne karty w chassis nie maj� go w CAMie ruch ten jest wysy�any do wszystkich kart. W efekcie widzimy unicast flooding w ramach jednego vlanu. Jak mo�na rozwi�za� taki problem? Nale�y w��czy� synchronizacj� tablic MAC adres�w DFC z PFC Supervisora oraz opcjonalnie wyd�u�y� czas aging-time:

(config)#mac-address-table synchronize
(config)#mac-address-table aging-time 900

#sh mac address-table address 0014.0000.aabb all
Legend: * - primary entry
        age - seconds since last seen
        n/a - not available

  vlan   mac address     type    learn     age              ports
------+----------------+--------+-----+----------+--------------------------
Module 2[FE 1]:
   10  0014.0000.aabb   dynamic  Yes        180   Gi9/21
Module 2[FE 2]:
   10  0014.0000.aabb   dynamic  Yes        180   Gi9/21
Module 3[FE 1]:
   10  0014.0000.aabb   dynamic  Yes        145   Gi9/21
Module 3[FE 2]:
   10  0014.0000.aabb   dynamic  Yes        145   Gi9/21
Module 4[FE 1]:
   10  0014.0000.aabb   dynamic  Yes        180   Gi9/21
Module 4[FE 2]:
   10  0014.0000.aabb   dynamic  Yes        180   Gi9/21
Active Supervisor:
   10  0014.0000.aabb   dynamic  Yes         15   Gi9/21
Module 7[FE 1]:
   10  0014.0000.aabb   dynamic  Yes         20   Gi9/21
Module 7[FE 2]:
   10  0014.0000.aabb   dynamic  Yes         20   Gi9/21
Module 8[FE 1]:
   10  0014.0000.aabb   dynamic  Yes        170   Gi9/21
Module 8[FE 2]:
   10  0014.0000.aabb   dynamic  Yes        170   Gi9/21
Module 9[FE 1]:
*  10  0014.0000.aabb   dynamic  Yes         15   Gi9/21
Module 9[FE 2]:
*  10  0014.0000.aabb   dynamic  Yes        180   Gi9/21


#sh mac address-table synchronize statistics

MAC Entry Out-of-band Synchronization Feature Statistics:
---------------------------------------------------------

    Module [2]
    -----------

    Module Status:
Statistics collected from module                    :  2
Number of L2 asics in this module                   :  2

    Global Status:
Status of feature enabled on the switch             :  on
Default activity time                               :  160
Configured current activity time                    :  160

    Statistics from ASIC 0 when last activity timer expired:
Age value in seconds from age byte register         :  0x3D
Current activity interval start time for seconds    :  0x20
Current activity interval end time for seconds      :  0x40
Current inactive interval start time for seconds    :  0x0
Current inactive interval end time for seconds      :  0x20
Age value in minutes from age byte register         :  0x2F
Current activity interval start time for minutes    :  0x2C
Current activity interval end time for minutes      :  0x2F
Current inactive interval start time for minutes    :  0x29
Current inactive interval end time for minutes      :  0x2C
Age value in hours from age byte register           :  0x27
Current activity interval start time for hours      :  0x26
Current activity interval end time for hours        :  0x27
Current inactive interval start time for hours      :  0x26
Current inactive interval end time for hours        :  0x26
Age value in days from age byte register            :  0x16
Current activity interval start time for days       :  0x15
Current activity interval end time for days         :  0x16
Current inactive interval start time for days       :  0x15
Current inactive interval end time for days         :  0x15
Number of active entries read                       :  1372435
Number of entries ignored with update to age byte   :  3812323
Number of entries updated with age byte             :  1781719
Number of entries created new                       :  4194

    Statistics from ASIC 1 when last activity timer expired:
Age value in seconds from age byte register         :  0x3D
Current activity interval start time for seconds    :  0x20
Current activity interval end time for seconds      :  0x40
Current inactive interval start time for seconds    :  0x0
Current inactive interval end time for seconds      :  0x20
Age value in minutes from age byte register         :  0x2F
Current activity interval start time for minutes    :  0x2C
Current activity interval end time for minutes      :  0x2F
Current inactive interval start time for minutes    :  0x29
Current inactive interval end time for minutes      :  0x2C
Age value in hours from age byte register           :  0x27
Current activity interval start time for hours      :  0x26
Current activity interval end time for hours        :  0x27
Current inactive interval start time for hours      :  0x26
Current inactive interval end time for hours        :  0x26
Age value in days from age byte register            :  0x16
Current activity interval start time for days       :  0x15
Current activity interval end time for days         :  0x16
Current inactive interval start time for days       :  0x15
Current inactive interval end time for days         :  0x15
Number of active entries read                       :  2043307
Number of entries ignored with update to age byte   :  3928935
Number of entries updated with age byte             :  993682
Number of entries created new                       :  0

�r�d�o:
http://www.cisco.com/en/US/products/hw/switches/ps708/products_tech_note09186a00807347ab.shtml

Heatmap dla ruchu HTTP

juggler — Fri, 01 Oct 2010 23:07:21 +0000

Poni�ej link do bardzo ciekawej iRule’ki. Zlicza po��czenia HTTP i przy wykorzystaniu Google Chart Tools rysuje map� z zaznaczeniem obszar�w, z kt�rych jest najwi�cej hit�w. Im ciemniejszy obszar, tym wi�cej ruchu z tego miejsca trafia do naszego VIPa.

�r�d�o:

Heatmaps, iRules Style: Part 1
Heatmaps, iRules Style: Part 2

Cisco search bar

juggler — Tue, 28 Sep 2010 20:44:28 +0000

Ma�a rzecz, kt�rej u�ywam od dawna i jest przydatna w codziennej pracy – plugin do FF, IE oraz Google Chrome umo�liwiaj�cy szybkie przeszukiwanie strony Cisco.com, a dok�adniej obszar�w:

Tools

* BugID Lookup Tool
* Command Lookup Tool for IOS Commands
* Error Message Decoder Tool
* RMA/Service Order Status Tool
* TAC Service Request Query

Searches

* Search Cisco
* Search Cisco Brazil
* Search Cisco Japan
* Search Cisco Latin America
* Search Cisco Russia
* Search Forums, Blogs, and Wikis
* Search Software Downloads

http://www.cisco.com/web/tsweb/searchplugins/plugin_homepage.html#

Troubleshooting CDR Analysis and Reporting – CUCM

juggler — Tue, 14 Sep 2010 15:07:18 +0000

Dobry dokument opisuj�cy troubleshooting zrzut�w CDR w CUCMie, kr�tko i konkretnie.

https://supportforums.cisco.com/docs/DOC-5706

Click to Call with Firefox 3.x

juggler — Thu, 05 Aug 2010 00:34:53 +0000

Jaki� czas temu szuka�em alternatywy dla Ciscowego Click to Call, kt�ra poradzi sobie z Firefoxem >= 3.0 (niestety Click to Call dzia�a �wietnie z Wordem, Excelem, PowerPointem, Outlookiem i IE, ale z Firefoxem tylko do wersji 2.0) i trafi�em na Laurenson UC Plugin, nice:).

new method in HTTP – PATCH

juggler — Sun, 09 May 2010 14:07:40 +0000

PATCH Method for HTTP

Abstract

Several applications extending the Hypertext Transfer Protocol (HTTP)
require a feature to do partial resource modification. The existing
HTTP PUT method only allows a complete replacement of a document.
This proposal adds a new HTTP method, PATCH, to modify an existing
HTTP resource.

http://tools.ietf.org/html/rfc5789

Slow Ramp Time

juggler — Mon, 03 May 2010 13:54:41 +0000

Przydatna sprawa, gdy nie chcemy aby nowy member pooli nie dosta� zbyt du�e ruchu na pocz�tku. Zbyt du�y “strza�” nowych po��cze� mo�e po�o�y� membera. Dlatego korzystamy z Slow Ramp Time, aby nowe po��czenia by�y stopniowo dok�adane.

Slow Ramp Time

Specifies the duration during which the system sends less traffic to a newly-enabled pool member. The amount of traffic is based on the ratio of how long the pool member has been available compared to the slow ramp time, in seconds. Once the pool member has been online for a time greater than the slow ramp time, the pool member receives a full proportion of the incoming traffic.