Centralized log management - Syslog-ng, Phpsyslog-ng and MySQL back-end

Should I split this blogtorial in different parts and spoon feed it or are my readers man (or woman) enough to just take this blog as a whole and tear it apart? I decided my readers are hungry enough to handle the beast that centralized Syslog management really is. If you follow this blogtorial step by step you will have a fully functioning centralized Syslog management with a database back-end to store the logs, PHP web GUI front-end to view the logs and a solid Syslog server collecting all of the data.

Here is what we will cover in this blogtorial: 

• Installing and configuring MySQL - This will house the database and the necessary tables to organize the logs.  
• Installing httpd/apache and PHP libraries - This will be the webserver to house the Syslog-ng web GUI front-end (phpsyslog-ng)
• Installing phpsyslog-ng - This will be the web based GUI to view the logs.
• Installing syslog-ng - This will be the app collecting the logs and sending it to MySQL. 

Grab some chips, salsa and your favorite beer or a glass of wine because it is going to be a long one but in the end you should have a robust centralized log management system.

Configuring ASA NAT - Dynamic NAT - Object Network NAT

In this blogtorial we will see how we can take an inside LAN subnet and dynamically NAT using a POOL of addresses. Make sure the pool of addresses being used is reachable from the destination.

Here is the topology and the entire config can be downloaded here.

Objective:

Inside LAN (10.1.1.0/24) subnet should be dynamically translated to one of the IP addresses from the POOL (204.11.72.0/24). 

Configuring ASA Active/Standby failvover - ASA High Availability

When will this fail? How can we increase resiliency? How can we achieve close to 100% up-time? Questions one should be asking when designing any system. One way to answer these critical design questions -- redundancy!!. So in this blogtorial we will see how we can deploy two ASAs in a redundant design. When it comes to ASA high availability there are two modes: Active/Active where both ASAs are forwarding traffic and the other is Active/Standby where only the primary ASA is responsible for forwarding traffic and the other is in a hot-standby state waiting to forward traffic soon as the primary one fails. Each mode has its own set of pros and cons. Please review the Cisco website for a full list of Guidelines and Limitations.

Full configurations are located here so you can lab this up in GNS3.

With this in mind, let's get started on this topology.

TCP - TCP small window size causing latency

If you need a primer on window size and scaling you can check out my previous blogtorial that I posted a while ago. Today a client called and complained about latency. The basic premise was that they sent a New Order Single (FIX) and they didn't see the execution report for about 11 seconds. Application logs however showed that it was executed within sub microseconds and so why this 11 second delay? Obviously network equipment is not going to buffer the packets for multiple seconds. In order to troubleshoot this I turn to man's best friend (not dogs) -- but rather sniffers / packet captures ... perhaps I should have said nerd's best friend. :-) Once I started looking at the packet captures it all came together. I won't post the packet capture however a screen shot cant hurt.

Configuring ASDM for ASA on GNS3

ASDM is a GUI tool that you can use to configure ASAs. Although I prefer to use CLI, ASDM does come in handy from time to time. In this blogtorial we will see how to configure ASDM so that we can use it to configure ASAs running on GNS3. If you need a primer on how to get ASAs working on GNS3 then see my previous blogtorial.

Overview: 

• Download ASDM image
• Create a Loopback interface
• Connect it to the ASA
• Assign IP addresses
• Download TFTP server
• Copy ASDM image to the ASA
• Install ASA on the computer
• Connect to the ASA using ASDM 

GNS3 - Configuring ASA on GNS3

I generally use GNS3 to emulate routers but recently I have been using it to do some ASA labs. So here is how I emulate ASAs on GNS3.

First thing to take care of is acquiring the ASA images needed to emulate an ASA. Files needed can be downloaded here.

Once you've downloaded the files it is time to configure GNS3 to run the ASA. Follow the screenshots.

Dot1Q Tunnel / q-in-q Tunneling

Dot1Q tunnel or q-in-q tunneling is a technique generally used by service providers to extend customer's VLANs to different locations. It is done by encapsulating the customer VLAN inside another 802.1q encapsulation and because of this we must increase the system mtu on the service provider switches to something greater than 1500. In this blogtorial, we will take a look at a very simple topology with easy to follow configurations.

Here is the topology. 

Our objective: 

VLAN 10 in a Customer Site in California (SW1) needs to be extended to a Customer Site in Illinois (SW4).

BGP - Unicast NLRI to Multicast NLRI - translate-update cisco

I have been extremely busy with work, school and CCIE studies so I have not been able to post as much as I want to. There are numerous drafts ready to be posted so hopefully I'll have sometime to share it on here. Alright, enough with the excuses and let's get started. In this blogtorial we will see how we can take a unicast route received from a unicast BGP neighbor and install it in the multicast routing table and advertise it to MBGP peers using translate-update feature. Usually this is done for in-congruent BGP topology where a MBGP capable router peers with router that is incapable of MBGP.

Here is the topology.

The entire configs can be downloaded here so you can lab it up in GNS3.

BGP - Troubleshooting Lab 2

Objective

• R3 and R4 must have 5.5.5.5/32 and 6.6.6.6/32 in their BGP/routing table. 

Sounds simple..? Well how about you figure it out then :) .. Here is the topology. 

Restrictions

• Static routes should not be added anywhere!! In other words, get BGP to work properly. 

You should be able to figure out the issues with the following show commands below.  

BGP - Troubleshooting Lab

In this blogtorial, I will be posting configs of the routers and a few commands. Please leave me comments on what you think the issue maybe.

Consider this topology below. 

Objective: 

• 11.11.11.11/32 should be pingable from R4. 
• Static routes or artificial routes cannot be installed anywhere!! 

Hint -- There are three issues.

The entire config can be downloaded here so you can lab it up in GNS3.

BGP - inject-map - Conditional Route Injection

In my recently published posts we discussed how to aggregate addresses in BGP and the various optional parameters associated with the "aggregate-address" command. However, there could be instances where we may want to do just the opposite -- un-aggregate the addresses. In this blogtorial we will see how we can achieve this. Consider a very simple topology below and we'll dive right in.

BGP - aggregate-address suppress-map

In my previous blogtorial we utilized the aggregate-address command to summarize routes in BGP. In this blogtorial we will take a look at one of the optional parameters we can use with the aggregate-address command to manipulate routes. As you noticed the "aggregate-address <network> <netmask>" command actually advertised the aggregate route and the more specific routes.

 R2(config-router)#aggregate-address 11.11.11.0 255.255.255.0 ?  
  advertise-map Set condition to advertise attribute  
  as-set     Generate AS set path information  

  attribute-map Set attributes of aggregate  
  nlri      Nlri aggregate applies to  
  route-map   Set parameters of aggregate  
  summary-only  Filter more specific routes from updates  
  suppress-map  Conditionally filter more specific routes from updates  
  <cr>  

You could presumably use summary-only to filter all the more specific routes, however what if you wanted to suppress only a selected few of the more specific routes and advertise the rest of the specific routes along with the aggregate? This is where "suppress-map" or "advertise-map" comes to the rescue  If you only had a few specific routes to advertise but a lot of specific routes to suppress out of an aggregate then you would use the "advertise-map" to advertise just what you want. However, if you only had a few specific routes to suppress but more specific prefixes to advertise then you would use a "suppress-map" to suppress what you want and advertise the rest. See below for "suppress-map" in action.

BGP - aggregate-address as-set

In my previous blogtorial we utilized the aggregate-address command to summarize routes in BGP. In this blogtorial we will take a look at one of the optional parameters we can use with the aggregate-address command to manipulate routes.

 R2(config-router)#aggregate-address 11.11.11.0 255.255.255.0 ?  
  advertise-map Set condition to advertise attribute  
  as-set     Generate AS set path information  
  attribute-map Set attributes of aggregate  
  nlri      Nlri aggregate applies to  
  route-map   Set parameters of aggregate  
  summary-only  Filter more specific routes from updates  
  suppress-map  Conditionally filter more specific routes from updates  
  <cr>  

The optional parameter we will look at in this blogtorial is the as-set option. In my previous post we talked about "atomic-aggregate" and how the aggregate routes clears the AS_PATH information along with other attributes of the route such as no-export community. For example, let's take a look at the R3.

BGP - aggregate-address summary-only

In my previous blogtorial we utilized the aggregate-address command to summarize routes in BGP. In this blogtorial we will take a look at one of the optional parameters we can use with the aggregate-address command to manipulate routes.

 R2(config-router)#aggregate-address 11.11.11.0 255.255.255.0 ?  
  advertise-map Set condition to advertise attribute  
  as-set     Generate AS set path information  
  attribute-map Set attributes of aggregate  
  nlri      Nlri aggregate applies to  
  route-map   Set parameters of aggregate  
  summary-only  Filter more specific routes from updates  
  suppress-map  Conditionally filter more specific routes from updates  
  <cr>  




The optional parameter we will look at in this blogtorial is the summary-only option. In my previous post we saw that the aggregate-address command advertised the aggregate route along with the more specific prefixes. What if we wanted to suppress those more specific prefixes and advertise only the summary? summary-only command suppresses all of the more specific prefixes and advertises only the aggregate route to the neighbors.