Ascend Archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
(ASCEND) The Nailing Game (long)
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: <http://www.nealis.net/ascend/faq>