ACI Release 3.2 New Features
Three weeks ago Cisco released ACI version 3.2. This is the new long-lived release version of ACI and therefore the recommended version to deploy in new deployments or when upgrading. (Versions 2.1 and 2.2 are also long-lived releases and can still be used).
Most of the really new features were introduced in the 3.0 release, but 3.2 also boasts some interesting features. The release notes list them all, but I would like to zoom in on a few of them in this post.
The release notes for the 3.2 version can be found here
Anycast is a service used often on the internet. The most well known anycast service is the DNS service. The DNS root servers all use anycast. The idea behind anycast is that you connect to an IP address and that the network will route you to the nearest instance of that IP address. This implies that the IP address is used by more than one system, which is correct.
So for example, if you have clients in both Amsterdam and New York. These clients want to access a website. In a scenario without anycast you would need to decide where to place the webserver and live with the consequences of it. If you place it in Amsterdam, the users of the site from New York will experience a slower website and if you place the webserver in New York, the users from Amsterdam will have a slower website. Of course some solutions exist like Global Server Loadbalancing in which each site has a different IP address and you give the closest IP address to each user. The downside of many of these solutions is when one of the sites goes down (due to problems or maintenance). Many of the Global Server LoadBalancing solutions have to consider cache.
Anycast solves this by always routing to an available server. If the server is unavailable, the IP address should not be advertised.
The usecase for ACI is when you have a multi-pod or multi-site deployment and you want to keep traffic in the local datacenter as much as possible. Say for example a DNS server. Place a DNS server in both DC’s and give them the same IP address. The client will then always use the closest DNS server. If that server is unavailable it will be redirected to a server somewhere else inside the fabric. Another usecase is an active-active firewall service in which traffic is directed to the closest firewall.
More information about anycast in the ACI fabric, including requirements and restrictions for the implementation can be found here
Contract and Subject Exceptions
Exceptions inside contracts allow you to deny a subset of contract providers or consumers to participate in the contract. This enables you to create a more complete security policy with less contracts. Say for example you have an EPG containing both DNS and NTP services. You want to supply NTP to all devices available in the fabric, but DNS only to all Production systems. Previously you had to create several contracts to be able to do this. You had to create one contract that provided NTP and consume this from all EPG’s and you had to create a DNS contract that was only consumed from the Production EPGs.
Aside from being more labour intensive, this could cause issues when somebody accidentally consumed the contract from a non-Production EPG.
When using Exceptions you can create one contract that allows DNS and NTP, but create an exception for the non-Production EPG’s. You can create these exceptions in several ways. It is possible for example to use wildcards.
An example (provided by Cisco) is as follows:
<vzException consRegex= “EPgPa*” field= “EPg” name= “excep03” provRegex= “EPg03” />
This would prevent all EPG’s starting with EPgPa in their name from consuming this contract provided by EPG EPg03.
More information about this feature can be found here Scroll down to Configuring Contract or Subject Exceptions for Contracts.
Layer 3 port-channels
Not much needs to be explained about L3 port channels, but they are supported now.
More information here
Cisco Smart Licensing is Cisco’s new way of managing licenses. According to the promotional information its a “new, time-saving method of customer or partner-managed software license asset management”. In regards to ACI the first thing you’ll notice when you’ve upgraded to 3.2 is a new yellow warning message stating that smart licensing has not been configured. It will also state that you have 90 days of evaluation remaining. This might make you feel a bit uncomfortable, but reassuringly they also state “There will be no impact on the functionality of the ACI fabric at the end of the evaluation period”. However, when the evaluation period has definitively expired (for some reason you will get two evaluation periods) you will receive a major fault stating that you must register the APIC.
More information about Smart Licensing for ACI can be found here