>I've run into bit of trouble hooking up a frame relay link. Here's the
>situation- if anyone has suggestions let me know. Perhaps it can't be
>done?
>
>My IRX has the DLCI 16 for the local DLCI on the primary FR interface.
>
> [IRX frm1]-------[Nynex]----DLCI 17 [pm2er] (works great)
> [ ] [ ]----DLCI 18 [ascend] (works great)
> [ ] [ ]----DLCI 19 [ascend] (works great)
> [ sub-if] [ ]----DLCI 28 [cisco]---DLCI 16--Nynex (no
communications)
>
>The IRX and the Cisco are each part of different Frame Relay networks, but
>we had the other end include us in their network by giving us DLCI 28 and
>having us make a sub-interface, so that makes the IRX part of both
>networks.
>
>The key is that both routers have DLCI 16 has their local FR
>interface, though each DLCI 16 is on a different FR network for the IRX.
>Is this causing the problem, or is the Cisco the problem, or is the
>network design the problem? Maybe it will work afterall and it's a Nynex
>problem?
>
>I've tried messing with the DLCI-ipnumber static mappings but to no avail.
>
>We also stopped receiving DLCI 28 from the LMI information coming from the
>switch, which means it might be a nynex problem. But if it's a Nynex
>problem, we have to be lucky and catch a clueful person which hasnt
>happened yet.
The most important thing you need to know (and from your post I wasn't sure
if you already knew this, which is why I mention it) is that when you are
programming a frame relay device, it is always completely irrelevant what
the DLCI is on the other end of the connection. The *only* thing that
matters is what the DLCI is on *your* end of the connection. The two DLCIs
might be the same number, or might be different, and that too is irrelevant.
For many FR connectivity providers, the custom is to start numbering DLCIs
from 16 and going up. You could make a special request that a particular
PVC be assigned a DLCI number that is something other than "the next in
order" but in general there is no reason to do so.
There are some people whose approach to this is to turn on all routing
broadcasts and listening and turn on LMI and let the routers sort out for
themselves how to route packets from one machine to the next over the FR
cloud. There are other people whose approach to this is to turn off all
routing broadcasts and listening and simply hand-type the static routes to
make it all work. Hopefully I won't start a flame war by advocating the
second approach.
Anyway, if you have turned on the trace function that lets you watch the
LMI packets as they come in, this is certainly a helpful diagnostic step
for you to take. If the DLCI list that is received differs from what you
expected, then you do have work to do. If you have the *correct* number of
DLCIs (it matches the number of PVCs you are paying for, in this case four)
then you should just call up the telco and have them explain to you which
DLCI goes to which distant router. Then set up static routes (if you
happen to follow the second approach above) to make each link work properly.
You could probably also work out which DLCI goes to which router by trial
and error. Or you could (gack) turn on all routing (broadcasts and
listening) and watch the machine for a while and see if it manages to build
up its own routing table. This has the possibility of being problematic
since the distant routers may not be programmed to do this for you (i.e.
they may not be broadcasting).
if the number of DLCIs is *smaller* than the number of PVCs you are paying
for, then clearly you need to call up the FR service provider (in this
case, apparently Nynex) and get it straightened out.