[c-nsp] ATM OAM?

[Vincent De Keyzer]

Thanks to all who replied.

Vincent

> -----Original Message-----
> From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-
> bounces at puck.nether.net] On Behalf Of Mark Rogaski
> Sent: jeudi 6 octobre 2005 7:15
> To: cisco-nsp at puck.nether.net
> Subject: Re: [c-nsp] ATM OAM?
> 
> 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"
> []                       |