8 Useful Log::Log4perl Recipes

perl-icon_aThis article contains eight (8) of my most frequently used Log::Log4perl recipes. The Log::Log4perl is a Perl logging API port of the Log4J Java logging API. It's very comprehensive and is used in a large number of the scripts, tools, and applications that have been developed by Netlinx, Inc. In this article, we provide recipes for the following:

  1. Initializing Log4perl with a config file vs in-line
  2. Output messages to file and screen using appenders
  3. Log events and messages to a database
  4. Logging messages to Syslog
  5. Have different applications log to the same file
  6. Outputting stacktrace in logging messages
  7. Implementing rotating log files
  8. Applying log filtering

Anycast DNS - Part 5, Using BGP

In this fifth article on Anycast DNS, we provide some examples of deploying Anycast using Border Gateway Protocol or BGP, the core routing protocol of the Internet. While BGP is mostly used by Internet Service Providers (ISPs), it is also used in some of the larger enterprise environments that must interconnect networks that span geographical and/or administrative regions and boundaries. Since BGP is a very complex routing protocol, we will provide only a basic recipe using Cisco and Quagga host-based routing software. A detailed discussion of the BGP protocol is beyond the scope of this article.

BGP is an Exterior Gateway Protocol (EGP), which means that it exchanges routing information between Autonomous Systems (AS). BGP is quite different from other IGPs, such as RIP and OSPF. BGP uses a different routing algorithm that uses a path vector algorithm, causing it to keep a list of every AS that the path passes through.

Our recipe will demonstrate how to configure Quagga to peer with a Cisco router using BGP. Suppose our Anycast design consists of an Autonomous System 65500 and AS 64555 as shown below. AS 64555 will contain our Anycast DNS servers and we'll establish peering between the two as shown below:

 

anycast-dns-bgp-1

Anycast DNS - Part 4, Using OSPF (Advanced)

In this continuation of the fourth article, we improve the design with enhanced security, performance, and efficiency. Our configuration consists of two OSPF areas 51 and 52, containing an Anycast DNS server, and pair of Cisco Routers connected to the backbone area 0.0.0.0. The Anycast DNS servers are configured with Quagga, running the OSPF routing protocol engine, this is used to advertise our two (2) Anycast DNS VIPs, 192.168.0.1/32 and 192.168.1.1/32 into the OSPF routed network. The diagram below focuses on our "fictitious" area 51:

anycast-dns-ospf-3

As mentioned, we'll provide additional "recipes" for improving our Anycast DNS design to achieve faster convergence and failover, added security, and better efficiency.

Anycast DNS - Part 4, Using OSPF (basic)

The fourth article in our Anycast DNS series covers Anycast DNS using Open Shortest Path First or OSPF routing protocol. OSPF is a dynamic routing protocol used to build larger scale IP networks. It differs from RIP, because it is a link-state routing protocol and falls into the group of Interior Gateway Protocols that operate within a single Autonomous System or AS.

OSPF is a link-state routing protocol that runs Dijkstra's algorithm to calculate the shortest path to other networks. Taking the bandwidth of the network links into account, it uses cost as its metric. OSPF works by developing adjacencies with its neighbors, periodically sending hello packets to neighbors, flooding changes to neighbors when a link's status changes, updating its neighbors of all recent link state changes every 30 minutes. The use of this algorithm makes OSPF much faster at network convergence, which is why it makes a better selection for building Anycast DNS solutions for enterprise environments.

Our OSPF network will consist of a two different OSPF areas 0.0.0.51 and 0.0.0.52 that are connected to a thrid area, backbone area 0.0.0.0. This is shown in the figure below:

anycast-dns-ospf-2

Each router, will have one interface directly connected to backbone area 0.0.0.0. Their other interface(s) will connect into their own respective OSPF routing areas. We do not dive into the details of OSPF networking because it is beyond the scope of this article. Our goal is to provide a working recipe for using OSPF, Cisco routers, and Quagga Open Source host-based routing software.

Anycast DNS - Part 3, Using RIP (cont)

This article is a continuation of our third article in our series on Anycast DNS. In this next recipe, two Anycast VIPs will be advertised on two (2) DNS servers that are multi-homed on different subnets by different routers using RIP v2. In this recipe, we'll review the commands that will be needed to add the additional interfaces to our Quagga configuration, as well as, briefly discuss how to handle multiple default gateways on multi-homed hosts. The figure below depicts our configuration for this recipe:

anycast-dns-rip-2

Anycast DNS - Part 3, Using RIP

This third article in our series on Anycast DNS, focuses on deploying Anycast DNS using RIP v2 routing protocol. In this article we'll be using Quagga, Open Source host-based routing software, to originate our Anycast IP address. Our upstream routers are Cisco routers, so we'll also be providing all routing configurations that are needed for the recipes. The goal of the recipe is to be efficient, secure, and simple.

In this recipe we configure a single Anycast VIP on two name servers, using host-based routing software to originate the routes Anycast VIPs to their upstream routers via the RIP v2 routing protocol. The following figure shows our configuration for this exercise:

anycast-dns-rip-1

Two Linux-based DNS servers running Quagga's ripd routing protocol, are configured with an Anycast VIP of 192.168.0.1/32. But first, a quick refresher on RIP v2 is in order.