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
[root@dcnm-ova ~]# appmgr add_user xmpp -u leaf1 -p cisco123
User added. Read More »
Tags: Cisco Data Center Fabric, Cisco Nexus, DCNM, instant messaging (IM), NX-OS, open standard protocol, XML, XMPP, xmpp with python
For a few of us in the Cisco Brussels office the last weekend of January always marks a special occasion.
The weekend is dedicated to the Free and Open-source Software Developers’ European Meeting (FOSDEM) conference in Brussels, with around 5,000 visitors attending. The event happens at the ULB (Université libre de Bruxelles) campus, but traditionally uses its own network infrastructure, sponsored by Cisco. And we, who are Cisco employees, volunteered our time to help the community as well as meet some new friends and get extra hands-on experience with a sizable network.
What was different this year was that just before the official start of the conference I finally figured out how NAT64 works, gave a 5 minute warning on twitter (image below), and then disabled IPv4 on the main network (simply stated I removed the IPv4 address of the router on the client interface so that only the IPv6 address remained).
That meant that visitors would only get an IPv6 address Read More »
Tags: cisco live, disabling IPv4, FOSDEM, IPv6, IPv6-only SSID, NAT64
That is it, Cisco Live Milan is over! The “before” of anticipation, seemingly a moment ago, is replaced by the “after” of takeaways and accomplishments for the week. Some passed their CCIE certification, some met a new business partner, but it’s likely that everyone learned something new. I am not an exception.
During the week, I presented at two different technical breakout sessions (BRKRST-2304 – Hitchhiker’s Guide to Troubleshooting IPv6 and BRKEWN-2666 – IPv6 on WiFi: You talk too much! NOT anymore) and spent my remaining time working with everyone in the Network Operations Center (NOC) to ensure that IPv6 is a smooth ride for all of the 9,000+ devices on the network. Not only did I learn a lot, but this year at Cisco Live Milan was a year of “firsts” for me.
- For starters, it was the first time I shared details about my experience with large-scale IPv6 WiFi setups with Cisco Live attendees in the form of a breakout session. After talking with attendees, my main takeaway – Read More »
Tags: #CLEUR, #IPV6ONLYEXP, Cisco Live Milan, Cisco Live NOC, IPv6, IPv6-only WiFi, NOC
As Cisco Live Europe 2014 draws to a close I wanted to reflect on what has (for me) been a personal campaign to raise the visibility of IPv6 in the World of Solutions / WoS (the demonstration / show floor of the event)
Last year at Cisco Live London I heard some comments that there was not enough IPv6 in the WoS. I decided to see if I could encourage Cisco Business Units and Partners to enable demonstrations for Dual Stack operation and highlight that fact. I wrote previously we would be “awarding” an “IPv6 Enabled Logo” to all Cisco and Partner demonstrations that took the step of enabling Dual Stack and highlighting the same fact.
How did we fare ? Cisco Live 2014 Milano showcased over 15 IPv6 enabled demonstrations including two which were enabled as “IPv6 only”. These were spread between Cisco and Partner booths and were mainly marked with the newly created green “IPv6 Enabled Logo”.
I personally visited a number:
Read More »
Tags: autonomic networking, Cisco, cisco live, first hop security, IPv6, LISP
I am not qualified to discuss it much, but can you guess what this does?
ne = NetworkElement("172.16.66.1", "JasonsApp")
conn = ne.connect("admin", "cisco", sc)
intf1 = ne.get_interface_by_name("FastEthernet0/1")
If you guessed that it logs into a switch at 172.16.66.1 and disables interface F0/1 for 5 seconds and re-enables it, then you guessed right.
Let us talk a little about putting the “ability” in programmability. Did I code in college? Yes. Was I good at it? Not really. Dijksta’s algorithm (the actual coding bit) drove me crazy, however, actually using and operating networks quickly became my cup of tea. I became a network geek. Subnets? Awesome! Cisco CLI? Sweet. Using Enhanced Interior Gateway Routing Protocol (EIGRP)? Yay! AVVID? Even better. But I never wanted to see C++ or another “program” again.
Fast forward to 2014. I’m still a networking guy but now I’m seeing code again. The good news is, maybe like you, I hang out with some really cool people. I challenged a couple of them to help me demonstrate program “ability” to networking people on the show floor at CiscoLive Milan…with me as the test subject! Read More »
Tags: #CLEUR, Cisco Live Milan, Cisco ONE, networking, onePK, programmability, Programming with Python, python