Cisco keeps giving this week by allowing any desktop to join - for free - into any existing Telepresence video, and the quality of this video is really, really good. John Chambers recently said that Video is already the #1 traffic driver over Cisco's internal network, and that by 2013 it is expected that over 90% of all traffic over the internet will be based on Video. There's never been a better time to be training for Unified Communications!
Just announced at the Cisco Partner Summit yesterday, Cisco is making Unified Presence, IM and it's Jabber client for Mac, PC, iPad, iPhone, Cisco Cius, Blackberry and all Android devices completely FREE. This probably has something to do with how badly they've been spanked in Presence server and client sales by Microsoft basically giving away the presence features of Lync (although MS does make you pay when you want to add Voice/Video features to those clients - just as Cisco will). At any rate and for whatever their reasons and motivations - I personally think it is a very, very smart move for Cisco. It's also one that makes complete sense seeing that UCM v9 is about to go into beta testing next week. Understanding that the Jabber client can interact with video from any IP phone or Telepresence unit, and the fact that Cisco announced that this free Jabber client and Presence support is not only for those with existing IP Phones, but for every member of any enterprise with a UCM server, this makes the announcement all that more powerful. This doesn't include Voice or Video, but those can be enabled later with a simple license upgrade. Still not bad at all - especially with the new Jabber client for Windows, and the fact that once installed it enables all MS Office apps to have native presence tied into them directly to Cisco Jabber. This was the entire reason that Cisco purchased Jabber.
Another thing that Cisco is making free (at least for some limited time) is their WebEx Meetings Beta offering - for up to 25 participants. This includes desktop sharing and VoIP as well. Sign up here.
Also of no small merit, Cisco just shipped its 50 millionth phone - that's 50,000,000 phones shipped. I still remember putting in my first Selsius Call Manager more than 13 years ago. Not bad Cisco, not bad at all.
Just wanted to throw out a quick reminder to all of you involved day-to-day with Cisco Unified Communications in some fashion. Tomorrow I will host a free vSeminar on configuring and utilizing Active Directory as a source of LDAP user synchronization and authentication with the Cisco UC architecture servers.
- December 14, 2010 - 03:00 PM EST
- Instructor: Mark Snow, CCIE #14073
- Topic: LDAP Synchronization and Authentication in Unified Communications
If you still haven't registered, you can do so right up until the webinar begins. To do so, simply click here and fill in your requested information at the bottom of the page.
In case you missed any previous vSeminars, be sure to check out the recent updates here.
Hope to see you tomorrow!
In our CCDP bootcamp, we examined Cisco’s implementation of Virtual Private LAN Services (VPLS) in some detail. One blog that I promised our students was more information about how large enterprises or Internet Service Providers can enhance the scalbility of this solution.
First, let us review the issues that influence its scalability. We covered these in the course, but they are certainly worth repeating here.
Remember that VPLS looks just like an Ethernet switch to the customers. As such, this solution can suffer from the same issues that could hinder a Layer 2 core infrastructure. These are:
- Control-plane scalability - classic VPLS calls for a full-mesh of pseudo-wires connecting the edge sites. This certainly does not scale as the number of edge sites grow - from both operational and control-plane viewpoints.
- Network stability as the network grows – Spanning Tree Protocol-based (STP) infrastructures tend not to scale as well as Multiprotocol Label Switching (MPLS) solutions.
- Ability to recover from outages – as the VPLS network grows, it could become much more susceptible to major issues for customer connectivity in the result of a failure.
- Multicast and broadcast radiation to all sites – remembering that the VPLS network acts as a Layer 2 switch reminds us that multicast and broadcast traffic can be flooded to all customers across the network.
- Multicast scalability - multicast traffic has to be replicated on ingress PE devices, which significantly reduces forwarding efficiency.
- IGP peering scalability issues – all routers attached to the cloud tend to be in the same broadcast domain and thus IGP peer, which results in full-mesh of adjacencies and excessive flooding when using link-state routing protocols.
- STP loops – it is certainly possible that a customer creating an STP loop could impact other customers of the ISP. STP may be blocked across the MPLS cloud, but it is normally used for multi-homed deployments to prevent forwarding loops.
- Load-balancing - the use of MPLS encapsulation hides the VPLS encapsulated flows from the core network and thus prevents the effective use of ECMP flow-based load-balancing.
The solution for some of these issues is Hierarchical VPLS (H-VPLS). H-VPLS only interconnects the core MPLS network provider edge devices with a full mesh of pseudo-wires, thus reducing the complexity of the full-mesh. The customer provider edge equipment is then connected hierarchically using pseudo-wires to these core devices. The topology now looks like a reduced full-mesh with tree-like connections at the edge of the network. Notice the customer edge equipment no longer connects to each other.
Using H-VPLS, the problem of control-plane scalability can be significantly alleviated. The network is partitioned into as many edge domains as is required. These edge domains are then very efficiently connected using an MPLS core. The MPLS core for the provider allows for the simultaneous usage of L3 MPLS VPNs for those additional customers that desire it. In addition, the MPLS core may limit the extent of the STP domain in non multi-homed scenarios, and therefore, improves performance and limits instabilities.
It is worth mentioning that the main problem with VPLS deployments is not the control-plane but rather data-plane scalability - mainly because of the MAC address table explosion and excessive broadcast/multicast traffic flooding. In addition to improving control-plane scalability by means of H-VPLS pseudo-wire hierarchies, additional techniques can be used to alleviate the issues of the data-plane. The first technique is MAC-in-MAC address stacking, which reduces the number of MAC addresses to be exposed in the core. The second is known as multicast forwarding optimization. This allows for the use of special point-to-multipoint pseudo-wires in the SP core to improve multicast traffic replication.
To summarize, H-VPLS offers the following benefits compared to traditional VPLS solutions:
- Lowers the number of pseudo-wire connections that must be full-meshed and thus improves control-plane scalability
- Reduces the burden on core devices presented by frame replication and forwarding by adding a hierarchical "aggregation" layer
- Reduces the size of MAC address tables on the provider equipment when combined with MAC-in-MAC address stacking
To complete this blog post, we should mention that there is an alternative to H-VPLS control plane scaling that has been championed by Cisco's rival, Juniper Networks. Juniper's approach utilizes BGP for VPLS pseudo-wire signaling, as opposed to using point-to-point LDP sessions. Scaling BGP by means of route-reflectors is well-known and thus Juniper's approach automatically has a scalable control-plane.
I hope you enjoyed this post. Be sure to watch the blog for more exciting Design-related presentations.
Here is the recommended reading list that several asked for from our CCDP Bootcamp. Thanks again to all that attended for the awesome participation and discussions.
One of the fun things for me about helping with the new CCDP Bootcamp is learning about technologies you do not get exposure to in the "traditional" Routing and Switching curriculum that are based on mid-level and low-level Cisco hardware. One of those technologies that our new course will cover is Bidirectional Forwarding Detection (BFD). This technology is found on Cisco 6500/7600 series routers, as well as 12000 series and Carrier Routing System (CRS-1 Routers).
Like many of the features covered in the Routing Protocol Design section of the course, Bidirectional Forwarding Detection seeks to speed up routing protocol convergence. The key factor in this goal addressed by BFD is the fast detection of node or link failure in the routing design.
Many approaches to the fast detection of the failure of a link or neighbor deal with some type of accelerated hello packet (fast hellos at Layer 3). BFD operates along a similar line,except the fast link hellos are accomplished at Layer 2. The CPU impact of the BFD process ends up being much less compared to other fast hello approaches. Cisco has tested systems running 100 concurrent BFD sessions between routers and noticed an increase in CPU utilization of a mere 2%. And remember, that was with 100 concurrent sessions running.
In order to take advantage of Cisco's BFD, we not only require the correct software and hardware version, but we need the cooperation of the routing protocol. Fortunately, BFD functionality has been engineered into OSPF, EIGRP, IS-IS, and BGP, as well as such important "support" protocols like HSRP.
If you would like to learn more about BFD right now, visit the Cisco DOC-CD.
Our BGP class is coming up! This class is for learners who are pursuing the CCIP track, or simply want to really master BGP. I have been working through the slides, examples and demos that we'll use in class, and it is going to be excellent. :) If you can't make the live event, we are recording it, so it will be available as a class on demand, after the live event. More information, can be found by clicking here.
One of the common questions that comes up is "Why does the router choose THAT route?
We all know, (or at least after reading the list below, we will know), that BGP uses the following order, to determine the "best" path.
So now for the question. Take a look at the partial output of the show command below:
Regarding the 188.8.131.52/24 network, why did this router select the 192.168.68.8 next hop route, over the one just below it?
Post your ideas, and we will have a drawing next week, before the BGP class begins. We'll give 1 lucky winner some rack tokens for our preferred rack vendor, Graded Labs. Everyone who comments, will be entered into the drawing. I will update the post with the lucky winner.
Thanks for your ideas, and happy learning.
Thank you to all who responded. eBGP is preferred over iBGP, and that is what it came down to.
The winner of the graded labs tokens is Jon! Congratulations.
As you may have noticed, INE does a wide variety of training in the Cisco space. :) This blog post goes out to all those folks who have recently begun their Cisco training.
This month we delivered new live classes on CCNA and CCNP. We are excited for and encourage our students at every level in their journey. In that light, we have gathered a collection of Videos Answers, targeted at the CCNA level, with a few topics leaking into security and CCNP. These videos were primarily created as quick (under 10 minutes each) Video Answers to questions that various learners have had.
Take a look at the list of topics, and if there are 1 or 2 you feel you would benefit from, feel free to enjoy them.
Here are a few of the topics (in no particular order):
- How the network statement really works in IOS
- Setting up SSH
- Initial commands for sanity sake
- NAT with overload
- Router on a stick
- SDM Security Audit
- Adding your own PC to interact with GNS3 routers
- IPv6 basic implementation
- Converting Multicast address to MAC address for that group
- Frame relay mappings
- VLSM implementation
- HUBs Swtiches and Routers comparison
- Configure IOS to be a Frame Switch
- EIGRP offset lists
- Multicast GET VPN
- Context Based Access Control
- Zone Based Firewalls
- Dot1q Trunking
- ARP cache tutorial
and more... :)
You can view them using this link here on YouTube
You may also use this link: http://www.youtube.com/user/Keith6783
If you want to look further into learning, we offer a full suite of self-paced workbooks, videos, and interactive learning tools.
Best wishes, and happy studies.
As I mentioned in a blog article a few months back, INE installed 7961 phones in all of our Voice Racks used for customer rental, and simultaneously struck up an exclusive deal with the company called VoIP Integration so that our students could buy their fantastic Remote Phone Control Software at quite a significant discount. More students than I ever imagined would, have contacted me and received the INE Student Edition of this software for use during their studying sessions. In fact, many that already have phones of their own, bought the software just so that they could travel and stil practice labs - while on the road - with their phones and without having to pack up and take their phones with them.
This is the very tool we use during all of the live online and recorded CCIE Voice Deep Dive's to show you exactly what is happening in real-time on the actual phones (which happen to be in front of me so that you can hear what is going on as well) for any given task we are all working through configuring or testing & troubleshooting.
Well, now VoIP Integration has updated their Remote Phone software to version 2.1 and brought quite a significant update in features. Standing out clearly in front of all of them - even in front of the great performance improvements - is support for IP Phones registered to Cisco Unified Communications Manager Express and IOS CME as SRST!
I have provided the basic configuration here that you would need to support them in CME. Important NOTE: Don't forget the "type" command on your ephone. Without it, CME doesn't actually build the CNF files for that phone, and while they will register using the Default.cnf.xml file, that file doesn't contain the necessary Authentication URL.
ip http server
no ip http secure-server
ip http path flash:gui
ixi transport http
response size 4
request outstanding 1
ixi application cme
ip source-address 184.108.40.206 port 2000
url authentication http://220.127.116.11/CCMCIP/authenticate.asp admin cciecisco
log password cciecisco
ephone-dn 1 dual-line
Also, If you would care to purchase a copy of INE's Student Edition of the VoIP Integration Remote Control software, please ping me at msnow at ine dot com.