Re: (ASCEND) Connecting 2 DSLTNTs via SDSL

[Phillip Vandry <vandry@Mlink.NET>]

> I have 2 DSLTNT's that I want to connect together vis
> SDSL, one functioning as the COE (where the link to
> the internet is) and the other functioning as the CPE,
> where additional xDSL lines will go to customers with
> DSLPipelines. Can this be done ?

Yes. We use this *extensively*.

Here are the most important issues:

The way the SDSL chipset works is that it is configured and activated by
the software, and will only attempt to bring up the link once it has been
activated. This is OK for Pipeline to TNT connections, or for Pipeline
to Pipeline connections, because the Pipeline constantly tries to
reconfigure and reactivate the chipset over and over until it comes up.

But the TNT only activates 4 ports at a time. When the card first boots,
it configures and activates only the first 4 ports. When it's done with
those, it moves on to the next set of 4 ports, and so on. (I'm not sure
exactly what the source of this limitation is). This happens fairly
quickly, it goes through all 24 ports generally within a 90-120 seconds.

When you connect a TNT to a Pipeline, this is OK, because whenever the TNT
gets around to activating port "x", it will be met with a Pipeline that is
also activating the link.

But when you connect to a TNT, you might be unlucky: one TNT might be
activating one port while the other is activating some other port and they
might never see each other (think of two people looking for each other in
a house and one is seaching the living room while the other is seaching
the kitchen, and they don't find each other and then they cross each other
and look again and they still can't find each other, and so on).

Now in practice the link will always come up eventually, and chance will
work out that both TNTs will find each other actually quite quickly,
however you should keep this in mind, because I have seen TNT to TNT
SDSL links take 10 minutes to come up on occasion.

Among other issues:

- I do not recommend using OSPF over these links. In my experience it was
a little too flaky.

- If your goal is to have multiple SDSL links in parallel between the
same two boxes (redundancy and load balancing), then be careful to make
changes to only 3-4 of them at a time (i.e. configure one group, let the
links come up again or whatever needs to be done, then move on to the
next group). I have found that making config changes to lots of ports
at one time will crash the SDSL card (7.0.1, 7.0.4, various engineering
releases). YMMV.

- (This applies to all SDSL links) I recommend running BERT tests (2 minutes)
every time you install an SDSL link. It is better to see errors on the link
at that time then wonder why you get packet loss later on, or why there
are LMI errors (Frame Relay). Plus if you have a positive test result
(no errors), it can help you feel confident in the quality of the link :-)

> For customers with Pipelines, we are normally using FR
> over SDSL; is this the best solution for connecting
> the DSLTNTs, by setting one as the DTE and the other
> as the DCE, just like we would do with a "normal"
> DSLTNT<->Pipeline connection ?

FR encapsulation is the default and is recommended by Ascend (and by me)
because there are good applications for Frame Relay's support for virtual
circuits in the DSL world. PPP's main advantage over FR is that it
supports authentication. But most people don't authenticate leased lines
or DSL links (which work just like leased lines). After all a cracker
needs physical access to the wire to hijack it (with switched links all
they need is a phone number). So use FR. Maybe you can even sell Frame
Relay services to your customers (use frame relay switching functionality
in the TNTs).

Depending on what this TNT to TNT link is being used for, you can use,
as you suggest, DCE to DTE (for consistency, assign DCE to the COE SDSL
and DTE to the CPE SDSL). But if you are using frame relay switching or
simply if you think this link falls under the definition of backbone or
trunk, you can use NNI frame relay on both sides. It doesn't really
matter, you can actually sidmiss the previous sentence as semantic
irrelevance and use NNI on both sides. NNI stands for Network to Network
Interface, and is the type of link used inside frame relay networks (as
opposed to at the edge). An NNI interface performs both DCE and DTE
tasks. There are tangeible advantages to using NNI only if you use
frame relay switching.

> Is there anything special thatI have to take into
> consideration with this setup ? 
> If anyone is running a similar setup, I would
> appreciate example connection and frame-relay
> profiles!


TNT #1:

;
new FRAME-RELAY
set fr-name = ontario1
set active = yes
set nailed-up-group = 11
set link-mgmt = ansi-t1.617d
set link-type = nni
write -f
;
new SDSL
set name = 1:2:1
set physical-address shelf = shelf-1
set physical-address slot = slot-2
set physical-address item-number = 1
set enabled = yes
set line-config nailed-group = 11
write -f
;
new CONNECTION
set station = ontario1
set active = yes
set encapsulation-protocol = frame-relay
set session-options idle-timer = 0
set telco-options call-type = ft1
set mp-options enabled = no
set fr-options frame-relay-profile = ontario1
set framed-only = yes
write -f
;

TNT #2:

new FRAME-RELAY
set fr-name = belmont1
set active = yes
set nailed-up-group = 11
set link-mgmt = ansi-t1.617d
set link-type = nni
write -f
;
new SDSL
set name = 1:1:1
set physical-address shelf = shelf-1
set physical-address slot = slot-1
set physical-address item-number = 1
set enabled = yes
set line-config nailed-group = 11
set line-config unit-type = cpe
write -f
;
new CONNECTION
set station = belmont1
set active = yes
set encapsulation-protocol = frame-relay
set session-options idle-timer = 0
set telco-options call-type = ft1
set mp-options enabled = no
set fr-options frame-relay-profile = belmont1
write -f

-Phil
++ Ascend Users Mailing List ++
To unsubscribe:	send unsubscribe to ascend-users-request@bungi.com
To get FAQ'd:	<http://www.nealis.net/ascend/faq>