Skip to main content

Posts

Cisco SDA - Components

Cisco Software Defined Access is a new paradigm towards building Enterprise Networks. Primarily built upon the Cisco's DNA Center software, it leverages several next-generation components to design, provision and apply policy to create an intelligent wired and wireless network infrastructure. Cisco DNA Assurance which turns the network devices into sensors, giving visibility to everything on the network; guided remediation which automates resolution to keep the network at its optimal performance and thereby improve the end user experience, are some of Cisco's USPs. Cisco SDA accomplishes this intent based networking via the following components: Fabric Control Plane nodes: Based on LISP map-server and map-resolver functionality combined together on the same node, control plane node (database) tracks the endpoints in the fabric site and associates the endpoints to fabric nodes. Border nodes and edge nodes register with the control plane nodes. Control Plane node can be dedicate

Cisco ACI - Forwarding inside the Fabric

One of the most intriguing (of course, if you get the hang of it) or depressing concepts of Cisco ACI is how the traffic forwarding takes place inside Cisco ACI. Let's start with an endpoint sending the frame to the connected leaf: The leaf checks the destination MAC address of the frame. The leaf will do a layer 2 lookup to find the destination MAC. If the leaf knows the location of the destination MAC (either local to the leaf or some other leaf), it will determine the destination's EPG. Depending on the EPG, it would determine if a contract is required to allow the frame to forward.. If yes, it would look into the L3 and L4 contents of the packet to determine if the contract exists. If it does, allow the traffic, if not drop. If the frame has the destination MAC address of that of the leaf, it will be routed. This will be the standard destination IP based routing. If a route exists for the destination in the VRF of the source, it is routed. If not, it will be dropped. With r

Cisco ACI - VLAN Types

Unlike the traditional Cisco switching world, where there existed only 3 VLAN types (standard, extended, private), Cisco ACI is definitely supposed to have several of them, to ensure that multitudes of Network Professionals get their brains wired! Luckily, I came across the following ones which seem to make sense about their respective roles to have the traffic forwarding in place: VLAN ID ( VlanID ) - Platform independent VLAN that is locally significant to each switch. This VLAN is automatically bound to the port-group VLAN existing on the DVS. It is derived from the VLAN pool that is configured in the Fabric Access Policies. Hardware VLAN ID ( HW_VlanId ) - In order to switch traffic locally, most leaf switches comprise of Broadcom ASIC. This VLAN type is utilized by the Broadcom ASIC chip. Connect to Broadcom ASIC on the leaf : vsh_lc To generate the list of endpoints connected : show system internal eltmc info vlan brief The various VLAN types are: BD_CTRL_VLAN - Infrastructure

Cisco Nexus - Switch Fabric Module

What is a switch fabric module? Fabric module connects the supervisor engine and line cards of the switch Fabric Module Types Fabric Module - 1 - Generation 1 (provides 46 Gbps of backplane capacity) Fabric Module - 2 - Generation 2 (provides 110 Gbps of backplane capacity) Fabric Module - 3 - Generation 3 (provides 2.8 Tbps of backplane capacity) What do the above numbers indicate? The original M1 series I/O modules eg. N7K-M132XP-12 have 80 Gbps of capacity per slot. So, two Generation 1 fabric modules would be required (2*46Gbps = 92 Gbps) for providing sufficient fabric capacity for the M1 series 10GE line card. Ordinarily, Cisco would recommend using 3 fabric modules in this case, for redundancy purposes, since one fabric module going down would translate to reduced capacity / backplane in the production environment. This implies, the overall fabric module capacity should exceed the line card capacity. Hardware specific details Nexus 7004 has no fabric modules Nexus 7000 series su

Cisco ACI Node states

During the fabric registration process, an ACI node usually transitions across different states. These states are usually recorded in the Fabric Node Vector (FNV) table, which can be checked using the below command on the APIC acidiag fnvread States and descriptions: Unknown – Node has been discovered but no Node ID policy has been configured Undiscovered – Node ID has been configured but the node is yet to be discovered Discovering – Node has been discovered but VTEP IP has not yet been assigned Unsupported – Node is not a supported model Disabled – Node has been decommissioned Inactive – There is no IP connectivity Active – Node is active

How to create a subnet in AWS

If you haven't created the VPC in which you are going to create a new subnet, then check the article here . A subnet is simply the subset of the IPv4 CIDR block which you defined while creating a VPC. It provides a demarcation for the broadcast domains. Requirements: An AWS account Virtual Private Cloud (VPC) - A subnet always resides in a VPC and hence a VPC should be present prior to creating it The subnet must be the wholly contained within the IPv4 CIDR block that you defined in the VPC Steps: Sign in to your AWS account. Under Services >> Networking >> VPC VPC Dashboard >> Your VPCs >> Click on your VPC Select Subnets >> Click on "Create Subnet" Details: Name tag: Name of the subnet (self evident) VPC: Select the VPC that you want this subnet to be the part of VPC CIDRs would be automatically populated (since it was defined at the time of VPC creation) Availability Zone: You get an option to select the AZ (in the same region as that of t

AWS Elastic IP address Billing

An Elastic IP address doesn’t incur charges as long as the following conditions are true: The Elastic IP address is associated with an EC2 instance. The instance associated with the Elastic IP address is running. The instance has only one Elastic IP address attached to it. AWS does provide you an option to import your own IP pool (if you already bought it) for which you would never incur any additional expense. Amazon would penalize you for breaching the above conditions on an hourly basis. So, best utilize your elastic IPs efficiently. Release them if you no longer need them.