08-10-2023 02:49 PM
I'd just like to hear everyones opinion on a simple greenfield ACI design. Below is a simple 3 tier application that we'd like to use as a starter template to migrate all applications. I have a few questions below.
08-10-2023 11:05 PM - edited 08-10-2023 11:06 PM
Hello @dnoc43,
- A /20 subnet might be too big for a single BD, especially in a greenfield setup. It's often recommended to follow a /24 or smaller subnets for better IP address utilization, easier management, and to limit broadcast domains.
- Yes, it's generally a good practice to have each tier in its own BD with separate subnets. This provides segmentation, isolation, and helps in applying policies specific to each tier.
- In the context of a one-arm ADC, you don't necessarily need different BDs for each tier for the service graph. You can map different EPGs within the same BD to different tiers of the service graph.
- Using a service graph allows for more dynamic policy-based traffic steering and manipulation compared to simply sending traffic to L3 out to access the ADC VIP. Service graphs provide better control over traffic flow and enable more advanced features.
- Service graphs provide a way to orchestrate complex application flows. If you have multiple tiers and need to apply different policies or services at each tier, a service graph can simplify the configuration and enhance visibility.
- Creating a service graph from web to app does not inherently expose all app VIPs to web EPGs. You have control over how traffic flows within the service graph, and you can control which VIPs are exposed.
- Chaining firewall and ADC service graphs can be beneficial to control and secure the traffic between tiers. This approach allows for better visibility, monitoring, and enforcement of policies.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide