Switch Network Configuration Table

Now that the router network configuration table is complete, let’s move on to the switch
version of this table. More information on switches and switch commands is provided in
Chapter 41, “Troubleshooting Switched Ethernet.” As stated in the preceding section, in this
example we are assuming that there are about 20 switches in the network for which we are creating
documentation. In addition, we are working with switches that have only layer 2 functionality.
Based on this arrangement, we have decided to include the following list of items in
our switch network configuration table:
 Device Name
 Model #
 Location
 Flash

 DRAM
 CatOS Version
 Management Address
 VTP Domain
 VTP Mode
 Port Number
 Port Speed
 Port Duplex
 VLAN
 Spanning Tree Protocol (STP) State
 Portfast Status
 Trunk Status
The beginning of the switch network configuration table is shown in Figure 34.2.
As was the case with the network configuration table for routers, just a few commands are
needed to populate the table produced for the switches. Specifically, these commands are
 show version
 show interface
 show vtp domain, show port
 show trunk
 show spantree vlan
Note that the preceding are CatOS commands. The IOS equivalents of these
commands are show version, show interface, show vtp status, show
interface, show interfaces trunk, and show spanning-tree vlan, respectively.
More information about the differences between CatOS and IOS are
covered in Chapter 41.

The first of these commands, show version, operates similarly to the same command in the
router. It produces a number of the elements that are needed in order to populate the switch network
configuration table:
core_switch> (enable) show version
WS-C6509 Software, Version NmpSW: 6.4(3)
Copyright (c) 1995-2003 by Cisco Systems
NMP S/W compiled on Apr 10 2003, 17:33:25
System Bootstrap Version: 5.3(1)
Hardware Version: 2.0 Model: WS-C6509 Serial #: SCA123456F
PS1 Module: WS-CAC-1300W Serial #: SON01234564
PS2 Module: WS-CAC-1300W Serial #: SON01234569
Mod Port Model Serial # Versions
--- ---- ------------------- ----------- ----------------------------
1 2 WS-X6K-SUP1A-2GE SAD05430RPV Hw : 3.2
Fw : 5.3(1)
Fw1: 5.1(1)CSX
Sw : 6.4(3)
Sw1: 6.4(3)
WS-F6K-PFC SAD05430LYJ Hw : 1.1
3 48 WS-X6248-RJ-45 SAD04330N7Z Hw : 1.2
Fw : 5.1(1)CSX
Sw : 6.4(3)
7 24 WS-X6324-100FX-MM SAD0234523C Hw : 1.3
Fw : 5.4(2)
Sw : 6.4(3)
8 8 WS-X6408A-GBIC SAL43566W9J Hw : 2.0
Fw : 5.4(2)
Sw : 6.4(3)
DRAM FLASH NVRAM
Module Total Used Free Total Used Free Total Used Free
------ ------- ------- ------- ------- ------- ------- ----- ----- ----
1 65408K 48425K 16983K 16384K 9568K 6816K 512K 310K 202K
Uptime is 55 days, 11 hours, 28 minutes


As you can see in the underlined output, the show version command provides the CatOS
level of the switch, as well as the flash and DRAM information.
The next command, show vtp domain, reports both the VTP domain and the VTP mode of
the switch. (VTP [VLAN Trunk Protocol] is covered in more detail in Chapter 41.)
core_switch> (enable) show vtp domain
Domain Name Domain Index VTP Version Local Mode Password
----------------------- ------------ ----------- ----------- ----------
dover_core 1 2 Transparent -
Vlan-count Max-vlan-storage Config Revision Notifications
---------- ---------------- --------------- -------------
13 1023 0 enabled
Last Updater V2 Mode Pruning PruneEligible on Vlans
--------------- -------- -------- -------------------------
10.40.40.2 disabled disabled 2-1000
Once you have obtained the VTP data, the next piece of information needed is the management
interface IP address. This address is included as part of the output from the show interface command.
Notice that on a switch, the command displays far less information than for routers and
focuses only on the management interfaces, not on the user ports.
core_switch> (enable) show interface
sl0: flags=51
slip 0.0.0.0 dest 0.0.0.0
sc0: flags=63
vlan 2 inet 10.40.40.2 netmask 255.255.255.252 broadcast 10.40.40.3
By using a separate VLAN for the management VLAN, we ensure that management
traffic to or from the switch will not be directly affected by user traffic, and
vice versa. For further protection, a separate uplink instead of a common trunk
can be used for the management VLAN, as is shown in this example.
The next command that is used to populate the switch network configuration table is the show
port command, which provides a substantial amount of fairly concise information about each port
on the switch. Be aware, however, that the output can get very lengthy if there are a large number
of ports on the switch. For the purpose of the switch network configuration table, the port numbers,
VLAN (for nontrunked ports), duplex, and speed information can be obtained from this output:
core_switch> (enable) show port
Port Name Status Vlan Duplex Speed Type
----- ----------------- ---------- --------- ------ ----- -----------
1/1 core_switch_2 connected trunk full 1000 1000BaseSX


1/2 core_switch_2 connected trunk full 1000 1000BaseSX
3/1 server1 connected 45 full 100 10/100BaseTX
3/2 mgmt_tool1 connected 45 half 10 10/100BaseTX
3/3 server3 connected 45 a-full a-100 10/100BaseTX
3/4 notconnect 45 auto auto 10/100BaseTX
3/5 notconnect 45 auto auto 10/100BaseTX
3/6 notconnect 45 auto auto 10/100BaseTX
...
...

The output removed from the foregoing show port command includes more
than just additional port numbers, names, status, VLAN, duplex, speed, and
type. It contains packet statistics, error rates, security parameters, and much
more. This information was not shown here because it does not directly relate
to the switch network configuration table.
Because the VLAN information is not included in the output of a show port command for
a trunked port, we need to get this data in another manner. There are a couple of ways to get
this information, but the usual method is via the show trunk command:
core_switch> show trunk
* - indicates vtp domain mismatch
Port Mode Encapsulation Status Native vlan
-------- ----------- ------------- ------------ -----------
1/1 nonegotiate dot1q trunking 45
1/2 nonegotiate dot1q trunking 45
Port Vlans allowed on trunk
-------- -------------------------------------------------------------
1/1 1-2,45-46
1/2 1-2,45-46
Port Vlans allowed and active in management domain
-------- -------------------------------------------------------------
1/1 1-2,45-46
1/2 1-2,45-46
Port Vlans in spanning tree forwarding state and not pruned
-------- -------------------------------------------------------------
1/1 1-2,45-46
1/2 1-2,45-46

The VLANs that traverse the trunk are shown in the Vlans allowed on trunk section
of this output. If a VLAN is not listed in this section, then it will not be permitted on
the trunk.
The final command necessary to complete the information in the switch network configuration
table is the show spantree vlan command. In our case, we need information regarding
VLAN 45, the VLAN in which our servers reside.
core_switch> show spantree 45
VLAN 45
Spanning tree mode PVST+
Spanning tree type ieee
Spanning tree enabled
Designated Root 00-d0-f6-bc-aa-aa
Designated Root Priority 49152
Designated Root Cost 3004
Designated Root Port 1/1
Root Max Age 20 sec Hello Time 2 sec Forward Delay 15 sec
Bridge ID MAC ADDR 00-d0-f6-bc-7e-00
Bridge ID Priority 49152
Bridge Max Age 20 sec Hello Time 2 sec Forward Delay 15 sec
Port Vlan Port-State Cost Prio Portfast Channel_id
---------------- ---- ------------- --------- ---- -------- ----------
1/1 45 forwarding 4 32 disabled 0
1/2 45 blocking 4 32 disabled 0
3/1 45 forwarding 19 32 enabled 0
3/2 45 forwarding 100 32 enabled 0
3/3 45 forwarding 19 32 enabled 0
3/4 45 not-connected 19 32 disabled 0
3/5 45 not-connected 19 32 disabled 0
3/6 45 not-connected 19 32 disabled 0
...
...

Notice that this command provides the necessary information to complete the STP State and
the Portfast configuration columns of the table.
When both the router and switch network configuration tables are complete, we can move
on to creating the network topology diagrams.

1056

Router Network Configuration

Now that we have discussed the basis for what goes into a network configuration table, let’s go
through a couple of examples. We will first create the template for what we are looking for, and
then step through the gathering of the necessary information. For these examples, we will first
create a separate network configuration table for routers and one for switches. The network
itself in this example is a small one, containing fewer than 15 routers and 20 switches.
Based on this information, we have decided to include the following list of items in our router
network configuration table:

Device Name

Model #

Location

Flash

DRAM

IOS Version

Interface Name

MAC Address

Subnet

Subnet Mask

IP Address

Routing Protocol
The start of the router network configuration table is shown in Figure 34.1. As you can see
in the figure, part of the information has already been entered for our example. This information
was gathered through a series of
show
commands run on each router. Specifically, the commands
used were

show version

show ip interface brief

show interface

show ip protocols

show ip interface

Though the information in the first two columns of the sample network configuration table
can be obtained through some
show
commands (assuming the
location
or
snmp location
options are set in the router), in our example, as well as in most real-world scenarios, they are
already known by the network administrator doing the work. The next three columns in our
example—Flash, DRAM, and IOS—are all obtained by using the
show version
command:
salmon>
show version
Cisco Internetwork Operating System Software
IOS (tm) C2600 Software (C2600-JS-M), Version 12.0(12), RELEASE SOFTWARE (fc1)
Copyright (c) 1986-2000 by cisco Systems, Inc.
Compiled Tue 11-Jul-00 10:09 by htseng
Image text-base: 0x80008088, data-base: 0x80B1468C
ROM: System Bootstrap, Version 11.3(2)XA4, RELEASE SOFTWARE (fc1)
salmon uptime is 3 days, 20 hours, 48 minutes
System restarted power on
System image file is "flash:c2600-js-mz.120-12.bin"
cisco 2610 (MPC860) processor (revision 0x203) with 39936K/9216K bytes
➥
of memory.
Processor board ID JAD04430NYN (832809334)
M860 processor: part number 0, mask 49
Bridging software.
X.25 software, Version 3.0.0.
SuperLAT software (copyright 1990 by Meridian Technology Corp).
TN3270 Emulation software.
Basic Rate ISDN software, Version 1.1.
1 Ethernet/IEEE 802.3 interface(s)
2 Serial(sync/async) network interface(s)
1 ISDN Basic Rate interface(s)
32K bytes of non-volatile configuration memory.
16384K bytes of processor board System flash (Read/Write)
Configuration register is 0x2102


The flash information is shown at the bottom of the
show version
output, the DRAM is in
the middle, and the IOS is at the top. One item to note is that because the 2610 is a shared memory
router, the DRAM information here is divided into two categories, separated by a slash
character. The first number represents the local memory on the router, and the number on the
right-hand side of the slash represents the I/O memory on the router. The local memory is used
for items such as holding the running IOS, whereas the I/O memory is used for buffers and similar
input and output functions.
To obtain the interfaces that are active on the router, as well as the IP addresses that are
assigned to these interfaces, the
show ip interface brief
command is used:
salmon#
show ip interface brief
Interface IP-Address OK? Method Status Protocol
Ethernet0/0 10.254.254.1 YES NVRAM up up
Serial0/0 10.10.10.1 YES NVRAM up up
Serial0/1 unassigned YES unset administratively down down
Once you have determined which interfaces are used on the router, you can execute the
show
interface
command to get the MAC addresses of the interfaces and the subnet information:
salmon#
show interface e0/0
Ethernet0/0 is up, line protocol is up
Hardware is AmdP2, address is 0004.4d65.b9c0 (bia 0004.4d65.b9c0)
Internet address is 10.254.254.1/24
MTU 1500 bytes, BW 10000 Kbit, DLY 1000 usec, rely 255/255, load 1/255
Encapsulation ARPA, loopback not set, keepalive set (10 sec)
ARP type: ARPA, ARP Timeout 04:00:00
Last input 00:00:00, output 00:00:00, output hang never
Last clearing of "show interface" counters never
Queueing strategy: fifo
Output queue 0/40, 0 drops; input queue 0/75, 0 drops
5 minute input rate 0 bits/sec, 0 packets/sec
5 minute output rate 0 bits/sec, 0 packets/sec
27067 packets input, 3624228 bytes, 0 no buffer
Received 27067 broadcasts, 0 runts, 0 giants, 0 throttles
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
0 input packets with dribble condition detected
39804 packets output, 3815083 bytes, 0 underruns
0 output errors, 0 collisions, 0 interface resets
0 babbles, 0 late collision, 0 deferred
0 lost carrier, 0 no carrier
0 output buffer failures, 0 output buffers swapped out


In looking at the output of the
show interface
command, notice that following the MAC
address is the output
(bia 0004.4d65.b9c0)
. The
bia
stands for burned-in address and is the
MAC address that was assigned by Cisco to the interface. The BIA is usually, but not always,
the MAC address that is used on the interface. Specifically, by using the interface-level
macaddress
command, a network administrator can set the MAC address used to any value considered
appropriate.
The final command we’ll examine that is used to populate the network configuration table
is show ip protocols:
salmon#show ip protocols
Routing Protocol is "eigrp 200"
Outgoing update filter list for all interfaces is
Incoming update filter list for all interfaces is
Default networks flagged in outgoing updates
Default networks accepted from incoming updates
EIGRP metric weight K1=1, K2=0, K3=1, K4=0, K5=0
EIGRP maximum hopcount 100
EIGRP maximum metric variance 1
Redistributing: eigrp 200
Automatic network summarization is in effect
Routing for Networks:
10.0.0.0
Routing Information Sources:
Gateway Distance Last Update
Distance: internal 90 external 170
The preceding command tells you the routing protocol that is active on the router, as well as
the networks this routing protocol is used for.
One command that was not demonstrated in our example is often used in creation of network
configuration tables: the show ip interface command. In addition to the standard IP
address information, this command provides a wealth of other information such as whether or
not access lists are applied to the interface, the switching methodology of the interface, and
whether or not there is a helper address assigned. Here is a sample output of the show ip
interface command:
salmon#show ip interface e0/0
Ethernet0/0 is up, line protocol is up
Internet address is 10.254.254.1/24
Broadcast address is 255.255.255.255
Address determined by non-volatile memory
MTU is 1500 bytes
Helper address is not set
Directed broadcast forwarding is disabled

Multicast reserved groups joined: 224.0.0.10
Outgoing access list is not set
Inbound access list is not set
Proxy ARP is enabled
Security level is default
Split horizon is enabled
ICMP redirects are always sent
ICMP unreachables are always sent
ICMP mask replies are never sent
IP fast switching is enabled
IP fast switching on the same interface is disabled
IP Flow switching is disabled
IP Fast switching turbo vector
IP multicast fast switching is enabled
IP multicast distributed fast switching is disabled
IP route-cache flags are Fast
Router Discovery is disabled
IP output packet accounting is disabled
IP access violation accounting is disabled
TCP/IP header compression is disabled
RTP/IP header compression is disabled
Probe proxy name replies are disabled
Policy routing is disabled
Network address translation is disabled
Web Cache Redirect is disabled
BGP Policy Mapping is disabled

Network Configuration

Network Configuration Table
The general purpose of a
network configuration table
is to give a listing of the hardware and
software components used in the network. This information will be used in the course of troubleshooting
to ensure that the functioning of the network is well understood. At a minimum, a
network configuration table should include the name of the network device, the layer 2 addresses
and implemented feature sets, and the layer 3 addresses and implemented features. In addition
to these items, you should include any additional information about layers 4 through 7 that is
deemed important (for instance, extended access lists and application flow details). Finally, all of
the specifics about the physical devices should be recorded (their location in the computer room,
their UPS circuit information, and so forth).
One of the most common ways to determine the specific items that will go into your network
configuration table is to divide the types of information being observed into groups corresponding
to the layers of the OSI model. Some items, such as name of the device, do not necessarily
fall in a particular layer, but these can be incorporated as part of the Physical layer or placed in
a separate column. A sample list of items that can be included in a network configuration table
is shown in Table 34.1.
Once you have identified the information that you will put in your network configuration
table, the next step is organizing this information in a logical and repeatable sequence. When
planning the organization of this information, you must take into account all the device types
that are in the network as well as the needs of each of these devices. Due to the variation in the
requirements for different types of network devices such as switches and routers, in many cases
you will need a different table structure for each major classification of device. For example, in
most instances, there will be one set of information gathered for routers and a separate set of
information for switches. This separation prevents a lot of unnecessary fields that are left empty
because they do not apply. By separating these information groups, you can simplify the overall
network documentation.

If you do decide to separate switches from routers in your network documentation,
be sure to have a plan for how to account for devices that do
both
routing
and switching. You might create both a routing and a switching document
for such devices. Alternately, you could create a third set of documentation
specifically for these types of devices.
In most cases, the preferred manner to store this information is in a spreadsheet or database.
For smaller networks, a spreadsheet is usually the preferred method due to its low cost and ease
of use. For large networks, a database is the preferred arrangement because of its flexibility, and
it lets you better manage large volumes of data. For both of these means of storage, hard copies
of the information should be maintained in addition to the electronic versions. This paper documentation
may be critical during a network outage, when the information contained in the network
configuration table will be most useful and you may not be able to access the online version.

The Network Baseline

The easiest way to solve network problems is to be able to compare current configurations
against previous configurations. This sounds easy enough, but it requires a lot of effort to get
a system established for keeping a historical
baseline
of your network. A historical
baseline is
simply a collection of network settings and configurations that are maintained over time. This
baseline makes it easy to locate changes and identify the differences between a current configuration
and a previous one.
A network baseline is sometimes referred to as a baseline network model.
Baseline information is actually a composite of various network and end-system documentation.
This collection includes

Network configuration table

Network topology diagram

End-system network configuration table

End-system network topology diagram
The first two items—the network configuration table and the network topology diagram—
are covered in this chapter. The latter two items—the end-system network configuration table
and the end-system network topology diagram—are discussed in Chapter 35, “End-System
Documentation and Troubleshooting.”

When creating any documentation of this sort, there are several things to keep in mind:

First, before you start, determine the scope of what the documentation should cover. Without
clearly understanding what is inside and outside of the scope of the documentation
effort, you could end up taking on more than you bargained for.

The second rule is to be consistent. If you do not collect the same information for all the
devices in the network, the documentation may have holes that will come back to haunt
you later.

Third, know your objective. When you are collecting your information, be certain you
understand what the documentation will be used for, and include all relevant pieces.

Be sure to use the documentation and ensure that it is accessible in the event of an emergency.
This information was not put together just as an exercise; it is meant to be useful.

Finally, after putting together your baseline information, you must maintain it. If the baseline
is out-of-date, troubleshooting will be much more difficult.
After you your start using the documentation, if you are finding that you are consistently
going back to the network devices to find a particular bit of information, it may be a good idea
to include that information on your baseline. Likewise, if you notice that you are never using
certain information, it may be best to remove that data from the baseline documentation to prevent
clutter.