Download CDP1

The Laboratory of Computer
Communication and Networking
Cisco Development Protocol
CDP1
Submitted by:
Michael Shmulyan skteddy@t2
Evgeny Kulikov stevgkul@t2
Ilya Raichman silyar@t2
What is CDP

CDP stands for Cisco Detection Protocol.
All Cisco devices support CDP because the
protocol is implemented in IOS (operating
system used on Cisco hardware).
CDP works above layer 2, thus can be used
before IP is configured.
How CDP works
All Cisco devices transmit once in a while
CDP packets, which contain information
about the device.
 These packets advertise a time-to-live value
in seconds, which indicates the length of
time that the receiver can hold the packet
before it must be discarded.

How CDP works(cont.)


CDP packets are sent with a time-to-live value that
is nonzero after an interface is enabled and with a
time-to-live value of zero immediately before an
interface is idled down. This provides for quick
state discovery.
All Cisco devices receive CDP packets and cache
the information in the packet. The cached
information is available to network management.
How CDP works(cont.)

Cisco devices never forward a CDP packet
so the information gathered is only about
devices with which we have layer two
connectivity, and not all the devices in the
network. If any information changes from
the last received packet, the new
information is cached and the older
information is discarded even if its time-tolive value has not yet expired.
Our Final Goal
Our goal was to implement a CDP protocol
for PC under Windows XP operating
system.
 We implemented user-friendly view of
information collected from the neighbor
devices (Such as real Cisco devices or other
PCs).

Our Final Goal (cont.)

As well as reading CDP packets from the
network, the product transmits CDP packets
either in:
Real mode
Simulation mode
Silent mode
Our Final Goal (cont.)
 Real
mode – the real information about the
PC.
 Simulation mode – distributing information
of inexistent virtual devices.
 Silent mode – sending nothing
Our Final Goal (cont.)
In Real mode the information is taken
directly from the operation system using
special purpose API, without the
involvement of the user.
 In Simulation mode – the user has an option
to choose how his PC will appear for the
other devices (as a router for example)
using nice GUI. User can store these
configurations and load them as needed.

Modules Description

Networking and connection

DATABASE

GUI
MODULES LAYOUT
Networking and connection


Receiver – implements a listener that is
responsible for receiving, validating and analyzing
CDP packets from the network and storing them in
DB.
Sender – is responsible for transmitting CDP
packets from this PC, this information may
represent true facts about the PC as well as made
up information in order to simulate other Cisco
devices and test our own system under different
conditions
DATABASE
Stores all the information collected by the
Receiver
 Our database is implemented as a delta queue in
order to minimize the number of timers running in
the system to one instead of a timer for every
device.
 There is a special thread, internal to the data base
module, which is responsible for cleaning it from
expired entries.
 The database holds internal Mutex to protect the
critical section of reading / writing to it.

GUI
Graphic User Interface is dialog-based MFC
application.
 Through the GUI user can:

• check current database state or/and his PC
settings and save it to file.
• switch between modes(simulating, real or
silent)
• set attributes for simulated CDP
packet(manually or load from the file)
THREADS
 There




are four main threads:
READER
PARSER
PACKET-BUILDER
WRITER
THREADS(cont.)




Reader-Parser threads pair:
The reader thread receives CDP packet from the
network and invokes the parser thread.
The reader thread filters traffic and verifies that
the packet it passes to the parser has CDP’s MAC
header.
Parser thread analyzes the packet and stores the
sending device info in the database, making it
available for the GUI to take for display.
THREADS(cont.)



There may be more than one reader thread, one for
every adapter that the computer has.
The reader thread listens on that adapter using
WINPCAP libraries and sends message to the
parser thread when a packet arrives.
There is only one parser thread, and it needs to do
much more complex operations than the reader
(such as parsing the raw buffer of bytes into a
device info, validating the checksum, and inserting
it to the data base).
THREADS(cont.)



Packet builder - Writer threads pair
Packet builder thread is responsible to create CDP
packets once in a needed time and invoke the
writer thread, which will send the packet on the
Ethernet by attaching an appropriate MAC
address.
The writer is not intelligent, it receives a buffer of
bytes and is responsible to send it to the network
(without even knowing what it was).
THREADS(cont.)



On the other side, the packet builder thread creates
a valid CDP packet out of information about
device, stored in the system (cdevice class).
Once in a predefined interval of time the packet
builder builds the packet and invokes the writer
thread to send it.
In order to prevent writers message queue from
overflowing, writer’s priority is higher than the
priority of packet builder.
THREADS(cont.)

There can be no deadlock in our system, (so no
other mechanisms of synchronization are needed)
because in each pair of thread there is a master
thread that gives orders to the slave thread.
INTERNAL INFO REPRESENTATION

CDP packets are binary, with variant field
length - which makes it harder to create and
parse them.

We want to save it (internally) in a more
accessible way, making it easier to display
and modify field info, however this way is
not that economical in place.
INTERNAL INFO
REPRESENTATION(cont.)

Our way to do this is CiscoDevice class that holds
complete information about one device, and
provides the functionality needed for a device
such as:
•
•
•
•
•
•
building it from a CDP packet
extracting CDP packet from a device
saving and loading device information from / to disk
selectively changing / adding / modifying fields
checking what fields (TLV) are present in a device
validating checksum of a packet
Modes Of Operation

There are three main modes of operation in our
system
 Silent Mode – nothing at all is being sent
 Real Mode – the real information about the PC is
distributed
 Simulation Mode – the user can configure a simulated
device, and other devices on a network will not see the PC
but a simulated device.
Modes Of Operation(cont.)



Real mode is a default mode, but the user can
switch the modes.
Simulation mode is limited in time by Simulated
Period setting. When entering the mode, the user
specifies for how long (in seconds) he wants to
simulate.
When the simulation period is over the system
automatically switches back to the Real mode and
notifies the user.
DIAGNOSTICS AND LOGGING




For diagnostics issues, our application maintains statistics
of valid packets versus broken packets that were received.
If more detailed information is needed about the events in
the network, the user may watch the log file, automatically
created by our application.
Any packet, either valid or broken, is recorded in the log
together with the time it was received and the MAC
address of the sender.
Our application simply appends all the info to the log file,
marking the beginning of a new session (activation of the
application).
WinPCap Usage




To execute actual CDP packets distribution and
sniffing (Level 2) we used WinPCap package.
The user is requested to install the package before
using the application.
All the interaction with WinPCap while running
the application is hidden from the user.
In a case of multiple adapters, configured on PC,
CDP packets are distributed on and collected from
every adapter
THE END
That’s all!
Hope you enjoy it!!
For more detailed information about the
project see FINAL REPORT!
Now it’s time to run CDP1!!!