The MPLS-OPS Archive
[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index][Thread Index][Author Index][Subject Index]
RE: IMA E1 card and MPLS
-
From: <Alaerte.Vidali@nokia.com>
-
Date: Sun, 12 Nov 2006 14:20:57 -0600
-
Cc: <mpls-ops@mplsrc.com>
-
Resent-Date: Sun, 12 Nov 2006 15:48:09 -0500
-
X-Nokia-AV: Clean
-
X-OriginalArrivalTime: 12 Nov 2006 20:21:03.0594 (UTC) FILETIME=[1389C4A0:01C70698]
-
X-Scanned-By: MIMEDefang 2.53 on 209.239.41.31
-
X-Security: MIME headers sanitized on host.secure4-hosting.netSee http://www.impsec.org/email-tools/sanitizer-intro.htmlfor details. $Revision: 1.138 $Date: 2003-01-26 11:25:54-08
-
X-SpamProbe: GOOD 0.0000000 285cc262ddfe98f769320aab097a9ce5
Hi Shravan,
Have you migrated to IMA?
Br,
Alaerte
Thanks to Rajesh for Details on IMA.
From my experience, I know that E1s over multilinks can have lot of
issues while using mlppp. The root cause is the low resiliece of the E1 Links.
some times they may even flap during peak or bursty traffic. Juniper in their
latest releases showed good functionality during the flapping of E1s on
multilink. There were complaints from users at the sites still however the
multilink stayed up.
Even if you are upgrading your solution, it is a good idea to test your
problematic areas on the new setup before deploying.
On 11/6/06, rajesh.parikh@wipro.com <rajesh.parikh@wipro.com> wrote:
Hi,
A good IMA
solution compliant to the specification should take care of the condition you
mentioned. It should not matter at the MPLS layer
To explain
in few words...
IMA
protocol synchronizes on the ICP cells (OAM) for synchronization of frames and
it implements something known as IFSM (IMA frame synchronisation state
machine) to take care of TC/physical link anomalies. It also integrates any
phy layer faults/defects and has clearly defined primitives for initiating Far
End Reporting. For the condition mentioned by you, A link failure on one
of the links should not cause link failures/flaps on other links part of the
same IMA Group.
A flap on
the link once detected causes discard of cells during the anomaly period,
until either the link recovers or is declared to be in LIF state (Loss of IMA
frame). This triggers link to be declared as faulty by the IMA receiver who
initiates Far End Reporting and brings down the link from the IMA group
(aggregator).
Hope that
helps.
Cheers,
Rajesh
Hi,
Have you used MPLS over
IMA?
We have a network with E1
multilink but when there is a flapping on one link, the all multilink suffers.
We did a test bed to verify if Interface Damping could help, but it does not
work fine when the interface belongs to Multilink.
Now we are considering scalable
ATM IMA solution, using multiple E1 connections instead of OC-3 (I would
prefer OC-3 but it is not an option)
Did you know the behavior of IMA
card when there is a flapping on one of the E1 links?
Thanks, Alaerte
| |
|