Cisco Blogs


Cisco Blog > Architect & DE Discussions

XMPP: A Power Tool in Your Tool Box

February 25, 2014 at 3:16 pm PST

Extensive Message Protocol (XMPP) is an open standard protocol based on XML (Extensible Markup Language). XMPP is designed to transport instant messages (IM) between entities and to detect online presence. It supports authentication of IM application and secure transport of messages over SSL/TLS. In XMPP entities can be bots, physical users, servers, devices or components. It’s really a powerful tool that has great potential for system administrators to add to their toolbox because:

  • XMPP is powerful
  • XMPP with Python is only 12 lines of code – trust me, it’s easy!
  • XMPP only requires a single query for multiple nodes
  • Status message can be used to track host presence

The Power of XMPP

For those of you that are not familiar with XMPP, it not only supports one-to-one messaging between entities but it also supports multi-party messaging (which enables an entity to join a chat room for the exchange of messages with several participants). The messages can be text messages embedded in XML format but XML can also be used to send control messages between entities as we will see with the presence stanza in a bit.

XMPP is widely used; Google uses it (for its Hangout application -- formerly google chat) and so does Yahoo and MSN. At Cisco, we use Cisco Jabber extensively to communicate internally. The XMPP client function is now integrated in the Cisco Nexus 5000 series with the release 5.2(1)N1(7) and the Nexus 6000 series with the release of 7.0(0)N1(1). XMPP is an integral part of the single console access for Dynamic Fabric Automation (DFA) which is a powerful framework described in my previous blog.

The new Data Center Network Manager (DCNM) 7.0(1) is delivered as an OVA file that can be deployed quickly on an existing VMware-enabled server. Although DCNM comes with a lot of features that simplify the deployment of the Data Center fabric, we can pick and choose any service we want to use independently -- which is great since DCNM comes with Cisco Jabber XCP and is license free. If you already have a XMPP service installed (like Openfire or ejabberd), it will not be a problem because everything discussed here is valid on any standard XMPP implementation.

On NX-OS devices, the XMPP feature is activated by configuring ‘feature fabric access’ and is part of the Enhanced L2 license (ENHANCED_LAYER2_PKG). Once activated, the switch becomes a XMPP client that needs to be registered on the server. In order to register it, XMPP requires the use of fully qualified domain names (FQDNs) to identify the domain server. If the switch does not have access to a DNS service, I recommend that you use the switch management network for messaging and a static host–to–IP address mapping in the switch configuration.

The switch will use its hostname to login to the XMPP service. If your XMPP server does not support auto-registration, you will need to register the switch and the rooms in the XMPP database beforehand. The DCNM OVA requires users and groups to be created via the CLI, and example of this user and group creation is:

[root@dcnm-ova ~]# appmgr add_user xmpp -u leaf0 -p cisco123
User added.
[root@dcnm-ova ~]# appmgr add_user xmpp -u leaf1 -p cisco123
User added.

User added. Read More »

Tags: , , , , , , , ,

Suitable For Everyone or Restricted to Some…

This is the third in a series of blogs comparing and contrasting the Microsoft and Cisco approaches to providing enterprise collaboration in the post-PC world. The first blog from Cisco SVP and GM, Rowan Trollope, discussed the differences between a purpose-built architecture and a desktop-centric approach that needs third party extensions to make a working enterprise-class system. The second blog discussed how the two companies are approaching the trend towards “Bring your own device” (BYOD) to work. Today’s blog discusses how the two companies deliver voice and video.

Suitable For Everyone or Restricted to Some…

We’re seeing more and more advisory labels on products these days that inform us whether they are suitable for everyone to use, or should be restricted to certain groups.  I’m wondering whether Microsoft should apply such a label to Lync? Let me explain, starting with Cisco’s point of view.   Read More »

Tags: , , , , , , , , , ,