Point-to-Point Links Example

Let's say you're running a WAN made up of a series of point-to-point links (T1 lines, VPN links, or whatever). You want a good way to represent those links in your Netomata network model, so that it's easy to add/drop/change links, while ensuring that all the right data gets into the model.

For example, let's say you're running a point-to-point network for a small company with main offices in San Francisco (SFO) and Los Angeles (LAX), and branch offices in San Jose (SJC), Oakland (OAK), San Diego (SAN), and Santa Barbara (SBA). Each main office (SFO and LAX) has a Cisco 3640 router, and each branch office (SJC, OAK, SAN, and SBA) has a Cisco 3620. Each branch office has a point-to-point link to both main offices (SFO and LAX). There's also a point-to-point link between the two main offices (SFO and LAX). (Never mind the ridiculous economics of running all these point-to-point links; imagine that they're all point-to-point VPN connections, if it makes you happier. ;-) )

To start with, we need to create a entries for the routers at each site. We'll do this in the "!devices" part of the Netomata tree that models our network, via the following neto_table file (call it "devices.neto_table"):

# List of devices in our network, along with their location,
# model number, and IP address to be used for managing them
#
# For each device, we simply create a node in "!devices" with the info for
# that device.
# 
@ !devices!(+)!name = %{name}
@ !devices!(name=%{name})!location = %{location}
@ !devices!(name=%{name})!model = %{model}
@ !devices!(name=%{name})!management_ip = %{management_ip}
#
% name	location	model		management_ip
#
sfo	San Francisco	Cisco 3640	192.168.1.1
lax	Los Angeles	Cisco 3640	192.168.2.1
sjc	San Jose	Cisco 3620	192.168.3.1
oak	Oakland		Cisco 3620	192.168.4.1
san	San Diego	Cisco 3620	192.168.5.1
sba	Santa Barbara	Cisco 3620	192.168.6.1

(If you're copying/pasting from this page, remember that columns need to be separated by one or more tabs.)

Now that we've got the devices defined, we can create a neto_table file that describes all the links, and adds all the necessary interfaces (two for each link: one for each end) to all of the devices; call this file "links.neto_table":

# Each data line below describes a single point-to-point link from
# 	ifcA on rtrA to ifcZ on rtrZ. 
#
# A /30 subnet is assigned to each link.  The interface on rtrA gets the .1
#	address on the subnet, and the interface on rtrB gets the .2 address.
#
# For each router/interface pair, we set the following keys:
#	name = name of this interface (i.e., Serial0/1)
#	description = text describing what's at the other end of this link
#	ip_net = IP network assigned to this net (should be a /30 boundary)
#	ip = this interface's IP address on ip_net
#		(.1 for rtrA:ifcA, .2 for rtrZ:ifcZ)
#	netmask = 255.255.255.252 (i.e., /30)
#	type = point_to_point (i.e., what kind of interface this is)
#
########
# Set keys for rtrA:ifcA
########
@ !devices!(name=%{rtrA})!interfaces!(+)!name = %{ifcA}
@ !devices!(name=%{rtrA})!interfaces!(name=%{ifcA})!description = \
	Link to %{rtrZ}:%{ifcZ}
@ !devices!(name=%{rtrA})!interfaces!(name=%{ifcA})!ip_net = %{ip_net}
@ !devices!(name=%{rtrA})!interfaces!(name=%{ifcA})!ip = \
	[%= ip_union("%{ip_net}", "0.0.0.1") %]
@ !devices!(name=%{rtrA})!interfaces!(name=%{ifcA})!netmask = 255.255.255.252
@ !devices!(name=%{rtrA})!interfaces!(name=%{ifcA})!type = point_to_point
########
# Set keys for rtrZ:ifcZ
########
@ !devices!(name=%{rtrZ})!interfaces!(+)!name = %{ifcZ}
@ !devices!(name=%{rtrZ})!interfaces!(name=%{ifcZ})!description = \
	Link to %{rtrA}:%{ifcA}
@ !devices!(name=%{rtrZ})!interfaces!(name=%{ifcZ})!ip_net = %{ip_net}
@ !devices!(name=%{rtrZ})!interfaces!(name=%{ifcZ})!ip = \
	[%= ip_union("%{ip_net}", "0.0.0.2") %]
@ !devices!(name=%{rtrZ})!interfaces!(name=%{ifcZ})!netmask = 255.255.255.252
@ !devices!(name=%{rtrZ})!interfaces!(name=%{ifcZ})!type = point_to_point
########
# Data
########
% rtrA	ifcA		rtrZ	ifcZ		ip_net
# ----	----		----	----		------
sfo	Serial0/1	sjc	Serial0/1	172.31.1.0
sfo	Serial0/2	oak	Serial0/1	172.31.1.4
sfo	Serial0/3	san	Serial0/1	172.31.1.8
sfo	Serial0/4	sba	Serial0/1	172.31.1.12
sfo	Serial1/1	lax	Serial1/1	172.31.0.0
lax	Serial0/1	sjc	Serial0/2	172.31.2.0
lax	Serial0/2	oak	Serial0/2	172.31.2.4
lax	Serial0/3	san	Serial0/2	172.31.2.8
lax	Serial0/4	sba	Serial0/2	172.31.2.12

Finally, we need a neto file to pull these tables in; call it point-to-point.neto:

table devices.neto_table
table links.neto_table

Now, if you run 'ncg -k point-to-point.neto', you can see the list of keys created by this trio of files, and if you run 'ncg -d point-to-point.neto', you can see a dump of the fully-populated Netomata network model.

This is just a starting point, obviously. You've still got to populate the data tree with the rest of the information to describe your network, create templates, and so forth. But once you've done that, you can have NCG generate the configs for all of these devices, as well as for associated monitoring (via MRTG and Nagios, for example). You could look to the Web Hosting Example for a complete example.