22 SDN Controllers Flashcards
What is an SDN ?
Software Defined Networking controller that centrally manages and monitors the network instead of doing everything manually.
Traditional Network Monitoring
Systems (NMS)
Continuously poll your network devices using SNMP so it can pinpoint any misbehaving devices. The NMS also keeps track of how much traffic is moving through the network, and depending on the exact solution being used, everything from applications to VoIP call quality can be tracked. By default, NMS polls the network devices every couple of minutes. Plus, when an interface goes down on a Cisco router, the router can send an SNMP trap to the NMS. Most NMS solutions can send an email, an SMS text message if someone’s on call for network support, or just display the alert so the Network Operations Center can investigate the issue.
Configuring SNMP
C3750X-SW01(config)#snmp-server community testlabRO RO
C3750X-SW01(config)#snmp-server community testlabRW RW
C3750X-SW01(config)#snmp-server host 10.20.2.115 traps testlabTRAPS
C3750X-SW01(config)#snmp-server source-interface traps vlan 310
C3750X-SW01(config)#snmp-server enable traps
C3750X-SW01(config)#do sh run | in enable trap
Network Health
NMS’s usually show the status of your network with three colors:
■ Green - Healthy nodes with no reported problems.
■ Yellow - Nodes that are up but have reported issues like interfaces that are down, or a hardware issue like a fan that isn’t working.
■ Red - Nodes that aren’t reachable and are probably down.
NMS is configured with lots of default rules defining how a system should treat various events discovered by the SNMP polling.
Central Syslog
NMS solutions can also serve as a convenient central syslog when troubleshooting. On the Syslog page, you can run searches to make it easier to filter exactly what you’re looking for. Syslog messages from a network device can also be used to notify the NMS there’s a network issue. You can even configure rules that will determine how the syslog will react to whatever syslog messages you want. This allows you to make things happen like having the server run a script if the NMS receives an OSPF-related message. All we have to do to configure a Cisco router to send syslog messages to the NMS is tell the router what logging level the router should send traps at.
Interface Information
You can easily view a graphical representation of various interface information through the interface utilization graph.
Hardware Health
When you’re troubleshooting manually, hardware health is notoriously hard to keep track of. The NMS makes life a whole lot easier by presenting us with an easy-to-read graph on our hardware health.
Network Information
The network monitoring system does offers a ton of information about what’s generally up with the network. Two graphs worth highlighting are Response Time & Packet Loss, which is great for troubleshooting those “slow Internet” phone calls, and CPU Load and Memory Utilization. NMS also pulls in intel like CDP information to show you vitals like which devices are directly attached to the switch and which VLANs are on the switch so it can populate other graphs. It analyzes routes within the routing table so it can determine if flapping is happening in your network, where a route appears and then disappears over and over. It culls even more advanced information like if the switch is in a stack or not, revealed in the VLAN table.
Traditional Network Configuration
Managers (NCMs)
It manages your network configuration. Depending on the specific solution, the NCM can be the same server as your NMS, or it can even be an entirely separate server with no integration. The NCM routinely backups your configuration by connecting to each network device and copying the configuration over to the server. Network devices can also be set up to notify the NCM about any changes so the server knows to collect the new configuration. Once the config is on the server, the NCM lets you search through saved configs for keywords, letting you compare configuration to see if there are any changes between saved versions. And you can push out configurations too! The NCM can also push out simple configurations. What’s more, you can even use the NCM scripting language to make configuration templates to effect mass configuration changes across the network. Every type NCM uses a different scripting engine for the template. feature.
Traditional Networking
To really get what Software Defined Networking (SDN) is you’ve got to understand how a regular router sends traffic first. When a router receives a packet, it jumps through several hoops before it can send that packet out towards destination. Before the router can send out traffic, it has to know all the available destination routes. These routes are learned via a static route, a default route, or through a routing protocol. The router will need an ARP entry for the next hop IP address before it can send the traffic. The TTL on the packet will also be decreased by one as it passes through the router, and the IP header and Ethernet frame checksum will also be recalculated before the traffic is sent over the wire. Routers divide these different tasks into three different planes:
■ The management plane
■ The control plane
■ The data plane
Management Plane
The management plane controls everything about loging into a network device including telnet and SSH access. SNMP is also included in the management plane, which allows Network Monitoring Systems to poll the device for information. And HTTP and HTTPs are also part of the plane. APIs are also considered management access including restful API discussed back in the Automation chapter. Ports like the console port, the AUX port, and the management port are also found here.
Control Plane
it’s where all the protocols are run and where all the decisions are made. The goal of this plane is to generate all necessary forwarding information needed to send the packet on towards its destination. So, lots of important things happen in the control plane. Security functions like defining ACLs and NAT, if the packet needs to change its source, or if the destination changed. Of course, everything to do with routing protocols like OSFP, including forming adjacencies and learning the routes, all occur on this plane. ARP is also a big part of the control plane, since knowing how to reach the layer 2 address of the next hop is essential for the actual routing to occur. Other control plane protocols include things like STP, VTP, and MAC address tables on switches, as well as QoS and CDP/LLDP.
Data Plane
The data plane’s job is to take all the information presented from the control plane and use it to send the packet on its merry way. Everything that happens at the data plane directly affects traffic. These are activities like encapsulating and de-encapsulating traffic as it arrives at and leaves the router, adding and removing packet headers as needed, plus actually dropping traffic that hits a deny statement. on a ACL are all data plane tasks. Even the actual forwarding, where the packet moves from the inbound interface to the outbound interface, happen here as well.
Southbound Interfaces
the South Bound Interface (SBI) is how the SDN Controller actually talks with the network device, and there are lots of different ways it can do that depending on your specific solution. For instance, OpenDaylight, a popular open source SDN Controller, uses a protocol called OpenFlow to talk to switches. On the other hand, Meraki uses a proprietary solution right now since they manage everything themselves.
OpenFlow
Describes an industry-standard API defined by the ONF (opennetworking. org). It configures non-proprietary, white label switches and determines the flow path through the network. All configuration is done via NETCONF. OpenFlow first sends detailed and complex instructions to the control plane of the network elements in order to implement a new application policy. This is referred to as an imperative SDN model.
NETCONF
Even though all devices don’t yet support NETCONF, it provides a network management protocol standardized by the IETF. With the help of RPC, you can install, manipulate, and delete the configuration of network devices using XML.
onePK
This is a Cisco proprietary SBI that allows you to inspect or modify the network element configuration without hardware upgrades. It makes life easier for developers by providing software development kits for Java, C, and Python. One PK is now legacy, but it’s still possible to find it in the real world.
OpFlex
This is a southbound API that is used by Cisco ACI, OpFlex uses a declarative SDN model because the controller, which Cisco calls the Application Policy Infrastructure Controller (APIC), sends a more abstract, “summary policy” to the network elements. The summary policy makes the controller believe that the network elements will implement the required changes using their own control planes, since the devices will use a partially centralized control plane.
SDN Solutions
Cisco APIC-EM
This was Cisco’s first real attempt at an enterprise SDN controller, and its main focus was configuring Cisco’s IWAN solution. Considered legacy these days, APIC-EM was succeeded by DNA Center.
Cisco DNA-Center
This is Cisco’s main enterprise SDN controller
Cisco ACI
This is Cisco’s Data Center focused SDN solution.
Cisco SD-WAN
This solution brings the benefits of SDN to the WAN. You’ll learn more about SD-WAN when you tackle the CCNP.
OpenDaylight
ODL is a popular open source OpenFlow controller. Cisco offers a bit of OpenFlow support, but Cisco definitely prefers their own SDN solutions due to OpenFlow limitations.
Controller-Based Architectures
Cisco SDN solutions like Digital Network Architecture (DNA) Center, allows you to centrally manage your network device’s configuration through several applications that live on the SDN Controller. This is better than traditional configuration because if you need to make changes to your network, you just adjust the settings in DNA Center to be replicated to your network’s relevant devices. It ensures configuration is consistent everywhere at once, greatly reducing the risk of a typo when making changes manually. The downside, if you make a mistake on a template thats being pushed to many devices that can cause a huge problem. Controllers also give us a convenient central point for monitoring and automation since they’re usually aware of a large part of the network, if not all of it.
Campus Architecture
Switches are connected to each other in a hierarchical fashion. The upside to this approach is that troubleshooting is easy since the stuff that belongs in each layer of the model is well defined, just like how the OSI model makes it easier to understand what’s happening on the network and where. All the endpoints in the network connect to the access layer where VLANs are assigned. Port-level features like port security or 802.1X are applied at this layer. Since access layer switches don’t have a lot of responsibilities and generally, no layer 3 configuration aside from what’s needed for managing the switch, you can usually get away with cheaper layer 2 switches and save some coin. The Distribution layer hosts all the SVIs and provides any IP-based services the network needs like DHCP relay. The distribution switch uses layer 2 interfaces with the access layer switches to terminate the VLANs, plus layer 3 interfaces to connect to the core switches. It will also a run a routing protocol to share routes with them. The core layer’s only job is providing high speed routing between the distribution switches. It doesn’t offer any other services—it just makes sure packets get from one switch to another.
Spine/Leaf Architecture
The new and preferred architecture for controller-based networks and data centers is called CLOS, which stands for nothing other than the guy’s name who thought it up. CLOS is a spine/leaf design wherein you have two types of switches: a spine and a leaf. The Leaf switch maps to the access and distribution layers in the Cisco 3 tier model and is what you connect your devices into. Each leaf switch has a high-bandwidth uplink to each spine switch. The spine switch is a lot like the core because its sole job is to provide super fast transport across the leaf switches. Because leaf switches only connect to the spine switches not other leaf switches, traffic is really predictable since all destinations in the fabric follow the same path: Leaf -> Spine -> Leaf. Because everything is 3 hops away, traffic is easily load balanced in the routing table via equal-cost load balancing (ECMP). What’s more, it’s also very easy to expand the network. If you need more ports, just add a leaf switch. Need more bandwidth? Just add another spine switch.
SDN Network Components
One of the benefits of Software Defined Networking is that a SDN controller can abstract away the “boring stuff” so you can focus on the fun more complex configurations. One of the ways SDN achieves this is by dividing the network into two different parts. An underlay, this is the physical network that is focused on providing a lot of layer 3 connectivity throughout the network. The underlay typically uses the spine/leaf architecture we just discussed but can also use the campus architecture depending on the solution being used. For example, DNA Center’s Software Defined Access solution is based on a typical campus topology because it is aimed at enterprise networks. SD-Access does use slightly different names though, the access layer is called the edge, and the intermediate node is the equivalent of the distribution layer but we don’t need to worry too much about that architecture. There is also the overlay component, which is where the services the SDN controller provides is tunneled over the underlay.
Underlay
■ MTU
■ Interface Config
■ OSPF or IS-IS Config
■ Verification
So the underlay is basically the physical network that provides connectivity so that the overlay network can be built upon, or over it. There’s usually basic configuration on it and its focus is on advertising the device’s loopback IP into OSPF or IS-IS is another link state routing protocol that is beyond what we need to learn for the CCNA. Devices in the underlay tend to be cabled so they’re highly redundant, removing single points of failure and optimizing performance. One way to implement this is via a full mesh topology, where every device is connected to every other device. Even though a full mesh network provides maximum redundancy, it can get out of hand fast because of the number of links involved as your network grows.
MTU
The Underlay’s job it to carry a lot of traffi c with larger packet payloads than you’d normally see in a standard network. Because of this, it’s a good idea to raise the MTU on the underlay switches so the larger packets don’t give you any grief. You change the MTU on most Cisco IOS or IOS-XE based switches via the system mtu command. The switch must be rebooted for the change to take effect.
Interface Config
It’s a bad idea to go with Spanning Tree Protocol in an underlay topology because its job is to block redundant links—a problem, because it results in the underlay switch’s superfast uplink interfaces that clock in between 10gbs, 40gbs, even 100gbs, not always being used. What a waste! You can sort of mitigate this by spending (wasting) a bunch of time adjusting the STP confi guration by spreading the VLAN root across several switches, but it really won’t solve the problem because each VLAN will still have blocked links. The better way to handle this is to use only layer 3 interfaces. Doing this means STP won’t run at all, meaning all the switch interfaces in the underlay will also run without being blocked. Plus, there won’t be any loops to worry about since its just OSPF or IS-IS doing the routing. And as a further bonus, because the switches should all have the same number of connections, the routing table can load balance traffi c using Equal Cost Load Balancing (ECMP)! So with all that in mind, I’m going to confi gure the interfaces connecting the switches together as layer 3 interfaces and give them an IP address. To be more effi cient, I’ll also configure OSPF on the interfaces to use the point-to-point network type in order to remove the need for a designated router.
Overlay
Basically, an overlay is a “virtual network” that’s tunneled over your underlay devices. This allows the SDN Controller to have strict control over the traffic running through the network. The type of tunnel being used varies depending on the exact SDN solution, but generally it is Virtual Extensible LAN (VXLAN) being used. VXLAN is a way of tunneling Layer 2 traffic over Layer 3, this allows you to connect VLANs across routed networks, but the details are above the CCNA level. The overlay is where the advanced configurations like security or QoS gets introduced into the network. The underlay has no visibility into the tunneled networks so it can’t effectively do things like filtering traffic. Routing for the overlay is usually handled by BGP or EIGRP. Going with link-state protocols is a bad idea because they require all devices in an area to have the same LSAs. Plus, you can’t easily improve the routing table with summaries, etc. Dynamic Multipoint Virtual Private Network (DMVPN) is a very popular type of overlay that runs over the WAN. In this topology, each branch connects to the hub router through DMVPN using the 10.100.123.0/24 network, allowing us to run an IGP across the Internet to provide that all-important, consistent routing factor. DMVPN actually offers lots of advantages.
Fabric
It’s really just a shorthand term for all the layer 3 network devices—the routers, switches, firewalls, wireless controllers access points involved in a solution. We can refer to the network as a fabric when we’re talking about SDN because the network details are abstracted by the SDN Controller. Put another way, a fabric is a simple, high-speed, layer 3 network. The motivation behind this trend is that IP networks scale better than layer 2 networks because we don’t need to work a bunch of complex engineering magic to get around STP limitations. Also, layer 3 fabric isn’t usually so risky when it comes to misconfigurations because the SDN Controller dynamically builds and maintains the underlay and overlay networks for you!
DNA Center Overview
Basically, the whole point of DNA Center is to be your one-stop shop for managing all networking and troubleshooting needs. In that vein, DNA Center provides full network monitoring just like we talked about in the NMS section, only more. In addition to the SNMP monitoring and storage for statistics, DNA Center captures a complete snapshot of your network for up to a week—pure gold when troubleshooting network snags of any stripe! DNA Center even offers troubleshooting advice to help you resolve complex issues by taking advantage of AI/Big Data analytics to help you make decisions. The server has a robust NCM component that can not only do configuration apply templates, it takes things much further by allowing you to automatically configure switches just by taking them out of the box, connecting the network interfaces, and powering it up! As if that wasn’t enough, DNA Center is also an actual SDN Controller, fully capable of building out underlay and overlay networks in order to support Cisco’s Software Defined Access feature. And Cisco is continuously adding new features and application integration to the solution. For example, DNA Center can replace APIC-EM by managing IWAN, a legacy SD-WAN solution through an SDN application. The server can also centrally manage the WLCs in your network and will be able to eventually manage other Cisco solutions like SD-WAN or ACI down the road.
Discovery
To make our lives easier, DNA Center can dynamically search the network for the devices to add so we don’t have to add them all manually. The Discovery feature works by querying IP ranges you specify or by logging into a device and following its CDP/LLDP information throughout your network. Once DNA Center has detected devices, it’ll try to access them with SNMPv2, SNMPv3, Telnet, SSH, HTTP(S), and Netconf to gain control of the device and add it to the inventory. Discovery jobs can be scheduled to run as often as you want to ensure all your Cisco devices are managed by DNA Center. You can also create multiple jobs in case you need to use different connection options in other parts of your network. So while it’s true that other NMS solutions can usually discover nodes in the network, DNA Center again takes things a step further by serving up a lot of robust options for protocol support. Another cool factor comes down to licensing… When you buy a solution like SolarWinds or Prime Infrastructure, you’ve also got to pony up for licensing to be able to add nodes. And SolarWinds charges you for every little element you add, even a measly network interface. Just imagine you have four switches in a stack and each one of them has 48 interfaces. That comes to a whopping 192 licenses required to add all those interfaces into SolarWinds for monitoring! Because of this, most SolarWinds deployments focus only on adding vital interfaces like uplink ports. But with DNA Center, life is so much better because each device has the proper license installed locally, which is something you can take care when you order the device from your Cisco partner. Contrast all of the above if you aren’t using an NMS. You’d have to manually keep track of your network devices with either an open source solution or maybe just an Excel spreadsheet that you edit when you make changes to your network!
Network Hierarchy
A wonderful benefit DNA Center brings is allowing us to organize our networks into sites and locations using the Network Hierarchy feature. This gives us another troubleshooting advantage, provides site survey information to Wireless Controllers, and also provides configuration consistency across various locations. Common settings like Authentication, Syslog servers, NTP Servers, or the Message of the Day can be automatically pushed to network devices when they’re added to the inventory. This feature ensures that there’s no stale configuration on random routers after the NTP server has an IP change because we can just update the value for the DNA. DNA Center can also fully manage your wireless environment so any WLC configurations, like when you add a new SSID, can be done in the Network Hierarchy tool. This makes it easy to create wireless configurations to apply to multiple WLCs. A traditional NCM like SolarWinds has a similar feature to Network Hierarchy called Compliance. It allows you to define which configuration should appear on a network device, with the NCM alerting you if the device doesn’t have that configuration. The difference here is that the compliance feature won’t usually push the configuration to ensure consistency. NCMs rarely allow you to group network devices in a hierarchy. Instead, they typically make you manage each device independently. NCMs generally can’t centrally control your wireless controllers either since that requires deep vendor knowledge to make happen. Whereas, DNA Center uses that in-depth knowledge to offer plenty integrations into Cisco devices beyond just wireless! One caveat is that DNA Center doesn’t yet support device configuration backups. Because of this we still need to use SolarWinds or Prime Infrastructure to handle device backups. But there’s some rapid development going on with DNA Center so maybe a nice backup feature will be available by the time you read this sentence. It kind of goes without saying, but if you’re doing all this manually, you’d have to be logging into all your network devices almost constantly to verify that the configuration is still current and meeting your needs. Configuration changes over time as you troubleshoot issues or execute changes on devices.
Templates
When you need more specific configuration pushed to network devices, you can apply Template features to a Network Hierarchy location. The Template feature allows you to type out the IOS configuration you want applied and to make things easier it also supports the Apache Velocity scripting language. Apache lets you make your templates more powerful by adding more functionality into your configuration with some cool little tools like: Variables Variable can be defined anywhere in the configuration by adding a dollar sign in front of a word. In the screenshot example, I created a variable called loopback_ip so I can have a different loopback interface IP on each network device. Enable Mode By default, DNA Center will assume everything in the template is a configuration command. If you need to push an enable command like clock set you can put the command between #MODE_ENABLE before the command and #MODE_END_ENABLE after it like this: #MODE_ENABLE clock set Sept 17 2019 00:00:00 #MODE_END_ENABLE Interactive commands Most commands in IOS don’t prompt the user for additional input but some, like the banner motd or the crypto key generate rsa general-keys commands, do. If you need to push such a command, you can put #INTERACTIVE at the top and #ENDS_INTERACTIVE at the bottom. This can get a little confusing, so I’m going to give you an example to bring it all home to you. For the interactive portion, I put a <IQ> after the command, and followed by the expected prompt values, you’d enter your response after the a <R>.</R></IQ>
Topology
DNA Center likes to build a layer 3 diagram using the network devices it knows about. This is great because we get to reference a dynamic network diagram when troubleshooting instead of only relying on some Visio diagram that’s probably way out of date! It creates its diagrams with the information provided by CDP and LLDP, and it also follows the MAC and ARP tables to figure out what’s connected. If the map isn’t entirely accurate, you can tweak it manually. DNA Center also needs to know the topology so it can inform other features like SD-Access. Good to know is that while NMS solutions can create network maps, they’re often created manually by the network team. For instance, SolarWinds has a network map creator used to arrange the network devices into the network topology you want to see in the dashboard. The thing is, doing this manually means maintaining a network topology made in Visio, and as implied, these almost always get out of date fast. As far as I know, no one has ever met anyone chomping at the bit to obsessively make sure the documentation is current! To everyone’s relief, DNA Center tries to improve life by dynamically creating the network topology for us. It discovers network devices and adds them to the map in an intelligent way. True—you’ll definitely still need to customize the map to make sure its accurate, but it does the heavy lifting for you.
Upgrades
Another thing that will scatter everyone on your team is when you need to upgrade a device’s firmware. This is painfully boring: You must find and download the proper IOS image for your device, copy the image onto the device, set the boot statement, reboot, and then… WAIT. Now while upgrading a router or two doesn’t sound so bad, things can get really get out of control if some security vulnerability is discovered within the IOS you’re using. Yep— just like that, now you’ve got a hundred routers you need to upgrade—fast! Upgrading is usually a big part of onboarding a new router too since the IOS that ships on a router is probably not the same version you actually want to be using on everything. Breathe easy because DNA Center can allow help you standardize the IOS versions you’re using on all your network devices by making sure new network devices are automatically upgraded to the version you want. This feature allows us to download images directly from Cisco.com or manually upload them and it also points out the suggested IOS release for the platform. DNA Center will move the image onto the device using SCP or HTTPS, which is a heck of a lot more efficient than trying to use TFTP across the network. What’s more, when you schedule an upgrade, DNA Center will go through a bunch of checks to make sure the device is going to support it. Here’s a list of the Device Upgrade Readiness Pre-checks: Precheck Description Device management status Checks if the device is successfully managed in Cisco DNA Center. File transfer check Checks if the device is reachable through SCP and HTTPS. NTP clock check Compares device time and Cisco DNA Center time to ensure certificates from DNA Center can be installed on the device. Flash check Verifies if there’s enough room on the device for the update. Some devices support the ability to automatically cleanup flash to try to fit the update file in by deleting unused files. Config register check Verifies the config registry value, ensuring the switch will boot properly if you forgot to fix the config register after a password recovery. Crypto RSA check Checks whether an RSA certificate is installed. This is required for SSH and HTTPs to work. Crypto TLS check Checks whether the device supports TLS 1.2. Precheck Description IP Domain name check Checks whether the domain name is configured, which is required for SSH and HTTPs to work. Startup config check Checks whether the startup configuration exists for the device. Service Entitlement check Checks if the device has valid license. Interface check Checks the status of the device’s management interface. CDP neighbors check Displays information about the connected routers and switches in the network discovered using CDP. Running Config check Checks the configuration that’s currently running on the device. Spanning Tree Summary check Checks the information about the Spanning Tree Protocol (STP). AP Summary check Displays the AP Summary associated with the Cisco Wireless Controllers devices.
comparison: NCMs / DNA Center
NCMs can push IOS images to Cisco devices too, but they generally don’t have as many sanity checks and safety precautions that DNA Center does. For instance, SolarWinds basically just pushes a copy tftp command to the device to download the firmware, and depending on your script, it’ll also change the boot statement and reboot for you. And of course, SolarWinds doesn’t have direct access to cisco.com to download the firmware for you, so you’ll need to download the file manually and store the file on the server. Doing this manually is fairly labor intensive because not only do you have to download the file, you’ll probably need to set up a TFTP/FTP/SCP server to transfer it. Then you’ll have to manually log into the device to start the upgrade.
Command Runner
One of the beautiful benefits of central management is that you can take advantage of the fact that DNA Center can access many devices at once to do get something done. The command runner tool lets you to run a bunch of commands against devices in your inventory and store the results. This comes in handy when you need to quickly verify information across your network devices, like when you want to be sure all your routers can see a new OSPF route! Another pro is that the output can also be exported as a text file in case you want to store it or use it in a document. Configuration commands are not supported though, so you’ll need to use the template feature if you want to push changes to the device. Both DNA Center and NCMs have similar functionality for this feature. Both can push commands to several devices and present the output to you all tied up in a bow. If you aren’t using a solution, though, there you would be, connecting to each device, one at a time and saving the output on a Notepad or a email to send later.
Assurance
Sadly, blaming the network when it usually isn’t at fault is rampant in this field. A huge amount of your time is going to be spent troubleshooting network issues based on vague, outdated, and incorrect information. Let’s say a manager comes up to you at lunch saying he couldn’t connect to the corporate wireless a few days ago on his laptop but it works fine now. How would you troubleshoot that one? Well, you could check ticketing to find out if there was an outage at the time that could explain the snag. If you don’t have any tickets to rummage through, maybe your team members will remember something, right? Of course, you could also log into the wireless controller or Cisco ISE if you’re using it for wireless security and check there for any logs, but it’s pretty hard to find relevant logs from a few days ago and even harder to correlate them! What about trying to replicate the issue on your laptop? That’d be a tough one unless the issue consistently pops up. You’d be stuck trying to connect at random times in the day in different locations to try to hit the issue. But all that was before you were armed with DNA Center’s Assurance feature… This amazing tool actually gives you access to a time machine! It stores loads of network information for a week—everything from logs, network health issues seen on the network, and connection results—all stored and ready for you. The Assurance feature also correlates issues and provides suggestions on what the cause probably was, even offering troubleshooting tips about the steps you can try. This is so good because it makes it possible to troubleshoot glitches that slipped by your radar since users can just get used to it taking three tries to connect to wireless before it works so they never even mention it! DNA Center’s Assurance feature is unique, and it’s no small thing. NMS solutions can give you a lot of great information, but only DNA Center can carry out full analytics to give us a solid network time capsule snapshot right now. And doing this manually turns you into a gumshoe relentlessly grilling users for information and stuck doing a bunch tests to possibly hit on issues. You may even be reduced to mindlessly fishing through configurations hoping something jumps out at you!
Path Trace
The path a given user’s network traffic takes through the network isn’t always so straightforward today. Back in the day, traceroute was a go-to way to determine the path a user is taking to get to their destination. But it won’t show you that that wireless traffic is going through a CAPWAP tunnel or that a site is connected through a VPN or a DMVPN. Traceroute also won’t reveal the layer 2 switches that the packet must travel through. Path Trace is an evolution of the APIC-EM Path Trace feature that was on the previous CCNA. It takes advantage of the fact that DNA Center knows everything about all the network devices in your network and gives you a visual representation of the path taken from source to destination. The tool reveals the true path tunnels take and shows you if any ACLs on network devices will block your traffic. You can even specify which ports you want to test. This is another feature that’s unique to DNA Center and APIC-EM if you happen to have that in your network. Solarwinds has something similar called NetPath, but it works by using agents you deploy throughout your network. DNA Center uses the firsthand information it collects from the network and as said can detect ACL issues. SolarWinds can’t do that. An important point here is that the things Path Trace does can’t really be done manually either. Sure, you can run some utilities like tcptraceroute or hping3 on Linux, but these methods have limitations regarding UDP traffic and they won’t serve up a graphical display of the path traffic takes!
EasyQoS
Quality of Service can be tough to implement and maintain. DNA Center includes the successor to APIC-EM’s EasyQoS feature, which lets you to simplify your QoS policies by grouping applications into three categories instead:
■■ Business Relevant: applications important to your business like Email or Active
Directory.
■■ Business Irrelevant: applications with no business value like BitTorrent, YouTube and
FaceBook.
■■ Default: applications that aren’t in the other two categories, like DNS or Database
traffic.
You can move applications into whichever category works for your network. After all, if you work for YouTube, then YouTube may very well be business relevant! DNA Center will take your Application Policy and convert it into a QoS one that handles all the components for you. All you need is to adjust the DSCP and bandwidth allocations for your connections and you have a consistent QoS policy applied across your network. By the way, this is another feature unique to DNA Center. NCMs can push QoS policies that you create, but they aren’t designed to let you to easily manage your end-to-end QoS policies like DNA Center does. And here again, doing this manually can be majorly complex task that needs to be planned out very carefully. Every network device, including routers, switches, wireless controllers, and even firewalls can all be part of the QoS policy and therefore must be adjusted.
LAN Automation
Up until now if we wanted to add a new network device to DNA Center, we would’ve had to make sure the device could reach the server. We also needed to have authentication, SSH, and SNMP set up so the server could connect to the new device. LAN Automation eases the pain by allowing new devices to be set up automatically via Cisco Plug and Play (PNP). This feature works by creating a DHCP server on the upstream network device, which then passes an IP address and the PNP server information on to the new Cisco device when it boots. From there, DNA Center automatically sets up basic routing and other things that should go on an underlay device like multicast. Once it’s done, the new device will appear in DNA Center in the proper site. Here we have yet another feature that’s unique to DNA Center. Because of the deep integration required to make PNP work, other NCMs just can’t compete in this area! To go about this manually, you’d have to manually put the configuration on the router before you ship it to its destination—the risk here being that if there are any configuration errors, a-troubleshooting you’ll go before the device can get online.
SD-Access
Software Defined Access is really the flagship feature of DNA Center. Essentially, it lets you to make use of intent networking to state that the Marketing team doesn’t get to access the IT team’s resources—let DNA Center “figure it out.” The actual solution under the hood is extremely complex and uses a plethora of features that are well out of the scope for the CCNA. Even so, DNA Center makes it easy for even a junior to manage a network that would normally require a much more senior team to keep it up and running! Since SD-Access is Cisco proprietary, there’s no way for a NMS or NCM to do something similar. You can manually configure the network features that comprise SD-Access, but you won’t be able to easily manage it with a web interface!
Restful API
Everything in DNA Center can be managed by REST. This makes it really easy to have your scripts contact DNA Center instead of having to individually connect to devices to get information. A neat feature is Code Preview. DNA Center lets you test drive Restful API through the web interface so you can get a feel for the kind of information it will give you. The web interface can even generate Restful API code snippets for you in several languages including Python!
SDN Architecture
Software Defined Networking (SDN) solutions tunnel traffic across the underlay devices using an overlay. The underlay provides connectivity for the tunnels to be able to be formed. The overlay provides the actual services to the fabric. The fabric is simply a term for all network devices that use the SDN solution.
Controller-based Architecture
Rather than managing your network devices individually, you can use a controller-based solution that allows you to centrally manage everything instead. This improves efficiency since you can configure a large number of devices at once and also reduces the risk of configuration errors because your changes aren’t applied immediately and can be reviewed. It also ensures configuration for all your network devices is consistent. Controllers also provide a great single point to monitor or script against since it knows about most or all of your network fabric. SDN Controllers communicate with the network using a southbound interface towards the devices and a northbound interface to permit access to the SDN Controller.
DNA Center
DNA Center is the successor to APIC-EM and provides SDN and controllerbased features to your network. DNA Center can ensure your configuration is consistent and make sure QoS is working properly and is set up on all devices in the network. The assurance feature provides a unique time machine to view issues that happened up to a week ago.
