[c-nsp] ATM OAM?

[Mark Rogaski]

An entity claiming to be Marko Milivojevic (markom at pangalactic.net) wrote:
:  > pvc alfonso816 9/816
: 
: 	Add: "oam-pvc manage" on both 7200's and you should be fine. As far as I 
: know, this is transparent for the switches.
: 
: 	What this will do, in very simple terms is that ATM subinterface will go 
: down if the underlying PVC goes down.
: 

There are a couple of options available with the oam-pvc directive.  Just
setting "oam-pvc" tells the router to respond to OAM per ITU-T's I.610.
IMHO, this should always be enabled.  With this in place, the router will
pay attention to OAM AIS and RDI cells.  If there is a failure that
generates a alarm in the cloud the router should get and integrate the
alarm.

But, things aren't always quite so simple.  There's always an instance of a
component that fails silently or a DIE (disconnect in error) that may no
trigger the generation of AIS or RDI cells.  In this case, you may want to
use "oam-pvc manage" which can be enabled on either one side or both sides.  
This configures the router to send out an OAM loopback cell on some interval,
10 seconds by default.  The router at the remote end must have at least 
"oam-pvc" enabled so it will respond to the loopback cells. 

While Cisco's docs give examples of reducing the interval to 3 seconds, be
careful.  If you have a fat pipe with thousands of PVC's, the loopback
cells are sent in batches and OAM is often handled in a separate (and much
smaller) queue than normal user traffic.  If you have thousands of PVC's
all sending loopback cells at the same time, some cells could be dropped
and some false failures could occur.  While "oam-pvc manage" is
theoretically transparent, the implementation makes it a bit murky.

Another nice thing about "oam-pvc manage" is that, with most carriers, it
works for a FR/ATM Service Interworking PVC.  The FR/ATM IWF will usually
respond to OAM loopback cells.  But this isn't always reliable.  Some of 
Cisco's FRSM cards throw some junk into the reserved fields of the loopback
responses that will seriously disturb your calm if you have a LS1010
sitting between your ATM router and the cloud without "no oam intercept"
set.  The bottom line in "oam-pvc manage" is:  it's _very_ useful, but it's
been know to cause some nasty false failures.

Last of all is "oam-pvc manage cc".  This sends OAM CC cells instead of
loopback cells, which act as heartbeats.  If the remote end doesn't get a
CC cell within a specified interval, it declares the PVC failed.  This came
in 12.2(13)T, and I've never seen it in the wild.  Some carriers will pass
OAM CC cells, but you PVC's my need to be reengineered.  There are
applications for this type of OAM, but they are few and far between.

Mark 

-- 
[]                       |     "I've lost my equilibrium, my car keys,
[] Mark Rogaski          |     and my bride.  The tattoo parlor was warm,
[] wendigo at pobox.com     |     so I hustled her inside."
[] mrogaski at cpan.org     |     -- Tom Waits, "The One That Got Away"
[]                       |
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : https://puck.nether.net/pipermail/cisco-nsp/attachments/20051006/6ec997b6/attachment.bin