Up: OSPF Monitoring: Architecture, Design
The LSAR captures LSAs from the network for real-time and off-line
analysis. LSA traffic is reliably flooded by OSPF, not routed since LSAs
need to be reliably communicated even when routing is impaired or broken.
As a result, the LSAR has to be closely attached to the network it monitors.
There are four choices for network attachment.
Below, we describe these four choices along with their pros and cons:
- Wire-tap mode:
An obvious way of capturing LSAs from a network
is to use a tap on a link of the network,
either a physical tap or port forwarding on a layer-2 switch.
We will generically refer to this way of capturing LSAs as
the wire-tap mode.
If done in the right manner, this allows
one to capture LSAs in a completely passive manner.
However, depending on the physical media or the layer-2
technology being used, wire-tapping may not be
As a result, the LSAR currently does not support wire-tap, though
it should be relatively straight-forward to add a module that
supports LSA capture via wire-tap.
- Host mode:
LSAs are exchanged via a multicast group all-rtrs
on a broadcast network .
Thus, on broadcast networks, LSAs
can be received by joining this group;
we term this mode of network attachment as the host mode.
In this mode, the LSAR does not have to establish any form of adjacency
with operational routers in the network.
As a result, the LSAR is completely invisible
to the routers, which is the ideal situation
for any passive monitoring system.
However, there are a few disadvantages.
First, the LSAR has to initialize the database as routers flood
LSAs on the network during the refresh process.
In the worst case, it can take
one refresh cycle (30 minutes as per )
for the LSAR to receive the first copy of an LSA after it comes up.
Second, OSPF's reliable flooding does not extend to the LSAR
in the host mode. If the LSAR misses transmission of an LSA to
the multicast group for any reason, the sending router will
be unaware of this, and there will be no retransmission.
Finally, the host mode can be used only on a broadcast
capable media where LSAs are sent to the multicast group.
- Full adjacency mode:
On a point-to-point link where routers do not send LSAs to
the multicast group, the LSAR has to establish an adjacency with
a router to receive LSAs.
We will refer to this mode as the full adjacency mode.
In this mode, the LSAR cannot be completely
invisible to the network. However, it is crucial to
ensure that the LSAR has minimal impact on the network,
and most importantly, other routers in the network never
send data packets to the LSAR to be forwarded elsewhere.
A natural line of defense is to use router
configuration measures: assign high OSPF weights and
install strict access control lists and route filters
on the link to the LSAR.
Another line of defense stems from the fact that the
LSAR (by design) cannot send LSAs.
As a result, the link from the LSAR to
the router it attaches to does not exist in the OSPF topology graph.
Since OSPF uses a link for data forwarding only if both of its
unidirectional edges exist in the graph ,
this ensures that the LSAR-router link cannot be used for data forwarding.
However, the LSAR might still have an impact on the network
since the router advertises a link to the monitor in its router LSA.
If the LSAR or its link with the router
is flapping (going up and down), the associated
adjacency can start flapping, triggering SPF calculations around the
- Partial adjacency mode:
To prevent network-wide SPF calculations when the adjacency
between the LSAR and the router is flapping in the full adjacency mode,
we can keep the adjacency in an ``intermediate'' state at
the router, so that the router does not include a link to the LSAR
but still sends LSAs to it.
We refer to this mode as the partial adjacency mode.
To keep the LSAR-router adjacency in the intermediate state, the
LSAR describes a ``fake'' LSA to the router during the link state database
synchronization process but never actually sends it out to the router.
As a result, the database is never synchronized, the adjacency stays in OSPF's
loading state, and is never fully established.
Note that this is permissible under the
OSPF specification .
With the partial adjacency,
instability at the LSAR does not impact other routers in the network,
which makes for an attractive choice.
However, there are two potential issues.
First, with an adjacency in the intermediate state,
the router cannot delete LSAs from its link state database .
In the worst case, this might lead to memory exhaustion on the router.
We deal with this problem by periodically dropping the partial
adjacency (so that the router has a chance of garbage collecting the
link state database) and then re-establishing the partial adjacency after a short
In our implementation, the LSAR drops its adjacency
once every 24 hours for a five second period.
While there is a possibility for the LSAR to lose data during this five second
period, we believe that chances of this happening are rare.
Second, the use of the partial
adjacency is a deviation from the normal behavior of OSPF. Keeping an
adjacency in the loading state on a router for a long time might
generate alarms, or might cause the router to drop the adjacency.
However, we have not observed this problem with the commercial routers
we have tested.
Up: OSPF Monitoring: Architecture, Design