From: Brian McGahan (bmcgahan@internetworkexpert.com)
Date: Wed May 03 2006 - 12:11:07 ART
Just configure the main site with IP SLA to send ICMP pings to
the remote sites based on whatever interval is appropriate. If the ICMP
ping fails based on the number of times you define you can generate an
SNMP trap.
http://www.cisco.com/univercd/cc/td/doc/product/software/ios124/124cg/hs
la_c/hsicmp.htm
http://www.cisco.com/univercd/cc/td/doc/product/software/ios124/124cr/hs
la_r/sla_01h.htm#wp1037845
HTH,
Brian McGahan, CCIE #8593
bmcgahan@internetworkexpert.com
Internetwork Expert, Inc.
http://www.InternetworkExpert.com
Toll Free: 877-224-8987 x 705
Outside US: 775-826-4344 x 705
24/7 Support: http://forum.internetworkexpert.com
Live Chat: http://www.internetworkexpert.com/chat/
> -----Original Message-----
> From: Todd.Osterberg@compucom.com [mailto:Todd.Osterberg@compucom.com]
> Sent: Wednesday, May 03, 2006 9:42 AM
> To: Brian McGahan; ccielab@groupstudy.com
> Subject: RE: SP Question
>
> I understand where you're coming from with watching layer 3 because if
> layer 2 breaks, so will layer 3. With OAM we wanted to avoid having a
> one-sided connection in the event of a frame site failure. Not that I
> trust telcos (grin) but they assured me that OAM would fit the bill.
>
> Circuit status is polled and trapped via snmp.
>
> Todd
>
> -----Original Message-----
> From: Brian McGahan [mailto:bmcgahan@internetworkexpert.com]
> Sent: Wednesday, May 03, 2006 6:26 AM
> To: Osterberg, Todd (tosterbe); ccielab@groupstudy.com
> Subject: RE: SP Question
>
> Todd,
>
> Think about it this way, what exactly are you trying to
> accomplish by running OAM? You want to track the circuit status
right?
> If the circuit status is down what do you do? Are you polling it or
> trapping it via SNMP? Other solutions come to mind such as the IP SLA
> (RTR, SAA) that will allow you to accomplish the same thing. The main
> difference is that you will be tracking the layer 3 status (i.e. IP
> connectivity) instead of the layer 2 status. You can still trap or
poll
> these results via SNMP.
>
>
> HTH,
>
> Brian McGahan, CCIE #8593
> bmcgahan@internetworkexpert.com
>
> Internetwork Expert, Inc.
> http://www.InternetworkExpert.com
> Toll Free: 877-224-8987 x 705
> Outside US: 775-826-4344 x 705
> 24/7 Support: http://forum.internetworkexpert.com
> Live Chat: http://www.internetworkexpert.com/chat/
>
>
> > -----Original Message-----
> > From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf
> Of
> > Todd.Osterberg@compucom.com
> > Sent: Tuesday, May 02, 2006 11:08 PM
> > To: ccielab@groupstudy.com
> > Subject: SP Question
> >
> > I had a client experience an outage on two ATM DS3 circuits this
> weekend
> > and the telco did something very interesting. Both of these
circuits
> > have been up for nearly two years without any downtime. The telco's
> > story is that one of their atm switches (lucent) was eating
linecards
> > and that the only card they had left had been installed and was
> working.
> > Well, our client still didn't have connectivity. More about these
> > circuits... we're using frame-relay service interworking to support
22
> > remote sites with frame and the head-end is ATM. Again, this has
been
> > working fine for nearly two years without any issue at all. So I do
> > some debug and come to find out, the atm switch is no longer sending
> OAM
> > cells back to us. Turns out the line card that the telco installed
> > didn't support OAM. Once the OAM config line was removed from 22
> PVCs,
> > things started to work just fine. So here is my real question...
> >
> >
> >
> > In a service interworking environment, how important is OAM? Since
> > there isn't end-to-end ATM, does OAM really buy you anything? Mind
> you,
> > I've got a meeting set with the telco sales rep to discuss this
> > situation. Neither my client, nor I am happy that we needed to
change
> > the clients config to help resolve a telco outage. Anyone else run
> into
> > a situation like this? Anyone else running OAM with service
> > interworking?
> >
> >
> >
> >
> >
> > Todd
> >
> >
> >
> >
> >
> > Todd Allen Osterberg
> > Senior Consultant, Professional Services US Western Region
> >
> > CompuCom
> > eMail: todd.osterberg@compucom.com
> > T: (916) 577-1066
> > C: (916) 316-4650
> > www.CompuCom.com
> >
>
<outbind://4-0000000078027C4F809C5F448BBD4AD06CC1CD9207005BA671B4ADEFD54
> >
>
18728E128462975250000000D51F50000B7CF08D69463BB4FA89400956DFA551A0000010
> > 7CF9A0000/exchweb/bin/redir.asp?URL=http://www.CompuCom.com>
> >
> >
>
This archive was generated by hypermail 2.1.4 : Thu Jun 01 2006 - 06:33:20 ART