By Andrew Boring When you’re using curl to interact with the APIC API, or even if you’re using a toolkit/library to create applications, you may want to know which APIC API methods and objects are available for a given task. Yeah, yeah. RTFM. You know what’s up. You’ve already done that. You’ve read the Cisco APIC REST API Configuration Guide, at least until your eyes started to blur and lose focus. Here are a few quick ways to get the APIC API info you need for the task you’re doing right now. And you can even do it while your boss is peering over your shoulder looking slightly confused at your elite command-line skills. APIC API Inspector The first method is the API inspector. Clicking on the gear sprocket in the upper-right corner provides a menu of Helpful Options. Select API Inspector to open a small window showing each API call for everything you click on in the GUI. Want to know how to get a list of tenants? Just turn on API Inspector, click on the Tenants menu, and watch the API calls scroll by. Want to know what API activates/deactivates a check box option? Just navigate to the screen, make the settings change, and submit it to get the right POST call. Change it back to confirm it (this will include some helpful POST data as well). Some GUI screens will consist of many API calls, for example dashboard screens retrieving health status, so you’ll need to read through the calls carefully. You may wish to uncheck the box “Scroll to latest” to prevent GUI screen refreshes from scrolling additional API requests in the Inspector while you’re trying to read. The Save As/Post If you used the API Inspector to find the object, but are having trouble figuring out the exact POST data you need to send, the Save As option will conveniently download the configuration data in your choice of XML or JSON file. You can make the necessary changes and use POST within the GUI or via curl to test the change directly. Right click on the object, select “Save As…”, and then select your options in the modal dialog. Content: All Properties vs Only Configuration – Shows whether you want to retrieve just the relevant properties to a configuration, or all properties, including objects and attributes indicating relationships to other objects. Scope: Self vs Subtree – Determines whether you want just the object itself and its attributes, or the object with attributes AND its child objects, with attributes. Export Format: XML vs JSON – Indicates your preferred text format, eXtensible Markup Language or JavaScript Object Notation. Normally when we are saving configuration to post back we want to select ‘Only Configuration’ since ‘All Properties’ may contain values that the APIC won’t accept when you ‘POST’ back. Subtree is often the preferred option over Self, but if you’re working with just the object-level attributes, saving just Self will work fine. You can certainly save both and compare the two. After saving the file and editing its contents, you can use the Post option to effect the change. Be careful with your objects though! In the example above, we’re operating on the exact object we wish to change. In other cases, the object itself might not exist (yet), so we’d need to POST back to the parent object. For example, the DN of a tenant object won’t exist until you actually create the tenant. So if you want to use an existing tenant configuration, you can save a tenant config, modify it for the new tenant configuration, but POST it to a new object based on your desired configuration. For example, let’s save a Tenant: In the example above, we want to save the COAST user as tn-COAST.xml and modify the contents to create a tenant named Andrew. But tn-andrew does not exist! So we’d want to modify the XML file to change the DN from “uni/tn-COAST” to “uni/tn-andrew”, and the name from “COAST” to “andrew”. We’ll save as the Configuration Only, Subtree, and XML. Changing the DN and name attributes of a tenant object. Once we’re ready to POST it back, we need to remove the tn-COAST object, and either leave it as “uni” (the parent DN) or add the “tn-andrew” to explicitly tell it which object we want to operate on. I recommend including the object name to match to keep the practice consistent with operating other objects where it’s explicitly defined. Visore You may have tried curing insomnia by reading the APIC Management Information Model Reference instead of counting sheep. I recommend melatonin supplements instead, and save the MIM Reference for when you have some coffee to help you get through it. In the meantime, the APIC also has an online/searchable utility to display objects, too. Just click on the sprocket menu in the upper-right corner where you found the API Inspector (see above), and select Object Store Browser instead. A new tab/window will display the Visore object store browser. Finally, in the same sprocket menu of “Helpful Things” in the upper-right corner, there is an option to “Show Debug Info.” Enabling this will use the status bar of your browser (usually the bottom edge of the window) to display the object name when you hover your mouse over it.   We’ll include more info on using Visore and the Show Debug Mode in a future post. That’s all for today’s blog! But more to come on ACI right here on the ACI Board on Cisco Community.   In the meantime, please drop a comment and let us know if this walk through of the APIC API was helpful. Feel free to even comment below on ACI topics you’d like to see discussed here in the near future! ... View more

By: Jody The vast majority of ACI customers do not start out with an Application Centric deployment of ACI; mainly because they do not have a clear understanding of their applications and the vast amount of interdependencies. However, with the advent of Tetration and other 3rd party analytics tools, the knowledge about how your applications are connected is increasing and customers are looking to migrate some apps from the “Network-Centric approach (Vlan=EPG=BD) to a full ACI-Centric model. Let me be clear; The Network-Centric model serves many customers well. It allows them to migrate their existing compute/applications/network into ACI in a way that is familiar and well understood. Customers operating their fabrics in a Network-Centric model continue to gain numerous benefits from ACI, such as Single Pane of Glass management from the UI, elimination of box-by-box mgmt of the entire data center, the ability to upgrade the entire fabric (APICS+Switches) from one location with ease, decreased time to resolution during issues due to the availability of consolidated faults and health scores, etc. However, for those customers who want to take their ACI deployment to the next level, moving applications into an ACI-Centric Model is one of the next logical steps. Below, we will discuss a sample methodology for moving applications into an ACI-Centric Model.   Here are 8 assumptions before we begin: 1) This document assumes that the customer has the data needed to build out the application profiles for their ACI-Centric application.   2) This data can be obtained in several manners, such as:   Application Dependency mapping via Cisco Tetration Analytics Cisco Advanced Services ANP Analysis Service Customer knowledge of applications 3rd party tools   3) Network Centric Mode is currently used (Network-centric means 1 vlan = 1 bd = 1 epg)   All legacy vlans that will be a part migrated to the ACI-Centric application exist on the fabric (or will be operational prior to the migration to aci-centric implementation). All legacy vlans exist on the L2 trunk between the Legacy network and ACI fabric New ACI-Centric Vlans will live exclusively inside of ACI (do not extend the ACI-centric vlans outside of ACI)   4) VMM Integration to the ACI Fabric must be completed before moving VMs from the Legacy network to the ACI Fabric. Pre-work includes, but not limited to, installation of additional connectivity from FIs to the ACI Fabric, configuration of ESXi vnics, and OOB connectivity. 5) L2 connectivity traffic between the ACI Fabric and Legacy network should be monitored before, during and after migration. 6) All L3GW functionality for applications will migrate from the Legacy network to the ACI Fabric prior to activation of ACI-Centric EPGs.   7) EPG to EPG communication is a permit any. << Highly recommended; Contracts for ACI Centric-mode should be configured last 8) DHCP Labels are created prior to migration Here are 10 generic migration guidelines. The following guidelines should be followed when migrating applications to the ACI Fabric. 1) Map existing Vlans into ACI in Network-Centric Mode (L2 only – no contracts) Create legacy EPGs and BDs on the ACI Fabric. BDs will be initially created as L2. L3GW functionality will remain on the legacy network until after L3GW Migration.   2) L2 BD configurations – For each of your bridge domains, it is recommended that they are configured with the following:   IP Subnet check is enabled Flood is enabled (for migration) ARP flooding is enabled (for migration) BD is associated with respective VRF and L3out Unicast Routing is DISABLED at the BD level IP address and VMAC are configured on the BD   3) Create static bindings for the Legacy EPGs on the L2 trunk between the ACI Fabric and Legacy network   4) Identify list of servers (both bare-metal and VMs) present in the legacy network that will be migrated to ACI.   5) Create L3out for Tenant and establish routing availability from ACI to legacy environment   6) Migrate L3GWs for legacy Vlans into ACI Fabric Validate routing from inside the ACI Fabric and outside of the ACI Fabric.   7) Create New Application Profile and EPGs from application data analysis   Associate New EPGs with the proper BDs Associate new EPGs with the proper VMM Domains for VMs Configure static bindings for Physical devices   8) Migrate Servers – Servers associated with the various application will move to the ACI Fabric and be associated with the specific EPG designated based on the output of the data analysis.   Bare Metal VMs 9) Deploy ACI-centric contracts (optional)   10) Perform Cleanup   Remove unneeded EPGs Remove L2 connections to legacy environments (once all migration of services is completed)   Here’s a sample migration of the application “NewApp” to an ACI-Centric Model. The diagrams below represent a “story-board” approach of how we would migrate an application into ACI. Network-Centric Mode In general, I would recommend the “crawl/walk/run” approach to ACI deployments. For the application below, there are different components spread across (3) different Vlans, vlan 5, 6, and 7. So the first step (crawl) is to migrate these Vlans in the ACI-fabric in a network-centric approach, meaning that we will implement an approach where Vlan=EPG=BD.   L3GW Migration Once we have all of the L2 Vlans available on ACI (EPG/BDs are created, and an L2 trunk is configured between ACI and the Legacy environment), we can then migrate the L3GW services to ACI. This involves creating a L3out (External Routed Network) from ACI to the outside network, and then migrating each Vlan/Subnet to ACI, one at a time.   ACI-Centric component creation Now that we have L3GW functionality, we are fully operating in a Network-Centric model for our Vlans. Next, assuming we have the data that shows us how to deploy our application in ACI-Centric mode, we will take that data and configure our new Application Profiles, EPGs, and Contracts (to be used later) into ACI.   Server Migration into new ACI-Centric EPGs Now that we have EPGs built for our ACI-Centric Application, we can begin moving servers (both bare-metal and virtual) into the EPGs. This also serves as an opportunity to determine if we need to remove unneeded EPGs (i.e., EPGs with no endpoints) from the fabric.     Decommission of Legacy components Once all endpoints have been removed from a legacy network-centric EPG, such as Vlan5_EPG, it can be deleted. Additionally, once all servers have been migrated off of the legacy infrastructure, the L2 trunk between ACI and the Legacy network can be decommissioned.   A couple of caveats…   DHCP relay is only available on the primary subnet for a BD; if multiple subnets are needed on a BD, keep this in mind, as DHCP relay will only be forwarded to a DHCP server on the primary subnet Do not combine multiple external Vlans into one ACI BD and extend those vlans outside of ACI. Consider the case where you have two legacy Vlans (Vlan 11 and Vlan 12) with HSRP configured, and L3GW functionality on the non-ACI equipment. The HSRP hellos from both Vlan 11 and Vlan 12 would be visible to each and result in problems.   And that wraps up today’s blog! But more to come on ACI right here on the ACI Board on Cisco Community.   In the meantime, please drop a comment and let us know if this migration piece was helpful. Feel free to even comment in ACI topics you’d like to see discussed here in the near future! ... View more

By: Jody   Hey folks! Welcome to another blog where we tackle yet again, another ACI topic. I was going to create a detailed configuration guide for Multi-Pod, however, after checking out the Cisco ACI MultiPod Configuration Whitepaper on CCO, I realized I would be duplicating efforts at best. The configuration whitepaper on CCO contains detailed configuration examples for the IPN and screenshots from the APIC. If you are looking to deploy Multi-Pod, this is what you will want to use! So instead, I have worked to collect important caveats, design guidelines, and requirements that can serve as a one-stop shop for ACI Multi-Pod deployments.   Why Multi-Pod? Before we dig in, let’s examine some of the benefits that come with deploying ACI Multi-Pod.   ACI Multi-Pod allows for fault isolation of Control Plane Protocols inside of each respective Pod (IS-IS and COOP protocols operate intra-Pod). This is important because it ensures that a routing or protocol issue in one Pod will not take down the entire fabric. Centralized Management through one APIC Cluster (Cluster of 3, 5, of 7). Eliminates fate sharing if one DC goes down End-to-end Policy Enforcement Pervasive GW across all leafs in all Pods   Here are some hardware and software requirements   APIC Software Requirement   2.0(1) on APIC 12.0(1) on Leafs and Spines Ability to change MTU for Inter-Pod traffic (CPU generated traffic) – available starting with 2.2(2e) 50msec latency across Pods – Supported starting 2.3(1) APIC Hardware Requirement   Any APIC Model All Nexus 9000 Platforms for Fabric nodes   Here are IPN node options While the list below is not all inclusive, it gives a quick reference of platforms that can act as Inter-Pod Node devices.   Nexus 9200, 9300-EX or later (not first generation 9300/9500). Nexus 7000 ASR9k ASR1k   Regardless of which one you go with, the IPN device must support the following:   OSPF PIM Bi-Dir (will handle Unknown unicast, multicast and broadcast traffic)Jumbo MTU (will allow for VXLAN encapsulated traffic between Pods) DHCP Relay (will allow for Spine and Leaf nodes to be discovered across the IPN) QOS (will support the prioritization of APIC-to-APIC communication over the IPN) Support for 40/100G interfaces (or 10Gig with QSA adapters on the Spine) Here are the Multi-Pod scalability numbers   2.2(x) – 10 pods / 200 leafs per pod /No more than 400 leafs per fabric 3.2(x) – 12 pods / 200 leafs per pod / No more than 400 leafs per fabric Multi-Site vs Multi-Pod from an Availability Zone / Region perspective First, some definitions (courtesy of AWS). If you’d like to know more about AZs/Regions on AWS, check that out here. Regions: Geographically separated areas, each of which can be comprised of multiple availability zones. Availability Zones: Locations within a Region that are designed to be isolated fault domains which provide low latency network connectivity to other Availability zones in the same Region. Note: What you read below is not mandate for every use-case of a Multi-Pod or Multi-Site design, rather it is a guideline that you can use when deciding which is more appropriate for your overall design. When it comes to mapping the Availability Zone / Region concepts to ACI designs, here are 5 things to keep in mind:   Each “Fabric”, which is made up of multiple Pods, is considered a Single Availability Zone. Configuration Zones (an ACI concept) can be used to span certain switches in your fabric, and can be used to map the configuration zone to an availability zone (applies to configuration and policy only). “Multiple Fabrics (whether a single Pod or Multi-Pod) connected by Multi-Site” is considered a Region with multiple Availability Zones. The original use case for Multi-Pod is to have multiple “pods” of ACI at a customer location, linked together via Multi-Pod (i.e., AZ in one Region) Multi-Site allows you to manage and connect multiple sites (Several Fabrics) via the Multi-Site Orchestrator (MSO)*   * The ability to connect Multi-Pod Fabrics with Multi-Site became available beginning with APIC 3.2 code.* Check out this Multi-Pod vs Multi-Site at a glance. Here are 4 Guidelines and Limitations:   Spine switches must have an active Leaf facing link (LLDP up), otherwise it is deemed unused and cannot be used cannot be used by the fabric. LLDP must be enabled on the IPN switch. At least one Spine must be configured with BGP-EVPN session for peering with remote Pod(s). For Production environments, you should have redundant connections. Up to 50msec RTT between Pod(s) is supported (this support was added beginning with the 2.3 software release). Here are 2 Caveats:   1) Traffic loss for Multi-Pod traffic after a Spine reboot (CSCvd75131)   In a Multi-Pod setup when a Spine switch is rebooted, traffic should not flow through the switch for 10 minutes after its routing protocol adjacencies come up. This is achieved by advertising a high metric into OSPF and IS-IS for 10 minutes. This works fine for OSPF, but not for IS-IS. The problem is that within the Cisco APIC, the default metric for routes redistributed into IS-IS (such as the remote POD TEP pool) is 63.   This also happens to be the max-metric that can be set for redistributed routes into IS-IS in Cisco APIC. So when the spine that was just rebooted comes back up, it cannot advertise a worse metric than the default, which causes all of the leaf switches immediately to install the switch as an ECMP path for the route even though things such as COOP might not have converged yet. If traffic is hashed to this ECMP path, there could be traffic loss for several seconds.   This issue can be seen in any Multi-Pod environment. Beginning with APIC 3.0 code, users have a way to change the default IS-IS metric to prevent this issue.   To change the default ISIS metric for redistributed routes, go to Fabric > Fabric Policies > Pod Policies > ISIS Policy default, and change the value from 63 to 32.   2) Spines dropping COS6 Inter-Pod traffic (CSCva15076) ACI Spines will drop Inter-Pod traffic (traffic coming across the IPN) when it is marked CS6, except iTraceroute. The bigger problem with this is that several Cisco platforms (Nexus 7000) will send control plane protocol traffic (i.e. STP, BGP, OSPF, etc.) marked as CS6 (CoS 6), and this cannot be changed on those platforms. If this traffic is dropped, it can result in the drop of BUM traffic between ACI Pods. As a workaround, change the QOS settings and re-mark COS6 traffic to COS4. If you need a detailed configuration guide to walk you through setting up QOS for Multi-Pod, check out the ACI Multi-Pod QOS guide. Design Considerations for APICs When it comes to deploying APICs in an ACI Multi-Pod Design, there are several ways to spread out your APICs across the various Pods, depending on how many Pods you intend to connect together. Cisco has a lot of good information to consider located on their Multi-Pod Whitepaper on CCO. If you are just going with (2) Pods, which is very prevalent in DR/BC deployments, my rule of thumb is (2) APICs in Pod1, (1) APIC in Pod2, and a Standby APIC in both Pod1/2. My main reason for this is that you will alway have a full copy of the APIC Shards in both Pods.     You always are assured that your APIC Shards are replicated between APIC1/2/3. This means if Pod1 goes down, you will have a full replica available on APIC3 in Pod2. If Pod1 were to go down, you can promote the Standby APIC in Pod2 to active and be ready to resume configuration (if needed). Design Considerations with Firewalls Deploying a pair of Active/Standby firewalls across Pods in an ACI Multi-Pod Fabric is a common requirement from most customers. However, please be aware that Active/Standby FW connectivity was broken with older versions of APIC code.   Please review the options below and ensure you select the appropriate solution, depending on your needs. Option 1 – Active/Standby FW with NO use of vPC   Active and Standby FWs are connected to a single Leaf node with a physical link or a local port-channel. The “bounce” of traffic between BorderLeaf in Pod2 and BorderLeaf in Pod1 will work. This is supported in the 2.1 release starting with 2.1(2e) and in the 2.2 release starting with 2.2(2e) on ACI Leaf nodes (E, EX, FX) Option 2 – Active/Standby FW with vPC   Active and Standby FWs can be connected to respective Leaf pairs in each Pod. This is supported in the 2.3 release starting with 2.3(1) on EX/FX Leaf switches ONLY. This option is not supported on first generation ACI Leaf switches due to CSCux29124. Pointer about troubleshooting APIC in Pod1 cannot ssh to spine/leaf in Pod2 APICs are not VRF aware; because of this, if you are trying to SSH from your APIC to Leaf or Spines in other Pods you will have to specify the the interface or use the attach command. Using the “attach” command will automatically source the correct interface to allow for SSH. coast-apic1# acidiag fnvread ID Pod ID Name Serial Number IP Address Role State LastUpdMsgId ————————————————————————————————————– 101 1 Spine1 FOX2123PLDK 10.0.32.65/32 spine active 0 102 2 Spine2 FOX2123PLD2 10.1.152.64/32 spine active 0 201 1 Leaf201 FDO21250W9K 10.0.32.67/32 leaf active 0 202 1 Leaf202 FDO21260TFC 10.0.32.66/32 leaf active 0 203 1 Leaf203 FDO21242YD1 10.0.32.68/32 leaf active 0 204 1 Leaf204 FDO21260TBZ 10.0.32.64/32 leaf active 0 205 2 Leaf205 FDO21250W1Y 10.1.152.66/32 leaf active 0 206 2 Leaf206 FDO21253CGH 10.1.152.65/32 leaf active 0 Total 8 nodes coast-apic1# attach Leaf206 This command is being deprecated on APIC controller, please use NXOS-style equivalent command # Executing command: ssh Leaf206 -b 10.0.0.1 Warning: Permanently added ‘leaf206,10.1.152.65’ (RSA) to the list of known hosts. Password: Cisco Nexus Operating System (NX-OS) Software TAC support: http://www.cisco.com/tac Specifying the interface in your SSH command coast-apic1# ssh admin@10.1.152.65 -b 10.0.0.1 Password: Last login: Mon Jul 23 11:24:48 2018 from 10.0.0.1 Cisco Nexus Operating System (NX-OS) Software TAC support: http://www.cisco.com/tac   That’s all for now folks. But don’t fret, the ACI blog series will continue right here on the ACI Board on Cisco Community. In an effort to make sure we’re providing you with top-notch content that’s helpful and most fitting to where you are in your current journey, drop us a comment and let us know if the caveats and considerations we provided for ACI multi-pods was helpful! And while you’re at it, let us know what specific ACI topics you’d like to see addressed in this blog series.     ... View more

By: Jody When configuring MultiPod, a frequently asked question that often comes up is how to configure QOS between the ACI Fabric and the IPN network, to ensure that critical ACI fabric traffic is not dropped. With this article, we will go through configuration examples of how to do just that!   What are we doing?   Marking Control Plane and Policy Plane traffic (APIC to APIC traffic), with some DSCP, in this example, we are marking it with CS4 for Policy Plane traffic and CS7 for Control Plane traffic. On the IPN devices, we will check the ingress traffic coming from Spine, put a label of QOS group (qos-group 6) On egress from the IPN, we will put that qos-group 6 traffic in the priority queue. * Note: User Level 1, 2, 3 are marked with EF, CS3, CS0 in this example (which in most scenarios are likely the case, based on rfc4594 or MediaNet QOS Design). However, keep in mind that QOS design must be done in a way so as to align with your existing QOS models. Level 1 traffic will often be set with EF marking, as this is often voice related traffic. * Note: This example is focused on showing how to configure QOS for Multi-Pod, i.e., mark User Level traffic and Control Plane Policy Plane traffic on ACI and then treat the traffic according to the policy determined in the IP network (IPN to IPN). The actual markings of User Level 1, 2, 3 in a deployment scenario might be different in you deployment scenario, and will likely be based on your QOS requirement / existing QOS deployment standards already present your IP network. If that is the case, adjust the markings accordingly. Fabric Side Configuration Note the default, from Fabric > Access Policies > Policies > Global > QOS Class*, the default is: Level1: 20%, Level2: 20%, Level3: 20%. * In earlier versions of APIC code, this was located in the GUI @ Fabric > Access Policies > Global Policies > QOS Class Here we are changing Level3 (default traffic) to 58%, User Level2 (CS3 traffic) to 40 % and we will change User Level1 traffic to Strict Priority Traffic. We will match this configuration to the IPN, “policy-map type queueing”.   Next, go to Tenant Infra > Policies > Protocol > DSCP class-cos translation policy for L3 Traffic* and map Level1 traffic to EF, Level2 to CS3, Level3 to CS0, Control Plane Traffic to CS7, Policy Plane traffic to CS4, Span Traffic to CS1 and Traceroute Traffic to CS5. * In earlier versions of APIC code, this was located in the GUI @ Tenant Infra > Networking > Protocol Policies > DSCP class-cos translation policy for L3 Traffic Why are we making these changes? For treatment of marked traffic, the graphic below illustrates an example based on aggregated diffserv model RFC5127. If your QOS model/standard is customized and is different from this, this should be modified based on your QOS standards.   Level 1 UserTraffic is mapped to EF in this case (101110, decimal 46), since it carries voice and real time traffic. Level 2 User Traffic is mapped to CS3 (011000, decimal 24), as it is often used by customer for traffic marked for precedence 3 treatment. Level 3 User Traffic is mapped to CS0 (000000, decimal 0 or default), as it is the default traffic. Control Plane Traffic and Policy Plane Traffic is marked with CS7 (111000, decimal 56) and CS4 (100 000, decimal 32 ) and will be mapped to priority queue. Span Traffic is marked with CS1 (001000, decimal 8), as it is traditionally treated as background/scavenger class traffic. Traceroute Traffic is marked with CS5 (101000, decimal 40) which is often done. * Note: In this example we are classifying the Control Plane traffic as CS7 and Policy Plane traffic as CS4. However, based on your requirements you might want to classify your traffic with a different DSCP class, based on your standards. The idea is to make sure that for traffic in the IP network (from IPN to IPN), you treat that traffic as priority traffic. Furthermore, we are classifying the Policy Plane traffic as CS4 (and not CS6) due to CSCva15076.   Graphic – Mapping User Levels and Control Plane/Policy Plane to DSCP levels in Infra Tenant   On the IPN Side: In this example, we are using -EX-based Leafs for our IPN device. -EX-based leaves have a total of (8) egress queues. The idea is to check for the ingress Control Plane and Policy Plane traffic coming from the Spine, place a label of the QOS group, then on egress place that traffic in a prority queue. * Note: If you are using IPNs are not -EX-based Nexus 9Ks, the basic idea will be the same but configuration will vary depending on the amount of queues present. Remember the main idea is to put the control plane and policy plane traffic in the high priority queue. In this example 1/49.4 and 1/50.4 are the interfaces on IPN that connect to Spine.   Here is the IPN Config: ! Below we are matching the markings based on what was configured on ACI ! Creation of Class Maps ! class-map type qos match-all UserLevel1 match dscp 46 class-map type qos match-all UserLevel2 match dscp 24 class-map type qos match-all UserLevel3 match dscp 0 class-map type qos match-all SpanTraffic match dscp 8 class-map type qos match-all iTraceroute match dscp 40 class-map type qos match-all CONTROL-TRAFFIC match dscp 32,56 ! ! creation of Policy Map (to be applied on ingress interfaces of IPN, facing Spines) ! policy-map type qos ACI-CLASSIFICATION class CONTROL-TRAFFIC set qos-group 7 class UserLevel1 set qos-group 6 class UserLevel2 set qos-group 3 class UserLevel3 set qos-group 0 class SpanTraffic set qos-group 1 class iTraceroute set qos-group 5 ! ! Below we are configuring priority queue for qos group 6 (there is a default configuration already on the router that matches class map qos-group 6 traffic to queue c-out-8q-q6). We are mapping EF traffic to Priority Queue 1 and COS4 traffic to Priority Queue 2. Level 2, 3 traffic are given 40% and 58% of bandwidth (to match up with Global QOS config in APIC, Figure 1 and Figure 2). ! policy-map type queuing IPN-8q-out-policy class type queuing c-out-8q-q7 priority level 2 class type queuing c-out-8q-q6 priority level 1 class type queuing c-out-8q-q5 bandwidth remaining percent 0 class type queuing c-out-8q-q4 bandwidth remaining percent 0 class type queuing c-out-8q-q3 bandwidth remaining percent 40 class type queuing c-out-8q-q2 bandwidth remaining percent 0 class type queuing c-out-8q-q1 bandwidth remaining percent 1 class type queuing c-out-8q-q-default bandwidth remaining percent 58 ! ! Below we are applying the policy IPN-8q-out-policy to the system level, so all egress will be treated as policy dictates ! ! system qos service-policy type queuing output IPN-8q-out-policy ! ! ! Below we associate the interfaces going to spine with the input service policy so that EF and CS4 traffic will be marked with qos-group-7 ! ! interface Ethernet1/49.4 description POD2-Spine-401 e1/5 mtu 9150 encapsulation dot1q 4 vrf member IPNACISJC service-policy type qos input ACI-CLASSIFICATION ip address 10.149.195.106/30 ip ospf network point-to-point ip router ospf IPNACISJC area 0.0.0.0 ip pim sparse-mode ip dhcp relay address 10.0.0.1 ip dhcp relay address 10.0.0.2 ip dhcp relay address 10.0.0.3 no shutdown ! ! interface Ethernet1/50.4 description POD2-Spine-402 e1/5 mtu 9150 encapsulation dot1q 4 vrf member IPNACISJC service-policy type qos input ACI-CLASSIFICATION ip address 10.149.195.110/30 ip ospf network point-to-point ip router ospf IPNACISJC area 0.0.0.0 ip pim sparse-mode ip dhcp relay address 10.0.0.1 ip dhcp relay address 10.0.0.2 ip dhcp relay address 10.0.0.3 no shutdown Verification on IPN: ! Looking at ingress interface on IPN, (towards ACI Spine) IPNPOD2# show policy-map interface ethernet 1/50.4 input Global statistics status : enabled Ethernet1/50.4 Service-policy (qos) input: ACI-CLASSIFICATION SNMP Policy Index: 285215377 Class-map (qos): CONTROL-TRAFFIC (match-all) Slot 1 1434 packets Aggregate forwarded : 1434 packets Match: dscp 32,56 set qos-group 7 Class-map (qos): UserLevel1 (match-all) Aggregate forwarded : 0 packets Match: dscp 46 set qos-group 6 Class-map (qos): UserLevel2 (match-all) Aggregate forwarded : 0 packets Match: dscp 24 set qos-group 3 Class-map (qos): UserLevel3 (match-all) Slot 1 25 packets Aggregate forwarded : 25 packets Match: dscp 0 set qos-group 0 Class-map (qos): SpanTraffic (match-all) Aggregate forwarded : 0 packets Match: dscp 8 set qos-group 1 Class-map (qos): iTraceroute (match-all) Aggregate forwarded : 0 packets Match: dscp 40 set qos-group 5 IPNPOD2# show policy-map interface ethernet 1/49.4 input Global statistics status : enabled Ethernet1/49.4 Global statistics status : enabled Ethernet1/49.4 Service-policy (qos) input: ACI-CLASSIFICATION SNMP Policy Index: 285215373 Class-map (qos): CONTROL-TRAFFIC (match-all) Slot 1 5149 packets Aggregate forwarded : 5149 packets Match: dscp 32,56 set qos-group 7 Class-map (qos): UserLevel1 (match-all) Aggregate forwarded : 0 packets Match: dscp 46 set qos-group 6 Class-map (qos): UserLevel2 (match-all) Aggregate forwarded : 0 packets Match: dscp 24 set qos-group 3 Class-map (qos): UserLevel3 (match-all) Slot 1 960 packets Aggregate forwarded : 960 packets Match: dscp 0 set qos-group 0 Class-map (qos): SpanTraffic (match-all) Aggregate forwarded : 0 packets Match: dscp 8 set qos-group 1 Class-map (qos): iTraceroute (match-all) Aggregate forwarded : 0 packets Match: dscp 40 set qos-group 5 ! Looking at egress interface of IPNPOD2 (towards IP network from IPN) IPNPOD1# show queuing interface e 1/3 | b “GROUP 7” slot 1 ======= Egress Queuing for Ethernet1/3 [System] —————————————————————————— QoS-Group# Bandwidth% PrioLevel Shape QLimit Min Max Units —————————————————————————— 7 – 2 – – – 9(D) 6 – 1 – – – 9(D) 5 0 – – – – 9(D) 4 0 – – – – 9(D) 3 20 – – – – 9(D) 2 0 – – – – 9(D) 1 1 – – – – 9(D) 0 59 – – – – 9(D) +————————————————————-+ | QOS GROUP 0 | +————————————————————-+ | | Unicast |Multicast | +————————————————————-+ | Tx Pkts | 125631| 70| | Tx Byts | 42902871| 8836| | WRED/AFD & Tail Drop Pkts | 0| 0| | WRED/AFD & Tail Drop Byts | 0| 0| | Q Depth Byts | 0| 0| | WD & Tail Drop Pkts | 0| 0| +————————————————————-+ | QOS GROUP 1 | +————————————————————-+ | | Unicast |Multicast | +————————————————————-+ | Tx Pkts | 0| 0| | Tx Byts | 0| 0| | WRED/AFD & Tail Drop Pkts | 0| 0| | WRED/AFD & Tail Drop Byts | 0| 0| | Q Depth Byts | 0| 0| | WD & Tail Drop Pkts | 0| 0| +————————————————————-+ | QOS GROUP 2 | +————————————————————-+ | | Unicast |Multicast | +————————————————————-+ | Tx Pkts | 0| 0| | Tx Byts | 0| 0| | WRED/AFD & Tail Drop Pkts | 0| 0| | WRED/AFD & Tail Drop Byts | 0| 0| | Q Depth Byts | 0| 0| | WD & Tail Drop Pkts | 0| 0| +————————————————————-+ | QOS GROUP 3 | +————————————————————-+ | | Unicast |Multicast | +————————————————————-+ | Tx Pkts | 0| 0| | Tx Byts | 0| 0| | WRED/AFD & Tail Drop Pkts | 0| 0| | WRED/AFD & Tail Drop Byts | 0| 0| | Q Depth Byts | 0| 0| | WD & Tail Drop Pkts | 0| 0| +————————————————————-+ | QOS GROUP 4 | +————————————————————-+ | | Unicast |Multicast | +————————————————————-+ | Tx Pkts | 0| 0| | Tx Byts | 0| 0| | WRED/AFD & Tail Drop Pkts | 0| 0| | WRED/AFD & Tail Drop Byts | 0| 0| | Q Depth Byts | 0| 0| | WD & Tail Drop Pkts | 0| 0| +————————————————————-+ | QOS GROUP 5 | +————————————————————-+ | | Unicast |Multicast | +————————————————————-+ | Tx Pkts | 0| 0| | Tx Byts | 0| 0| | WRED/AFD & Tail Drop Pkts | 0| 0| | WRED/AFD & Tail Drop Byts | 0| 0| | Q Depth Byts | 0| 0| | WD & Tail Drop Pkts | 0| 0| +————————————————————-+ | QOS GROUP 6 | +————————————————————-+ | | Unicast |Multicast | +————————————————————-+ | Tx Pkts | 645609| 217| | Tx Byts | 115551882| 25606| | WRED/AFD & Tail Drop Pkts | 0| 0| | WRED/AFD & Tail Drop Byts | 0| 0| | Q Depth Byts | 0| 0| | WD & Tail Drop Pkts | 0| 0| +————————————————————-+ | QOS GROUP 7 | +————————————————————-+ | | Unicast |Multicast | +————————————————————-+ | Tx Pkts | 23428| 9| | Tx Byts | 4132411| 1062| | WRED/AFD & Tail Drop Pkts | 0| 0| | WRED/AFD & Tail Drop Byts | 0| 0| | Q Depth Byts | 0| 0| | WD & Tail Drop Pkts | 0| 0| +————————————————————-+ | CONTROL QOS GROUP | +————————————————————-+ | | Unicast |Multicast | +————————————————————-+ | Tx Pkts | 6311| 0| | Tx Byts | 809755| 0| | Tail Drop Pkts | 0| 0| | Tail Drop Byts | 0| 0| | WD & Tail Drop Pkts | 0| 0| +————————————————————-+ | SPAN QOS GROUP | +————————————————————-+ | | Unicast |Multicast | +————————————————————-+ | Tx Pkts | 0| 0| | Tx Byts | 0| 0| | Tail Drop Pkts | 0| 0| | Tail Drop Byts | 0| 0| | WD & Tail Drop Pkts | 0| 0| +————————————————————-+ Ingress Queuing for Ethernet1/3 —————————————————– QoS-Group# Pause Buff Size Pause Th Resume Th —————————————————– 7 – – – 6 – – – 5 – – – 4 – – – 3 – – – 2 – – – 1 – – – 0 – – – Per Port Ingress Statistics ——————————————————– Hi Priority Drop Pkts 0 Low Priority Drop Pkts 0 Ingress Overflow Drop Pkts 0 PFC Statistics —————————————————————————— TxPPP: 0, RxPPP: 0 —————————————————————————— PFC_COS QOS_Group TxPause TxCount RxPause RxCount 0 0 Inactive 0 Inactive 0 1 0 Inactive 0 Inactive 0 2 0 Inactive 0 Inactive 0 3 0 Inactive 0 Inactive 0 4 0 Inactive 0 Inactive 0 5 0 Inactive 0 Inactive 0 6 0 Inactive 0 Inactive 0 7 0 Inactive 0 Inactive 0 —————————————————————————— IPNPOD2# show queuing interface e 1/4 slot 1 ======= Egress Queuing for Ethernet1/4 [System] —————————————————————————— QoS-Group# Bandwidth% PrioLevel Shape QLimit Min Max Units —————————————————————————— 7 – 2 – – – 9(D) 6 – 1 – – – 9(D) 5 0 – – – – 9(D) 4 0 – – – – 9(D) 3 20 – – – – 9(D) 2 0 – – – – 9(D) 1 1 – – – – 9(D) 0 59 – – – – 9(D) +————————————————————-+ | QOS GROUP 0 | +————————————————————-+ | | Unicast |Multicast | +————————————————————-+ | Tx Pkts | 63049| 0| | Tx Byts | 15968783| 0| | WRED/AFD & Tail Drop Pkts | 0| 0| | WRED/AFD & Tail Drop Byts | 0| 0| | Q Depth Byts | 0| 0| | WD & Tail Drop Pkts | 0| 0| +————————————————————-+ | QOS GROUP 1 | +————————————————————-+ | | Unicast |Multicast | +————————————————————-+ | Tx Pkts | 0| 0| | Tx Byts | 0| 0| | WRED/AFD & Tail Drop Pkts | 0| 0| | WRED/AFD & Tail Drop Byts | 0| 0| | Q Depth Byts | 0| 0| | WD & Tail Drop Pkts | 0| 0| +————————————————————-+ | QOS GROUP 2 | +————————————————————-+ | | Unicast |Multicast | +————————————————————-+ | Tx Pkts | 0| 0| | Tx Byts | 0| 0| | WRED/AFD & Tail Drop Pkts | 0| 0| | WRED/AFD & Tail Drop Byts | 0| 0| | Q Depth Byts | 0| 0| | WD & Tail Drop Pkts | 0| 0| +————————————————————-+ | QOS GROUP 3 | +————————————————————-+ | | Unicast |Multicast | +————————————————————-+ | Tx Pkts | 0| 0| | Tx Byts | 0| 0| | WRED/AFD & Tail Drop Pkts | 0| 0| | WRED/AFD & Tail Drop Byts | 0| 0| | Q Depth Byts | 0| 0| | WD & Tail Drop Pkts | 0| 0| +————————————————————-+ | QOS GROUP 4 | +————————————————————-+ | | Unicast |Multicast | +————————————————————-+ | Tx Pkts | 0| 0| | Tx Byts | 0| 0| | WRED/AFD & Tail Drop Pkts | 0| 0| | WRED/AFD & Tail Drop Byts | 0| 0| | Q Depth Byts | 0| 0| | WD & Tail Drop Pkts | 0| 0| +————————————————————-+ | QOS GROUP 5 | +————————————————————-+ | | Unicast |Multicast | +————————————————————-+ | Tx Pkts | 0| 0| | Tx Byts | 0| 0| | WRED/AFD & Tail Drop Pkts | 0| 0| | WRED/AFD & Tail Drop Byts | 0| 0| | Q Depth Byts | 0| 0| | WD & Tail Drop Pkts | 0| 0| +————————————————————-+ | QOS GROUP 6 | +————————————————————-+ | | Unicast |Multicast | +————————————————————-+ | Tx Pkts | 1141418| 0| | Tx Byts | 237770324| 0| | WRED/AFD & Tail Drop Pkts | 0| 0| | WRED/AFD & Tail Drop Byts | 0| 0| | Q Depth Byts | 0| 0| | WD & Tail Drop Pkts | 0| 0| +————————————————————-+ | QOS GROUP 7 | +————————————————————-+ | | Unicast |Multicast | +————————————————————-+ | Tx Pkts | 32440| 0| | Tx Byts | 6986806| 0| | WRED/AFD & Tail Drop Pkts | 0| 0| | WRED/AFD & Tail Drop Byts | 0| 0| | Q Depth Byts | 0| 0| | WD & Tail Drop Pkts | 0| 0| +————————————————————-+ | CONTROL QOS GROUP | +————————————————————-+ | | Unicast |Multicast | +————————————————————-+ | Tx Pkts | 6275| 0| | Tx Byts | 804748| 0| | Tail Drop Pkts | 0| 0| | Tail Drop Byts | 0| 0| | WD & Tail Drop Pkts | 0| 0| +————————————————————-+ | SPAN QOS GROUP | +————————————————————-+ | | Unicast |Multicast | +————————————————————-+ | Tx Pkts | 0| 0| | Tx Byts | 0| 0| | Tail Drop Pkts | 0| 0| | Tail Drop Byts | 0| 0| | WD & Tail Drop Pkts | 0| 0| +————————————————————-+ Ingress Queuing for Ethernet1/4 —————————————————– QoS-Group# Pause Buff Size Pause Th Resume Th —————————————————– 7 – – – 6 – – – 5 – – – 4 – – – 3 – – – 2 – – – 1 – – – 0 – – – Per Port Ingress Statistics ——————————————————– Hi Priority Drop Pkts 0 Low Priority Drop Pkts 0 Ingress Overflow Drop Pkts 0 PFC Statistics —————————————————————————— TxPPP: 0, RxPPP: 0 —————————————————————————— PFC_COS QOS_Group TxPause TxCount RxPause RxCount 0 0 Inactive 0 Inactive 0 1 0 Inactive 0 Inactive 0 2 0 Inactive 0 Inactive 0 3 0 Inactive 0 Inactive 0 4 0 Inactive 0 Inactive 0 5 0 Inactive 0 Inactive 0 6 0 Inactive 0 Inactive 0 7 0 Inactive 0 Inactive 0 —————————————————————————— That’s all for today’s ACI blog. More to come on the ACI Board here in Cisco Community. Drop us a comment and let us know if super technical blogs like these are helpful. And while you’re at it, let us also know what kinds of topics relating to ACI you’d like posted on here. A special thanks to Soumitra Mukherji for his contribution on this post.     ... View more

By: Jody   Let’s start at the beginning…what is it?   Common Pervasive Gateway is an older feature that was used to connect multiple ACI fabrics together via a L2 connection prior to the availability of ACI MultiPod and ACI MultiSite. While most customers will use a newer feature such as ACI MultiPod, or ACI MultiSite, there are still a number of customers who use the Common Pervasive Gateway feature to support L2 connectivity between fabrics.   What will we be covering here?   We’ll be discussing the Common Pervasive Gateway feature in ACI, which has been available since 1.2(1i). This feature addresses the requirement to extend Bridge Domain(BD) across multiple ACI Fabrics to provide a same default gateway to servers in each ACI Fabrics.   A normal default gateway configured as ACI BD subnet is called pervasive gateway. Hence why this feature is called “Common Pervasive Gateway.”   This cool thing about this feature is that it enables moving one or more virtual machines (VM) or conventional hosts across different ACI Fabrics seamlessly without any configuration changes or operations. It’s as if VMs are moving within the same ACI Fabric.   Interested in checking out in-depth documentation? We’ve listed some out for you below!   Cisco Application Policy Infrastructure Controller, Release 1.2(1m), Release Notes Cisco Application Centric Infrastructure Fundamentals (Chapter: Networking and Management Connectivi… Cisco ACI Basic Configuration Guide (Chapter: ACI Fabric Layer 3 Outside Connectivity)   What problem is solved by Common Pervasive Gateway?   Short answer: EndPoint (EP) learning on another ACI Fabric is what Common Pervasive Gateway resolves. However, here’s the detailed walkthrough of the problem:   ※ pMAC : physical MAC 1) H1 ARPs for GW IP 192.168.0.254     L1 responds to ARP with pMAC 2) H1 sends the packet with DMAC as pMAC and DIP as 192.168.1.2 3) L1 routes the packet and sends it to one of the Spines for proxy 4) Spine, being unable to find the entry for 192.168.1.2, sends glean packets 5) BL1 ARPs for 192.168.1.2 with pMAC as ARP sender MAC and 192.168.1.254 as ARP sender IP. BL2 doesn’t learn pMAC and 192.168.1.254 since ACI Fabric2 owns these as its own MAC and IP as well. 6) If 192.168.1.2 is already learned: ARP request from BL1 is forwarded to L2. And L2 sends it to H2. If 192.168.1.2 is not learned yet: ARP request from BL1 is sent to one of the Spines for proxy and glean packets are sent for 192.168.1.2 to learn      192.168.1.2 as EP. Then, next ARP request from BL1 is forwarded to H2. If ARP flood is enabled: ARP request from BL1 is flooded to H2 7) H2 responds to ARP with DMAC as pMAC, DIP as 192.168.1.254, SMAC as H2MAC, SIP as 192.168.1.2 8) L2 receives the ARP reply and doesn’t forward it to anywhere because DMAC and DIP is L2’s router MAC and IP. Hence ACI Fabric1 cannot learn H2.   SIDE NOTE: This may work if we configure different pMACs on each ACI Fabric BDs. However, that means having two different MACs for the same IP address. This implies VM may keep using wrong ARP entry when vMotion happened from one Fabric to another.   Your next question might be: ‘What if we configure different pMACs and different subnet IPs on each ACI Fabrics?” Well this means that we would need to reconfigure the default gateway IP address on VM when VM moves between ACI Fabrics.   But lo and behold, this problem is resolved by common pervasive gateway.    How does Common Pervasive Gateway even work?   We’re glad you asked!   Common pervasive gateway allows us to have a virtual MAC and virtual IP which is common (i.e., the same) across multiple ACI Fabrics.   All devices in the Bridge Domain with the Common Pervasive Gateway feature is supposed to point at the Common Pervasive Gateway (virtual IP) as its default gateway.   However, it is still required to have a non-virtual IP on the BD in each of the ACI Fabrics on top of virtual IP. This non-virtual IP should be in the same subnet as virtual IP and should be unique for each of the ACI Fabrics. This is similar to HSRP physical IP and virtual IP configuration.   It is also required to have unique physical MAC addresses (Custom MAC address in APIC GUI) on each BD in each ACI Fabrics that will be stretched. Let’s dive into how Common Pervasive Gateway really works:   H1 ARPs for GW IP 192.168.0.254 (vIP) L1 responds to ARP with vMAC H1 sends the packet with DMAC as vMAC and DIP as 192.168.1.2 L1 routes the packet and sends it to one of the Spines for proxy When vMAC is configured on BD, a packet with DMAC set to pMAC1 won’t be routed since router-mac for the BD becomes vMAC. Spine, being unable to find the entry for 192.168.1.2, sends glean packets BL1 ARPs for 192.168.1.2 with pMAC1 as ARP sender MAC and 192.168.1.251 as ARP sender IP. -> Both sender MAC/IP are set to physical not virtual BL2 learns pMAC1 and 192.168.1.251. If 192.168.1.2 is already learned: ARP request from BL1 is forwarded to L2. And L2 sends it to H2. If 192.168.1.2 is not learned yet: ARP request from BL1 is sent to one of the Spines for proxy and glean packets are sent for 192.168.1.2 to learn 192.168.1.2 as EP. Then, next ARP request from BL1 is forwarded to H2. If ARP flood is enabled: ARP request from BL1 is flooded to H2 H2 responds to ARP with DMAC as pMAC1, DIP as 192.168.1.251, SMAC as H2MAC, SIP as 192.168.1.2 L2 learns H2MAC,IP(192.168.1.2) and updates COOP on Spines in ACI Fabric2. L2 bridges the packet to BL2 BL2 bridges the packet to BL1 BL1 learns H2MAC,IP(192.168.1.2) and updates COOP on Spines in ACI Fabric1. Subsequent packets from H1 are routed to ACI Fabric2 through BL1. BL1 sends them out on L2OUT with SMAC as pMAC1, DMAC as H2MAC What are the Configuration Components?   Multiples ACI Fabrics Bridge Domain (BD) for each ACI Fabrics Unique physical BD MAC (Custom MAC) for each ACI Fabrics Unique non-virtual IP for each ACI Fabrics Identical virtual MAC across ACI Fabrics Identical virtual IP across ACI Fabrics L2Out between each BDs on each ACI Fabrics   Here's some clarification about terminology.   L2Out in ACI means we have a Layer 2 Network, which could have other switches or different networks while normal EPG basically is supposed to have only EndPoints such as servers.   The term “L2Out” technically implies External Bridged Network which is associated directory to BD. However, attaching L2 networks via an EPG (L2EPG) can accomplish the same thing. Which is why a lot of documents use L2Out which means either configuration.    Note: L2Out via EPG is the most widely deployed version of the L2Out, and is the recommended configuration.   Cool. Got it. But what are some design prerequisites?   When using Common Pervasive Gateway, we have three requirements:   The Bridge domain that is configured to communicate across ACI fabrics must be configured for flood mode. This means we need to set L2 Unknown Unicast to flood on the BD for Common Pervasive Gateway   Only one EPG from a bridge domain (If the BD has multiple EPGs) should be configured on a border Leaf on the port which is connected to the second Fabric. This means we should have only one L2Out for each BD with Common Pervasive Gateway. And any normal EPGs in the same BD with Common Pervasive Gateway cannot use the port used for L2Out connection between two ACI Fabrics Do not connect hosts directly to an inter-connected Layer 2 network that enables a pervasive common gateway among the two ACI fabrics. This means L2Out connection between two ACI Fabrics for Common Pervasive Gateway must be used only for L2Out connectivity between two ACI Fabrics. For example, even if we have an external L2 switch between two ACI Fabrics for L2Out connectivity for Common Pervasive Gateway, we cannot connect any hosts to that switch with same vlan as L2Out. Also we cannot connect any hosts to that switch even with other vlans for any EPGs in the same BD which is the second prerequisite above.   Here’s a picture of what is described above for you visual folks! And because the common pervasive gateway is also a feature to extend BD, each BD with common pervasive gateway requires one L2Out respectively.   Here’s a visual of the GUI: It’s Questions & Answer time!   What is the purpose of virtual IP? The BD subnet marked as virtual IP should be default gateway for servers. This IP must be identical across multiple ACI Fabrics.   Also if a BD subnet is configured as virtual IP, that IP address won’t be used as a source for ARP request originated from ACI Leaf BD SVI as long as other non-virtual IP exists in the same subnet. This is to make sure that BL1 in ACI Fabric1 in the previous scenario generates ARP request to H2 with unique sender MAC,IP for ACI Fabrics.   What is the purpose of virtual MAC?   When virtual MAC is configured, it becomes router-mac for the BD. Hence the packet with DMAC set to physical MAC (custom MAC in GUI) is no longer routed on the BD but just bridged.   ARP requests for any of SVI subnets on the BD is resolved with this virtual MAC. If it wasn’t resolved with virtual MAC, it may hit CSCux73998 .   How is physical MAC (custom MAC in GUI) used after virtual MAC is configured?   When traffic is routed on BD and source MAC needs to be rewritten, physical MAC is used as a source MAC for the packet.   Also it is used as a source MAC when traffic is generated from BD SVI such as ping from BD SVI.   This applies to both virtual IP and non-virtual IP. So even when ping is sourced from virtual IP, physical MAC is used as source MAC.   How is a packet with DMAC set to physical MAC (custom MAC in GUI) processed on ACI Leaf after virtual MAC is configured?   It will be bridged as normal Layer2 traffic. It cannot be routed on BD with virtual MAC since router-mac for the BD is already replaced with virtual MAC. Hence as long as ACI Leaf doesn’t learn the physical MAC from outside, it will be processed as unknown L2 unicast.   Can we still ping to BD SVI with DMAC set to physical MAC (custom MAC in GUI) after virtual MAC is configured?   Yes. Given Layer2 forwarding table, it looks like a packet should not be processed in CPU but just bridged. However, due to sup-tcam entry below, ICMP packets destined to BD SVI (router-ip for BD) are sup-redirected. Can we still use non-virtual IP as default gateway for servers when virtual MAC and virtual IP are configured?   Technically yes but not recommended. It would work because ARP is always resolved with VMAC even for non-virtual IP.   What if virtual MAC is configured without any virtual IP?   Same thing still happens as described in the question “What is the purpose of virtual MAC?”   However, ACI Leaf switches cannot be sure which BD subnet is used as common across ACI Fabrics. Hence ARP request for H2 from BL1 in the previous scenario may be generated with sender IP of the one which is supposed to be virtual IP, in other words, the one configured as BD SVI on another ACI Fabrics as well. ACI Fabric1 fails to resolve ARP for H2 if that happened.   Why do we have to configure non-vitual IP on top of virtual IP in the same subnet?   If there was only virtual IP, target IP for ARP reply from H2 in previous scenario would be virtual IP because BL1 had no choice other than generating ARP with sender IP set to virtual IP. Hence ARP reply from H2 would be sup-redirected on L2 in ACI Fabric2 due to this sup-tcam entry. Why do we have to configure unique non-virtual IP for each ACI Fabrics?   Same reason as above.   Why do we have to configure unique physical MAC (custom MAC in GUI) for each ACI Fabrics?   Basically same reason as non-virtual IP. If DMAC of ARP reply is same as one of router-mac, it is sup-redirected and not forwarded. All About Verification.   We need to know how to verify the current software and hardware status is correct. We can do that by checking each processes described at previous section.   Policy Manager (Logical Object) Policy Manager (Concrete Object) Policy Element (Concrete Object) SVIMgr IPMgr ARP ELTMC   Here are some additional troubleshooting tips.   As described in FAQ section, BD SVI always uses physical BD MAC (custom MAC in GUI) as source MAC even though it replies to ARP request with virtual MAC.   Hence the expected dst/src MAC in packets through BD with virtual MAC are as follows.   (that is, assuming both BDs are using virtual MAC)   ICMP echo:   H1(192.168.0.1) —-> [(192.168.0.254)BD—BD(192.168.1.254)] —-> H2(192.168.1.2) DMAC: VMAC                                                                                 DMAC: H2MAC SMAC: H1MAC                                                                               SMAC: pMAC   ICMP reply:   H1(192.168.0.1) <—- [(192.168.0.254)BD—BD(192.168.1.254)] <—- H2(192.168.1.2) DMAC: H1MAC                                                                                 DMAC: VMAC  SMAC: pMAC                                                                                    SMAC: H2MAC   As described in FAQ section, router-mac is replaced with virtual MAC. So if DMAC of incoming packets were pMAC instead of vMAC, it won’t be routed but just handled as L2 unicast and most likely flooded or proxy’ed within BD.   Oh and by the way…   There are some devices such as Netapp with fast path feature which doesn’t do ARP when it replies to packets but instead uses source MAC of incoming packets as dest MAC for reply packet. Those devices may reply to ACI Leaf with pMAC as dest MAC since pMAC is used as source for packets coming out from ACI BD with virtual MAC. If that happens, traffic won’t be routed.   Example Product & Feature   NetApp : Fast Path F5 Big-IP : Auto Last Hop EMC VNX series : Packet Reflect EMC ISILON : Source Based Routing  That’s all for now folks. But don’t fret, the ACI blog series will continue right here on the ACI Board on Cisco Community.   In an effort to make sure we’re providing you with top-notch content that’s helpful and most fitting to where you are in your current journey, drop us a comment and let us know if this deep dive into the common pervasive gateway was helpful!   And while you’re at it, let us know what specific ACI topics you’d like to see addressed in this blog series.   A special thanks to Takuya Kishida for his contribution to this blog.   ... View more

By Andrew Boring   Let’s talk about Curl. If you’ve spent any time with the ACI interface, you’ve probably realized that herding a mouse around a browser is fine for small/one-time operations, but does not scale when you have a large quantity of repetitive operations. Maybe you started using Postman to run API queries, but you want to build a succession of queries and roll them up in a script. If you’re competent with Python, you might even be using the Cobra SDK or ACI Toolkit to develop anything from simple scripts to integration with other infrastructure components. On the other hand, maybe you like pain and suffering and have a preference for simple shell scripts. If this is you, you’ll be using curl. In this series, we’ll explore using curl on the command line and in simple shell scripts for quick, repeatable operations. If you’re not familiar with curl, it’s an excellent utility for interacting with HTTP servers, especially for performing CRUD operations against an API. Further, you can connect to other Unix tools by using conventional STDIN/STDOUT interfaces. This can help you quickly prototype applications by connecting components to repeat frequently-used tasks. Anatomy of a curl request. You’ve probably used curl to download a file from a webpage, like this:   curl http://www.unofficialaciguide.com/index.php This performs a simple GET request on the server, retrieving the data and printing it out on the screen. To perform other HTTP operations (HEAD, PUT, DELETE, POST, etc), you might use the -X switch: curl -X POST -d "some data" http://example.com/api/path/to/object To use HTTPS when you have a self-signed certificate, maybe you’ll add the -k switch to bypass untrusted certificate warnings (useful for internal testing where a quick cert is all that’s needed): curl -k https://example.com/api/path/to/object If you need to pass HTTP header information, like content-type, simply add -H with the headers, like specifying XML: curl -X POST -d "param1=value1" -H "Content-Type: application/x-www-form-urlencoded" http://example.com/api/object or JSON: curl -X POST -d '{"key1":"value1"} -H "Content-Type: application/json" http://example.com/api/object When constructing requests, it will be helpful to have some reference materials handy. First, you’ll want the official Cisco APIC REST API Configuration Guide, as that is the authoritative API reference. Secondly, while the full curl manual page (“man curl” at your Unix/Linux prompt) is quite comprehensive, it can be challenging to find the exact switch you need among all the options available to you. A good online reference is useful. I personally find this Gist to be a good intro/quick reference for the most common curl options and usage. Finally, parsing the XML output can be an adventure in formatting. Useful tools include json_pp and xmllint are common formatting utilities when working with raw curl output, while standard Unix tools like grep, sed, cut, etc will be indispensable.   In order to interact with the API, we will need to authenticate. An authentication POST request will require a username/password, expressed using the aaaUser object. The XML version looks like this:   Substitute your username, password, and IP address/hostname as needed. The leading $ sign indicates a command prompt, and should not be typed. The response will include a session token and a number of attributes. We can use the token to pass subsequent requests, but extracting the token programmatically can be painful when you just want to run a quick command or two. We’ll use curl’s -c switch to save the info in a cookie file, named “COOKIE”:   Then, you simply use “-b COOKIE” in subsequent requests, such as retrieving a list of tenants:   You can pass XML output through the xmllint utility to format (indent) it:   Don’t forget that trailing hyphen! The pipe | character tells the shell to take the output of the curl command and use it as input to xmllint. The trailing hypen tells the xmllint program to read from input rather than a file. Another way to do this is to save the output to a file, and then read the file using xmllint (or your favorite XML editor).   If you’re using JSON, you can use a tool called json_pp (“pretty print”) to get nice formatting:   We’ll dive more into using curl to interact with the APIC API in upcoming posts. But that wraps up today’s blog! More blogs regarding ACI are yet to come right here on the ACI Board on Cisco Community. Make sure to drop a comment and let us know if this piece focused on “Curl” was helpful! And as always, we’d love to know what other topics you’d like us to write about in future ACI blogs. Help us, help you! ... View more

By Andrew Boring Have you already read through our ACI Best Practices Configuration post? If you haven’t, go ahead and do it now! Don’t worry, I’ll wait. (Are you done clicking those buttons in the GUI yet? Take your time. I won’t leave you, but I may sneak out for some coffee). All done? Cool. Welcome back! If you’re not hot for all that button-clicking, or if you want to check that the options are enabled as part of an Operations Dashboard or a sanity_check.sh script, you may want to configure these via the API. Not a programmer? Not a problem! We’ll use the curl utility to GET/POST data to demonstrate the API interfaces involved. If you haven’t used curl before, or are not experienced with using curl to send API requests from the command line, check out our post on “Getting Started with Curl.” Each option below assumes you have already authenticated and curl is storing the token as a cookie for use in each request (-b COOKIE). For more details on what each option is and why you want to configure it, please refer to “Getting Started with Curl.” Also, we’ll be operating on each object directly, as opposed to performing operations on the top-level uni.xml object. This simplifies our JSON/XML data. Cisco has a whitepaper introducing the APIC object model, while our own post titled “Not Sure About the APIC API? Let’s Get You Familiar” is a short introduction to the tools to help you explore the API and object model. We’ve also included a “best_practices_for_curling.txt” file in the same Github repo to get you started with your own scripts. It contains just the curl commands and comments, without the shell script. The Goods: bp-config.sh The demonstration code is posted at https://github.com/unofficialaciguide/bestpractices It’s written in shell, and should work on any modern Unix/Linux system with bash 4.x. To install, simply clone the repo with git or use the download link to get a zip file, then follow the instructions in the README. Before we dive into the curl specifics, let’s review the structure of the script. If you’re not familiar with writing shell scripts, The Linux Documentation Project has a beginner HOWTO and an advanced HOWTO, though I personally like this tutorial as a good intro for the beginner (all three links are ad-free sites). If you like paper manuals, the OG Unix Programming Environment from Kernighan and Pike is the definitive resource despite its age. I challenge you to find any other computer-related reference manual still relevant after 35 years! To run the script and configure the settings on your APIC, just pass the word “enable” or “disable” on the command line. The script will then run each option to enable or disable accordingly. Simple, no?   The Walkthrough Let’s review the script itself. First thing you see under Configuration section is your username, password, and controller hostname/IP address. The HOST variable will be used to construct all API requests, while USER/PASS are used for authentication. Input your information here. Examples are included for reference. Note, this is stored in plain text, so if you share the script with your colleagues, be sure to scrub your user info first, or point them to the github repo to get it directly. We also need to configure the script to run each setting listed in the original article. Since you may have a need to override a specific setting (eg, you might need a different setting for Endpoint Loop Detection), the next section will be to enable/disable each configuration option for the script. Note, this does not enable/disable the setting on your controller! This only tells the script whether to run the option or not. The “export” tells the script to make this variable available to any subprocesses. Setting YES to any option will tell the script to execute the config setting. Change to NO or set to anything else to skip the config option when run.     There are a couple of curl-related options to configure, but are optional. COOKIEFILE controls where the cookie/token/session info is kept. It defaults to your current working directory, which may not be writable. You can specify an alternate location writable by your user, if needed. We also want to configure specific options for our environment. We include the -k and -s as defaults. The -k switch allows curl to accept certificates without a proper chain of trust (eg, self-signed). If you are using an internal CA or otherwise have trusted certificates, you can omit this. The -s option suppresses the status output, which gives you a progress bar and other niceties that are useful for interactive work, but not good for scripts. We also configure the content-type as XML since that’s the data we’re passing along with POST as the default HTTP method (because we’re POSTing the XML data to the API web service). The COOKIEFILE is where to store the session/authentication token. It defaults to YOUR current working directory, which may not be writable, You can specify a specific location if needed (eg, /tmp, or $HOME). This is how the overall program flow in the demo works. The MAIN section at the bottom is where the program looks for an argument on the command line and decides what action to take. If no parameter is passed (tested against the shell variable ?#, which is a special variable telling you the number of arguments passed to the script), then it runs the usage function, which in turn prints a usage/help text. If you type “bp-config.sh enable”, then it executes two defined functions, “auth” and “enable_all”, in sequence. Likewise, the “disable” command runs auth and disable_all. Pretty simple. The enable_all and disable_all consequently runs a command/function for each setting, to enable or disable respectively. Each function must be defined first before we can use them, which is why the MAIN section is all the way at the bottom. If we were writing a much larger program in shell, we might move the functions into a separate file and simply load them at the top. The FUNCTIONS section in the middle is where the magic happens.   Each of the Best Practices suggestions are broken out into separate functions for each configuration option, along with a further split for each “enable” and “disable setting”. The first function defined is the auth() function, which is called to create a session token/cookie to store info. In this demo script, I call it each time the script is executed, since it’s very likely that the token will expire in between uses. When the function is called, it runs the command “curl”, followed by some options:     $CURL_OPTS is from our curl options variable above. It includes the -k, -s, and HTTP headers so we can configure it once and apply it to all statements https://$HOST/api/mo/aaaLogin.xml is the URI for authentication. The HOST variable is defined at the top. -d “<aaaUser name=$USER pwd=$PASS> is the XML data for authentication. The variables $USER and $PASS were also defined at the top of the script. -c $COOKIEFILE tells the script to store the session info in the COOKIEFILE we defined earlier. Finally, we redirect the output to /dev/null. The curl command outputs response information in XML to screen. For a script like this, we don’t want that. For a more interactive program, we might capture the output and then perform another action based on it. Next is the usage() function, which is executed whenever you run the script with no arguments or when you type something other than enable/disable. It’s nice to provide guidance to other people using your tools.   The skip() function simply gives us info when a configuration is skipped; that is, when the option is not set to YES in the configuration section above. There’s a new variable called $OPTION, which we’ll cover in a moment. When a command completes successfully, there’s usually an exit code of 0 to indicate this. Any non-zero code tells us there’s a problem, or at least something happened that we want to know about. I used “return 1” to send back a non-zero exit status indicating that the option was not executed. You can test for that value (using the “$?” special variable which records the exit status of the previous command) and do something with it. Now we’re gonna get into the good stuff. Each APIC configuration function includes a comment for where each setting is in the GUI if you wanted to double-check it. For example, in the Mis-Cabling Protocol setting, you can verify it in the GUI by going to Fabric > Access Policies > Global Policies > MCP Instance Policy Default.     Let’s review the code snippet above. First, the function name is enable_mcp(), cleverly chosen because MCP is what we’re working with, and enable is the action we want to take. Ta Da! We include a test for the variable MCP and whether it is set to YES. Remember, MCP is the variable we configured earlier to tell the script we want to change the setting. If we kept the YES setting, then we print “Activating MCP Protocol” and then run the following curl command with the provided POST data. The DN of the object we’re working with is represented by the URI: https://$HOST/api/node/mo/uni/infra/mcpInstP-default.xml The XML data we’re providing starts again with the DN of the object in the data model, mcpInstPol, and each setting we want as a key=value pair. The ‘adminSt=”enabled”‘ enables the policy setting (boolean: enabled/disabled) while the other options configure specific attributes. The else statement tells us that if the MCP setting is NOT set to “YES”, then we should run this instead of the curl command. First, it sets the OPTION variable based on the configuration parameter for MCP, and then runs the “skip” function we discussed earlier. If you remember, the skip function provide information that the configuration is being skipped, probably because we didn’t set it to YES. Setting the $OPTION variable lets us reuse the function each time a config is skipped. Let’s look at the disable_mcp function.   We’re doing the same thing here as we did for enable. Testing that $MCP=YES in the config at the top, otherwise skip this option and tell the user that MCP options needs to be configured before we can do anything to it. The curl statement is just like the enable_mcp curl statement, except the XML data is a bit different. In this case, we set adminSt to “disabled”, which turns off the setting. None of the other parameters (like initDelayTime=”180″) are needed, because we’re simply turning all this off. If you wanted to update the parameters, like change initDelayTime=”180″ to initDelayTime=”90″, you would use the curl statement from enable_mcp, but change the XML as needed. The other functions are constructed the same way, one for each enable and disable setting, for each configuration option in our Best Practices article. Take a look at the best_practices_for_curling.txt file in the github repo and the original article. You may have noticed that I used the term “Activating” and “Deactivating” rather than enable/disable in the script itself. I did this because the Disable Remote EP Learning is a setting where you enable the setting to disable the feature. So technically, we’re disabling remote EP learning, but we’re doing it by enabling the setting. Confused? Yeah, me too.   Enable to disable. Disable to enable. Fnord. When confronted with lingual gymnastics like this, I tend to side with the users who just want to get their dang work done so they can go home and drink a beer. So I chose to use activate/deactivate to refer to the actual setting itself (we’re activating the “Disable Remote EP Learning” setting), while enable/disable is the broader objective of the script itself. We want to “enable” the best practices, which includes activating settings like Disable Remote EP Learning. There is always room for improvement. You may have wondered why there isn’t a command to simply list the existing parameters. The reason is that reading and parsing the XML data for displaying on screen is a bit more complex than POSTing the prepared XML. Not to worry! We’ll cover that in a future post very soon. We could also add a “reset defaults” option for completeness. Did you notice that each time you run the script, you’re sending up to nine API calls each time it’s executed? That’s not usually an issue for a one-off script, but isn’t a good practice for a utility in regular use (like an actual Ops Dashboard). A more robust approach would be to use each supplied configuration to construct a single XML data file, then send one POST request to the root/base URI with the new configuration. We could also include a check on the session token/cookie data to determine if the token is still valid before running another authentication request, while also accepting user/pass as command line parameters as well (or at least store them in a config file separate from the script itself), and throw a helpful error if no credentials are found. Finally, since we’re using the same URI for each enable/disable function, we could combine those into a single function that reads the original parameter (enable/disable) and sends the correct data accordingly. If you want to make any of these improvements to the bp-config.sh script, feel free to send us a pull request on github. If you have a script of your own that you would like to share with other ACI users, let us know! As always, help us help you! Drop a comment below to let us know if this blog was helpful. There are more to come right here on the ACI board on Cisco Community. And if you have suggestions regarding any other ACI related topics, let us know! ... View more

  The enterprise and campus footprints are just getting bigger with things like cameras, sensors and other IoT devices all connected to the internet, but also are our networks. Employees and customers are connecting to our networks from all different places using three or four different kinds of devices. Not only do networking people need to figure out how to allow all of this, but more importantly, they need to make sure it’s secure.   Traditionally, this would have taken a lot of time to configure due to manually configuring multiple polices for the same person depending on where they were connecting from and what device they were connecting with. However, SD-Access allows network admins to configure intent driven networking through Cisco DNA Center. Now discovering devices, creating policies, and pushing the configurations can all be done through the centralized GUI.   To see this in action, check out this demo that introduces SD-Access, DNA Center and the Network. Intuitive. ... View more

  The enterprise and campus footprints are just getting bigger with things like cameras, sensors and other IoT devices all connected to the internet, but also are our networks. Employees and customers are connecting to our networks from all different places using three or four different kinds of devices. Not only do networking people need to figure out how to allow all of this, but more importantly, they need to make sure it’s secure.   Traditionally, this would have taken a lot of time to configure due to manually configuring multiple polices for the same person depending on where they were connecting from and what device they were connecting with. However, SD-Access allows network admins to configure intent driven networking through Cisco DNA Center. Now discovering devices, creating policies, and pushing the configurations can all be done through the centralized GUI.   To see this in action, check out this demo that introduces SD-Access, DNA Center and the Network. Intuitive. ... View more

Congratulations and welcome to the start of your ACI journey!   Chances are, if you’re reading this, you’re amped-up to start your ACI experience and we’re excited to empower you with relevant content to make this journey all the more helpful. As with all of our products and services, we want to provide you with as much information as possible…without overloading you of course. So why not start with some introductory resources we feel would serve you best in the initial stages of your journey?   Here are the top 4, must-have resources you need to consume before you kick start your ACI adoption process:   1) Fundamentals of Cisco Software-Defined Networking Who doesn’t love a good video to jumpstart a product or service? This video jumps right into explaining the fundamentals of Cisco Software-Defined Networking and how Application Centric Infrastructure is truly the first-of-its-kind, valuable solution which resolves some of our most complex issues regarding data center networks. Listen to our expert discuss how ACI is the first data center solution to combine innovation in software, hardware, systems and ASICs. Learn more here.   2) The Cisco Learning Network: Cisco ACI Introduction The Cisco Learning Network is an awesome resource that empower folks just like you in attaining extensive knowledge of Cisco products and services. And what better way to display your expertise than through certifications? But in this video particularly, we have Cisco’s very own Technical Lead, Robert Burns, walking you through the ACI jumpstart training program. This will provide you with greater insight on complex ACI concepts, terminology, navigating through the GUI, configuring basic policies, and much more. Check it out here !   3) Learning Labs: Introduction to ACI Programmability Welcome to the DEVNET Learning Labs . What’s so cool about this platform? Glad you asked. Learning Labs directly connects you to useful tutorials covering complex engineering technologies, products, and concepts. And you know what product they cover here? Yep, you guessed it: ACI. Broken down by modules, you’re able to get a step-by-step guide of ACI concepts, programmability options, introduction to the toolkit and much more. Check it out for yourself here .   4) Cisco ACI Simulator Installation Guide Last but certainly not least, you all need to check out our handy dandy ACI Simulator Installation Guide . This guide primarily focuses on the inner workings of the Application Centric Infrastructure Simulator.  Sure it’s more geared towards data center administrators, but if you’re not an admin, this may still be instrumental to your ACI adoption journey. Want a deeper dive? Check it out here .   In an effort to make sure we’re providing you with top-notch content that’s helpful and most fitting to where you are in your current journey, drop us a comment and let us know if these resources were valuable.   ... View more

  With Smart Licenses you can easily view and manage your Cisco licenses. For your Next-Generation Firewall, below are the three licenses available – and what each one of these licenses can unlock:   Threat:   With the Threat License, you have access to Next-Generation Intrusion Prevention System (NGIPS), which combines superior visibility with embedded security intelligence, and automated analysis. With NGIPS, you can see and correlate extensive amounts of event data within your Next-Generation Firewall management console. By activating your Threat license, you’ll be able to detect and prevent intrusions and exploits, optionally drop offending packets, and block users from uploading or sending/receiving files of specific types.   URL Filtering:   The URL filtering license enables you to enforce policies on millions of URLs in more than 80 categories. You can restrict access to high risk or objectionable websites and reduce your overall attack surface. By activating your URL filtering license, you’ll be able to automatically gain control over suspect web traffic.   Malware:   Discover, track, contain, and block the progression of network-based advanced malware, zero-day attacks, and persistent threats. The Malware license helps you find hidden malware in your environment with Advanced Malware Protection and get advanced threat intelligence along with static and dynamic malware analysis with Threat Grid. By activating your Malware license, you’ll be able to stop malicious files from compromising your network.   To learn more about these Smart Licenses that are available with your Next-Generation Firewall, and how to get started on activating them, check out the Next-Generation Firewall Resource Center. ... View more

  With Smart Licenses you can easily view and manage your Cisco licenses. For your Next-Generation Firewall, below are the three licenses available – and what each one of these licenses can unlock:   Threat:   With the Threat License, you have access to Next-Generation Intrusion Prevention System (NGIPS), which combines superior visibility with embedded security intelligence, and automated analysis. With NGIPS, you can see and correlate extensive amounts of event data within your Next-Generation Firewall management console. By activating your Threat license, you’ll be able to detect and prevent intrusions and exploits, optionally drop offending packets, and block users from uploading or sending/receiving files of specific types.   URL Filtering:   The URL filtering license enables you to enforce policies on millions of URLs in more than 80 categories. You can restrict access to high risk or objectionable websites and reduce your overall attack surface. By activating your URL filtering license, you’ll be able to automatically gain control over suspect web traffic.   Malware:   Discover, track, contain, and block the progression of network-based advanced malware, zero-day attacks, and persistent threats. The Malware license helps you find hidden malware in your environment with Advanced Malware Protection and get advanced threat intelligence along with static and dynamic malware analysis with Threat Grid. By activating your Malware license, you’ll be able to stop malicious files from compromising your network.   To learn more about these Smart Licenses that are available with your Next-Generation Firewall, and how to get started on activating them, check out the Next-Generation Firewall Resource Center. ... View more

  With Smart Licenses you can easily view and manage your Cisco licenses. For your Next-Generation Firewall, below are the three licenses available – and what each one of these licenses can unlock:   Threat:   With the Threat License, you have access to Next-Generation Intrusion Prevention System (NGIPS), which combines superior visibility with embedded security intelligence, and automated analysis. With NGIPS, you can see and correlate extensive amounts of event data within your Next-Generation Firewall management console. By activating your Threat license, you’ll be able to detect and prevent intrusions and exploits, optionally drop offending packets, and block users from uploading or sending/receiving files of specific types.   URL Filtering:   The URL filtering license enables you to enforce policies on millions of URLs in more than 80 categories. You can restrict access to high risk or objectionable websites and reduce your overall attack surface. By activating your URL filtering license, you’ll be able to automatically gain control over suspect web traffic.   Malware:   Discover, track, contain, and block the progression of network-based advanced malware, zero-day attacks, and persistent threats. The Malware license helps you find hidden malware in your environment with Advanced Malware Protection and get advanced threat intelligence along with static and dynamic malware analysis with Threat Grid. By activating your Malware license, you’ll be able to stop malicious files from compromising your network.   To learn more about these Smart Licenses that are available with your Next-Generation Firewall, and how to get started on activating them, check out the Next-Generation Firewall Resource Center. ... View more