ACI - security policy / cluster multicast support

[CSCO10662744_2]

In a webinar, it was mentioned application teams don't need to know which ports are used.
All they have to do is pick a security policy, to allow web tier to talk to app tier.

How does ACI know which ports are used for an app?
Doesn't someone (network, or apps team) still need to find out that information, and create such security policy?
In reality, I'm a network admin, and don't know this info.
Wouldn't I still need to ask the apps team which ports their app uses?
============

Also, how would Microsoft or Oracle clusters work in ACI?
In non-ACI networks, we'd create multicast groups for special purpose app clusters.
Is that needed in ACI?

TIA

[Venkata Naveen Chapa]

Cisco’s ACI groups all of these web tier and app tier into an Application Network Profile. An Application Network Profile is a logical profile outlining how an application will look, connect, and be treated on the network fabric.  The application profile, which is a logical template, gets deployed down onto a stateless network infrastructure including the layer 4 – 7 network services that are required for that application deployment.  Essentially, we are using a model that makes sense to the application owners deployed onto the network via a logical GUI- driven template that is installed in seconds, as opposed to the weeks it can take to tailor a network in traditional architectures.   

Endpoint groups (EPGs) are what make up any of the given tiers within this Application Network Profile model.  ACI groups endpoints together for the enforcement of policy and uses these EPGs as a policy instantiation point.   Typically, the way that we do policy instantiation (qos, SLAs, Layer 4-7 services, security) in traditional architectures is based on things like layer 3 IP address, layer 4 TCP, or UDP port numbers.

The problem with traditional network terms (layer 3 IP addresses and Layer 4 port information) is they aren’t really application relevant terms, and they aren’t terms that an application developer knows or should have to know.   So, ACI uses things that make sense to a developer; such as the components of the tiers of the application.  ACI uses EPGs to put endpoints into these groups – endpoints are virtual servers, physical servers, or services running on any given server.   ACI then implements policy based on those boundaries of groupings, rather than implementing it on traditional networking information such as IP address or Layer 4 TCP/UDP port.

At this point, it doesn’t matter what IP subnet an EPG is in, or if that EPG has multiple IP subnets, or specific layer 4 information; we are grouping based on the fact that they are a tier or component of the application and require a common policy.  Then, we implement a policy between these groups based on the connectivity graph that we draw within the Application Network Profile.

Thanks 

Naveen

[CSCO10662744_2]

Thank you for the reply, and the detailed explanation of what ACI is about, and its benefits, but my questions remain unanswered.

Even though ACI's supposed to abstract the traditional requirement for developers to speak network language, the network still needs to know which ports to allow between EPG's, or different app tiers.

My question, as a network engineer, is how does ACI know about them?

Don't we still need to find out, and define such security policies?

Same question for the cluster support, how does ACI know how to support Oracle clusters that require multicast?

[Joseph Young · Accepted solution]

Yes, you need to know which ports should be permitted so that you can build your contracts. A successful ACI migration will require a great deal of communication between network engineers and developers. Additionaly Cisco has developed their Tetration solution with this purpose in mind...to provide granular visibility into your data center traffic flows. Netflow will also be available in the 2.2 release which should come out later this month.