[c-nsp] IMA Interface/PVC flapping issue

[Michael Nicks]

Anyone have any other insight into this problem? I've verified 
everyone's suggestions to no avail.

Thank you.
-Michael

-- 
Michael Nicks
Network Engineer
KanREN
e: mtnicks at kanren.net
o: +1-785-856-9800 x221
m: +1-913-378-6516



Mark Rogaski wrote:
> An entity claiming to be Michael Nicks (mtnicks at kanren.net) wrote:
> : I've had this PVC rebuilt probably 10 times already. I've had other PVCs 
> : on other equipment also rebuilt many times, to no avail. Regular ATM T1s 
> : terminated on the same physical path within the telco's network are not 
> : exhibiting these symptoms. Also this is not isolated to just one telco 
> : vendor, it's happening with every telco vendor that has provisioned IMA 
> : service for us.
> : 
> 
> Rarely does a PVC-level event impact port-level operation.  I suspect that
> the order of the log entries is just a minor timing issue with the
> logging.  I doubt that rebuilding the PVC will have any impact.  The 
> symptoms you are reporting match what you would expect with a timing issue.
> Here are some things to check.
> 
>   sh controller t1 0/0
>   sh controller t1 0/1
> 
> Make sure that you have line timing configured.  Look for slips or frame
> loss.
> 
>   sh network-clocks
> 
> Verify that one of the T1's is being used as a reference.
> 
>   sh ima int atm 0/ima0 detail
> 
> Verify that the clock mode is CTC.  Look for errors under group and link
> counters.
> 
> If your ticket with AT&T is being handled by the FR/ATM NOC or by Tier 3/4,
> you can ask to have them look at the following commands on the AUSM or MPSM
> card that the port is configured on.
> 
>   dspimainfo
>   dspimalncnt
>   dspimagrpcnt
> 
> Also, it might be worth dropping all but one line on an IMA group to see if
> you have the problem with a single-link IMA group.  If you don't and you
> don't see evidence of timing slips on the T1, that would isolate the issue 
> to the IMA layer.
> 
> Mark
>