Vell, if he has 4 VC4 containers in some sort of LCAS configuration over different physical paths, it is possible for just one to go down. But more details would be welcome. Some sort of alarm on the SDH equipment should be visible in any case.
-- *blap* On Tue, Oct 26, 2010 at 13:41, Keegan Holley <[email protected]>wrote: > An STM is simply a group of time slots over the existing physical path. It > would be pretty strange for an STM to go down without the entire circuit > going down. Less strange would be misconfiguration, but that has all the > standard hooks. If you own the layer-1 equipment then change control > policies would help with this. I'm personally not aware of a way to > monitor > capacity from within the circuit without testing and trying to use all the > available bandwidth, which would defeat the purpose. > > > On Tue, Oct 26, 2010 at 1:56 AM, jack daniels <[email protected] > >wrote: > > > Hi guys, > > > > I have a EOSDH as a primary link in which GE is mapped to 4 STM-1 > > > > and backup path is another GE Link. > > > > In case 2 STM-1 out of 4 STM-1 in EOSDH fail my routing will not be > > aware of that and will not reroute the traffic to backup GE. > > This will lead to congestion on Primary link , while backup path not > > at all be used. > > Is there any way to work out this issue. > > _______________________________________________ > > cisco-nsp mailing list [email protected] > > https://puck.nether.net/mailman/listinfo/cisco-nsp > > archive at http://puck.nether.net/pipermail/cisco-nsp/ > > > > > > > _______________________________________________ > cisco-nsp mailing list [email protected] > https://puck.nether.net/mailman/listinfo/cisco-nsp > archive at http://puck.nether.net/pipermail/cisco-nsp/ > _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
