Re: FR question

jp@sugar.midcoast.com
Sat, 5 Jul 1997 17:14:08 -0400 (EDT)

>
> At 06:22 PM 07/02/97 -0400, jp@sugar.midcoast.com wrote:
>
> >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.

A couple others brought this up. Thanks to all. It's an important point which
is overlooked by people, like me, who learn FR by the seat of their pants.

> 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.

We ended up asking for DLCI's 27 and 28, and got it working. (neither were in
use by either network, and it ended up working)

After we asked for the new DLCI's, I got LMI from Nynex indicating the new DLCI,
which means it could have been a problem there too.

In an effort to work around my problem, I also did not try to connect to both
frame relay "networks" at the same time, (using sub-interfaces, which I've
effortlessly setup several times in the past on other livingston routers).
Instead, I had the guy with the cisco join our frame relay network. It worked.

> 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.

I'd advocate 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.
>
>
>

-- 
/*
Jason Philbrook         |         Midcoast Internet Solutions
jp@midcoast.com         |     Internet Access, LAN, WAN, and Linux
www.midcoast.com/jp/    |   Service and Consulting for Midcoast Maine
*/