Friday, November 18, 2011

Creating Rendezvous (Meetme) Conference on UCM + Cisco Telepresence MCU

My environment:  UCM 8.6.1-20000-1, Cisco Telepresence MCU 4510 4.3(1.27)

Previously in the last blog post:

We have successfully configured Cisco Telepresence MCU as ad-hoc conference resource on UCM.  The caveat is this ad-hoc video conference resource can’t be used on Tandberg endpoint such as EX60 today, because there is no conference soft key or hard key for the conference initiator to start the conference.  The alternative is meetme conference.  However you might want password protected meetme conference, you can achieve it by configuring Rendezvous meeting on Cisco Telepresence MCU.

1.  Add the Cisco Telepresence MCU as H323 gateway on UCM


2. Create Route List, Route Group, then Route Pattern.  Standard stuff.

3. Create Route Pattern with the destination to this H323 gateway.  In my case, my route pattern is 1357.

4. Then go to Cisco Telepresence MCU.  Add UCM IP address as H323 gateway.


5. Create Rendezvous Conference, the numeric ID is the number that you previously created on UCM route pattern, 1234 is the PIN to protect this meeting.


Test it by calling 1357.  Then you should see the screen asking for PIN.  Enter the PIN then you are now in the rendezvous meeting.



This is not official support.  Currently you can’t configure the MCU as media resource (UCM ad-hoc, meetme) and MCU rendezvous at the same time with the same MCU, however it works.  Make sure you are not using the UCM software MTP.  With that MTP in your MRGL or your default <none> MRGL, EX60/90 will become audio only. 

Friday, November 4, 2011

Device initialization error has occured 1201

My environment:  UCM 8.6.1, CUP 8.5.1, CUPC 8.5.3

I have encountered an error on CUPC saying "Device initialization error has occured.  [1201]".  Everything is working except the softphone and hardphone mode.  It seems to be something is wrong on the UCM side.

The root cause of my problem is when the UCM is installed, it is synchronized with a NTP server with wrong time configured, therefore the tomcat certificate on UCM is expired.  The step to fix this:

1. UCM OS admin page > Security > Certificate management
2. Find the tomcat.pem, click on the certificate and check the validity date
3. If it is expired, click on "Regenerate"
4. Restart the tomcat service in CLI - "utils service restart Cisco Tomcat"

After CUPC logout and login, the softphone and hardphone mode works again!

Thursday, November 3, 2011

My LISP notes to share

What is LISP?
  • enables separation of IP addresses into two new numbering spaces: Endpoint Identifiers (EIDs) and Routing Locators (RLOCs)
  • Locator / Identifier Separation Protocol
Routing Locators (RLOCs)
  • topologically assigned to network attachment points, used for routing and forwarding of packets through the network
Endpoint Identifiers (EIDs)
  • assigned independently from the network topology, are used for numbering devices, aggregated along administrative boundaries
LISP then defines functions for mapping between the two numbering spaces and for encapsulating traffic originated by devices using non-routeable EIDs for transport across a network infrastructure that routes and forwards using RLOCs. Both RLOCs and EIDs are syntactically-identical to IP addresses; it is the semantics of how they are used that differs.

Provider Independent (PI) address
- An address block assigned from a pool where blocks are not associated with any particular location in the network
- Not topologically aggregatable in the routing system

Provider Assigned (PA) address
- An address block assigned to a site by each service provider to which a site connects
- Each block is sub-block of a service provider CIDR block and is aggregated into the larger block before being advertised into the global Internet

Routing Locator (RLOC)
- RLOC is an IPv4 or IPv6 address of an egress tunnel router (ETR)
- RLOC is the output of a EID to RLOC mapping lookup
- 1 EID maps to 1 or more RLOCs
- Multiple RLOCs can be assigned to the same ETR device or to multiple ETR devices at a site

Endpoint ID (EID)
- A 32-bit (IPv4) or 128-bit (IPv6) value used in the source and destination address fields of the first (most inner) LISP header of a packet
- The host obtains the destination EID similar to DNS
- Source EID is obtained via existing mechanisms used to set a host's local IP address
- An EID is allocated to a host from an EID-prefix block associated with the site where the host is located
- EIDs MUST NOT be used as LISP RLOCs

- A power of two block of EIDs
- allocated to a site by an address allocation authority
- EID prefixes are associated with a set of RLOC address which make up a database mapping

Ingress Tunnel Router (ITR)
- A router which accepts an IP packet with a single IP header (does not contain a LISP header)
- The router treats this inner IP destination address as an EID and performs an EID to RLOC mapping lookup
- The router then prepends an outer IP header with one of its globally routable RLOCs in the source address field
- ITR receives IP packets from site end systems on one side and sends LISP-encapsulated IP packets toward the Internet on the other side

Egress Tunnel Router (ETR)
- An ETR is a router that accepts an IP packet where the destination address in the outer IP header is one of its own RLOCs
- The router strips the outer header and forwards the packet based on the next IP header found
- ETR receives LISP encapsulated IP packets from the Internet on one side and sends decapsulated IP packets to site end system on the other side

- ITR or ETR - tunnel endpoint

EID-to-RLOC cache
- short lived, on demand table in an ITR

EID to RLOC database
- global distributed database that contains all known EID-prefix to RLOC mappings

Basic Overview
- For routers between source host and ITR - destination address = EID
- For routers between destination host and ETR - destination address = EID
- For routers between ITR and ETR - destination address is RLOC
- IP addresses of the end systems = Endpoint Identifiers (EIDs)
- The IP address in the outer header are RLOCs
- ITR prepends a new LISP header to each packet and an egress tunnel router strips the new header
- ITR performs EID-to-RLOC lookups to determine the routing path to the ETR, which has the RLOC as one of its IP address

Basic Rules
- End systems only send to addresses which are EIDs. They don't know address are EIDs versus RLOCs but assume packets get to LISP routers and deliver packets to destination end system
- EIDs are always IP address assigned to hosts
- LISP routers mostly deal with RLOCs
- RLOCs are always IP addresses assigned to routers, preferably topological-oriented addresses from provider CIDR blocks
- EIDs are not expected to be usable for global end-to-end communication in the absence of an EID-to-RLOC mapping operation
- maximum 2 LISP headers can be prepended to a packet - first header as Location / Identity separation and second prepended header inside service provider for TE purposes
- Map-Requests can be sent on the underlying routing system topology or over an alternative topology
- Map-Replies are sent on the underlying routing system topology

Packet Flow
1. wants to open a TCP connection to
2. It does a DNS lookup on
3. A/AAAA record is returned. This address is the destination EID
4. Locally assigned address of is source EID
5. Packet is built and forwarded through the LISP site as a normal packet until reaches ITR
6. ITR must be able to map the EID destination to an RLOC of one of the ETRs at the destination site. The ITR will send a LISP Map-Request, and it should be rate-limited
7. When an alternate mapping system (ALT) is not in use, the Map-Request packet is routed through the underlying routing system. Otherwise the Map-Request packet is routed on an alternate logical topology
8. Map-requests arrives at one of the ETRs at the destination site
9. ETR looks at the destination EID of the Map-Request and matches it against the prefixes in the ETR's configured EID-to-RLOC mapping database. This is the list of EID-prefixes the ETR is supporting for site it resides in
10. If there is no match, Map-Request is dropped. Otherwise a LISP Map-Reply is returned to the ITR
11. The ITR receives the Map-Reply message, parses the messages and stores the mapping information from the packet. This information is stored in the ITR's EID-to-RLOC mapping cache. Note that the map cache is an on-demand cache
12. Subsequent packets from host1 to host 2 will have LISP header prepended by the ITR using the appropriate RLOC as the LISP header destination address learned from the ETR
13. ETR receives these packets directly, strips the LISP header and forwards the packets to the attached destination hosts

Tuesday, November 1, 2011

LISP 101 Pencast

I have spent a couple of days to study LISP, and I have summarized what I have learnt in the following pencast. Feel free to take a look and see if it helps you to have a basic understanding on how LISP works:

Cantonese version:

English version: