GNS3 - VitualBox Part 6: Stub, Totally Stubby and Not-So-Stubby OSPF Areas

An explanation of the various types of OSPF Stub Areas and demonstrations of how to configure Stub, Totally Stubby and Totally NSSA Areas.

 

Introduction

OSPF Stub Areas restrict the number and types of routing table updates -- Link State Advertisements -- they accept, limiting the amount of overall network topology detail they must maintain in their routing tables and link state databases.  A common (but by no means mandatory) implementation of Stub Areas is an OSPF Area that has only one ABR for all traffic between the Area and the rest of the Autonomous System.

OSPF Link State Advertisement Types

OSPF routers maintain a routing table and link state database by communicating topology information using Link State Advertisements (LSAs).  There are different types of LSAs; this article examines the six relevant to Stub Areas.

Type 1 - Router LSA

Type 1 - Router LSA - the router announces its presence and lists the links and metrics to other routers or networks in (and only within) its own area.  The link-state ID of the Type 1 LSA is the originating router ID.

Type 2 - Network LSA

Type 2 - Network LSA - the Area's designated router (DR) on a broadcast segment (e.g. Ethernet) lists the router IDs in broadcast domain. Type 2 LSAs are flooded across their own area only. The link-state ID of the Type 2 LSA is the IP interface address of the DR.

Type 3 - Summary LSA

Type 3 - Summary LSA - an Area Border Router (ABR) summarizes information about an Area and sends it to other attached Areas.  Summarization provides scalability by aggregating contiguous networks information into a single address/mask entry.  For instance, all of the individual networks in the 172.16.0.0 - 172.16.31.255 range may be summarized as 172.16.0.0 / 255.240.0.0 The link-state ID is the destination network number for Type 3 LSAs.

Type 4 - ASBR-Summary LSA

Type 4 - ASBR-Summary LSA - support Type 5 - External LSAs (see below).  Type 5 External LSAs list routes imported from external systems and are flooded to all areas in the OSPF Domain.  However, accurate next-hop information may not be available for other areas in the OSPF Domain with the Type 4 ASBR-Summary LSA which includes information specific to the ASBR advertising the routes.  The link-state ID is the router ID of the described ASBR for Type 4 LSAs.

Type 5 - External LSA

Type 5 - External LSA - provide routes imported into OSPF from other routing protocols. They are flooded to all areas unchanged (except stub and NSSA areas).  The link-state ID of the Type 5 LSA is the external network number.

Type 7 - NSSA External LSAs

Type 7 - NSSA External LSAs are specific to Not-So-Stubby-Areas (NSSA), which -- like Stub and Totally Stubby Areas -- do not receive external routes from ABRs.  Unlike Stub Areas, NSSA Areas may have links to external routing protocols. NSSA Areas use Type 7 LSAs to tell their ABRs about these external routes, which the Area Border Router then translates to type 5 external LSAs and floods as normal to the rest of the OSPF network.

OSPF Stub Area Types

The illustration above depicts the important differences between the four types of Stub Areas, the types of LSAs they use and relations to external routing protocols.  The most important concepts of stubby areas is understanding how they treat Type 3 Summary and Type 5 External LSAs.  In the NSSA area types, Type 7 NSSA External LSAs operate only within the NSSA Area, but are translated at border routers into Type 5 External LSAs.

Stub Areas

Stub Areas receive route summaries from the ABR via Type 3 Summary LSAs, providing information about networks in other Areas in the Autonomous System.  They also receive a default route.  They do not receive Type 5 External LSAs that provide information about routes external to the OSPF Autonomous System.

Totally Stubby Areas

Totally Stubby Areas receive neither Type 5 External LSAs nor Type 3 Summary LSAs from the ABR and lack both routes external to the OSPF Autonomous System and summary information about the networks in other Areas in the Autonomous System.  They are only aware of routes within their own Area and reach others through a default route, typically handled by the ABR.

Not-So-Stubby Areas

Not-So-Stubby Areas (NSSAs) differ from Stub and Totally Stubby Areas by including external routes (in the illustration above injected from EIGRP by and ASBR in the NSSA).  They are stubby with respect to the OSPF Autonomous System n that they do not receive Type 5 External LSAs but do receive Type 3 Summary LSAs from the ABR.  They differ significantly from Stub and Totally Stubby Areas in that they use Type 7 LSAs to advertise their external routes to the ABR, which then floods them to the OSPF Autonomous System as Type 5 External LSAs.  NSSAs differ from the other three types of Stub Areas in that they do not automatically assign default routes; these must be manually configured on the ABR.

Totally Not-So-Stubby Areas

Totally Not-So-Stubby Areas (Totally NSSAs) operate much like NSSAs with two important differences:  they receive neither Type 3 Summary nor Type 5 External LSAs (and thus do not have external routes) and do automatically assign default routes.

Configuring Stub and Totally Stub Areas

The illustrations at the beginning of this article depicts a network with several potential Stub Areas.  One, however, is not:  10.64.0.0.  This OSPF Area is a Transit Area providing a virtual link (see Part 5 of this series) to Backbone Area 0.0.0.0 for Area 10.72.0.0.  Area 10.72.0.0 is a WAN Border Router (10.64.0.0-10.72.0.0) serving Cisco 2691 Branch Office routers.  This is a good candidate for limiting the detail of routing information it maintains (the Link State Databases) by configuring it as a Stub or Totally Stubby Area.

Each router in the area must be configured with the following OSPF statement to create a Stub Area:

area 10.72.0.0 stub

This statement blocks Type 5 - External LSAs from Area 10.72.0.0.  However, notice the topology: there are no external routing protocols injecting routes into the OSPF Autonomous System.  Specifically, the ASBRs are simply Debian Linux Gateways with an external static route to the wireless router.  This will be apparent when comparing the Links State Databases on routers in Area 10.72.0.0 before and after -- there is no change.

Reducing the size of the Link State Databases in Area 10.72.0.0 in this system requires configuring it as a Totally Stubby Area.  Each router in the area must be configured with the following OSPF statement to create a Totally Stubby Area:

area 10.72.0.0 stub no-summary

This statement also blocks Type 3 - Summary LSAs from Area 10.72.0.0.  Now the change in this system is noticeable -- summary routes to other OSPF Areas are no longer listed in the Link State Databases, which now contain only routes within Area 10.72.0.0 and a default route.

The video below illustrates configuring area 10.72.0.0 as a Stub and then Totally Stubby Area.

Configuring Totally NSSA Areas

NSSA and Totally NSSA Areas are a difficult topic.  A simplified topology is warranted for clarity.  The illustration aboce is the topology that will be used in this section.

NSSA and Totally NSSA Areas are stubby with respect to OSPF, but connected to external routes and routing protocols.  Since Stub and Totally Stubby Areas do not accept Type 5 External LSAs, such an area would no longer inject external routes into OSPF.  NSSA and Totally NSSA Areas handle exteral routes using Type 7 NSSA External LSAs.  These LSAs inject external routes from the NSSA ASBR into the NSSA Area; the NSSA ABR then translates the Type 7 NSSA External LSAs into Type 5 External LSAs and floods the OSPF AS with the external routes.

Redistributing OSPF and External Routes

The first step in configuring a NSSA or Totally NSSA Area is to assure the external routing protocol and OSPF are exchanging information correctly.  The ASBR in this example (COU_ASBR) is already running OSPF and RIP.  It is the only router in the topology that is aware of all routes because it is not configured to redistribute.  The following commands enable redistribution of OSPF routes into RIP and RIP routes into OSPF:

router ospf 1
redistribute rip subnets

router rip
redistribute ospf 1 metric 1

Once configured, the router redistributes the routes.  Checking OSPF routers, RIP routes 192.168.x.x are now present.  Checking RIP routers, the OSPF route 10.0.0.0/8 is now present.

Creating the Totally NSSA Area 10.0.0.0

On all routers in the 10.0.0.0 Area (COU_ABR, COU_ASBR and COU_IR), issue the command:

area 10.0.0.0 nssa no-summary

This command drops Type 3 Summary and Type 5 External LSAs while creating Type 7 NSSA LSAs for the connected RIP External System.  IRs now have no OSPF Summary or External routes, but do have Intra Area and RIP External routes.  The ABR and ASBR manage redistribution of RIP External routes into OSPF and OSPF routes into RIP.

Creating the Stub Area 10.64.0.0 and Totally Stubby Area 10.128.0.0

The two normal Areas 10.64.0.0 and 10.128.0.0 maintain OSPF Summary Routes (10.x.x.x) and RIP External Routes (192.168.x.x).  Converting them to Stub and Totally Stubby Areas further summarizes routing information.

Convert Area 10.64.0.0 into a Stub Area by issuing, on all area routers, the command:

area 10.64.0.0 stub

Once converted, the Stub Area no longer accepts Type 5 External LSAs (originating at the COU_ABR router) and rely upon the default gateway (PHL_ABR) to maintain external routes.  Although the external routes are no longer maintained by IRs, you may still ping addresses in the RIP External System (192.168.x.x) and get responses.

The Stub Area still maintains Intra Area routes and summary routes (10.x.x.x) for OSPF AS Areas.


Convert Area 10.128.0.0 into a Totally Stubby Area by issuing, on all area routers, the command:

area 10.128.0.0 stub no-summary

Once converted, the Totally Stubby Area no longer accepts Type 3 Summary and Type 5 External LSAs (originating at the COU_ABR router) and rely upon the default gateway (PHL_ABR) to all but Intra Areal routes.  Although the routes are no longer maintained by IRs, you may still ping addresses in the OSPF AS (10.x.x.x) and RIP External System (192.168.x.x) and get responses.

The video below illustrates configuring Area 10.0.0.0 as Totally NSSA, Area 10.64.0.0 as Stub and 10.128.0.0 as Totally Stubby.

GNS3 - VitualBox Part 5: Creating OSPF Virtual Links

Adding a Cisco 3745 WAN router connected to five Cisco 2691 branch office routers by point-to-point T-1.  This article starts using the topology configured in Part 4 of the series.

Introduction

The illustration above depicts what will be configured:  a Cisco 3745 router equipped with a Fast Ethernet adapter and six T-1 adapters connected by point-to-point T-1 to five Cisco 2691 routers equipped with a Fast Ethernet adapter and one T-1 adapter.  The Cisco 3745 router is located in the Philadelphia Data Center and its Fast Ethernet adapter is in OSPF Area 10.64.0.0; its T-1 adapters are in the new OSPF Area 10.72.0.0.  The five Cisco 2691 routers' T-1 and Fast Ethernet interfaces are all in OSPF Area 10.72.0.0.

The 10.72.0.0 - 10.72.255.255 address range is reserved for T-1 point-to-point links (e.g. networks 10.72.0.0/255.255.255.252, 10.72.0.4/255.255.255.252, 10.72.0.8/255.255.255.252, etc.).  Each branch office router's Fast Ethernet interface services an address range (e.g. 10.73.0.0/255.255.0.0, 10.74.0.0/255.255.0.0, 10.75.0.0/255.255.0.0, etc.).

Role of the OSPF Backbone Area

The OSPF Backbone Area 0.0.0.0 is the logical core of and OSPF Domain; all other area must be connected to it.  The Backbone Area is responsible for distributing routing information between non-Backbone Areas (i.e. Areas with non-zero numbers).  The Backbone Area must also be logically contiguous; it may be physically discontiguous if connected by virtual links.

Backbone Routers

Backbone Routers (BRs) have at least one interface connected to OSPF Area 0.0.0.0.  In the design above, the four Debian Linux Gateway Routers and four Cisco 7206 Routers have interfaces in Area 0.0.0.0 and are Backbone Routers.

Area Border Routers

Area Border Routers (ABRs) have interfaces in more than one OSPF Area.  In the design above, the four Debian Linux Gateway Routers and four Cisco 7206 Routers, and the new Cisco 3745 WAN Router are ABRs

Internal Routers

Internal Routers (IRs) have interfaces connected to the same OSPF Area.  In the design above, the Debian Linux Layer 3 Switches, Philadelphia Data Center Cisco 3745 and five new Cisco 2691 Branch Office Routers are IRs.

Autonomous System Border Routers

Autonomous System Border Routers (ASBRs) have at least one interface connected to systems outside of the OSPF Domain.  These typically run an exterior routing protocol (such as Border Gateway Protocol, BGP) or have static routes.  In the design above, the four Debian Linux Gateway Routers (with DHCP addresses and a static default route assigned by the Wireless Router) are ASBRs.

Physical and Logical OSPF Area Topology

The OSPF Backbone Area 0.0.0.0 is physically and logically contiguous; all routers with interfaces in the Backbone Area 0.0.0.0 have at least one physical connection to another router in Backbone Area 0.0.0.0.

Area 10.64.0.0 (range 10.64.0.0/255.248.0.0) is connected to OSPF Backbone Area 0.0.0.0 by the Backbone BR/ABR PHL_7206.  Thus, Area 10.64.0.0 receives updates about all other non-Backbone Areas directly connected to the Backbone (i.e. 10.0.0.0, 10.128.0.0 and 10.192.0.0).  Consider the example of an Area 10.64.0.0 IR such as the Philadelphia Data Center 3745.  This router receives route summaries that define networks and gateways for the listed networks:

10.0.0.0/13 via 10.64.0.1 FastEthernet0/0
10.128.0.0/13 via 10.64.0.1 FastEthernet0/0 
10.192.0.0/13 via 10.64.0.1 FastEthernet0/0

These routing table entries specify the summarized networks, default gateway (10.64.0.1 on PHL_7206) and local interface to use (FastEthernet0/0).

Area 10.72.0.0 is not contiguous with the OSPF Backbone Area 0.0.0.0.  It consists of an ABR -- PHL_WAN_3745 -- connected to Areas 10.64.0.0 and 10.72.0.0 and five IRs -- the Cisco 2691 Branch Office routers -- connected only to Area 10.72.0.0.  ABR PHL_WAN_3745, by virtue of membership in Area 10.64.0.0, will receive updates from the Backbone Area from PHL_7206.  The five Cisco 2691 Branch Office routers will not and are only aware of Area 10.72.0.0 routes; they also lack default gateway definitions and can not route outside of Area 10.72.0.0.

OSPF Virtual Links

An OSPF Virtual Link is a logical link to OSPF Backbone Area 0.0.0.0.  The discontiguous Area (in this case 10.72.0.0) must use a Transit Area (in this case 10.64.0.0) to establish a connection with the OSPF Backbone Area.  A Virtual Link must provide a connection between a BR (PHL_7206) and the discontiguous Area's ABR (PHL_WAN_3745).  The Transit Area (in this case 10.64.0.0) may not be in any way stubby because it must pass all OSPF LSA types.  Stub Areas will be the subject of Part 6 in the series.

The process is quite simple.  The format of the Router OSPF command is:

area <transit area number a.b.c.d> virtual-link <destination a.b.c.d IP address>

On the Backbone Router PHL_7206:

area 10.64.0.0 virtual-link 10.64.0.3

On the Area Border Router PHL_WAN_3745:

area 10.64.0.0 virtual-link 10.64.0.1

The status of the Virtual Link may be checked with the command:

show ip ospf virtual-links

on either the PHL_7206 or PHL_WAN_3745 routers.

The Cisco 2691 Branch Office routers will now receive updates from Backbone Area 0.0.0.0, including Inter Area route summaries (e.g. 10.0.0.0/13, 10.128.0.0/13 and 10.192.0.0/13).  They will also have default gateways assigned (the corresponding PHL_WAN_3745 serial T-1 interface).  One additional check is the command:

show ip ospf broder-routers

This command will return the Area 10.72.0.0 ABR (PHL_WAN_3745) and the OSPF Domain's ASBRs (the Debian Linux Gateway Routers).

The video below illustrates adding the six routers for Area 10.72.0.0, configuring OSPF routing and adding the Virtual Link between PHL_7206 and PHL_WAN_3745.

GNS3 - VitualBox Part 4: Building Data Center Areas Connected to the OSPF Backbone Area

Adding a Cisco 3745 and Debian Linux Layer 3 Switch to a non-Backbone OSPF Area to create a data center.  This article starts using the topology configured in Part 2 of the series.

Introduction

The illustration above depicts what will be configured: a Cisco 3745 (equipped with Fast Ethernet adapters) and a Deiban Linux Layer 3 Switch installed in the Philadelphia Data Center in OSPF Area 10.64.0.0.  OSPF Area 10.64.0.0 begins with a range of 10.64.0.0 / 255.255.0.0 (10.64.0.0 - 10.64.255.255) and will be expanded to 10.64.0.0 / 255.248.0.0 (10.64.0.0 - 10.71.255.255).

The Cisco 3745 will have one Fast Ethernet adapter connected to the existing Cisco 7206 router and the remaining will service networks with 255.255.255.0 (24-bit) subnet masks in the 10.64.x.0 range.  The Debian Linux Layer 3 Switch will have one Gigabit Ethernet interface connected to the existing Cisco 7206 router and the remaining will service networks with 255.255.255.0 (24-bit) subnet masks in the 10.65.x.0 range; additionally, it is preconfigured with seven subinterfaces for each physical Gigabit Ethernet adapter, creating a total of 24 networks in the 10.65.x.0 range.
Expanding the 10.64.0.0 OSPF Area
On the existing Philadelphia Cisco 7206 router, enter configuration mode for the OSPF process:

config t
router ospf 1

The existing area definition must be replaced:

no area 10.64.0.0 range 10.64.0.0 255.255.0.0

with:

area 10.64.0.0 range 10.64.0.0 255.248.0.0

Once reconfigured, save the running configuration.

Adding the Cisco 3745 Router

Use the GNS3 interface to add the Cisco 3745 router and four (although three are illustrated above) virtual Layer 2 switches.  It begins with a GT-96100-FE card in slot 0; add NM-1FE-TX cards to slots 1 through 4.  Connect Fast Ethernet adapter f0/0 to the existing GNS3 virtual Layer 2 switch connected to the existing PHL_7206 router.  Add four additional
GNS3 virtual Layer 2 switches and connect them to the Fast Ethernet adapters in slots 1 through 4.

The 3745 is ready to configure. Relevant configuration statements are below:

interface FastEthernet0/0
 ip address 10.64.0.2 255.255.255.0
 full-duplex
 
interface FastEthernet1/0
 ip address 10.64.1.1 255.255.255.0
 full-duplex
 
interface FastEthernet2/0
 ip address 10.64.2.1 255.255.255.0
 full-duplex

interface FastEthernet3/0
 ip address 10.64.3.1 255.255.255.0
 full-duplex
 
interface FastEthernet4/0
 ip address 10.64.4.1 255.255.255.0
 full-duplex
 
router ospf 1
 router-id 10.64.0.2
 area 10.64.0.0 range 10.64.0.0 255.248.0.0
 network 10.64.0.0 0.0.0.255 area 10.64.0.0
 network 10.64.1.0 0.0.0.255 area 10.64.0.0
 network 10.64.2.0 0.0.0.255 area 10.64.0.0
 network 10.64.3.0 0.0.0.255 area 10.64.0.0
 network 10.64.4.0 0.0.0.255 area 10.64.0.0

Adding the Debian Linux Layer 3 Switch

Use the GNS3 interface to add the preconfigured Debian Linux Layer 3 Switch and three GNS3 virtual Layer 2 switches. Connect interface eth0 to the existing GNS3 virtual Layer 2 switch connected to the existing PHL_7206 router.  Connect interfaces eth1 through eth3 to the three new GNS3 virtual Layer 2 switches.

This device is preconfigured with Quagga routing software and IP Forwarding enabled.  As mentioned above, it has subinterfaces configured for the data center side of the device (eth1, eth2 and eth3) for a total of 24 different networks.  A portion of the /etc/network/interfaces file is below:

iface eth1 inet static
address 10.65.1.1
netmask 255.255.255.0

iface eth2 inet static
    address 10.65.9.1
    netmask 255.255.255.0
    broadcast 10.65.2.255
    network 10.65.9.0

iface eth3 inet static
    address 10.65.17.1
    netmask 255.255.255.0
    broadcast 10.65.3.255
    network 10.65.17.0

iface eth1:2 inet static
    address 10.65.2.1
    netmask 255.255.255.0
    broadcast 10.65.2.255
    network 10.65.2.0

iface eth1:3 inet static
    address 10.65.3.1
    netmask 255.255.255.0
    broadcast 10.65.3.255
    network 10.65.3.0

The nomenclature of the subinterfaces reflects the subnet serviced.  For example, subinterface eth1:2 services network 10.65.2.0 / 255.255.255.0 and interface eth1:3 services network 10.65.3.0 / 255.255.255.0, etc.

The relevant part of the /etc/quagga/ospfd.conf file (configuring OSPF routing) is below:

router ospf
 ospf router-id 10.64.0.4
 network 10.64.0.0/24 area 10.64.0.0
 network 10.65.0.0/16 area 10.64.0.0
 area 10.64.0.0 range 10.64.0.0/13

Note the statement "network 10.65.0.0/16 area 10.64.0.0."  This statement adds every subnetwork (as defined in the /etc/network/interfaces file) included in the range 10.65.0.0 - 10.65.255.255 to area 10.64.0.0.  It is essentially a "short hand" reference to those networks, which appear individually in the routing tables.

Checking the Configuration

Upon starting and configuring the Cisco 3745 router and Debian Linux Layer 3 switch, check that they see each other and the PHL_7206 Cisco router as OSPF neighbors and their routing tables list all routes and a default gateway of 10.64.0.1 (the PHL_7206 router).

 

You may also check the Linux kernel routing tables to assure the operating system routes are correctly updated by the Quagga daemons.

The video below illustrates the entire process.

GNS3 - VitualBox Part 3: Adding Redundant Internet ASBR's to an OSPF Backbone Area

Adding three VirtualBox Debian Linux Gateways that provide multiple paths to the Internet. this article starts using the Backbone Topology configured in Part 2 of the series.

Introduction

The illustration above depicts what will be configured:  three Debian Linux Gateways (Philadelphia, Pittsburgh and Harrisburg).  These three gateways are connected to the OSPF Backbone Area (0.0.0.0) and bridged to the host laptop's wireless adapter; they receive a DHCP address as the default gateway.

Specific details of network addressing are presented in the figure above.

Adding the Debian Linux Gateways

The gateways are VirtualBox servers preconfigured for the network.  These are connected to the respective Cisco 7206 routers' OSPF Backbone Area Fast Ethernet adapter (Philadelphia, 172.16.253.1; Pittsburgh, 172.16.252.1 and Harrisburg, 172.16.251.1, respectively) over adapter eth1.  Adapter eth0 is bridged to the host laptop's wlan0 interface and receives a DHCP address (and default gateway) from a wireless router running DD-WRT; the bridged wlan0 interfaces are part of OSPF Area 192.168.0.0, corresponding to the DHCP range 192.168.1.x / 255.255.255.0.

Each gateway has IP Forwarding enabled and uses Quagga routing software.  The pertinent OSPF configuration provided by the /etc/quagga/quagga.conf file (for Philadelphia as an example) is:

router ospf
 ospf router-id 192.168.1.3
 network 172.16.253.0/24 area 0.0.0.0
 network 192.168.1.0/24 area 192.168.0.0
 area 0.0.0.0 range 172.16.0.0/12
 default-information originate always

The router-id identifies the router as part of the wlan0-bridged OSPF area 192.168.0.0.  The two network lines specify the networks in which OSPF is active and the area defines the OSPF Backbone configuration as a summarized network (172.16.0.0 - 172.16.31.255).

The statement "default-information originate always" instructs the OSPF routing process to advertise itself as a default gateway to exterior networks -- the gateways are Autonomous System Boundary Routers (ASBRs).

Checking the Configuration

Prior to booting the three Debian Linux Gateways, check the routing tables, OSPF neighbors and default gateways of the four Cisco 7206 routers.  As configured in Part 1 and Part 2 of the series, there was only one Debian Linux Gateway acting as an ASBR -- Coudersport.  Thus, the Philadelphia, Pittsburgh and Harrisburg routers' default gateways are the OC-3 interfaces connected to the Coudersport OC-3 interface; all Internet-bound traffic must route through the Coudersport Cisco 7206 and then the Coudersport Debian Linux Gateway.

Upon booting the three new Debian Linux Gateways, check their routing processes by telnetting to port 2604, the Quagga ospf daemon.  Each should see the host laptop and a local Cisco 7206 router as OSPF neighbors; additionally, they should see each other as neighbors with 192.168.1.x router-ids.

Once the new Debian Linux Gateways are working properly, check and compare (to the previous information) the routing tables, OSPF neighbors and default gateways on the Cisco 7206 routers.  At this point, the local Debian Linux Gateway will appear as a neighbor.  More importantly, the default gateway will now be that local Debian Linux Gateway (Philadelphia, 172.16.253.2; Pittsburgh 172.16.252.2 and Harrisburg 172.16.251.2, respectively).

There are now four ASBRs in the network -- the Debian Linux Gateways.  This provides several benefits:

1. Internet-bound traffic is now distributed through four gateways, local to each data center (Coudersport, Philadelphia, Pittsburgh and Harrisburg).  If one, two or three local ASBRs fail, traffic will route through another (as determined by the OSPF shortest-path algorithm).
2. Previously, all Internet-bound traffic routed through the single Coudersport ASBR.  Internet-bound traffic now uses a local gateway, not the OC-3 and backup T-1 leased lines.

The video below illustrates the process.

GNS3 - VitualBox Part 2: Creating an OSPF Backbone Area

Configuring four Cisco 7206 routers connected by OC-3 and T-1 lines to act as an OSPF Backbone Area.  This article starts using the Basic Topology configured in Part 1 of the series.

Introduction

The illustration above depicts what will be configured: four Cisco 7206 routers (Coudersport, Philadelphia, Pittsburgh and Harrisburg).  The Coudersport router is connected to the other three using point-to-point OC-3 lines; the remaining three links between Philadelphia, Pittsburgh and Harrisburg are point-to-point T-1 lines.

The LAN side of each router consists of two Fast Ethernet adapters, one configured with addresses in the OSPF Backbone Area 0.0.0.0 (address range 172.16.0.0 - 172.16.31.255) and the other defining a private network in the 10.x.x.x address range.

Specific details of network addressing are presented in the figure above.

Adding the Cisco Routers

There are two new 7206 routers (Pittsburgh and Harrisburg) added to the existing two in the network (Coudersport and Philadelphia).  All routers are provided a C-7200-IO-2FE card in slot 0 (two Fast Ethernet adapters).  The existing Coudersport and Philadelphia routers have PA-POS-OC3 cards in slot 6 (one OC-3 adapter).

The Coudersport router requires two additional adapters to support the topology: PA-POS-OC3 cards in slots 4 and 5.  The Philadelphia router requires one additional adapter to support the topology: a PA-4T+ card in slot 1 (four T-1 adapters). The Pittsburgh and Harrisburg routers are equipped identically to the Philadelphia router: a PA-4T+ card in slot 1 and a PA-POS-OC3 card in slot 6.

Note the distribution of cards.  The Cisco 7206 has two PCI buses bridged into the system bus, with slots 0, 1, 3 and 5 on one PCI bus and slots 2, 4 and 6 on the other.  The distribution specified spreads the high-speed interfaces (Fast Ethernet and OC-3) among the two PCI buses.  Detailed instructions for calculating allowable card configurations are available from Cisco's 7200 Port Adapter Configuration Guidelines.

Router Configurations

The following sections present those parts of the router configurations that define address and OSPF information.

Coudersport 7206 (COU_7206)

interface FastEthernet0/0
 ip address 172.16.254.1 255.255.255.0
 duplex full
 speed auto
!
interface FastEthernet0/1
 ip address 10.0.0.1 255.255.255.0
 duplex full
 speed auto
!
interface POS4/0
 ip address 172.16.0.9 255.255.255.252
!
interface POS5/0
 ip address 172.16.0.5 255.255.255.252
!
interface POS6/0
 ip address 172.16.0.1 255.255.255.252
!
router ospf 1
 router-id 10.0.0.1
 log-adjacency-changes
 area 0.0.0.0 range 172.16.0.0 255.240.0.0
 area 10.0.0.0 range 10.0.0.0 255.255.0.0
 network 10.0.0.0 0.0.0.255 area 10.0.0.0
 network 172.16.0.0 0.0.0.3 area 0.0.0.0
 network 172.16.0.4 0.0.0.3 area 0.0.0.0
 network 172.16.0.8 0.0.0.3 area 0.0.0.0
 network 172.16.254.0 0.0.0.255 area 0.0.0.0
!

Philadelphia 7206 (PHL_7206)

interface FastEthernet0/0
 ip address 172.16.253.1 255.255.255.0
 duplex full
 speed auto
!
interface FastEthernet0/1
 ip address 10.64.0.1 255.255.255.0
 duplex full
 speed auto
!
interface Serial1/0
 ip address 172.16.1.1 255.255.255.252
 serial restart-delay 0
!
interface Serial1/1
 ip address 172.16.1.5 255.255.255.252
 serial restart-delay 0
[...]
!
interface POS6/0
 ip address 172.16.0.2 255.255.255.252
!
router ospf 1
 router-id 10.64.0.1
 log-adjacency-changes
 area 0.0.0.0 range 172.16.0.0 255.240.0.0
 area 10.64.0.0 range 10.64.0.0 255.255.0.0
 area 10.64.0.0 virtual-link 10.64.0.3
 network 10.64.0.0 0.0.0.255 area 10.64.0.0
 network 172.16.0.0 0.0.0.3 area 0.0.0.0
 network 172.16.1.0 0.0.0.3 area 0.0.0.0
 network 172.16.1.4 0.0.0.3 area 0.0.0.0
 network 172.16.253.0 0.0.0.255 area 0.0.0.0
!

Pittsburgh 7206 (PIT_7206)

interface FastEthernet0/0
 ip address 172.16.252.1 255.255.255.0
 duplex full
 speed auto
!
interface FastEthernet0/1
 ip address 10.128.0.1 255.255.255.0
 duplex full
 speed auto
!
interface Serial1/0
 ip address 172.16.1.2 255.255.255.252
 serial restart-delay 0
!
interface Serial1/1
 ip address 172.16.1.9 255.255.255.252
 serial restart-delay 0
[...]
!
interface POS6/0
 ip address 172.16.0.6 255.255.255.252
!
router ospf 1
 router-id 10.128.0.1
 log-adjacency-changes
 area 0.0.0.0 range 172.16.0.0 255.240.0.0
 area 10.128.0.0 range 10.128.0.0 255.255.0.0
 network 10.128.0.0 0.0.0.255 area 10.128.0.0
 network 172.16.0.4 0.0.0.3 area 0.0.0.0
 network 172.16.1.0 0.0.0.3 area 0.0.0.0
 network 172.16.1.8 0.0.0.3 area 0.0.0.0
 network 172.16.252.0 0.0.0.255 area 0.0.0.0
!

Harrisburg 7206 (HBG_7206)

interface FastEthernet0/0
 ip address 172.16.251.1 255.255.255.0
 duplex full
 speed auto
!
interface FastEthernet0/1
 ip address 10.192.0.1 255.255.255.0
 duplex full
 speed auto
!
interface Serial1/0
 ip address 172.16.1.6 255.255.255.252
 serial restart-delay 0
!
interface Serial1/1
 ip address 172.16.1.10 255.255.255.252
 serial restart-delay 0[...]
!
interface POS6/0
 ip address 172.16.0.10 255.255.255.252
!
router ospf 1
 router-id 10.192.0.1
 log-adjacency-changes
 area 0.0.0.0 range 172.16.0.0 255.240.0.0
 area 10.192.0.0 range 10.192.0.0 255.255.0.0
 network 19.192.0.0 0.0.0.255 area 10.192.0.0
 network 172.16.0.8 0.0.0.3 area 0.0.0.0
 network 172.16.1.4 0.0.0.3 area 0.0.0.0
 network 172.16.1.8 0.0.0.3 area 0.0.0.0
 network 172.16.251.0 0.0.0.255 area 0.0.0.0
!

Checking the Configuration

Upon configuring the routers, each will:

1. Have a default gateway that routes through the Coudersport Gateway Debian Linux server
2. Have routing table entries for all networks in the OSPF Backbone network
3. Have a routing table entry for its own 10.x.x.x network
4. Have routing table summary entries for the three other 10.x.x.x networks
5. Have OSPF Neighbor entries for the three other Cisco 7206 routers
6. Be able to ping public IP addresses (e.g. 8.8.8.8)

The video below depicts the process described above.

GNS3 - VitualBox Part 1: Creating an Internet Gateway and Private Network

Configuring a basic GNS3-VirualBox system (one Linux Gateway router, two Cisco 7206 routers connected over OC-3 and a Windows Domain Controller).  The Linux gateway provides a simple connection to the host operating system (Ubuntu 14.04) using Quagga routing software; it also communicates with Cisco routers, providing the host operating system full visibility of the virtual Cisco network.

Introduction

The illustration above depicts what will be configured:  a shared wireless adapter for the host operating system (Ubuntu 14.04) and Debian Linux Gateway (in a virtual data center Coudersport).  A wireless router running DD-WRT provides DHCP addresses to the shared wireless adapter.  The virtual Cisco network consists of two 7206 routers.  One router is in the Coudersport data center and the other is in the Philadelphia data center.  There is a Windows 2012 R2 server in the Philadelphia data center; Fast Ethernet adapters are connected to GNS3 virtual Layer 2 switches.  Ultimately, the test of the network's configuration is the Windows server connecting to the Internet.

Adding the Debian Linux Gateway

The Debian Linux Gateway requires two Ethernet adapters:  one is bridged (through VirtualBox) to the host laptop's wireless adapter.  The second is a linked to the GNS3 software using a "Generic Driver."

The host laptop and Debian Gateway use Quagga to communicate with other routers -- and themselves.  Wireless routers frequently provide addresses in the 192.168.0.0 - 192.168.254.0 range; the host laptop and Debian Gateway are configured to communicate over these DHCP addresses using the command:

network 192.168.1.0/24 area 192.168.0.0

as the router most frequently used assigns an address in the 192.168.1.0/24 range.

The host laptop is assigned the router-id 192.168.1.1 and the Debian Gateway VirtualBox server the router-id 192.168.1.2.

The Debian Gateway is also the starting point of the Backbone OSPF area 0.0.0.0 with the command:

area 0.0.0.0 range 172.16.0.0/12

The equivalent Cisco IOS command is:

area 0.0.0.0 range 172.16.0.0 255.240.0.0

This defines the private network range 172.16.0.0 - 172.16.25.255 as belonging to the Backbone Area.  Properly configured, the Debian Gateway will be adjacent to the host laptop in the 192.168.0.0 area.

Adding the Coudersport 7206 Router

The Coudersport Cisco 7206 router is connected to the Debian Gateway over Ethernet and a GNS3 virtual Layer 2 switch.  The interface FastEthernet0/0 is configured with the commands:

ip address 172.16.254.1 255.255.255.0
duplex full
no shutdown

The OSPF process is configured with the commands:

router-id 10.0.0.1
area 0.0.0.0 range 172.16.0.0 255.240.0.0
network 172.16.254.0 255.255.255.0 area 0.0.0.0

These commands set the interface IP address, the router-id, define the backbone network address range and add the local network to the backbone area.  Upon configuration, the router will be adjacent to the Debian Gateway (running Quagga) in the backbone area (0.0.0.0).

Adding the Philadelphia 7206 Router

The Philadelphia 7206 router is connected to the Coudersport 7206 router over a point-to-point OC-3 line.  In addition to the Fast Ethernet cards in slot 0, we must also add PA-POS-3 cards to slot 6 in each router chassis.


On the Coudersport router, the P6/0 interface is configured with:

ip address 172.16.0.1 255.255.255.252
no shutdown

On the Philadelphia router, the P6/0 interface is configured with:

ip address 172.16.0.2 255.255.255.252
no shutdown

This defines a point-to-point network (172.16.0.0, broadcast address 172.16.0.4).  The Philadelphia router also needs a private network to host the Windows Domain Controller (see below). The Fast Ethernet interface is configured with the commands:

ip address 10.64.0.1 255.255.255.0
duplex full
no shutdown

The Philadelphia router's OSPF process is configured with the commands: 

router-id 10.64.0.1
area 0.0.0.0 range 172.16.0.0 255.240.0.0
area 10.64.0.0 range 10.64.0.0 255.255.0.0
network 172.16.0.0 255.255.255.252 area 0.0.0.0
network 10.64.0.0 255.255.255.0 area 10.64.0.0

The Coudersport router requires adding network 172.16.0.0 255.255.255.252 to area 0.0.0.0 as well.  Upon completion, the two routers will form an adjacency in area 0.0.0.0.  The Philadelphia router's connectivity to the Internet may be tested by pinging a public IP address (e.g. 8.8.8.8).

Adding the Windows Domain Controller

Finally, add the Windows Domain Controller to the Philadelphia network.  Set the server's IP address to 10.64.0.2.  At that point, it will connect to the Internet through the virtual routers.

The video below illustrates the entire configuration process.

Installing Zabbix 2.4 on Debian Wheezy

Zabbix 2.4 is a significant upgrade to Zabbix 2.2.  This post describes some of the enhancements and the simplified installation on Debian Wheezy.

Changes from Zabbix 2.2 to 2.4

A complete list of changes is available in the Zabbix documentation.  A summary of selected improvements includes:

1. Defining multiple filters for low level discovery
2. Node-based distributed monitoring removed (Node-based monitoring has been problematical in Zabbix 2.2, possibly due to high bandwidth, low latency requirements)
3. Ad-hoc graphs for several items
4. Custom calculation of action conditions
5. Support of new trigger operators
6. Web monitoring improvements (custom headers, SSL verification and authentication options, clearing history and trend data)
7. Optional SNMP bulk requests (as opposed to the previous mandatory)
8. Graph prototypes supported in screens
9. Option to remove missing resources when importing
10. Frontend improvements (unified date and time format, global search by technical name, application filter for maps, URL as dynamic screen element, responsible action shown in action log, description field added to host, host, template and proxy configuration, trigger dependencies shown as links, option to see items only on trigger status page, more options for trigger filtering, maintenance period sorting, host menu changes, regular expression validation, dropping green status icons in listings, changing uploaded image type disallowed, changes regarding multibyte string support, and several more miscellaneous improvements)
11. Macro improvements
12. Daemon improvements (LLD, item processing, configuration file handling, including specific items from the Include directory, JSON formatting, log file handling, automaticly discovered host handling, more unsupported item details, database, housekeeper and script result changes and log level at runtime changes)
13. Item changes/improvements
14. API improvements

The Zabbix development team has been responsive to user comments and has done a good job of separating Maintenance (included in Zabbix 2.2 updates) from Development (included in the Zabbix 2.4 release).

Installation on Debian Wheezy

The Zabbix 2.2.x package included with Debian Wheezy is not a seamless installation.  There are many manual changes required, as demonstrated in a previous article.  Zabbix 2.4 is not included in Debian Wheezy and the packages must be downloaded from the Zabbix repositories (at http://repo.zabbix.com).  While this may sound like more work, in reality the packages available from the Zabbix repository are better integrated with the apt package management system tan those available from Debian; a great deal of manual configuration is eliminated.

Instructions are available from the Zabbix and this article is drawn heavily from those.

Download and Install the Zabbix Release

Adding a repository to /etc/apt/sources.list is not necessary.  Rather, a release package (downloaded from the Zabbix repository) performs the necessary modifications.

# wget http://repo.zabbix.com/zabbix/2.4/debian/pool/main/z/zabbix-release/zabbix-release_2.4-1+wheezy_all.deb
# dpkg -i zabbix-release_2.4-1+wheezy_all.deb
# apt-get update

 The author installed Debian Wheezy from the boot DVD and specified repositories from the Advanced Installation.  Prior to the package update, the author commented out the line specifying DVD 1 as a source.  This is illustrated in the video at the end of this article.

Install Zabbix Packages

The release package installed above adds the appropriate sources.  Better still, the dependency problems in the Debian distribution packages are solved, eliminating the need to manually specify a long list of packages required for a Debian-version Zabbix 2.2 installation.

# apt-get install zabbix-server-mysql zabbix-frontend-php zabbix-agent postfix

The author installs postfix (replacing the default Debian exim mail MTA); this is optional and included because the author prefers the features in postfix.

During installation, several screens will prompt the administrator to configure Postfix, MySQL and Zabbix.  These are illustrated in the video at the end of this article.

Configure a Time Zone in the Zabbix Frontend PHP Settings

Appropriate PHP settings are included in the installation and installed to /etc/apache2/conf.d/zabbix.  However, the date.timezone value must be manually set by editing that file.  Simply chose an appropriate value from this list.

php_value max_execution_time 300
php_value memory_limit 128M
php_value post_max_size 16M
php_value upload_max_filesize 2M
php_value max_input_time 300
# php_value date.timezone Europe/Riga

Perform the Zabbix Web-Based Installation

Finally, browse to the server's /zabbix directory and perform the web-based installation.  Unlike the installation for the package included with Debian Wheezy, there are no significant manual actions to perform (e.g. manually editing all of the required PHP values and manually adding the frontend configuration file).  Enter the database password specified during the package installations above and the rest is automatic.  The administrator may then log in to the frontend using the default user name "admin" and password "zabbix."

The video below illustrates the entire process.