GNS3 - VirtualBox Part 8: Creating tun/tap and Cloud Devices

Describes how to configure persistent tun/tap devices and IP Masquerading on a host machine and connect to GNS3 Cloud Devices and virtual networks to the host and Internet.

9 April 2015 -- Important Update
If you install dynamips from source on Ubuntu, the executable will not have the correct permissions for tun/tap devices.  Change to the executable's directory (/usr/local/bin) and run the following command:

sudo setcap cap_net_raw,cap_net_admin+eip dynamips

Creating Persistent tun/tap Interfaces
Additional software is required to create the logical interfaces for cloud devices.

sudo apt-get install uml-utilities bridge-utils

The rc.local file is executed at boot time and configures persistent tun/tap interfaces.

tunctl -t tap0
sudo ifconfig tap0 172.16.100.1 netmask 255.255.255.0 up

tunctl -t tap1
sudo ifconfig tap1 172.16.101.1 netmask 255.255.255.0 up

tunctl -t tap2
sudo ifconfig tap2 172.16.102.1 netmask 255.255.255.0 up

tunctl -t tap3
sudo ifconfig tap3 172.16.103.1 netmask 255.255.255.0 up

exit 0

Once configured and executed, ifconfig will list devices tun0, tun1, tun2 and tun3.

Configuring Network Address Translation Masquerading on the Host Machine

There are numerous articles describing Network Address Translation (NAT) masquerading available.  For this example, the Webmin Firewall interface provides a graphical configuration tool to use the host wireless interface wlan0 for NAT masquerading.

Under the host's Webmin interface, navigate to Networking and select Linux Firewall.  In the upper left, select Network Address Translation (NAT) from the Showing IPTable pull-down menu.  There will be no rules configured.  NAT is a Post Routing action, so click Add Rule under the Packets After Routing (POSTROUTING) section.  In the subsequent screen, select the Masquerade radio button and change the Outgoing Interface section from <ignore> to Equals and select interface wlan0 as illustrated below.  Save this rule.

Make sure the Activate at Boot option is selected and click Apply Configuration.

This typically -- but not always -- applies the NAT.  You may wish to reboot at this point.

The /etc/network/interfaces for the host laptop only configures a loopback device at boot time.  Recall also the tun/tap devices are configured in the rc.local file.  Webmin's firewall module adds a line invoking the IPTables rules under the loopback device configuration:

iface lo inet loopback
    post-up iptables-restore < /etc/iptables.up.rules

The files /etc/iptables.up.rules generated by webmin is:

# Generated by iptables-save v1.4.21 on Thu Jan 22 06:32:20 2015
*filter
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
COMMIT
# Completed on Thu Jan 22 06:32:20 2015
# Generated by iptables-save v1.4.21 on Thu Jan 22 06:32:20 2015
*mangle
:PREROUTING ACCEPT [0:0]
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
:POSTROUTING ACCEPT [0:0]
COMMIT
# Completed on Thu Jan 22 06:32:20 2015
# Generated by iptables-save v1.4.21 on Thu Jan 22 06:32:20 2015
*nat
:PREROUTING ACCEPT [0:0]
:POSTROUTING ACCEPT [0:0]
:INPUT ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
-A POSTROUTING -o wlan0 -j MASQUERADE
COMMIT
# Completed on Thu Jan 22 06:32:20 2015

The most important line is:

-A POSTROUTING -o wlan0 -j MASQUERADE

Some variation of that command is required for masquerading.

Configuring OSPF Routing between the Host Machine and GNS3 Networks

Previous articles in this series have used Debian Linux VirtualBox Gateways to connect GNS3 networks to the host machine and Internet.  These Gateways require 160 - 192 MB memory each and each machines eth0 interface is VirtualBox bridged to the host machines wlan0 interface.  These work well, but four of them use 640 - 768 MB memory, not insignificant, when (by comparison) a Linux VirtualBox Nagios, Icinga or Zabbix server requires only 512 MB memory.  Converting to host machine tun/tap devices and GNS3 clouds frees up that memory for other purposes.

Debian Linux Gateways also present additional security issues.  In the illustration above, the top part depicts how the Debian Linux Gateways -- with eth0 bridged to the host's wlan0 interface -- require additional security.  Each Gateway's connection runs OSPF to share routes with the host using Area 192.168.0.0 -- the wireless LAN interface -- and must be secured (this network uses the FWBuilder application to configure IPTables) because they are exposed to the wlan0 network.  This may not be a issue at home, but is when connecting a laptop host to other networks.

Many articles are available describing how to configure static routes for tun/tap interfaces.  However, with multiple tun/tap interfaces, a routing protocol on the host machine is more flexible and reliable.  For instance, multiple Cloud Device - GNS3 router instances may be created with automatic host-GNS3 and GNS3 virtual router updates.  GNS3 routing topologies may be created and modified as needed and the host machine's routes to GNS3 devices will automatically update.  In the illustration above, the bottom part depicts how only one interface -- the host's wlan0 -- is exposed.  The cloud devices, running on tun/tap interfaces, must route through the host for Internet and wireless network access.  The tun/tap device addresses and networks are merely added to the host's OSPF process.  Routing from the GNS3 virtual network to the Internet is provided by the host's NAT masquerade rule.

To configure routing for GNS3 Cloud devices, add the tun/tap interface networks to the OSPF configuration in the Quagga routing process.  Also, the host must originate default routes for the GNS3 routers.  For the four tun/tap devices already configured:

network 172.16.100.0/24 area 0.0.0.0
network 172.16.101.0/24 area 0.0.0.0
network 172.16.102.0/24 area 0.0.0.0
network 172.16.103.0/24 area 0.0.0.0 

default-information originate always

Migrating from VirtualBox Debian Linux Gateways to GNS3 Cloud Devices

Migrating the network used in this series from VirtualBox Debian Linux Gateways to GNS3 Cloud devices is, at this point, rather simple:

1. Remove the VirtualBox Debian Linux Gateways
2. Add GNS3 Cloud Devices configured for host tun/tap interface
3. Change existing GNS3 router's IP addresses and OSPF networks

When the VirtualBox Gateways are removed there are no routes from the host to the GNS3 network.  The route command on the host will only list its default gateway, wireless network and the four tun/tap interface networks.

Once the first tun/tap device is connected to a cloud and the GNS3 router updated (Coudersport_Cloud in this example), the host will establish an OSPF adjacency and have routes to all GNS3 networks through interface tap0.

As each of the remaining three Cloud Devices are added, new shortest path routes appear in the host's routing table.  For instance, when adding the Philadelphia_Cloud device, the route to network 10.64.0.0 255.248.0.0 changes from tap0 to tap1 (from 172.16.100.2 to 172.16.101.2).  Upon completion, there will be routes from the laptop through each of the Cloud devices tap0, tap1, tap2 and tap3.

The video below depicts the process.

GNS3 - VitualBox Part 7: OSPF over Frame Relay Switches

An explanation of mapped and Inverse ARP Frame Relay configurations and how to implement OSPF over them.

Introduction

Frame Relay is a Non Broadcast Multiple Access (NBMA) technology.  It operates at Layer 2 -- Datalink -- of the OSI Networking Model and relies upon connected nodes (in this case Cisco routers) to implement Layer 3 and above (in this case, TCP/IP).  NBMA technologies do not support broadcast and multicast traffic.  OSPF uses multicast packets for LSAs.  Additional configuration is required to implement OSPF on Frame Relay switched networks.

Frame Relay Basics

In Ethernet networks, this is implemented with Media Access Control (MAC) addresses -- 12-hexadecimal digit unique identifiers typically "burned in" to the hardware by the manufacturer.  When two nodes on an Ethernet network, they translate Layer 3 (e.g. IP) addresses into Layer 2 (MAC) addresses using Address Resolution protocol.  The Ethernet devices (e.g. hubs and switches) and supporting hardware (e.g. cabling, wireless) determine the path and access at Layer 2.  This sequence operates dynamically because the end nodes and networks support Address Resolution Protocol (ARP), which maps Layer 3 IP addresses to Layer 2 MAC addresses.

Frame Relay does not operate at Layer 2 the same way Ethernet does.  Frame Relay uses Data Link Connection Identifiers (DLCIs) assigned to physical interfaces rather than MAC addresses.  The switched Frame Relay network manages connections between DLCIs with mappings -- associating one DLCI with a corresponding one.  DLCIs are typically assigned by the Internet Service Provider (ISP).  A pathway from one DLCI to a corresponding DLCI is a Virtual Circuit (VC).  For this example, a unique and unchanging DLCI and data path is assigned for each VC, creating a Permanent Virtual Circuit (PVC).  Although not demonstrated in this article, DLCIs and paths may be assigned dynamically to endpoints (analogous to dial-up networking) and the resulting VCs are Switched Virtual Circuits (SVCs).

Each PVC requires a unique DLCI-DLCI mapping on the Frame Relay switched network.  This implies other differences between Frame Relay and Ethernet Layer 2 technologies:  Frame Relay must be manually configured with one or more unique Layer 2 addresses while Ethernet is configured with (typically) permanent Layer 2 addresses and the switches establish endpoint connections automatically.  Each Frame Relay endpoint must have a unique DLCI assigned for each connection to another endpoint, so a single endpoint will have multiple DLCIs if it connect to more than one other endpoint.

Example Frame Relay Layer 2 Topologies

The illustration at the top of the page depicts the Layer 1 Physical topology -- each router has a single serial T-1 connection to a Frame Relay switch port.  There are many Layer 2 -- DLCI-DLCI PVC mappings -- that may be implemented.

Hub and Spoke Topology

A hub and spoke topology applicable to a Data Center to five Branch Offices is to create a PVC connection from each Branch Office to the Data Center.  This is implemented by assigning five DLCIs to the Data Center endpoint (port 1) mapped to a each of a single DLCI assigned to each Branch Office (ports 2 through 6).  There are a total of five PVCs.  The illustration above depicts the logical Layer 2 Frame Relay Hub and Spoke DLCI-DLCI PVC mappings.

The format of the DLCIs used in the GNS3 Frame Relay switch example is "<source port> 0 <destination port>.  DLCI 102 is assigned to the PVC from interface 1 to interface 2 and is mapped to the corresponding DLCI 201  assigned to the PVC from interface 2 to interface 1.

Mesh Topology

A mesh topology applicable to a Data Center and five Branch Offices is to create a PVC connection between every endpoint.  Each endpoint has five unique DLCIs and there are a total of 15 PVCs.  The illustration above depicts the logical Layer 2 Frame Relay Mesh DLCI-DLCI PVC mappings.

Establishing Router-To-Router Connections Over Frame Relay

Ethernet uses ARP to map IP to MAC addresses.  When an IP node establishes a connection to another IP node, it first consults its local ARP cache (list of IP address to MAC adress mappings).  If there is no corresponding IP address to MAC address mapping, it sends out an ARP broadcast packet to determine the MAC address to use.  Frame Relay, as an NBMA technology, does not support broadcast packets.

Lacking broadcast support, establishing router-to-router IP connections over Frame Relay connections is a different process.

Manual IP Address-to-DCLI Mappings

Cisco IOS provides commands to manually map IP addresses to DLCIs.  Two important ones are frame-relay map and frame-relay interface-dlci.

Addresses Assigned to the Physical Interface

When an IP address is assigned to the physical serial interface (e.g. s0/0, s0/1, s1/0, etc.), Cisco IOS recognizes the assigned DLCIs in much the same way operating systems recognize Ethernet MAC addresses.  That is, the Cisco IOS on the router already has a mapping for its local DLCI assigned by the ISP to its physical interface.  However, it lacks a DLCI to remote IP address mapping (analogous to Ethernet's ARP cache).  This mapping may be established by manually specifying the remote IP address associated with the local DLCI using the frame-relay map command, whose syntax is:

frame-relay map <protocol> <destination IP address> <local DLCI> <option>

The goal is to support OSPF over the link and NBMA networks do not support broadcasts.  The operating system must specify that broadcast packets are forwarded to this DLCI, at which point the Frame Relay switched network delivers it to the corresponding DLCI and receiving device accepts the packet.  To do so, add the "broadcast" option to each configuration.  For example:

On Router 1:

frame-relay map ip 192.168.0.2 102 broadcast

On Router 2:

frame-relay map ip 192.168.0.1 201 broadcast

A complete example, mapping Router 1 with IP address 192.168.0.1/30 and DLCI 102 to Router 2 with IP address 192.168.0.2/30 and DLCI 201, is:

On Router 1:

config t
interface s0/0
no shutdown
ip address 192.168.0.1 255.255.255.252
encapsulation frame-relay
frame-relay map ip 192.168.0.2 102 broadcast

On Router 2:

config t
interface s0/0
no shutdown
ip address 192.168.0.2 255.255.255.252
encapsulation frame-relay
frame-relay map ip 192.168.0.1 201 broadcast

Addresses Assigned to Logical Subinterfaces

Logical subinterfaces (e.g. s0/0.1, s0/0.2, etc.) operate differently than physical interfaces.  They are logical devices created by the Cisco IOS, not physical ones recognized by the Cisco IOS.  One implication of this is that subinterfaces do not recognize any of the DLCIs assigned to their parent physical interfaces.  Before mapping remote IP addresses to local DLCIs, the subinterface must first have one or more DLCIs from the parent physical interface assigned to the logical subinterface.  Using the example above:

On Router 1:

config t
interface s0/0
no shutdown
encapsulation frame-relay
interface s0/0.1multipoint
ip address 192.168.0.1 255.255.255.252
frame-relay interface-dlci 102
frame-relay map ip 192.168.0.2 102 broadcast

On Router 2:

config t
interface s0/0
no shutdown
encapsulation frame-relay
interface s0/0.1 multipoint
ip address 192.168.0.2 255.255.255.252
frame-relay interface-dlci 201
frame-relay map ip 192.168.0.1 201 broadcast

Inverse ARP IP Address-To-DLCI Mappings

Frame Relay Inverse ARP is another way to map addresses.  ARP translates Layer 3 IP addresses to Layer 2 MAC addresses; Inverse ARP (as the name implies) translates Layer 2 DLCI addresses to Layer 3 IP addresses.  In operation, when a router requests a remote IP address, it sends Inverse ARP packets by matching the associated network and using any local IP addresses to decide where to send it.  It then sends the Inverse ARP packets to every DLCI mapped to candidate IP addresses.  On the receiving devices, the receiving DLCI that corresponds to the requested remote IP address responds, creating the PVC and DLCI-IP address mappings.

Consider the section above explaining how physical and logical interfaces interact with Cisco IOS.  When an IP address is assigned to a physical interface, the corresponding DLCIs are available to IOS.  However, when an IP address is assigned to a logical subinterface, there is no DLCI mapping until one is specified.  So, Inverse ARP works by default on physical interfaces as soon as an IP address is assigned.  Inverse ARP will not work on a logical subinterface until both an IP Address and DLCI assigned to the parent physical interface are assigned.  In fact, the frame-relay map command is disallowed on subinterfaces because if it is point-to-point because there is only one possible destination DLCI; multipoint subinterfaces still require mappings.

Once properly configured for Inverse ARP, the IP Address - DLCI mappings will be configured upon the router requesting the remote IP address.  Pinging the remote address will trigger the Inverse ARP request and dynamic DLCI mappings created.

Configuring OSPF over Frame Relay

The OSPF network type, by default, for frame relay is non-broadcast.  To manually set the OSPF network type to broadcast:

config t
interface s0/0
ip ospf network broadcast

At that point, the two routers will form an adjacency.

Optionally, you may manually specify the IP Address of neighboring routers using the neighbor command. 

The video below illustrates how to configure the above OSPF over Frame Relay options.

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.