Hello, First of all, both the Application Centric Design and the Network Centric Design are valid design strategies, and you can read more of the official Cisco view on the URL link: https://www.cisco.com/c/en/us/td/docs/switches/datacenter/aci/apic/sw/1-x/ACI_Best_Practices/b_ACI_Best_Practices/b_ACI_Best_Practices_chapter_010.html#id_26532 Pros of an Application Centric Design vs Network Centric Design 1. Application developers don't need to be tied to the Network team for the allocation of new subnets and VLANs to be able to implement policy between groups of servers (EPGs). Once an initial Bridge Domain and Subnet has been allocated, they can peel off as many EPGs as they want until they run out of IPs. And even then... 2. ...if required, the same Bridge Domain can be allocated multiple IP Addresses across multiple subnets, and if this is done... 3. ...there is no restriction about which servers are in which subnet - the only restrictions come via the Contracts between the EPGs. Cons of an Application Centric Design vs Network Centric Design 1. A single Bridge Domain is still a single Broadcast Domain, just as a single VLAN is a broadcast domain in a traditional network - apart from the fact that ACI can reduce ARP broadcast traffic and some BUM traffic (Broadcast, Unknown Unicast and Multicast traffic). So, you need to remember that... 2. ...just like since forever, you should be wary of having broadcast domains that are too big. How big is too big? But in part it depends on how the following options are enabled on your Bridge Domain: * L2 Unknown Unicast [Not flooded by default - instead sent to the proxy] * L3 Unknown Multicast Flooding [Flooded by default. Can be Optimized so only Multicast Router ports receive L3 Unknown Multicast] * Multi-Destination Flooding. [Flooded in BD by default] * ARP Flooding [Disabled by default. ARP traffic is routed based on the Target IP address] Assuming you have left the options above at their defaults (which is what happens if you specify Optimize as the Forwarding method when you create the bridge domain) then you will be able to create a larger Bridge Domain than the traditional Broadcast Domain you would have been able to create using traditional networking methods. (Switches/VLANs). But, there are some limitations on those optimized values, and if you need to change them in the future, you may find that your BD suddenly has to cope with more BUM traffic than before. Specifically: * L2 Unknown Unicast - not much to worry about there, you should never have any valid Unknown L2 traffic, so let it be sent to the Proxy * L3 Unknown Multicast Flooding - Not sure why you wouldn't set this to Optimized Flood, but again, you are unlikely to have to worry about too much unknown Multicast traffic. However, if you DO optimize L3 Unknown Multicast traffic, you are limited to optimizing 50 BDs per switch. Which should be plenty in most cases but might a pain to troubleshoot if exceeded. * Multi-Destination Flooding - This is one that can get a little out of control. Multi-Destination means L2 Multicasts and Broadcasts that aren't consumed by the Leaf Switch. (E.g. LLDP Multicasts are consumed by the Leaf Switch). Capture a few minutes of traffic on a given switch port on your own corporate network (if you are allowed to do that without breaching company policy) and look at all the weird traffic you capture that is NOT being sent to your PC. This is your typical Multi-Destination traffic. Amongst it you will likely see some NetBIOS broadcasts as well as lots or ARP requests. * If you tell ACI to Drop Mult-Destination frames, you may break some protocols - I can't think of any in particular at the moment, but my first suspects would be file sharing applications, like Windows Filesharing or Apple File Sharing and even DropBox. * IMPORTANT In a single BD with Multiple EPGs, each EPG is defined by a different VLAN encapsulation. IF those VLANs extend into you legacy non-ACI network, then (by default) these frames will leak from one VLAN to another - which is probably NOT what you want, which is why there is a Multi-Destination Flooding option to Flood in Encapsulation - to prevent leakage from one EPG to another - but again, this may break some protocols. But before setting your BD to Flood in Encapsulation re-read the IF statement above. * ARP Flooding is the most important of these options. There are times when you need to enable ARP flooding, such as if you have a silent host on a subnet that does not exist in the ACI environment (if your BD has an IP address on the same subnet as the silent host, ACI will encourage the silent host to speak by sending it an ARP request). The quintessential case for this is when one of you EPs is in fact a router port or a firewall interface. So, just remember that IF you have such a situation, it may be worth separating the BD where the Firewall/Router lives into a separate BD if possible. * Application Centric Designs do not follow the normal expectations of network engineers who have to troubleshoot networking issues, so troubleshooting may be more difficult. Pros of a Network Centric Design vs Application Centric Design 1. If your situation is one of migrating an existing network to ACI, a Network Centric approach is much more aligned to the existing structure and therefore much easier to implement. This is pretty much an overriding reason why most ACI implementations end up with at least some part of the design being Network Centric. 2. A Network Centric approach looks much more like a traditional design. This gives some people a lot of comfort, especially Network engineers who can't handle the new-fangled software-designed thingy that might threaten their life. The more like the old network it is, the better they like it. 3. There are some cases, such as when leaking routes between VRFs, that are easier to implement in a network centric design. 4. When working with Layer 4-7 devices that require traffic to directed to an IP address that is not part of the ACI Fabric (think Firewall), a Network Centric design is easier to work with. Cons of a Network Centric Design vs Application Centric Design 1. A network centric design requires more careful IP subnet planning - much the same as it is now. 2. Application designers and writers of orchestration applications will probably find it harder to work within the restraints of a Network Centric Design. Think about it. If you are writing an Orchestration Application that is going to spin up half a dozen VMs with policies between them, is it easier to put all servers in the same subnet (Application Centric), or easier to find say 3 different subnets to put the servers in (Network Centric)? Conclusion One approach is not necessarily better than the other. When migrating existing VLANs/Subnets, a Network Centric approach is recommended. When writing an Orchestration Application, an Application Centric approach is recommended. If neither is more important, and each is equally easy to implement, recommendation is to stick with a Network Centric approach because it gives you better flexibility to later implement L4-7 services and control BUM traffic. ... View more

Your question is very clear. You can just simply add another subnet say 172.16.2.100/24 to the BD to make it work. If the client still does not know how to reach the newly add subnet, then within the BD Properties, you may have to change the Scope to Public Subnet so the newly added subnet will get advertise. ... View more

Hello, The recommended solution for this migration is to deploy the Layer 4 through Layer 7 (L4-L7) service graph. Using the service graph, Cisco ACI can redirect traffic between security zones to a load balancer, without the need for the load balancer to be the default gateway for the servers. In an One-arm mode, the default gateway for the servers is the server-side bridge domain, and the L4-L7 device is configured for source NAT (SNAT). In this One-arm mode, the VRF instance is created and associated with all three bridge domains. One bridge domain is created for the outside, or client side (BD1); One bridge domain is created for the inside, or server side (BD2); And one bridge domain is created for connectivity with the load balancer (BD3); With this setup, you can optimize flooding on BD2. In one-arm mode, the default gateway for the servers is the router upstream. The load balancer is connected with one VLAN to the router as well, which is the default gateway for the load balancer itself. The load balancer uses source NAT for the traffic from the clients to the servers to help ensure receipt of the return traffic. The default gateway for the servers is the subnet on BD2. The default gateway for the load balancer is the subnet on BD3. The contract is established between the external EPG and the server EPG, and it is associated with the service graph. On BD3 the load balancer forwards traffic from the clients to the servers by routing it through the Cisco ACI fabric. Therefore, you need to make sure that the only addresses learned in BD3 are the ones that belong to the BD3 subnet: that is, the virtual addresses announced by the load balancer and the NAT addresses. Additional information about LB-PBR scenario your VIPs will typically be part of the LB-service BD itself, so the VIP-subnet is directly connected to ACI. https://www.cisco.com/c/en/us/solutions/data-center-virtualization/application-centric-infrastructure/white-paper-c11-739971.html In the meantime, I am doing some more searches about the detail configurations of your scenarios and if it's available, will forward them to you. ... View more

Hello, After doing some research, Yes, the fabric policy model can be used to queried about an existing flow between two endpoints with a default (open) contract between them so you can determine what TCP or UDP ports are actually in use. ... View more

Hello, for Port-channel migration, if you keep one cable on the brownfield switch, and the other to one of the ACI vPC, the existing Port-channel would not flap. Until all endpoints in the brownfield migrated over to the ACI vPC, then you can tear down the vPC links in the brownfield. Also, the Bridge Domain Setting is important. Make sure that you are temporary "enable flooding of L2 unknown unicast", and "enable ARP flooding". After the migration, put the Bridge Domain setting back to default. ... View more

Hello, DHCP Relay Overview While ACI fabric-wide flooding is disabled by default, flooding within a bridge domain is enabled by default. Because flooding within a bridge domain is enabled by default, clients can connect to DHCP servers within the same EPG. However, when the DHCP server is in a different EPG, BD, or context (VRF) than the clients, DHCP Relay is required. Also, when Layer 2 flooding is disabled, DHCP Relay is required. This attached documents has all of the details related to "DHCP Relay in ACI" and how to decode Option 82. ... View more

Hello, You can use layer 3 VLAN 4 interface to configure instead of subinterface. The use of subinterfaces on the links connecting the IPN devices is optional and only required when multiple VRFs need to be connected over the same physical interface. ... View more

Hello, ACI doesn't filter between IP addresses, but between EPGs. An example of ACL from the Brownfield: permit tcp 192.168.50.77 0.0.0.0 172.16.30.21 0.0.0.0 eq 37 So this is what you need to do (I've assumed /24 subnets and default gateway addresses of x.x.x.1): Create a Bridge Domain - let's call it 192.168.50.0-BD * Add an IP address to the BD - make it the default gateway for the 192.168.50.0/24 network, presumably 192.168.50.1/24 Create another Bridge Domain - let's call it 172.16.30.0-BD * Add an IP address to the BD - make it the default gateway for the 172.16.30.0/24 network, presumably172.16.30.1/24 Create an EPG - let's call it 192.168.50-EPG * and put host 192.168.50.77 in that EP Create another EPG - let's call it 172.16.30-EPG * and put hosts 172.16.30.21 in that EPG Create a filter for TCP Port 37 Create a contract * Add a subject to the contract * Add a filter to the subject Apply the contract between the two EPGs, presumably with 172.16.30-EPG providing the contract and 192.168.50-EPG consuming the contract. I am not aware of a scalability calculation method available. the maximum limit of EPG, filters and contracts for ACI: For EPG, the maximum limit is 15,000 For Filter, the maximum limit is 10,000 For Contract, the maximum limit is 10,000 ... View more

Hello, For question #1, Migrating hosts with Etherchannel / MLAG connection from brownfield switches (non-Nexus) to the ACI leaves? The typical downtime should be between a half an hour to 45 minutes. That would give you times to move hosts, test out connectivity and traffics. For question #2, Can the migration vPC interface (L2 Trunk vPC interface) be used for both EPG static port and L3Out SVI? Yes, it can be used for both EPG static port and L3Out SVI. For question #3, In a network-centric model, the current gateway MAC (on our firewall) would also be used by the BD as we migrate the default gateway to the ACI fabric. The typical downtime should be about a half an hour. For this question, In version 4.2 (or later than 3.2) what's your opinion on using vzAny-vzAny contract, its subject has common/default filter (with PBR to redirect to firewall)? It would work. But for your requirements such as like IP traffic being redirected, non-IP bypassing the firewall, you should use a more detailed filter. ... View more

Hello, Yes, just lift and shift if you want your remote to be physically move to the main DC.  When the remote physically moved to the main DC, just connect the remote leaf(s) that just moved to the Spine(s) and the fabric will automatically discover the new leaf(s) and add them to the fabric.  The IP schema should be preserved assuming they are not in conflict with the current main DC ACI.  ... View more

Hello, The example of how the policy model can be queried for that info through the GUI on the APIC. Before creating the contract, we’ll start by creating filters, being the protocols we’re using to allow traffic between two EPGs. For this example we will create a filter for a contract that will go between a Database EPG and an Application EPG. In this example, the database EPG (DB-EPG) will be providing database services to the Application EPG (App-EPG), using port 1433 as a common MS SQL port. Create Filter:   Log in to your APIC Click Tenants and make sure to select the tenant you’re going to use Expand Security Policies on the Left Navigation Tree Select Filters Right click on Filters and select Create Filter In the pop-up give it a name such as “DB-Filter” You can put in an optional description Click the + sign next to Entries to add a new filter Put in a name such as MSSQL The configurations here will depend on what you’re trying to do. You may want to speak with your firewall administrator to see what is recommended. For this example I will use IP as my Ethertype. I will select TCP as my IP Protocol For my destination ports I’ll type in 1433. Notice I can use the pull down to select ports that are already available, but I don’t have to. I can enter anything I want, just be careful that you don’t hit TAB or it will change the value in this field Click Update Click Submit Now that we have the Filter created we can create a Contract in which to put it. Keep in mind, I’m assuming you already have two EPGs, in this case we’re using DB-EPG and App-EPG. Create contract: While still in your tenant expand Security Policies Select Contracts Right click on Contracts and click Create Contract. Give it a name such as DB-Contract-MSSQL Give it an optional description Click the + sign next to subjects (remember a subject contains a filter, object, and optional label) Give the subject a name, such as MSSQL-Subject We can leave the two check boxes checked as they will allow for bidirectionality. However, if we only want to apply these filters unidirectionally from provider to consumer we can uncheck these. Click the + Sign next to Filters and select the filter we created in the last step (DB-Filter) Click Update Click OK Click Submit We have an App-EPG and a DB-EPG, we also have a contract created, so to complete our Application Network Profile, we need to attach our contract between the EPGs. Create and Application Network Profile: Right click on your DB-EPG Select Add Provided Contract In the pull-down menu select the contract you just created Click Submit Now right click on your App-EPG Select Add Consumer Contract In the pull-down menu select the contract you just created Click Submit Now if you click on the Application Profile that contains these to EPGs and Contract we see the topology where DB-EPG allows App-EPG to see traffic over port 1433.   ... View more

Hello, Yes, the ACI policy model can be queried to find out what flows are in use between endpoints that have a default contract between them. An administrator uses a contract to select the type(s) of traffic that can pass between EPGs, including the protocols and ports allowed. If there is no contract, inter-EPG communication is disabled by default. There is no contract required for intra-EPG communication; intra-EPG communication is always implicitly allowed. Thanks, Tuan Nguyen ... View more

Initial consideration for information gathering to migrate to ACI: - Starting from a traditional network (Your current traditional 3 tiered Network) - Your current traditional 3 tiered network could be built leveraging vPC, STP, FabricPath, VXLAN or even 3rd party devices - Assumption is also that network services are connected in traditional fashion (routed mode at the aggregation layer) - Default gateway in this case could be at the spine or on a pair of Border Leaf nodes - Creating a L2 connectivity path between your current traditional 3 tiered aggregation layer devices to a pair of Border Leaf nodes - No connectivity between leaf switches and no connectivity between spine switches for loop prevention mechanisms.  Only leaf switches connect to spine switches. Additional references related to Migrating Existing Network to ACI:   https://www.cisco.com/c/en/us/td/docs/switches/datacenter/aci/apic/sw/migration_guides/migrating_existing_networks_to_aci.html ... View more