Tejas Jain

Cisco ACI - Port Tracking One of the techniques to speed up convergence in case of internal fabric connectivity failures, "port-tracking" feature addresses an outage where a leaf node loses connectivity to "all" the spine nodes in the Cisco ACI fabric. In such a scenario, the hosts that are connected to such a leaf in active-standby setup are usually not aware of such an outage and continue to send traffic to the now isolated leaf. This is where the port-tracking feature brings down all the host facing ports of the isolated leaf node. For the servers that are dual homed to different leafs, this action would ensure that the uplink to the isolated leaf is not considered for forwarding the traffic. The changes can be made as below: System >> System Settings >> Port Tracking

Cisco ACI has the concept of Anycast Gateway where the default gateway of the subnet (configured with the Bridge domain) exists on the Leaf devices. Now, more importantly, the anycast gateway / SVI (Switched Virtual Interface) is configured (rather programmed) on only those Leaf switches which have endpoints belonging to that bridge domain. How does Cisco ACI determine whether it should configure an SVI on a particular Leaf? It does this via CDP, LLDP or OpFlex (if the endpoints support it). This would imply, that CDP / LLDP is not just there for operational purposes, but rather, it actually holds a powerful influence on the actual traffic forwarding, unlike traditional switches. CDP uses the usual Cisco CDP timers with an interval of 60s and a holdtime of 120s. LLDP uses the usual LLDP timers with an interval of 30s and a holdtime of 120s. CDP support for Fabric Extenders has started from ACI 2.2 release. For older releases, LLDP should do the trick.

For network guys coming from the traditional switching world, the interface configuration on Cisco ACI is not as simple as putting "switchport xxx" command under interface x/x. Rather there is a huge list of interface policies which needs to be configured, which is then referenced in the Interface policy group and then stitched with the actual interface (Interface selector). The list of interface policies are as follows: LLDP - Link Layer Discovery Protocol CDP - Cisco Discovery Protocol LACP - Link Aggregation Control Protocol Port Speed Storm Control MCP - Mis-Cabling Protocol Now each policy type is already configured with the default configuration. The best practice is to not touch this default configuration but create an explicit policy. For example, I always have an LLDP_ON, LLDP_OFF, CDP_ON, CDP_OFF and so on, configured explicitly for my setup. Explicit policies for each of these policy types also enables you to configure other parameters such as the CDP, LLDP i

Traditional catalyst switches like Cisco Catalyst 3750 / 3560, by default do not have IPv6 routing enabled, and simply entering the " ipv6 unicast-routing " won't work! First, enable dual-stack routing by: sdm prefer dual-ipv4-and-ipv6 This should be followed by a reboot, post which enable IPv6 routing by: ipv6 unicast-routing Post which you should be able to do all the IPv6 configuration..

A VPC has been created with an address scope, subnets have been created within that scope and EC2 instances have been created in the VPC. Now, you wish to provide your EC2 instances with Internet access. This can be done either by selection "Allocate a public IP" during the instance creation or allocating an Elastic IP to your account and associating the elastic IP to your instance. All this is possible only if you have an Internet Gateway associated with the VPC and the route table having the internet routes (or default route) pointing towards Internet Gateway. Let's create Internet Gateway. Go to Services >> VPC >> On the left pane, under Virtual Private Cloud, click Internet Gateways. Internet Gateway Click on "Create internet gateway", enter the Name tag and "Create" Internet Gateway Now associate the Internet Gateway with a VPC, by clicking on the internet gateway (just created), and Actions: Attach to VPC Attach to VPC In my case s

So you have created a VPC and your EC2 instance is ready.. (here I am assuming we haven't configured public IP, while creating EC2 instance). Let us now allocate an Elastic IP address to our AWS account from the Amazon's reserved public IP range. This can be done by Services >> EC2 >> Scroll down the left navigation pane and under Network & Security, click on Elastic IPs . Click on the Allocate Elastic IP address button AWS Elastic IP Once this IP address is allocated, select the Elastic IP, click on Actions and click on "Associate Elastic IP address", as below: Associate Elastic IP with an instance This would bring up the below page which gives an option to select the EC2 instance which this Elastic IP needs to be allocated to. [I have erased my Elastic IP address and the Instance ID] Associate Elastic IP with an instance And that should be it. There is a catch here, however! The above process won't work if there is no Internet Gateway associa

Depending upon your platform find the setup file below: https://www.elastic.co/downloads/beats/auditbeat Unzip the file, rename it to Auditbeat and copy the unzipped folder to C:\Program Files as below: Auditbeat 2. Open Powershell with Administrator privileges, and type the following: In case of code execution restriction, please check my post here . Once the installation is successful, modify the C:\Program Files\Auditbeat\auditbeat.yml file to establish the connection with Elastic Cloud tenant we created above. Scroll down and un-comment: "cloud-id" to enter the following: cloud.id: " Deployment:Cloud ID " cloud.auth: "username:<password>" I have masked the Cloud ID and password details for my deployment (Deployment-1) Enter the following commands in Powershell to load Kibana dashboards. The setup is ready.. Check on Kibana if the Windows Audit logs are getting populated in Kibana. The logs can be found by clicking on the compass icon in