Network +security L3 - Computa Center
Network +security L3 - Computa Center
With a focused skill set on either Cisco ACI, Checkpoint FW’s or SDWAN technologies.
Candidates Experience in design/deployment and Run.
They should have experience in handling a team
Software defined networking can be defined as a new approach to design, implement and manage networks that is
based on the concept of separating the network control plane and data plane, where the control plane provides an
abstracted centralized view of the network.
The control plane you can think of as the brain of the network where the all the intelligence happens such as
routing function (path peering, path selection etc.)
Control plane on the other hand, you think of it as the muscular part where all the heavy load of the traffic
forwarding happens.
With the classical networking approach, both of these functions as co-exist on the same network device.
Using the SDN approach, as highlighted earlier these two functions are separated, in which the control plane is
Centralized and the forwarding plane is ket distributed.
As a result, SDN provide the ability of administering traffic and deploying services centrally to address changing
business needs, without having to touch each individual switch or router in the forwarding plane.
OpenFlow can be considered as the first (SDN) standard that is managed by Open Networking Foundation (ONF)
which facilitates the communications interface defined between the controls and forwarding layers of SDN
architecture. Moreover, SDN facilitates innovations and enable efficient services automation by providing open,
application programmatic interfaces (APIs).
As a result, SDN provide the ability of administering traffic and deploying services centrally to address changing
business needs, without having to touch each individual switch or router in the forwarding plane.
OpenFlow can be considered as the first (SDN) standard that is managed by Open Networking Foundation (ONF)
which facilitates the communications interface defined between the controls and forwarding layers of SDN
architecture. Moreover, SDN facilitates innovations and enable efficient services automation by providing open,
application programmatic interfaces (APIs).
Why SDN
OpenFlow-based SDN creates flexibility in how the network is used, operated, and sold.
It lowers operating expenses and results in fewer errors and less network downtime because it enables
automated configuration of the network and reduces manual configuration.
OpenFlow-based SDN enables virtualization of the network, and therefore the integration of the network
with computing and storage.
As a standard way of conveying flow-table information to the network devices, it fosters open, multi-vendor
markets.
However, OpenFlow based SDN lack to scalability, visibility, security and associated with complexity and disjoint
overlays. Cisco introduced a new approach and architecture that is driven from SDN with more emphasis on the
most important part in the Data center which is the application, called Application Centric infrastructure ACI .
Application Centric Infrastructure (ACI) in the data center is a holistic architecture with centralized automation and
policy-driven application profiles. ACI delivers software flexibility with the scalability of hardware performance that
provides a robust transport network for today’s dynamic workloads. ACI is built on a network fabric that combines
time-tested protocols with new innovations to create a highly flexible, scalable, and resilient architecture of low-
latency, high-bandwidth links
Open software flexibility for DevOps teams and ecosystem partner integration
Investment protection by integrating with the existing fabric infrastructure e.g. Nexus 7000
CI architecture Elements
Cisco ACI architecture is a combination of high performance Hardware and software innovation and intelligence
integrated with two important concepts from SDN solutions; overlays and centralized control. However the ACI
utilize different approach and offer capabilities that goes beyond the typical SDN offering or what is known as
Openflow based-SDN
A centralized policy management and Cisco Application Policy Infrastructure Controller (APIC)
A Cisco Application Virtual Switch (AVS) for the virtual network edge
Software and hardware innovations
The Cisco ACI fabric is designed as an application-centric intelligent network. The Cisco APIC policy model is defined
from the top down as a policy enforcement engine focused on the application itself and abstracting the networking
functionality underneath.
The Cisco APIC policy use an object-oriented approach based on promise theory. Promise theory is based on
declarative, scalable control of intelligent objects, in comparison to legacy imperative models, which can be thought
of as heavyweight, top-down management.
With this declarative model, using a centralized policy controller, you can define the policy centrally and push it out
and the endpoint should have the intelligence to abide by that policy. Therefore, these network nodes are not treat
as dumb devices, because the intelligence solely resides in the controller, instead the the controller will tell the
network node(s) what dose it needs to provision, change delete etc, but not how to be done.
The APIC centrally push policies to the underlying infrastructure using an extensible policy protocol designed to
exchange abstract policy between a network controller and a set of smart devices capable of rendering policy called
OpFlex. Cisco is proposing OpFlex as an informational RFC to the IETF and plans to lead the standardization process
through that forum. At the same time, Cisco is working with the open source community to provide an open source
implementation
ACI Farbic
ACI Fabric is based on an IP fabric supporting routing to the edge with an integrated overlay for host routing
All end-host (tenant) traffic within the fabric is carried through the overlay
Decoupling of endpoint identity, location, and associated policy, all of which are independent from the
underlying topology
Full normalization of the ingress encapsulation mechanism used: 802.1Q VLAN, IETF VXLAN, IETF NVGRE
Fabric provides a pervasive SVI, which allows for a distributed default gateway
Cisco is innovating across its Nexus switch portfolio to expand deployment options and help ensure investment
protection as networks evolve from traditional deployments to cloud deployments
Two new ACI-ready Nexus 9000 series switches: the Nexus 9336PQ fixed switch and the Nexus 9396TX, an
enterprise-class Top of Rack switch.
The Nexus 9336PQ offers advanced scalability in the industry's smallest spine form-factor, designed for small
to medium ACI spine deployments.
The Nexus 9396TX offers 100M/1G/10G copper-based front panel port connectivity for top-of-rack
deployments in both traditional 3-tier network designs and Cisco ACI enabled deployments.
The N9K-X9736PQ non-blocking line-card enables the Application Centric Modular Spine for the Cisco Nexus
9500 platform. The ACI line-card with 36 non-blocking 40GbE QSFP+ ports will help organizations to create
large-scale spine-leaf deployments.
The Nexus 7000 Series Switches add support for several open source tools and standards enabling
programmability and automation/SDN capabilities for virtualized and cloud deployments.
The Nexus 6004X Switch offers a new chassis that delivers added VXLAN capabilities with the same eight slot
form factor and feature set as the current Nexus 6004
Multi-Hypervisor-Ready Fabric
Integrated gateway for VLAN, VxLAN, and NVGRE networks from virtual to physical
The ACI fabric provides consistent low-latency forwarding across high-bandwidth links (40 Gbps and 100-Gbps).
Traffic with the source and destination on the same leaf switch is handled locally, and all other traffic travels from
the ingress leaf to the egress leaf through a spine switch. Although this architecture appears as two hops from a
physical perspective, it is actually a single Layer 3 hop because the fabric operates as a single Layer 3 switch.
The ACI fabric object-oriented operating system (OS) runs on each Cisco Nexus 9000 Series node. It enables
programming of objects for each configurable element of the system.
The ACI fabric OS renders policies from the APIC into a concrete model that runs in the physical infrastructure. The
concrete model is analogous to compiled software; it is the form of the model that the switch operating system can
execute. The figure below shows the relationship of the logical model to the concrete model and the switch OS.
All the switch nodes contain a complete copy of the concrete model. When an administrator creates a policy in
the APIC that represents a configuration, the APIC updates the logical model. The APIC then performs the
intermediate step of creating a fully elaborated policy that it pushes into all the switch nodes where the concrete
model is updated.
The APIC is responsible for fabric activation, switch firmware management, network policy configuration, and
instantiation. While the APIC acts as the centralized policy and network management engine for the fabric, it is
completely removed from the data path, including the forwarding topology. Therefore, the fabric can still forward
traffic even when communication with the APIC is lost.
The Cisco Nexus 9000 Series switches offer modular and fixed 1-, 10-, 40-, and 100-Gigabit Ethernet switch
configurations that operate in either Cisco NX-OS stand-alone mode for compatibility and consistency with the
current Cisco Nexus switches or in ACI mode to take full advantage of the APIC's application policy-driven services
and infrastructure automation features.
Chapter: ACI Policy Model
About the ACI Policy Model
The ACI policy model enables the specification of application requirements policies. The APIC automatically renders
policies in the fabric infrastructure. When a user or process initiates an administrative change to an object in the
fabric, the APIC first applies that change to the policy model. This policy model change then triggers a change to the
actual managed endpoint. This approach is called a model-driven framework.
As a model-driven architecture, the software maintains a complete representation of the administrative and
operational state of the system (the model). The model applies uniformly to fabric, services, system
behaviors, and virtual and physical devices attached to the network.
The logical and concrete domains are separated; the logical configurations are rendered into concrete
configurations by applying the policies in relation to the available physical resources. No configuration is
carried out against concrete entities. Concrete entities are configured implicitly as a side effect of the
changes to the APIC policy model. Concrete entities can be, but do not have to be, physical (such as a virtual
machine or a VLAN).
The system prohibits communications with newly connected devices until the policy model is updated to
include the new device.
Network administrators do not configure logical and physical system resources directly but rather define
logical (hardware independent) configurations and APIC policies that control different aspects of the system
behavior.
Logical Constructs
The policy model manages the entire fabric, including the infrastructure, authentication, security, services,
applications, and diagnostics. Logical constructs in the policy model define how the fabric meets the needs of any of
the functions of the fabric. The following figure provides an overview of the ACI policy model logical constructs.
Fabric-wide or tenant administrators create predefined policies that contain application or shared resource
requirements. These policies automate the provisioning of applications, network-attached services, security policies,
and tenant subnets, which puts administrators in the position of approaching the resource pool in terms of
applications rather than infrastructure building blocks. The application needs to drive the networking behavior, not
the other way around.
The fabric comprises the physical and logical components as recorded in the Management Information Model
(MIM), which can be represented in a hierarchical management information tree (MIT). The information model is
stored and managed by processes that run on the APIC. Similar to the OSI Common Management Information
Protocol (CMIP) and other X.500 variants, the APIC enables the control of managed resources by presenting their
manageable characteristics as object properties that can be inherited according to the location of the object within
the hierarchical structure of the MIT.
Each node in the tree represents a managed object (MO) or group of objects. MOs are abstractions of fabric
resources. An MO can represent a concrete object, such as a switch, adapter, or a logical object, such as an
application profile, endpoint group, or fault. The following figure provides an overview of the MIT.
The hierarchical structure starts with the policy universe at the top (Root) and contains parent and child nodes. Each
node in the tree is an MO and each object in the fabric has a unique distinguished name (DN) that describes the
object and locates its place in the tree.
Tenants
A tenant (fvTenant) is a logical container for application policies that enable an administrator to exercise domain-
based access control. A tenant represents a unit of isolation from a policy perspective, but it does not represent a
private network. Tenants can represent a customer in a service provider setting, an organization or domain in an
enterprise setting, or just a convenient grouping of policies. The following figure provides an overview of the tenant
portion of the management information tree (MIT).
Tenants can be isolated from one another or can share resources. The primary elements that the tenant contains are
filters, contracts, outside networks, bridge domains, Virtual Routing and Forwarding (VRF) instances, and application
profiles that contain endpoint groups (EPGs). Entities in the tenant inherit its policies. VRFs are also known as
contexts; each VRF can be associated with multiple bridge domains.
Tenants are logical containers for application policies. The fabric can contain multiple tenants. You must configure a
tenant before you can deploy any Layer 4 to Layer 7 services. The ACI fabric supports IPv4, IPv6, and dual-stack
configurations for tenant networking.
VRFs
A Virtual Routing and Forwarding (VRF) object (fvCtx) or context is a tenant network (called a private network in
the APIC GUI). A tenant can have multiple VRFs. A VRF is a unique Layer 3 forwarding and application policy domain.
The following figure shows the location of VRFs in the management information tree (MIT) and their relation to
other objects in the tenant.
A VRF defines a Layer 3 address domain. One or more bridge domains are associated with a VRF. All of the endpoints
within the Layer 3 domain must have unique IP addresses because it is possible to forward packets directly between
these devices if the policy allows it. A tenant can contain multiple VRFs. After an administrator creates a logical
device, the administrator can create a VRF for the logical device, which provides a selection criteria policy for a
device cluster. A logical device can be selected based on a contract name, a graph name, or the function node name
inside the graph.
Application Profiles
An application profile (fvAp) defines the policies, services and relationships between endpoint groups (EPGs). The
following figure shows the location of application profiles in the management information tree (MIT) and their
relation to other objects in the tenant.
Application profiles contain one or more EPGs. Modern applications contain multiple components. For example, an
e-commerce application could require a web server, a database server, data located in a storage area network, and
access to outside resources that enable financial transactions. The application profile contains as many (or as few)
EPGs as necessary that are logically related to providing the capabilities of an application.
Endpoint Groups
The endpoint group (EPG) is the most important object in the policy model. The following figure shows where
application EPGs are located in the management information tree (MIT) and their relation to other objects in the
tenant.
An EPG is a managed object that is a named logical entity that contains a collection of endpoints. Endpoints are
devices that are connected to the network directly or indirectly. They have an address (identity), a location,
attributes (such as version or patch level), and can be physical or virtual. Knowing the address of an endpoint also
enables access to all its other identity details. EPGs are fully decoupled from the physical and logical topology.
Endpoint examples include servers, virtual machines, network-attached storage, or clients on the Internet. Endpoint
membership in an EPG can be dynamic or static.
EPGs contain endpoints that have common policy requirements such as security, virtual machine mobility (VMM),
QoS, or Layer 4 to Layer 7 services. Rather than configure and manage endpoints individually, they are placed in an
EPG and are managed as a group.
(https://www.cisco.com/c/en/us/td/docs/switches/datacenter/aci/apic/sw/1-x/aci-fundamentals/b_ACI-
Fundamentals/m_policy-model.html#concept_5FE260BAAC514DB58AD6E70B3A3959A4)