Cisco Blogs


Cisco Blog > Perspectives

#CiscoChampion Radio S1|Ep12 Value of the Partner Eco-System

#CiscoChampion Radio is a podcast series by Cisco Champions as technologists, hosted by Cisco’s Amy Lewis (@CommsNinja). This week Dominick Delfino, VP Systems Engineering at Cisco, joins Cisco Champion and Senior Pre-Sales Engineer Ahmad Manzoor. The topic is the Value of the Partner Eco-System.

cisco_champions_BADGE_200x200

Listen to the Podcast

Cisco Subject Matter Expert:
Dominick Delfino, VP Systems Engineering Cisco (@domdelfino)

Cisco Champion:
Ahmad Manzoor, Senior Pre-Sales Engineer (@AhmadManzoor1)
Read More »

Tags: , , ,

Internet Security Necessary for Global Technology Economy

Today’s security challenges are real and significant.  We want governments to detect and disrupt terrorist networks before they inflict harm on our society, our citizens, and our systems of government.   We also want to live in countries that respect their citizens’ basic human rights.  The tension between security and freedom has become one the most pressing issues of our day.  Societies wracked by terror cannot be truly free, but an overreaching government can also undermine freedom.

It is in this context that I want to offer some thoughts on actions by the US Government that in Cisco’s eyes have overreached, undermining the goals of free communication, and steps that can be taken to right that balance, and I do so on behalf of all of Cisco’s leadership team.

Confidence in the open, global Internet has brought enormous economic benefits to the United States and to billions around the world.  This confidence has been eroded by revelations of government surveillance, by efforts of the US government to force US companies to provide access to communications of non-US citizens even when that violates the privacy laws of countries where US companies do business, and allegations that governments exploit rather than report security vulnerabilities in products.

As a matter of policy and practice, Cisco does not work with any government, including the United States Government, to weaken our products. When we learn of a security vulnerability, we respond by validating it, informing our customers, and fixing it.  We react the same when we find that a customer’s security has been impacted by external forces, regardless of what country or form of government or how that security breach occurred.  We offer customers robust tools to defend their environments against attack, and detect attacks when they are happening. By doing these things, we have built and maintained our customers’ trust.  We expect our government to value and respect this trust.

Read More »

Tags: , , ,

Automatic Software Delivery now available on the Cisco Small Business RV215W VPN Router

May 13, 2014 at 4:15 pm PST

You may not realize this, but Cisco has a thriving business building and selling networking products specifically designed for Small Businesses. Unfortunately, we know dealing with Cisco can sometimes be challenging for some smaller customers, a good example of this is managing software. Sometimes, it can be quite challenging to finding out whether equipment is running the latest software, and if not, how to get the latest software.

We recently announced a new feature called Automatic Service Delivery (ASD) on the RV215W, a wireless-n VPN Router that is in the Cisco Small Business Routing Portfolio.

The Automated Software Delivery service allows network devices such as the Cisco RV215W router or management tools such as Cisco FindIT to automatically retrieve software release information and software images from the cisco.com software library. This means that the user can be notified when a new software image is available, and they can obtain that software at the click of a button, rather than having to find their way through the thousands of files in the software library. If the user so chooses, a device can even automatically update itself, thereby ensuring the network is always running the most current versions of software.

This work was completed by our Smart Web Technology Group (SWTG). The API they developed enables client applications to retrieve vital software release and image information including release note, field notices and PSIRT information.

In order to gain access to this new feature, simply download the latest RV215W firmware form the RV215W product page and enable automatic updates on the Administration > Firmware/Language Upgrade page.

Cisco RV Series_RV215W VPN Firewall

Look for more RV Series Models to get this free ASD Service.

So to wrap this up, we know Cisco’s Small Business customers face so many challenges and demands on their time, the Automated Software Delivery service is a great tool that helps make their job just that little bit easier.

Thanks for taking the time out of your busy day to hang out with us.

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

Network Design for Automation

20140519-CISCO-spine-and-leafThere has been a lot of recent online discussion about automation of the datacenter network, how we all may (or may not) need to learn programming, the value of a CCIE, and similar topics. This blog tries to look beyond all that. Assume network configuration has been automated. How does that affect network design?

Automation can greatly change the network landscape, or it may change little. It depends on what you’re presently doing for design. Why? The reason is that the programmers probably assumed you’ve built your network in a certain way. As an example, Cisco DFA (Dynamic Fabric Automation) and ACI (Application Centric Infrastructure) are based on a Spine-Leaf CLOS tree topology.

Yes, some OpenFlow vendors have claimed to support arbitrary topologies. Arbitrary topologies are just not a great idea. Supporting them makes the programmers work harder to anticipate all the arbitrary things you might do. I want the programmers to focus on key functionality. Building the network in a well-defined way is a price I’m quite willing to pay. Yes, some backwards or migration compatibility is also desirable.

The programmers probably assumed you bought the right equipment and put it together in some rational way. The automated tool will have to tell you how to cable it up, or it  might check your compliance with the recommended design. Plan on this when you look to automation for sites, a datacenter, or a WAN network.

The good news here is the the Cisco automated tools are likely to align with Cisco Validated Designs. The CVD’s provide a great starting point for any network design, and they have recently been displaying some great graphics. They’re a useful resource if you don’t want to re-invent the wheel — especially a square wheel. While I disagree with a few aspects of some of them, over the years most of them have been great guidelines.

The more problematic part of this is that right now, many of us are (still!) operating in the era of hand-crafted networks. What does the machine era and the assembly line bring with it? We will have to give up one-off designs and some degree of customization. The focus will shift to repeated design elements and components. Namely, the type of design the automated tool can work with.

Some network designers are already operating in such a fashion. Their networks may not be automated, but they follow repeatable standards. Like an early factory working with inter-changeable parts. Such sites have likely created a small number of design templates and then used them repeatedly. Examples: ”small remote office”, “medium remote office”, “MPLS-only office”, or “MPLS with DMVPN backup office”.

However you carve things up, there should only be a few standard models, including “datacenter” and perhaps “HQ” or “campus”. If you know the number of users (or size range) in each such site, you can then pre-size WAN links, approximate number of APs, licenses, whatever. You can also pre-plan your addressing, with, say, a large block of  /25′s for very small offices, /23′s for medium, etc.

On the equipment side, a small office might have one router with both MPLS and DMVPN links, one core switch, and some small number of access switches. A larger office might have one router each for MPLS and one for DMPVN, two core switches, and more access switches. Add APs, WAAS, and other finishing touches as appropriate. Degree of criticality is another dimension you can add to the mix: critical sites would have more redundancy, or be more self-contained. Whatever you do, standardize the equipment models as much as possible, updating every year or two (to keep the spares inventory simple).

It takes some time to think through and document such internal standards. But probably not as much as you think! And then you win when you go to deploy, because everything becomes repeatable.

Read More »

Tags: , , , , , , , , ,

Openstack Expectations for Summit

Openstack SummitAs I was flying to Atlanta for Openstack Summit, I was thinking about the difference in my expectations for this summit from the summit last year in Portland.

In Portland, Havana was just released and was starting to become interesting to service providers as the project was maturing and gaining interest with some enterprises. The Havana release was not ready for enterprises but Icehouse, the next release was bringing features that are of great interest. I was interested in getting involved in Icehouse so I attended with my R&D team and networked. There was not much excitement at the event and the attendance was not that great. Walking into the exhibit hall was depressing as there were only a small number of exhibits and mostly tables with brochures.

One year later, and the excitement around Openstack and Icehouse is high. Openstack has finally hit the feature capability and scale requirements needed to be accepted by the enterprise. Over the last year, numerous enterprises performed Proof of Concepts (PoCs) on Havana and 2014 is quickly becoming the year of Openstack coming out! The Icehouse features that are of greatest interest are:

  • Ceilometer support in Horizon for administrators to view daily usage reports per project across services.
  • Keystone now enables federated authentication via Shibboleth for multiple Identity Providers, and mapping federated attributes into OpenStack group-based role assignments 
  • Keystone assignment backed is completely separate from the identity backend. This allows much greater flexibility in which data comes from where. This allows an enterprise back your deployment’s identity data to LDAP, and your authorization data to RSA for instance.
  • Token KVS driver is now capable of writing to persistent Key-Value stores such as Redis, Cassandra, or MongoDB. In combination with above, this means we can use Redis or Cassandra for tokens and LDAP for user/pass/domain/etc.
  • Notifications  are now emitted in response to create, update and delete events on roles, groups, and trusts.
  • LDAP driver for the assignment backend now supports group-based role assignment operations.
  • Ceilometer API now gives direct access to samples decoupled from a specific meter events API, in the style of StackTach 
  • New Metric sources, including Neutron north-bound API on SDN controller, VMware vCenter Server API, SNMP daemons on bare metal hosts and OpenDaylight REST APIs    [ Check also Mike Cohen's blog  Delivering Policy in the Age of OpenSource  ]

For the full set of features, please refer to: https://wiki.openstack.org/wiki/ReleaseNotes/Icehouse

I’m really looking forward to the Summit in Atlanta and will be spending most of my time in the Juno Design Summit contributing to Heat, Ceilometer, and Solum.

You can also follow me on Twitter @kenowens12

 

Tags: , , , , ,