Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations SkipVought on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

DLCI nail down to a particular trunk?

Status
Not open for further replies.
Jul 18, 2004
25
0
0
IN
Hi,

Need to know how we can nail down a DLCI to a particular trunk only? and if this trunk goes down only then go via the alternate path?
Is this possible with Nortel 7480?

thanks
Keshav
 
Hi kashnortel,
guaranteeing that an indivdual DLCI is using a particular trunk at any point in time may be difficult - especially if you have a large number of DLCs and trunks available to route them.
By default, Passport trunks use a "load spreading" algorithm where all packets of the first VC to establish over a link group use the same link - that is, all information goes down the same link. Successive DLCs to establish over this link group will generally use each other link in turn (assuming all DLCs are about the same bandwidth) and then the original link again, and so on. In this way, if you have 5 x 100kbps DLCs establishing over a link group with 3 links in it, the first (lowest throughput metric) link will have the first and fourth DLCs over it, and second link will have the second and the fifth DLC over it, and the third link will have only one (the third DLC established).

One other option available to you is "loadsharing" where packets from each DLC are shared across all links in the link group. This is the opposite of what you want.

So, by default (load spreading), you will be using ONE of your links for your DLCI, but it might not be the right one. You can make one trunk look more attractive to Frame Relay (throughput-based) traffic by altering the throughput metric which would normally be used for path selection. Eg: increase the OverrideTransmitSpeed of the trunk you usually want the DLC to use, and then when that trunk goes down the remaining trunk will be the only remaining choice. Conversely, decrease the OverrideTransmitSpeed of the non-preferred trunk instead.
Here's what the NTPs (241-5701-420 4.2S1) describe:
"Changing provisioned Passport trunk overrides
Passport trunk overrides consist of two provisionable Trunk attributes:
overrideTransmitSpeed and overrideRoundTripDelay. These attributes
override the operational Trunk attributes measuredRoundTripDelay and
measuredSpeedToIf when reporting to the routing system for metric
calculations. You can control the metrics calculated for this Passport trunk
and in turn the routing behavior by using overrides.
If you change either the overrideTransmitSpeed or overrideRoundTripDelay
attribute
• while the Trunk component is providing service, then these values are
renegotiated with the remote Passport trunk with no disruption to the
service
• while the Passport trunk is still staging, then the Passport trunk
immediately restages
If there is a mismatch on two ends, the system issues the alarm 7005 0108
(overrideRoundTripDelay) or 7005 0109 (overrideTransmitSpeed). No
change in metrics occurs until both ends are running with the same override
values"

Don't forget that this will apply behaviour to ANY traffic going across these trunks - you may affect more than just a single DLCI that you are interested in. Your scenario sounds fairly simple but if you've left out more detail about you topology etc, then be careful.
Doing this stuff to force DPRS traffic around like this makes one appreciate PORS routing features like specifying a Manual Path!
Have fun!
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top