Hi, this is a lengthy and mostly polemic text. However, I would still appreciate if one or the other ascend engineer reads it, even if I may tend to some bashing here. All this is about is the Ascend family and the handling of leased (nailed) lines with several units of this family (more exactly, the Pipeline and Max family). IMHO there are severe bugs and insufficiencies in this area, so I'll list them. 1) Low level bundling It appears that all Ascend units that deal with BRI or PRI interfaces are able to handle low level bundling of a selection of B channels of such interface to build a bigger pipe. This feature is, however, not proactively documented, so using it remains guesswork. a) BRI Interfaces The Max (and the Pipe400) bundle the 2 B channels of a BRI by plugging the Bs into the same nailed group. This concept remains on the whole family, i.e. a nailed group is a name for a big pipe made up from low level bundling of B channels, for exactly one B channel or another kind of interface (serial WAN). The bad thing is that the sequencing of the bundling is not documented. I was told that it is B1B2B1B2 in every S0 frame (assume that I've read I.430 and understand at least the sections necessary for this discussion). The Pipe50 can handle the same style of bundling, however it is circumclouded with a lot of mysticism of some Zen nature (the typical sentence when you ask about it is "This feature is only available in Japan"). The feature is called SuperDig128 and is documented even less than the Max nailed group stuff. Nevertheless, if all goes well a P50 can connect to a Max1800 with SuperDig128 - so I assume the same bundling is used (B1B2B1B2). The big problem with BRI low level bundling is that it doesn't work if the B channels are not octet synchronous, bad enough this seems to be the normal case here in Germany. Our lab lines are always sync, telcos are never. So this feature is not useable, we need high level bundling to do 128kbps with 2 Bs. This is impossible simply because the P50 wont do Leased/Leased - a FR is open for this since months but the feature didn't appear yet. b) PRI Interfaces PRI can be bundled in the same way as BRI - plug any selection of Bs into a nailed group and it works. This is easy to test with a cross- over E1 cable (dunno for T1, may be as simple). But here too, the mechanism is not documented. However, anything but using the Bs in native timeslot order would be nonsense. This is also proven by the fact that an E1 that bundles all 31 channels into one group works flawless against an E1 CSU/DSU which has never heard of Ascend (I've read I.431, too). The drawback of using Net/E1 as leased lines by bundling all B channels is the enourmous loss of HDLC processors - one per channel. And HDLC cards are not that cheap. Conclusion: Low level bundling is there and works, but is insufficiently documented and has some drawbacks and myths. Why I'm telling this whole pletora ? See next chapter. 2) High level bundling Also called inverse multiplexing. Using several pipes with a high level multiplexing protocol (MP, MPP) to get the combined throughput. But: a) P50 As already mentioned, the P50, while it can do MPP on switched lines, it cannot be used Leased/Leased to do MPP on two independent Bs. This is weird, but everything is already said. Hope for the FR... b) MPP Madness There is this nice dyn stat window which shows two interesting values: a) Channel Count b) Bandwith It is clear that a switched MPP call using 4 B channels shows up here as 4 channels 256 kbps bandwith. But if we build a big pipe by low level bundling 4 Bs off a PRI, it shows the same ! This is weird, as MPP via 4 low level bundled Bs doesn't mean 4 MPP channels - it is _one_ channel via the big pipe. This breaks all the nice statistics MPP tries to keep. If you go to debug mode (mppcm), you see that MPP constantly (every second) tries to remove channels from this line, even if there is only one channel. It thinks the Bs in the low level bundle would be individual channels. For a 31 channel line: MPP-2: Event = Utilization, CurrentState = Idle/A MPP-2: check dynamic says: current = 31, recommended = 2 MPP-2: new state is: Idle/A Over and over again... Note: I could set MPP to 31 channels. This is broken. I have one channel. If I set it to 31 channels, it doesn't help at all on the real problem caused by this bug: Nailed/Mpp will not work as expected (see below). c) Failover - how the hell ? The ability to failover a nailed line that broke to a dial-on-demand (DOD) line is advertised in lengthy by Ascend and is a major necessity for ISPs and other customers. But how ? The latest versions seem to provide a chance to do failover simply IP-routing-based by selecting proper Metric and DownMetric values (or Preference). But these values are brandnew - how should this have worked before ? The only answer I found is: Nailed/Mpp. Nailed/Mpp is a mixup of two components: The ability to bundle several nailed groups on a higher level and the ability to specify a dial on demand way to add further channels to the existing nailed lines. Nailed/Mpp can be used to add dynamic bandwidth to a nailed line. Nailed/Mpp can be used to failover to a dial on demand line as soon as the nailed line fails. However, Nailed/Mpp is not really good for either. Adding bandwidth didn't work as we tested it lately. It thought it needed to add band- width nicely (mppcm again), but it failed to call (call not possible or such). Failover is even more problematic: I need failover, no bandwidth addition, thus I would need a way to disable bandwidth addition. But now the really horrific - combine a low level bundled line (as an example an E1 with 31 channels) with Nailed/Mpp to get a failover to _one_ switched B channel. It's impossible. First MPP thinks it has 31 channels and wants to reduce them. This lets the stats go weird and disturbs the Nailed/Mpp setup. The only chance to deal with this would be to wire the MPP options to 31 channels. Now guess what happens if the E1 fails - Nailed/Mpp will try to establish 31 (!) dialed channels, wont it ? We gave up on testing this when we saw that suddenly we had _two_ sessions with the _same_ profile shown up on our Max, and the routing to the remote side break totally. BTW, Nailed/Mpp is the only way to do high level bundling of nailed lines, but why ? MP or MPP would be sufficient, there is no need to add dial on demand capabilities just to MP(P)-bundle several pipes which may in turn be low level bundles of B channels. Has this changed lately ? When I last tested, I couldn't specify Call Type=Nailed Group=1,2,3 but this should work with MP/MPP, shouldn't it ? Serial WAN interfaces make the next problem. Besides from their limited availability (see 3) they are statistically broken in MPP either: 0 Channels 0K Bandwidth How is Nailed/MPP expected to work with a nailed line that has 0K bandwidth and thinks it has 0 channels ? You know it: mppcm shows constant tries to add a channel (current=0, recommended=1) and failover to a dialed line fails completely. We had our Max placing calls to a mythic number "70" over and over again, which was of course nowhere in the NVRAM or RADIUS. But we have a serial WAN link, running MPP, and the other side has a phone number that ends with "70". Seems MPP decided to call this number (clearly 0K 0 channels is a bit low). Going back to MPP fixed this. We are even under the impression that our TR#2554 crashes where influenced by this MPP behavior. 5.0Ap24 ran well for more than a week, the problem appeared when p27 was installed _and_ the serial WAN line went into operation. It didn't disappear on downgrade to p24, so gues what ? We are now back on p13 and plugged a V.34 card... Conclusion: The statistics for MPP need fixing. From my point of view these fixes would be: - MPP counts every nailed group as one channel. It doesn't matter how this channel is constructed, from MPPs view it is one channel. - MPP thus counts a serial WAN interface as one channel. Thats trivial. - MPP uses the real bandwidth of the channel. If it is a group of B channels it can be computed (our 31 channel E1 is 1984K 1 channels, if you MPP-bundle two of them it is 3968K 2 channels). - The Serial WAN menu requires a new parameter, Bandwidth. Here I would plug the real bandwidth of the serial WAN link, in case of an E1 CSU/DSU this would be 1984K as well: Module Name=Serial Nailed Grp=64 Activation=Static Bandwidth=1984 - The ability to bundle nailed lines with MP/MPP must be independent of the Nailed/Mpp switch type. Nailed/Mpp is only necessary for adding dynamic bandwidth to a leased line (which may be a bundle of groups). - Nailed/Mpp needs a switch to specify whether it should actually add and remove bandwidth or be only a failover solution. In the failover case, the dial on demand line should be really DOD, i.e. it should not stay open when no traffic is there. This seems to be the current be- havior, but docs (if at all) specify another one. If you now prefer other ways of failover, please document them. I'm under the impression that with newer releases I can simply set up two times the same profile, make one nailed and the other switched, and set the Metric of these profiles as (example): Metric (Nailed): 1 Metric (Switched): 2 Down Metric (Switched): 7 Down Metric (Nailed): 8 and expect the rest to be done properly by the routing engine. Am I right ? Problems with duplicate profile names and LAN Adrs ? 3) Serial WAN interfaces They are a great idea. They seem to be documented, but making a cable f.i. to plug a Primus X.21/E1 CSU/DSU onto them is impossible without the real cabling plan (the one in the docs is bogus). We finally got this (with the help from Ascend support), and it works quite nice. Even the so-called V.35 P130 can speak with the X.21 CSU/DSU with this exact same cable (one of my seldom positive surprises with Ascend in the last months, however it also sheds a light on quality of documentation). But: Why is there no way to add further serial WAN interfaces to a Max ? There are MX-SL-2PMHP cards, but they add serial HOST ports which are of no use here. Kevin only said "FR". Seems that they were simply forgotten, but why ? Does Ascend expect every customer to have at least a TNT ? A 2 port serial WAN card for our Max4000 would fit our needs _perfectly_, but there is none. So we are using Net/E1 bundles instead, but they need HDLC cards in turn (see 1) and suffer MPP madness (see 2b). BTW: Is there any chance the once mentioned to be in development P130/E1 (i.e. P130 with builtin E1 CSU/DSU) will ever come to live ? I can use a P130/V.35 and plug a Primus onto its serial WAN port, but then I could also use a small Cisco. A P130/E1, however, would be extremely interesting on the German market - the typical "better" leased line around here is the German Telekom D2MS, an E1 leased line. Building leased lines just with two P130/E1 or a P130/E1 to a central Max with Net/E1 or serial WAN /Primus seems very cost effective and easy to handle. Conclusion: Please double think about an ability to add serial WAN cards to a Max. Double think about the P130/E1. Especially those two systems together can ease the life of medium sized PoPs and smaller ISPs. Especially over here in Germany and in the whole E1 area. Thanx in advance for any comments (or corrections, I'd rather like to hear that something is possible and I'm too dumb to use it instead of it is impossible), Andre. -- Kanther-Line: PGP SSH IDEA MD5 GOST RIPE-MD160 3DES RSA FEAL32 RC4 +-o-+--------------------------------------------------------+-o-+ | o | \\\- Brain Inside -/// | o | | o | ^^^^^^^^^^^^^^ | o | | o | Andre' Beck (ABPSoft) beck@ibh-dd.de XLink PoP Dresden | o | +-o-+--------------------------------------------------------+-o-+ ++ Ascend Users Mailing List ++ To unsubscribe: send unsubscribe to ascend-users-request@bungi.com To get FAQ'd: <<A HREF="http://www.nealis.net/ascend/faq">http://www.nealis.net/ascend/faq</A>> </PRE> <!--X-MsgBody-End--> <!--X-Follow-Ups--> <!--X-Follow-Ups-End--> <!--X-References--> <!--X-References-End--> <!--X-BotPNI--> <HR> <UL> <LI>Prev by Date: <STRONG><A HREF="msg09521.html">Re: (ASCEND) IE4.0 vs. Pipeline Monitor/Configurator.</A></STRONG> </LI> <LI>Next by Date: <STRONG><A HREF="msg09520.html">(ASCEND) Ap27</A></STRONG> </LI> <LI>Prev by thread: <STRONG><A HREF="msg09535.html">Re: (ASCEND) Ap27</A></STRONG> </LI> <LI>Next by thread: <STRONG><A HREF="msg09523.html">(ASCEND) MAX 4000 with ATMP</A></STRONG> </LI> <LI>Index(es): <UL> <LI><A HREF="mail20.html#09526"><STRONG>Main</STRONG></A></LI> <LI><A HREF="thrd198.html#09526"><STRONG>Thread</STRONG></A></LI> </UL> </LI> </UL> <!--X-BotPNI-End--> <!--X-User-Footer--> <!--X-User-Footer-End--> </BODY> </HTML>