Ascend Archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: (ASCEND) Ascend Frame relay Problem
James Voyes said:
>Has anyone out there Had a problem with Frame Relay where if you loose the
>host site , You also loose all Remotes. The problem we are seeing is if the
>host side goes down we loose all the remotes and when the host side comes up
>the remotes do not recover on there own. They have to be power cycled in
>order to recover. Anyone!
Been there, done that, still have the emotional scars
from a small network of 10 Pipeline 130s "hosted" by
a Cisco router.
From what we have seen from local laptops plugged into
the P130s that are "down", the specific P130s >>DO<< see
the LMI packets from the frame relay switch, and >>DO
NOT<< have an alarm condition. We have seen a lack of
incrementing in the transmitted packet counts on
occasion.
The FNIDs to which the Pipelines are connected also
show no error lights, but these are very primitive
(nearly obsolete, in my view) devices.
Since the majority of these outages have been due to
power flickers at the customer site (out core sites
never go down), we expect that there is some strange
power-up sequence incompatibility between the P130
and the FNID.
We have found that, in some cases, power-cycling the
FNID will fix the problem, where in others, power
cycling the FNID is not enough, and the P130 must
also be power-cycled. The lack of a consistent
scenario is problematic.
There is no ISDN service in the area in question, so
dial-back-up is impossible in these cases.
What I would suggest would be:
a) Send your own people on site, and
see what the pipeline says to a laptop
plugged into the console port. If you have
an alarm condition, you have a "properly
working P130 (or whatever)", and a beef with
the telco.
b) Check the telco interface device. PairGains
also have a serial port suitable for plugging
a laptop into to see status. The lights should
tell most of the story.
c) Try power-cycling the telco customer-premise
equipment (FNID, PairGain, whatever), and wait
3 mins before doing anything else (Frame Relay
DLCIs can require up to 2 mins to "recover"
once LMI packets start flowing again).
d) Ask the telco to overtly send some LMI packets
downstream from the frame relay switch in the
reverse of the "normal" situation. This is
fairly easy to do, and can be used to verify
that the Pipeline "sees" the packets.
In our case, the majority of the outages "went away",
after about 6 months of daily problems. We therefore
tend to lay "blame" at the feet of the telco, even if
the solution was to upgrade the Ascend/Cascade frame
relay switch code.
My resulting opinions would be one or more of:
1) FNIDs suck. PairGains rule.
2) Ascend has(had) an initialization problem with
the P130, and/or the Cascade switches, a problem
that they have denied to date.
3) It is possible to train non-technical customer
staff to be decent "field techs", and they can
be of great help in debugging such a problem
once given some clear instruction about status
lights, telnet, Pipeline status screens, etc.
4) It is never possible to get the telco frame
relay switch admin and Ascend on the phone
at the same time due to the Hisenberg Uncertainty
Principle, so make it clear to the telco
that you expect THEM to address the problem
with Ascend/Cascade. They likely buy more
toys from Ascend/Cascade than you do, so
perhaps they will get more respect/attention.
Who Knows What Evil Lurks In The Heart of MENSA?
james fischer jfischer@supercollider.com
++ Ascend Users Mailing List ++
To unsubscribe: send unsubscribe to ascend-users-request@bungi.com
To get FAQ'd: <http://www.nealis.net/ascend/faq>