This is the first of the articles you've written that I've read. I intend to read "New EPG" and "BD Template" deployment model articles next. The following are my comments/questions. Of course, in some of my experiences I could personally be doing something wrong with or without knowing it, so bear that in mind as you read. Primary Guiding Assumptions section is fully understood. ACI Configuration section is fully understood. CC Application Profile section: Is the “enable micro-segmentation” checkbox new as of v4.7.3 and required for successful application deployment with an ACI integration? Reason for the question: I was not aware of this checkbox, as such my recent app deployment tests ran with this checkbox disabled. App deployments sometimes succeeded and sometimes failed. What are the intended/true impacts of enabling this setting? What is the point of configuring the 0.0.0.0/0 TCP/80 firewall rule on the web-tier app node (or any other firewall rule on any other tier app node) if this article is about existing EPGs and per assumptions, existing EPGs are wholly sufficient and CC will not manipulate existing EPGs? I learned about “contextual association” of firewall rules between tiers which I didn’t know about previously (or had not previously noticed/attempted), so thank you for that. However, it seems limiting that in order for this to work properly that the DB tier firewall rules must be configured BEFORE drawing the ‘drag and drop’ connection between tier elements in the workspace. This comes down to an ‘order of configuration operations’ requirement within the software itself and from my perspective is an unlikely to occur. I personally would lay out all of my app tiers in the workspace, draw their dependencies, and then set out to configure the requirements for each tier (top down: look at the big picture before looking at the small picture within each of the finer app tier elements). I would argue that this functionality should work regardless of the order of configuration operations within CC software. From my perspective, to have a dependency on the order of configuration operations is to generate a lot of support calls for no good reason. If that’s not going to change I would argue against using contextual firewall rules between tiers and use firewall rules leveraging IP space to identify the desired tier since it’s likely each tier will be designed with its own IP space to begin with (not necessarily true when ACI is deployed in an application centric model, where all app tiers may be held within the same IP space because IP is just an identifier and has nothing to do with policy). Also, back to Q2… per assumptions, I thought we said none of these contracts would apply to existing EPGs anyways? CC Environment section is fully understood. CC Deployment Submission section: If the L3OUT pre-exists as it must in the ACI fabric, for what reason would we not select this in the Deployment Environment Defaults? My understanding is that Deployment Environment Defaults, while exposed to consumer-based users of CC, can still be modified by the user… in which case, does it really matter if any of these settings are selected or not, other than to try to guide the user when ultimately they are responsible for understanding how all of these settings could impact their application deployment efforts (which I feel is unrealistic for most shops)? My understanding is that Simplified Networking is used in an attempt to limit what the consumer-based user can modify before deployment (in my mind this is a good thing), however in my testing I’ve found that despite Simplified Networking containing an opportunity to define all of the same settings, deployment using Deployment Environment Defaults functions properly and Simplified Networking does not. Exceptions section. Maybe going to answer one of my own previous questions. So if I’m reading this correctly, CloudCenter will create ACI artifacts when “Existing EPG” deployment model is chosen if the L3out selection is configured? I personally would always choose the L3out so as to be deterministic about desired traffic flows… which now means that ACI would create and apply artifacts (contracts) to node Existing app-node EPGs to ensure communication between them and EPGs within the common tenant or with the outside work (External EPG)? To summarize: In my mind, “Existing EPGs” means what the assumptions stated at the beginning of the article. In this mode I expect zero automation of any kind coming from CC with regards to ACI artifacts being created or terminated. In fact, in this mode I do not want CC making any changes regardless of which settings may or may not have been selected (L3out, etc).
... View more
I'm monitoring a number of a switches in a customer environment. I used CPI automated discovery and SNMP to load the switches into the system. Even though I can see basic system summary and interface information for a particular switch, I'm unable to see any Client information such as 'Current Associated Clients'. Here is one way to navigate to the area that I'm referring to: LifeCycle Theme > Operate > Device Work Center ALL > Pick A Switch, check the box next to it Device Details Tab > Clients > Current Associated Clients The CPI 1.2 documentation say sI should be able to see 'wired' client information on this screen and lists no pre-requisites to doing so. I can't figure out why I'm not seeing any data ('no data available') and can't find any information on how to 'deploy' this functionality or troubleshoot why it's not working. The switch is online in 'managed' status and I know it has clients on it, this has been validated by typical CLI. Any ideas anyone? Thanks in advance for the help. Dan
... View more