Thanks to everyone who was able to join us on September 27 for DemoFriday™ with Cisco. If you missed the demonstration on Cisco’s Extensible Network Controller (XNC). It now is available in our archives.
The XNC demo shows how the application is designed provide greater automation and orchestration of the network fabric and enable dynamic configuration of networks and services that align to business requirements. Watch the full presentation, or check out the teaser video and other resources below.
Following are responses from Cisco presenters Sr. Director Strategy and Portfolio Marketing, Data Center Group Archana Khetan, Product Manager Jothi Prakash Prabakaran, and Distinguished Engineer Bhushan Kanekar to questions submitted from the attendees at the September 27th XNC demo.
Whats the size of the Flow table in N3K?
Cisco: Max flow table size on N3K is 1500.
Can slices overlap?
Cisco: A switch can be part of more than one slice as the slicing can be at flow level granularity. This means an unique flow can be part of a slice and one slice alone but multiple unique flows coming in on an interface of a switch can each be part of different slices.
Is it VLAN based?
Cisco: Assuming the question is whether slicing is VLAN based, given that VLAN is part of the flow spec and slicing can be at flow level granularity, VLAN can be used for slicing. But slicing is not limited to VLAN alone.
Can we use other vendors’ OpenFlow switch for Monitor Manager solution today?
Cisco: The demos we have shown today all use Openflow 1.0 for southbound APIs. Since we support industry standards a third party device that supports OF1.0 should work with the solution.
Note that the XNC commercial controller solution comes with full TAC support on devices which have been tested. Today the supported platform includes Nexus 3000 with other Cisco platforms to follow.
Are there any use cases to utilize Cisco OnePK?
Cisco: OnePK API offers programmability of a much richer set of capabilities than OpenFlow which is primarily focused on forwarding rules based on classifiers.
For example, onePK offers a robust service set for routing for protocol change events and queries, while the Utilities service set can address Netflow and DHCP events.
We have use cases where one can use OnePK for attributes other than the limited set available via OpenFlow to determine forwarding. Please stay tuned as we cover those use cases in future
Is XNC related to the recently-announced NCS (Network Convergence System)? If so, how are they integrated?
Cisco: As mentioned in the NCS press release it will have touch points with Cisco ONE. Cisco XNC is part of the Cisco ONE portfolio so we will have the touch points elaborated in the future. The use cases demoed today are not related to IoT (Internet of Things) which NCS is addressing.
Is there a way to automate the policy-selection process shown in the network tapping use case? It would be tedious to follow the steps being shown for 100 or 1000 switches.
Cisco: One can define the policies a priority and attach them to ports from one or more switches or one can apply policy universally (match traffic against the policy irrespective of which switch port the traffic ingresses on). Also everything you can do via GUI is available via REST API so one can write scripts using those.
What integration will the XNC have with Cisco technologies such as AVC and PfR for best route determination?
Cisco: TIF is a Controller based path calculation that gives more comprehensive attributes a user can specify in calculating paths. Customers can choose the SDN based approach or the PfR if they are comfortable with it. AVC, which provides application visibility, is complementary to TIF.
Is there any plan to leverage cisco ISE for policy or identity to further define the criteria for transit selection?
Cisco: Integration with Cisco ISE for policy or identity or location is future improvement that is on the roadmap. Stay tuned.
You mentioned that XNC could seamlessly be integrated into an existing network. First, with the assumption that the elements themselves support OpenFlow?
Cisco: Yes one would need the network elements to support OpenFlow for these use cases.
Assuming the above question is the case, then do you have the ability to maintain existing policies, etc. and use XNC for the future or does the entire network have to be controlled via XNC; hence all parameters have to be migrated to XNC?
Cisco: One can choose which portions of network you want under SDN (and hence XNC) control. Rest could use well known methods in use. We call this hybrid model.
As was mentioned during the demo, In the Monitor Manager use case only the Monitoring switches are controlled by XNC while the production switches are not controlled by the XNC. So Monitor Manager use case is a great way to start SDN with, as it is safe (your production network runs using the protocols and technologies you are comfortable and familiar with) and also saves you money compared to the traditional monitor matrix solutions. With the Topology Independent Forwarding you can choose to start using it for the Edge like Data Center Interconnect or Campus/Enterprise Edge device. Then only those network devices are under the control of XNC. With Slicing you will have more of your network devices engaging with XNC. However, please note that we follow the Hybrid Integrated model where the well known networking Protocols (Control Plane) continues to run on the network devices and XNC Applications complement those Control Planes by installing rules to work in tandem with the forwarding rules built via the well known networking protocols.
To summarize we are providing solutions and applications to solve real world problems while easing one into SDN and retaining your investment and comfort with well known networking protocols and devices.
Is it possible to match on IPv6 packet characteristics?
Cisco: IPv6 is not supported with OpenFlow 1.0 One would need vendor extensions or OpenFlow 1.3 support. Roadmap has to support those including OpenFlow 1.3 support.
Does the XNC controller have an option implement a ‘learning switch’ function, allowing all hosts to communicate without configuring any flow entries?
Cisco: One can write a learning switch App on the Controller. We have a sample “Simple Forwarding” App on OpenDaylight to do that. Once learnt and first few packets go to Controller and App it can program rules into the switch to handle traffic in hardware. You want data traffic to be handled in switches, the classical reactive model of OpenFlow is not scalable but if one wants to do that with XNC they can. However our use cases don’t need any data traffic to go to XNC.
What model of Nexus switches are you using in this demo?
Cisco: Nexus 3064, Nexus 3016 from the Nexus 3000 switch family
Does policy based troubleshooting affect the performance?
Cisco: There is no performance impact as controller collects the raw statistics and aggregates them for user display. The system specification takes into account the compute resource requirements to support this function.
What’s the adoption of XNC in the market?
Cisco: Our SDN controller went into trials in May. Not only did we quickly oversubscribe the trials, some of our customers have already converted to paying customers and are now planning deployments with availability of GA code.
As an example, we have sold a 2000 port solution to customer who plans to use Monitor Manager Application extensively in their DC and lab environments to direct traffic for security analytics.
Since we have taken a very solution centric approach to SDN, we are seeing trials and deployments in a very broad range of environments wherever there is a fit. In talking to customers a few things have become clear however:
- Customers are looking for a solution to their problems and not a solution looking for problems. We are taking a very pragmatic approach of solving real world problems.
- Customers also want an approach that can be adopted with least disruption. Most environments are brownfield. Monitor Manager is a good example, where SDN can be inserted with little disruption.
What are the north bound APIs available? Is there any documentation available?
Cisco: We support REST/JSON and JAVA OSGI based north bound interfaces. The API documentation is available on Cisco Developer Network (CDN). http://developer.cisco.com/web/cdc/home .
What is the pricing for XNC?
Cisco: We are pricing the XNC controller on a perpetual license model based on the number of devices it controls. The application pricing similarly is also perpetual and based on number of devices.
A promotional bundle that supports the controller and applications is available for a limited time. Please contact your local account representative for pricing.
What is the effort required to develop these applications and does XNC provide significant acceleration to the effort?
Cisco: Cisco Developer Network provides an overview for application developers to get on board. Details are available at http://developer.cisco.com/web/cdc/home .
Last week, Juniper demoed an OpenStack based solution. Today, Cisco demoed OpenDayLight based solution. SDN is early stage of evolution. From Cisco’s perspective, could you provide thoughts why Cisco is going with OpenDayLight?
Cisco: Cisco has played a crucial role in the both the formation and contribution to OpenDaylight as we believe that through his project we can help establish an open, vendor agnostic approach to building programmatic infrastructure. By establishing a common, industry supported model we give our customers and the development community the needed confidence to accelerate efforts in open networking and SDN.
Note that Cisco has a strong history of supporting industry efforts through open standards development and seeding ecosystems. We will continue to innovate on top of the industry standard efforts to deliver greater value to our customers.
The XNC controller is a good example of this strategy that delivers innovation on a common industry framework.
Cisco is also very active in OpenStack development.
Why should I buy Cisco vs. other solutions?
Cisco: Cisco is the market leader in Data Center Infrastructure and the XNC Controller with its OnePK API extension offers programmability of a much richer set of capabilities than what a standard controller using just OF can offer. This makes a huge difference in type of Applications that can be developed and supported on the controller.
The controller itself has many areas of value add including:
- Advanced Flow Management
- Flow Based Troubleshooting
- Role Based Authentication
- Intuitive User Interface
- Better Scalabilty
And most important full TAC support.
When will XNC support OF 1.3?
Cisco: Support for OF 1.3 on XNC is planned towards first half of 2014.
Doesn’t TIF essentially exploit explicit routing capability?
Cisco: TIF installs policies/rules which complement the Routing Table. Also TIF policies are at flow level granularity while routing table is at destination IP granularity only.
Find the SDN Products that are right for you at our DemoFridays! Watch videos, download podcasts and PDF about leading SDN technologies.
Check out more DemoFriday™ SDN Demos:
- Introducing SDN DemoFriday™: Experience Real-World SDN Solutions
- SDN DemoFriday™ with Plexxi and Boundary
- SDN DemoFriday™: Cloud-enabled Networking–NEC ProgrammableFlow SDN in Action
- SDN DemoFriday™: Plexxi and Boundary Answer Your Toughest Questions
- DemoFriday™: Lior Cohen of Radware Demonstrates Adaptive SDN Based DDoS Protection Solution
- SDN University™ and DemoFriday™ Archives Now Online!
- Don’t Miss May’s DemoFridays™: SDN Emerging Technologies…Live!
- Last Call: May 3rd DemoFriday™: Radware DefenseFlow Adaptive DDoS Protection Solution
- This Week’s DemoFriday™ Plexxi & SolidFire – See Demo & Meet Live Customer
- 5/10 Live Demo With Winning Triad: Plexxi, SolidFire And Customer, CloudSigma